/v1/chat/completions. Toutefois, les clients que vous souhaitez connecter à ce modèle n’utilisent pas tous ce dialecte. Claude Code emploie les Messages d’Anthropic, tandis qu’OpenAI Codex utilise les Responses d’OpenAI. Aucun de ces formats ne correspond aux Chat Completions, et aucun ne sera modifié pour s’adapter à votre infrastructure.
Tokios comble cette lacune au niveau du passerelle, avant même que les requêtes n’atteignent votre machine. Ainsi, un même déploiement peut répondre à Claude Code, Codex ainsi qu’à un appel effectué via le SDK OpenAI, sans que vous ayez à lancer trois serveurs ou à concevoir vous-même une couche de traduction.
Trois dialectes clients convergent vers le passerelle, qui les traduit tous en Chat Completions pour un modèle local unique.
Le déséquilibre entre formats
Trois formats de transmission apparaissent àapi.tokios.com, mais seul l’un d’eux est reconnu par votre infrastructure :
Ollama, llama.cpp, vLLM et LM Studio ne prennent en charge que le troisième format. Si Tokios se contentait de transmettre les octets sans modification, les requêtes provenant de Claude Code et de Codex arriveraient sur votre serveur local sous une forme inconnue, entraînant un échec immédiat.
Endroit où se produit la traduction
Tokios convertit la requête du client en format OpenAI Chat Completions au niveau du portail — cette composante publique située dans le cloud à l’adresseapi.tokios.com — avant que quoi que ce soit ne soit acheminé vers votre machine via le tunnel. Pour en savoir plus sur le déroulement complet d’une requête, consultez Comment Tokios oriente les requêtes vers vos modèles locaux.
- Anthropic Messages (
POST /v1/messages, format utilisé par Claude Code) est traduit en Chat Completions. - OpenAI Responses (
POST /v1/responses, format utilisé par Codex) est également traduit en Chat Completions. - OpenAI Chat Completions (
POST /v1/chat/completions) est transmis tel quel — aucune traduction n’est nécessaire.
tokios-connector ne reçoit jamais de payloads provenant d’Anthropic ou de l’API Responses ; il reçoit uniquement des requêtes Chat Completions et les transmet telles quelles au BaseUrl que vous avez configuré (par exemple, http://127.0.0.1:11434/v1 pour Ollama). Le connecteur ne traduit rien, il se contente de transférer les données. Toute la logique liée au format se trouve du côté du gateway, et ce pour chaque déploiement.
Cette centralisation est ce qui rend la configuration portable : votre backend n’a jamais besoin d’implémenter les nouveaux formats de données d’Anthropic ou d’OpenAI. Il lui suffit de continuer à fonctionner comme il le fait déjà.
Les champs relatifs aux outils ou aux appels de fonctions sont transmis lors de la traduction, mais le fait que le modèle sous-jacent les prenne en compte dépend du modèle lui-même. La traduction modifie uniquement l’enveloppe des données, pas les capacités du modèle.
Le même déploiement, accessible par deux voies différentes
Supposons que vous ayez enregistré un déploiement nommégemma-tunnel pointant vers un modèle local. Ce même déploiement répond aussi bien à un client utilisant le format Anthropic qu’à un client OpenAI, sans aucune modification côté backend.
Claude Code (Messages d’Anthropic)
Claude Code communique via les Messages d’Anthropic, c’est pourquoi il utilise l’URL de base racine — sans mention de/v1 :
claude*, donc gemma-tunnel n’apparaît pas dans cette liste. Il faut donc indiquer --model explicitement, comme indiqué ci-dessus. Consultez Utiliser Claude Code avec vos propres modèles locaux via Tokios pour la configuration complète.
SDK OpenAI (Chat Completions)
Un client OpenAI utilise l’URL de base/v1 :
model : le nom public du déploiement (gemma-tunnel), et non l’identifiant interne utilisé par votre runtime local. Après traduction si nécessaire, elles aboutissent toutes deux à un unique appel Chat Completions transmis via le même tunnel vers le même modèle local. Le modèle ignore totalement quel protocole le client a utilisé au départ.
OpenAI Codex suit le même schéma via l’API Responses — consultez Utiliser OpenAI Codex avec vos propres modèles locaux via Tokios pour la configuration config.toml.
Pourquoi cela revêt une importance pour les outils d’agents
Les agents de codage illustrent parfaitement cette divergence de protocoles : Claude Code s’appuie sur le format Messages d’Anthropic, Codex sur le format Responses d’OpenAI, tandis qu’une grande partie des autres solutions — LangChain, la plupart des interfaces de chat et des SDK — utilisent le format Chat Completions. Si vous exécutez un modèle local et souhaitez l’utiliser avec plusieurs de ces outils, il faudrait que chacun supporte nativement le format de votre backend ou qu’il dispose de son propre adaptateur. Tokios simplifie grandement cette situation : il suffit d’enregistrer un seul déploiement, et tous les formats clients pris en charge renvoient à un même appel backend. Pour changer de modèle local associé à un déploiement, il n’est pas nécessaire de modifier la configuration client, car l’étape de traduction et la recherche du déploiement se déroulent au niveau du gateway, et non dans le fichier de configuration de l’agent. Pour consulter la liste complète des clients actuellement compatibles, rendez-vous sur Connect any OpenAI- or Anthropic-compatible client to Tokios.Guide de démarrage rapide
Associez le connecteur et effectuez votre première requête en quelques minutes seulement.
Mécanisme de routage des requêtes dans Tokios
Découvrez l’intégralité du cycle de vie d’une requête, du client au gateway, puis au connecteur et enfin au modèle.
Clients compatibles
Vérifiez quelle URL de base et quelle interface API votre client requiert.
Utiliser Claude Code avec Tokios
Définissez la valeur ANTHROPIC_BASE_URL afin de rediriger les requêtes de Claude Code vers votre modèle.