Fonctionnement de Tokios : vos modèles, votre matériel, un seul point de terminaison

Most networking problems with local models come down to direction: cloud clients want to send traffic in, but home networks, firewalls, and corporate VPNs block inbound connections by default. Tokios solves this by flipping the direction entirely. The tokios-connector dials out to Tokios once on startup and keeps that connection alive. Nothing on your side ever listens for an inbound connection — which means nothing on your side ever needs to be opened up. Connect a model, point a client at api.tokios.com, and your local hardware does the work.

​

Le rôle de Tokios

Les passerelles d’IA cloud assurent efficacement le routage vers des fournisseurs hébergés tels qu’OpenAI, Anthropic ou Azure. Elles ne peuvent toutefois pas atteindre un modèle situé sur localhost ou dans un VPC privé, faute d’adresse publiquement accessible. Tokios a été conçu spécifiquement pour combler ce vide. Plutôt que d’essayer de joindre votre machine depuis l’extérieur, Tokios inversé la dynamique : c’est votre machine qui contacte Tokios. Le point d’accès cloud demeure stable et public, tandis que le modèle reste strictement privé et local. Vous bénéficiez ainsi d’une interface API pleinement fonctionnelle sans avoir à modifier votre pare-feu, votre routeur ou votre DNS.

​

Architecture unidirectionnelle

Voici comment les composants interagissent en l’absence de requête : The one connection your machine opens is the connector’s outbound WebSocket (the thick arrow). Every request rides back down that same tunnel (the dotted arrow) — nothing ever connects in. The connector maintains a persistent outbound WebSocket to the Tokios gateway. Claude Code, OpenAI Codex, or any other API client sends its request to api.tokios.com from anywhere on the internet — the Tokios gateway holds that inbound connection and pushes the request down the existing WebSocket to the connector, which forwards it to your local model. Your model never needs to be reachable from the outside world.

​

Flux des requêtes

Lorsqu’un agent de codage lance une requête API, voici le déroulement exact : Étapes à suivre :

1. Le client envoie une requête à https://api.tokios.com/v1/chat/completions (ou à /v1/messages, /v1/responses) en incluant l’en-tête Authorization: Bearer sk-tok-....
2. Tokios authentifie la clé API et localise le déploiement correspondant. Le passerelle valide le token sk-tok-... en le comparant à vos informations d’identification, s’assure que la clé est active, recherche le déploiement mentionné dans le champ model (par exemple gemma-tunnel), puis le remplace par l’ID de modèle amont associé (par exemple gemma4:e4b).
3. Le passerelle traduit et transmet la requête via le tunnel. Si le client a utilisé le format Anthropic Messages ou OpenAI Responses, le passerelle le convertit d’abord en format OpenAI Chat Completions (voir ci-dessous), puis l’envoie par le biais du WebSocket ouvert géré par le connecteur du déploiement concerné.
4. Le connecteur transmet la requête à votre modèle local. tokios-connector reçoit la requête Chat Completions provenant du tunnel et effectue un appel HTTP standard vers l’adresse BaseUrl que vous avez configurée — par exemple http://127.0.0.1:11434/v1 pour Ollama. Du point de vue du modèle local, il s’agit simplement d’une requête classique.
5. La réponse est renvoyée. La réponse générée par le modèle local — y compris les jetons transmis en continu si vous avez activé cette option sur "stream": true — remonte le tunnel jusqu’au passerelle Tokios, qui la transmet au client en attente. Globalement, ce processus ressemble à un appel API HTTP classique.

​

Traduction de protocoles

Le format API utilisé par votre agent de codage et celui requis par votre modèle ne doivent pas nécessairement coïncider ; la traduction s’effectue au niveau du passerelle, avant que quoi que ce soit n’atteigne votre machine. Tokios convertit le format du client en format OpenAI Chat Completions et l’envoie dans le tunnel ; le connecteur se contente de le transmettre à l’adresse /v1/chat/completions de votre serveur local.

• Anthropic Messages (/v1/messages, le format employé par Claude Code) est traduit en Chat Completions.
• OpenAI Responses (/v1/responses, le format utilisé par Codex) est également traduit en Chat Completions.
• OpenAI Chat Completions (/v1/chat/completions) est transmis tel quel.

C’est pourquoi votre backend n’a besoin de supporter que le format OpenAI Chat Completions : Ollama, llama.cpp, vLLM et LM Studio le font déjà. Le connecteur ne réalise aucune traduction ; il se contente de relayer les données. Grâce à la centralisation de la traduction au niveau du passerelle, vous pouvez changer de modèle associé à un déploiement sans modifier la configuration de votre agent.

​

Sécurité

Comme l’architecture ne permet que des connexions sortantes et est limitée à chaque locataire, la surface d’attaque est volontairement réduite :

• Aucun port entrant n’est ouvert sur votre machine. Il n’y a donc rien qu’un attaquant distant puisse sonder ou contacter.
• Vos modèles restent sur localhost. Par défaut, le connecteur envoie les requêtes uniquement vers la boucle de retour (127.0.0.1) ; pour accéder à un modèle sur votre réseau local, il faut activer cette option explicitement. Vos modèles ne sont jamais exposés à Internet.
• Les invites et les réponses sont chiffrées en transit. Tout le trafic entre le connecteur et api.tokios.com transite via un WebSocket sécurisé par TLS (wss://). Aucune donnée ne circule en clair sur Internet.
• Les clés API limitées à chaque locataire restreignent les risques. Chaque clé sk-tok-... s’applique uniquement à votre locataire et aux déploiements que vous avez enregistrés. Une clé compromise ne permet pas d’accéder aux modèles ou à l’infrastructure d’autres clients.
• Rien n’est stocké par défaut. Les données enregistrées concernent le nombre de jetons, la latence, l’état et les identifiants — jamais le contenu des réponses. Les corps de requête ne sont conservés que si un administrateur d’espace de travail active l’enregistrement des requêtes ; ces données sont chiffrées, les pièces jointes supprimées, les informations sensibles masquées, puis effacées après 7 jours.

Vos modèles. Votre matériel. Un seul point d’accès.