Open weights inside a closed harness

01The swap is a config file

DeepSeek publishes an official route into Codex. A one-command setup script writes a model catalogue to ~/.codex/models.json and adds a [model_providers.deepseek] block to ~/.codex/config.toml.¹ It backs up the existing configuration first and leaves MCP servers and project trust levels untouched. DeepSeek maintains this path itself.

It works because Codex talks to models over OpenAI's Responses API, and DeepSeek implemented Responses support in its own API to match.¹ The client is open source, the weights are open, and the protocol between them is documented well enough for a third party to implement.

The limits of that implementation are stated on DeepSeek's pricing page.

The Responses API currently only supports deepseek-v4-flash, and does not yet support deepseek-v4-pro.

02Only the cheaper model is reachable

DeepSeek serves two models: deepseek-v4-flash at $0.14 per million input tokens and $0.28 output, and deepseek-v4-pro — described in DeepSeek's own catalogue as its "most capable frontier agentic coding model" — at $0.435 and $0.87.²

Responses works on Flash. It does not work on Pro. DeepSeek's page says support for Pro is coming "in early August 2026"; read on 9 August, it still says it is coming.²

Codex has meanwhile narrowed what a third party may speak. A maintainer, replying on an open issue this summer, states the position: custom providers are Responses-only, wire_api = "chat" is rejected, and streaming goes through /v1/responses.³ Chat Completions — the format most OpenAI-compatible backends use internally — is being removed as an option for custom providers.

So the practical choice on Codex today is not between an open frontier model and a closed one. It is between a closed frontier model and the smaller open model, because the larger open model cannot yet speak the protocol the harness accepts.

03The price gap, and the token count that decides the bill

Flash against GPT-5.6 Sol is 36× cheaper on input and 107× on output.

Per-token price is one half of a bill. The other half is how many tokens the loop burns, which depends on the harness, the task and the individual run rather than on the model alone.

Microsoft Research published a production-scale measurement of that in July: sampled GitHub Copilot traces from June 2026, covering 3.2 million users, 13 million sessions, 761 million model calls and 95 trillion tokens.⁴ Two findings bear on this. Each user turn unfolds into an autonomous loop in which model calls are coupled nearly one-to-one with tool executions, so the token count is set by how many times the agent goes round. And cache hit rates average 90% within a turn but fall to 55% across turn boundaries, and are "drastically invalidated after events like model switches or context compaction".⁴

Both figures matter to anyone switching providers. DeepSeek charges $0.0028 per million on a cache hit against $0.14 on a miss, a factor of fifty,² so the cheap input rate is largely a cached rate — and a model switch is named as one of the events that invalidates the cache.

04Three failures at the compatibility boundary

Six open issues on the Codex tracker describe failures specific to non-OpenAI providers. Three are worth describing precisely, because each has a different symptom.

The MCP wrapper. When Codex talks to a custom provider over Responses, it sends tools from MCP servers wrapped in a Responses extension of its own — {"type":"namespace","name":"mcp__<server>__","tools":[…]}.⁵ ChatGPT's own websocket backend unwraps this server-side. Other backends drop or reject a tool whose type is not function: llama.cpp skips it, LM Studio returns an invalid_request_error, DeepSeek behind a proxy returns plain text with no function call.⁵

DeepSeek's own setup script. It writes a catalogue entry with "supports_search_tool": true and "tool_mode": null. On Codex 0.145.0 and 0.146.0 that combination registers every MCP tool as deferred behind a tool-search mechanism DeepSeek's model does not call. Web search still works and MCP resources still list; the tools themselves are absent, and the model reports that it has no such tool.⁶ A second developer reproduced this independently on Windows 11; a third reported the same failure reaching Codex's own multi-agent tools, and concluded that tool discovery is broken for this model generally rather than for MCP alone.⁶ The fix is one boolean in a file the vendor's script wrote for you, and you find it by reading a stranger's issue on someone else's tracker.

Reasoning replay. DeepSeek's thinking mode requires every assistant message in the history to carry back its reasoning_content field. Codex holds that content internally but does not serialise it into the outbound message, so the second turn of a tool-using conversation returns 400 Bad Request with the message that the field "must be passed back to the API".³ The working answers offered in this thread and in the MCP thread are both a local compatibility gateway posted by the developer who maintains it, who discloses as much. Neither is a fix, and both authors say so.

The MCP tools never reach the model. The user sees "no MCP tools" with no error from either side.

05Two of the three return no error

The MCP tools are absent rather than refused. The deferred-tool bug produces a model that truthfully reports having no such tool. Only reasoning replay throws a clean 400, and that is the failure people fix fastest.

The likely mechanism from there is straightforward, and it is a mechanism rather than a measurement. An agent that cannot call the tool it needs does not stop; it works around the absence, reading a file some other way and repeating the attempt. Each lap is billed, and the Copilot traces show why laps compound: one model call per tool execution, with cache validity falling at turn boundaries.⁴

This is where a hundredfold discount can begin to disappear — not into a worse answer, but into more laps at a cache-miss rate, with nothing in the log recording that the run was degraded from the first request. How much of the discount survives on a real repository has not been measured here, and we found no published measurement of it.

06Why Claude Code and Aider avoid this particular compatibility boundary

Claude Code takes an environment variable. DeepSeek serves an Anthropic-shaped endpoint at api.deepseek.com/anthropic; you point ANTHROPIC_BASE_URL at it and the client speaks the protocol it already spoke.⁷ Aider was built on a provider abstraction, and aider --model deepseek/deepseek-chat is a documented path.⁸

Neither project is currently migrating its third-party surface. Codex is moving that surface onto an API whose extensions — the namespace wrapper, reasoning-item semantics, the tool-mode catalogue — are defined by the organisation that also owns the first-party backend, and are implemented completely in one place. That asymmetry is a plausible explanation for why these failures cluster on Codex, though we have not compared issue rates across harnesses to establish it.

None of this says that Claude Code or Aider run open-weights models well in general. It says only that the two integrations above avoid this specific boundary, because in both cases the client's existing protocol is the one the provider implements.