推荐这篇硬核实测。一个工程师用了一周追踪自己的 coding agent session，发现任务本身只消耗了 0.67% 的 token——其余 99% 全花在搬运工具目录、skill 描述和系统 prompt 上。工作对开销比 1:150。最扎心的数据：Shell 输出过滤省了 46.9% 的 token，而压缩历史只省了 4.2%。他给了一整套优化方法论——从读 usage block 开始。

你的 Agent 花了 99% 的 Token 在搬运工具箱，不在干活

代理编码中有一个舒服的假设：token 和工作量成正比。大任务，大账单。小修复，小账单。

是错的。

我追踪了一个修复 GitHub issue 的完整 session：读 issue → 编辑 98 行 server.mjs → 跑测试 → 提交 → 开 PR。输出是约 10,304 个 token。总处理上下文是约 155 万 token。工作开销比约 1:150。

账单上最贵的四样东西

1. 工具名称倾倒——最大的单块消耗。 我连了 9 个 MCP 服务器，暴露约 260 个工具。当两个服务器中途附加时，harness 注入了它们的完整工具目录——一个服务器就列了约 180 个工具名。这是一次性的，但它巨大，且从不离开对话历史。

2. Skill 目录——每回合的固定税。 几十个 skill，每个带多句描述，每回合都加载。不尖峰——它抬高底部。

3. 系统 prompt、安全政策、工具 schema。 固定成本，每回合。在 agent 做任何事之前，每回合基线可能已经超过 100K token。

4. 实际任务。 几 KB。和目录相比微不足道。

上下文增长的主导因素是你连接了什么，不是你在做什么。

怎么修——按效果排

1. 读 usage block（免费）。 最后回合的 API 响应携带三个数字：output_tokens、input_tokens、cache_read_input_tokens。缓存读取就是你的累计历史——每次 git status、每次 npm test 的输出、每次编辑的旧/新字符串对。在我的 session：约 10.3K 输出，约 9.9K 新输入，约 153.5 万次缓存读取。那一个数字说了全部故事。

2. 中途用 /context 看一眼。 显示现在什么占着上下文窗口。这是你抓到“每回合固定成本“的方式。

3. 过滤 Shell 输出——最大的单笔杠杆。 在 shell 命令前加一个薄过滤层，跨约 6800 条命令省了 270 万 token（46.9%）。这是最高杠杆的每 token 干预——因为工具输出在每个后续回合都重新进入上下文。

4. 断掉你这次不用的 MCP 服务器。 最大单赢，零工程。最胖的工具倾倒来自一个我整个 session 没调用过的服务器。按任务连接，不是永久连接。

5. 压缩输出风格。 Hook 强制 agent 在常规回台上给出简洁回复。基准估算：受影响回合约节省 65% 输出 token。

6. 压缩陈旧历史——但要精准。 31% 的消息是文件读取输出（压缩风险太大），51% 太短不值得。只有陈旧读取——10 回合以上的文件内容——值得定向压缩。

7. 尊重缓存。 95.1% 的命中率是什么让一周 7.13 亿 token 变得可负担的。任何扰乱 prompt 前缀稳定性的东西——重排工具、中途编辑 prompt、不稳定的工具目录——都会重置这条曲线。

五条教训

1. 比例是核心指标。 不是总 token——任务 token 对环境 token 的比例
2. 每个连接的工具是一笔固定收费。 按需求连接，不要永久挂载
3. 一次性消耗和每回合消耗要不同策略对待
4. 先测量再优化——直觉通常是第三好的方案。 我本来会赌历史压缩是最大赢家（实际 4.2%），CLI 输出过滤我排最后（实际 46.9%）
5. 输出 token 少但贵；缓存 token 大但便宜。 优化两者，但知道你在动哪根杠杆

原文：https://praveenvijayan.substack.com/p/your-agent-spends-99-of-its-tokens…

#Token优化 #Agent工程 #MCP

Your Agent Spends 99% of Its Tokens Carrying the Workshop, Not Doing the Work

Source: https://praveenvijayan.substack.com/p/your-agent-spends-99-of-its-tokens There’s a comfortable assumption in agentic coding: tokens scale with work. Big task, big bill. Small fix, small bill.

It’s wrong. In a session I instrumented last week, the agent closed a GitHub issue — read the issue, edited a 98-lineserver\.mjs, ran tests, committed, opened a PR. The output was**~10,304 tokensof reasoning and generation. The total processed context was~1.55 million tokens**.

That’s a work-to-overhead ratio of roughly1:150. The agent wasn’t thinking with 1.5M tokens. It washaulingthem — re-reading its own environment on every turn.

If you’re running coding agents daily, this ratio is your bill, your latency, and your context-rot risk. So I broke it down.

Across the last 24 hours on this machine, 37% of requests ran above 150k context. My first instinct was “the task grew.” It hadn’t. Ranked by size:

**1. Deferred-tool name dumps — the single biggest chunk.**I had 9 MCP servers connected exposing ~260 tools. When two of them (githuband a code-graph server) attached mid-session, the harness injected their full tool catalogues — one server alone listed ~180 tool names. It fires once, but it’s massive, and it never leaves the conversation history.

**2. The skills catalogue — the per-turn tax.**Dozens of skills, each with a multi-sentence description, loaded oneveryturn. Unlike the tool dump, this isn’t a one-shot cost; it rides along for the entire session. This is the quiet one — it doesn’t spike, it just raises the floor.

**3. System prompt, safety policy, tool schemas.**Fixed cost, every turn. Before the agent did anything at all, the per-turn baseline was likely north of 100k tokens.

**4. The actual task.**Issue text, the file, the diffs, test output, the PR body. A few thousand tokens total. Trivial next to the catalogues.

The lesson generalises:context growth in agent sessions is dominated by what you’veconnected**, not what you’redoing.**

Don’t guess. Three methods, in the order I’d use them:

1. Read theusageblock on the final turn.Every API response carriesoutput\_tokens,input\_tokens, andcache\_read\_input\_tokens. The cache-read figure is your cumulative history — everygit status, everynpm teststdout, every old/new string pair from every edit, every tool-call UUID and timestamp. In my session: ~10.3k output, ~9.9k fresh input,~1.535M cache reads. That one number told the whole story.

2. Use/context**(or your harness equivalent) mid-session.**It shows what’s occupying the windowright now, categorised. This is how you catch the per-turn fixed costs — the skills catalogue and schemas that a final-turn usage block can’t separate out.

**3. Instrument the pipeline.**I run Headroom (a local proxy) that logs every request. Over one week: 10,678 requests, 713M tokens in, a 95.1% cache hit rate, average conversation of 103 messages (max 607). Once you can see per-model, per-transform, per-tool numbers, optimisation stops being folklore.

**Filter CLI output before it enters context.Tool results are the raw sewage of agent contexts — full test logs, verbose git output, directory listings. A thin filtering layer in front of shell commands saved2.7M tokens (46.9%)**across ~6,800 commands lifetime. This is the highest-leverage per-token intervention because tool output re-enters context onevery subsequent turn.

**Disable MCP servers you aren’t using this session.**Biggest single win, zero engineering. The fattest tool dump in my setup came from a server I didn’t call once that session. Connect per-task, not permanently. Same logic for plugins and skills: fewer loaded = smaller per-turn floor.

**Constrain output style.**I run a hook that forces terse agent responses on routine turns. Benchmarked estimate: ~65% output-token reduction on affected turns. Output tokens are the expensive ones — and most agent verbosity is ceremony, not signal.

**Compress stale history, surgically.**My proxy’s content router taught me something counter-intuitive: 31% of messages were file-read outputs itexcludedfrom compression (too risky to touch fresh reads), and 51% were too short to bother with. Net reduction: only 4.2% (~30M tokens across four active days). Blanket compression underdelivers. The real opportunity isstalereads — file contents from 10+ turns ago that the agent will never reference again. Target those, not everything.

/compact**mid-session.**The blunt instrument. When a conversation crosses a few hundred messages, squash the history. You lose fidelity; you keep your budget.

**Respect the cache.**95.1% hit rate is what made a 713M-token week affordable at all. But caching has a shape: my first-five-requests average showed cache writes nearly equal to reads; by session end, reads were 4x writes. Anything that churns the prompt prefix — reordering tools, editing system prompts mid-session, unstable tool catalogues — resets that curve and you pay full price again.Stability of the prefix is a cost feature.

**1. The ratio is the metric.**Not total tokens — the ratio of task tokens to environment tokens. Mine was 1:150. If yours is similar, no amount of “prompt engineering” on the task side matters; the task side is a rounding error.

**2. Every connected tool is a standing charge.**MCP made connecting integrations trivial, and that’s the trap. ~260 tools sounds like capability; in practice it’s a catalogue the model re-reads forever, plus a documented degradation in tool-selectionaccuracy. Deferred tool loading helps, but the name dump alone is nontrivial. Connect deliberately.

**3. One-shot costs and per-turn costs need different treatment.**The tool dump is one-shot: painful but bounded — fix it by connecting less. The skills catalogue is per-turn: it compounds with session length — fix it by loading less. Confusing the two leads to optimising the wrong thing.

**4. Measure before optimising — the intuitive fix is usually third-best.**I would have bet on history compression as the top intervention. It delivered 4.2%. CLI output filtering, which I’d have ranked last, delivered 46.9% on its slice. The data disagreed with me, and the data was right.

**5. Output tokens are small but expensive; cache tokens are huge but cheap.**Optimise both, but know which lever you’re pulling. Cutting output verbosity saves money per token; cutting context bloat saves latency, context-rot, and cache-write spikes.

The industry conversation is about bigger context windows. My data says the bottleneck isn’t windowsize— it’s windowhygiene. A 1M-token window filled 99% with tool catalogues and stale test logs is not a more capable agent. It’s a more expensive one with worse recall of the 1% that matters.

Before you reach for a bigger model or a bigger window: read yourusageblock. Count your connected tools. Filter your shell output. The cheapest million tokens are the ones you never send.

Numbers in this piece are from my own instrumented sessions — a week of proxy logs (10,678 requests, 713M tokens) and a single end-to-end issue-to-PR session. Your ratios will differ; your categories won’t.

Discussion about this post

Ready for more?