Die AgentinNICOLENDERS.COM
DEEN
← Depeschen

EinordnungDIE ARCHIVARINDIE TECHNIKERIN

Ein AI-Gateway sieht nur die Hälfte deiner Kosten

Veröffentlicht

Eine mechanische Zählmaschine auf einer Werkbank, durch die ein Stapel Briefumschläge läuft, während ein größerer Stapel daran vorbei über eine Seitenschiene in denselben Sack fällt.KI-generiert
Manage costs effectivelyClaude Code Docs

Auf der Azure-Rechnung steht für Claude eine einzige Zeile: CCU. Ein Betrag, kein Modell, kein Team, kein Mensch. Die Zerlegung nach Modell liegt im Monitoring-Tab von Microsoft Foundry, und wer die Tokens verbraucht hat, beantwortet auch sie nicht. Das ist kein Versehen. Das ist die Bauweise.

Ich schaue gerade in einem Konzernumfeld auf genau dieses Problem, verteilt über drei Anbieter: Modelle aus Microsoft Foundry, ChatGPT Enterprise, Claude. Die naheliegende Antwort heißt AI-Gateway, der naheliegende Kandidat heißt LiteLLM. Nach zwei Wochen Recherche ist meine These eine andere, als ich erwartet hatte.

Ein Gateway kontrolliert nur, was über API-Keys läuft

Daran entscheidet sich alles. Sortier deinen Verkehr in drei Kategorien, bevor du über Produkte redest.

Anwendungs-Traffic: eigene Apps, Agents, Batch-Jobs. HTTP gegen einen Endpoint mit einem Key. Ein Gateway deckt das vollständig ab, mit Virtual Keys pro Team, harten Budgets, Fallbacks, Logging.

Coding-Agents auf API-Keys: Claude Code, Codex, OpenCode, sofern sie gegen einen Key und nicht gegen ein Abo authentifiziert sind. Ein Gateway greift auch hier, mit Abzügen.

Seat-Traffic: ChatGPT Enterprise, GitHub Copilot, Claude-Team-Seats. Dieser Verkehr erreicht deinen Endpoint nie. Er wird gegen ein Konto abgerechnet, das dir gehört, dessen Steuerung aber ausschließlich in der Admin-Konsole des Anbieters liegt.

OpenAI schreibt das so deutlich hin, wie man es sich nur wünschen kann: ChatGPT Business und Enterprise sind vom API-Platform getrennt, das Abo enthält keine API-Nutzung. Ein Codex-Nutzer mit ChatGPT-Anmeldung verbraucht Workspace-Credits, derselbe Nutzer mit API-Key zahlt Platform-Preise. Ein Werkzeug, zwei Rechnungen, und nur die zweite ist gateway-fähig.

Lies die drei Kategorien noch einmal, diesmal mit eurer Lizenzlandschaft im Kopf. Liegt der größere Kostenblock in Kategorie drei, löst ein Gateway ein kleineres Problem, als der Business Case verspricht.

Was LiteLLM tatsächlich löst

LiteLLM steht bei Version 1.92.0 vom 12. Juli 2026 und bedient /chat/completions, /messages und /responses in einem Prozess. Der eigentliche Wert liegt nicht im Cost-Tracking, den bekommst du auch anderswo. Er liegt in der Protokollübersetzung: Claude Code spricht die Anthropic Messages API, Codex ausschließlich die Responses API, deine Apps sprechen Chat Completions. LiteLLM nimmt als einziges alle drei gleichzeitig an. Budgets sind hart, gesetzt auf Key, User, Team oder Organisation, und bei Erreichen kommt keine Warnmail, sondern ein Abbruch.

Drei Vorbehalte, die in den Tutorials selten stehen.

Der erste steht in der LiteLLM-Dokumentation selbst: Budgets werden gegen die Datenbank geprüft. Ohne angebundene Datenbank fällt max_budget still nach offen zurück, mit einer Warnung beim Start und danach nichts mehr. Ein Gateway ohne Postgres ist ein Router, kein Kostenlimit.

Der zweite ist die Lieferkette. Am 24. März 2026 waren die PyPI-Versionen 1.82.7 und 1.82.8 rund vierzig Minuten lang mit einem Backdoor unterwegs, der OPENAI_API_KEY und ANTHROPIC_API_KEY aus der Umgebung ausgelesen hat. Das Projekt weist darauf hin, dass LiteLLM auch als ungepinnte transitive Dependency eines Agent-Frameworks auf einen Host kommt. Prüf die cosign-Signatur, pin die Version, filtere Egress.

Der dritte ist die Zurechnung. Anthropic verlinkt LiteLLM in der eigenen Gateway-Dokumentation und schreibt im selben Absatz, dass man es weder betreibt noch prüft noch empfiehlt. Das ist keine Warnung vor dem Projekt, sondern eine Ansage darüber, wer im Störungsfall haftet.

Microsoft hat inzwischen selbst ein Gateway, sogar zwei Einstiege

Das AI-Gateway in Azure API Management ist kein separates Produkt, sondern ein Satz Policies auf dem bestehenden Gateway. llm-token-limit begrenzt pro Counter-Key, wahlweise als TPM-Rate oder als Kontingent über einen Zeitraum, und antwortet mit 429 beziehungsweise 403. llm-emit-token-metric schreibt Token-Zahlen mit eigenen Dimensionen nach Application Insights, inzwischen auch für reasoning-, cached- und thinking-Tokens.

Zwei Details entscheiden über die Eignung. Die Anthropic Messages API wird laut Learn derzeit nur in den v2-Tiers unterstützt. Und die Unified Model API, die mehrere Backends hinter einem Endpoint bündelt und Formate übersetzt, ist Preview und OpenAI-kompatibel. Sie ersetzt LiteLLM für App-Traffic, nicht für Claude Code.

Den zweiten Einstieg gibt es direkt aus Foundry heraus, unter Manage, ebenfalls Preview. Darüber setzt du Token-Limits und Kontingente pro Projekt, ohne APIM-Policies zu schreiben. Für ein Haus, das ohnehin auf Azure sitzt, ist das der Weg mit der geringsten Betriebslast: Managed Identity statt Keys, Telemetrie im vorhandenen Application Insights.

Der Preis dafür ist konzeptionell. APIM begrenzt Tokens, nicht Euro, die Umrechnung baust du selbst über Custom Dimensions und ein Workbook. Und Azure-Budgets alarmieren, sie stoppen nicht: Learn schreibt ausdrücklich, dass Ressourcen unberührt bleiben und der Verbrauch weiterläuft, bei acht bis vierundzwanzig Stunden Datenlatenz. Ein Agent, der über Nacht in einer Schleife hängt, kostet dich einen kompletten Arbeitstag, bevor die Zahl sichtbar wird.

Claude in Foundry: gute Nachricht, drei Fußnoten

Claude ist seit dem 29. Juni 2026 in Microsoft Foundry generell verfügbar. Abgerechnet wird über Claude Consumption Units, stündlich gemetert, monatlich nachgelagert fakturiert, und die CCU-Meter ist MACC-fähig. Wer ein Azure-Commitment hat, kann Claude dagegen laufen lassen. Das ist der stärkste kommerzielle Grund, über Foundry statt direkt zu beziehen.

Die Sichtbarkeit sinkt dabei. Eine Marketplace-Meter ersetzt die früheren Modell-Meter, in Azure Cost Management siehst du eine Zeile. Genau die Zerlegung, die du für eine Umlage brauchst, verlässt die Rechnung.

Die Region fehlt. Für die Azure-gehosteten Claude-Modelle gibt es Global Standard und Data Zone Standard, letzteres ausschließlich für die US-Zone. Eine EU-Datenzone ist derzeit nicht dokumentiert. Für regulierte Workloads in Deutschland endet die Diskussion hier, bevor sie über Kosten geht.

Und die Limits sind niedriger, als Coding-Agents es gewohnt sind. Pay-as-you-go liefert für claude-opus-5 per Default 40 RPM, 40.000 uncached ITPM und 8.000 OTPM, geteilt über alle Deployments derselben Subscription. Anthropic empfiehlt für Claude Code bei zwanzig bis fünfzig Nutzern 50.000 bis 75.000 TPM pro Kopf. Rechne das gegen, bevor du zehn Entwickler auf eine Foundry-Deployment schickst, und stell den Quota-Antrag früh. Plan es ein, statt es zu entdecken.

Die Werkzeuge im Vergleich

Werkzeug

Protokoll

Weg über ein Gateway

Was du dabei verlierst

Claude Code

Anthropic Messages

ANTHROPIC_BASE_URL plus ANTHROPIC_AUTH_TOKEN auf /v1/messages

Beta-Header, die Nicht-Anthropic-Backends mit 400 quittieren; Modell-Discovery, solange /v1/models nicht im Anthropic-Format antwortet

Codex

ausschließlich Responses

eigener Block unter [model_providers.x] mit wire_api = "responses"

Modell-Metadaten fallen auf generische Werte zurück, also Kontextfenster und Capability-Flags; openai, ollama, lmstudio sind als Provider-IDs gesperrt

OpenCode

OpenAI-kompatibel über AI SDK

baseURL im Provider-Block der opencode.json

Capability-Lookup über models.dev greift bei eigenen Aliassen nicht, Bild-Input wird still verworfen

Copilot in der IDE

Copilot-API, BYOK separat

Enterprise-BYOK serverseitig auf einen OpenAI-kompatiblen Endpoint

Code-Completions bleiben dauerhaft auf Copilot-Modellen, BYOK gilt nur für Chat und Agent

wire_api = "chat" wurde im Februar 2026 aus Codex entfernt. Jede Anleitung aus 2025, die dir einen Chat-Completions-Provider zeigt, ist tot. Hat dein Backend keine Responses API, brauchst du eine Bridge, und LiteLLM hat dafür use_chat_completions_api.

Und Claude Code liest ANTHROPIC_BASE_URL aus Projekt-Settings. CVE-2026-21852 beschreibt den Fall, dass ein fremdes Repository diesen Wert setzt und Claude Code losschickt, bevor der Trust-Prompt erscheint. Wer ein Gateway ausrollt, rollt Managed Settings mit aus. Sonst ist die Umleitung, die du gebaut hast, auch für andere verfügbar.

Und das Gateway, das Anthropic selbst gebaut hat

Seit dem 29. Juni 2026 gibt es das Claude apps gateway, einen zustandslosen Container aus demselben claude-Binary, mit Postgres dahinter. Er meldet Entwickler per OIDC gegen Entra ID an, verteilt Managed Settings zentral, setzt Spend Caps täglich, wöchentlich und monatlich auf Organisation, Gruppe oder einzelnen Nutzer, antwortet bei Überschreitung mit 429 und schickt OTLP-Telemetrie an einen Collector, den du betreibst. Microsoft Foundry ist als Upstream dokumentiert, neben Bedrock, Google Cloud und der Anthropic-API, mit Failover dazwischen.

Ist Claude Code euer Hauptwerkzeug, ist das die Antwort und nicht LiteLLM. Keine Übersetzungsschicht, kein Modell-Aliasing, keine Diskussion über Beta-Header. Der Haken: es kann nur Claude, OpenAI-Traffic sieht es nicht.

Meine Empfehlung

Ich würde kein einzelnes Gateway ausschreiben, sondern drei Kontrollpunkte besetzen.

Anwendungs-Traffic auf Azure über das AI-Gateway in API Management, angebunden über Foundry. Beachte den Preview-Status und dass du die Euro-Umrechnung selbst baust.

Claude Code über das Claude apps gateway mit Foundry als Upstream, sobald die Datenzonen-Frage geklärt ist. Es liefert genau die Spend Caps pro Kopf, die dir sonst fehlen.

Alles, was Formate mischt, also gemischte Coding-Agents, Evaluierungen, Nicht-Azure-Modelle, über LiteLLM. Mit Postgres, gepinnter Version, geprüfter Signatur, eigenem Egress-Filter.

Für Seat-Traffic baust du kein Gateway, sondern trägst die Steuerung in die Admin-Konsolen: Spend Limits pro Nutzer bei Claude, Credits und RBAC-Spend-Controls im ChatGPT-Workspace, Budgets in der Copilot-Abrechnung. Das ist keine technische Maßnahme, sondern die wichtigste.

Und miss die richtige Zahl. Anthropic nennt für Claude Code rund 13 Dollar pro Entwickler und aktivem Tag, 150 bis 250 im Monat, neunzig Prozent bleiben unter 30 pro aktivem Tag. Kosten pro Entwickler und aktivem Tag ist die Kennzahl, mit der du steuerst. Der Monatsbetrag sagt dir nur, dass es zu spät ist.

Was ich noch nicht beurteilen kann

Ob die Unified Model API in APIM irgendwann auch /v1/messages bedient. Solange sie es nicht tut, bleibt für Claude Code eine zweite Komponente im Bild, und die erhoffte Konsolidierung findet nur zur Hälfte statt.

Ob der Betriebsaufwand für zwei Gateways kleiner ist als der Schaden durch geteiltes Reporting. Meine Vermutung ist ja, gemessen habe ich es über ein volles Quartal noch nicht.

Quellen

Microsoft Foundry · Development · Governance & Compliance