{
"$type": "site.standard.document",
"bskyPostRef": {
"cid": "bafyreiezwhtyomcmxwbbt56oo4hw5xdx6qlp2gdo6d57nj4cjzcbskouf4",
"uri": "at://did:plc:ws6dhxzqnqxu5aqxt4kd27oc/app.bsky.feed.post/3mk5qdfz25ea2"
},
"coverImage": {
"$type": "blob",
"ref": {
"$link": "bafkreigmomf5k2j6vnyd64ltayjxzg67m2elomwuzapwpngncbosz6spp4"
},
"mimeType": "image/png",
"size": 1379166
},
"description": "How the session and weekly caps work, what drains them fastest, and how to stretch your quota.",
"path": "/claude-code-usage-limits-explained-pro-max-and-weekly-caps/",
"publishedAt": "2026-04-23T09:50:02.000Z",
"site": "https://allthings.how",
"tags": [
"claude.ai"
],
"textContent": "Claude Code runs on the same usage budget as the rest of Anthropic's Claude products, and hitting a limit mid-task is one of the fastest ways to derail a coding session. The caps are measured in rolling time windows rather than a visible token counter, which is why burn rates can feel unpredictable depending on the model, context size, and time of day.\n\nā”\n\nQuick answer: Claude Code shares one usage budget across claude.ai, Claude Desktop, and the CLI. You get a rolling 5-hour session limit plus a weekly cap, with higher allowances on Pro, Max 5x, and Max 20x. Peak-hour throttling (weekdays 5ā11 a.m. PT / 1ā7 p.m. GMT) makes the 5-hour window drain faster.\n\n* * *\n\n### How the two limits actually work\n\nThere are two separate caps running at the same time, and both can stop a session cold. The 5-hour session limit is a rolling window that starts with your first message and resets five hours later. The weekly limit is a longer cap that covers all models across a seven-day window.\n\nUsage is not measured in raw messages. It's weighted by conversation length, model choice, features in use, and tool calls. A short prompt with heavy file reads, extended thinking, or multiple MCP connectors can burn far more than a longer prompt with none of that overhead. Everything you do across claude.ai, Claude Desktop, and the Claude Code CLI counts against the same pool.\n\n* * *\n\n### Plans and where Claude Code fits\n\nAll paid tiers include Claude Code access, but the headroom differs sharply. Pro is the entry point and is the one most users report as tight for any sustained agentic coding. Max 5x and Max 20x are aimed at developers running Claude Code for hours per day, and Enterprise uses a different consumption-based model.\n\nPlan| Price| Relative session allowance| Typical fit\n---|---|---|---\nFree| $0| Baseline| Light chat, testing\nPro| $20/mo| ~5x Free| Casual Claude Code use, short tasks\nMax 5x| $100/mo| ~5x Pro| Daily Claude Code work, single project\nMax 20x| $200/mo| ~20x Pro| Heavy agentic workflows, parallel sessions\nTeam / Enterprise| Varies| Per-seat or usage-based| Orgs, custom billing\n\nAnthropic doesn't publish exact token numbers for session or weekly caps. The allowances shift with load, and the company has adjusted them more than once as demand grew.\n\n* * *\n\n### Peak-hour throttling\n\nFree, Pro, and Max subscribers move through the 5-hour session limit faster on weekdays between 5 a.m. and 11 a.m. Pacific Time (1 p.m. to 7 p.m. GMT). The weekly cap is unaffected by this change.\n\nIn practice, a task that consumed 20% of a session window off-peak can eat 40% or more during those hours. If you have flexibility, shifting heavy Claude Code runs outside that band is the single biggest lever for Pro and Max 5x users.\n\n* * *\n\n### What burns the session limit fastest\n\nClaude Code is agentic, so each turn can trigger many tool calls, file reads, and subagent invocations. A few patterns drain the session meter disproportionately:\n\n * **Opus versus Sonnet.** Opus consumes roughly 5x more per equivalent task. Sonnet handles most implementation work.\n * **Extended thinking.** High reasoning budgets compound across every tool call in a loop.\n * The 1M-token context variant of Opus. Larger payloads per request mean more tokens in flight even when the actual task is small.\n * Repeated file reads. Claude Code often re-reads files already in context.\n * Heavy `CLAUDE.md` files and always-on MCP connectors. Both load into every message.\n\n\n\n* * *\n\n### Length limits are separate\n\nThe usage cap controls how much you can do over time. The context window controls how much Claude can hold in a single conversation. All paid plans get a 200K-token context window, with 500K available on some Enterprise models.\n\nWhen code execution is enabled, Claude automatically summarizes older turns as a chat approaches the context window, so long sessions continue rather than hitting a hard wall. The full chat history stays accessible even after summarization. The message \"organizing its thoughts\" is the visible signal that automatic context management is running.\n\n* * *\n\n### Stretching the session budget in Claude Code\n\nA handful of configuration changes have an outsized effect on burn rate inside the CLI.\n\n**Step 1:** Open `~/.claude/settings.json` and set Sonnet as the default model, cap thinking tokens, lower the autocompact threshold, and route subagents to Haiku. This single block cuts consumption meaningfully for most workflows.\n\n\n {\n \"model\": \"sonnet\",\n \"env\": {\n \"MAX_THINKING_TOKENS\": \"10000\",\n \"CLAUDE_AUTOCOMPACT_PCT_OVERRIDE\": \"50\",\n \"CLAUDE_CODE_SUBAGENT_MODEL\": \"haiku\"\n }\n }\n\n\n~/.claude/settings.json\n\n**Step 2:** Add a `.claudeignore` file at the project root to block directories like `node_modules/`, `dist/`, and lockfiles. It works like `.gitignore` and saves tokens on every prompt that would otherwise pull those files into context.\n\n**Step 3:** Keep `CLAUDE.md` lean. A 60-line file is typically enough. Move everything else into `docs/` and let Claude pull it on demand rather than loading it into every message.\n\n**Step 4:** Use `/clear` between unrelated tasks and `/compact` at logical breakpoints. Do not let a single conversation balloon past roughly 200K tokens even when a larger window is available.\n\n**Step 5:** Plan in Opus, implement in Sonnet. Use Opus only where reasoning quality matters, then switch models for execution.\n\n* * *\n\n### Web and desktop app tactics\n\nThe CLI-only tricks don't apply to claude.ai or the desktop app, but a few habits still help:\n\n * Switch Opus to Sonnet unless you need the reasoning difference.\n * Start new conversations per task; context accumulates with every message.\n * Write specific prompts. \"Fix the JWT validation in `src/auth/validate.ts` line 42\" is far cheaper than \"fix the auth bug.\"\n * Pre-process large PDFs into plain text before uploading.\n * Disable web search, Research, and MCP connectors when they aren't needed. Tools and connectors are token-intensive.\n * Use projects for documents you'll reference repeatedly. Projects use retrieval instead of loading everything into context.\n * Turn off extended thinking for tasks that don't need it.\n\n\n\n* * *\n\n### What happens when you hit a limit\n\nA session-limit message shows a reset time five hours from your first message in that window. Hitting the weekly cap locks all-model usage until the weekly reset, which is tied to your own seven-day cycle rather than a fixed calendar day.\n\nPaid plans can purchase extra usage from the account settings, which adds a separate credit pool. Note that extra usage is billed against an API-style budget and resets monthly rather than being a permanent top-up. If extra usage is enabled, log out and back in if the CLI continues to show the limit message after a purchase.\n\nYou can check current consumption and reset times in the Claude Code CLI with the `/usage` command, which shows session percentage, weekly percentage, and any extra-usage balance in a single view.\n\n* * *\n\n### Monitoring burn rate\n\nAnthropic's in-product usage display updates slowly and lags actual consumption. Community-built tools fill the gap by reading local Claude Code logs:\n\n * `npx ccusage@latest` for daily, session, and 5-hour window reports.\n * `ccburn --compact` for visual burn-up charts and projections.\n * Claude Code Usage Monitor for a real-time terminal dashboard.\n * `ccstatusline` or `claude-powerline` for status-bar integration.\n\n\n\nThese are useful because the official meter doesn't expose token counts directly, and they help you see whether you're on track to finish a task before the next reset.\n\n* * *\n\n### When limits feel broken\n\nShort, clean prompts occasionally consume 30% or more of a session window. Two factors usually explain it. First, peak-hour throttling multiplies session consumption silently. Second, the 1M-context Opus variant sends a much larger payload per request than the 200K model, so each turn costs more tokens even for trivial tasks. Switching away from the 1M variant and confirming your model choice in the CLI resolves a lot of these spikes.\n\nIf session usage jumps with no obvious cause, try updating the Claude Code CLI to the latest version, then run `/compact` or `/clear` to rebuild the context from a clean state.\n\n* * *\n\n### Choosing the right plan for Claude Code\n\nThe practical breakpoints:\n\n * Pro at $20/month works for short, focused coding tasks and light planning. Sustained agentic loops will hit session limits quickly.\n * Max 5x at $100/month fits most individual developers doing daily Claude Code work on a single codebase.\n * Max 20x at $200/month is the practical tier for parallel sessions, long-running agent loops, and teams coordinating through one account.\n\n\n\nIf you're consistently hitting the weekly cap on Max 20x, the sustainable path is distributing load, with Claude handling planning and review and a second tool like Codex or a local model handling bulk implementation, rather than upgrading further.",
"title": "Claude Code usage limits explained: Pro, Max, and weekly caps",
"updatedAt": "2026-04-23T09:50:04.647Z"
}