Claude Code context window size: what actually fits

What a context window is—and is not

A context window is the information a model can reference while generating a response. In an API request, that includes the system prompt, message history, tool definitions and results, images or documents, and the new output. Anthropic's context guide says the output counts too.

It is not the model's training data, and it is not durable project memory. A Claude Code session starts with a fresh window. CLAUDE.md and auto memory can carry selected knowledge into a new session, but they use part of that new session's context when loaded.

That distinction matters in practice. A request to “remember the whole codebase” is not a useful operating plan. Give Claude the current goal, the relevant files, the acceptance check, and any constraints that apply. Keep a decision or handoff in a file when a future session must recover it.

Why there is no single Claude Code context-window size

People often quote a context limit as if it applied to every Claude product. It does not. API documentation describes capacity per model, while Claude Code, Claude.ai, managed environments, and third-party surfaces can select or restrict models differently. Account access and organization policy can change what you can select.

The current model overview lists context and output limits per API model. For Claude Code itself, the extended-context guide gives more useful conditions, checked September 9, 2026:

The guide says extended context uses standard model pricing, without the old premium beyond 200K. This is not unlimited usage: subscription allowances or usage credits still apply. Check /model for your available model and 1M option, and /context for the running session. Do not change a managed context setting simply to match a blog's number.

If you build against the API, query the Models API for models available to your account and their reported limits. Do not hard-code a blog's old model ID or assume the number shown for one product is the number available in another.

What fills a Claude Code session

The visible chat is only part of the context. Claude Code also loads project guidance. Its memory documentation says CLAUDE.md files enter the context at session start and recommends keeping each file under 200 lines. Imports still load, so splitting one oversized document into several always-loaded files does not create more room.

Use the smallest durable form of guidance that fits the job:

Run /context to confirm which memory files loaded. That is a useful diagnostic, not a guarantee that an instruction is enforceable: CLAUDE.md guides the model, while settings, permissions, and hooks govern what the client allows.

Claude Code's VS Code extension, shown in the official documentation.

A larger window still needs curation

More capacity can let you analyze a larger change or keep a longer investigation together. It does not make irrelevant material helpful. Anthropic explicitly warns that accuracy and recall can degrade as the token count rises; it calls that effect context rot.

Use a simple review loop:

1. State one deliverable and how you will verify it.
2. Name the files, subsystem, or documents that are in scope.
3. Keep recurring, broadly useful instructions concise; move specialized instructions behind a path or skill.
4. Ask separate Claude Code subagents to explore independent areas and bring back a short, sourced finding.
5. Before an edit, restate the evidence, remaining uncertainty, and the exact test to run.

This is not a trick for bypassing a limit. It gives the model less unrelated material to weigh and gives a reviewer a smaller, clearer trail to inspect.

For an API workflow that genuinely approaches its selected limit, use the documented token-counting endpoint before a request. Anthropic offers server-side compaction for eligible models and context editing for specialized cases. Cached prompt prefixes can change billing, but they still occupy context capacity.

Use eesel CLI for a focused support-context review

Consider a support owner who wants to check whether a helpdesk teammate still has the approved return-policy source after a documentation migration. The useful question is narrow: is the named source connected and ready, and do the teammate's standing instructions still point people to the approved escalation path?

Do not paste every support article, old ticket, and dashboard export into a coding chat. The owner supplies the approved teammate and source. Claude Code or a script then reads the current setup and prepares a comparison for that owner.

eesel CLI lets a person, script, Claude Code, Codex, or Cursor inspect the same teammate and workspace shown in the dashboard. JSON output helps the coding agent select the relevant facts for its review. A repository configuration does not choose the eesel identity or teammate for you.

With Node.js 18.17 or newer and an approved eesel login or script credential, first establish the actual identity. For an existing workspace, npx @eesel/cli login opens the browser and stores credentials if needed. The following reads state; it does not change the teammate:

npx @eesel/cli whoami
npx @eesel/cli agents

For a script, EESEL_API_URL and EESEL_API_TOKEN take precedence over stored credentials. That means a terminal and a CI job can reach different workspaces. Confirm the output with the support owner before continuing, and never put tokens in CLAUDE.md or a report.

Then use the exact teammate the owner approved. This example reads only the information needed for the migration review:

CONTEXT_REVIEW_AGENT="REPLACE_WITH_OWNER_APPROVED_AGENT"
npx @eesel/cli status --agent "$CONTEXT_REVIEW_AGENT"
npx @eesel/cli integrations --agent "$CONTEXT_REVIEW_AGENT"
npx @eesel/cli integrations download list --agent "$CONTEXT_REVIEW_AGENT"
npx @eesel/cli instructions --agent "$CONTEXT_REVIEW_AGENT"
npx @eesel/cli activity --agent "$CONTEXT_REVIEW_AGENT"

Ask the coding agent for a compact report with four rows: approved source, observed source status, relevant instruction, and an unresolved question. For example, it can flag that the source is connected but not ready, that an instruction names a retired escalation route, or that the inspected output does not show the field needed to decide. “Not shown here” is not the same as “absent.”

Have the owner supply only the approved policy excerpt, its version, and the intended escalation route for comparison. Source status is evidence of setup, not proof that the actual policy text is correct. Keep the full output available for an authorized reviewer, but bring only the relevant passage and finding into the coding conversation. That saves context without asking the coding agent to guess the missing policy or claiming the entire eesel knowledge base was loaded into Claude Code.

This workflow gives the support owner a reviewable difference; it does not authorize an automatic change. If the owner wants a correction, inspect that command's current --help, preview a supported write with --dry-run, and apply only the separately approved change. Read it back afterward. A preview is not an answer test. Setup and observation are free; chat is billed work. If a response test is needed, use an owner-approved nonproduction teammate with consequential actions Disabled in the actual Actions settings, and get approval for billed chats.

Keep the support review focused with eesel CLI

Choose the current model and surface for the task you actually have, then keep the session's working set small enough to review. A large context window helps when the relevant work is truly large. It is not a replacement for selecting evidence, preserving a handoff, or testing a result.

For support operations, the coding agent can review a narrow excerpt and setup while the owner manages the same eesel teammate in the dashboard. It does not need a second copy of every ticket in its own context window.

This example workspace is not evidence of a completed policy migration. Try eesel with one named support job and an owner who reviews its sources and behavior before expanding the scope.