Context-Window Economics: What Actually Eats Your Agent's Tokens

I spent a long time thinking about AI agent quality in terms of the model and the prompt. Then I started reading the raw context I was actually sending, token by token, and realized most of my problem was economics.

The model was fine. My context window was a landfill.

Every turn, an agent resends its entire working context: system prompt, tool definitions, conversation history, tool results, files it read, reasoning traces. The model does not remember anything between calls. It rereads all of it, every single time. So the cost of a sloppy context is not paid once. It is paid on every turn until the run ends.

That is the core of context-window economics, and once you see it, you cannot unsee it.

The five things eating your tokens

When I started profiling agent runs, the same culprits showed up over and over.

Tool definitions. Every tool you expose ships its full JSON schema on every request. One tool is cheap. Twenty tools with rich descriptions, nested parameter objects, and long enum lists can quietly cost thousands of tokens before the agent does anything. And you pay that on every turn, whether or not the tool gets called. I have seen agents where a third of the fixed overhead was tool schemas the model never touched during the run.

Repeated tool results. This is the sneakiest one. Your agent calls a search tool, gets back a 4,000-token blob, reasons about it, then calls another tool. The blob stays in history. Ten turns later it is still there, still being resent, still being paid for, long after it stopped being relevant. Large tool outputs are the single biggest source of drift I see.

Re-read files. Agents love to read the same file twice. It read config.py on turn 3, forgot it was already in context, and read it again on turn 9. Now you have two full copies of the same file competing for the model's attention and both are billed. Duplication like this is pure waste: no new information, double the cost.

Stale outputs. Command results, logs, intermediate scratch data. A 500-line test log was useful for exactly one turn, when the agent diagnosed the failure. After that it is dead weight that never leaves. Multiply by a long run and stale output becomes a dominant line item.

Thinking. Reasoning traces earn their keep, but they are not free, and they accumulate. Verbose thinking on every trivial step adds up fast, especially when earlier reasoning is carried forward into later turns where it no longer matters.

Why this compounds

Here is the mental model that changed how I build agents. Think of context cost as roughly the size of your context multiplied by the number of turns that context survives.

A one-time 200-token prompt is trivial. A 4,000-token tool result that lingers for 15 turns is not a 4,000-token cost. It is closer to 60,000 tokens of cumulative resending.

That multiplier is why waste matters more in agents than in single-shot prompts. In a chatbot you pay for a bloated message once. In an agent loop you pay for it again and again until the loop ends. Small inefficiencies that you would never notice in a one-off call become the main cost driver in a 30-turn run.

There is a quality tax too, not just a money tax. Long, cluttered contexts dilute attention. When the genuinely important 500 tokens are buried in 50,000 tokens of stale logs and duplicated files, the model has a harder time finding them. Cutting waste often makes agents both cheaper and sharper at the same time.

How to actually measure it

You cannot cut what you cannot see, so start by profiling. Concretely:

• Capture the real context. Log the exact payload sent on each turn, not your idea of it. The gap between what you think you are sending and what you are actually sending is usually large.
• Attribute tokens by category. Bucket every span into tool definitions, tool results, file reads, command outputs, thinking, and conversation. Now you have a bill with line items instead of one scary total.
• Measure lifespan, not just size. For each chunk, ask how many turns it survives. A big chunk that dies immediately is fine. A medium chunk that lives forever is your real problem.
• Flag duplication. Hash file contents and tool results. Exact or near-exact repeats are free money on the table.

This profiling instinct is what pushed me to build ctxlens. It profiles an agent's context, attributes tokens across those categories, flags duplication and stale spans, and recommends specific cuts. But the tool is just an implementation of the discipline. The discipline is what matters: read your context like a bill and question every line.

Tactics that actually cut tokens

Once you can see the waste, the fixes are mostly boring and effective.

• Prune tool definitions to the job. Do not expose 20 tools when the task needs 5. Trim descriptions and enums. Consider loading tool schemas on demand rather than all upfront.
• Summarize or evict large tool results. After the agent has used a big blob, replace it in history with a short summary of what mattered. The raw 4,000 tokens rarely need to survive.
• Deduplicate reads. Track what is already in context. If a file is present, do not read it again. Reference the existing copy.
• Set a lifespan on stale output. Logs and command results should expire. Keep the conclusion, drop the raw dump after it has served its turn.
• Right-size thinking. Reserve deep reasoning for hard steps. Do not burn a long trace deciding to read one file.

One honest caveat

Aggressive cutting has a real failure mode: you can evict something the agent genuinely needed later. If you summarize a tool result too hard and the agent needs a detail you dropped, it just re-fetches, and now you have paid for the original, the summary, and the refetch. That can cost more than keeping the data.

Compression is a bet that the detail will not be needed again, and sometimes you lose the bet. Measure the net effect on real runs. Do not optimize token count in isolation and assume you won the trade.

Still, in most agents I have profiled, the waste is so obvious and so redundant that careful trimming is nearly free of downside. The stale logs, the duplicated files, the tool schemas no one called: cutting those almost never costs you anything but noise.

If you want to see where your own agent's tokens are going, that is exactly what I built ctxlens to answer. Point it at a run, read the breakdown, and start with the line items that surprise you. The code is at github.com/AgentPostmortem/ctxlens if you want to profile before you prune.