Why did my Claude Code limit run out so fast?

1. Run /usage and read the breakdown below the bars. Press d or w for the last day or the last week. If one subagent, plugin or MCP server is behind a large share, that is your answer, and the suggestion beside it says what to change.
2. Do not resume a long, old session when the window resets. Ask Claude to write a short handoff note of where things stand before you stop, then start a fresh session with /clear and point it at the note. /clear costs nothing.
3. Do not compact just before you stop for the day. Compacting reads the whole conversation, so it spends a share of the window to save context you are about to abandon anyway.
4. If you were running subagents or an agent team, cap them or give them a smaller model before you start again.

Anthropic does not publish what a message costs in per cent, so this table ranks causes rather than giving figures. The explanations are from Anthropic's usage-limits article, its best-practices page and the Claude Code costs docs.

This is the cause people describe most often, and the one that surprises them most. Claude Code caches the conversation so that each new request can read the earlier part cheaply. On a Claude subscription the main conversation's cache lasts one hour, according to Anthropic's prompt-caching docs. After a longer break, the costs docs say your first message reprocesses your full context at the full rate. So the first "carry on" after lunch can cost more than the whole morning's last hour.

A Pro user in a thread of 96 replies put it this way: "after the reset, simply telling Claude to continue what it was doing sent my usage from 0% to around 40% almost immediately". The most upvoted practical reply in the same discussion on r/ClaudeCode: "Don't compact, ever. Just start a new chat if you are over 400k context for example."

Once you are past your plan and on usage credits, the cache for the main conversation drops to five minutes, so even short pauses cost more.

The costs docs say /compact reads the conversation it summarises, so compacting a large context is itself a large request. Claude Code sometimes suggests it, which is why it catches people out. Reports in their own words:

• A Pro user, right after a reset: "Claude suggested using `/compact` to save context, smart suggestion, so I did. Within seconds, my usage jumped to 11%, without actually getting any work done."
• Another, in a post titled "Claude just compacted my session and took me from 15% usage to 90%": "Almost 80% of my 5-hour limit gone just from compacting context."

Compaction is worth it when you will keep working in the same session and the history matters. When you are about to stop, a handoff note and a fresh session cost far less.

Every subagent sends its own requests on top of the main conversation's, and the costs docs say "the subagent's own requests still draw on your usage". Agent teams use roughly seven times the tokens of a normal session when teammates run in plan mode. Many agents at once can empty a window in minutes:

• On the $100 plan: "had about 50% left on my 5 hour block. I asked Fable to review a couple recent feature additions. It spun up 18 fable sub agents." The same person hit 101 per cent of the window in about two minutes.
• Also on the $100 plan, with a feature that runs many agents: it "blew through my 5-hour context window on my pro x5 plan in 10min trying to utilize over 200 agents!"

Claude Code's error reference says the same about the weekly limit: "A single burst of heavy activity, such as a large workflow fanout, can exhaust the weekly allowance before the session window resets." Giving subagents a smaller model, or capping how many run at once, is the change people report helps most.

Anthropic lists the model and the effort level among the things that decide how much a message costs against your limit. People who make the window last describe the same habit: the largest model for planning and hard problems, a smaller one for routine steps. One $100 plan user: "Mostly using Opus 5.5 medium on the $100 plan and delegating as much as I can to subagents using Haiku or Sonnet for tasks that don’t need Opus computing."

Some things load with every request whether you use them or not. One developer found they "had like 5 or 6 MCP servers configured and did not realize all of them were loading every single time i sent a prompt." The /usage breakdown shows each MCP server's share, and suggests trimming a large CLAUDE.md when it is behind a big share.

The reports that get the most attention are tiny tasks that took a large bite. When people dig in, the cause is almost always what was loaded before the task started. In their own words:

• A one-line bug fix on the $200 plan: "a hundred thousand tokens. 10 lines added 1 deleted. 5% usage for just this single prompt."
• Three short questions on Opus at medium effort: "Those three questions have used 42% of my session allowance?"
• A whitespace change: "My Claude code used up 40% of the session limit just to reduce a couple of empty spaces on the website", in a session whose context was nearly 400,000 tokens.
• On Codex rather than Claude Code, the same mechanism: a scheduled "good morning" task on ChatGPT Plus "ate 8 % of my 5‑hour Plus quota and 119 k tokens". The most upvoted reply explained it: "looks like it's reading your agents, memory, etc".

• They start fresh rather than resume. A short handoff note and a new session cost less than carrying a day of context into the next window.
• They watch the window in the status line and stop before it runs out: "When you get close to 85% it is time to tell Claude to "wrap-up" and update anything it learned/needs for the future into CLAUDE.md." The guide on checking your Claude Code usage shows how to set that up.
• They give routine steps to a smaller model, and keep the largest one for planning and hard problems.
• They trim what loads with every request: MCP servers they do not use, and a CLAUDE.md that has grown long.
• Some start the window early on purpose. Because "The period starts when you send your first message", they send a tiny message a few hours before work, by hand or on a timer, so a reset lands in the middle of the day. It is not free: one person found a simple "hello world" took 4 to 5 per cent of their limit.

Since Anthropic removed the 5-hour limit for verified Ultra accounts on 30 October 2026, some people on Ultra and on the $100 plan report their weekly allowance going faster. Anthropic's announcement said "Weekly limits remain unchanged." What users report is mixed:

• An Ultra user: "Last week I can consume 50% in 2 days, now it's just 10 hours."
• A $100 plan user who measured it: "100% of 5-hour session used to be 10-11% of weekly, but since the last 2 weeks it’s 15-16% of weekly."
• Others in the same threads say they see no change, and that without a 5-hour stop it is simply easier to use more in a day.

Nobody outside Anthropic can settle this from one person's screen, because the limits are described only as multiples of Pro. What you can settle is your own pattern: how much of the week one full 5-hour window takes, and whether that has changed. That needs a record kept over time, which the last section is about.

Codex works the same way in one respect: what loads before your task counts, as the "good morning" report above shows. Three things are its own, all on OpenAI's Codex pricing page:

• The model matters most. OpenAI's estimates for a Plus plan run from 5 to 45 local messages per five hours on GPT-6 Astra, and from 350 to 3,000 on GPT-6 Luna. A routine step on the largest model costs many times what it would on the smallest.
• Speed costs extra. On the models that offer them, Fast mode uses your included usage 2.5 times as fast as Standard, and Ultrafast 8 times.
• Cloud tasks count too. OpenAI says local messages and cloud chats share your plan's allowance, and that cloud tasks may use more of it than local messages.

The allowance is also shared beyond Codex. OpenAI's article on using Codex with your ChatGPT plan says Codex, ChatGPT Work, ChatGPT for Excel and Workspace Agents use one allowance on plans that share it, and from December, Plus, Pro and Business plans will share one allowance across ChatGPT and Codex, measured in tokens. Type /status in the Codex CLI to see which window ran out; how Codex's limits work has the rest.

Team and Enterprise seats have the same 5-hour and weekly windows, sized by seat type, and everything above applies. If you run out often, the guide on how to ask your company for more Claude Code budget covers what to ask for and what to bring.

/usage shows the last 24 hours or 7 days, on the machine you run it on. To see which turns used up a window, open Session Forensics, a free page that reads your Claude Code and Codex session files in your browser, with no sign-up and nothing uploaded. It lists the limits you hit in the last seven days and, for each one, the turns that took the most, with their estimated share of the window and a plain reason, such as a long chat re-read at every step. For Claude Code its 5-hour figure is an estimate, because Claude Code's files do not record the meter.

OpenReason Intel, a dashboard for Claude Code and Codex usage, keeps the longer record: your 5-hour and weekly windows over time from every machine you use, each time a window filled, and the sessions and turns that were running, each with its estimated share of the window. So the question "what used it up?" has an answer for last Tuesday as well as for today, and "is my week draining faster?" can be checked against your own weeks.

It does not tell you anything as you work, and it does not stop a session; it is a record you look at afterwards. What you can do as you work is keep your 5-hour and weekly percentages in the Claude Code status line, which or-otel leaves running, and stop or start fresh when they get high.