Why you hit your Claude Code weekly limit on Thursday

You were mid-task. Thursday afternoon, deep in something, and the wall arrived.

The first reaction is that it was arbitrary. The second is that you must have been hammering it. The second one is the expensive mistake, because it leads to the advice everyone gives themselves next, which is to use it less.

You don't need to use it less. You need to know which of about five habits is quietly costing you most of your week, and that turns out to have a real answer sitting in a folder on your laptop.

Why it feels random

The cause and the symptom are days apart.

The sessions that spent your rate-limit window probably happened Monday. The wall shows up Thursday. Nothing in between connects them, so there's no feedback loop tight enough to learn from. By the time you get the signal you've forgotten which session was the expensive one, and at the time it didn't feel different from any other.

Compare that to almost every other cost in software. A slow test suite is slow while you wait for it. A bloated bundle shows up in the build output. But a session that burned four times what it needed to looks identical from the inside. Same speed, same output, no number printed anywhere.

So the pattern survives contact with experience. It repeats next week, and the week after.

The mechanism nobody explains: your context is cached

Most explanations of token cost stop at "you pay for every token in the window on every turn." That's true about tokens and misleading about money, and the gap between those two is where most of your week goes.

Here is what happens underneath. Reprocessing your entire conversation from scratch on every turn would be enormously wasteful, so the provider caches it. On the next turn, the parts that haven't changed get read from cache instead of processed fresh. A cache read costs roughly a tenth of what the same tokens cost as new input. That discount is the only reason a two-hour session is affordable at all.

Now the part that costs you. The cache is a prefix match. It compares your context from the very beginning, token by token, and stops at the first difference. Everything from that point onward is a cache miss and has to be written to cache again. And writing is not free: on the standard bucket it costs more than sending the tokens uncached in the first place, because you're paying for storage as well as processing.

Put the two together and you get a price cliff. The same tokens, sitting in the same window, cost either about a tenth of input or about one-and-a-quarter times input depending entirely on whether the prefix still matches. That's better than a tenfold swing on identical content, decided by something you never see.

What breaks the cache

Four ordinary things, none of which announce themselves:

• Editing a file that's already in context: the old contents are sitting in the prefix, so changing them forces everything after that point to be rebuilt. A session that alternates read, edit, read, edit costs considerably more than one that reads what it needs and then makes its changes.
• Going idle: cached context expires after a few minutes. Take a call, go to lunch, get pulled into a review, and your next turn re-writes the whole context at the higher write rate. You pay for being away from your desk.
• Compaction: when the window fills, the agent summarizes and continues from the summary. That summary is a new prefix, so the cache is rebuilt around it.
• Changing configuration mid-session: standing instructions sit at the very front of the window. Touch your CLAUDE.md or add a skill while a session is open and you've invalidated the prefix at position zero, which means all of it.

None of this is a flaw. Caching is what makes the whole thing viable. But the shape of the cost is not the shape most people assume, and it explains something you've probably felt without being able to name: some sessions are inexplicably expensive, and they tend to be the stop-start ones rather than the long focused ones.

The practical consequence is worth stating plainly. Uninterrupted work is cheaper than the same work spread across a day. Batching your edits is cheaper than interleaving them with reads. Neither of those is obvious from the outside, and neither has anything to do with how much you typed.

What else spends the window

Cache behaviour is the biggest single lever, and four other things matter:

• Sheer carry: even at cache-read rates, a window twice the size the task needed costs about twice as much on every turn. Cheap per token is not free per token.
• Re-reads: the agent opening a file it already has in context. You pay twice for one thing, and the second copy takes up room, which drags you closer to compaction, which rebuilds the cache. This one compounds.
• Oversized models on routine work: tiers differ severalfold per token, and over-modelling has no symptom, so the default drifts to the largest model and stays there for months.
• Standing configuration: your CLAUDE.md, skills, plugins, and MCP definitions are loaded before you've stated the task and carried on every turn afterwards.
• Grind: the third, fourth, and fifth attempt at something that stopped working on the second.

Notice what isn't on the list. How much code you generated barely registers. Output tokens are a small share of the total for almost everyone, which is why the thing that felt like the work is rarely the thing that spent the window.

Most people have one habit, not five

If everyone had a bit of all five, "be more careful" would be reasonable advice.

They don't. In practice one habit dominates and the rest are noise. One person runs a single sprawling session all week and never restarts it. Another has a CLAUDE.md that's been growing for a year, charged on every turn of every session. A third set their model once, months ago, to the largest available, and has sent every trivial rename there since. A fourth works in ten-minute bursts between meetings and pays the cache-write penalty six times a day.

Those are four different problems with four different fixes, and three of the four fixes would do nothing for the others. The first person should start new sessions and shouldn't touch their model settings. The fourth should batch their work into fewer, longer sittings and would gain nothing from pruning config.

This is why generic advice fails here. "Be mindful of context" is true for everyone and useful to no one. The question worth answering is which one is yours, and that's a measurement rather than an opinion.

You already have the data

Claude Code writes a transcript of every session to ~/.claude/projects, and has been doing so the whole time. Those transcripts carry the token accounting, including the cache-read and cache-write buckets separately, along with the tool calls and file paths. Everything above is reconstructable from them after the fact, with no instrumentation set up in advance.

npx @promptster/cc-audit

It reads what's on your disk, prints to your terminal, and sends nothing. No account, no sign-up. The analysis works from token accounting, tool calls, and paths, so the contents of your files are never opened.

It will tell you what share of your spend went to carrying context rather than producing output, how often the agent re-read a file it already had and which files those were, what your standing configuration costs per turn, and the context size past which your own sessions start to degrade. That last number is personal, and it isn't one you can get from a blog post.

Then you'll know which of the five is yours. Fix that one, and Thursday stops being a thing that happens to you.