Welche Alternative zu OpenRouter eignet sich für Claude Code?

Ein erfolgreicher Messages-Aufruf ist der Anfang einer Migration. Entscheidend sind die Grenzen zwischen HTTP, Client-Konfiguration und Werkzeugaufrufen.

Wer Claude Code an einen anderen API-Gateway anschließt, ändert scheinbar nur eine URL, einen Schlüssel und einen Modellnamen. In der Praxis bestimmen jedoch mehrere voneinander unabhängige Einstellungen, wohin eine Anfrage gelangt und welche Funktionen anschließend funktionieren.

Crazyrouter ist ein Kandidat neben OpenRouter, weil der Dienst einen Anthropic-Messages-Endpunkt und eine eigene Claude-Code-Anleitung anbietet. Für diesen Beitrag wurden am 12. Oktober 2026 ein minimaler Request, ein Werkzeugzyklus und mehrere Thinking-Konfigurationen ausgeführt. Dabei gab es erfolgreiche Antworten, aber auch eine falsche Beschreibung des verwendeten Werkzeugs. Gerade diese Unterschiede sind für die Integration aufschlussreich.

Zuerst den Vertrag der Schnittstelle festhalten

Für den Test wurden POST /v1/messages, der Header x-api-key, die Protokollversion 2023-06-01 und das Modell claude-haiku-5-5 verwendet. Der Auftrag lautete ausschließlich: Reply with exactly: OK.

Diese kleine Eingabe ist absichtlich langweilig. Sie trennt die grundlegende Erreichbarkeit von Themen wie Repository-Kontext, Werkzeugberechtigungen oder langen Antworten. Ein Fehler lässt sich so wesentlich enger eingrenzen.

Die Messages-Dokumentation beschreibt den Endpunkt und die Authentifizierung. Für den Client ist zusätzlich die Claude-Code-Integration relevant: Dort steht die Basisadresse ohne angehängtes /v1/messages.

Screenshot der offiziellen Dokumentation vom 12. Oktober 2026. Er zeigt die Schnittstellenbeschreibung, keinen Client-Test.

Einen reproduzierbaren Smoke-Test ausführen

Das folgende Beispiel ist für Bash gedacht. CRAZYROUTER_API_KEY muss vorher über die lokale Konfiguration gesetzt sein. Der Schlüssel benötigt Zugriff auf das angegebene Modell und ausreichendes Guthaben. Unter Windows ist beispielsweise Git Bash geeignet; die Zeilenfortsetzung ist keine PowerShell-Syntax.

curl --silent --show-error --fail-with-body \
  https://api.crazyrouter.com/v1/messages \
  -H "x-api-key: $CRAZYROUTER_API_KEY" \
  -H "anthropic-version: 2023-06-01" \
  -H "Content-Type: application/json" \
  -d '{"model":"claude-haiku-5-5","max_tokens":512,"messages":[{"role":"user","content":"Reply with exactly: OK"}]}'

Beim erneuten Test kamen HTTP 200, ein Textblock mit OK und stop_reason: "end_turn" zurück. Die Antwort meldete 42 Eingabe- und 4 Ausgabetokens. Die Zähler für Cache-Erstellung und Cache-Lesen waren null.

Für die Auswertung sollten drei Prüfungen zusammenkommen: erfolgreicher HTTP-Status, erwartete Antwortstruktur und der verlangte Inhalt. Ein Statuscode allein ist kein Beleg dafür, dass die Anwendung ihre Aufgabe erfüllt hat.

Der Modellname dient hier einem kleinen Verbindungstest. Er ist keine Empfehlung für jede Refactoring-Aufgabe. Ein späterer Wechsel auf ein anderes Modell verändert die Testbedingung und muss gesondert geprüft werden.

Einen Werkzeugzyklus bis zum Ergebnis verfolgen

Ein Tool-Test braucht mehr als einen Funktionsnamen im Request. Im Versuch erhielt claude-haiku-5-5 bei einem Ausgabelimit von 512 Tokens ein Werkzeug namens add_numbers. Das JSON-Schema erlaubte die beiden ganzzahligen Pflichtfelder a und b. Der Auftrag war Use add_numbers to calculate 3 + 4. Do not calculate it yourself.; über tool_choice wurde genau dieses Werkzeug ausgewählt.

Die erste Antwort hatte den Status 200 und den Abbruchgrund tool_use. Der strukturierte Aufruf enthielt den Namen add_numbers, eine Aufruf-ID und die Argumente 3 und 4. Zu diesem Zeitpunkt hatte das Modell eine Ausführung angefordert. Die Funktion war dadurch noch nicht im lokalen Programm gelaufen.

Der aufrufende Code überprüfte die Argumente, berechnete lokal 7 und übernahm den vollständigen Assistant-Inhalt in den Nachrichtenverlauf. Anschließend folgte eine User-Nachricht mit einem tool_result, dessen tool_use_id auf den tatsächlichen Aufruf verwies. Der Inhalt war die Zeichenfolge 7. Im zweiten Request blieben die Werkzeugdefinitionen erhalten, die erzwungene Auswahl wurde jedoch entfernt, damit das Modell antworten konnte.

Auch die zweite Antwort kam mit HTTP 200 zurück. Sie endete mit end_turn und nannte das richtige Ergebnis. Ihre zusätzliche Erklärung war allerdings falsch: Sie behauptete, add_numbers sei nicht vorhanden gewesen und das verwendete Werkzeug habe Agent geheißen. Im strukturierten Protokoll stand der andere Name.

Damit lassen sich drei Ergebnisse getrennt festhalten. Die Argumente entsprachen dem Schema. Der lokale Aufruf und die Rückgabe der passenden ID funktionierten. Die natürlichsprachliche Beschreibung stimmte nicht mit dem beobachteten Ablauf überein. Ein einzelnes Boolean-Feld wie tools_ok würde diese wichtige Unterscheidung verschlucken.

Für einen Coding-Agenten folgt daraus eine konkrete Anforderung an die Beobachtbarkeit: Eine Aussage wie „Tests ausgeführt“ muss mit dem realen Prozessaufruf und dessen Exit-Code verknüpft sein. Für Dateiarbeit zählt der tatsächliche Diff. Der Versuch erklärt nicht, warum der falsche Werkzeugname entstand, und belegt keine bestimmte interne Architektur. Er zeigt lediglich, dass korrekte Ergebnisse und korrekte Prozessbeschreibungen separat geprüft werden müssen.

Thinking als beobachtbares Verhalten prüfen

Im nächsten Versuch blieb die Frage 9.11 and 9.9, which is larger? unverändert. Die Requests verwendeten max_tokens:2048 und thinking:{"type":"enabled","budget_tokens":1024}. Nur der Modellbezeichner wechselte. Alle vier Anfragen erhielten HTTP 200, aber nicht dieselben Inhaltsblöcke.

Modell	Beobachtete Blöcke	Gemeldete Thinking-Tokens
claude-opus-5-5	thinking, text	34
claude-haiku-5-5	text	0
claude-sonnet-5-5	text	0
claude-opus-4-8	text	0

Haiku wurde zusätzlich mit einem Budget von 128 geprüft; anschließend wurden 128 und 1.024 jeweils wiederholt. Auch diese Antworten enthielten bei der gewählten Frage keinen sichtbaren Thinking-Block. Die einfache Anleitung „Budget erhöhen, dann erscheint Thinking“ ließ sich damit nicht bestätigen.

Aus diesen Zahlen folgt kein Ranking der Denkfähigkeit. Null gemeldete Thinking-Tokens beweisen nicht, dass keinerlei interne Verarbeitung stattfand. Außerdem lieferte das separate Werkzeugexperiment bei Haiku Thinking-bezogene Informationen. Die Auswertung muss daher beim jeweiligen Request bleiben, statt das Ergebnis zur unveränderlichen Eigenschaft des Modellnamens zu erklären.

Für einen Parser sind Blockpräsenz, sichtbarer Text und Verbrauch drei unterschiedliche Größen. Im Werkzeugversuch war beispielsweise der Thinking-Text leer. Eine Anwendung, die eine sichtbare Erklärung benötigt, darf einen leeren Block nicht als erfüllte Anforderung verbuchen. Umgekehrt sollte eine Anwendung ohne diese Anforderung nicht schon deshalb die gesamte Antwort verwerfen.

Die Client-Konfiguration als eigene Schicht behandeln

Bei Crazyrouter lautet die dokumentierte Basisadresse für Claude Code https://api.crazyrouter.com. Der Client ergänzt den Messages-Pfad selbst. Ein manuell angehängtes /v1 oder /v1/messages kann deshalb eine falsche Zieladresse erzeugen.

Das ist ein anderer Vertrag als bei einem OpenAI-kompatiblen Client. Eine funktionierende Cursor-Konfiguration ist daher keine sichere Vorlage für Claude Code. Auch die Modellbezeichner können zwischen Anbietern voneinander abweichen.

Offizieller Screenshot, aufgenommen am 12. Oktober 2026. Der grüne Hinweis erklärt, warum die Basisadresse am Domain-Stamm endet.

Vor einer dauerhaften Änderung lohnt sich ein temporäres Terminal mit klarer Konfiguration. So lässt sich erkennen, ob der gestartete Prozess tatsächlich die neuen Variablen erhält. Alte Zugangsdaten, ein bereits laufender Prozess oder ein anderer Shell-Kontext können sonst dieselben Symptome wie ein Gateway-Fehler erzeugen.

Bei Crazyrouter empfiehlt die Anleitung außerdem einen eigenen Token für Claude Code. Das hilft bei Berechtigungen und Kostenzuordnung. Es beweist nicht, dass zusätzliche Tokens zusätzliche Kapazität freischalten.

Fehler anhand ihrer Herkunft bearbeiten

Wenn bereits der minimale HTTP-Aufruf scheitert, beginnt die Suche bei Netzwerk, Adresse, Authentifizierung und Modellfreigabe. Funktioniert er, während Claude Code scheitert, wandert der Fokus zum Client und seiner Umgebung.

Beobachtung	Nächste sinnvolle Prüfung
Keine HTTP-Antwort	DNS, Proxy, TLS und Erreichbarkeit
400 oder 401	Request-Format beziehungsweise Authentifizierung
403	Fehlertext, Modellberechtigung und Guthaben
429	Frequenz reduzieren, dokumentierte Retry-Hinweise beachten
HTTP funktioniert, Client nicht	Basisadresse, Variablen, alte Anmeldung, Modellzuordnung
Chat funktioniert, Werkzeug nicht	Tool-Aufruf, Berechtigung, Arbeitsverzeichnis und tatsächliches Ergebnis

Die Crazyrouter-Fehlerdokumentation führt sowohl Berechtigungs- als auch Guthabenprobleme unter möglichen 403-Fällen auf. Deshalb sollte die Anwendung den Fehlercode im JSON erhalten und nicht nur die HTTP-Zahl protokollieren.

Ein Retry behebt keine falsche Berechtigung. Für vorübergehende Fehler sind begrenzte Wiederholungen mit wachsendem Abstand sinnvoll; Konfigurationsfehler müssen zuerst korrigiert werden. Geheimnisse gehören dabei weder in Request-Logs noch in Screenshots.

OpenRouter nicht anhand der falschen Schnittstelle beurteilen

OpenRouter bietet ebenfalls eine Claude-Code-Integration über das Anthropic-Protokoll. Die Anleitung empfiehlt den Anthropic-Erstanbieter als bevorzugten Provider und begrenzt ihre Kompatibilitätsgarantie entsprechend.

Auch beim Cache wäre die Aussage „vereinheitlichte Felder bedeuten verlorene Anthropic-Funktionen“ zu weitgehend. Die Caching-Dokumentation beschreibt sowohl Cache-Lese- und Schreibzähler als auch fünfminütige und einstündige TTLs. Welche Darstellung relevant ist, hängt vom tatsächlich verwendeten Endpunkt ab.

Für diesen Artikel wurde kein kostenpflichtiger OpenRouter-Aufruf ausgeführt. Seine Funktionen werden hier anhand der Dokumentation beschrieben, nicht als Ergebnis eines symmetrischen Leistungstests.

Provider-Regeln gehören zum Testaufbau

Die OpenRouter-Dokumentation zur Provider-Auswahl unterscheidet eine Reihenfolge von einer Einschränkung. order legt Präferenzen fest, only begrenzt zulässige Provider, und allow_fallbacks erlaubt standardmäßig weitere Ausweichwege. Wer nur den ersten Namen einer Liste protokolliert, kennt deshalb nicht zwangsläufig den tatsächlich verwendeten Weg.

Auch require_parameters ist relevant: Laut Dokumentation ist die Option standardmäßig false; true schränkt die Auswahl auf Provider ein, die die angeforderten Parameter unterstützen. Das ist eine dokumentierte API-Eigenschaft, kein Nachweis, dass jede Claude-Code-Konfiguration diese Option automatisch sendet. Die verwendete Client-Anbindung und mögliche Kontoeinstellungen müssen dazu passen.

Caching verbindet die Route mit den Kosten. OpenRouter beschreibt Sticky Routing, um denselben Provider wiederzuverwenden, aber eine ausdrücklich gesetzte provider.order hat Vorrang. Ein notwendiger Fallback kann den warmen Cachepfad ändern. Deshalb sind Cache-Lesezähler, Schreibzähler und Route gemeinsam aussagekräftiger als allein die Anzahl der Eingabetokens.

Ein weiterer Sonderfall steht in der Limits-Dokumentation: Bestimmte vorausbezahlte Konten unterliegen einem Budget für laufende beziehungsweise noch nicht abgerechnete Anfragen. Die Schätzung berücksichtigt unter anderem Eingabe und max_tokens. Eine 402-Antwort mit in_flight_budget_exhausted verlangt daher eine andere Diagnose als 429. Eine größere Ausgabegrenze kann den geschätzten Bedarf erhöhen, selbst wenn die tatsächlich ausgegebene Antwort später kurz bleibt. Diese Regel gilt nicht pauschal für jedes Konto oder jedes Abrechnungsmodell.

Die konkrete Reaktion sollte deshalb den Fehlergrund erhalten. Bei einer falsch formatierten Anfrage muss die Nutzlast korrigiert werden; eine Pause ändert daran nichts. Bei einem ausgeschöpften laufenden Budget können Abschluss und Abrechnung anderer Anfragen relevant sein. Überschreitet dagegen bereits die geschätzte einzelne Anfrage das verfügbare Budget, wird sie durch unverändertes Wiederholen nicht kleiner. Ein vorhandener Retry-After-Hinweis gehört in die Entscheidung, ersetzt aber nicht die Klassifikation. Für die vorliegenden Versuche wurde keine Lastgrenze ermittelt, und die dokumentierten OpenRouter-Regeln sind kein Messergebnis über Crazyrouter.

Eine Migration mit einem kleinen Repository abschließen

Nach dem Smoke-Test folgt ein überschaubares, rücksetzbares Projekt. Claude Code soll erst die Struktur lesen, dann eine konkrete Funktion erklären und schließlich eine kleine Änderung mit den vorhandenen Tests bearbeiten. Entscheidend sind Dateidiff und Testergebnis, nicht die Selbstauskunft des Modells.

Erst danach werden längere Kontexte, Cache-Nutzung und parallele Aufgaben interessant. Werden alle Variablen zugleich geändert, lässt sich ein Problem kaum noch einem Modell, dem Gateway oder dem Client zuordnen.

Crazyrouter hat im beschriebenen Test den minimalen Messages-Aufruf und einen einzelnen Werkzeugzyklus verarbeitet. Die falsche Werkzeugbeschreibung und die unterschiedliche Thinking-Ausgabe bleiben Teil des Ergebnisses. Beim nächsten Schritt sollte die Anwendung gerade diese Unterschiede sichtbar halten: strukturierte Aufrufe, lokale Ausführung und generierte Zusammenfassung separat erfassen und erst dann den Arbeitsauftrag bewerten.

Stand: 12. Oktober 2026. Screenshots stammen aus den genannten offiziellen Dokumentationen. Der beschriebene API-Aufruf wurde tatsächlich geprüft.