/v1/chat/completions bereit. Doch die Clients, die Sie eigentlich an dieses Modell anbinden möchten, nutzen nicht alle dieses Protokoll. Claude Code verwendet Anthropic Messages, OpenAI Codex nutzt OpenAI Responses. Keines dieser Protokolle entspricht Chat Completions, und keines wird sich ändern, um Ihrem Backend gerecht zu werden.
Tokios schließt diese Lücke bereits am Gateway, noch bevor eine Anfrage Ihren Rechner erreicht – dadurch kann dieselbe Deployment sowohl Claude Code, Codex als auch Aufrufe über das normale OpenAI SDK bedienen, ohne dass Sie drei Server betreiben oder eine eigene Übersetzungsschicht entwickeln müssen.
Drei verschiedene Client-Protokolle treffen am Gateway ein; dieses wandelt sie alle in Chat Completions um, damit ein einziges lokales Modell genutzt werden kann.
Die Unstimmigkeit
Am Endpunktapi.tokios.com treffen drei verschiedene Datenformate ein; nur eines davon versteht Ihr Backend:
Ollama, llama.cpp, vLLM und LM Studio unterstützen ausschließlich die dritte Variante. Sollte Tokios die eingehenden Daten unverändert durch den Tunnel leiten, würden die Anfragen von Claude Code und Codex in einer für den lokalen Server unbekannten Form eintreffen und sofort fehlschlagen.
Der Ort, an dem die Übersetzung erfolgt
Tokios wandelt die Anfrage des Clients in das Format OpenAI Chat Completions am Gateway um – also an der öffentlichen, cloudseitigen Komponente unterapi.tokios.com – bevor sie durch den Tunnel zu Ihrem Rechner gelangt. Einen vollständigen Überblick über den Ablauf der Anfragen finden Sie unter Wie Tokios Anfragen an lokale Modelle weiterleitet.
- Anthropic Messages (
POST /v1/messages, die von Claude Code gesendeten Daten) werden in Chat Completions übersetzt. - OpenAI Responses (
POST /v1/responses, die von Codex gesendeten Daten) werden ebenfalls in Chat Completions übersetzt. - OpenAI Chat Completions (
POST /v1/chat/completions) werden ohne weitere Umwandlung direkt weitergeleitet – eine Übersetzung ist hier nicht erforderlich.
tokios-connector erhält niemals Daten im Format von Anthropic oder Responses; es erhält lediglich Chat Completions-Daten und leitet sie unverändert an den von Ihnen konfigurierten BaseUrl weiter – beispielsweise http://127.0.0.1:11434/v1 bei Ollama. Der Connector übersetzt nichts, sondern leitet lediglich weiter. Die gesamte Logik zur Formatverarbeitung befindet sich auf Seiten des Gateways, und zwar pro Deployment genau einmal.
Diese Zentralisierung sorgt dafür, dass die Einrichtung portabel bleibt: Ihr Backend muss keine neuen Datenformate von Anthropic oder OpenAI implementieren; es muss lediglich weiterhin das tun, was es ohnehin tut.
Felder bezüglich Werkzeugen oder Funktionen werden während der Übersetzung mitgegeben, doch ob das Upstream-Modell sie tatsächlich berücksichtigt, hängt vom Modell selbst ab – die Übersetzung verändert lediglich das Datenformat, nicht die Fähigkeiten des Modells.
Dasselbe Deployment ist auf zwei Wegen erreichbar.
Angenommen, Sie haben ein Deployment namensgemma-tunnel erstellt, das auf ein lokales Modell verweist. Dieses eine Deployment reagiert sowohl auf Clients im Stil von Anthropic als auch auf solche im Stil von OpenAI, ohne dass Änderungen am Backend nötig wären.
Claude Code (Anthropic Messages)
Claude Code nutzt das Protokoll Anthropic Messages, weshalb es die Basis-URL verwendet – ohne/v1:
claude*-IDs auf; daher erscheint gemma-tunnel dort nicht. Geben Sie stattdessen --model explizit an, wie oben beschrieben. Die vollständige Einrichtung finden Sie unter Verwendung von Claude Code mit eigenen lokalen Modellen via Tokios.
OpenAI SDK (Chat Completions)
Ein Client im Stil von OpenAI nutzt die/v1-Basis-URL:
model-Wert: den öffentlichen Deployment-Namen (gemma-tunnel), nicht die interne ID Ihres lokalen Modells. Nach notwendigen Übersetzungen werden sie schließlich als eine einzige Chat Completions-Anfrage über denselben Tunnel an dasselbe lokale Modell gesendet. Das Modell weiß dabei nicht, mit welchem Protokoll der Client ursprünglich kommuniziert hat.
OpenAI Codex folgt im Rahmen der Responses API dem gleichen Muster – siehe Verwenden Sie OpenAI Codex mit eigenen lokalen Modellen über Tokios für die erforderliche config.toml-Konfiguration.
Warum dies für Agenten-Tooling von Bedeutung ist
Bei Codierungs-Agenten zeigt sich diese Aufteilung der Protokolle besonders deutlich: Claude Code setzt auf Anthropic Messages, Codex nutzt OpenAI Responses; zudem haben zahlreiche weitere Tools – etwa LangChain, die meisten Chat-UIs sowie SDKs – Chat Completions als Standard gewählt. Wer ein lokales Modell betreibt und mehrere dieser Werkzeuge nutzen möchte, muss entweder sicherstellen, dass jedes Tool das Format des Backends unterstützt, oder eigene Adapter implementieren. Mit Tokios entfällt dieses Problem: Man registriert die Deployment lediglich einmal, woraufhin alle unterstützten Client-Formate auf denselben Backend-Aufruf verweisen. Der Wechsel des lokalen Modells erfordert keinerlei Anpassungen an der Client-Konfiguration, da sowohl die Übersetzung als auch die Zuordnung der Deployment im Gateway erfolgen – nicht in der Konfigurationsdatei des Agenten. Die vollständige Liste der derzeit kompatiblen Clients finden Sie unter Verknüpfen Sie beliebige OpenAI- oder Anthropic-kompatible Clients mit Tokios.Schnellstart
Verknüpfen Sie den Connector und senden Sie innerhalb weniger Minuten Ihre erste Anfrage.
Wie Tokios Anfragen routet
Erfahren Sie mehr über den gesamten Ablauf einer Anfrage – vom Client über das Gateway bis hin zum Connector und schließlich zum Modell.
Kompatible Clients
Entdecken Sie, welche Basis-URL sowie welches API-Interface Ihr Client benötigt.
Claude Code in Kombination mit Tokios nutzen
Legen Sie ANTHROPIC_BASE_URL fest und leiten Sie Claude Code-Anfragen anschließend an Ihr Modell weiter.