@yibie: Recommends this hardcore real-world test. An engineer tracked his coding agent session for a week and found that only 0.67% of tokens were spent on actual tasks—the remaining 99% all went to moving tool directories, skill descriptions, and system prompts. Work-to-overhead ratio 1:1…

X AI KOLs Timeline News

Summary

An engineer tracked his coding agent's token usage over a week, finding that only 0.67% of tokens were spent on actual tasks, with 99% consumed by tool directories, skill descriptions, and system prompts. He provides optimization strategies, including shell output filtering which saved 46.9% of tokens.

Recommend reading this solid real-world test. An engineer tracked his coding agent session for a week and found that only 0.67% of tokens were spent on actual tasks—the remaining 99% all went to moving tool directories, skill descriptions, and system prompts. Work-to-overhead ratio: 1:150. The most painful data point: shell output filtering saved 46.9% of tokens, while compressing history saved only 4.2%. He provides a full optimization methodology—starting with reading the usage block. Your Agent Spends 99% of Tokens Moving the Toolbox, Not Working Agent-assisted coding has a comfortable assumption: tokens are proportional to work. Big task, big bill. Small fix, small bill. It's wrong. I tracked a complete session fixing a GitHub issue: read issue → edit 98 lines of server.mjs → run tests → commit → open PR. Output was ~10,304 tokens. Total processed context was ~1.55 million tokens. Work-to-overhead ratio ~1:150. The Four Most Expensive Items on the Bill 1. **Tool name dumping**—the biggest single block. I connected 9 MCP servers, exposing about 260 tools. When two servers attached mid-session, the harness injected their full tool directories—one server listed about 180 tool names. This is one-time, but it's huge and never leaves the conversation history. 2. **Skill directory**—a fixed tax per turn. Dozens of skills, each with a multi-sentence description, loaded every turn. Not spikey—it raises the floor. 3. **System prompt, safety policies, tool schemas.** Fixed cost, per turn. Before the agent does anything, the per-turn baseline may already exceed 100K tokens. 4. **Actual task.** A few KB. Negligible compared to the directories. The dominant factor in context growth is what you connected, not what you're doing. How to Fix—Sorted by Impact 1. **Read the usage block (free).** The last turn's API response carries three numbers: output_tokens, input_tokens, cache_read_input_tokens. Cache reads are your cumulative history—every git status, every npm test output, every edit's old/new string pair. In my session: ~10.3K output, ~9.9K new input, ~1.535 million cache reads. That one number tells the whole story. 2. **Use /context mid-session to look.** Shows what's currently occupying the context window. This is how you catch the "per-turn fixed cost." 3. **Filter shell output—biggest single lever.** Adding a thin filtering layer before shell commands saved 2.7 million tokens (46.9%) across ~6,800 commands. This is the highest-leverage per-token intervention—because tool output re-enters context on every subsequent turn. 4. **Disconnect MCP servers you don't need right now.** Biggest single win, zero engineering. The fattest tool dump came from a server I never called during the entire session. Connect per task, not permanently. 5. **Compress output style.** Hook to force the agent to give concise replies on regular turns. Baseline estimate: ~65% output token savings on affected turns. 6. **Compress stale history—but precisely.** 31% of messages were file read outputs (too risky to compress), 51% too short to bother. Only stale reads—file content older than 10 turns—are worth targeted compression. 7. **Respect caching.** A 95.1% hit rate made 713 million tokens over a week affordable. Anything that disrupts prompt prefix stability—reordering tools, editing prompts mid-session, unstable tool directories—resets this curve. Five Lessons 1. **Ratio is the core metric.** Not total tokens—the ratio of task tokens to environment tokens. 2. **Every connected tool is a fixed fee.** Connect on demand, don't mount permanently. 3. **One-time consumption and per-turn consumption need different strategies.** 4. **Measure before optimizing—intuition is usually third best.** I would have bet history compression was the biggest win (actual 4.2%), CLI output filtering I placed last (actual 46.9%). 5. **Output tokens are few but expensive; cache tokens are huge but cheap.** Optimize both, but know which lever you're pulling. Original: https://praveenvijayan.substack.com/p/your-agent-spends-99-of-its-tokens… #TokenOptimization #AgentEngineering #MCP
Original Article
View Cached Full Text

Cached at: 07/15/26, 01:55 PM

Recommend this hard-hitting real-world test. An engineer spent a week tracking his own coding agent sessions, only to find that the actual task consumed just 0.67% of the tokens—the remaining 99% was all spent hauling tool directories, skill descriptions, and system prompts. Work-to-overhead ratio: 1:150. Most painful stat: Shell output filtering saved 46.9% of tokens, while compressing history saved only 4.2%. He offers a full optimization methodology—starting with reading the usage block.

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

There’s a comfortable assumption in agentic coding: tokens scale with work. Big task, big bill. Small fix, small bill.

It’s wrong.

I tracked a full session that fixed a GitHub issue: read the issue → edit 98 lines of server.mjs → run tests → commit → open PR. Output was about 10,304 tokens. Total processed context was about 1.55 million tokens. Work-to-overhead ratio: roughly 1:150.

The Four Most Expensive Items on the Bill

  1. Tool name dumps—the single biggest chunk. I connected 9 MCP servers, exposing about 260 tools. When two servers attached mid-session, the harness injected their full tool catalogues—one server alone listed about 180 tool names. It’s one-time, but it’s huge, and it never leaves conversation history.

  2. Skills catalogue—a per-turn fixed tax. Dozens of skills, each with multi-sentence descriptions, loaded every turn. No spike—it just raises the floor.

  3. System prompt, safety policies, tool schemas. Fixed cost per turn. Before the agent does anything, the per-turn baseline could already exceed 100K tokens.

  4. The actual task. A few KB. Trivial compared to the catalogues.

The dominant driver of context growth is what you’ve connected, not what you’re doing.

How to Fix It—Ranked by Effectiveness

  1. Read the usage block (free). The API response on the final turn carries three numbers: output_tokens, input_tokens, cache_read_input_tokens. Cache reads = your cumulative history—every git status, every npm test output, every old/new string pair from edits. In my session: ~10.3K output, ~9.9K fresh input, ~1.535M cache reads. That one number tells the whole story.

  2. Use /context mid-session to take a look. It shows what’s currently occupying the context window. That’s how you catch the per-turn fixed cost.

  3. Filter shell output—biggest single lever. Add a thin filtering layer before shell commands, saving 2.7 million tokens (46.9%) across about 6,800 commands. This is the highest-leverage per-token intervention—because tool output re-enters context on every subsequent turn.

  4. Disconnect MCP servers you aren’t using for this session. Biggest single win, zero engineering. The fattest tool dump came from a server I never called during the entire session. Connect per task, not permanently.

  5. Constrain output style. Hook to force terse agent responses on routine turns. Baseline estimate: ~65% output-token savings on affected turns.

  6. Compress stale history—but be precise. 31% of messages were file-read outputs (too risky to compress), 51% too short to bother. Only stale reads—file contents from 10+ turns ago—are worth targeted compression.

  7. Respect the cache. A 95.1% hit rate is what made a 713 million token week affordable. Anything that disrupts prompt prefix stability—reordering tools, editing prompts mid-session, unstable tool catalogues—resets this curve.

Five Lessons

  1. The ratio is the core metric. Not total tokens—the ratio of task tokens to environment tokens.
  2. Every connected tool is a fixed charge. Connect on demand, don’t mount permanently.
  3. One-shot costs and per-turn costs need different treatment.
  4. Measure first, then optimize—intuition is usually third-best. I would have bet history compression was the biggest win (actual 4.2%), and CLI output filtering last (actual 46.9%).
  5. Output tokens are small but expensive; cache tokens are huge but cheap. Optimize both, but know which lever you’re pulling.

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

#TokenOptimization #AgentEngineering #MCP

Similar Articles

@freeman1266: Slash AI coding costs by 80% monthly with optimization strategies and model routing. Inefficient context management and blind use of expensive models can cause bills to skyrocket. By implementing prompt caching, trimming context files, and fixing auto-loops in tool calls, developers can significantly reduce ineffective token consumption.…

X AI KOLs Timeline

This article introduces practical techniques to cut AI coding costs by 80%, including prompt caching, context trimming, multi-model routing (using Kimi 2.6 for daily coding tasks and advanced models for core architecture), and more.

@wsl8297: When running complex tasks with AI agents, the most painful thing is often not that the model isn't strong enough, but that as the conversation gets longer, the context starts to overflow. You have to keep filling in background details, re-explaining the process, plus the redundant logs from tool calls — tokens just gush out like a broken pipe. Recently, I saw TencentDB Agent Memory open-sourced by Tencent...

X AI KOLs Timeline

Tencent has open-sourced TencentDB Agent Memory, which solves the AI agent long-context overflow problem through hierarchical memory management (symbolic short-term memory + hierarchical long-term memory). Benchmarks show token consumption reduced by up to 61% and task success rate improved by over 50%.