How Do I Stop Hitting Claude Code Usage Limits Without Max?

How do I stop hitting Claude Code usage limits without upgrading to Max?

Stop resending large chats. Claude Code bills you for the context it reads on every message, and Anthropic's default cache expires after about an hour. So avoid running /compact on an old chat, save state to handoff and context files, trim what loads before your first prompt, keep model and effort settings steady, check /usage to see what is eating your limit, and extend the sub-agent cache TTL for long jobs.

Why do Claude Code limits run out so fast?

Reddit threads on this split into two camps. One says Anthropic cut limits. The other says to check your context. In one thread, a user was starting every chat at 150,000 tokens, which explains a lot.

The mechanism is caching. Each new message sends the whole conversation back to the model. While the prompt cache is warm, that costs a fraction of full price (the source puts it at about a tenth). On a subscription, the main chat's cache lasts an hour. Come back after that, and your first message pays full price to re-read everything.

Every habit below either keeps the cache warm, avoids needing it, or shrinks what gets sent.

Why is /compact a bad idea on a long chat you came back to?

/compact summarizes the chat. To summarize it, Claude has to read all of it. If the cache is still warm, that is cheap. If the cache expired on a big conversation, /compact becomes a large full-price request by itself.

/clear costs nothing but throws away all context. The useful middle ground is a handoff file.

How do I write a handoff file?

Before you stop a session, ask Claude to write a handoff.md. Then /clear and tell the new session to start from that file. Anthropic uses a similar pattern for its long-running agents: each session leaves a progress note and a commit, so the next session can see the state of the work.

Keep the handoff to what a fresh chat cannot work out on its own:

• The goal
• What is done
• What should come next
• Files already touched
• Decisions made
• What did not work, so it does not get retried

Should I resume yesterday's chat or start a new one?

Resume only if you left less than an hour ago. Anything older will re-cache the full history at full price on your next message.

If you still need the context, save it to a file at the end of the earlier chat. For example, after an hour of settling on three pricing tiers, type something like "save the pricing we agreed into pricing.md." Next day, open a fresh chat and ask it to read pricing.md and write the pricing page. Claude skips the hour of back-and-forth and reads only the conclusions.

The same logic applies to model choice. Pick the right model at the start, because switching halfway through a job discards the cache.

How do I audit what loads before I type anything?

Open a fresh chat and run /context. Since the desktop update, you can see this straight away in a new Claude Code chat. It lists your CLAUDE.md, installed skills and plugins, and memory files. You pay for all of it on every message.

MCP servers used to be the main offender because their schemas loaded constantly. According to the source, their tools now load only when Claude needs one, so they matter less.

Practical trims:

1. Keep CLAUDE.md under 200 lines.
2. Move repeatable workflows, like a weekly report, into a skill instead of a chat thread.
3. Uninstall plugins you tried once and forgot.
4. Move finished tasks and old project notes out of CLAUDE.md and memory into separate files Claude reads only when asked.

Check your effort level too. Max effort on a job that does not need it burns reasoning you did not need. Changing effort mid-job also discards the cache, the same way a model switch does.

What happens when I walk away mid-task?

You go to lunch, return, and type "continue." If more than an hour passed, that message re-reads the entire chat at full price instead of a tenth. One Reddit user worked through this and found about five times the token usage for that single restart.

Before leaving, finish the step, or write the handoff and close the chat.

Also check what keeps running while you are away. /loop, scheduled tasks, /goal, and messages from other sessions each start a new turn, and each turn sends the whole chat again.

How do I find out what is actually using my limit?

Run /usage. On Pro or Max it shows which skills, sub-agents, plugins and MCP servers are consuming your limit. Press W for the full week. It also lists specific recommendations for anything above 10% of usage, such as trimming a CLAUDE.md that costs 49,000 tokens per request. Press F and Claude can apply the changes.

It also has a prompt cache line showing how many times a chat missed the cache, often with a likely cause such as changed tool definitions. A running loop gets its own row with tokens used per firing.

This is how you tell "Anthropic cut my limits" apart from "my setup is expensive."

Do sub-agents save tokens or cost more?

Sub-agents exist to protect your main context, but they draw from the same limit. Extra ones can raise total spend.

• Drop custom role agents unless they are critical. Let Claude decide when to split work.
• For small jobs, a sub-agent is just overhead.
• Ask for one when a job produces huge output, and say exactly what it should return.

Anthropic's own example: use a sub-agent to run the test suite and report only the failing tests with their error messages. The noisy output stays in the sub-agent, and your main chat stays small.

Sub-agents keep their cache for only 5 minutes. If yours run long jobs with pauses, set the sub-agent prompt cache TTL environment variable to one hour so they stop repeatedly uncaching and recaching. I could not confirm the exact variable name from the source, so check Anthropic's current documentation for it.

Is this enough to avoid Max?

For many users, probably. The source creator admitted to upgrading to Max when optimizing would have worked. If /usage still shows heavy, legitimate work after these fixes, a bigger plan is a fair choice. Check the diagnostics first.