Long-Context Prompting with Claude (1M Tokens): What Actually Works

TL;DR: Claude's newest models now handle up to 1M tokens across chat, Claude Code, and the API, but window size stopped being the bottleneck. What actually degrades is recall inside that window, a problem Anthropic calls context rot. Put your documents first, your question last, and ask Claude to quote before it reasons.

How big is Claude's context window, really?

Bigger than most people assume, and it depends on where you're asking. "Claude's context window" is not one number in 2026; it is a matrix of model and surface, and the two other things everyone assumes (that ChatGPT and Gemini are still smaller, and that a bigger window means better recall) are both wrong.

Here is the verified breakdown, current as of September 2026, straight from Anthropic's own help center and API documentation:

Anthropic states it plainly: "Claude Fable 5.1, Opus 5, and Sonnet 5 support a 1M token context window on all paid plans when chatting with Claude. Claude Opus 4.8, Opus 4.7, Opus 4.6, and Sonnet 4.6 support a 500K token context window on all paid plans when chatting with Claude" (How large is the context window on paid Claude plans?, read September 2026). On Claude Code specifically, the same page notes a wrinkle worth knowing before you assume: "Pro users need to enable usage credits to access the 1M token context window for Opus models."

On the API side, Anthropic's models overview puts a real size on that number: "1M tokens is roughly 555k words or 2.5M Unicode characters on the current tokenizer (introduced with Claude Opus 4.7)" (Models overview, read September 2026). That is genuinely enormous. It is also, by itself, not the interesting part of this story.

The per-surface split matters in a practical way, not just a trivia way. It is entirely possible to confirm a 1M-token window in a claude.ai chat, then paste the same enormous document into Claude Code on a Pro plan and get truncated results, because the usage-credit condition on that surface never got flipped on. If a long-context prompt is behaving worse than it did somewhere else, check which surface and which plan you're actually on before you assume the model regressed.

Is a bigger context window actually the differentiator any more?

No, and this is the correction worth making up front. A live comparison on this site once treated Claude's long-context edge as a settled advantage over ChatGPT; by 2026 both flagships had converged on roughly 1M tokens, and our own ChatGPT vs Claude guide already documents that the two "have largely converged" on window size, with the real difference having "moved from window size to recall quality inside the window." Kimi K3 ships a near-identical 1,048,576-token window of its own. If you're choosing a model based on which one has the biggest window, you're optimizing the wrong variable in 2026.

Once three separate labs have shipped roughly the same ceiling, the ceiling stops being useful information for a buying decision. What's left to actually compare is price per token, latency, and how gracefully each model degrades as you approach that ceiling, and that last one is precisely what the rest of this guide is about.

Context window size answers "how much can I fit." It says nothing about "how much will it actually use."

Does a bigger context window mean Claude uses all of it well?

No, and Anthropic names the effect directly rather than leaving it implied. Its own developer documentation states: "As token count grows, accuracy and recall degrade, a phenomenon known as context rot" (Context windows, read September 2026).

Anthropic's engineering team goes further in a companion piece written for people building agents, but the mechanism applies just as much to a single long chat: "Studies on needle-in-a-haystack style benchmarking have uncovered the concept of context rot: as the number of tokens in the context window increases, the model’s ability to accurately recall information from that context decreases" (Effective context engineering for AI agents, read September 2026). The same piece explains why, naming the resource models are actually short on: "LLMs have an “attention budget” that they draw on when parsing large volumes of context. Every new token introduced depletes this budget by some amount, increasing the need to carefully curate the tokens available to the LLM."

That reframes the whole practical question. Once you accept that tokens have a cost beyond the ones on your invoice, the job shifts from "how do I get more context in" to "how do I make Claude actually use the context I gave it." The rest of this guide is about that second question.

How do you structure a prompt so Claude actually uses everything you gave it?

Put the material first, and label it. Anthropic's own current prompting guidance says exactly this under the heading "Put longform data at the top": "Place your long documents and inputs near the top of your prompt, above your query, instructions, and examples. This improves performance across all models" (Claude prompting best practices, read September 2026).

It gets more specific than "it helps." The same page states: "Queries at the end can improve response quality by up to 30 percent in tests, especially with complex, multidocument inputs." That is a large, named effect from the vendor whose model you are prompting, not craft folklore.

For more than one document, wrap each in its own tagged block so Claude can tell them apart without guessing from formatting alone:

<documents>
  <document index="1">
    <source>q3_board_deck.pdf</source>
    <document_content>
      {{Q3_BOARD_DECK}}
    </document_content>
  </document>
  <document index="2">
    <source>competitor_pricing_notes.txt</source>
    <document_content>
      {{COMPETITOR_NOTES}}
    </document_content>
  </document>
</documents>

Compare the pricing assumptions in the board deck against the competitor
notes above. List every place they disagree, citing the source tag for
each side of the disagreement.

Notice the order: the tagged documents come first, the instruction comes last. That ordering is not a style preference; it is the specific structure Anthropic's own guidance measured.

Where should the question go, and do OpenAI and Google agree?

Google agrees with Anthropic. OpenAI does not, and this is a real, current split between vendors rather than something one of them got wrong.

Google's Gemini prompt design guidance is nearly a restatement of Anthropic's: "Structure for long contexts: When providing large amounts of context (e.g., documents, code), supply all the context first. Place your specific instructions or questions at the very end of the prompt" (Prompt design strategies, read September 2026). It also names a specific bridge technique Anthropic's page does not spell out on its own: "Anchor context: After a large block of data, use a clear transition phrase to bridge the context and your query", offering its own worked example of one: Based on the information above...

OpenAI's own prompt engineering guide describes the opposite order for the same kind of content. Listing the sections a developer message typically contains, its entry for "Context" places that section last, for a different stated reason: "Give the model any additional information it might need to generate a response, like private/proprietary data outside its training data, or any other data you know will be particularly relevant. This content is usually best positioned near the end of your prompt, as you may include different context for different generation requests" (Prompt engineering, read September 2026).

Two vendors say one thing, one says another, and both sides cite a real reason rather than a guess. If you are writing one prompt template you intend to reuse across Claude, Gemini, and ChatGPT with the same long document, this is the one structural choice you cannot copy-paste across all three. Build your document-heavy prompts for Claude with the document on top; if the same content is going into ChatGPT afterward, move it to the bottom rather than assuming the same layout works everywhere.

How do you get Claude to prove it actually read the right part?

Ask it to quote before it concludes. This is the single highest-leverage technique in this guide, and it is Anthropic's own documented fix for context rot inside a genuinely long document, filed under the heading "Ground responses in quotes", not a trick discovered by trial and error: "For long document tasks, ask Claude to quote relevant parts of the documents first before carrying out its task. This helps Claude focus on the relevant content and ignore the rest of the document" (Claude prompting best practices, read September 2026).

<documents>
  <document index="1">
    <source>vendor_contract_v3.pdf</source>
    <document_content>
      {{CONTRACT_TEXT}}
    </document_content>
  </document>
</documents>

First, find every clause in the contract above that mentions termination,
renewal, or notice periods. Quote each one exactly, inside <quotes> tags,
citing the section number. Only after you have listed every quote, write
your summary of what the termination terms actually require, inside
<summary> tags.

The quotes do two jobs at once. They force Claude to locate the actual passage instead of pattern-matching to a plausible-sounding summary, and they give you something concrete to check before you act on the conclusion. If a quote doesn't actually exist at the cited location, you know the summary built on it is suspect before you've relied on anything. That instinct, checking the load-bearing claim before you trust what's stacked on top of it, is the same discipline behind red-teaming your own prompt; grounding in quotes is the long-document version of it.

What do you do when the material genuinely doesn't fit, or barely does?

Curate, don't cram. Anthropic's engineering guidance, again written primarily for agent builders but just as applicable to a person managing one very long chat, states the goal plainly: "good context engineering means finding the smallest possible set of high-signal tokens that maximize the likelihood of some desired outcome" (Effective context engineering for AI agents, read September 2026).

In practice, for someone working in a chat window rather than building an agent pipeline, that translates into three habits:

• Chunk by logical unit, not by raw length. Split a huge document drop at chapter, section, or contract-clause boundaries, not at an arbitrary character count. A chunk that respects the original structure is a chunk Claude can reason about coherently.
• Carry a running summary forward instead of re-pasting the source. Once Claude has read and summarized a section, keep the summary in context for later turns and drop the raw source text. This is the same instinct behind Claude Cowork automatically compacting a conversation once it crosses 500K tokens: past a point, the compressed version of what happened is more useful than the raw transcript.
• Name what you're asking for before you paste the material. State the question first in your own head, then decide which parts of the document actually bear on it. Pasting everything and hoping the question sorts itself out is exactly the pattern that produces context rot.
• Treat the compaction point as a signal, not a failure. When Claude Cowork compacts a conversation at 500K tokens, that is the product doing on your behalf exactly what this section recommends doing yourself earlier: keeping the useful summary and letting the raw history go. If you notice a long chat getting harder to steer well before any documented limit, that is your cue to summarize and restart rather than push further into the same thread.

A copy-paste template for a real multi-document task

Put this together and the previous four sections become one reusable pattern: documents first, tagged, followed by a quote-then-conclude instruction, with the actual question last.

<documents>
  <document index="1">
    <source>{{DOC_1_NAME}}</source>
    <document_content>
      {{DOC_1_TEXT}}
    </document_content>
  </document>
  <document index="2">
    <source>{{DOC_2_NAME}}</source>
    <document_content>
      {{DOC_2_TEXT}}
    </document_content>
  </document>
</documents>

Step 1: Quote every passage from the documents above that is directly
relevant to {{YOUR_QUESTION}}. Cite the source and section for each quote.
Do not paraphrase in this step.

Step 2: Based only on the quotes you just extracted, answer:
{{YOUR_QUESTION}}

If the documents do not contain enough information to answer fully, say
so explicitly rather than filling the gap from general knowledge.

That last line matters as much as the structure around it. A 1M-token window makes it easy to forget that "the answer isn't in what I gave you" is a valid and useful response. Ask for it explicitly, and a long-context prompt stops being a bet on whether the model found the right paragraph and starts being a process you can actually check.