Startseite / Artikel

Claude, GPT und Gemini über openAI-kompatible Endpunkte aufrufen

Sehen Sie, welche Funktionen die für Anthropic und Gemini sowie OpenAI kompatiblen Schichten unterstützen, an welchen Stellen sie Features stillschweigend weglassen und wann es sinnvoll ist, alle drei über ein einziges Gateway zu leiten.

Verlag: REACTAPP.TOP8 Min. Lesezeit1812 Wörter

Quellen: Claude, GPT, and Gemini via One OpenAI-Compatible API

Sowohl Anthropic als auch Google bieten nun OpenAI-kompatible Endpunkte an, sodass es ausreicht, einige Zeilen im vorhandenen OpenAI SDK-Code zu ändern, anstatt eine Integration neu zu schreiben, um auf Claude oder Gemini zuzugreifen. Der schwierige Teil liegt nicht bei der ersten Anfrage, sondern darin, zu wissen, welche Funktionen jede Kompatibilitätsschicht stillschweigend ignoriert und was es kostet, mehrere davon nebeneinander zu betreiben. Unten finden Sie die genaue Client-Einrichtung für jeden Anbieter, die dokumentierten Lücken, die für Produktionsagenten relevant sind, sowie die Abwägungen beim Zusammenfassen aller drei Dienste unter einer einzigen Basis-URL und einem Schlüssel.

Was „OpenAI-kompatibel“ tatsächlich verspricht

messages-Array, dieselben Streaming-Flags sowie dasselbe Schema zur Aufrufung von Tools. Da dieses Format bereits vor Jahren zum de facto Standard wurde, bieten die meisten Modellanbieter heute eine Version davon an, sodass Teams ein anderes Modell ausprobieren können, ohne ihren Client-Code ändern zu müssen.

Kompatibel bedeutet jedoch nicht identisch. Die Struktur der Anfrage stimmt zwar überein, doch die Semantik hinter den einzelnen Parametern kann unterschiedlich sein, und ununterstützte Optionen werden oft akzeptiert und anschließend ignoriert anstatt abgelehnt. Genau dieses Verhalten macht diese Schichten riskant: Es tritt keine deutliche Fehlermeldung auf, wodurch fehlende Funktionen sich als minderwertige Ausgabe statt als Fehler zeigen.

Anthropics Kompatibilitätslayer

Die Kompatibilitätsdokumentation von Anthropics OpenAI SDK stellt diese Schicht als Möglichkeit zur Testung und Vergleich der Fähigkeiten von Modellen dar, nicht jedoch als empfohlene Lösung für die Produktivumgebung. Zudem werden konkrete Einschränkungen aufgelistet:

  • Die strict-Flagge für Funktionsaufrufe wird ignoriert, wodurch nicht garantiert werden kann, dass die JSON-Daten der Tool-Aufrufe dem von Ihnen bereitgestellten Schema entsprechen.
  • Prompt-Caching ist über die Kompatibilitäts-Schicht nicht verfügbar, obwohl die native Anthropic-API es unterstützt.
  • Sämtliche System- und Entwicklernachrichten werden zu Beginn des Gesprächs in eine einzige Systemnachricht zusammengeführt, da Claude nur einen einzigen initialen Systemprompt akzeptiert.

Nichts davon wird ein schnelles Experiment behindern. Jeder von ihnen kann einen Produktionsagenten zum Versagen bringen, der auf Argumenten abhängt, die einem Schema entsprechen müssen, auf Caching zur Kontrolle von Latenz und Kosten oder auf Systemanweisungen, die mitten im Gespräch eingeschleust werden.

Googles Kompatibilitätslayer

Die Seite von Google ist aus der Box heraus vollständiger. Laut seiner Gemini-Dokumentation zur Kompatibilität mit OpenAI funktionieren Standard-Chat-Erweiterungen, Streaming sowie Funktionsaufrufe problemlos. Google macht jedoch gleichzeitig deutlich, dass nicht jede anbieterbezogene Option zwischen den beiden APIs übertragen werden kann, und empfiehlt, so bald wie möglich auf die native Gemini-API umzusteigen, sobald eine gemini-spezifische Funktion benötigt wird.

Die Kosten für den Betrieb all dieser Lösungen

Jede Schicht für sich ist eine praktische Übergangslösung, um ein Modell zu bewerten. Wenn man alle drei Anbieter in einer einzigen Anwendung zusammenführt, verdoppelt sich der Aufwand: drei Basis-URLs, drei API-Schlüssel, drei Abrechnungs-Dashboards, drei Satz von Rate-Limits sowie drei verschiedene Listen mit Parametern, die stillschweigend weggelassen werden – alles nur, um Code zu unterstützen, der für jeden Anbieter gleich aussieht.

OpenAI SDK auf Claude richten

Um eine OpenAI SDK-Integration auf Claude umzustellen, sind drei Änderungen notwendig: die Basis-URL, ein Anthropic-API-Schlüssel anstelle eines OpenAI-Schlüssels sowie der Name des Claude-Modells. Dadurch ist es die schnellste Möglichkeit, Claude zu testen, bevor man sich auf Anthropics natives SDK festlegt. Die Imports bleiben unverändert:

import os
from openai import OpenAI

Der Client wird mit Anthropics Endpunkt sowie einer aus der Umgebung gelesenen Schlüsselzeichen erstellt, und der Aufruf selbst stellt eine standardmäßige Chat-Vervollständigung dar. Beachten Sie, dass im abgedruckten Auszug eine Zeilenumbruch zwischen dem schließenden Klammernzeichen des Clients und response = fehlt; teilen Sie diese in zwei Anweisungen auf, wenn Sie ihn kopieren:

client = OpenAI(
    api_key=os.environ.get("ANTHROPIC_API_KEY"),
    base_url="https://api.anthropic.com/v1/",
)response = client.chat.completions.create(
    model="claude-opus-5",
    messages=[{"role": "user", "content": "Explain how AI works"}],
)

Für eine einfache Chat-Vervollständigung ist das die gesamte Migration. Alles, was von den oben aufgeführten Einschränkungen abhängt, erfordert mehr Sorgfalt. Wenn Ihre Anwendung auf strengen Tool-Schemata, Prompt-Caching oder der vollständigen erweiterten Denkausgabe angewiesen ist, verwenden Sie Anthropics native API, um die vollständige Funktionalität zu erhalten, anstatt deren OpenAI-ähnliche Approximation. Modellnamen wie der hier gezeigte ändern sich häufig, daher prüfen Sie den aktuellen Identifikator in der Modellliste des Anbieters.

OpenAI SDK auf Gemini ausrichten

Die Gemini-Version desselben Austauschs zielt auf Googles Endpunkt ab. Sie benötigen einen Gemini-API-Schlüssel, den Sie in Google AI Studio erstellen können. Auch hier ist nur die Standard-OpenAI-Import-Methode erforderlich:

from openai import OpenAI

Der Client verwendet den Gemini-Schlüssel sowie Googles OpenAI-kompatiblen Basis-URL; der Anfragekörper bleibt unverändert. Auch hier fehlt eine Zeilenumbruch, und der fest codierte Schlüssel-Ersatz sollte besser durch eine Umgebungsvariable ersetzt werden, wie im Claude-Beispiel:

client = OpenAI(
    api_key="YOUR_GEMINI_API_KEY",
    base_url="https://generativelanguage.googleapis.com/v1beta/openai/",
)response = client.chat.completions.create(
    model="gemini-3.7-flash",
    messages=[{"role": "user", "content": "Explain how AI works"}],
)

Sowohl Streaming als auch Funktionsaufrufe funktionieren über diesen Endpunkt. Geminis Reasoning-Steuerungselemente werden über OpenAI’s reasoning_effort-Parameter bereitgestellt, doch die Zuordnung ist nicht immer eine exakte Entsprechung und hängt davon ab, welches Gemini-Modell verwendet wird. Wenn Sie eine neue, ausschließlich für Gemini verfügbare Funktion so schnell wie möglich nutzen möchten, bleibt das native SDK der schnellere Weg.

Was ist mit GPT selbst?

OpenAIs eigene API benötigt keine Kompatibilitätsschicht, denn sie definiert das Format, dem alle anderen folgen. Das löst das Problem mit mehreren Anbietern jedoch nicht, es verschiebt es lediglich. Code, der nach OpenAI’s Format geschrieben ist, erleichtert es später, auch die Schichten von Anthropic und Google hinzuzufügen, doch man behält weiterhin separate Schlüssel, unterschiedliche Rate Limits sowie eigene Besonderheiten für jeden Anbieter.

Jedes Modell über ein einziges Gateway leiten

Auch die eigenen Schichten der Anbieter beheben das Problem mit mehreren Anbietern nicht, da jede nur zu ihren eigenen Modellen leitet. Ein LLM-Gateway schließt diese Lücke: ein einziger OpenAI-kompatibler Endpunkt, der Anfragen je nach angegebenem model an Claude, GPT oder Gemini weiterleitet, sodass Ihr Code nicht mehr nachverfolgen muss, welche Besonderheiten zu welchem Anbieter gehören.

Die Migration sieht genauso aus wie die beiden vorherigen. Das untenstehende Beispiel verwendet den Endpunkt eines kommerziellen Gateways; dasselbe Muster gilt für jedes mit OpenAI kompatible Gateway. Die Importvorgänge bleiben unverändert:

from openai import OpenAI

Der Client verweist nun mit einem Gateway-Schlüssel auf die Basis-URL des Gateways, und der Modellname wählt den upstream-Anbieter aus. Wie zuvor sollte vor response = eine Zeilenumbruch eingefügt werden:

client = OpenAI(
    api_key="YOUR_SAYGM_API_KEY",
    base_url="https://api.saygm.com/v1",
)response = client.chat.completions.create(
    model="claude-opus-5",
    messages=[{"role": "user", "content": "Explain how AI works"}],
)

Um den Anbieter zu wechseln, muss model auf gpt-5.6-luna oder gemini-3.7-flash geändert werden; ansonsten bleibt alles unverändert. Betrachten Sie diese Modellnamen als Beispiele, die zum Zeitpunkt der Erstellung gültig sind, und prüfen Sie das Modellkatalog des Gateways auf aktuelle Identifikatoren. D dieselbe Konfiguration funktioniert in Entwicklerwerkzeugen, die bereits OpenAI-kompatible Einstellungen lesen, wie z. B. Cursor, Cline, Claude Code und das Vercel AI SDK: Eine Basis-URL sowie ein Schlüssel geben alle vom Gateway angebotenen Modelle preis, anstatt nur die Palette eines einzelnen Anbieters. Jedes Werkzeug verwendet eigene Feldnamen für die Basis-URL und den Schlüssel, daher sollten Sie sich in den Integrationsdokumenten des Gateways nach den genauen Einstellungen erkundigen.

Was ein Gateway nicht ändert

Durch das Routing über ein Gateway werden die Grenzen des Kompatibilitätsverhaltens des zugrunde liegenden Anbieters nicht aufgehoben. Das Senden von Claude-Anfragen im OpenAI-Format über ein Gateway gewährt weiterhin weder Prompt-Caching noch strenge vorgeschriebene Schemata; alle oben dokumentierten Einschränkungen bleiben weiterhin gültig.

Gateway bilden außerdem einen Teil Ihrer Vertrauensgrenze, da jeder Prompt und jede Antwort durch sie geleitet wird. Einige Anbieter werben mit Vertraulichkeitsmaßnahmen, beispielsweise dem Verarbeiten der Anfragen innerhalb hardwaregeprüfter, vertrauenswürdiger Ausführungsumgebungen, sodass der Gateway-Betreiber den Datenverkehr nicht lesen kann. Solche Garantien betreffen nur das Gateway; der Modellanbieter erhält und verarbeitet Ihre Anfrage weiterhin nach seinen eigenen Bedingungen. Beurteilen Sie beide Ebenen getrennt voneinander und überprüfen Sie alle Angaben zu Zertifizierungen anhand der technischen Dokumentation des Anbieters und nicht seiner Marketingmaterialien.

Häufige Migrationsfragen

Überleben Claude- oder Gemini-spezifische Funktionen eine OpenAI-kompatible Schicht?

Nur die Funktionen, die von der Schicht abgebildet werden. Egal, ob Sie den eigenen Kompatibilitäts-Endpunkt des Anbieters aufrufen oder über ein Gateway weiterleiten – alles, was nicht übersetzt wird, geht verloren. Bei Claude sind das unter anderem Prompt-Caching, PDF-Verarbeitung sowie die vollständige erweiterte Denkausgabe; bei Gemini gehören dazu modellspezifische Schlussfolgerungsparameter. Wenn Sie auf diese angewiesen sind, rufen Sie für diese Codepfade die native API auf.

Was kostet der Umstieg?

Mit einem Gateway zahlen Sie in der Regel pro Token, ähnlich wie bei direktem Aufruf eines Anbieters, doch die Tarife variieren je nach Modell und Anbieter, und einige Gateways fügen einen Aufschlag hinzu. Überprüfen Sie vor dem Umleiten des Produktivverkehrs die aktuell veröffentlichten Preise für das jeweilige Modell.

Was passiert, wenn ein Anbieter ausfällt?

Dies ist der stärkste Argument für einen einzigen Endpunkt. Ein für Failover konstruiertes Gateway kann ohne jegliche Änderung am Anwendungscode auf ein Ersatzmodell umgeleitet werden, während drei direkte Integrationen jeweils ihre eigene Wiederholungs- und Ersatzlogik benötigen. Bedenken Sie, dass ein Ersatzmodell ein anderes Modell ist: Für Claude optimierte Anfragen können sich bei Gemini anders verhalten, und die Zuverlässigkeit der Tool-Aufrufe variiert. Testen Sie Ihre kritischen Anfragen an jedem Modell in der Ersatzkette, bevor Sie sich auf ein automatisches Failover verlassen.

Auswahl des Migrationswegs

  • Bewertung eines zusätzlichen Anbieters: Nutzen Sie den eigenen OpenAI-kompatiblen Endpunkt dieses Anbieters. Dafür ist er genau konzipiert, und die Einrichtung erfordert nur drei Zeilen Anpassungen.
  • Zwei oder drei Anbieter in der Produktion betreiben: Überlegen Sie sich ein Gateway, da es doppelte Schlüssel, Dashboards sowie die Handhabung von Rate-Limits beseitigt und den Failover zentralisiert.
  • Abschließend hängt es von den anbieterbezogenen Funktionen ab: Verwenden Sie für diese Bereiche weiterhin native SDK-Aufrufe, unabhängig von der gewählten Option für alle anderen Aspekte.
  • Egal für welchen Weg Sie sich entscheiden, halten Sie die Basis-URL, den Schlüssel sowie den Modellnamen in der Konfiguration und nicht im Code fest. Fügen Sie außerdem Integrationstests hinzu, die die vom Anwendungsverhalten abhängigen Aspekte überprüfen, wie beispielsweise die Einhaltung des Tool-Call-Schemas. Auf diese Weise führt das Verschwinden eines Parameters zu einem fehlgeschlagenen Test statt zu einem Problem in der Produktion.

    Haupterkenntnisse

    • OpenAI-kompatible Endpunkte entsprechen der Anfragesyntax, nicht jedem Verhaltensaspekt; ununterstützte Parameter werden oft ohne Fehler ignoriert.
    • Anthropics Schicht ignoriert strict-Tool-Schemata, verfügt nicht über Prompt-Caching und fügt Systemnachrichten zusammen; sie ist als Testweg dokumentiert.
    • Geminis Schicht bewältigt Chat, Streaming und Funktionsaufrufe gut, doch anbieterbezogene Optionen benötigen weiterhin die native API.
    • Eine einzige Gateway-Lösung vereinfacht Schlüsselverwaltung, Abrechnung und Failover zwischen Anbietern, erbt aber alle Kompatibilitätsbeschränkungen und fügt eine weitere Partei zu Ihrem Vertrauensrahmen hinzu.