Kjør VS Code AI Coding Assistants gjennom en OpenAI-kompatibel gateway

Gatewayen tilordner deretter disse profilene til backend-modeller. For eksempel:

{
  "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
    }
  }
}

Dette holder redaktørkonfigurasjonen stabil selv når navnene på backend-modellene endres. Det lar også plattformteam flytte trafikk under leverandørhendelser eller modellavvikelser uten å be alle utviklere om å redigere lokale innstillinger.

Trinn 4: Konfigurer hvert verktøy som en gatewayklient

VS-kode BYOK

Bruk leverandørens oppsettflyt for å legge til en modellleverandør og velg den fra Chat-modellvelgeren. Der grensesnittet godtar en basis-URL, bruk gateway-endepunktet /v1. Bruk utviklergateway-nøkkelen som API-nøkkel og vis godkjente modellprofil-ID-er som code-fast eller code-review.

Operasjonsmerknad: BYOK-trafikk for leverandørstøttede modeller faktureres av den konfigurerte leverandørbanen, ikke av GitHub Copilot-kvoter. Det er en grunn til å sette gateway-fakturering og attribusjon mellom redaktøren og backend-leverandørene.

GitHub Copilot-appen BYOK

For Copilot-appen BYOK, konfigurer det OpenAI-kompatible HTTP-endepunktet med et visningsnavn, basis-URL og API-nøkkel. Bruk et visningsnavn som gjør rutebanen tydelig, for eksempel Company AI Gateway. Hold modell-ID-ene på linje med gateway-profiler.

Ikke anta at alle Copilot-drevne funksjoner vil rute gjennom denne banen. Noen semantiske søk, innebygde forslag eller innebyggingsavhengig atferd kan forbli knyttet til GitHub- eller Copilot-spesifikke tjenester.

Fortsett

Fortsett kan bruke en OpenAI-leverandørkonfigurasjon med en overstyrt API-base. En minimal konfigurasjon bør peke leverandøren mot gatewayen og bruke profil-ID-er som modeller:

{
  "modeller": [
    {
      "title": "Kode raskt",
      "provider": "openai",
      "model": "kode-rask",
      "apiBase": "https://gateway.example.com/v1",
      "apiKey": "${GATEWAY_API_KEY}"
    }
  ]
}

Foretrekk miljøvariabler eller hemmelig lagring fremfor committing av nøkler til dot-filer eller depot-lokal konfigurasjon.

Kline

Cline støtter en OpenAI-kompatibel leverandør som bruker basis-URL, API-nøkkel og modell-ID. Konfigurer basis-URLen som gateway-endepunkt, skriv inn utviklernøkkelen og velg en modellprofil som code-agent for agentarbeidsflyter.

For bedriftsimplementeringer, bruk administratorkonfigurasjon der det er tilgjengelig for å håndheve det OpenAI-kompatible endepunktet i hele organisasjonen. Det reduserer drift, spesielt for team som trenger egendefinerte overskrifter, Azure-relaterte innstillinger eller sentralstyrte autentiseringsbaner.

Roo Code

Roo Code støtter OpenAI-konfigurasjon med en valgfri basis-URL. Angi basis-URLen til gatewayen og bruk godkjente modell-ID-er. Hvis verktøyet avslører avanserte kontroller, for eksempel resonnementarbeid for støttede modeller, må du bestemme om disse kontrollene er brukerkonfigurerbare eller fikses av gatewaypolicy.

Trinn 5: Start med en tillatelsesliste

Åpen modelltilgang er attraktivt under eksperimentering, men IDE-agenter kan raskt produsere høyt tokenvolum. Start med en godkjenningsliste:

• Standardbrukere får koderask og kodeøkonomi.
• Agentbrukere får code-agent etter ombordstigning.
• Tunge team får kodegjennomgang med høyere, men eksplisitte budsjetter.
• Eksperimentelle modeller krever en eier, utløpsdato og bruksbegrensning.

Retningslinjer skal være synlige i gatewayen, ikke begravd i lokale oppsettnotater. En avvist forespørsel skal returnere en tydelig feil: utvikler, nøkkel, modellprofil, årsak og neste trinn.

Trinn 6: Bygg Analytics for utrullingsspørsmål

Generiske tokentotaler er ikke nok. Utrulling av utviklerverktøy trenger analyser som svarer på driftsspørsmål:

• Forbruk etter utvikler og team
• Bruk etter depot eller prosjekt der etiketter er tilgjengelige
• Modellmiks etter redigeringsverktøy
• Gjennomsnittlig kontekststørrelse og utdatastørrelse etter profil
• Mislykkede anrop gruppert etter endepunktform, modell-ID og statuskode
• Ytterligere økter med uvanlig høy tokenbruk
• Cachetrefffrekvens der hurtigbufring støttes
• Budsjettvarsler rutet til Telegram- eller teamoperasjonskanaler

Bruk prompt-redigert logging som standard. Behold forespørselsmetadata, tokenantall, modell-ID-er, tidspunkter, feiltyper og kostnadsreskontro. Lagre råmeldinger bare når det er en dokumentert feilsøkingsarbeidsflyt, kort oppbevaring og passende tilgangskontroll.

Trinn 7: Feilsøk endepunkt- og kapasitetsfeil

OpenAI-kompatibel betyr ikke atferdsidentisk. Forvent forskjeller på tvers av chatfullføringer, svar-API-er, strømming, verktøykall, resonneringskontroller, modellmetadata og leverandørfeilformater.

Bruk denne sjekklisten når et verktøy feiler:

• Tilkoblingsfeil: Sjekk lokal proxy, brannmur, DNS, TLS-inspeksjon og om verktøyet kan nå gatewayverten.
• 401 eller ugyldig nøkkel: Bekreft at utviklernøkkelen er aktiv, omfanget til verktøyet og limt inn uten mellomrom.
• 404 eller modell ikke funnet: Bekreft at verktøyet bruker gatewayprofil-ID-en, ikke en rå backend-modell-ID.
• Feil endepunkt: Bekreft om klienten forventer /v1 i basis-URLen eller legger den til internt.
• Verktøyanropsfeil: Bekreft den valgte profilen tilordnet en modell og adapter som støtter verktøyanrop i formatet klienten sender.
• Strømningsfeil: Test ikke-strømmemodus, og bekreft deretter at gatewayen bevarer serversendt hendelsesatferd som forventes av klienten.
• Uventet utgang: Sjekk om profilen endret backend-modeller, om systemforespørsler varierer fra verktøy til verktøy, og om klienten bruker en resonnementinnstilling som backend ikke støtter.

Trinn 8: Utrulling i etapper

Ikke start med alle utviklere og hver redaktør. Bruk en trinnvis utrulling:

1. Pilot: Velg ett lag med aktiv bruk av AI-koding. Utsted nøkler per utvikler, aktiver to eller tre profiler, og samle inn loger som er redigert med spørsmål.
2. Grunnlinje: Gå gjennom forbruk etter bruker, modellmiks, feiltyper og kontekststørrelser etter én eller to uker.
3. Retningslinjer: Angi standardbudsjetter, tillatte profiler og unntaksregler.
4. Automasjon: Leveringsnøkler gjennom SSO, SCIM, en Partner API-arbeidsflyt eller et internt onboarding-skript.
5. Utvidelse: Publiser oppsettkodebiter for hvert støttet verktøy og bruk fjernkonfigurasjon for hele organisasjonen der verktøyet støtter det.

Den trinnvise tilnærmingen gir utviklere en tidlig arbeidsvei samtidig som den lar plattformteam stramme styringen med reelle bruksdata.

Aktiv konklusjon

Operasjonsmodellen er enkel: få hver VS Code AI-kodingsassistent til å se ut som en gateway-klient, utsted én gatewaynøkkel per utvikler, eksponer oppgaveorienterte modellprofiler og analyser redaktørtrafikk sentralt. Det gir utviklere den samme lokale arbeidsflyten samtidig som organisasjonen får ett sted å administrere fakturering, modelltilgang, feilsøking og hendelsesrespons.

Start med en pilot, en liten godkjenningsliste, loger som er redigert med spørsmål og budsjettvarsler. Utvid først etter at gatewayen kan svare på de grunnleggende utrullingsspørsmålene: hvem bruker hvilket verktøy, hvilken modellprofil driver kostnadene, hvilke endepunktsfeil som forårsaker feil, og hvilke utviklere trenger høyere grenser for legitimt arbeid.

Relatert lesing

• nøkkeladministrasjonspraksis per utvikler API
• spørsmålsredigert bruksanalyse for gatewaytrafikk
• migrering og planlegging av modellprofiler