# Claude Code und Codex per API: Kosten und Anbindung im Vergleich > Canonical: https://vxi.me/de/posts/claude-code-codex-api-gateway-comparison/ > Locale: de-de > Published: 2026-10-14 > Updated: 2026-10-14 > Markdown: https://vxi.me/de/posts/claude-code-codex-api-gateway-comparison.md Wenn du jeden Monat dein Abo für Claude Code oder Codex verlängerst, hast du diese Rechnung vielleicht auch schon aufgemacht: Plus kostet 20 US-Dollar im Monat. Bei wenig Nutzung fühlt sich das nach zu viel an, bei intensiver Nutzung reicht es nicht. Die offizielle API nach Verbrauch klingt flexibler, aber ohne Kostendeckel bleibt die Rechnung schwer kalkulierbar. Ein selbst gehostetes Gateway könnte Abos bündeln, bringt aber VPS und OAuth-Konfiguration mit sich. Und bei einem Vermittler sind die Preise zwar niedriger, doch du gibst deinen API-Key aus der Hand und kannst nur darauf vertrauen, dass wirklich das gewünschte Modell antwortet. Ich habe die drei praktikablen Wege miteinander verglichen: CLIProxyAPI wandelt vorhandene CLI-Abos in eine kompatible API um, die du selbst betreibst; OpenRouter und ähnliche kommerzielle Vermittler leiten Anfragen nach Verbrauch weiter; oder du nutzt direkt die offizielle API des Modellanbieters. Das Fazit vorweg: Das beste Gateway gibt es nicht – entscheidend ist, welches Kostenmodell zu deiner Nutzung passt. Bei hoher, aber innerhalb des Abo-Kontingents stabiler Nutzung ist das Bündeln von Abos auf einem eigenen Server meist am günstigsten. Bei geringer Nutzung ist die Abrechnung nach Verbrauch am unkompliziertesten. Dazwischen kommt es darauf an, ob du einen VPS warten möchtest. Zunächst zur Abgrenzung: In diesem Beitrag geht es ausschließlich um die API-Bereitstellung für AI-Coding-Agents wie Claude Code und Codex, nicht um einen allgemeinen Vergleich von LLM-Gateways. CLIProxyAPI bündelt Zugangsdaten aus den Abos verschiedener CLI-Tools. Laut Projektdokumentation zählen Codex, Claude Code, Gemini CLI und Grok zu den unterstützten Upstreams; bereitgestellt werden OpenAI-, Gemini-, Claude- und Codex-kompatible Schnittstellen. Ein Vergleich mit allgemeinen Gateways wäre daher nicht sinnvoll. ## Erst die Kostenbasis angleichen Zuerst wollte ich mit einer Funktionsübersicht anfangen. Dabei wurde schnell klar: Die Anzahl der Funktionen beantwortet nicht die Frage, wofür das Geld draufgeht. Deshalb vergleiche ich stattdessen Kostenstruktur, Einrichtungsaufwand und Datenfluss – genau dort lauern bei der Auswahl die Fallstricke. Auch der Versionsstand kann das Ergebnis beeinflussen: CLIProxyAPI wird häufig veröffentlicht. Ich dachte zunächst, die Versionsnummer in den GitHub-Releases reiche zur Prüfung. Tatsächlich müssen auch die Image-Tags auf Docker Hub dazu passen. Erst wenn beide auf v8.0.27 (veröffentlicht am 2026-10-12) verweisen, ist der Stand bestätigt. Wer nur eine Quelle prüft, landet womöglich bei einer alten, zwischengespeicherten Seite. Die Versionsangaben unten beziehen sich auf den Stand vom 2026-10-14. Vor der Einrichtung solltest du zur Sicherheit noch einmal die Docker-Hub-Tags prüfen. ## Selbst hosten: Abo plus VPS, relativ feste Kosten Beim selbst gehosteten Ansatz solltest du mit festen Kosten rechnen und ihn nicht als „kostenlose API“ betrachten. Bei einem Abo ab 20 US-Dollar im Monat plus etwa 5–10 US-Dollar für einen VPS bleiben die monatlichen Ausgaben relativ konstant. Je höher die Nutzung, desto besser verteilen sich die Kosten. Für alle, die täglich intensiv mit einem Agent arbeiten, ist das meist der günstigste Weg. Dafür musst du drei Dinge selbst übernehmen: den OAuth-Device-Code-Ablauf, die laufende Wartung eines VPS und das Risiko, dass der Abo-Anbieter den Zugang einschränkt. Als ich Anfang Oktober auf einem VPS eingerichtet habe, gab es beim OAuth-Schritt einen Cloudflare-403-Fehler und regionale Timeouts. Am Ende stellte sich heraus, dass das Abo beziehungsweise die Netzwerkumgebung die Ursache war – kein Fehler im Gateway selbst. Den vollständigen Ablauf habe ich in einem Erfahrungsbericht festgehalten. Die Abschnitte zu Docker und zur Client-Konfiguration kannst du direkt übernehmen: [Codex über CLIProxyAPI weiterleiten](/posts/cliproxyapi-codex-docker-proxy/). Aber genau das gehört zum Selbstbetrieb: Wenn an irgendeiner Stelle der Verbindungskette etwas schiefgeht, bist du es, der nachts aufsteht und den Fehler behebt. ### Den ungefähren Break-even berechnen Wie viel Nutzung braucht es, damit sich Selbsthosting gegenüber der Abrechnung nach Verbrauch lohnt? Eine grobe Rechnung – mit klar genannten Annahmen, nicht als verbindliches Angebot: - **Feste Kosten beim Selbsthosting**: 20 $/Monat fürs Abo + 5 $/Monat für einen VPS-Einstiegstarif ≈ **25 $/Monat als Obergrenze**; unabhängig davon, wie viel du nutzt. - **Abrechnung nach Verbrauch über die offizielle API**: Bei einem Modell auf Sonnet-5.5-Niveau (2 $ Input / 10 $ Output pro einer Million Token, laut Drittanbieter-Aufstellung) kosten täglich eine Million Input-Token plus 200.000 Output-Token etwa 4 $ pro Tag. Auf einen Monat gerechnet sind das rund **120 $**. Der Kipppunkt ist leicht zu erkennen: Bei einer Million Token täglich und entsprechend intensiver Nutzung macht Selbsthosting aus einer schwer kalkulierbaren Rechnung eine feste Monatsgebühr. Wer dagegen nur ein paar Mal pro Woche ein Terminal öffnet, zahlt nach Verbrauch möglicherweise nur wenige Dollar im Monat. Beim Selbsthosting käme dann die ungenutzte Monatsmiete für den VPS obendrauf. Entscheide anhand deines eigenen Nutzungsprofils. ### Installation im Test: v8.0.27, auf Anhieb erfolgreich Ich habe die Installation auf einer isolierten Testmaschine (Ubuntu 26.04, 1 Kern / 1,9 GB RAM) vollständig wiederholt und die Version auf v8.0.27 festgesetzt, statt `latest` zu verwenden: ```bash docker pull eceasy/cli-proxy-api:v8.0.27 # 292MB，发布页显示 2026-10-12 发布 ``` Für eine minimale Konfiguration reichen drei Zeilen. Der Dienst startet auch ohne konfigurierten Upstream: ```yaml # config.yaml config-version: 8 server: port: 8317 ``` ```bash docker run -d --name cpa-test --restart unless-stopped \ -p 8317:8317 \ -v ./config.yaml:/CLIProxyAPI/config.yaml \ -v ./auths:/root/.cli-proxy-api \ eceasy/cli-proxy-api:v8.0.27 ``` Das Startprotokoll bestätigt Version, Commit und Build-Zeit (v8.0.27 / bf93416 / 2026-10-12) und stimmt mit GitHub main überein. `/` liefert HTTP 200 und listet drei kompatible Endpunkte auf. `/v1/models` gibt ohne konfigurierten Upstream eine leere Liste zurück – das ist normal und kein Fehler. Zwei Details aus dem Test sollte man in einer Anleitung ausdrücklich erwähnen: 1. **In der Minimal-Konfiguration ist die Authentifizierung standardmäßig deaktiviert.** Wenn `access.api-keys` nicht konfiguriert ist, kann jeder dein Gateway aufrufen. Im internen Netz ist das vielleicht unproblematisch. Sobald der Port öffentlich erreichbar ist, solltest du als Erstes einen Key einrichten. 2. **Im Container nicht `127.0.0.1` verwenden, um den Host zu erreichen.** Ich hatte den Mock-Upstream zunächst als `http://127.0.0.1:18888` konfiguriert. Das Gateway antwortete direkt mit „connection refused“ – localhost im Container verweist auf den Container selbst. Verwende stattdessen die Docker-Bridge-Adresse des Hosts (üblicherweise 172.17.0.1) oder `--network host`. Die Fehlermeldung des Gateways ist immerhin eindeutig: Im 500-Fehler steht der Grund für den fehlgeschlagenen Verbindungsaufbau. Die Fehlersuche ist dadurch unkompliziert. Außerdem gibt es den Endpunkt `/health` in meiner Testkonfiguration nicht (404). Kopiere ihn also nicht ungeprüft in ein allgemeines Health-Check-Skript. ### Wie viel langsamer ist das Gateway? Im Test etwa 4 ms „Wird das Selbsthosting langsam?“ ist eine der häufigsten Fragen bei der Auswahl. Also habe ich es direkt gemessen. Vorgehen: Auf derselben Maschine lief ein Mock-OpenAI-Upstream mit einer festen Verzögerung von 50 ms bis zum ersten Chunk. Ich habe Streaming-Aufrufe direkt an den Mock und über das Gateway dorthin jeweils 20-mal verglichen. | Pfad | Erfolgsquote | Median bis zum ersten Token | p95 bis zum ersten Token | Median der Gesamtdauer | |---|---|---|---|---| | Direkt zum Mock-Upstream | 20/20 | 52,4 ms | 52,9 ms | 104,2 ms | | Über das CLIProxyAPI-Gateway | 20/20 | 56,5 ms | 57,3 ms | 108,7 ms | Das Gateway selbst fügte nur etwa 4 ms hinzu. Dass p95 und Median dicht beieinanderliegen, deutet auf einen stabilen Overhead hin. Das Ergebnis gilt allerdings nur für die Testbedingungen: **Bei geringer Last auf derselben Maschine mit einem Mock-Upstream ist das selbst gehostete Gateway kein Engpass.** Eine gefühlte Verzögerung kommt meist von der Modellinferenz oder dem Upstream-Netzwerk, nicht von diesem zusätzlichen Proxy-Hop. Hohe Parallelität und komplexe Netzwerkumgebungen habe ich nicht getestet. ![Vergleich des Gateway-Overheads: direkt zum Mock-Upstream versus über das CLIProxyAPI-Gateway, Median bis zum ersten Token / TTFT p95 / Median der Gesamtdauer (N=20, Test auf derselben Maschine); Gateway-Overhead etwa 4 ms](/images/posts/claude-code-codex-api-gateway-comparison/gateway-overhead-chart.png) Zum Vergleich habe ich zehn echte Modellaufrufe direkt über einen kommerziellen OpenAI-kompatiblen Vermittler getestet: 10/10 erfolgreich, Median bis zum ersten Token 1.240 ms, p95 1.996 ms, Median der Gesamtdauer 1.745 ms. Das verwendete Modell war gpt-6-luna, die Modellbezeichnung aufseiten des Vermittlers; den Modell-Fingerprint habe ich nicht verifiziert. Die Zeit bis zum ersten Token wird vor allem von der Modellinferenz bestimmt. Das bestätigt auch das obige Ergebnis: Die 4 ms des Gateways sind im Gesamteindruck praktisch nicht wahrnehmbar. Die Bereitstellung selbst ist unkompliziert. Sobald der Container läuft, greift der Agent über eine OpenAI-kompatible Adresse auf den Dienst zu. Welche Endpunkte und Authentifizierungsmethoden gelten, hängt von der verwendeten Version ab – maßgeblich ist deren Dokumentation. Eine typische Konfiguration auf Client-Seite sieht so aus. Ersetze die Beispieladresse durch die deines Dienstes: ```python from openai import OpenAI client = OpenAI( base_url="https://your-api.example/v1", api_key="YOUR_API_KEY", ) ``` Wenn du nicht bei null anfangen möchtest: Ich habe die damals geprüften Bereitstellungsskripte in einem Repository für die Installation mit einem Klick zusammengestellt. Mit `setup.sh` lässt sich der Dienst direkt starten; ein Key muss noch eingerichtet werden. Eine praktische Option, wenn du Zeit sparen möchtest: kuangyongjie/cliproxyapi-codex-deploy ## OpenRouter: wenig Wartung, Abrechnung nach Verbrauch Bei OpenRouter funktioniert die Kostenlogik genau umgekehrt: Die Tokenpreise werden ohne Aufschlag zu den Preisen des jeweiligen Anbieters durchgereicht. Die Plattform verdient an der Einzahlung: Kreditkartenzahlungen kosten 5,5 % Gebühr (mindestens 0,80 US-Dollar), Kryptowährungen 5 %. Ich habe diese Gebühren mit drei voneinander unabhängigen Quellen aus Oktober 2026 abgeglichen (betterclaw.io, leanroute.dev, calculatorai.app); die Angaben stimmen überein. Maßgeblich sind die [offiziellen Preise](https://openrouter.ai/pricing), geprüft am 2026-10-14. Außerdem gibt es BYOK: Wenn du deinen eigenen offiziellen Key hinterlegst, fällt bis zu einem monatlichen Listenpreis-Umsatz von 25.000 US-Dollar keine Plattformgebühr an. Darüber hinaus werden 5 % berechnet. Auch hier gilt die offizielle Preisseite. Die Anbindung ist von den drei Wegen am einfachsten: registrieren, Guthaben aufladen, den `base_url` des OpenAI SDK auf OpenRouter zeigen lassen und ein Modell auswählen. Die offizielle Dokumentation bestätigt den OpenAI-kompatiblen Endpunkt und den Austausch ohne größere Codeänderungen: ```python from openai import OpenAI client = OpenAI( base_url="https://openrouter.ai/api/v1", api_key="YOUR_OPENROUTER_API_KEY", ) response = client.chat.completions.create( model="YOUR_MODEL", messages=[{"role": "user", "content": "Hello"}], ) ``` Weniger Wartungsaufwand hat allerdings seinen Preis: Die Anfrage läuft erst über OpenRouter und anschließend zum Upstream-Anbieter. Laut Standardeinstellung speichert die Plattform keine Prompts und Completions, sondern nur Metadaten; Protokolle lassen sich optional aktivieren. Das ist die standardmäßige Logging-Richtlinie der Plattform. Die Anfrage erreicht letztlich den Upstream-Anbieter und unterliegt dessen Datenschutzrichtlinien. Für Teams mit sensiblen Daten ist nicht allein entscheidend, ob etwas gespeichert wird, sondern auch, über welche Stellen die Anfrage läuft. Das gilt für jeden kommerziellen Vermittler. Risiken bei kommerziellen Vermittlern sollte man konkret benennen und Belege von Einschätzungen trennen. Eine Studie weist auf Fälle hin, in denen der Modell-Fingerprint bei weiterverkauften Vermittlungszugängen nicht übereinstimmt. Ich konnte die Originalquelle jedoch nicht unabhängig prüfen und nenne deshalb hier keinen chinesischen Vermittler beim Namen. Sinnvoller ist es, zunächst einen kleinen Betrag zu testen und anschließend den tatsächlichen Modell-Fingerprint und das Serviceverhalten zu prüfen. Wenn etwas nicht zusammenpasst, solltest du wechseln. Empfehlungen, die nur über den Preis sprechen und keine Prüfmethoden nennen, sind mit Vorsicht zu behandeln. ## Offizielle API: direkte Anbindung als Referenz Die offizielle API wird nach Verbrauch abgerechnet und verbindet dich direkt mit dem Modellanbieter. Der Datenweg ist damit am kürzesten. Sie dient als Vergleichsbasis für die anderen beiden Optionen: Bei allen Werbeaussagen über „X % günstiger“ ist genau das der Bezugswert. Die konkreten Preise von OpenAI und Anthropic stammen aus einer Drittanbieter-Aufstellung von 2026-10 und eignen sich für einen ersten Vergleich. Da sich Preise häufig ändern, solltest du sie vor der Einrichtung unbedingt auf der [offiziellen Preisseite](https://openai.com/api/pricing/) und der [Anthropic-Preisseite](https://www.anthropic.com/pricing/) prüfen. Verlass dich in deinem eigenen Kostenmodell nicht langfristig auf Preise, die sich ändern können. Die Stabilität lässt sich zunächst anhand der Architektur einordnen, auch ohne Messwerte abzuwarten: Beim selbst gehosteten Dienst ist der VPS ein zusätzlicher Single Point of Failure, und im Fehlerfall kümmerst du dich selbst darum. Kommerzielle Plattformen bieten Routing und Fallbacks, deren Wirksamkeit vom konkreten Modell und der Art des Ausfalls abhängt. Die offizielle API wird direkt vom Anbieter betrieben. Daraus ergeben sich drei einfache Empfehlungen: Bei hoher Nutzung, Bereitschaft zur VPS-Wartung und Akzeptanz des Risikos rund um das Abo bietet sich Selbsthosting an. Bei geringer Nutzung oder ohne Lust auf Wartung ist OpenRouter unkomplizierter. Wenn du strenge Anforderungen an Datenfluss und Direktanbindung hast, nimm die offizielle API. Die tatsächliche Verfügbarkeit der drei Optionen wurde in diesem Beitrag nicht verglichen. Architekturüberlegungen sind kein Verfügbarkeitsversprechen. ## Grenzen und Einschränkungen In diesem Test habe ich zwei Aspekte untersucht: den Overhead des Gateways selbst (Mock-Upstream auf derselben Maschine, N=20, +4 ms) und die praktische Latenz eines direkten Aufrufs über einen kommerziellen Vermittler (vorhandener Vermittler, gpt-6-luna, N=10). **Nicht getestet** habe ich die Online-Latenz von OpenRouter und der offiziellen API (keine passenden Keys vorhanden), die Ende-zu-Ende-Performance eines OAuth-Abo-Upstreams (dafür wäre eine Anmeldung per Device-Code im Browser nötig) und die Stabilität über mehr als 24 Stunden. Das Ergebnis zum Gateway-Overhead beruht auf einem Mock-Upstream. Es zeigt, dass „das Gateway selbst nicht langsam ist“, nicht, dass „dein Upstream nicht langsam ist“. Versionsnummern von CLIProxyAPI, Gebühren bei OpenRouter und offizielle Preise können sich ändern. Die Angaben oben beziehen sich auf den Stand vom 2026-10-14. Prüfe vor der Einrichtung noch einmal die Projekt-Releases, Docker-Hub-Tags und offiziellen Preisseiten. ## Zum Schluss: drei Empfehlungen - **Selbst hosten und Abos bündeln**: Wenn du täglich intensiv mit einem Agent Code schreibst, bereits ein CLI-Abo hast, grundlegende Linux-Kenntnisse mitbringst und deine Kosten fest kalkulieren möchtest. - **OpenRouter wählen**: Wenn deine Nutzung gering bis mittel oder stark schwankend ist, du keinen Server warten möchtest und häufig zwischen Modellen wechselst. - **Die offizielle API nutzen**: Wenn es Compliance-Anforderungen an den Datenfluss gibt, das Budget ausreicht und dir flexible Kosten nach Verbrauch keine Sorgen bereiten. **Weiterführende Links:** [CLIProxyAPI-Projekt](https://github.com/router-for-me/CLIProxyAPI) · [Repository für die Installation mit einem Klick](https://github.com/kuangyongjie/cliproxyapi-codex-deploy) · [OpenRouter-Schnellstart](https://openrouter.ai/docs/quickstart) · [OpenRouter-Preise](https://openrouter.ai/pricing) ## Verification context - Level: first-party - Verified: 2026-10-14T00:00:00.000Z - Environment: Ubuntu 26.04 - Environment: Docker 29.9.0 - Environment: CLIProxyAPI v8.0.27 - Evidence mode: mixed - Evidence receipt: https://vxi.me/evidence/claude-code-codex-api-gateway-comparison.json