Same DeepSeek-V4-Flash, Different Agent: Why Codex Feels Like a Different Model

This is a companion piece to “Model + Harness = Agent: The Gap Isn’t Where You Think”. That essay described an agent as two legs: the model supplies potential, while the harness carries it into real work. DeepSeek V4 Flash let me observe the relationship with the same backend model.

First, a plain-language definition: a harness is the model’s workbench — the agent runtime that decomposes a task, supplies tools, preserves context, verifies results, and retries or rolls back after failure. It is not optional packaging around the model; it is the execution system between the model and the world.

If the previous essay asked how a runtime turns model capability into work, the companion practice essay “How I Use DeepSeek V4 Flash: Reserve the Strongest Model for Uncertainty” asks which kind of model belongs in each phase.

The two essays stand alone. If you read them together, I suggest starting with the practice essay for the routing idea, then using this one to understand why a runtime can amplify or waste that division of labor.

Here is the thesis up front: the same backend model ID can realize very different capabilities on a long task when the protocol, tool contract, and recovery machinery change. The release background is kept short here. The real questions are: through which layers does the difference appear, how could we test the claim, and why might the harness create a product gap faster than model weights can?

First, see what the local sample actually supports

I will put the local facts first. They support a difference between two model–runtime pairings, not a claim that one product is universally better:

Sample	Observable fact	What it supports
Codex	A training deck grew from an outline to 40+ pages, with repeated overflow, navigation, overview, and geometry checks before convergence	This model–runtime pairing completed a long, cross-file, repeatedly verified task
Claude Code Flash	A separate task launched several read-only reviews and returned a consolidated report, but report quality was not independently verified	Claude Code is not incapable of substantial work; this is not a comparable success-rate measurement

To make the first row concrete: for a task like “bring a 40-page deck to deliverable quality,” the workflow reads files, edits a page, opens a preview, finds overflow, and repairs it. That repeated loop — rather than a one-shot code generation — is what I observed locally.

This deck sample is not the same experiment as the group-chat game case in the companion practice essay.

The evidence supports a bounded conclusion: the Codex pairing completed a long, cross-file, repeatedly verified task. It does not support “Codex is always stronger.” What the sample supports is an interaction between model version × protocol × runtime × task shape.

How far do we need to calibrate “the same model”?

DeepSeek’s July 31 changelog calls the release DeepSeek-V4-Flash-0731 under the existing deepseek-v4-flash model ID. For this article, confirming the same backend ID is enough; the other conditions are precisely where the difference may arise:

Item	codex-ds	ccc-ds-flash
Client / route	Codex CLI 0.146.0 / Responses API	Claude Code 2.1.220 / Anthropic-compatible API
Backend model	deepseek-v4-flash	deepseek-v4-flash, explicitly pinned
Runtime	1M context, parallel tool calls, freeform patch, multi-agent v2	Claude Code’s system prompt, tool protocol, context policy, and subagent rules
Reasoning setup	high in config; max in the complex session	max effort, adaptive thinking disabled

I used ccc-ds-flash deliberately: plain ccc-ds keeps Pro as its primary model and maps Flash only to some slots. Effort semantics, client versions, tool schemas, compaction, permissions, and retry policy also differ. This is an auditable workflow comparison, not an experiment with every other condition held constant.

So the accurate description is not “V4 Flash is good in Codex and bad in Claude Code.” It is:

In my long-task sample, DeepSeek-V4-Flash-0731 showed stronger effective delivery through Responses + Codex than through Anthropic-compatible API + Claude Code.

Keep only three public background signals

To keep familiar background from taking over the argument, only three signals matter here:

1. The harness is a benchmark condition. DeepSeek’s changelog says public code-agent tasks used its own Harness minimal mode. Minimal means the smallest evaluation runtime, not no harness. The score therefore measures a combination of model, runtime, and inference setup.
2. V4 Flash was adapted for Codex. The official wording says it natively supports the Responses API and is specifically adapted for Codex; the Codex integration guide also writes a model catalog and tool capability declarations. The Anthropic-compatible route connects, but some fields are not fully passed through (see the compatibility guide).
3. DeepSeek started forming a first-party Code Harness team. Its researcher hiring post and role pages put Model + Harness = Agent into the mission and call for collaboration with model-training researchers. That proves a strategic and organizational bet, not a shipped or commercially successful product.

The common direction is not “DeepSeek already has a finished vehicle.” It is that DeepSeek treats the execution surface where its models are used as part of the model product.

How could those signals explain the experience?

The following is a mechanism hypothesis, not a causal decomposition proven by a one-person sample. My claim is not that the Responses API magically makes a model smarter. It is that the runtime determines what the model sees each turn, what actions it can take, whether it can recover, and what counts as done. On long tasks, those four decisions compound.

1. A protocol is a trajectory interface, not a transport layer

Every turn uses a working language: how the goal is represented, how tool results are returned, how intermediate state is continued, and which fields mean “keep acting.” A protocol therefore changes how the model interprets the current state, not merely how text travels from A to B.

If the model and the Responses structure were adapted together, the runtime may carry state along a familiar trajectory. A compatibility layer can still produce valid answers while remapping or ignoring fields, leaving long-horizon action with fewer handles. “May” matters: proving the exact loss would require raw request/response and tool traces, not inference from feel.

That hypothesis makes a testable prediction: with task, model, and tools fixed, a protocol change should first show up in ignored parameters, state reconstruction, recovery turns, and replanning — not only in final prose quality.

2. Tool contracts define the real action space

Read, edit, shell, and search are not four buttons; they are schemas, parameters, return formats, and failure signals. The model must translate judgment into that grammar. Identical tool names do not imply identical action spaces.

Model tuning often adapts to a tool contract and a trajectory distribution. A successful first request proves the circuit is connected, not that twenty turns will converge. Rename a parameter, turn a structured error into vague text, or replace a patch operation with free-form text, and the model can slide from executing back into describing.

So the question is not simply whether tools exist. It is whether the model knows their boundaries, whether failures are legible, whether results can be referenced directly on the next turn, and whether an error triggers an explicit repair path.

3. Context and recovery turn local intelligence into long-term work

Short questions need one good answer. Long tasks must preserve the goal, prohibitions, verified facts, unfinished branches, and acceptance conditions. Compaction that keeps only a summary is most likely to lose why a path was forbidden and which step was already verified.

That is why recovery matters more than one-shot planning. Can the harness detect drift from tool errors, failed tests, and workspace state, retain the evidence, roll back to a stable point, and ask the model to replan? In this Codex session I saw a loop of read, edit, preview, discover, repair, and re-check — not a one-shot code dump.

If this layer is the main difference, the long-task curves should start similarly and diverge as turns accumulate: more recovery, repeated work, and contradictory context, rather than completely different answers from the first request.

4. Acceptance rules define what “done” means

When a model says “done,” it has produced a coherent account. For an agent, done should mean that files exist, tests pass, a page has no overflow, permissions were respected, or an external state really changed. Without independent acceptance, a runtime mistakes “looks complete” for “is delivered.”

That is why I count acceptance gates as part of the harness. A good gate does not replace the model’s judgment; it connects that judgment to evidence in the world, blocks unverified conclusions, and turns failure into usable input for the next turn.

Turn “capability realization” into a testable hypothesis

The previous essay used:

Model + Harness = Agent

The companion concept model is:

Effective Agent = Model potential × Harness realization rate

Realization rate is not a single existing metric. It is an engineering variable that can be decomposed into observable dimensions:

Dimension	What to record	Failure signature
Protocol fit	Parameter pass-through, state continuation, reasoning setup	Ignored fields, rebuilt state, interrupted action
Tool contract	Call success, error types, result reusability	Repeated bad arguments, unusable tool output
Context and recovery	Constraints before/after compaction, rollback points, retries	Rework, goal drift, errors compounding
Acceptance and evidence	Tests, previews, file state, human takeover	“Done” with no verifiable artifact

“A better harness” then becomes an engineering hypothesis that can be audited one row at a time.

Recent work is also beginning to treat the harness as an evaluation axis. Harness-Bench and Co-Harness both treat model–runtime pairings and failure traces as research objects. They are external preprints, not DeepSeek experiments: they show a research direction, but they do not supply causal evidence for this local observation.

What would falsify this claim?

I do not want “harness” to become a word that explains everything. If client version, effort, permissions, tool schemas, context, and acceptance can genuinely be aligned and the gap largely disappears, then this observation was mainly configuration confounding. If the gap remains across tasks, repetitions, and raw traces, with the difference consistently landing in state continuation, recovery, and acceptance, the harness explanation becomes stronger.

The next step is therefore not another prettier slogan. It is to collect raw requests/responses, tool traces, failure classes, and human takeover points from both runtimes. Knowing which turn created the gap is more valuable than declaring that one model is smarter.

Why the harness may be the thicker leg in the short term

“Thicker” here means near-term user value and iteration speed for a particular task window. It does not mean the harness replaces the model or raises its knowledge and judgment ceiling. The claim is most plausible when the model has crossed the task-capability threshold, the work is long and tool-heavy, and the main failures are runtime failures.

The task shape roughly changes the bottleneck:

Task shape	More likely bottleneck	Why
Short Q&A or one-step generation	Model	Recovery and acceptance rarely have time to matter
Model below the task threshold	Model	Tools cannot replace missing knowledge and judgment
Long, tool-heavy work with delivery evidence	Harness	State, retries, permissions, and acceptance losses accumulate

In the third case, a harness can iterate faster than model weights:

1. It is closer to failure. It sees malformed calls, lost constraints, skipped tests, and rollback points.
2. A repair can be reused immediately. One change to a tool schema, retry policy, or acceptance gate affects later tasks.
3. It can form a feedback and cost loop. Unit-task cost is not just inference; it includes retries, waiting, wasted tokens, and human takeovers. A useful accounting identity is: cost of one accepted delivery = inference + tools/retries + human intervention + latency. Removing one of those costs makes the model feel more reliable immediately. With user authorization and privacy compliance, failure labels and verification traces may later inform training.

That is also where a product moat might emerge: default tools, permissions, memory, acceptance, and distribution raise switching costs; real-task traces and evaluation assets create feedback advantages. But general harnesses can be open-sourced and standardized, while model-specific harnesses can create lock-in. Durable advantage will depend on proprietary task data, reliability, enterprise integration, and evaluation assets — not prompt packaging alone.

For users: compare the complete configuration

The smallest useful experiment is practical: pin the same backend model ID, task, and code state; record client version, effort, permissions, and acceptance criteria; repeat each setup at least three times; then record delivery, rework time, tool errors, human intervention, and rollbacks. Classify each failure as protocol, tool, context, recovery, or acceptance when possible.

If those conditions cannot be fixed, call the result a runtime observation, not a model ranking. An agent result should be labeled with the full configuration:

deepseek-v4-flash × Responses × Codex × tool/context/recovery policy

That is closer to what the user actually buys than deepseek-v4-flash alone. The purchased object is not a model ID; it is a delivery chain from request to evidence.

For model vendors: ship the model–harness pairing

DeepSeek is already pointing in this direction: name the harness in benchmark conditions, provide native Codex adaptation and capability declarations, and build a first-party Code Harness team. The next useful step would be to publish the minimal harness’s tool contract, context policy, inference setup, and acceptance rules, so developers know which vehicle produced a score and third parties can reproduce or replace a layer.

The product battle will involve more than parameters, data, and compute. It will involve who sees real-task failures first, who repairs the runtime fastest, and who owns the distribution and feedback loop. The smallest meaningful release artifact may shift from “a checkpoint” to “a validated model–harness pairing.” That is an industry inference; DeepSeek’s public hiring currently proves strategic intent, not product success.

Closing: compare the complete agent, not the isolated model

DeepSeek V4 Flash pushes the observation one step further: the model stayed the same while the model–protocol–tools–context–recovery stack changed, and effective capability changed with it.

For my long-task sample, the Codex bridge looks more complete. The question worth pursuing is not “which model is smarter?” but whether the gap comes from protocol, action space, state recovery, or acceptance evidence.

This also loops back to the previous essay: in my earlier observation, Kimi K3 actually worked better inside Claude Code than inside Kimi’s own harness.

The model supplies potential; the harness determines how much becomes reliable work. When a new model ships, ask not only how many parameters it has, but which harness it is paired with, which vehicle produced the score, and who owns the failure traces.

---

Sources and further reading

Official

• DeepSeek API changelog: DeepSeek-V4-Flash-0731 (Harness minimal mode and Codex-specific adaptation)
• DeepSeek: Integrate with Codex (Responses API, model catalog, and runtime declarations)
• DeepSeek: Using the Anthropic API (model mapping and compatibility fields)
• DeepSeek V4 Preview Release (V4 Flash parameter scale)

Hiring and reporting

• Deli Chen: DeepSeek Code Harness hiring post
• DeepSeek / High-Flyer: Harness Product Manager and Harness R&D Engineer
• Jazzyear: DeepSeek is forming a Harness team
• Decrypt: DeepSeek Is Building Its Own Claude Code

Research (preprints)

• Harness-Bench
• Co-Harness
• Previous post: Model + Harness = Agent

Note: The Codex and Claude Code configurations and sessions are the author’s local snapshot from August 1, 2026. This is a personal workflow observation, not an independent benchmark. The public hiring evidence establishes team formation and strategic intent, not a released first-party DeepSeek harness.