Unexpected 48M Token Usage During MCP Setup

[3bdulrahmanOthman]

Hi DeepSeek Harness team,

I'm a subscriber. I used a Flash model with Low effort to set up and verify five MCP servers: GitHub, Context7, Playwright, Code Cortex, and AgentMemory. I also briefly tested TAM before removing it due to startup issues.

The total reported usage reached 48,019,959 tokens. This seems excessive for MCP setup and basic verification.

Is this expected, or could context accumulation, repeated tool calls, or subagent loops be causing unusually high token consumption? How can I identify where these tokens went and prevent this from happening again?

Thanks!

[nefayran]

I can't see your session, so this is what I'd check first rather than a diagnosis.

Every turn sends the whole prompt again: the system prompt, the tools of every connected server (the MCP client puts all of a server's tools into the model's tool list when the harness starts) and every earlier tool result. So billed input grows roughly with the square of the number of turns. When I measured this in Claude Code, not in this harness, an answer that took 18 turns instead of 7 cost 708k input tokens instead of 267k. Setting up five servers in one session means many turns, each carrying all the output before it.

The footer's cache N% tells you how much of it was cheap: it is the share of billed prompt tokens served from the provider's cache. If it is high, most of the 48M is the same prefix read again on each turn.

Two of your servers make each turn heavier. Playwright MCP attaches a page snapshot to its responses by default (--snapshot-mode, default full, none turns it off), and the snapshots stay in the history. The GitHub server loads several toolsets by default; GITHUB_TOOLSETS limits it to the ones you use.

Next time I'd set up one server per fresh session, keep connected only the servers a task needs, and run Playwright with --snapshot-mode none unless the page tree is needed.

[3bdulrahmanOthman]

Thanks for the detailed explanation. One important clarification: I was already using a separate fresh conversation for each MCP setup, so the initial 48M-token usage was not from configuring all five servers in one long conversation.

I understand that repeated context, MCP tool definitions, and large tool results can increase cumulative input usage. However, I’m still seeing unusually high totals even in other workflows.

For example, in a separate Checkout & Payments development conversation, DSH reported 90.4M tokens across 355 steps, with a 99.8% cache hit rate. The work included code changes and regression tests, so I’m not treating that as directly comparable to MCP setup. But it makes me want to understand the actual accounting rather than infer the cause from the cache percentage alone.

What I’m trying to establish is where the tokens are going. Is there a way to inspect per-model-call usage, including cached versus uncached input, output tokens, and any retries or subagent calls, and correlate that with the reported step count? If this information isn’t exposed in the UI, is there a specific DSH log or usage-accounting component that would help verify how the total is calculated?

I’m not assuming this is a bug; I’d like to distinguish expected cumulative context usage from excessive tool/context overhead or a possible accounting issue.

[IlyaKhalafi]

On current main, the Web UI's Detailed mode lets you click the composer's token-total pill for exact recorded uncached input, cache reads and output, plus cache writes when nonzero. Completed Turns also have a usage button with their own breakdown, including retries. A missing Turn disclosure can mean insufficient recorded usage, so it does not establish zero consumption.

For individual calls, use Download session log or /export. The ZIP includes sub-sessions. Inspect their logs separately too, since I haven't verified whether the parent's pill includes their usage.

The accounting component is tokenUsageProjectionDefinition. assistant/message carries successful-call usage and assistant/attempt preserves any usage reported before failure. A message's top-level usage takes precedence over its embedded sample. A matching llm/retry-started opens another accounting slot even at the same Turn and step, so step counts can hide multiple attempts. Reasoning is already part of output.

I checked the current Turn fold with synthetic events. A failed 170-token attempt plus a 70-token retry at the same step totalled 240. Missing usage returned no result. This checks the accounting function, not your bill.

Which DSH version and client produced those sessions? These findings are from current main. The 90.4M total and cache percentage alone cannot identify the expensive calls or establish whether the accounting is correct.