Token Waste Sources
Overview (confidence: medium)
Token waste sources is the diagnostic framing behind token-reduction tooling: instead of asking “which tool saves the most tokens?”, ask “where is my agent actually wasting context?”. The premise is that agents waste context in a small number of recognizable places, each best fixed by a different tool.
The Six Waste Sources (confidence: medium)
| Waste source | Fix class | Representative tool |
|---|---|---|
| Terminal logs (git, tests, builds, package managers, Docker, grep) | Output compression | rtk-rust-token-killer |
| Full files / messy multi-source context (tool outputs, logs, RAG chunks, history) | Broad compression layer | headroom |
| Repeated grep loops / file-by-file navigation | Repo-navigation map | codegraph |
| Old state / stale conversation | Context editing, compaction | context-compaction, tool-context-management |
| Verbose replies (too much English) | Output-verbosity reduction | caveman |
| Code that did not need to be written (over-building) | Anti-overbuild / reuse-first | Ponytail |
Waste hurts quality, not just cost: more irrelevant context means slower runs, more retries, and a higher chance the agent loses the task, misses the right file, or changes the wrong thing.
The Measurement Checklist (confidence: medium)
To pick a fix, measure before optimizing: input tokens, output tokens, reasoning tokens, tool calls, latency, cost per task, tests passed, reruns, and how often the agent loses context. The goal is not fewer tokens as a vanity metric — it is less noise in, better context selected, smaller diffs, fewer reruns, and lower cost per successful task.
Token Reduction ≠ Cost Reduction (confidence: high)
“Don’t assume 80% fewer tokens means 80% cheaper.” Cached input, reasoning tokens, and reruns all affect the final bill. This matches the vault’s measured finding in token-reduction-is-not-cost-reduction (input cuts can raise billed cost) and the contested stance on input-compression proxies in rtk-rust-token-killer / headroom. It is also why caveman — which cuts output (the cheap part) while leaving reasoning tokens untouched — can raise total tokens in a coding benchmark even while reducing output.
Implications
The waste-source lens reframes token reduction as a targeted, measurable discipline rather than a toolkit sweep. It composes with token-usage-reduction (the overall cost-lever space) and tool-context-management (the client-side strategies), and it predicts a “1 tool per dominant waste source” deployment: RTK for terminal noise, Headroom for messy context, CodeGraph for navigation, Ponytail for smaller diffs, Caveman for shorter replies.
Open Questions
- Whether the six-source taxonomy generalizes beyond coding agents (research, chat, data tasks).
- Whether the representative-tool mappings hold as the tools evolve (e.g., Headroom absorbing RTK under the hood).
Related
token-usage-reduction — the cost-lever space this diagnostic feeds rtk-rust-token-killer — terminal-output waste headroom — multi-source context waste codegraph — repo-navigation waste caveman — output-verbosity waste token-reduction-is-not-cost-reduction — why token cuts ≠ cost cuts
Sources
- raw/prompts/articles/reduce-wasted-tokens.md