How dirty is your context window?

99.7% of the bill goes to input

What first made me take context-window waste seriously was a Reddit post by karmendra_choudhary. The author had tracked 100 million tokens of their own Claude Code usage — and 99.4% of it was input. Meaning: almost none of that money went to the model writing code. It went to re-feeding old context, every single turn.

I didn’t quite buy it, so I grabbed one of my own Codex coding sessions and took it apart. The result was even starker: 99.7% input. Out of that session’s 10.9 million tokens, only 25.8K were actual output — less than 0.3%.

Then I went back through my history and pulled the 69 Codex conversations I could still account for. 1.70 billion tokens in total. At API list pricing, that’s roughly $1,470. And of that money, 99.7% went to input — most of it billed at the cached-input rate for old context. The real output was worth about $167.

This isn’t “one conversation got expensive.” This is you, every day, waiting for the model to swallow a giant heap of history before it writes anything.

So the real question is this: is all that input actually doing anything? Or is it stretching your wait, diluting the model’s judgment, and dragging down your coding agent’s performance?

Talk is cheap. Show me the commit.

In Codex, a working session is essentially a conversation aimed at getting the code right and landing a single code commit. On a team you can think of it as a PR: the code has to reach a checkable, mergeable, traceable outcome.

So the commit is the most natural boundary. Only once code is committed does the work leading up to it count as a finished, meaningful unit.

But a commit usually doesn’t land in a single turn. It typically takes several. I describe what I want; the agent reads files, edits code; I correct it; it edits again. Finally, it lands the commit. We call this short stretch an episode.

A working session can hold multiple episodes. How many you run depends on your habits: some people do one thing per session, others keep going for several commits in a row.

Every turn inside an episode also carries its own context window. System prompts, prior dialogue, files it read, tool-call history, tool outputs, the code it just modified — all of it lives inside that window.

Once we break it apart this way, we can look at it from a different angle: what context does one commit actually need, and how much useless old baggage is it being forced to drag along?

An ordinary task is the one that exposes the problem

Day to day I’m a heavy user of Codex, Claude Code, and OpenClaw. Nothing mystical, no megaprojects — mostly web and apps: pages, components, animations, production bugs.

Just looking at Codex: from April 25 to today, I’ve accumulated 120 sessions. June alone has 69. I picked the June 2 session, not because it’s extreme, but because it’s so ordinary.

That day’s task was redoing the Echo homepage: tweaking the layout, adding a value-prop module, wiring up a mascot loading animation. The screenshot on the right is the page I was working on.

This session went 70 turns and landed 7 commits. The process was perfectly normal. I stated the goal; the agent read files, modified code, checked the result. I corrected, it adjusted, and once it was stable, the commit landed.

That’s what makes it representative: the task isn’t big, the workflow is real, the output is unremarkable. What’s not ordinary is the cost. This single homepage refresh chewed through 10.9M tokens. About 156K tokens per turn, on average. To put that into something you can feel: Moby Dick runs roughly 210K words, around 280K tokens — meaning every time I sent the agent a single sentence, it showed up dragging more than half of Moby Dick through the door with it.

Which raises the question: why does an ordinary edit have to lug around this much context? Is any of it actually necessary?

Zooming in on the last commit

So what’s actually inside a context window the size of half of Moby Dick? We don’t need to read all 70 turns. Take the three turns right before the last commit as our specimen: T65, T66, T67.

A note on the setup: the user’s goal was crystal clear. I already knew what I wanted — fix the homepage animation loading. The final commit ended up touching 5 files, with a diff of 106 lines added and 18 deleted.

But “useful” can’t mean only the files that got modified. The directly-edited files are the product; the supporting files I didn’t touch but which decide whether the change ships safely must count too: the protected route, buffer reuse, token cookies, middleware, Next packaging config, and whether v21 private resources are still kept private.

In practice that’s not how it played out. T65 had just emerged from the previous commit, already carrying a 182.1K-token context window. Then T66 ran one re-orientation loop: scanning recent related changes, searching components, checking the asset loading path, reading config, testing production behavior. It did produce a plan.

But the plan tripped over a hard constraint: one of the resources can’t simply become a plain public asset. More importantly, this wasn’t fresh information the user dropped on it at T67. The project history already contained this protection logic, and T66 itself had re-read the relevant paths and config in this same round. The problem: when it came time to synthesize the plan, that constraint never made it to top priority.

So T67 became a correction round: the user dragged the hard constraint it had just read back into focus, the AI reversed course, and switched to a loading strategy that doesn’t break the protection boundary. The following turns kept verifying the environment: are the resources still correctly protected, is production behavior consistent, are the verifications reliable. By T70, those 5 files finally landed in the commit.

So the problem isn’t “the user wasn’t clear.” The user’s goal was clear, the scope of change was small, the key constraint was in project history, and T66 had already read it. But execution still went through every motion: re-locating, drifting off plan, re-elevating the constraint, validating a second time, re-confirming the environment. Each step served its purpose once, but every one of them also stayed in the context window, layer on layer.

That’s what makes T65 through T67 so glaring: T66 jumped straight to 220.2K tokens, T67 didn’t shrink at all. Just those three turns ate 622.5K tokens. And worse — as the chart below shows — the portion actually relevant to this commit is tiny; most of the space is occupied by old records and detours.

T66 and T67 exist, fundamentally, because execution had already missed once: the key constraint was re-read but never made it into the plan, so one extra round of correction, rollback, and revision got tacked on.

This matches what Chroma found in Context Rot: after controlling for task complexity, model performance degrades as input length increases[1]. Anthropic’s Effective Context Engineering defines context as a finite resource and stresses curating the tokens best suited to current reasoning, rather than filling the window[2].

So the problem exposed here isn’t only that tokens are expensive. Long context also lowers accuracy: the model spends huge effort re-reading what it already read, and can still miss the constraint that actually mattered, then make a mistake it could have avoided.

The focus shifts: the question isn’t how big the window is. The question is, of those 220K tokens, which ones actually help the commit land — and which ones are just old scenery, or worse, are burying the useful signal.