Claude Code can feel slow while quota or token usage drops quickly because several different systems can produce the same symptom. The useful first move is to prove the active route, the exact limit or error class, and the context or cache shape before you upgrade, retry, or file a bug.
As of June 1, 2026, the safest diagnosis still starts with official surfaces: /status, /usage, /cost, the Claude Code status line, prompt-cache fields, and the exact error text. Community reports are useful because they show the pain is real, but they cannot tell you whether your current session is hitting subscription usage, API billing, provider rate limits, cache rebuilds, server overload, or a repeatable anomaly.
30-Second Branch Board: Slow + Burn
Use this table before changing your plan, rotating keys, clearing everything, or blaming a bug.
| What you see | Most likely owner | Proof to capture first | Smallest safe move |
|---|---|---|---|
Claude Code is slow and shows 529 or overloaded_error | Server-side overload or capacity | Exact error, any request_id, status page state, active route | Do one bounded same-path retry; use the 529 guide if it repeats |
| Pro or Max usage drops fast with no API-key route | Subscription usage window or shared plan drain | /status, Settings > Usage, five-hour/seven-day reset timing | Run a fresh scoped control task before upgrading |
| Costs or limits do not match your subscription expectation | API key, provider, or gateway route | /status, ANTHROPIC_API_KEY, base URL, Console or provider usage | Fix the route before interpreting quota; use the billing route guide |
One turn is slow and expensive after a pause, model switch, MCP change, /compact, or subagent | Cache rebuild, TTL expiry, or invalidated prefix | cache_creation_input_tokens, cache_read_input_tokens, recent invalidators | Stabilize route/model/MCP and verify the next similar turn; use the cache cost guide |
| Every turn gets heavier with no exact error | Context bloat, MCP/tool output, old session, model/effort overhead | context_window.current_usage, /context, /mcp, model, effort | Clear unrelated work, compact at a natural break, reduce tool output |
| A small controlled task still burns disproportionately | Suspicious repeatable spike | Route, model, timestamps, statusline/cache fields, screenshots, control run | Collect an evidence packet and escalate |
That branch split matters because the wrong fix can waste more usage. A 529 branch wants status and bounded retry. A cache branch wants token-class proof. An API route branch wants billing-owner evidence. A context branch wants session hygiene. A repeatable anomaly wants a clean support packet, not a bigger subscription.
Prove the Active Route Before Reading Any Meter
The same Claude Code terminal can represent different contracts. If you are logged into a Pro or Max plan, subscription usage is the first interpretation. If ANTHROPIC_API_KEY is set, Claude Code can use API authentication instead of subscription authentication. If a provider, base URL, or gateway is active, the provider route may own the limits and billing proof.
Start here:
bashclaude /status /usage /cost
/status tells you the active account or route and is the first subscriber-facing check inside Claude Code. /usage is the official usage command to inspect current usage surfaces. /cost is useful session telemetry, especially for API-style runs, but it is not automatically the authoritative bill for a Pro or Max subscription.
If you use a status line, make it carry proof instead of decoration. Useful fields include the active model, effort level, context-window usage, current cost, five-hour and seven-day usage percentages, reset timing, and cache creation/read fields when available. A status line cannot solve the issue by itself, but it helps you notice the branch while the session is still active.
The discipline is simple: do not compare a subscription usage message, an API estimate, an SDK cost field, and a provider invoice as if they were one meter. Each belongs to the route that produced it.
Slow Server, 529, 429, or Plan Limit?
Slowness is not always quota burn. A slow request can be server overload, provider congestion, a 529, a temporary throttle, a heavy context turn, or a local branch that forces Claude to read too much before acting.
Read the exact wording before you change anything:
| Exact signal | Meaning | First response |
|---|---|---|
529 or overloaded_error | Overload branch, not your personal quota by itself | Check status, retry same path once or twice with backoff, keep request evidence |
429 or rate_limit_error on an API/provider route | API or provider rate-limit branch | Read headers/provider logs, reduce concurrency, respect retry timing |
| Subscription session or weekly limit message | Plan usage branch | Check /status and Settings > Usage, then decide wait, usage credits, extra usage, or plan change |
| No exact error, just slow heavy turns | Context/cache/model/tool branch | Inspect context, cache fields, model, effort, MCP, and session age |
This split prevents two common mistakes. First, a 529 does not mean you need to buy more usage. Second, a 429 on an API route does not prove your Pro or Max subscription is exhausted. If the code, route, and meter disagree with your expectation, solve the mismatch before optimizing prompts.
When Normal Context Growth Looks Like a Bug
Many ugly Claude Code sessions are expensive but ordinary. Claude Code is not just answering a chat message. It reads files, keeps conversation history, uses tools, inspects results, and often loops through edits or tests before it finishes. The visible prompt count can stay low while the carried context grows.
Normal high-burn patterns include:
- one long session spanning several unrelated tasks
- broad "look through the repo" prompts
- repeated test or log output pasted into the main thread
- many active MCP servers or noisy tool outputs
- Opus or high-effort settings for routine edits
- subagents or forks that create separate context and cache behavior
- resuming an old session when a fresh task would be cheaper
The first control test is not "ask less." It is "make a comparable task smaller." Start a fresh session, keep the same route and model, scope the prompt to one concrete outcome, avoid unrelated files, and compare usage movement. If the fresh task burns much less, the original problem was probably context shape, not a hidden universal quota bug.
If MCP is the likely source, use /context and /mcp to see what is active. Disable or defer servers that are not needed for the current task, and prefer CLI tools when a compact command is cheaper than loading a large tool surface. For a deeper cleanup path, use the Claude Code MCP context overload guide.
Cache Rebuild, TTL Expiry, or Cache Bug?
A slow expensive turn can also be a cache branch. Claude Code's prompt caching is prefix-based: if the reusable prefix still matches and has not expired, later turns can read cached input cheaply. If the prefix changes, expires, or belongs to a different route scope, Claude may need to process or write it again.
Do not diagnose cache from total tokens alone. Look for token class fields:
| Field | What it tells you |
|---|---|
cache_creation_input_tokens | Input that was written into cache or rebuilt |
cache_read_input_tokens | Input that was read from an existing cache entry |
| full input tokens | Input that was processed without the cheap read path |
| output tokens | Generated text or tool output; cache does not make output free |
One cache write after a meaningful change can be expected. Repeated high cache creation with low cache reads on similar turns is stronger evidence that something is breaking reuse.
Common invalidators include model switches, effort changes, connecting or disconnecting MCP servers, denying an entire tool, running /compact, changing provider or route, long idle gaps, subagents, worktrees, or Claude Code version changes. If this is your main symptom, do not force the broader usage-limit article to solve it. Use the Claude Code cache miss token costs guide.
Run a Fresh Control Task Before You Escalate
The control task is the line between "this was a heavy session" and "this deserves escalation."
Keep it strict:
- Use the same active route you want to test.
- Use the same model and effort level.
- Start fresh or clear unrelated context.
- Ask for one small, comparable task.
- Capture
/status,/usage,/cost, statusline fields, and cache fields before and after. - Note whether the same slow/burn pattern repeats.
If the controlled task behaves normally, fix the workflow: shorter sessions, narrower prompts, fewer active tools, lower effort for routine work, and natural /compact or /clear boundaries. If the controlled task still burns a disproportionate amount, collect evidence while the state is fresh.
Smallest Fix Ladder
Choose the smallest fix that matches the branch:
| Branch | First fix | Do not do first |
|---|---|---|
| 529 or overload | Wait briefly, retry same path, keep request evidence | Upgrade plan or rotate keys |
| Subscription usage drain | Start fresh, scope task, check reset/usage | Treat /cost alone as billing truth |
| API/provider 429 | Respect retry timing, reduce concurrency, inspect provider limits | Assume subscription quota is gone |
| Cache rebuild | Stabilize model/MCP/route, verify cache creation/read fields | Compact blindly after every expensive turn |
| Context/MCP overhead | Clear unrelated work, reduce MCP/tool output, use CLI where cheaper | Add more tools to solve a tool-overhead problem |
| Model/effort overhead | Use Sonnet/Haiku or lower effort for routine work | Keep Opus/high effort as default for every task |
| Suspicious repeatable spike | Build evidence packet and escalate | Buy more headroom to hide the symptom |
Plan changes belong late in the sequence. Upgrade when your normal repeatable workload needs more room. Buy extra usage or usage credits when overflow is temporary and understood. Switch to API billing when you want explicit token economics, spend ceilings, or automation throughput. Do not let one unexplained slow session decide the whole economics of your workflow.
Escalation Packet for Suspicious Spikes
When the spike repeats after controls, collect a packet that lets support, a teammate, or a GitHub issue compare the same route and context shape:
- timestamp and timezone
- Claude Code version
- active route from
/status - whether
ANTHROPIC_API_KEY, base URL, provider, or gateway was active - model and effort level
- exact error text, including
429,529, or limit message - statusline rate/context fields before and after
cache_creation_input_tokensandcache_read_input_tokenswhen relevant- recent invalidators: model change, MCP change,
/compact, subagent, route change, upgrade, long idle gap - screenshot or written note from Settings > Usage when on subscription usage
- API Console/provider billing proof when on API/provider route
- the fresh control task result
That packet is more useful than a dramatic complaint. "Same route, same model, fresh task, no MCP change, five-hour usage jumped from X to Y, cache creation stayed high, repeated twice" gives someone a real comparison. "Claude ate my quota" does not.
Frequently Asked Questions
Why is Claude Code slow and burning through quota?
The common branches are overload, subscription usage, API/provider rate limits, cache rebuilds, context bloat, MCP/tool overhead, model or effort choice, and repeatable anomalies. Start with route and exact error or meter proof before choosing a fix.
Should I trust /status, /usage, or /cost?
Use /status to confirm route and allocation context, /usage for the current usage surface, and /cost as session-level cost telemetry. /cost is useful, but it is not automatically the authoritative bill for every subscription case.
Is a slow expensive turn always a cache bug?
No. It can be a normal cache write, TTL expiry, changed prefix, model switch, MCP change, /compact, route change, or subagent behavior. Use cache_creation_input_tokens and cache_read_input_tokens before calling it a cache bug.
Is 529 the same as hitting my Claude Code quota?
No. 529 or overloaded_error is the overload branch. Check status and retry the same path with bounded backoff before changing quota or billing assumptions.
Is 429 the same as 529?
No. 429 is the rate-limit branch, usually API or provider rate limiting. 529 is overload. If you are on a subscription route and see a plan usage message, that is a third branch.
When should I upgrade to Max or buy more usage?
Upgrade or buy extra usage after you know the drain is normal for your repeatable workload. If the drain is suspicious, first run the fresh control task and collect proof. More headroom can hide a problem without explaining it.
What is the fastest usage-saving change?
For many users, the fastest change is a fresh, scoped session for unrelated work, plus fewer active MCP/tool surfaces and a cheaper model or effort level for routine edits. If cache fields show repeated creation, stabilize the route/model/MCP setup and verify the next similar turn.