Claude Code, GitHub Copilot und Cursor über ein LLM-Gateway betreiben

Warum Coding-Agenten überhaupt über ein Gateway laufen sollten

Mit einem Gateway haben Sie eine zentrale Stelle für Verkehr, der sonst direkt von jedem Entwickler-Laptop zum Modellanbieter geht. Die Claude-Code-Dokumentation von Anthropic nennt dieselben Vorteile, die die meisten Plattformteams suchen:

• Ausgaben pro Team: Jeder Engineer hat eigene Gateway-Zugangsdaten, sodass die Nutzung einer Person und einem Team zugeordnet wird, egal welcher Anbieter die Anfrage bedient
• Eine Positivliste für Modelle: Das Gateway stellt nur die Modelle bereit, die Sie freigegeben und bepreist haben
• Sperren an einer Stelle: Der Anbieterschlüssel bleibt auf dem Server, und beim Offboarding werden nur die Gateway-Zugangsdaten dieser Person widerrufen
• Wahl von Anbieter und Region: Das Gateway kann an Claude auf Amazon Bedrock, Google Cloud oder Microsoft Foundry in Ihrem eigenen Cloud-Konto weiterleiten, und ein Wechsel erfordert keine Änderung auf den Rechnern der Engineers
• Ein Audit-Log der Modellanfragen, wo Ihre Richtlinien das verlangen

Ein Anbieterwechsel ohne Eingriff auf den Laptops funktioniert nur, wenn das Gateway einen einzigen Endpunkt im Anthropic-Format bereitstellt, ganz gleich, was dahinter liegt. Der Preis: Das Gateway wird zu Infrastruktur, die Sie selbst betreiben. Anthropic weist darauf hin, dass Claude Code mit jedem Release neue Funktionen bekommt und dass diese hinter einem Gateway, das sie nicht weiterreicht, ausfallen. Jemand muss es also aktuell halten. Unsere Einschätzung: Ein einzelnes Team mit einem Anbieter und ohne Audit-Pflicht kommt oft mit getrennten Workspaces oder Schlüsseln beim Anbieter aus. Ein Gateway lohnt sich, sobald mehrere Teams, mehrere Werkzeuge oder Vorgaben zum Datenstandort hinzukommen.

Welche Coding-Agenten ein Gateway unterstützen, Stand 7. November 2026

Nur bei Claude Code können Sie den gesamten Modellverkehr über Ihr eigenes Gateway schicken und das zentral erzwingen. Bei GitHub Copilot und Cursor bringen Sie Anbieterschlüssel oder Endpunkte für einen Teil des Produkts mit, für den Rest bleiben deren eigene Modelle im Einsatz.

GitHub Copilot mit eigenem Schlüssel

Bei GitHub gibt es zwei Varianten. Enterprise-BYOK für Copilot Business und Copilot Enterprise, weiterhin in Public Preview, erlaubt Enterprise- oder Organisations-Ownern, Schlüssel zu hinterlegen. Die zugehörigen Modelle sehen dann alle Nutzer unten in der Modellauswahl. Im Januar 2026 kamen AWS Bedrock, Google AI Studio und beliebige OpenAI-kompatible Anbieter hinzu, außerdem Modelle mit Responses API, ein maximales Kontextfenster und Streaming. Über die OpenAI-kompatible Option binden Sie einen LiteLLM-Endpunkt an. Lokale BYOK-Schlüssel bleiben auf dem Rechner der Person. Laut der Ankündigung von GitHub für VS Code vom April 2026 rechnet Ihr Anbieter die Nutzung ab, sie wird nicht auf die Copilot-Kontingente angerechnet und gilt nicht für Code-Vervollständigungen.

GitHub beschreibt Enterprise-BYOK als serverseitig über die Copilot API abgewickelt und dokumentiert den Datenweg nicht. Wir lesen das so, dass die Anfragen an Ihren Endpunkt dann von GitHub ausgehen und nicht vom Laptop des Engineers. Klären Sie die Netzwerkanforderungen also mit GitHub, bevor Sie ein nur intern erreichbares Gateway einplanen.

Cursor mit eigenen API-Schlüsseln

Die Hilfeseite von Cursor zu API-Schlüsseln nennt OpenAI, Anthropic, Google, Azure OpenAI und AWS Bedrock. Bedrock wird über Schlüssel in der IDE oder über IAM-Rollen im Cursor-Dashboard angebunden. Eigene Schlüssel funktionieren nur mit Chat-Modellen, die Tab-Vervollständigung nutzt weiter die eingebauten Modelle von Cursor. Anfragen laufen über die Server von Cursor, wo der endgültige Prompt zusammengesetzt wird. Der Schlüssel wird mit jeder Anfrage mitgeschickt und nicht gespeichert. Die Zero-Data-Retention-Richtlinie von Cursor gilt bei eigenen Schlüsseln nicht, und in den Plänen Teams und Enterprise berechnet Cursor für Anfragen mit eigenem Schlüssel zusätzlich zu den Kosten des Anbieters eine eigene Gebühr. Eine eigene Basis-URL dokumentiert die Seite nicht. Mit eigenen Schlüsseln rechnen Sie also über Ihr Azure- oder Bedrock-Konto ab, der Verkehr verlässt Ihr Netz trotzdem.

Claude Code mit LiteLLM oder einem anderen Gateway einrichten

Claude Code braucht eine Basis-URL und Zugangsdaten. ANTHROPIC_BASE_URL verweist auf ein Gateway, das das Anthropic-Messages-Format unter /v1/messages anbietet. LiteLLM kann das. Die Zugangsdaten gehören in ANTHROPIC_AUTH_TOKEN, wenn das Gateway einen Bearer-Token im Authorization-Header liest (so werden auch virtuelle Schlüssel von LiteLLM übergeben), oder in ANTHROPIC_API_KEY, wenn es x-api-key liest. Für Schlüssel, die rotieren oder aus einem Vault kommen, gibt ein apiKeyHelper-Befehl die Zugangsdaten aus, und Claude Code sendet sie in beiden Headern. Die Ausgabe wird standardmäßig fünf Minuten zwischengespeichert, einstellbar über CLAUDE_CODE_API_KEY_HELPER_TTL_MS.

Verteilen Sie beides über verwaltete Einstellungen und Ihre Secrets-Werkzeuge, nie über das Repository. Anthropic rät davon ab, Zugangsdaten in die .claude/settings.json eines Projekts zu schreiben, weil diese Datei eingecheckt wird. Damit ein verwalteter Rechner nur noch das Gateway ansprechen darf, setzt die Datei mit den verwalteten Einstellungen allowedProviders und die Basis-URL gemeinsam:

{
  "allowedProviders": ["customEndpoint"],
  "env": {
    "ANTHROPIC_BASE_URL": "https://llm-gateway.example.com"
  }
}

Claude Code lehnt dann jede Sitzung ab, die auf ein anderes Ziel zeigt, auch direkt auf Anthropic oder auf einen privaten Proxy eines Engineers. Spricht das Gateway die nativen Formate von Amazon Bedrock oder der Agent Platform von Google Cloud, früher Vertex AI, nutzen Sie ANTHROPIC_BEDROCK_BASE_URL mit CLAUDE_CODE_USE_BEDROCK=1 und CLAUDE_CODE_SKIP_BEDROCK_AUTH=1 oder die Gegenstücke mit VERTEX. Claude Code sendet dann nur die Funktionen, die diese Anbieter akzeptieren. Für Microsoft Foundry gelten ANTHROPIC_FOUNDRY_BASE_URL und CLAUDE_CODE_USE_FOUNDRY=1.

Drei Details überraschen Teams regelmäßig. Gateway-Zugangsdaten ersetzen für diese Anfragen das claude.ai-Abonnement des Engineers. Der Verkehr wird also pro Token dem Inhaber des Upstream-Schlüssels berechnet. Wer nur die Basis-URL setzt, nutzt weiter das Abonnement. Die VS-Code-Erweiterung liest Gateway-Variablen aus claudeCode.environmentVariables, die Desktop-App dagegen aus ihrer eigenen Konfiguration für Drittanbieter-Inferenz und nicht aus ANTHROPIC_BASE_URL. Und Anthropic unterstützt es nicht, Claude Code über ein Gateway an Modelle anderer Anbieter als Claude zu leiten, auch wenn ein Gateway das technisch möglich macht.

Was das Gateway sieht, was Sie protokollieren und was nicht

Das Gateway sieht alles, was der Agent an das Modell schickt: den System-Prompt, den Gesprächsverlauf, Quellcode und Dateiinhalte, die der Agent gelesen hat, Befehlsausgaben und Tool-Ergebnisse. Ein Secret in einer Datei, die der Agent öffnet, kann also hindurchlaufen. Claude Code sendet außerdem Header, die bei der Zuordnung helfen: x-claude-code-session-id bündelt die Anfragen einer Sitzung, x-claude-code-agent-id kennzeichnet Anfragen von Subagenten. Anthropic weist darauf hin, dass die Agent-ID nur einen Agenten bezeichnet, nicht eine Person oder ein Gerät.

Für Kosten und Betrieb reichen Metadaten. Ein brauchbarer Datensatz pro Anfrage enthält:

• Den Gateway-Schlüssel sowie Team und Engineer, denen er gehört
• Das angefragte Modell und das Modell, das geantwortet hat, einschließlich Fallbacks
• Eingabe-, Ausgabe-, Cache-Lese- und Cache-Schreib-Token sowie die berechneten Kosten
• Statuscode, Latenz und Time to First Token
• Sitzungs- und Agent-IDs aus den Anfrage-Headern

Speichern Sie Anfrage- und Antworttexte nur, wenn ein schriftlich festgelegter Zweck das verlangt. Laut Dokumentation erfasst LiteLLM Inhalte von Anfragen und Antworten standardmäßig nicht. store_prompts_in_spend_logs schaltet das ein, und ein Admin kann es auch in der Oberfläche ändern, wo es die Konfigurationsdatei übersteuert. maximum_spend_logs_retention_period löscht alte Spend-Logs, und turn_off_message_logging hält Nachrichten von externen Logging-Callbacks fern, während die Kosten weiter erfasst werden. Nutzungsdaten pro Engineer sind personenbezogene Daten. Stimmen Sie Zweck und Aufbewahrung vor dem Go-live mit den Verantwortlichen für Datenschutz und, falls vorhanden, mit dem Betriebsrat ab.

Nicht jede Anfrage läuft über das Gateway. Auch wenn ANTHROPIC_BASE_URL darauf zeigt, sendet Claude Code Telemetrie an Anthropic, und zwar ohne Ihre Gateway-Zugangsdaten. Die Domain-Sicherheitsprüfung von WebFetch ruft api.anthropic.com direkt auf. CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC=1 schaltet den nicht notwendigen Verkehr ab, deaktiviert aber auch automatische Updates. Planen Sie also einen anderen Update-Weg ein.

Budgets und Rate Limits pro Team, ohne Engineers auszubremsen

Setzen Sie die harte Grenze beim Team und halten Sie Limits pro Engineer großzügig. Agentensitzungen erzeugen Lastspitzen: Eine Aufgabe kann mehrere Subagenten parallel starten, die jeweils einen großen Prompt senden. Ein knappes Limit für Anfragen pro Minute auf einem Schlüssel stoppt deshalb echte Arbeit, lange bevor es das Budget schützt. Das ist unsere eigene Einschätzung aus dem Lastprofil. In LiteLLM gibt es dafür diese Stellschrauben:

• Pro Team: max_budget mit budget_duration für ein regelmäßiges Zurücksetzen und team_member_budget als Standard für jedes Mitglied
• Pro Schlüssel: max_budget, budget_duration, rpm_limit, tpm_limit und max_parallel_requests, dazu budget_limits für mehrere Zeitfenster auf einem Schlüssel, etwa eine Tages- und eine Monatsgrenze
• Pro Modell: model_max_budget, das die Dokumentation als Enterprise-Funktion kennzeichnet

Zwei Betriebsdetails entscheiden, ob die Grenzen halten. Budgets werden überhaupt nur mit einer Postgres-Datenbank durchgesetzt. Bei mehr als einem Worker oder Replikat empfiehlt LiteLLM Redis ausdrücklich: Ohne Redis werden Rate Limits pro Worker gezählt, Budgets können überschritten werden, und ein widerrufener Schlüssel bleibt auf Workern nutzbar, die den Widerruf nicht verarbeitet haben, bis ihr Cache-Eintrag abläuft. Legen Sie dann fest, was ein Engineer an der Grenze erlebt. Ein unerklärter Fehler mitten in einer Aufgabe kostet mehr Arbeitszeit, als die Token sparen. Warnen Sie das Team deshalb unterhalb der harten Grenze und machen Sie bekannt, wer ein Budget erhöhen kann.

Typische Fehlerbilder und wie Sie sie erkennen

Die meisten Probleme entstehen, wenn ein Gateway Anfrage oder Antwort unterwegs verändert. Die Protokollreferenz für Gateways und die Fehlertabelle von Anthropic beschreiben unter anderem diese Fälle:

Prüfen Sie Prompt Caching gesondert, denn ein defekter Cache kostet Geld, ohne einen Fehler auszulösen. Vergleichen Sie die Cache-Lese-Token pro Sitzung vor und nach Einführung des Gateways. Bei Claude-Code-Versionen vor v2.1.181 hat zudem ein Attributionsblock, der sich mit jeder Anfrage änderte, Caches ausgehebelt, die auf dem Anfrage-Body basieren. Die Protokollreferenz von Anthropic beschreibt für diesen Fall CLAUDE_CODE_ATTRIBUTION_HEADER=0.

Eine kurze Checkliste für die Einführung

Führen Sie das Gateway in dieser Reihenfolge ein und prüfen Sie jeden Schritt mit einer echten Agentensitzung statt mit einer einzelnen curl-Anfrage:

1. 1

   Umfang festlegen

   Halten Sie fest, welche Werkzeuge und Oberflächen das Gateway nutzen müssen. Die Claude-Code-CLI, die VS-Code-Erweiterung und die Desktop-App können das. Claude Code in Slack und Cloud-Sitzungen können es nicht, Copilot und Cursor nur teilweise. Schalten Sie nichts frei, was das Gateway nicht umgehen darf.

2. 2

   Gateway bereitstellen und absichern

   Fixieren Sie die Gateway-Version, betreiben Sie Postgres für Budgets und Redis für mehr als einen Worker und legen Sie die Log-Aufbewahrung vor der ersten Anfrage fest.

3. 3

   Modelle und Namen festlegen

   Veröffentlichen Sie die Positivliste mit den exakten Modell-IDs, die jedes Werkzeug sendet, und bilden Sie diese IDs im Gateway ab.

4. 4

   Eigene Zugangsdaten pro Engineer ausgeben

   Ordnen Sie jeden Schlüssel einem Team zu, setzen Sie Teambudgets und großzügige Limits pro Schlüssel und testen Sie den Widerruf gegen jedes Replikat.

5. 5

   Konfiguration zentral verteilen

   Verteilen Sie Basis-URL, Mechanismus für Zugangsdaten und allowedProviders über die verwalteten Einstellungen von Claude Code und setzen Sie die BYOK-Richtlinien von Copilot in den Enterprise- oder Organisationseinstellungen von GitHub.

6. 6

   Eine Abnahmesitzung durchführen

   Prüfen Sie Streaming, Tool-Aufrufe, Subagenten, Cache-Lesezugriffe und eine Budgetüberschreitung mit einem Testteam, bevor alle eingeladen werden, und lassen Sie jeden Engineer die Gateway-URL in /status bestätigen.

7. 7

   Bei jedem Upgrade erneut testen

   Claude Code ändert mit jedem Release, was es sendet. Wiederholen Sie die Abnahmesitzung deshalb vor jedem Gateway-Upgrade und vor der Freigabe einer neuen Client-Version.

Cloudsail richtet LiteLLM-Gateways für Engineering-Teams ein, betreibt sie und führt Claude Code darauf ein, einschließlich verwalteter Einstellungen, Teambudgets und der oben beschriebenen Abnahmesitzung.

LiteLLM-Gateway: Aufbau und BetriebLLM-KostenoptimierungClaude Code: Berechtigungen und Rollout