
Claude Code on a Pro, Max or Ultra plan has two usage limits: a weekly limit that every plan has, and a five-hour session limit that Pro and Max have and verified Ultra accounts do not. Both are shared with chat on claude.ai, and all your Claude Code sessions draw from the same pool. Type /usage to see what is left. This guide covers how the limits behave, how to read them, and how to make them last when several sessions run at once.
This is as of November 2026. The limits have changed several times this year, so check the linked docs.
How the limits work
The plan article from Anthropic says Pro and Max have a five-hour session limit and a weekly limit. Ultra has a weekly limit and, for verified accounts, no five-hour limit. Max and Ultra also have a separate weekly limit for Fable models. Claude chat and Claude Code share all of these.
The Ultra change came on October 30, when Anthropic renamed Max 20x to Ultra. Mixed News reports that verification is automatic, that the weekly cap stays at ten times Pro's, and that on a verified account Settings, then Usage, shows no "Current session" bar.
When you run out, Claude Code prints one of these, from the error reference:
You've hit your session limit · resets 3:45pm You've hit your weekly limit · resets Mon 12:00am You've hit your Opus limit · resets 3:45pm
Session and weekly limits cover all models, so /model does not help. The Opus and Sonnet limits cover one model family, so switching to another family does keep you working, at the price of a cold cache. Usage counts against both allowances at once, so one big burst can empty the week before the session window resets.
Check what you have left
/usage is the answer. On a plan it shows the limit bars, the reset time and a breakdown of what used your allowance, with recommendations. Press d or w to switch between 24 hours and 7 days. The costs page notes that the breakdown is approximate and covers only this machine, so other devices and claude.ai are not in it.
The status line can show it all the time. Claude Code passes rate_limits.five_hour and rate_limits.seven_day to your script, each with used_percentage and resets_at, as the status line docs describe. They appear only on a claude.ai plan and only after the first response. Our status line guide covers the setup.
/rate-limit-options and the wait: when a limit stops a task, an interactive session can wait and carry on after the reset. The interactive mode docs say it is on by default, shows Continuing automatically at 3:45pm · Esc to cancel, and gives up after three automatic continuations.
/usage-credits buys more when you would rather pay than wait.
ccusage is a different tool for a different question. ccusage reads the session logs on your computer and prints tokens and an API-price cost by day, week, month, session or five-hour block. It needs no install:
npx ccusage@latest claude weekly --offline npx ccusage@latest claude session --offline --since 20261025
It does not know your allowance, and its dollar figure is what those tokens would cost at API prices, not your bill. The blocks guide explains the five-hour blocks it draws.
What we saw when we tried it
We ran both on a Mac that runs Claude Code all day. npx ccusage@latest took about 7 seconds to start the first time. The plain weekly command now mixes in Codex and OpenCode, so we used ccusage claude weekly, which is Claude Code only. Here are the weeks, rounded from the real table (the last row is a partial week):
Week Output Cache read Total tokens API-price cost 2026-10-04 3.9M 1,226M 1,256M $640 2026-10-11 3.5M 1,772M 1,808M $656 2026-10-18 2.1M 795M 812M $333 2026-10-25 4.9M 1,084M 1,116M $617 2026-11-01 4.4M 838M 873M $671
About 97% of a week's tokens are cache reads, and output is under half a percent. That fits the docs: every request re-sends the conversation, so a long context is read again on each turn. Output is what you see; cache reads are most of what you spend.
The session report showed where it went. Since October 25 we had 148 sessions and about 2.0 billion tokens. The median session used about 3 million. The five biggest used about half of everything, and the largest, one session that stayed open from October 31 to November 4, used about 230 million.
Then /usage. It works non-interactively too, so claude -p "/usage" printed this (trimmed and rounded):
Current week (all models): 71% used · resets Nov 7 at 9am Current week (Fable): 91% used · resets Nov 7 at 8:59am Last 24h · 1154 requests · 32 sessions 82% Start fresh when you switch tasks · run /clear 35% Run fewer sessions at once · up to 7 at once 27% See what fills your context · run /context 23% Give simple subagents a cheaper model Last 7d · 5279 requests · 88 sessions 58% Stop sessions you no longer need · some ran 8 hours or more
There is no "Current session" line. That matches an account without a five-hour limit. The Fable weekly bar was the one near the wall, not the all-models bar, which is easy to miss if you only watch the general number. The shares do not add to 100% because one request can count toward several rows.
One thing the docs left out: ccusage's weeks start on a Sunday, while the plan's week resets at a time of its own, so the two will not line up.
This run was itself a routine. We run Briefkin routines through claude -p and record the tokens and cost each run reports, so we can see which routine eats the week. Long documentation pages fetched for this guide are exactly the context every later request re-reads.
Make it last across several sessions
These changes come from the docs and the numbers above:
- Close sessions you are done with, and
/clearbetween tasks./usageshowed "start fresh when you switch tasks" applying to 82% of our last day's usage. The costs page says the same: stale context is re-sent with every message. Use/renamefirst,/resumelater. - Do not leave sessions running work you forgot. The docs list scheduled tasks, messages from other sessions and goal check-ins as things that fire in an idle session and send its full context each time.
- Keep parallel sessions in the same folder when they work on the same code. The prompt caching docs say sessions in the same directory can read each other's cache, and sessions in different directories cannot. Worktrees are worth it for isolation, but they cost a cold cache each. See the worktrees guide.
- Use a smaller model for subagents. Subagents have their own context and their own requests. Choose a cheaper model for them, as
/usagesuggested to us at 23%. - Avoid model and tool changes mid-task. Each model has its own cache, so
/modelmakes the next request read everything uncached. - Be careful with agent teams. The docs say they use about 7 times more tokens than a standard session when teammates run in plan mode. See our agent teams guide.
A status line that shows pace helps more than a bar. This one prints weekly usage next to where an even pace would be. We checked it against sample input; the field names come from the docs:
#!/bin/bash input=$(cat) used=$(jq -r '.rate_limits.seven_day.used_percentage // empty' <<<"$input") reset=$(jq -r '.rate_limits.seven_day.resets_at // empty' <<<"$input") [ -z "$used" ] || [ -z "$reset" ] && exit 0 pace=$(( 100 - (reset - $(date +%s)) * 100 / 604800 )) printf 'week %.0f%% used, even pace %d%%\n' "$used" "$pace"
Save it as ~/.claude/statusline.sh, run chmod +x on it, and set "statusLine": {"type": "command", "command": "~/.claude/statusline.sh"} in ~/.claude/settings.json.
Problems people hit
The weekly limit drains faster than the work seems to justify. This is the most common complaint right now. Issue 102667 says the weekly quota went down about 50% faster with no change in work, and commenters compared local transcripts to the usage meter. Issue 106274 reports the same on Ultra after the rename. Neither thread has a maintainer answer, so the cause is unconfirmed. What helps: compare /usage with ccusage for the same days, so you have your own numbers.
Many open sessions keep adding up. In issue 105122 someone with 15 or more sessions open saw the weekly figure rise while sessions sat idle. Fixes people reported: fewer active sessions, regular compaction, and a handoff note in a file, then /clear, then a fresh session that reads the note.
You cannot see the meter, so you ration blindly. This was the top complaint in the Hacker News thread on weekly limits when they began, with commenters asking for a bar showing what is left. It exists now as /usage, but it is easy to forget. Put it in the status line.
Our take
I swing between two modes. Sometimes I burn through the limits fast, get annoyed and drift to other engines. Other times I try to space it out, and on the last day I have usage to spare and no idea what to build with it, which brings the pressure back. I have not found a clean way to optimise this.
The removal of the five-hour limit is the first change that made it feel better. I can spread work over the week as I like instead of racing a window, and that is the part of Anthropic's change that matters to me.
What I would pick: watch the weekly number, not the session number, and look at it on day three, not day seven. Use /usage for what is left and ccusage to find the sessions that cost the most. In our data five sessions made up half the tokens, so closing the long-lived ones beats any prompt trick. And I would not trust an even-pace rule too hard: some days there is a lot to do.
We would not use ccusage to predict when the limit ends. It has no idea what the allowance is, and the issue threads show the allowance and the meter can both move.
Sources
- Use Claude Code with your Pro, Max, or Ultra plan (Anthropic support)
- Claude Ultra: no five-hour limit for verified accounts (Mixed News)
- Error reference: You've hit your session limit (Anthropic docs)
- Manage costs effectively (Anthropic docs)
- Interactive mode: wait for a usage limit to reset (Anthropic docs)
- Status line: rate limit usage (Anthropic docs)
- How Claude Code uses prompt caching (Anthropic docs)
- ccusage (GitHub)
- ccusage blocks reports (ccusage docs)
- Weekly limit depletes much faster than before, issue 102667 (GitHub issue)
- Ultra plan: one 5-hour session consumes about 50% of the weekly limit, issue 106274 (GitHub issue)
- Max plan weekly usage draining while sessions are idle, issue 105122 (GitHub issue)
- Claude Code weekly rate limits (Hacker News)
Questions
How do I check my Claude Code usage limits?
Type /usage in Claude Code. On Pro, Max and Ultra plans it shows bars for your weekly limit (and the session limit if your plan has one) with the reset time, plus what used the most. You can also run claude -p "/usage" from a shell, or read rate_limits in a custom status line. ccusage shows tokens you used, not how much of your limit is left.
Does Claude Code still have a five-hour limit?
Pro and Max still have a five-hour session limit plus a weekly limit. Anthropic's support article says verified Ultra accounts have no five-hour limit, only the weekly one. If your /usage shows no session bar, that is your case.
When does the Claude weekly limit reset?
At a fixed time for your account, shown in /usage and in the error as, for example, You've hit your weekly limit · resets Mon 12:00am. It is not seven days from your first message, so read the time off /usage instead of guessing.
Does ccusage show how much of my limit I have left?
No. ccusage reads the logs on your computer and adds up tokens and an API-price cost. It does not know your plan's allowance. Use /usage for what is left and ccusage for where it went.
Why do several Claude Code sessions drain the limit faster?
Every request re-sends the whole conversation, and all your sessions draw on the same allowance. Long sessions, idle sessions with scheduled tasks and subagents all add up. A few long-lived sessions usually account for most of it.
What happens when I hit the limit in the middle of a task?
In an interactive session signed in with a claude.ai plan, Claude Code can wait and continue the task by itself after the reset (v2.1.234 or later). Press Esc to cancel, or run /usage-credits to pay for more now.