Claude Code Context, Models, Limits, and Cost: A Diagnostic Guide

“Claude Code is slow” can describe six different constraints: a large or noisy context, a task that needs a more capable model or higher effort, a provider or network delay, a subscription or API limit, a long-running tool command, or a workflow that repeatedly pays for the same information.

Treat those as separate diagnoses. Changing the model does not repair a hanging test. Compacting does not reset a usage allowance. A larger context window does not make irrelevant evidence useful. This guide reflects Anthropic’s official documentation checked on August 9, 2026; verify current availability and pricing before making a purchasing decision.

Identify the constraint before tuning it

Use this first-pass table:

Symptom	Likely boundary	First evidence
Claude loses an earlier requirement or context is nearly full	Context management	Context view, loaded instructions, recent tool outputs
Small tasks pass but complex changes fail validation	Capability or effort	Same-task evaluation across model and effort settings
Every response pauses while commands finish	Tool runtime	Command duration, captured output, process state
Requests stop until a displayed reset time	Subscription usage limit	`/usage` and the exact limit message
API returns rate-limit errors	API or provider quota	Status code, rate-limit headers, provider dashboard
First turn after model, MCP, compact, or upgrade is expensive	Prompt-cache rebuild	Cache creation and read token counts
Long sessions cost more on every turn	Accumulated context	Token use by layer and task boundary

Capture the Claude Code version, authentication provider, model, effort, mode, active MCP servers, task prompt, command timings, and validation result. “It felt faster” is not a routing policy.

Understand what occupies context

Claude Code’s context contains system instructions and tools, project instructions, auto memory, skill descriptions and loaded skill content, conversation messages, file reads, model responses, and tool results. MCP tool names and some definitions also contribute. Context is not only what you typed.

Large command output is a common avoidable source. Prefer a focused test, a bounded log range, a targeted search, or a saved artifact plus a short summary. Do not paste an entire build log when the exit status and first relevant stack trace answer the question.

Use indexes before bodies. Ask Claude to locate candidate files, then read the smallest relevant set. For large repositories, path-scoped rules and on-demand skills keep unrelated instructions out of every task.

Choose compact, clear, rewind, or resume deliberately

/compact replaces older conversation history with a summary. Use it at a stable boundary after decisions, current state, validation results, and remaining work are explicit. You can add instructions to the command to name what the summary must preserve.

Compaction is lossy. Exact earlier command output, code, and nuance may need to be read again. It also changes the conversation prefix, so the next request rebuilds that part of the prompt cache.

Use /clear when changing to an unrelated task. Stale context otherwise remains in every later request. Rename or preserve a short handoff if you need to return, then use the documented resume flow.

Use rewind when you want to abandon a path and return to a known earlier point. A fresh session is preferable when the goal, repository, authority, or investigation has materially changed. Re-prime it from current files and Git state instead of copying a long transcript.

A compact handoff should state:

goal and non-goals;
current branch and working-tree ownership;
decisions already made and why;
exact files changed;
commands run and observed results;
unresolved failures and the next smallest step.

Select the least expensive model that passes the validators

Model choice is an evaluation decision, not a prestige decision. Run representative tasks through the same prompt, tools, permissions, and validators. Measure accepted outcomes, correction time, retries, wall time, tool failures, and total usage.

Start routine, bounded, externally verifiable work on a lower-cost lane. Escalate when failures show a capability gap: cross-file reasoning, difficult debugging, ambiguous architecture, recovery from tool errors, or high-cost judgment. Do not escalate merely because a prompt is long; reduce irrelevant context first.

Effort and model are different controls. Lower effort can reduce reasoning time and may reduce quality on difficult work. Fast mode, where available, is a separate latency-and-price configuration and not a lower-effort model. Anthropic currently documents fast mode as a research preview with model, plan, provider, and extra-usage restrictions. Treat its current price and availability as time-sensitive inputs.

The one-million-token variants are also availability and billing choices, not permission to fill the window. Anthropic’s model configuration documentation distinguishes plan support and usage-credit requirements. Check /model and the current plan documentation rather than assuming every account or cloud provider exposes the same variant.

Use staged retrieval for long-context tasks

A robust long-context workflow has stages:

task brief
→ repository or document index
→ small evidence set
→ gap analysis
→ targeted expansion
→ verified output

This improves signal density and makes failures attributable. Keep stable reference material in files, rules, or skills; do not ask the conversation to be the only memory of an architecture decision.

For repeated work, preprocess deterministic material. A script can enumerate files, normalize metadata, extract a schema, or run validation more consistently than repeatedly asking the model to reconstruct it. Scripts are not “zero-token”: their invocation and returned output still enter the workflow. Their advantage is repeatability and bounded output.

Distinguish prompt-cache behavior from context size

Claude Code uses prefix caching. When consecutive requests share an exact prefix, previously processed tokens can be read from cache. The relevant usage fields include cache creation and cache read tokens.

Common cache invalidations include switching models, connecting or disconnecting MCP servers, compacting, and launching after a client upgrade. Effort changes do not currently alter the cache key. A first uncached turn after one of those changes can be slower and more expensive without indicating a permanent regression.

Keep the model and MCP set stable during a task when practical. Switch at a natural boundary. If cache creation remains high across ordinary turns, inspect which prefix component is changing rather than disabling caching as a general remedy.

Claude Code handles caching automatically for normal use. Provider and gateway behavior can differ, and cache storage location follows the authentication route. Use the official prompt-caching and data-usage pages for current retention and billing details.

Separate usage limits from API rate limits

Subscription session, weekly, or model limits display a reset time. /usage shows plan allowance information. When the limit is reached, wait for the shown reset, use an authorized extra-usage option, or change the plan through the supported billing path. Repeated CLI retries do not create allowance.

API and cloud-provider rate limits are different. Record the status code, headers, quota scope, and provider. Use bounded exponential backoff only for errors documented as retryable. A context overflow, invalid request, permission denial, or exhausted budget needs a different correction.

Do not publish fixed “messages per hour” tables as universal Claude Code limits. Subscription usage depends on plan and workload, and API quotas are organization and provider configuration. Link to current pricing and dashboards instead.

Bound long-running commands

A command can be slow even when the model is responsive. Before raising a timeout:

Reproduce the exact command outside Claude Code.
Determine whether it is progressing, waiting for input, blocked on network, or deadlocked.
Narrow the test, build target, log scope, or data range.
Preserve the exit code and relevant output.
Run the full required suite once the focused diagnosis passes.

Printing progress does not make a stuck operation correct. A timeout should be long enough for a measured healthy run plus variance, and short enough to leave time for failure recording and cleanup. Cap retries and stop when the same failure repeats without new evidence.

Measure cost per accepted outcome

API users can inspect session usage and use the Console for authoritative billing. Subscription users see plan usage rather than treating the local dollar estimate as their invoice. Bedrock, Vertex, Foundry, and gateways have their own billing and observability paths.

Record:

uncached input, cache creation, cache read, and output tokens;
tool or provider charges outside token billing;
retries and failed runs;
model, effort, context variant, and fast-mode state;
accepted outcome, human correction time, and wall time.

The useful denominator is an accepted task, not a model response. A cheaper model that needs three retries and an hour of repair can cost more than a stronger model. A frontier model used on every extraction task can waste money even if every response is good.

For a script-versus-instruction experiment, keep the client version, model, effort, prompt, cache state, source data, validators, and number of repeated runs fixed. Report the distribution rather than one favorable run.

Practical operating presets

Small verified change

Fresh or short session.
Focused context and tests.
Default or economical model that passes the task.
Normal latency mode.
Stop after the focused and required checks pass.

Difficult repository diagnosis

Index first, then targeted reads.
Higher-capability model or effort only after a measured failure.
Stable MCP set and model during the investigation.
Compact at a decision boundary, preserving failed hypotheses and evidence.

High-volume automation

Non-interactive mode with bounded turns and structured output.
Deterministic preprocessing and validation.
Fresh task context rather than a growing shared conversation.
Cost, retry, timeout, and side-effect caps.

Live debugging

Measure whether latency comes from the model or commands.
Use fast mode only when currently supported and the latency value exceeds its extra cost.
Turn it on at the start of a session to avoid an avoidable mid-context cache change.

The durable strategy is diagnostic: reduce irrelevant context, select the least expensive lane that passes, keep cache behavior observable, separate plan limits from API quotas, and bound tool execution. Recheck the official pages whenever model names, context variants, fast mode, or pricing enter a decision.

Continue with the setup guide, Git and parallel workflows, and comparison guide.