So funktioniert Tokios: Ihre Modelle, Ihre Hardware, ein Endpunkt

Die meisten Netzwerkprobleme bei lokalen Modellen hängen von der Richtung ab: Cloud-Clients möchten Daten hineinsenden, doch Heimnetzwerke, Firewalls sowie Unternehmens-VPNs blockieren standardmäßig eingehende Verbindungen. Tokios wendet diese Richtung komplett um. Der tokios-connector stellt beim Start eine Verbindung nach außen zu Tokios her und hält sie aufrecht. Auf Ihrer Seite wird niemals auf eingehende Verbindungen gewartet – folglich müssen Sie nichts freigeben. Verknüpfen Sie ein Modell, richten Sie einen Client auf api.tokios.com aus, und Ihre lokale Hardware übernimmt den Rest.

​

Welche Lücke Tokios schließt

Cloud-AI-Gateways leiten Anfragen hervorragend an gehostete Anbieter wie OpenAI, Anthropic oder Azure weiter. Doch sie können keine Verbindung zu Modellen auf localhost oder innerhalb einer privaten VPC herstellen, da es dort keine öffentlich erreichbaren Adressen gibt. Tokios wurde speziell für diese Lücke entwickelt. Anstatt von außen auf Ihren Rechner zuzugreifen, dreht Tokios das Verhältnis um: Ihr Rechner kontaktiert Tokios. Der Cloud-Endpunkt bleibt stets stabil und öffentlich zugänglich; das dahinterliegende Modell bleibt privat und lokal. So erhalten Sie eine vollständig nutzbare API-Schnittstelle, ohne Firewall, Router oder DNS anpassen zu müssen.

​

Architektur mit ausschließlich ausgehender Kommunikation

So stehen die Komponenten zueinander, wenn keine Anfragen vorliegen: Die einzige Verbindung, die Ihr System herstellt, ist der ausgehende WebSocket-Connector (der dicke Pfeil). Jede Anfrage wird anschließend über denselben Tunnel zurückgesendet (der gestrichelte Pfeil); es kommt niemals eine Verbindung hinein. Der Connector hält stets eine ausgehende WebSocket-Verbindung zum Tokios-Gateway aufrecht. Claude Code, OpenAI Codex sowie sämtliche anderen API-Clients senden ihre Anfragen an api.tokios.com von überall im Internet aus; das Tokios-Gateway verwaltet diese eingehenden Verbindungen und leitet die Anfragen über den bestehenden WebSocket an den Connector weiter, der sie schließlich an Ihr lokales Modell übergibt. Ihr Modell muss dabei niemals von außen erreichbar sein.

​

Ablauf der Anfragen

Sobald ein Coding-Agent eine API-Anfrage startet, geschieht Folgendes: Schritt für Schritt:

1. Der Client sendet eine Anfrage an https://api.tokios.com/v1/chat/completions (oder auch /v1/messages bzw. /v1/responses) und fügt dabei den Header Authorization: Bearer sk-tok-... hinzu.
2. Tokios prüft den API-Schlüssel und ermittelt die zugehörige Deployment. Das Gateway verifiziert das Token sk-tok-... anhand Ihres Tenants, stellt sicher, dass der Schlüssel aktiv ist, sucht nach der unter model angegebenen Deployment (z. B. gemma-tunnel) und ersetzt sie durch die entsprechende Upstream-Modell-ID (z. B. gemma4:e4b).
3. Das Gateway übersetzt die Anfrage und leitet sie durch den Tunnel. Falls der Client Daten im Format von Anthropic Messages oder OpenAI Responses gesendet hat, wandelt das Gateway diese zunächst in das Format von OpenAI Chat Completions um (siehe unten) und leitet sie anschließend über den WebSocket-Connector an die gewünschte Deployment weiter.
4. Der Connector leitet die Anfrage an Ihr lokales Modell weiter. tokios-connector empfängt die Chat-Completions-Anfrage und sendet eine reguläre HTTP-Anfrage an das von Ihnen konfigurierte Modell unter BaseUrl – beispielsweise http://127.0.0.1:11434/v1 bei Ollama. Aus Sicht des lokalen Modells handelt es sich dabei um eine ganz gewöhnliche Anfrage.
5. Die Antwort wird gestreamt zurückgesendet. Die Antwort des lokalen Modells – einschließlich der gestreamten Token, falls Sie "stream": true angefordert haben – gelangt über den Tunnel zurück zum Tokios-Gateway, welches sie anschließend an den wartenden Client weiterleitet. Insgesamt verhält sich dieser Rundlauf wie ein gewöhnlicher HTTP-API-Aufruf.

​

Protokollübersetzung

Das Format der API Ihres Coding Agents muss nicht mit dem Ihres Modells übereinstimmen – die Übersetzung erfolgt im Gateway, noch bevor die Daten Ihren Rechner erreichen. Tokios wandelt das Format des Clients in OpenAI Chat Completions um und leitet es durch den Tunnel; der Connector übermittelt es lediglich an Ihren lokalen Server unter /v1/chat/completions.

• Anthropic Messages (/v1/messages, das Format, das Claude Code verwendet) wird in Chat Completions umgewandelt.
• OpenAI Responses (/v1/responses, das Format, das Codex nutzt) wird ebenfalls in Chat Completions übersetzt.
• OpenAI Chat Completions (/v1/chat/completions) werden ohne Veränderung weitergeleitet.

Aus diesem Grund muss Ihr Backend lediglich OpenAI Chat Completions verstehen – Ollama, llama.cpp, vLLM sowie LM Studio beherrschen dieses Format. Der Connector selbst übersetzt nichts, sondern leitet lediglich weiter. Da die Übersetzung zentral im Gateway erfolgt, können Sie das Modell hinter einer Deployment beliebig wechseln, ohne die Konfiguration Ihres Agents anpassen zu müssen.

​

Sicherheit

Da die Architektur ausschließlich ausgehende Verbindungen zulässt und pro Mandant arbeitet, ist die Angriffsfläche von vornherein minimal:

• Es werden keinerlei eingehende Ports geöffnet auf Ihrem Rechner. Ein entfernter Angreifer hat somit nichts, was er scannen oder ansteuern könnte.
• Ihre Modelle verbleiben auf dem lokalen Rechner. Standardmäßig leitet der Connector Daten nur an den Loopback-Adapter weiter (127.0.0.1); um ein Modell im lokalen Netzwerk zu nutzen, muss dies explizit aktiviert werden. Ihr Modell gelangt niemals ins Internet.
• Anfragen und Antworten werden während der Übertragung verschlüsselt. Der gesamte Datenverkehr zwischen dem Connector und api.tokios.com erfolgt über ein TLS-gesichertes WebSocket-Protokoll (wss://). Keine Informationen werden im Klartext über das offene Internet gesendet.
• Mandantbezogene API-Schlüssel begrenzen die Auswirkungen von Sicherheitsverletzungen. Jeder sk-tok-...-Schlüssel gilt ausschließlich für Ihren Mandanten sowie die von Ihnen registrierten Deployment-Instanzen. Ein kompromittierter Schlüssel ermöglicht keinen Zugriff auf Modelle oder Infrastrukturen anderer Kunden.
• Standardmäßig werden keine Daten gespeichert. Es werden lediglich Token-Zahlen, Latenzzeiten, Statusinformationen sowie Identifikatoren erfasst – niemals Antwortinhalte. Anfragetexte werden nur gespeichert, falls ein Workspace-Administrator die Funktion Anfragen-Protokollierung aktiviert; diese Daten sind verschlüsselt, Anhänge werden entfernt, sensible Informationen maskiert und nach 7 Tagen gelöscht.

Ihre Modelle. Ihre Hardware. Ein einziger Endpunkt.