Claude Code Rate Limit: Why You Hit It and the 7 Fixes That Actually Work

What actually causes the Claude Code rate limit

You are not hitting the Claude Code rate limit because you typed too much. In a real audit of session logs, what a user actually typed accounted for 0.01% of total token spend. The rest comes from a mechanism baked into how these models work: they have no memory between messages, so every single turn resends your entire conversation history from the top. By message 20, the thing you just wrote is a sliver at the top of a much bigger, already-paid-for stack underneath it.

Fix that mechanism and you cut your usage limit problem down to almost nothing. This article covers the audit prompt to find your own numbers, then seven fixes ranked by how much they actually save, plus the advice that sounds smart but makes your bill worse.

Why your session hits the limit so fast (the mechanism)

Claude, like every LLM, is stateless. It doesn't remember your last message. So every time you hit enter, the client wraps up the full conversation so far and sends it again, plus your new message.

That means:

• Message 1 costs what you typed.
• Message 2 costs what you typed, plus the answer, plus message 1.
• Message 20 costs what you typed, plus everything that happened in the previous 19 turns.

A 3,000 token file your agent reads at turn 4 of a 40-turn session doesn't cost you 3,000 tokens once. It costs you 3,000 tokens on every one of the 37 turns that follow, because it's still sitting in the history that gets resent. This is why usage looks fine for an hour and then suddenly you're told to come back in 5 hours. It's compounding, not a sudden spike in what you asked for.

The audit prompt: paste this into Claude Code first

Before you change anything, find out where your own tokens are going. Your setup is not the same as anyone else's. Paste this into Claude Code:

Audit my current Claude Code configuration and usage. Specifically:
1. Run /context and break down what is consuming context right now, by category (system prompt, tools, memory files, conversation history).
2. Check whether tool deferral is active (look for "deferred" in the tools line of /context output).
3. Measure the size of my memory files (CLAUDE.md and any project-level memory).
4. Estimate my cache hit ratio based on recent session logs.
5. List any scheduled tasks or background agents configured, their run interval, and whether that interval is shorter than the 1-hour cache expiry.
6. Summarize which of these is costing me the most tokens and rank them.

This reads your real context breakdown, checks tool deferral, measures your memory files, estimates your cache hit ratio, and flags scheduled tasks firing while you're away. Run it once, then use the fixes below in the order your own audit ranks them, not in the order someone else's video ranks them.

What does /clear actually do, and why is it the best fix

The highest leverage fix costs nothing. When you finish one job and start a different one, run:

/clear

That old conversation isn't sitting there quietly. It gets resent on every message until the session ends. A session that had climbed to 80,000 tokens of context drops back to 0% the moment you run /clear. Anthropic's own docs say plainly: when you want a fresh start instead of continuity, use /clear.

Here's why it beats every other fix on this list: every other fix reduces one component of your context. Clearing resets the entire base that all those components are a fraction of. In one real audit, 96% of total spend was the agent rereading history it had already paid for once. /clear is the only fix that deletes the history itself.

One step first: rename the session before you clear it.

/rename

That lets you /resume it later if you need it. You're not throwing work away, you're just stopping the next job from carrying the last one's weight.

Why switching Claude models mid-session doubles your bill

This is the trap that feels like the responsible move. You're running low, so you hit /model, drop from Opus to Sonnet, and feel good about saving money.

That switch is often the most expensive single action you can take. Here's why. Your conversation is cached, and cache reads cost about a tenth of normal processing. That cache is what keeps long sessions from bankrupting you. But the model is part of the cache key. Change the model and none of your history matches the cache anymore, so the entire conversation gets reprocessed at full price.

On a large context window, that can turn a 10-cent turn into a 1-dollar turn: 10 times more expensive, and it happens invisibly while you're trying to cut costs.

The same thing happens with:

• Switching effort level
• Turning on fast mode
• Connecting or disconnecting an MCP server that loads its tools upfront
• Enabling a plugin that ships its own MCP server
• Compacting
• Upgrading Claude Code and then resuming a long session (Anthropic's docs call this the single most expensive request you can send)

Things that are safe and don't touch the cache key: editing files in your repo, editing your memory file, changing output style, changing permission mode, invoking skills and commands, rewinds, and spawning a sub-agent.

The rule: pick your model and effort level at the start of a session and leave them alone. If you want a cheaper model, start the session on it.

How do you stop command output from eating your context

You type "install remotion for me." The agent runs the real install command and 800 lines come back: package names, version numbers, warnings, a funding message. You read none of it. But the agent doesn't get to skim, so all 800 lines land in your conversation, and you pay for them again on every message until you clear.

The fix is a filter that sits between your agent and the raw command output, trimming it before your agent ever sees it. Anthropic ships a working example of exactly this pattern, and their own numbers show it cutting output from tens of thousands of tokens down to hundreds. Ask your agent to build one:

Write a small wrapper script that runs my install/build commands and
strips output down to just the result (success/failure, errors, and
the final package version). Use Anthropic's own output-filtering
example as a reference pattern. Save it so I can reuse it for every
command that produces long output.

You build it once. It works on every session after that.

Should you disconnect MCP tools you don't use

Every tool you connect, Gmail, Notion, Slack, ships with an instruction manual describing what it does and how to call it. Your agent has to load that manual before it can touch the tool. GitHub alone costs about 26,000 tokens. Slack costs about 21,000. All of that used to load into every session before you typed a word.

Claude Code now defers tool manuals by default: it loads a table of contents and only opens the section it needs when it needs it, cutting that cost by roughly 85%. That part is handled for you.

But you're still paying for the table of contents itself, and it grows every time you connect something new. So:

1. Open your tool connections panel.
2. Turn off anything you haven't used in the last month. This doesn't delete the connection, it just stops it from loading.
3. Run /context and check the tools line.

If it says "deferred," you're on the new behavior and manuals stay shut until used. Turning tools off mid-session is free, it doesn't rebuild your cache the way switching models does, it only appends a change.

Do sub-agents actually save tokens

Mostly not the way people say. Sub-agents move tokens, they don't eliminate them. In one documented example, a sub-agent read about 6,000 tokens of files and returned a 420-token summary to the main session, which looks like a huge win in your main context window. But the sub-agent still burned its own system prompt, its own copy of your memory file, and its own tools to do that reading. Total cost: roughly 9,800 tokens spent to save 5,700 tokens in the main thread. In isolation, that's a loss.

Anthropic's own multi-agent research post states it directly: agents use roughly 4 times more tokens than a plain chat, and multi-agent systems use roughly 15 times more.

Sub-agents are worth it only when all three are true:

That third condition is the whole game. If you delegate and then end the session immediately, you paid extra for nothing. One free upgrade: set the sub-agent's model to Haiku. That's roughly a 5x reduction on the isolated work and it doesn't touch your main session's cache.

How do scheduled tasks blow up your bill overnight

A scheduled task fires on its interval whether you're there or not, and every fire sends your full context, not a slice of it. If that task is attached to a bloated session, you pay for that entire context on every fire, forever, including at 3am.

Here's what makes it worse: cache expires. On a subscription plan, the cache lasts about 1 hour. If your task runs less often than once an hour, every fire misses the cache and gets reprocessed at full price instead of the roughly one-tenth cache price. That's 10x the cost, on a schedule, indefinitely.

So the run interval is a real cost setting. If a task can run every 45 minutes instead of every 2 hours, running it more often is actually cheaper, because it stays inside the cache window.

One correction while we're here: leaving Claude Code open in the background is not your problem. Anthropic documents idle background usage at under 4 cents a session. Your scheduled tasks and any live agent teams that keep running until they exit are the real cost, because each one consumes tokens the entire time it's active.

What token-saving advice is actually wrong

Some popular advice makes your bill worse, not better.

• Writing shorter prompts. What you actually type is a rounding error, around 0.01% of spend in a real audit. Vague prompts do cost you, but through the file reads and rework they trigger, not through length.
• Compacting to save tokens. Backwards. To write a summary, Claude has to send your entire conversation one more time, making the "savings" move the single most expensive message of the session. It also wipes your cache, since the old conversation no longer exists to match against. Compaction buys continuity, not savings. If you just want to undo a few turns, use /rewind instead, it goes back to a point the cache already knows, so nothing gets reread.
• Screenshotting text to save tokens. A picture is not cheaper than the words in it. A screenshot can cost around 2,700 tokens, a 4K one nearly 5,000. Paste the text instead. It's cheaper, and your agent can actually edit text, not a picture.
• Uploading PDFs. Every page costs roughly 1,500 to 3,000 tokens for the text, and the agent also takes an image of the page, so you pay for it twice. Ask your agent to convert it to plain text first. Same document, roughly a quarter of the cost.

Which Claude Code commands should you check regularly

Four things tell you what's actually happening, and three of them are already in your terminal:

• /context, shows exactly what's in your window right now, line by line.
• /usage, shows how much of your plan you've burned and names the specific skill, tool, or agent responsible.
• /cost, shows what the current session is costing and how much of that is rereading history versus new work.
• The burn rate meter in the corner of the Claude Code screen. Watching a number move while you work changes your habits faster than any rule.

Every session you run gets logged to a folder on your machine, and every reply records its own cost. Ask your agent to read through those logs and calculate your own breakdown instead of trusting anyone else's numbers, including the ones in this article.

The 7 fixes, ranked by what they actually save

What to do next

Run the audit prompt in this article once this week, and again about once a week after that or whenever you feel your limit dropping faster than usual. Setups drift: you add a connector, install a plugin, or change a setting, and six weeks later you're back to wondering why you're hitting the rate limit again. Start with /clear between jobs since it costs nothing, lock your model and effort at the start of each session, and check /context for "deferred" on your tools line. Those three alone fix most of what's actually burning your budget.