DeepSeek Harness vs OpenCode: The Token Usage Gap Most Developers Miss

You picked a cheap model. You did the math on the model card. Then the bill came in and it did not look like your math at all.

That gap is almost never the model. It is the harness. The harness decides how many times your model gets called, how much of the conversation gets replayed on every single call, how big the tool schemas are, and whether a failed test run gets retried three times or twelve. Same model, same task, two harnesses, wildly different token counts.

On August 13, 2026, DeepSeek open sourced its own agent harness and the argument got loud fast. One side has a two week old repo from the lab that builds the model. The other side has OpenCode, the most starred coding agent on GitHub. Both are MIT. Both run whatever model you point them at.

So this is the honest version of the comparison. Not vibes, not stars. What each one actually does to your token usage, and how to measure it on your own repo in about fifteen minutes.

Key takeaways

• DeepSeek Harness is a plugin-first agent runtime from DeepSeek AI, MIT licensed, written in TypeScript, still labeled developer preview. Models, tools, sessions, storage, sandboxes, loops and even the agent loop itself are swappable plugins.
• OpenCode is a Go, terminal-native coding agent with roughly 198k GitHub stars, a mature TUI, LSP support and a large provider catalog. It is the safe default today.
• Harness choice moves token usage more than most people expect. In a 30 workflow benchmark on DeepSeek V4 Flash, the tested harnesses ranged from about 192,000 to 1,400,000 average tokens per task.
• DeepSeek Harness was not in that benchmark. It launched two days after it published, so anyone quoting Harness benchmark numbers right now is guessing.
• Both are model agnostic, so you can point both at one OpenAI compatible endpoint and run a genuine like for like test. That is the only number that matters for your codebase.

Two laptops side by side on a sunlit desk running the same coding task through two different agent harnesses

The only fair way to run DeepSeek Harness vs OpenCode: one model, one task, two terminals.

Why DeepSeek Harness vs OpenCode became the argument of the month

DeepSeek's framing is a slogan: Agent = Model + Harness. The model thinks, the harness reads files, runs the terminal and calls tools. For two years everyone optimized the first half and treated the second half as plumbing.

The plumbing turned out to be expensive.

Composio ran 30 complex multi-app workflows through 8 different agent harnesses, all driving the same DeepSeek V4 Flash model, with a 900 second cap per task and binary programmatic grading across 240 runs (Composio, August 2026). Same model everywhere. The results were not close.

Read the token column again. The most frugal harness used roughly one seventh the tokens of the most wasteful one, running the identical model on the identical tasks. The benchmark's own conclusion was that harnesses "can matter as much as the models they run."

Now the part most articles skip. DeepSeek Harness is not in that table. The benchmark published August 11 and the Harness landed August 13. There is no credible head to head token number for DeepSeek Harness yet, and anyone showing you one this month either ran it themselves on a narrow task or made it up. What the table does give you is a solid, sourced baseline for OpenCode: 692,000 tokens per task, 46.7% pass rate, 129.7 second median.

That is the number you are trying to beat, and the rest of this article is how to test it honestly.

DeepSeek Harness vs OpenCode: same model, one endpoint, two runtimes

Here is the practical shape of each tool before we run anything.

The important line is the architecture row. OpenCode gives you a well built agent and lets you extend the edges. DeepSeek Harness gives you a skeleton and lets you replace the spine, including the agent loop, which is itself a plugin. That is genuinely unusual, and it is also why it is still a preview.

Both are model agnostic, and that is the whole reason a fair test is possible. Point both at one OpenAI compatible endpoint serving one model and every difference you measure belongs to the harness.

For this walkthrough I am serving DeepSeek V4 Flash from Atlas Cloud, because it exposes a plain OpenAI compatible endpoint that both harnesses accept without any adapter code, and the same key works for both runs. The deepseek-v4-flash-0731 listing there is $0.14 per million input tokens and $0.28 per million output tokens, with a 1,048,576 token context window and 393,216 max output, as of August 2026. Any OpenAI compatible provider works for this test. The point is that both harnesses must hit the same one.

Worth knowing before you pick a model: OpenCode publishes its own aggregate usage data, and DeepSeek models have moved 233 trillion tokens through it, with V4 Flash accounting for 85.5% of that and V4 Pro the remaining 14.5% (OpenCode, August 2026). Flash is what the ecosystem actually runs on.

Step 1: Point DeepSeek Harness vs OpenCode at the same model

Get one API key and one base URL, then feed both tools the exact same pair. Create the key in the Atlas Cloud console and export it once:

bashCopy
1export ATLAS_API_KEY="your-api-key"
2

Before wiring up either harness, sanity check the endpoint and the exact model id with one call. If this does not return text, nothing downstream will work:

bashCopy
1curl https://api.atlascloud.ai/v1/chat/completions \
2  -H "Authorization: Bearer $ATLAS_API_KEY" \
3  -H "Content-Type: application/json" \
4  -d '{
5    "model": "deepseek-ai/deepseek-v4-flash-0731",
6    "messages": [{"role": "user", "content": "Reply with the single word: ready"}]
7  }'
8

It helps to see the model answer the real task once, straight through the endpoint, before you hand it to an agent. Then you know a failed run is the harness and not the route:

The article's task prompt posted to api.atlascloud.ai, next to the real answer DeepSeek V4 Flash 0731 returned and the token usage the call reported

One real call to deepseek-ai/deepseek-v4-flash-0731, the same model id both harnesses will use: 148 prompt tokens in, 6,879 output tokens back, 5,731 of them reasoning. That is your floor before a harness adds a single tool schema.

Now configure each side. DeepSeek Harness reads $DSH_HOME/settings.yaml, and custom OpenAI compatible providers go under the llm-pi-ai plugin (DeepSeek Harness docs, August 2026):

yamlCopy
1llm-pi-ai:
2  providers:
3    atlas:
4      apiKeyEnv: ATLAS_API_KEY
5      api: openai-completions
6      baseURL: https://api.atlascloud.ai/v1
7      models:
8        - id: deepseek-ai/deepseek-v4-flash-0731
9

The api field accepts openai-completions, openai-responses or anthropic-messages. Use openai-completions here. If you would rather not hand edit YAML, the web UI has Settings then Models then Add a custom provider, which writes the same block and stores the key in $DSH_HOME/.credentials.yaml instead.

OpenCode reads opencode.json in your project root or global config directory (OpenCode docs, August 2026):

jsonCopy
1{
2  "$schema": "https://opencode.ai/config.json",
3  "provider": {
4    "atlas": {
5      "npm": "@ai-sdk/openai-compatible",
6      "name": "Atlas Cloud",
7      "options": {
8        "baseURL": "https://api.atlascloud.ai/v1",
9        "apiKey": "{env:ATLAS_API_KEY}"
10      },
11      "models": {
12        "deepseek-ai/deepseek-v4-flash-0731": {
13          "name": "DeepSeek V4 Flash 0731",
14          "limit": { "context": 1048576, "output": 393216 }
15        }
16      }
17    }
18  },
19  "model": "atlas/deepseek-ai/deepseek-v4-flash-0731"
20}
21

Use @ai-sdk/openai-compatible, not @ai-sdk/openai, since this endpoint serves /v1/chat/completions. Set the limit values to the real context and output numbers, because OpenCode uses them to decide when to summarize, and a wrong limit will skew your token comparison badly.

Step 2: Run the benchmark task in DeepSeek Harness

Pick one task that is big enough to need several tool calls and small enough to grade objectively. Multi file, plus a test suite that must actually pass. Use the same repo state for both runs, so commit or stash first.

This is the exact task prompt. Paste it verbatim into both harnesses:

textCopy
1In this repository, add a token-bucket rate limiter middleware for the Express
2app in src/server.js. Limit each IP to 60 requests per minute. On rejection,
3return HTTP 429 with the JSON body {"error":"rate_limited","retryAfter":<seconds>}.
4Wire the middleware into every /api/* route. Add unit tests in
5test/rate-limit.test.js covering three cases: a request under the limit is
6allowed, a request over the limit is blocked with 429, and the counter resets
7after the window expires. Run the test suite and fix failures until it passes.
8Do not modify any file outside src/ and test/.
9

Start Harness from your project directory:

bashCopy
1cd /path/to/your/repo
2npx @deepseek-ai/dsh web
3

That serves the web UI at http://127.0.0.1:3080. Select the atlas provider and the deepseek-ai/deepseek-v4-flash-0731 model, paste the task, and let it run to completion. Do not intervene, do not answer clarifying questions with hints. Any help you give one harness and not the other invalidates the comparison.

When it finishes, open the Trajectory view. That is the session record, and it is where the token numbers live.

Step 3: Repeat the run in OpenCode for a fair DeepSeek Harness vs OpenCode test

Reset the repo to the exact same starting state. This step is where most informal comparisons quietly break, because the second harness starts on a repo the first one already half fixed.

bashCopy
1git checkout -- . && git clean -fd
2

Then run OpenCode against the same model:

bashCopy
1opencode --model atlas/deepseek-ai/deepseek-v4-flash-0731
2

Paste the identical task prompt from Step 2. Use the default build agent, since that is the one with full file and shell access. Again, no hints, no course corrections, same hands off treatment.

Let it finish, then verify both runs the same way you would grade any PR:

bashCopy
1npm test
2

A run that leaves the suite red did not pass, no matter how confident the summary sounded. Grade it binary, exactly like the Composio methodology does. A half working rate limiter is a fail.

Step 4: Read DeepSeek Harness vs OpenCode token usage

Now collect the numbers. Both harnesses track usage, but they surface it very differently, and this is the single biggest day to day difference between them.

DeepSeek Harness ships a token meter mounted by default. It exposes three session projections you can read directly: tokenUsage for the running total, contextPressure for how close you are to the window, and contextBreakdown for where the tokens actually went. That last one is the useful one, because it tells you whether your bill is system prompt, tool schemas, file reads or conversation replay. The meter uses a fixed heuristic of roughly one token per four characters rather than a real tokenizer, so treat it as a strong estimate, not an invoice.

Harness also handles a full context differently. Instead of truncating, its compaction engine folds: it replaces the model visible surface with a summary while the full log stays in the persistence layer. You lose tokens from the prompt, not history from the record.

OpenCode tracks tokens and cost per session and prints them in the status line as you work. The in-TUI breakdown is deliberately minimal, which is why a small ecosystem of external analyzers exists that read OpenCode's session database directly to break usage down by tool and by cache hit rate. If you want a per tool attribution, you will be installing something.

For the comparison itself, do not trust either tool's own counter as the final word. Use the provider side number, because that is what you are actually paying:

The cleanest method is to create two separate API keys, one named harness-test and one named opencode-test, and use each for exactly one run. Then the provider's own usage page gives you an unarguable side by side with zero estimation error. That trick takes two minutes and removes every source of disagreement about whose counter is right.

DeepSeek harness token usage: what actually moves the bill

Once you have real numbers, these are the levers worth touching. They apply to both harnesses, and they matter far more than which one you picked.

Conversation replay is usually the biggest line. Agents resend the growing conversation on every step. A 40 step task does not cost 40 prompts, it costs something closer to the sum of 40 increasingly long prompts. This is why the benchmark spread ran from 192,000 to 1,400,000 tokens on identical work. Harnesses that summarize aggressively land at the bottom of that range.

Cache hits are the cheapest optimization available. DeepSeek V4 Flash cache hits are priced around $0.0028 per million tokens against $0.14 per million on a miss, roughly 98% cheaper. Caching only works when the request prefix is byte for byte identical, which is exactly why DeepSeek Harness enforces strict {{variable}} interpolation with fail loud semantics and keeps a stable request header. A harness that shuffles your system prompt between calls quietly turns every hit into a miss.

Tool schemas ride along on every single call. Twenty MCP servers connected means twenty sets of schemas in the prompt, forever, whether the task touches them or not. Disconnect what this task does not need before you benchmark, or you are measuring your MCP config rather than your harness.

Oversized tool results poison the context. One cat of a 3,000 line file, or a verbose test runner dumping full stack traces, sits in the conversation for the rest of the run. Harness has an optional result pruning companion that rewrites oversized tool results before summarizing. It is worth turning on.

Retries are invisible until you count calls. A harness that retries a failed test three times spends triple. Compare the call count column, not just total tokens, or you will misdiagnose a retry loop as an expensive model.

On cost, the arithmetic is simple once you have a token count. At the Atlas Cloud rate for DeepSeek V4 Flash, a 692,000 token task weighted toward input lands in the low single digit cents. That is the good news about this whole category: the model is cheap enough that harness waste is an efficiency problem rather than a budget emergency. It only becomes a real number when you multiply by a team, running all day, every day. Browse the full model catalog if you want to run the same test against a second model and separate model effects from harness effects.

One caveat that should shape your decision more than any token number: DeepSeek Harness is explicitly in developer preview and its own README warns in capitals that there will be compatibility breaking changes. That is a fine thing to benchmark and a risky thing to standardize a team on this month. OpenCode is the boring choice, and boring is a feature when it is running against your production repo.

Frequently Asked Questions

Is DeepSeek Harness better than OpenCode?

Not yet, for most people. OpenCode is mature, terminal native, has roughly 198k stars and a large provider catalog, and it works today. DeepSeek Harness is two weeks old, in developer preview, and warns about breaking changes. Harness is more interesting architecturally, because every component including the agent loop is a replaceable plugin. If you want to rewrite agent internals, Harness is built for that. If you want to ship code this week, OpenCode.

Does DeepSeek Harness only work with DeepSeek models?

No. It is model agnostic. It ships catalog providers for DeepSeek, Anthropic, OpenAI, Bedrock, Vertex, Azure and Codex, and you can add any custom provider that speaks openai-completions, openai-responses or anthropic-messages by adding a block to $DSH_HOME/settings.yaml. The config in Step 1 points it at a third party OpenAI compatible endpoint with no adapter code.

How do I check DeepSeek harness token usage?

Use the built in token meter, which is mounted by default and exposes tokenUsage, contextPressure and contextBreakdown projections, visible in the Trajectory view. Note that it estimates with a fixed heuristic of about one token per four characters rather than running a real tokenizer. For billing accuracy, read your provider's usage dashboard instead, ideally with a dedicated API key per run. Community plugins like token usage dashboards add persistent per session records on top.

Which harness uses fewer tokens, DeepSeek Harness or OpenCode?

There is no published head to head yet. The 8 harness benchmark on DeepSeek V4 Flash measured OpenCode at 692,000 average tokens per task, but it ran two days before DeepSeek Harness was released, so Harness was not included. Anyone quoting a Harness number from that benchmark is quoting something that does not exist. Run the Step 2 to Step 4 test on your own repo, since token usage depends heavily on your codebase size, your MCP config and your task shape.

Can I run DeepSeek Harness and OpenCode against the same API key?

Yes, and for a casual test that is fine. For a clean measurement, use two separate keys, one per harness. Then your provider's usage dashboard attributes every token to the right run automatically and you never have to reconcile two different internal estimators against one invoice.

What is the difference between an agent and a harness?

DeepSeek's own framing is Agent = Model + Harness. The model does the reasoning. The harness is everything that connects it to reality: reading and writing files, running shell commands, calling tools, managing sessions, handling approvals and driving the loop that decides what happens next. Same model plus a different harness gives you a measurably different agent, which is the entire point of this comparison.