Skip to main content
Your local model server almost certainly speaks one dialect: OpenAI Chat Completions. Ollama, llama.cpp, vLLM, and LM Studio all expose /v1/chat/completions. But the clients you actually want to point at that model don’t all speak that dialect. Claude Code speaks Anthropic Messages. OpenAI Codex speaks OpenAI Responses. Neither of those is Chat Completions, and neither one is going to change to accommodate your backend. Tokios closes that gap at the gateway, before any request reaches your machine — so the same deployment answers Claude Code, Codex, and a plain OpenAI SDK call without you running three servers or hand-rolling a translation layer yourself.
Claude Code (Anthropic Messages), OpenAI Codex (Responses), and an OpenAI SDK (Chat Completions) all send requests into the Tokios gateway, which translates every format to Chat Completions and forwards to one local model.

Three client dialects converge on the gateway, which translates them all to Chat Completions for one local model.

The mismatch

Three wire formats show up at api.tokios.com, and only one of them is what your backend understands: Ollama, llama.cpp, vLLM, and LM Studio only implement the third one. If Tokios simply forwarded bytes down the tunnel unchanged, Claude Code and Codex requests would arrive at your local server in a shape it doesn’t recognize and fail immediately.

Where the translation happens

Tokios converts the client’s request to OpenAI Chat Completions at the gateway — the public, cloud-side component at api.tokios.com — before anything travels down the tunnel to your machine. For the full request lifecycle, see How Tokios routes requests to your local models.
  • Anthropic Messages (POST /v1/messages, what Claude Code sends) is translated to Chat Completions.
  • OpenAI Responses (POST /v1/responses, what Codex sends) is translated to Chat Completions.
  • OpenAI Chat Completions (POST /v1/chat/completions) passes straight through — no translation needed.
Only the already-Chat-Completions-shaped request crosses the tunnel. tokios-connector never sees an Anthropic or Responses payload; it receives Chat Completions and forwards it verbatim to the BaseUrl you configured (for example, http://127.0.0.1:11434/v1 for Ollama). The connector doesn’t translate anything — it forwards. All the format-aware logic lives on the gateway side, once, for every deployment. That centralization is what makes the setup portable: your backend never has to implement Anthropic’s or OpenAI’s newer wire formats. It just has to keep doing what it already does.
Tool/function-calling fields are passed through during translation, but whether the underlying model actually honors them depends on the model itself — translation changes the envelope, not the model’s capabilities.

The same deployment, reached two ways

Say you’ve registered a deployment named gemma-tunnel pointing at a local model. Here’s that one deployment answering both an Anthropic-style client and an OpenAI-style client, with no change on the backend.

Claude Code (Anthropic Messages)

Claude Code talks Anthropic Messages, so it uses the root base URL — no /v1:
Claude Code’s model picker only lists claude* ids, so gemma-tunnel won’t show up in it — pass --model explicitly, as above. See Use Claude Code with your own local models via Tokios for the full setup.

OpenAI SDK (Chat Completions)

An OpenAI-style client uses the /v1 base URL:
Both requests name the same model: the public deployment name (gemma-tunnel), not whatever id your local runtime uses internally. Both end up, after translation where needed, as a single Chat Completions call forwarded down the same tunnel to the same local model. The model has no idea which protocol the client on the other end started with. OpenAI Codex follows the same pattern through the Responses API — see Use OpenAI Codex with your own local models via Tokios for the config.toml setup.

Why this matters for agent tooling

Coding agents are exactly where this protocol split shows up in practice: Claude Code standardized on Anthropic Messages, Codex standardized on OpenAI Responses, and a large share of everything else — LangChain, most chat UIs, most SDKs — standardized on Chat Completions. If you run a local model and want to try it with more than one of these tools, you’d otherwise need each tool to either support your backend’s format natively or run its own adapter. Tokios makes that a non-issue: register the deployment once, and every supported client format resolves to the same backend call. Swapping which local model answers a deployment doesn’t require touching any client configuration, because the translation step and the deployment lookup both live at the gateway — not in your agent’s config file. For the complete list of clients that work today, see Connect any OpenAI- or Anthropic-compatible client to Tokios.

Quickstart

Pair the connector and make your first request in a few minutes.

How Tokios routes requests

See the full request lifecycle, from client to gateway to connector to model.

Compatible clients

Check which base URL and API surface your client needs.

Use Claude Code with Tokios

Set ANTHROPIC_BASE_URL and start routing Claude Code to your model.