Kör VS Code AI Coding Assistants genom en OpenAI-kompatibel gateway

Gatewayen mappar sedan dessa profiler till backend-modeller. Till exempel:

{
  "model_profiles": {
    "code-fast": {
      "primary": "provider_a/coding-small",
      "fallback": "provider_b/general-fast",
      "max_context_tokens": 32000,
      "max_output_tokens": 4096
    },
    "code-review": {
      "primary": "provider_c/long-context-code",
      "fallback": "provider_a/coding-large",
      "max_context_tokens": 128000,
      "max_output_tokens": 8192
    }
  }
}

Detta håller redaktörskonfigurationen stabil även när backend-modellnamnen ändras. Det låter också plattformsteam flytta trafik under leverantörsincidenter eller modellavskrivningar utan att be alla utvecklare att redigera lokala inställningar.

Steg 4: Konfigurera varje verktyg som en gatewayklient

VS-kod BYOK

Använd leverantörsinställningsflödet för att lägga till en modellleverantör och välj den från chattmodellväljaren. Om gränssnittet accepterar en bas-URL, använd gateway-slutpunkten /v1. Använd utvecklarens gateway-nyckel som API-nyckel och visa godkända modellprofil-ID:n som kodsnabb eller kodgranskning.

Anmärkning: BYOK-trafik för leverantörsstödda modeller faktureras av den konfigurerade leverantörssökvägen, inte av GitHub Copilot-kvoter. Det är en anledning till att lägga gateway-fakturering och attribution mellan redaktören och backend-leverantörerna.

GitHub Copilot-appen BYOK

För Copilot-appen BYOK, konfigurera den OpenAI-kompatibla HTTP-slutpunkten med ett visningsnamn, bas-URL och API-nyckel. Använd ett visningsnamn som gör routningsvägen tydlig, till exempel Company AI Gateway. Håll modell-ID:n i linje med gateway-profiler.

Anta inte att alla Copilot-drivna funktioner kommer att gå genom denna väg. Vissa semantiska sökningar, inline-förslag eller inbäddningsberoende beteende kan förbli knutna till GitHub- eller Copilot-specifika tjänster.

Fortsätt

Continue kan använda en OpenAI-leverantörskonfiguration med en åsidosatt API-bas. En minimal konfiguration bör peka leverantören mot gatewayen och använda profil-ID:n som modeller:

{
  "modeller": [
    {
      "title": "Kod snabbt",
      "provider": "openai",
      "model": "kodsnabb",
      "apiBase": "https://gateway.example.com/v1",
      "apiKey": "${GATEWAY_API_KEY}"
    }
  ]
}

Föredrar miljövariabler eller hemlig lagring framför att överföra nycklar till dotfiler eller lagringslokal konfiguration.

Klina

Cline stöder en OpenAI-kompatibel leverantör som använder bas-URL, API-nyckel och modell-ID. Konfigurera basadressen som gatewayslutpunkt, ange utvecklarnyckeln och välj en modellprofil som code-agent för agentarbetsflöden.

För företagsinstallationer, använd administratörskonfiguration där den är tillgänglig för att tillämpa den OpenAI-kompatibla slutpunkten i hela organisationen. Det minskar driften, särskilt för team som behöver anpassade rubriker, Azure-relaterade inställningar eller centralt hanterade autentiseringsvägar.

Roo Code

Roo Code stöder OpenAI-konfiguration med en valfri bas-URL. Ställ in bas-URL till gatewayen och använd godkända modell-ID:n. Om verktyget avslöjar avancerade kontroller som resonemang för modeller som stöds, bestäm om dessa kontroller är användarkonfigurerbara eller fixade av gatewaypolicy.

Steg 5: Börja med en godkännandelista

Åtkomst till öppen modell är attraktivt under experiment, men IDE-agenter kan snabbt producera hög tokenvolym. Börja med en godkännandelista:

• Standardanvändare får kodsnabb och kodekonomi.
• Agentanvändare får code-agent efter ombordstigning.
• Recensionstunga team får kodgranskning med högre men explicita budgetar.
• Experimentella modeller kräver en ägare, utgångsdatum och användningstak.

Policy ska vara synlig i gatewayen, inte begravd i lokala installationsanteckningar. En avvisad begäran bör returnera ett tydligt fel: utvecklaren, nyckeln, modellprofilen, orsaken och nästa steg.

Steg 6: Bygg analys för lanseringsfrågor

Allmänna tokensummor räcker inte. Utrullning av utvecklarverktyg behöver analyser som svarar på driftsfrågor:

• Spendera efter utvecklare och team
• Spendera efter arkiv eller projekt där etiketter är tillgängliga
• Modellmix efter redigeringsverktyg
• Genomsnittlig kontextstorlek och utdatastorlek efter profil
• Mislyckade samtal grupperade efter slutpunktsform, modell-ID och statuskod
• Outlier sessioner med ovanligt hög tokenanvändning
• Cacheträfffrekvens där promptcache stöds
• Budgetvarningar skickas till Telegram- eller teamoperationskanaler

Använd loggning som är redigerad med prompt som standard. Behåll metadata för förfrågningar, tokenantal, modell-ID:n, tidpunkter, feltyper och kostnadsreskontra. Lagra råuppmaningar endast när det finns ett dokumenterat felsökningsarbetsflöde, kort lagring och lämplig åtkomstkontroll.

Steg 7: Felsök slutpunkts- och kapacitetsfelmatchningar

OpenAI-kompatibel betyder inte beteendeidentiskt. Förvänta dig skillnader mellan chattslutföranden, svars-API:er, streaming, verktygsanrop, resonemangskontroller, modellmetadata och leverantörsfelformat.

Använd den här checklistan när ett verktyg misslyckas:

• Anslutningsfel: Kontrollera lokal proxy, brandvägg, DNS, TLS-inspektion och om verktyget kan nå gatewayvärden.
• 401 eller ogiltig nyckel: Bekräfta att utvecklarnyckeln är aktiv, omfångad till verktyget och inklistrad utan blanksteg.
• 404 eller modellen hittades inte: Bekräfta att verktyget använder gateway-profilens ID, inte ett obearbetat backend-modell-ID.
• Fel slutpunkt: Kontrollera om klienten förväntar sig /v1 i basadressen eller lägger till den internt.
• Verktygsanropsfel: Bekräfta den valda profilen mappar till en modell och adapter som stöder verktygsanrop i det format som klienten skickar.
• Strömningsfel: Testa icke-strömmande läge och bekräfta sedan att gatewayen bevarar serversänd händelsebeteende som förväntas av klienten.
• Oväntad utdata: Kontrollera om profilen ändrade backend-modeller, om systemuppmaningar skiljer sig åt mellan olika verktyg och om klienten använder en resonemangsinställning som backend inte stöder.

Steg 8: Rulla ut i etapper

Börja inte med varje utvecklare och varje redaktör. Använd en stegvis lansering:

1. Pilot: Välj ett team med aktiv AI-kodning. Utfärda nycklar per utvecklare, aktivera två eller tre profiler och samla in loggar som har redigerats med prompt.
2. Baslinje: Granska utgifter efter användare, modellmix, feltyper och sammanhangsstorlekar efter en eller två veckor.
3. Policy: Ange standardbudgetar, tillåtna profiler och undantagsregler.
4. Automatisering: Tillhandahåll nycklar via SSO, SCIM, ett Partner API-arbetsflöde eller ett internt introduktionsskript.
5. Utökning: Publicera inställningskodavsnitt för varje verktyg som stöds och använd organisationsomfattande fjärrkonfiguration där verktyget stöder det.

Det stegvisa tillvägagångssättet ger utvecklare en arbetsväg tidigt samtidigt som det låter plattformsteam skärpa styrningen med verklig användningsdata.

Aktiv slutsats

Operationsmodellen är enkel: få varje VS Code AI-kodningsassistent att se ut som en gatewayklient, utfärda en gatewaynyckel per utvecklare, exponera uppgiftsorienterade modellprofiler och analysera redaktörstrafik centralt. Det ger utvecklare samma lokala arbetsflöde samtidigt som organisationen får en plats att hantera fakturering, modellåtkomst, felsökning och incidentrespons.

Börja med en pilot, en liten godkännandelista, loggar som har redigerats snabbt och budgetvarningar. Expandera först efter att gatewayen kan svara på de grundläggande utrullningsfrågorna: vem använder vilket verktyg, vilken modellprofil driver kostnaden, vilka slutpunktsfel som orsakar misslyckanden och vilka utvecklare som behöver högre gränser för legitimt arbete.

Relaterad läsning

• praxis för nyckelhantering per utvecklare för API
• prompt-redigerad användningsanalys för gatewaytrafik
• modellprofilmigrering och utfasningsplanering