AI Gateway vs. LiteLLM: Breiter Open-Source-Proxy oder Governance- und FinOps-Gateway im eigenen Tenant?

Das Wichtigste in Kürze (Stand 26.09.2026):

• LiteLLM von BerriAI ist laut eigener Dokumentation ein selbst betriebener LLM-Proxy mit Admin-Oberfläche (Docker, Helm, Kubernetes, Terraform), dessen Repository-Kern laut LICENSE-Datei unter der MIT-Lizenz steht, während der Ordner enterprise/ einer separaten BerriAI Enterprise License unterliegt.
• Das innFactory AI Gateway wird in den Cloud-Tenant des Kunden ausgerollt und bündelt Kostenstellen mit Per-Member-Caps, Budgets in Euro und einen Companion, der die Agent-Zeit von Claude Code, Codex und OpenCode je Repository misst, auch für Abo-Nutzung.
• Laut Dokumentation erfasst LiteLLM den Verkehr, der den Proxy passiert, und ordnet ihn Keys, Teams und Nutzern zu; SSO ist seit Version 1.76.0 für bis zu 5 Nutzer kostenfrei und darüber hinaus an eine Enterprise-Lizenz gebunden, und ein lokaler Companion für Agent-Zeit je Repository ist in der LiteLLM-Dokumentation mit Stand 26.09.2026 nicht beschrieben – genau das leistet der Companion des innFactory AI Gateway.
• LiteLLM passt, wenn Sie einen per Code erweiterbaren Proxy für Modelle von vielen, auch kleinen Anbietern sowie SAML, SCIM oder einen externen Secret-Manager brauchen; das innFactory AI Gateway passt, wenn Kostenstellen in Euro, sieben Rollen ohne Lizenzschwelle und die Agent-Zeit von Coding-Agenten inklusive Abo-Sitzungen im Vordergrund stehen.

LiteLLM beschreibt sich selbst als „The AI Gateway for platform teams“ und als „Open-Source AI Gateway & LLM Proxy“ (litellm.ai). LiteLLM von BerriAI positioniert sich nach eigener Angabe als Open-Source-Option für einen LLM-Proxy über mehrere Modellanbieter hinweg. Wir sagen es ohne Umschweife: LiteLLM ist ein gutes Produkt. Die Provider-Abdeckung ist sehr breit, die Dokumentation umfangreich, das Ökosystem an Integrationen groß.

Dieser Vergleich ist deshalb keine Abrechnung, sondern eine Einordnung. Beide Produkte laufen in der Infrastruktur des Kunden, beide sprechen die OpenAI-, Anthropic- und Gemini-Dialekte, beide setzen Budgets durch. Die eigentliche Entscheidung: Brauchen Sie einen möglichst breiten, per Code erweiterbaren Proxy mit einer Enterprise-Stufe für Identität und Governance — oder eine Infrastrukturkomponente, die Kostenstellen, Rollen, Guardrails und die Arbeitszeit von Coding-Agenten von Anfang an als Kernfunktion behandelt? Alle Aussagen über LiteLLM beziehen sich auf die öffentliche Dokumentation mit Stand 26. September 2026.

Was LiteLLM ist

LiteLLM von BerriAI ist ein LLM-Proxy mit Admin-Oberfläche, der Anfragen im OpenAI-Format oder im nativen Format an eine große Zahl von Modellanbietern weiterleitet. Der Kern des Repositories steht laut LICENSE-Datei unter der MIT-Lizenz. Dieselbe Datei stellt klar, dass alle Inhalte im Ordner enterprise/ einer separaten BerriAI Enterprise License unterliegen. Laut deren Text sind Kopieren und Verändern für Entwicklung und Test ohne Subscription erlaubt; der produktive Einsatz der Enterprise-Funktionen setzt eine gültige Enterprise-Lizenz für die entsprechende Anzahl an Nutzern voraus. Der Anbieter stellt die beiden Stufen als „Free“ und „Enterprise“ auf seiner Features-Seite gegenüber.

Technisch ist der Proxy laut Dokumentation heute Python-basiert; als produktive Datenbank wird PostgreSQL genannt. Laut LiteLLM-Dokumentation befindet sich der Proxy in einer schrittweisen Migration von Python zu einem Rust-Kern; der Anbieter veröffentlicht dazu einen eigenen Fortschrittsbericht. Das innFactory AI Gateway ist ebenfalls in Rust geschrieben — eine Architekturentscheidung, kein Alleinstellungsmerkmal.

Betriebsmodell: SaaS, Self-Hosting oder Infrastruktur im eigenen Tenant

Hier sind sich beide Produkte nah. LiteLLM wird laut Deployment-Dokumentation selbst betrieben: Docker-Images unter ghcr.io/berriai, zwei Helm-Chart-Varianten, Kubernetes-Manifeste, Terraform-Module für AWS ECS Fargate und Google Cloud Run sowie Deploy-Buttons für Render und Railway. Zum Datenfluss schreibt der Anbieter: „No data or telemetry is stored on LiteLLM Servers when you self-host“. Die Enterprise-Seite nennt „Self-hosted, in your infra“ und „Air-gapped deployment“.

Das innFactory AI Gateway wird ebenfalls in den Cloud-Tenant des Kunden ausgerollt — Referenzpfad Azure Container Apps oder AKS, alternativ STACKIT oder ein beliebiges Kubernetes. Das Backend ist ein einzelnes Binary im Container plus ein Dashboard-Image; als Datenbank dienen PostgreSQL (etwa STACKIT PostgreSQL Flex), MongoDB oder Azure Cosmos DB. innFactory hostet das Gateway nicht als SaaS; die innFactory GmbH unterstützt als Microsoft CSP beim Rollout und kann die Azure-Subscription stellen. Der Datenpfad bleibt in beiden Fällen im Tenant. Helm-Charts liefert LiteLLM mit, das innFactory AI Gateway derzeit nicht.

Identität, SSO und Rollen

LiteLLM dokumentiert SSO für Okta, Google, Microsoft Entra ID und einen generischen OAuth-Client, dazu SAML 2.0 und SCIM auf eigenen Seiten. Die Bedingungen sind klar benannt: „SSO requires a LiteLLM Enterprise license“ und „From v1.76.0, SSO is free for up to 5 users. Beyond that, an enterprise license is required.“ Für JWT-basierte Authentifizierung von API-Anfragen (Keycloak, Google Cloud OIDC, Azure AD, generische OIDC-Issuer) gilt laut Dokumentation: „JWT-based Auth requires a LiteLLM Enterprise license.“ Die dokumentierten Rollen heißen proxy_admin, proxy_admin_viewer, internal_user und internal_user_viewer, auf Team-Ebene admin und user.

Das innFactory AI Gateway bindet Microsoft Entra ID oder generisches OIDC an (Keycloak dokumentiert, AWS-Cognito-Claims werden verarbeitet); OIDC/JWT auf dem Proxy-Pfad ist optional zuschaltbar, für LibreChat und CompanyGPT gibt es Trusted-Header-Auth. Es gibt sieben Rollen: Owner, Admin, Auditor (liest alles), Finance (Kosten und Margen), Security (Guardrails, Audit-Log, Ablehnungen), Member und Guest — Gäste werden bei Anmeldungen außerhalb der erlaubten E-Mail-Domains automatisch zugewiesen und erhalten keinen Proxy-Zugriff. IdP-Gruppen lassen sich auf sechs Rollen abbilden, Kostenstellen haben eigene Administratoren. All das ist in jeder Lizenzstufe enthalten. SAML und SCIM sind im innFactory AI Gateway derzeit nicht enthalten; wer sie zwingend braucht, findet sie bei LiteLLM dokumentiert.

Kostenkontrolle und AI-FinOps

LiteLLM setzt Budgets laut Dokumentation global sowie je Team, Team-Mitglied, Key, Projekt („[Beta] Project Management“), Tag, Model Access Group und Customer. Budgets sind harte Stopps — bei Überschreitung antwortet der Proxy mit einem Fehler („Budget has been exceeded!“); ergänzend gibt es „Team Soft Budget Alerts“. Zeitfenster werden über budget_duration in Sekunden bis Tagen definiert, etwa 30d. Die Zurechnung erfolgt nach Endnutzer, Team, Key, freien Tags, Modell und Provider; der Header x-litellm-response-cost zeigt die Kosten je Anfrage. Ausgaben liefern JSON-Endpunkte wie /global/spend/report; ein CSV-Export ist auf der Cost-Tracking-Seite nicht dokumentiert. Als Währung ist ausschließlich USD dokumentiert.

Das innFactory AI Gateway ist hier auf Controlling-Prozesse zugeschnitten. Vier unabhängige Gates — Organisation (monatlich), Kostenstelle (monatlich plus Tages- und Wochenfenster, im Pool- oder Pro-Nutzer-Modus mit Obergrenzen je Mitglied), Nutzer und API-Key — antworten bei Erschöpfung mit HTTP 402 und Fehlercode E4006; optional greift statt der Ablehnung ein Budget-Fallback-Modell, Obergrenzen je Mitglied bleiben immer harte Stopps. Dazu kommen Caps je Modell, TPM- und RPM-Limits (429, E4007), Warnungen bei 80 und 90 Prozent und das Ereignis budget_exceeded, das einen Flow oder Webhook auslösen kann.

Kosten werden nach Nutzer, Key, Team, Kostenstelle, Modell, Provider, Tool, Repository, Herkunft und Abrechnungsquelle (Gateway oder Abo) zugeordnet und in Euro zum EZB-Tageskurs angezeigt; Listenpreise kommen von ai-prices.eu und werden erst nach Prüfung durch einen Admin übernommen. Jede gepufferte Antwort trägt den Header x-aigateway-response-cost; Insights bieten Aufschlüsselung und Zeitreihen je Dimension sowie einen CSV-Export inklusive Agent- und LLM-Zeit.

Coding-Agenten, Abos und Agent-Zeit

Zuerst die Anerkennung: LiteLLM dokumentiert eine lange Reihe von Client-Anleitungen — Claude Code (inklusive einer Anleitung, um den Verkehr eines Claude-Code-Max-Abos durch den Proxy zu leiten), Claude Desktop (Cowork), OpenCode, OpenClaw, Cursor, GitHub Copilot in VS Code, Gemini CLI, Qwen Code CLI, OpenAI Codex CLI, Retool Assist und Open WebUI; Roo Code wird als weiteres Tool für die Nutzungserfassung genannt.

Der Unterschied liegt in dem, was gemessen wird. Alles, was LiteLLM erfasst, ist Verkehr, der den Proxy passiert; er wird laut Dokumentation Keys, Teams, Nutzern und Customers zugerechnet, ergänzt um das Beta-Objekt „Project“. Ein lokaler Companion, der die Arbeitszeit eines Agenten je Repository misst und dabei auch Abo-Sitzungen erfasst, die das Gateway nie berühren, ist in der LiteLLM-Dokumentation mit Stand 26.09.2026 nicht beschrieben.

Genau das ist die Aufgabe des Companions aigw. Der kleine Hintergrunddienst auf dem Entwicklerrechner (Linux, macOS, Windows) liest die lokalen Sitzungsprotokolle von Claude Code, Codex und OpenCode und meldet Agent-Zeit (aktive Arbeitszeit des Agenten, unbeaufsichtigte Läufe zählen vollständig), LLM-Zeit und Token-Klassen — je Repository, Nutzer, Tool und Kostenstelle. Er erkennt, ob eine Sitzung über das Gateway oder über das Abo des Tools lief (Claude Max, ChatGPT- oder Codex-Plan); Abo-Nutzung wird als „Shadow Tokens“ zum Listenpreis bewertet, aber nie abgerechnet, budgetiert oder limitiert und immer getrennt ausgewiesen. Repositories werden über Regeln nach Repository, Owner oder Host einer Kostenstelle zugeordnet.

Der Rollout läuft per Device-Code-Login oder mit Enrollment-Tokens für unbeaufsichtigte Verteilung (Intune-Win32-App, macOS-Shell-Script-Policy, Linux-Script). Mit aigw run claude|codex|opencode startet ein Tool mit kurzlebigem Proxy-Token, ohne die Tool-Konfiguration anzufassen. Für den Proxy-Modus gibt es sechs Setup-Generatoren: Claude Code, Codex, OpenCode, Cowork, VS Code Continue und VS Code Copilot. Fair ist auch der Hinweis: Cursor, Windsurf, Cline, Copilot CLI oder Gemini CLI deckt der Companion nicht ab.

Provider, Dialekte und Modelle

Hier ist LiteLLM schlicht breiter. Der Anbieter nennt auf der Startseite „140+ LLM providers“ und auf seinem Modellkatalog „2,600+ models across 140+ providers“; die Zahlen unterscheiden sich je nach Seite und sind als ungefähre Anbieterangaben zu lesen. Dokumentiert sind auch europäische Anbieter wie Mistral AI, Aleph Alpha, Nscale und OVHcloud AI Endpoints. STACKIT und IONOS sind in der Provider-Liste der LiteLLM-Dokumentation nicht als eigene Provider dokumentiert. Als Dialekte dokumentiert LiteLLM OpenAI-kompatible Endpunkte, Anthropic und Gemini nativ, die Responses API, Realtime, Audio, Bildgenerierung und Embeddings.

Das innFactory AI Gateway unterstützt 13 Provider-Typen: OpenAI, Azure OpenAI, Azure AI Foundry, Anthropic (direkt oder über Vertex), Gemini (AI Studio oder Vertex inklusive EU-Endpunkt), Mistral, AWS Bedrock (inklusive Bedrock Mantle), STACKIT, IONOS, Ollama, LM Studio, ElevenLabs und beliebige OpenAI-kompatible Endpunkte. Eingehend werden die Dialekte OpenAI, Anthropic und Gemini gesprochen, dazu Realtime-WebSocket für OpenAI, Azure OpenAI, ElevenLabs und Gemini Live sowie Audio, Embeddings, Bilder, OCR und Batches. Wer einen Nischen-Provider braucht, ist bei LiteLLM besser aufgehoben; wer die souveränen deutschen Anbieter als Erstklasse-Provider will, findet sie im innFactory AI Gateway.

Governance: Guardrails, MCP, Routing und Flow Builder

LiteLLM setzt bei Guardrails auf ein breites Netz benannter Anbieter — Presidio, Aporia, Lakera, AWS Bedrock Guardrails, Guardrails AI, Azure Content Safety und TypeSafe — ergänzt um einen eingebauten Content Filter, einen Tool Permission Guardrail, eine generische Guardrail-API und die Beta-Funktion „Guardrail Policies“. Ausführungsmodi sind pre_call, post_call, during_call und logging_only für Shadow-Scanning. Laut Features-Seite liegen „Set Guardrails per request“, „Default-on Guardrails“ und „Set Guardrails by Key/Team“ in der Enterprise-Spalte. Für MCP dokumentiert LiteLLM ein zentrales MCP-Gateway mit Namespacing je Server, OAuth-2.0-Discovery mit PKCE, API-Key, Basic Auth, AWS SigV4 und weitergereichten Headern. Beim Routing stehen Simple-Shuffle, latenz-, nutzungs- und kostenbasierte Strategien, Least-Busy und eigene Strategien per Klasse zur Verfügung, dazu Fallbacks, Session-Affinität und Cooldowns; Caching gibt es exakt und semantisch. Ein visueller Flow Builder mit Knoten ist in den geprüften Seiten nicht dokumentiert; dokumentiert ist ein Model Compare Playground für bis zu drei Modelle.

Das innFactory AI Gateway bringt neun Guardrail-Regeltypen als eigene Engine mit: Secret-Erkennung, PII-Blockieren oder -Schwärzen mit Rückauflösung, verbotene Begriffe, Token- und Kostenlimit, Azure Content Safety, Prompt-Injection, verbotene Themen, Groundedness und externer Webhook — mit Shadow-Modus, Schwärzung mitten im Stream, DSGVO-Preset und /check-Trockenlauf, in jeder Lizenz. Der MCP-Proxy stellt Streamable-HTTP-Server unter /mcp/servers/{name} bereit, mit acht Upstream-Auth-Modi (unter anderem OAuth Client Credentials, Per-User-OAuth-PKCE, Entra On-Behalf-Of, AWS SigV4), benannten Toolsets, semantischer Tool-Suche und Guardrails auf Tool-Argumenten und -Ergebnissen. Routing umfasst einen Auto-Router nach Prompt-Komplexität, Aliase, Provider-übergreifende Fallbacks, Deployment-Gruppen und einen optionalen Cache.

Der Flow Builder ist der Teil, den LiteLLM in dieser Form nicht dokumentiert: ein visueller Graph mit neun Strategien (unter anderem failover, least_cost, cost_cascade, strategy_llm), Guardrail-Knoten mit den Zweigen pass, block und fail sowie Ereignis-Triggern wie budget_exceeded, die Webhooks auslösen. Ein Flow ist wie ein Modell aufrufbar und belastet dieselben Budgets.

Was LiteLLM besser kann

• Provider-Breite: Nach eigener Angabe über 140 Provider und ein öffentlicher, laufend gepflegter Modellkatalog — deutlich mehr als 13 Provider-Typen.
• Erweiterbarkeit per Code: Eigene Guardrails über apply_guardrail, eigene Routing-Strategien über CustomRoutingStrategyBase, eine generische Guardrail-API.
• Secret-Manager: AWS KMS, Azure Key Vault, Google KMS, HashiCorp Vault und CyberArk laut Enterprise-Dokumentation. Das innFactory AI Gateway verschlüsselt Provider-Credentials AES-256-GCM im eigenen Store; externe Secret-Manager sind nicht Teil des aktuellen Umfangs.
• Guardrail-Anbieter: Presidio, Aporia, Lakera, Bedrock Guardrails, Guardrails AI, Azure Content Safety und TypeSafe als benannte Integrationen.
• MCP-Authentifizierung: OAuth-2.0-Discovery mit PKCE, Basic Auth und weitere Modi sind in der MCP-Dokumentation breit beschrieben.
• Client-Anleitungen: Über zehn dokumentierte Integrationen von Claude Code bis Open WebUI.
• Deployment-Artefakte: Zwei Helm-Chart-Varianten, Terraform-Module für AWS und GCP im Terraform Registry, Render- und Railway-Buttons.
• SAML und SCIM: Auf eigenen Dokumentationsseiten beschrieben.
• Transparenz: Öffentlicher Engineering-Blog, veröffentlichter Fortschritt der Rust-Migration, dokumentierte Support-SLAs und Versionsrichtlinie.

Wann LiteLLM die richtige Wahl ist

• Ihre Plattform muss Modelle von vielen, auch kleinen Anbietern erreichen.
• Ihr Team möchte Guardrails, Routing und Hooks selbst in Python erweitern.
• Sie brauchen SAML, SCIM oder einen externen Secret-Manager wie HashiCorp Vault.
• Sie nutzen viele verschiedene Coding-Tools und brauchen für jedes eine dokumentierte Proxy-Anleitung.
• Sie wollen Helm-Charts oder fertige Terraform-Module für ECS und Cloud Run.

Wann das innFactory AI Gateway die richtige Wahl ist

• Die Fachabteilung will Kostenstellen mit Pool- oder Pro-Nutzer-Budgets, Tages- und Wochenfenstern und Auswertungen in Euro.
• SSO, sieben Rollen und Guardrails sollen ohne Lizenzschwelle in jeder Stufe enthalten sein.
• Sie wollen wissen, wie viel Agent-Zeit Claude Code, Codex und OpenCode je Repository leisten — inklusive Abo-Sitzungen, die nie über das Gateway laufen.
• STACKIT, IONOS oder Azure AI Foundry sollen Erstklasse-Provider sein.
• Routing und Guardrails sollen als visueller Flow gepflegt werden, nicht als Code.
• Sie nutzen CompanyGPT oder planen es und wollen Identität, Kostenstellen und Guardrails nur einmal aufsetzen.

Vergleich auf einen Blick

Fazit

LiteLLM ist ein gutes Produkt. Wer einen breit erweiterbaren Open-Source-Proxy mit sehr vielen Providern sucht, hat damit eine belastbare Grundlage — vorausgesetzt, das Team plant die Enterprise-Lizenz für SSO jenseits von fünf Nutzern, JWT-Auth und Teile der Guardrail-Steuerung von Anfang an ein.

Das innFactory AI Gateway setzt den Schwerpunkt anders: eine Infrastrukturkomponente im eigenen Tenant, in der Kostenstellen in Euro, sieben Rollen, eine eigene Guardrail-Engine, ein MCP-Proxy und der Flow Builder in jeder Lizenz stecken — und die mit dem Companion eine Frage beantwortet, die ein reiner Proxy nicht beantworten kann: Wie viel Arbeitszeit leisten unsere Coding-Agenten je Repository, auch wenn sie über ein Abo laufen?

Nativ in CompanyGPT integriert, Stack wiederverwendbar

Das innFactory AI Gateway ist nativ in CompanyGPT integriert: Dieselben Budgets, Kostenstellen und Guardrails gelten für Chat, Agenten und Add-ons. Identität (Entra ID oder Keycloak), Kostenstellen, Guardrails und die MCP-Registry sind ein Stack, der in CompanyGPT, im Gateway und in allen Anwendungen, die über das Gateway laufen, wiederverwendet wird. Das Gateway lässt sich ebenso eigenständig betreiben, etwa als Basis für interne Tools und Coding-Agenten. Weitere Gegenüberstellungen finden Sie unter alle Vergleiche, die Produktseite unter AI Gateway.

Quellen

Abgerufen am 26. September 2026:

• LiteLLM Startseite — https://www.litellm.ai/
• LiteLLM Enterprise — https://www.litellm.ai/enterprise
• LiteLLM Features: Free vs Enterprise — https://www.litellm.ai/features
• LiteLLM Repository — https://github.com/BerriAI/litellm
• LiteLLM LICENSE (MIT, Hinweis auf enterprise/) — https://raw.githubusercontent.com/BerriAI/litellm/main/LICENSE
• BerriAI Enterprise License — https://raw.githubusercontent.com/BerriAI/litellm/main/enterprise/LICENSE.md
• Deployment-Dokumentation — https://docs.litellm.ai/docs/proxy/deploy
• Production-Dokumentation — https://docs.litellm.ai/docs/proxy/prod
• Data Security — https://docs.litellm.ai/docs/data_security
• Rust-Migration — https://docs.litellm.ai/rust-migration
• Admin UI SSO — https://docs.litellm.ai/docs/proxy/admin_ui_sso
• JWT-based Auth — https://docs.litellm.ai/docs/proxy/token_auth
• Users und Rollen — https://docs.litellm.ai/docs/proxy/users
• Team Budgets — https://docs.litellm.ai/docs/proxy/team_budgets
• Customers — https://docs.litellm.ai/docs/proxy/customers
• Cost Tracking — https://docs.litellm.ai/docs/proxy/cost_tracking
• Enterprise-Funktionen — https://docs.litellm.ai/docs/proxy/enterprise
• AI Tools — https://docs.litellm.ai/docs/ai_tools
• Claude Code Max Subscription — https://docs.litellm.ai/docs/tutorials/claude_code_max_subscription
• OpenAI Codex CLI — https://docs.litellm.ai/docs/tutorials/openai_codex
• Providers — https://docs.litellm.ai/docs/providers
• Modellkatalog — https://models.litellm.ai/
• Guardrails Quick Start — https://docs.litellm.ai/docs/proxy/guardrails/quick_start
• Tool Permission Guardrail — https://docs.litellm.ai/docs/proxy/guardrails/tool_permission
• Guardrail Policies — https://docs.litellm.ai/docs/proxy/guardrails/guardrail_policies
• Realtime Guardrails — https://docs.litellm.ai/docs/proxy/guardrails/realtime_guardrails
• LiteLLM Docs: Custom Guardrail — https://docs.litellm.ai/docs/proxy/guardrails/custom_guardrail
• LiteLLM Docs: Bedrock Guardrails — https://docs.litellm.ai/docs/proxy/guardrails/bedrock
• LiteLLM Docs: TypeSafe Guardrail — https://docs.litellm.ai/docs/proxy/guardrails/typesafe
• MCP — https://docs.litellm.ai/docs/mcp
• Routing — https://docs.litellm.ai/docs/routing
• Caching — https://docs.litellm.ai/docs/proxy/caching
• Model Compare UI — https://docs.litellm.ai/docs/proxy/model_compare_ui

Hinweis zu den Angaben: Alle Aussagen über Produkte anderer Anbieter beruhen auf deren öffentlich zugänglicher Dokumentation zum angegebenen Stand. Anbieter entwickeln ihre Produkte, Funktionen und Konditionen laufend weiter — maßgeblich sind stets die aktuellen Angaben des jeweiligen Anbieters. Sollte Ihnen eine Angabe veraltet oder unzutreffend erscheinen, schreiben Sie uns kurz an info@innfactory.ai; wir prüfen und korrigieren zeitnah. Dieser Vergleich ersetzt keine Rechts- oder Datenschutzberatung im Einzelfall.

Weiterführende Artikel

• AI Gateway – Proxy-Modus, Companion und Lizenzen im Überblick
• CompanyGPT – die Plattform, in die das Gateway nativ integriert ist
• Claude Code als AI Harness – Bausteine, Modelle und Enterprise-Einsatz
• AI Harness erklärt – Grundlagen zu KI-Agenten und Harnesses
• Alle Vergleiche zum AI Gateway – LiteLLM, OpenRouter, Portkey, Cloudflare, Kong, Bifrost, TrueFoundry, Helicone, Vercel
• AI Gateway vs. Bifrost (Maxim AI)
• AI Gateway vs. Helicone
• AI Gateway vs. Kong AI Gateway