Claude Code on a Pro or Max plan does not have its own allowance. It draws from the same usage limit as claude.ai and Claude Desktop, and that limit resets every five hours. This page covers how that limit works, what to do when you hit it, and the 10 habits that decide how fast you get there.
How Claude Code usage limits work
Everything in this section comes from Anthropic’s help articles, read on 09/28/2026.
- One shared pool. Anthropic’s usage-limits article states that usage of claude.ai, Claude Code and Claude Desktop “counts towards the same usage limit.” A morning of Claude Code leaves less for chat in the afternoon.
- A five-hour session limit. The session limit resets every five hours. Max plans also carry a weekly limit across all models, which resets at a fixed weekly time assigned to each account.
- No published token count. Anthropic states plan usage as multiples: Pro is at least 5x Free per session, and Max is 5x or 20x Pro. It never states a number of tokens or turns.
- What uses it up. Conversation length and complexity, the features used, the model, and the effort level.
- Claude Code is on Pro and Max, not Free. The full plan and price table is in Claude pricing.
To see where you stand, run /status in Claude Code. The general version of this topic, for every Claude app, is in Claude usage limits, explained.
What to do when Claude Code hits the limit
Anthropic’s Claude Code article (updated 08/19/2026) lists four options:
- Wait for the reset. The session limit refills five hours after the window started.
- Upgrade. Pro to Max 5x is five times the allowance. Claude Pro vs Max covers when that is worth $80 a month more.
- Turn on usage credits. Keep working and pay for the extra usage.
- Switch to API credits. Claude Code can bill the Claude Console at standard API rates instead, and does so only with your explicit consent. At API prices a heavy agent day adds up fast: one day of 2,979 turns I measured costs $220 at Opus 5.5 list prices. The Claude token counter prices your own prompts before you switch.
The better fix is to hit the limit less often. That is what the rest of this page is about.
Why I run 8-hour sessions at 32% of the plan
In May 2026 I traced why my 8-hour Claude Code sessions use 32% of the plan. The plan tier is not the reason. Ten habits explain it, and each one is something you can check against /status.
I treat Claude Code as a steering wheel. The conversation steers, and subagents, hooks, scripts and scheduled tasks do the work, reading files on disk instead of carrying them in the prompt. In my sessions, that one difference is worth roughly 5-15x in plan usage.
Each pattern below names a habit that burns the limit, what I run instead, and a rough multiplier. The multipliers are my estimates from my own sessions, not figures Anthropic publishes.
TL;DR
Under subscription pricing, the usage limit is the binding constraint, not API tokens. Most builders are still tuning as if dollars per call mattered, when the real cost is how much of the five-hour window each turn uses. The 10 patterns below are where the gap lives. Stack five of them and you get the 5-10x compound effect behind my 32% burn at 8 hours.
The 10 patterns
1. Loading the repo into context versus querying files on disk
The habit. Open Claude Code, read every file in a 200-file repo to give it context, then start asking questions. Every turn re-passes 150-300K tokens. Even with prompt caching, the first turn alone is huge, and the cache invalidates the moment one file changes.
What I run instead. About 30-50K tokens load by default, and I query the codex on demand. The codex is a hand-authored knowledge graph stored on disk at ~/.claude/codex/, with an INDEX.json that maps terms and aliases to node files. When I need context on plan quota, I grep the index, load 3-5 relevant nodes, and proceed. The files on disk hold the working set, and the prompt only steers.
Savings. Roughly 5-10x per turn.
2. Opus-everywhere versus a routed model mix
The habit. Use Opus for all coding because it is the smartest model, including file lookups, status checks and questions about what a function does.
What I run instead. 50% Haiku 4.5 / 30% Sonnet 4.6 / 20% Opus 4.7 per the routing rule in my operations playbook (model versions current as of 2026-05; for the updated tier matrix and effort-inversion findings, see Fable 5 vs Opus 4.8). Haiku finds (exploration, triage, status, browser automation, simple refactor). Sonnet builds (multi-file implementation, async work, security-adjacent). Opus decides (architecture, money-moving, final review, deep debug). Opus reserves itself for judgment work where being wrong costs more than an hour of rework.
Savings. Anthropic names the model as one of the factors in how fast a plan’s limit runs down, but does not publish the ratio. On the API side, Opus 5.5 lists at 4x the per-token price of Haiku 4.5 ($4 against $1 per million input tokens). My estimate is that running the largest model for everything costs several times a routed mix, and most of those turns are routine work that does not need its judgment.
3. Conversational chat versus done-when delegation
The habit. Steer Claude one step at a time: X, then Y, then Z, then debug when it breaks. Each step is a full turn with full context, steered by hand across 50 turns.
What I run instead. Single-shot delegated workflows through a goal-driven session mode I call /done-when. You specify the success condition + a max-turn budget + an evaluator model (Haiku, usually). The main agent works toward the goal; the Haiku evaluator scores each loop iteration against the success condition; the loop exits when the condition is satisfied or the turn budget runs out. The main agent does not manually steer 50 turns; it runs to the goal.
Savings. 10-50x per task. Steering a multi-step task by hand, turn by turn, is one of the biggest wastes I measured.
4. Heavy work in main session versus subagent delegation
The habit. The main session does the broad codebase exploration, the document analysis and the multi-file grep itself. All of it burns the main session context.
What I run instead. I spawn an Explore or general-purpose agent (or a domain specialist like a brand-voice document-analyzer) for anything reading more than ~20 files. The subagent has its own context window. The main session receives a summary, not the raw output. Spawning a subagent costs roughly one turn of orchestration overhead; the subagent then burns its own window separately and returns a 200-word summary.
Savings. The subagent reads into its own window, and the main session pays for the summary only. On a typical >20-file read, I estimate a 30-50x reduction in what the main session carries forward.
5. Always-on extended thinking versus decision-only thinking
The habit. Keep thinking at the highest level for everything, on the theory that it gives better answers. Anthropic lists the effort level as one of the factors in how fast you use the limit, because higher effort spends more thinking tokens per answer.
What I run instead. Thinking only on actual decisions. My decision-mode skill (a knowledge-graph-walk skill I call /librarian) triggers thinking when the readback has multiple plausible paths and a principle has to pick between them. My adversarial-critique skill (which I call /red-team) triggers thinking when a decision is irreversible. Routine work skips thinking entirely.
Savings. My estimate is 5-20x per thinking turn, depending on depth. Decisions get the thinking budget; status checks and file lookups do not.
6. Cache-invalidating mid-session versus cache discipline
The habit. Edit CLAUDE.md mid-session to add a rule, edit a config, push a small change. Each one invalidates the prompt cache, and the next turn pays full freight.
What I run instead. An explicit rule (sitting at ~/.claude/rules/session-management.md under a section called “Cache discipline”) that batches all edits to those files to session end. My cache stays warm across the five-minute cache lifetime, dropping repeated-prefix input cost to 10 percent of full (5 percent on Opus 5.5). The per-model math is in Claude prompt caching cost. Mid-session edits go into a scratch file and apply at session close.
Savings. A cache hit drops input cost 10x or more compared to a cold prefix. Across an 8-hour session, that is the difference between hitting the wall mid-day and finishing the work.
7. Retry-without-diagnose versus preflight + red-team
The habit. Code fails, so try again. It fails, so think harder. It fails, so switch to Opus. Each retry is a full Opus turn.
What I run instead. Hard rules in my operating playbook (“do not retry the same approach without diagnosis”), a /preflight skill that runs config-reconciliation and break-even checks before risky actions, a /red-team skill that attacks proposed picks adversarially before they ship, and circuit breakers that stop after the same error appears 3 consecutive times. The principle is “diagnose root cause first, then retry intelligently.”
Savings. 3-5x fewer turns per bug. Most retry storms come from re-trying the same approach with different model temperature instead of changing the approach itself.
8. Re-deriving context every conversation versus codex plus decisions-ledger
The habit. Open a new session and spend 1,000 tokens re-explaining the project, the goal and what you already tried before the actual question.
What I run instead. A codex (the same knowledge graph from pattern 1) plus an append-only decisions ledger at ~/.claude/decisions.jsonl that records every architectural pick I make with the AI, including the red-team attack on each pick and the operator ratification. The agent already knows the project. The session starts with the same stable files loaded (CLAUDE.md + the rules files in ~/.claude/rules/, about 30K tokens total), then queries the codex for the specific question and pulls in 3-5 relevant nodes. No re-explaining.
Savings. 5-10K tokens per session of unnecessary context never get sent. Across 5 sessions per week, that compounds.
9. AI doing what hooks should do versus deterministic pre-commit hooks
The habit. Ask Claude to check each commit for leaked secrets. Opus reads 30 files and reports, on every commit.
What I run instead. A pre-commit hook I installed on 05/15/2026 that runs as a Python script. It blocks the commit before it even hits Claude. Same shape for the role-classifier (a hook that reads my prompt before each turn and classifies whether the work is ARCHITECT or TACTICAL, locking the appropriate discipline), the em-dash check, the output validator. These cost nothing in plan usage, because they never go through Claude.
Savings. The whole task. A shell script never touches Claude, so it uses zero plan quota, and the same check inside Claude costs a full turn.
10. Sequential tool calls versus batched parallel
The habit. Check git status in one tool call, then git diff in a second, then git log in a third. Three full agent turns.
What I run instead. Batched parallel tool calls in a single message, per the routing rule that says “make all independent calls in parallel.” Three tool calls in one message equals one turn. The agent emits all three tool_use blocks at once; the runtime executes them in parallel; the agent receives all three results in the same response.
Savings. 3x fewer turns per multi-step check.
The compound math
Stack 5x context savings + 3x model-mix savings + 5x cache hit + 3x batched workflows + 2x parallel calls. Multiplied together, that is 450x on paper. In practice I see more like 10-30x, because the multipliers do not compound cleanly on every turn. A 5x effective multiplier is enough to explain an 8-hour session at 32 percent of the plan.
What this means for you
If you are running Claude Code as a chat app and hitting the 5-hour wall on substantive work, the issue is almost never plan-tier. It is that the work happening inside the LLM contains a large fraction of work that does not belong there. I follow three rules.
One: do not put in your prompt what you can put on disk and query. Patterns 1 and 8 together are the biggest multiplier I measured.
Two: do not ask the LLM to do what a 5-line shell script can do deterministically. Pattern 9 is the highest-impact one-time fix; pre-commit hooks pay for themselves the first day.
Three: tune for plan usage per useful decision, not API tokens per call. This inverts Patterns 2, 5, and 7. Use Opus on judgment calls. Use Haiku on triage. Skip thinking unless the decision deserves it.
FAQ
Five questions I keep getting.
Do these patterns require a custom harness, or can I run them on stock Claude Code?
Most are stock features. Subagents (pattern 4) ship with Claude Code. Batched parallel tool calls (pattern 10) are documented in the prompting guide. Hooks (pattern 9) are configurable through ~/.claude/settings.json. The codex (patterns 1 and 8) is operator-built but the shape ports easily: an INDEX.json plus a folder of markdown files. The done-when delegation skill (pattern 3) and the librarian and red-team skills (pattern 7) are operator-authored skills; the patterns work without them but the discipline is harder to maintain.
What is the highest-impact pattern to start with?
Pattern 9 (deterministic hooks). The setup cost is one afternoon. The plan-quota savings compound on every future session. Pattern 1 (codex as query surface) is the second-highest-impact but requires building the files on disk, which takes weeks. Hooks pay back in days.
Why does the routed model mix (pattern 2) not produce more savings?
Because the savings from model-routing alone are modest under subscription pricing (roughly 3x). Moving the work out of the conversation is where the big multipliers live. Routing matters but it is not the main lever; pattern 1, 3, 4, 8, and 9 are.
Is the 32% burn number reproducible?
Yes, on the same workload mix. The variability is in workload. A session that is 80 percent codex maintenance and 20 percent shipping content burns differently than a session that is 80 percent debugging a single hard bug. The 32% number references a specific 8-hour session on 05/15/2026 that shipped 4 codex-driven blog posts, 1 skill upgrade, 1 schema fix on chudi.dev, and 1 deploy methodology fix.
How fast does the architectural shift pay off?
Pattern 9 (hooks) pays off in days. Pattern 1 (codex) pays off in weeks. Pattern 3 (done-when delegation) pays off in months as you build up the skill library. The full 5-10x compound usually surfaces around the 3-month mark; before that you are still trading off setup cost against savings.
What to do next
- Implement one deterministic pre-commit hook today. Pick the smallest validation you currently do through Claude (secret-scanning, em-dash check, type-check). Make it a shell script that runs on
git commit. Measure: how often the LLM asked about this check before vs after. The difference is pure plan-quota savings. - Audit your next session for whole-repo context loading. Note every time you Read a file just to “give Claude context” instead of querying for a specific answer. Replace those reads with grep + targeted load. Measure plan-quota burn before and after on a comparable workload.
- List your 10 most common workflows and tag each: belongs in the LLM, belongs in a subagent, belongs in a shell script, belongs in a hook. The tag tells you where the work should live. The last two categories are usually bigger than they look.
The harder version of this work is rebuilding your workflow so the conversation steers and 95 percent of the work happens elsewhere. I think most production teams get there by the end of 2026.
Most of your work does not belong inside the model. The person who knows which part does is way ahead of the one who pays for all of it.
Drafted from the May 2026 plan-quota session-burn data + the 10-pattern enumeration that surfaced during a discussion of Claude Code tuning across operator stacks. The 32% number is verified from session logs on 05/15/2026 and was later measured against a real 2-day production sprint, where the same setup came out at 2% per session. The pre-commit-hook reference (pattern 9) was implemented the same morning. If you want the AI-visibility framework I built alongside this discipline, see chudi.dev/framework.