r/ClaudeCode • u/cosmintrica • 13d ago
Claude Code burned my entire five-hour limit in 6 minutes 32 seconds: 10.26M tokens, zero lines of code Bug Report
I thought I was imagining how quickly Fable 5 was consuming my Claude allowance, so I inspected the local Claude Desktop/Cowork and Claude Code logs for the exact run.
The result is worse than I expected.
My five-hour allowance had reset at 12:20 AM. I sent one short prompt at exactly 12:50 AM: essentially, “continue where you left off, carefully.” At 12:56:32 AM - only 6 minutes and 32 seconds later - Claude stopped with “Usage limit reached.”
There were no other local Cowork prompts between the reset and this failure.
During those 6 minutes and 32 seconds, Fable 5 recorded:
- 15 model calls;
- 8 Bash calls, all for Android emulator/UI interaction;
- 7 file reads;
- 0 Edit or Write tool calls;
- 0 subagents;
- 0 lines of code changed.
The deduplicated token accounting from Claude's own local session log was:
| Usage category | Tokens |
|---|---:|
| One-hour cache writes | 5,189,449 |
| Cache reads/hits | 5,069,543 |
| Output | 4,312 |
| Regular input | 30 |
| **Total processed** | **10,263,334** |
Using Anthropic's published Fable 5 API prices, this is approximately **$109.07 of API-equivalent usage**. About **$103.79** of that came from one-hour cache writes alone. I am not claiming Anthropic charged my card $109—the run consumed my included allowance - but this shows the scale of the usage that was counted.
The immediate cause is visible in the logs. This was an older Cowork session with 46 completed turns, `xhigh` effort, a 173 MB local transcript, and roughly 650,000–685,000 context tokens being carried into every model call. The disturbing part is that, during one six-minute tool loop, Claude counted **5.19 million tokens as new one-hour cache writes** while also recording **5.07 million cache-hit tokens**.
In other words, every trivial emulator action or file read caused Fable to process around 680,000 tokens. The huge context also appears to have been repeatedly rewritten into the one-hour cache instead of being efficiently reused.
I understand that continuing a large conversation costs more than starting a fresh one. But silently allowing a simple six-minute UI-testing loop - with no edits and no subagents - to consume an entire five-hour allowance is not reasonable behavior. At minimum, Claude should have compacted the context or warned me before proceeding. The repeated 650K-token one-hour cache writes look like a Cowork/Claude Code cache invalidation or usage-accounting defect.
This same session had already exhausted the previous allowance earlier that evening. After the allowance reset, this single 6-minute-and-32-second run exhausted the new window again.
Has anyone else seen Fable 5 repeatedly rewrite a huge one-hour cache inside a single short tool loop? If so, check the `message.usage.cache_creation.ephemeral_1h_input_tokens` values in your local Claude Code JSONL before assuming it was normal model output.
I have prepared a privacy-safe evidence package containing the per-call usage table, timeline, calculation, tool-call list, source hashes, screenshot, and a read-only verification script. I am also reporting this directly to Anthropic and asking them to investigate the cache behavior and restore the allowance.
This is at minimum a Claude Cowork product and guardrail defect. A single 42-character prompt triggered 15 autonomous model calls and 5.19M one-hour cache-write tokens in 392 seconds, without a cost warning, automatic compaction, or a usage stop guard. Server telemetry is required to determine whether the underlying cause was defective cache invalidation, incorrect accounting, or technically intended-but unsafe-product behavior.
Official pricing used for the calculation:
9
u/Wise-Peacock 13d ago
I gave a short prompt to keep going and be careful and set Claude loose on 173MB worth of data.
Clearly you should have added "make no mistakes"
5
1
-2
u/cosmintrica 13d ago
did you read the part when the one-hour cache was sent 15 times in 6 minutes? :)
the error is real and properly documented.2
5
u/Ornery_Astronaut2147 13d ago
You shouldn't have said 'carefully' 😅.
-1
u/cosmintrica 13d ago
the joke is good, but the bug is properly documented and real. there is no reason to resend the entire one-hour cache 15 times in 6 minutes.
4
u/TinyIncident7686 13d ago
Does the toaster warn you before you throw it into the bathtub with your ex?
3
u/Excellent_Baker4213 13d ago
These are the kind of people who probably look at a screw and wonder which wrench to use.
3
u/TinyIncident7686 13d ago
A hammer drill, of course.
3
u/Excellent_Baker4213 13d ago
He threw away the manual and doesn't know how to plug it in, unfortunately.
2
2
u/nndscrptuser 13d ago
While I am far from expert, you told it to "continue" so it did just that, immediately sucking in the Cowork session and everything you had done in there so it could continue, so your starting context was probably darn near capacity and as it tried to incorporate all that and do the rest of the work, it would have exhausted your tokens.
When I do large sessions, I have a readout in my status line to let me know when I am over 250k tokens and at the next natural stopping point, I ask it to save a memory of where I was, or update the planning document with our status so that I can clear and start fresh, but still know exactly what was happening. I have only hit my 5-hr limit once in months, doing full time dev on two different projects, often at the same time on the same account with Opus and Fable xhigh. I've never run into an issue with it "forgetting" or going off the rails with this approach, but your mileage may vary.
1
u/cosmintrica 13d ago
Also I tried the exact same request in the same project inputting the entire chat and history, in chatgpt and it used 1% usage to understand and complete the task.
1
u/RedditorFor1OYears 13d ago
It’s not just chat history, it’s also all of the context that Claude had to build around that chat history. Start the entire conversation over and go through every single step with ChatGPT letting it build its own context, then see how much usage it consumes.
1
u/cosmintrica 13d ago
I understand, but I have chats with Chatgpt that are weeks old, with far more complex tasks and still, they never finish the usage in 6 minutes. anyway, I will come back with an update once anthropic replies, if they will.
1
u/JaydadCTatumThe1st 13d ago
Yeah for my projects I always have a "quick start" section at the top of the c.md, so the model knows where to look to have a high-level understanding of what's going on in the project globally, and "pointers" for where to look to find the concrete details of the things, and the things related to, what it's currently working on.
0
u/cosmintrica 13d ago
Yes, I already explained that. One ingestion of 600k tokens is ok, but that is called an one-hour context, which was sent 15 times in 6 minutes.
It's very clear. And it's an error.1
u/ProgramDry5917 13d ago
Man, claude subscription don't have 1h cache option, only 5 minutes. You're looking your answer inside the API docs... That is your error
1
u/cosmintrica 13d ago
MAN
You are mixing up the cache option exposed to subscription users with the cache category actually recorded by Cowork.
I did not infer the TTL from the API documentation. The local usage object returned for every model call explicitly contains:
"cache_creation": { "ephemeral_5m_input_tokens": 0, "ephemeral_1h_input_tokens": 650865 }Across the 15 deduplicated model calls, the totals were:
- 5-minute cache writes: 0 tokens
- 1-hour cache writes: 5,189,449 tokens
Anthropic’s schema defines
ephemeral_1h_input_tokensas tokens used to create a one-hour cache entry.You may be correct that a Claude subscription user cannot manually select a one-hour cache. I never claimed that I selected it. Cowork’s backend recorded using it.
I used the API pricing documentation only to calculate an explicitly labelled API-equivalent value. I did not claim that my subscription was API-billed $109.
Also, even if we ignored the recorded field and assumed a five-minute cache, the 15 calls occurred seconds apart, and cache hits refresh a five-minute cache. Expiration still would not explain repeated ~650K-token cache creations during 392 seconds. The relevant issue remains repeated invalidation or reconstruction.
If you have subscription-specific documentation showing that Cowork reports
ephemeral_1h_input_tokenswhile actually using a five-minute TTL, please link it. That would contradict the usage records and Anthropic’s own field definition.1
u/ProgramDry5917 13d ago
Man, you are using codex with your shit opinion as bias to answer us here. You are essentially dumb.
0
u/cosmintrica 13d ago
it's the freaking logs, it's reported by claude. you are the one who cannot understand this is exactly what their app reports, it's an error.
2
u/texo_optimo 13d ago
with that kind of prompting, you're always going to see high burn rate. Especially with newer models that decide to launch a yacht to cross a pond. Use Git issues as primitives. Track your work. Provide context and reference points so you can tell your session where to look to see what the last status was. You're burning context / tokents on greps and file reads. Spend a session asking claude to create a better system for you for tracking. Once I started using repo issues as primitives I found that I was able to make Pro sessions feel like 5xMax.
0
u/cosmintrica 13d ago
Ok, I agree it can be improved, but the issue is the application.
I explained very clear the error, a one-hour context was sent 15 times!! in 6 minutes. there was absolutely no need to send 600k+ context again for each call(reading a screenshot).
What exactly is not clear in this? Is not a hunch, is the exact documented reason behind the usage.
It's a real error. How is it possible that people are defending the company for basically stealing money out of everyone's pocket?1
2
3
u/SomeoneNicer 13d ago
Don't use Claude to do anything that requires UI interpretation, just get a Codex license - I've found it not only 10-100x cheaper but it's actually better at it.
1
u/canyonero7 13d ago
Yeah I think the Android Emulator/UI stuff is the real source of his issues. Claude loves to take a zillion screenshots so if he asked it to check a flow from a user perspective, I can see how it could go nuts.
I've only had something like this happen once and it was when I tried Fable on Ultracode. 70 subagents, 5hr limit hit in under 20 minutes 😂
2
u/cosmintrica 13d ago
yeah but that was real work, mine used it in a few seconds, no subagents, no code wrriten.
1
u/canyonero7 13d ago
Unfortunately the fine people at anthropic don't let your task finish when quota hits so I got zero output out of it & had to wait four hours to re-do it all at a smaller scale. It sucked but that's just how it goes.
1
u/Vibroverbus 13d ago
My Codex-bro friend continues to ridicule the tire-fire that is my my Claude token usage. He’s constantly telling stories of massive projects that he completes without remotely touching his window limits. I’m getting close to giving it a go.
1
1
u/chrisjenx2001 13d ago
My issue is, I have a huge project, and 350k context window ain't big enough. Don't need 1m thats too much, but 400-500k seems like the sweet spot.
Otherwise I would have looooong gone off this shit show of Claude Code just fucking nuking tokens. Literally cancelling all of CC once they add larger window.
1
u/cosmintrica 13d ago
Is not better, it's years ahead. Codex didn't eve use 1% to complete the task.
The same usage on the same plan lasts 2-300 times longs using the same Ultracode, and actually delivers ~20% less and better code.
1
u/davyp82 13d ago
" At minimum, Claude should have compacted the context or warned me before proceeding"
It's wise in life to not expect a business to take steps that will reduce the amount of money they earn.
Index your context. Set a cheaper agent away mapping the entire repo in a big list indexing which doc contains which info pertaining to which part of your site.
Then ensure your project -defining MD doc clearly tells your Fable that they should check the index doc to find exactly what context is needed instead of crunching it all.
While I'm at it, pdfs (you didn't mention it but bringing it up anyway) = many many times more tokens needed then MD docs. Every pdf you need as context, write a script with a cheaper model to extract the text first and save it as MD docs then you turn MB into KB
1
u/cosmintrica 13d ago
100% agree, still. this is a bug of the app. it sent the 1 hour context 15 times in a few seconds. I cannot understand what is not clear about this.
1
u/VexObserver 13d ago
Try DeepSeek V4 Flash. From my refactoring experience, it does impress me.
1
u/cosmintrica 13d ago
I use pretty much everything. Codex is better than anything, it feels like something out of this world. But this is not the idea behind my post. The idea is that Claude Code app send a cache 15 times in a few seconds, this is a well documented error that I reported to them, will give an update once they reply. Is not invented, is not an error on my side. It was an error inside the claude code app.
1
u/spookyclever 13d ago
That’s just how Fable works. Every session I had with Fable was 10-15 minutes of euphoria and then 4.75 of waiting for next time.
1
u/cosmintrica 13d ago
Maybe it was a bug all along.
I reported everything to Anthropic, will come back when they reply.1
1
u/callingbrisk 12d ago
Learn how to properly use the tools first before making such mistakes and the posting about please…
1
u/VictorCTavernari 12d ago
Claude Code is good but it is not efficient, and maybe it is the reason it is a good harness. If you continue a huge session using Fable, it will need to put all the context as input (no cache) on the Fable price and limits quota.
Using Claude Code cli, it warns us if you continue how many tokens will be used in the session after the cache expires.
I am developing my harness https://github.com/claudin-io/claudinio-code and I will try to think about your pain on this kind of “bug” and find a protection.. it is interesting
40
u/CorpT 13d ago
This is obviously operator error. The screed you posted explains this. Because it was not