Tokios 的工作原理：您的模型、您的硬件，仅需一个端点即可运作

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.

​

Tokios 填补的空白

云端 AI 网关在将流量路由至各类托管式服务提供商方面表现优异，比如 OpenAI、Anthropic 以及 Azure。不过它们无法访问部署在 localhost 上或位于私有虚拟私有云内的模型，因为缺乏可供连接的公开可路由地址。 Tokios 正是为填补这一空白而设计的。与其试图从外部访问您的机器，Tokios 换了一个思路：让您的机器主动连接 Tokios。云端端点始终稳定且公开；而其背后的模型始终私有且运行在本地。您无需改动防火墙、路由器或 DNS，即可获得完全可用的 API 接口。

​

仅限出站的连接架构

以下是各组件在静止状态下（即没有任何请求时）的相互关系： 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.

​

当编程智能体发起 API 调用时，具体处理步骤如下：

当编码代理发起一次 API 调用时，具体会发生以下情况： 操作步骤如下：

1. 客户端发送请求至 https://api.tokios.com/v1/chat/completions（或者 /v1/messages、/v1/responses），并在请求头中附带 Authorization: Bearer sk-tok-... 字段。
2. Tokios 会验证 API 密钥并定位对应的部署环境。网关会依据您的租户信息校验 sk-tok-... 令牌的有效性，确认该密钥处于启用状态后，再依据 model 字段指定的名称查找对应部署（例如 gemma-tunnel），随后将其替换为该部署所使用的上游模型 ID（例如 gemma4:e4b）。
3. 网关完成协议转换后通过连接器发送请求。若客户端发送的是 Anthropic Messages 或 OpenAI Responses 格式的请求，网关会先将其转换为 OpenAI Chat Completions 格式（详见下文），再通过该部署对应的连接器所维护的 WebSocket 通道转发至后端。
4. 该连接器会将请求转发至您本地的模型。 tokios-connector 负责接收来自隧道的聊天补全请求，随后向您所配置的 BaseUrl 发起标准的 HTTP 调用，比如针对 Ollama 时就是调用 http://127.0.0.1:11434/v1。从本地模型的角度来看，这完全就是一次普通的本地请求而已。
5. 响应数据也会沿原路径返回。本地模型生成的响应内容——包括您所要求的 "stream": true 令牌信息——会经由通道传回 Tokios 网关，再由网关转发给等待响应的客户端。从整体流程来看，这一往返过程与普通的 HTTP API 调用并无二致。

​

协议转换机制

编程代理所使用的 API 格式与本地模型所需的格式无需保持一致；所有转换操作均在 网关 层面完成，且不会影响本地机器。Tokios 会将客户端的请求格式转换为 OpenAI Chat Completions 格式后再通过通道发送；连接器仅负责将其转发至本地服务器上的 /v1/chat/completions 接口即可。

• Anthropic Messages 格式的请求（/v1/messages，即 Claude Code 所使用的格式）会被转换为 Chat Completions 格式。
• OpenAI Responses 格式的请求（/v1/responses，即 Codex 所使用的格式）同样会被转换为 Chat Completions 格式。
• OpenAI Chat Completions (/v1/chat/completions) 可直接通过。

正因如此，您的后端仅需支持 OpenAI Chat Completions 格式即可——Ollama、llama.cpp、vLLM 以及 LM Studio 均具备该能力。连接器本身并不执行转换操作，仅负责转发。由于所有协议转换工作均由网关集中处理，您即便更换部署所使用的模型，也无需调整编程代理端的任何配置。

​

安全性

由于该架构仅支持出站连接且以租户为隔离单位，其攻击面在设计层面便被降至最低：

• 您的机器上不会开放任何入站端口。远程攻击者无从探测或连接至您的设备。
• 所有模型均保留在本地主机。默认情况下该连接器仅向环回地址转发请求（127.0.0.1）；若要访问局域网内的模型则需手动启用相应设置。您的模型绝不会暴露于互联网。
• 传输过程中的提示词与响应内容均经过加密。连接器与 api.tokios.com 之间的所有通信均通过基于 TLS 加密的 WebSocket 协议完成（wss://）。数据绝不会以明文形式在公网传输。
• 基于租户的 API 密钥有效限制风险扩散范围。每个 sk-tok-... 密钥均绑定至特定租户及其注册的部署实例。即便密钥泄露，攻击者亦无法访问其他客户的模型或基础设施。
• 默认状态下无任何数据留存。系统仅记录令牌使用量、延迟数据及标识符信息，绝不会保存响应内容；请求正文仅在工作区管理员启用 请求日志 功能时才会被存储（该数据经过加密处理，附件内容会被剥离且敏感信息亦经脱敏，最终于 7 日后自动删除）。

您的模型，您的硬件，一个统一的接入端点。