Why Your Claude Code 5-Hour Window Vanishes in Minutes

You’re forty minutes into a refactor, three files deep, when the reply comes back: usage limit reached. No warning. No countdown that meant anything. The 5-hour window you were rationing all morning is just gone, mid-thought. You have no idea what ate it. You didn’t run anything unusual. You didn’t leave an overnight loop going. You were, by any normal definition, working.

This is the failure mode I kept seeing across the GitHub issue threads I read this spring. One Max 20x user watched a single prompt take them from “21% to 100% usage.” Another reported their window “gone in 90 minutes.” A third said quota “depleted in 19 minutes with normal usage” (#42249, #38335). The common thread isn’t heavy use. It’s that the cut-off arrives as a surprise, with no visible cause. You can see that you’re out. You can’t see why.

The meter you’re watching is the wrong instrument

Inside Claude Code you have /status, /context, and /cost. They tell you a number and nothing else.

/status gives you a snapshot of how much of the window you’ve used. It doesn’t show the rate you’re burning at, so a session that’s about to spike looks identical to one that’s coasting, right up until the wall. /context shows the current session’s totals, not what’s recurring turn over turn. And /cost is API-user framing. On a subscription it’s not even your real billing reference. The community worked this out already: on Max or Pro, lean on /status and /stats, not /cost.

So the standard workflow is to glance at a meter that can’t warn you, then get surprised when it hits the ceiling. The instrument isn’t broken. It’s just answering “how much is left” when the question you actually have is “what is eating it, and how fast.”

Cause one: burn rate you can’t see

Burn rate is the first invisible variable. Two sessions can sit at the same 40% mark while one is about to double its consumption on the next turn and the other will drift for another hour. Nothing in the built-in surface distinguishes them.

This is the gap the existing burn-rate tools fill. Claude-Code-Usage-Monitor and its cousins watch your consumption and project when you’ll hit the wall. That’s genuinely useful, and if all you want is a countdown, install one. But a countdown tells you the wall is coming. It doesn’t tell you what’s driving you toward it, so it can’t tell you what to change. You brace instead of fix.

Cause two: per-turn re-reads that compound

Here’s the mechanism that surprised me most, because it’s so mundane. Claude Code re-sends context on every turn. Your CLAUDE.md. Any MCP tool schemas you’ve loaded. The output of tools you called earlier. This is how the model stays coherent across a conversation, and it’s fine when the context is small. It stops being fine when it isn’t.

A 12,000-word CLAUDE.md doesn’t cost you once. It costs you on turn one, turn two, turn twenty, and turn eighty. MCP schemas injected at tens of thousands of tokens per call get re-injected. A pile of skills loaded globally rides along on every request whether or not the current task touches them. The overhead isn’t a line item you paid at the start. It’s a tax on every exchange, and a long refactor has a lot of exchanges.

One developer got tired of guessing and hand-parsed 30 days of their own JSONL transcripts. The finding: CLAUDE.md re-reads accounted for 99.93% of their quota (#24147). Almost none of their window was going to the actual work. It was going to re-reading the same instructions over and over, at full token price each turn. The tragedy is that the only way they could learn this was to write a custom parser after the fact, because nothing ships the view.

Cause three: subagent fan-out multiplies everything

Now hand part of the task to subagents. Each one gets its own copy of the context. Each one runs its own turns, with its own re-reads. If you fan out to five agents, you’re not paying the overhead once, you’re paying a version of it five times over, in parallel, faster than any single session could.

And the tools that are supposed to count this get it wrong. ccusage, the most popular usage reporter in this space, miscounts subagent tokens by up to 91x because of how it replays the parent thread (#950). So the one number you might have trusted to explain a fan-out burn is, for exactly the workload most likely to nuke your window, off by nearly two orders of magnitude. A dev who ran five agents at once put it plainly: they “had no idea what they were doing.” Neither did their tooling.

Cause four: retries and the reactive patch

Two smaller multipliers finish the picture. Retries: a tool call that fails and gets attempted again spends the tokens again, and a quiet loop can do this many times before you notice. And /compact, the tool people reach for when the window feels heavy. It fires at saturation and compresses the conversation blindly, dropping detail (which files you edited, what you’d decided). It’s reactive and lossy. Worse for diagnosis, it destroys the evidence of what was bloating context in the first place. You reach for the fix and it eats the clue.

What changes when you can see the composition

Every one of these causes has the same shape: real tokens spent on something other than the work, invisible at the moment it matters. So the fix isn’t a better countdown. It’s making the composition visible before the wall, on your own machine, from data you already have.

That’s exactly what TokenJam does (a local-first quota and session diagnostic for Claude Code). It reads the JSONL Claude Code already writes to your disk, so there’s no signup and no API key. Nothing leaves your machine. The piece aimed squarely at this problem is tj context, and it ships today. Install and run it now: pipx install tokenjam then tj context (or npx tokenjam, or uvx --from tokenjam tj). It’s a per-turn card that splits each turn into re-read-vs-work: how much of the window went to re-sending context (CLAUDE.md, schemas, tool output) versus how much went to the task. It reproduces the #24147-style finding automatically instead of by hand. It diagnoses; you act on it.

tj context isn’t the only shipped piece. Session Story reconstructs what each session actually did, and it does per-subagent attribution correctly where ccusage is 91x off, rebuilt from the same raw JSONL. So after a fan-out run you can see which agent burned what, not a number that’s wrong by design. Plan-tier reporting reads your window against the plan you’re on. An MCP server exists too, for SDK/API integrations that want an agent to query its own history mid-run; Claude Code onboarding doesn’t wire it in by default, since an in-loop MCP server is a real quota cost on every turn.

The point isn’t to squeeze out every token. It’s that a 5-hour window dying in 19 minutes should be a thing you can explain, and then prevent, rather than a surprise you reverse-engineer after it’s gone. If you want the wider context on where the spend goes, where your agent bill actually goes and the problem with tokenmaxxing both dig into adjacent ground.

To try it today:

pipx install tokenjam
# or
npx tokenjam
# or
uvx --from tokenjam tj

tj context

Common questions

Why did my 5-hour window vanish in like 20 minutes when I was barely doing anything?

Barely doing anything at the task level can still mean heavy overhead per turn. Claude Code re-sends your CLAUDE.md, any loaded MCP schemas, and prior tool output on every single turn, so a large context taxes each exchange at full price. Add a couple of subagents or a quiet retry loop and the window drains fast even though your actual edits were small. The built-in status view shows a number, not that per-turn composition, so it feels like nothing happened.

Isn't watching /status enough to avoid hitting the limit?

It tells you how much is left, not the rate you are burning or what is driving it. Two sessions at the same percentage can be on completely different trajectories, and status looks identical for both right up to the wall. It is a meter, not a warning. And on a subscription, /cost is not your real billing reference either.

Does running subagents actually burn more quota, or does it just feel that way?

It really does. Each subagent carries its own context copy and runs its own turns with their own re-reads, so fan-out multiplies the overhead rather than sharing it. It also breaks the popular counters: ccusage can miscount subagent tokens by up to 91x because of how it replays the parent thread, so the number you would check to explain the burn is unreliable for exactly that workload.

Will /compact fix this if I run it before the window fills up?

Not really. Compaction is reactive and lossy. It compresses the conversation blindly, drops detail like which files were edited, and it destroys the evidence of what was bloating context in the first place. It can reclaim some room, but it does not tell you what was recurring or what to trim, so the same bloat comes back next session.

Does TokenJam send my code or transcripts anywhere?

No. It runs entirely on your machine and reads the JSONL that Claude Code already writes to your disk. There is no signup and no API key. Nothing is uploaded. Session Story, per-subagent attribution, and the per-turn re-read-vs-work card, tj context, all work today. Install with 'pipx install tokenjam' and run 'tj context'.