Why does Claude Code use up my limit so fast?

Because every reply sends the whole conversation to the model again: your messages, its answers, every file it read and every command output. Prompt caching makes those re-reads cheaper, but late in a long session each one-line question still carries the entire history. In a month of our own sessions, re-reading was 53% of usage, and replies with more than 150,000 tokens of context made 68% of it.

Does Claude Code use prompt caching?

Yes, on its own. Each request starts with the same system prompt, project context and conversation as the one before, so that part is read from the cache at the cached token rate and only the new part is processed in full. On a Claude plan the main conversation's cache lasts an hour after its last use; once you draw on usage credits, or with an API key, it lasts 5 minutes by default.

What breaks the Claude Code cache?

A break longer than the cache's lifetime, switching model (each model has its own cache), turning on fast mode, connecting an MCP server whose tools load up front, enabling some plugins, compacting the conversation and upgrading Claude Code. The next reply then writes the whole history to the cache again.

Is /compact or /clear better for saving usage?

/clear, when you are starting unrelated work: it costs nothing and the next task begins with a short context. /compact is for keeping going on the same task with less history. It reads the conversation it summarises, cheaply while the cache is warm and at full price after a long break, so run it at a natural pause rather than waiting for automatic compaction.

How can I see where my Claude Code usage goes?

Run /usage. On a plan it shows how much of your limits you have used, what used it, and flags long context or cache misses when either is 10% or more of recent use; its Prompt cache line shows the cache hit rate and misses for the session. For a month at once, our free ReRead command reads the session files on your machine and shows how much was re-reading, when the cache was lost and why.

Why Claude Code eats your limit

Every reply sends the whole conversation to the model again. Over a month of our own Claude Code sessions, 53% of usage was that re-reading, and replies past 150,000 tokens of context made 68% of it. Here is where the limit goes, and the habits that keep it.

Tecyfy · Published 22 October 2026 · 7 min read

A machine swallows an ever longer paper scroll as its gauge drops, showing why Claude Code re-reads the chat and eats your limit

Claude Code eats your limit because every reply sends the whole conversation to the model again. Your messages, its answers, every file it read and every command's output go back with each new request, so a one-line question late in a long session carries hours of history with it. Prompt caching makes those re-reads cheaper, but it does not make them free.

We measured a month of our own Claude Code use: 129 sessions and 43,193 replies. 53% of the usage was the model re-reading history, not doing new work. Replies with more than 150,000 tokens of context made 68% of it.

Every reply starts from zero

A model remembers nothing between requests. So each time you send a message, Claude Code sends the system prompt, your CLAUDE.md, every earlier message and every tool result, then your new line at the end. Each time Claude runs a tool, the result goes back in another request carrying all of that again. One task can be dozens of requests.

Prompt caching is what keeps this affordable. Each request starts exactly like the one before, so the API reads that unchanged start from the cache at a fraction of the input price, and only the new part at the end is processed in full. On Claude Sonnet 5.5 and Opus 5.5 a cache read costs 5% of the normal input price.

5% of a very large number is still large. Anthropic's own example of the /usage Session block shows 940,000 tokens read from the cache against 1,200 tokens of new input in one session. That is the shape of nearly every Claude Code session: the new work is small, and the history read again is huge.

Long sessions cost more with every reply

Re-reading grows with the session. At 20,000 tokens of context each reply reads 20,000 tokens back. At 150,000, each reply reads 150,000. So 100 replies late in a long session read 15 million tokens from the cache, while the same 100 replies at the start of a fresh session read 2 million.

That is why the share of usage from long contexts is so lopsided. In our month, replies past 150,000 tokens of context made 68% of all usage, and the 10 costliest sessions made 45%. None of those sessions did unusual work. They had simply run for a long time, through several tasks, without a fresh start.

On a Claude plan you never see this as a bill, only as the limit running out. Anthropic's docs put it plainly: a one-line question in a session that has been open all day still draws usage for the whole conversation.

Losing the cache writes it all again

The cache only helps while the start of each request stays the same and the cache is still alive. When either fails, the next reply writes the whole history to the cache again, at 1.25 times the input price with the 5-minute cache or 2 times with the 1-hour cache. On Sonnet 5.5, one such rewrite of a 150,000-token context costs as much as 25 replies read from the 5-minute cache, or 40 from the 1-hour cache.

It happens for 3 kinds of reason:

A break longer than the cache's lifetime. On a Claude plan the main conversation's cache lasts an hour after its last use. It drops to 5 minutes once you draw on usage credits, and it is 5 minutes by default with an API key.
A switch of model. Each model has its own cache, so the first reply after /model reads the whole conversation with no cache hits. Turning on fast mode does the same, and so does changing the effort level on most models other than Opus 5.5, Sonnet 5.5, Haiku 5.5 and Fable 5.1.
A change near the start of the context. Tool definitions sit at the top of every request. When an MCP server's tools load up front rather than through tool search (the default on current models), connecting or removing that server mid-session changes the top, and everything after it is processed again.

Compaction also replaces the history by design, and an upgrade of Claude Code starts the next conversation's cache from the top.

Losing the cache is the cause people talk about most, but in our month it was the smaller one: 81 rewrites cost 3.2% of usage. The other 50% was ordinary re-reading in sessions that had grown long.

Habits that make the limit last

Start fresh for each new task. /clear costs nothing, and a new task that starts at a short context reads far less on every reply. Run /rename first if you may want the old session back with /resume. This is the largest single saving, because it cuts the 68% at its source.

Compact at a pause, with instructions. /compact summarises the history so the session keeps going with less of it. Anthropic notes it reads the conversation it summarises: cheaply while the cache is warm, at full price after a long break. So run it between steps, before you walk away, and tell it what to keep: /compact keep the failing test names and the files changed. Our sessions were compacted at 279,000 tokens on average, mostly automatically, which means most of their replies had already paid for a very large context. If you went down a wrong path, /rewind to an earlier turn instead: it goes back to a start that is already cached.

Pick the model at the start. Choose Sonnet or Opus for the task before it begins, not halfway through a long session, and leave fast mode as it is until the next task.

Change tools between tasks. Add MCP servers and plugins when you start a session, not in the middle of one. Editing CLAUDE.md mid-session does not break the cache, but the change only applies after /clear, /compact or a restart.

Keep the start small. CLAUDE.md is read again on every reply, so keep it short (Anthropic suggests under 200 lines) and move long procedures into skills, which load only when used. Send noisy work, such as a test run or a log search, to a subagent, so only its summary joins your conversation.

See where your own usage goes

Run /usage. On a plan it shows how much of your limits you have used and what used it, and it flags long context or cache misses when either is 10% or more of recent use. Its Prompt cache line shows the session's cache hit rate, its misses and whether the cache is warm right now.

For a whole month at once, we made ReRead, a free command. npx reread-cli reads the session files Claude Code already keeps on your machine, using only their token counts, and shows how much of your usage was re-reading, when the cache was lost and why, and which sessions cost the most. It sends nothing anywhere. Plans measure usage their own way, so it weighs each kind of token by its API price: treat the share as a guide to where the limit goes, not as your plan's meter.

Claude Code cost has the full list of ways to use fewer tokens, sessions covers /clear, /compact and /resume, and the prompt caching calculator prices a repeated prompt on each Claude model with the 5-minute and the 1-hour cache.

Questions

Why does Claude Code use up my limit so fast?: Because every reply sends the whole conversation to the model again: your messages, its answers, every file it read and every command output. Prompt caching makes those re-reads cheaper, but late in a long session each one-line question still carries the entire history. In a month of our own sessions, re-reading was 53% of usage, and replies with more than 150,000 tokens of context made 68% of it.
Does Claude Code use prompt caching?: Yes, on its own. Each request starts with the same system prompt, project context and conversation as the one before, so that part is read from the cache at the cached token rate and only the new part is processed in full. On a Claude plan the main conversation's cache lasts an hour after its last use; once you draw on usage credits, or with an API key, it lasts 5 minutes by default.
What breaks the Claude Code cache?: A break longer than the cache's lifetime, switching model (each model has its own cache), turning on fast mode, connecting an MCP server whose tools load up front, enabling some plugins, compacting the conversation and upgrading Claude Code. The next reply then writes the whole history to the cache again.
Is /compact or /clear better for saving usage?: /clear, when you are starting unrelated work: it costs nothing and the next task begins with a short context. /compact is for keeping going on the same task with less history. It reads the conversation it summarises, cheaply while the cache is warm and at full price after a long break, so run it at a natural pause rather than waiting for automatic compaction.
How can I see where my Claude Code usage goes?: Run /usage. On a plan it shows how much of your limits you have used, what used it, and flags long context or cache misses when either is 10% or more of recent use; its Prompt cache line shows the cache hit rate and misses for the session. For a month at once, our free ReRead command reads the session files on your machine and shows how much was re-reading, when the cache was lost and why.

Sources