If you use Claude Code and Claude chat with the same subscription, you are probably assuming they give you the same working memory. They do not. On the same paid plan, Anthropic’s help centre states that 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” — and then states that in Claude Code, the same models “support a 1M token context window.” Same subscription, same model, twice the window in the terminal.
That discrepancy is a fair summary of this whole topic: the context window is the least-documented number in the Claude stack and the one most likely to be quoted wrongly. This page collects what Anthropic actually publishes about it — the sizes, who gets which one, what fills the window before you type a single character, what caching and compaction cost, and what happens when you run out. Every figure below is quoted from an Anthropic page named at the bottom. Where Anthropic publishes nothing, it says Not published and names the pages checked.
First: the context window is not your usage limit
These two get conflated constantly, including by people writing about them. Anthropic separates them explicitly. Usage limits “control how much you can interact with Claude over a specific time period.” Length limits “relate to Claude’s context window—the amount of information Claude can work with in a single chat.” The summary sentence on the same page is the one to memorise: “usage limits control how much you can use Claude across all your conversations, while length limits control how long any single conversation can become.”
The Claude Code cost documentation is blunter still, in the section written for admins fielding questions. A “context or auto-compact warning,” it says, is “not a usage limit.”
The practical consequence is that the two failure modes have opposite fixes. Filling the context window is solved by clearing, compacting or starting a new session — waiting does nothing. Exhausting your usage allowance is solved by waiting for a reset or buying credits — starting a new conversation does nothing. We cover the second one in detail in when Claude’s usage limits reset, and the plan-level allowances in Claude Pro usage limits. This page is about the first.
Context window sizes, by where you are using Claude
Anthropic publishes three different answers depending on the surface, which is why nobody agrees on this number. Here is each one, quoted.
On the API
From the platform documentation: “Claude Opus 5, Claude Opus 4.8, Claude Opus 4.7, Claude Opus 4.6, Claude Sonnet 5, and Claude Sonnet 4.6 have a 1M-token context window on the Claude API, Amazon Bedrock, Google Cloud, and Microsoft Foundry.” Claude Fable 5 and Claude Mythos 5 also have a 1M-token window. “Other Claude models, including Claude Sonnet 4.5, have a 200k-token context window.”
Two details that get lost. First, output is capped separately: “A single request to any model with a 1M-token context window can generate up to 128k output tokens.” Second, there is no premium tier to buy — “For every model with a 1M-token context window, 1M is the default: you don’t need a beta header, and long-context requests are billed at standard pricing.”
In Claude chat, on a paid plan
From the help centre: “Claude 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. Outside of these models, Claude’s context window size is 200K.”
Note the 500K tier. It exists only in chat — it appears nowhere in the API documentation, where those same models are 1M.
In Claude Code, on a subscription
From the same help article: “When using Claude Code with a Pro, Max, Team, or Enterprise plan, Claude Sonnet 5, Fable 5, Opus 5, Opus 4.8, Opus 4.7, and Opus 4.6 support a 1M token context window. Pro users need to enable usage credits to access the 1M token context window for Opus models. Sonnet 4.6 also supports a 1M context window for all paid Claude plans on Claude Code, but usage credits must be enabled to access it (except for usage-based Enterprise plans).”
The Claude Code documentation puts the same rule in a table, and adds that on “Max, Team, and Enterprise plans, including both Team Standard and Team Premium seats, Opus is automatically upgraded to 1M context with no additional configuration.”
| Plan | Opus with 1M context | Sonnet 4.6 with 1M context |
|---|---|---|
| Max, Team, Enterprise | Included with subscription | Requires usage credits |
| Pro | Requires usage credits | Requires usage credits |
| API and pay-as-you-go | Full access | Full access |
This is the single most actionable fact on the page for anyone weighing tiers. The 5x and 20x multipliers describe how much usage you get; they say nothing about how much context you get. Moving from Pro to Max does not just raise your allowance, it flips Opus 1M from credits-funded to included. If that is the axis that matters to you, our breakdown of Claude Max 5x vs 20x covers the rest of the tier comparison, and whether Claude Code is free covers the entry paths below Pro.
One more published constraint, easy to miss: “A portion of the context window is always reserved for Claude’s response, so the longest possible conversation is slightly smaller than the full window.” How much is reserved? Not published.
What is already in the window before you type
A Claude Code session does not start empty. Anthropic’s prompt caching documentation describes what every single request carries: “Claude Code re-sends the full context: the system prompt, your project context, every prior message and tool result, and your new message.”
Those pieces are deliberately ordered so the stable parts come first:
| Layer | Content | Changes when |
|---|---|---|
| System prompt | Core instructions, tool definitions, output style | The set of loaded tool definitions changes, or Claude Code is upgraded |
| Project context | CLAUDE.md, auto memory, unscoped rules | Session starts, or after /clear or /compact |
| Conversation | Your messages, Claude’s responses, tool results | Every turn |
On the API side the accounting rule is stated without exceptions: “Everything in the request counts toward the context window: the system prompt, every message in messages (including tool results, images, and documents), and your tool definitions. The output Claude generates for the turn, including its extended thinking, counts too.”
And the sentence that kills the most common misconception about caching: “Cached prompt prefixes still occupy the context window: prompt caching changes what you pay for those tokens, not whether they count.” Caching is a billing mechanism, not a compression mechanism.
How many tokens does Claude Code’s own system prompt consume? Anthropic ships an interactive explorer of the context window rather than a committed figure, so a real per-component token budget is Not published. Pages checked: the Claude Code context-window explorer, the prompt caching page, the cost management page, and the two help-centre articles on limits.
Why bigger is not automatically better
Anthropic is unusually candid here, and it undercuts the marketing value of its own 1M number: “A larger context window allows the model to handle more complex and lengthy prompts, but more context isn’t automatically better. As token count grows, accuracy and recall degrade, a phenomenon known as context rot. This makes curating what’s in context just as important as how much space is available.”
So the goal is not to fill the window. Two habits from the cost documentation follow directly: “Clear between tasks: Use /clear to start fresh when switching to unrelated work. Stale context wastes tokens on every subsequent message,” and, for CLAUDE.md, “Aim to keep CLAUDE.md under 200 lines by including only essentials,” because that file “is loaded into context at session start” and its tokens “are present even when you’re doing unrelated work.”
Auto-compaction: the threshold you can actually set
Most of the context window’s behaviour is fixed. The compaction threshold is not. Anthropic defines it plainly: “The auto-compact window is how full the context window can get before Claude Code compacts the conversation.”
You can set it in three places — /autocompact 500k for this session and later ones, the --autocompact flag for one launch, or CLAUDE_CODE_AUTO_COMPACT_WINDOW in scripts and cloud environments, which “takes precedence over the command, the flag, and the setting.” The accepted range is published: “a window size from 100K to 1M tokens.” And there is a hard ceiling — “Claude Code caps the window at the model’s context window” — so you cannot use this to fake a larger window.
Left alone, “Claude Code compacts when the conversation reaches the model’s context limit,” with documented exceptions: cloud sessions compact as the conversation approaches the limit; “Sonnet 4.6 and Opus 4.6 without extended context compact at the 200K boundary”; and with CLAUDE_CODE_DISABLE_1M_CONTEXT=1, models with a native 1M window compact at 200K instead. Sonnet 5 gets its own number, and it is the only concrete auto-compact figure Anthropic publishes: sessions “auto-compact before the window fills, at about 967K tokens by default.”
What compaction costs — and why /clear is free
Compaction is not a free reset. “To produce the summary, Claude Code sends a separate request with the same system prompt, tools, and history as your conversation, plus a summarization instruction appended as a final user message.”
Whether that hurts depends entirely on cache temperature. Warm: “that request reads your prefix from the cache, so a mid-session /compact costs a fraction of what the context size suggests and spends most of its time generating the summary.” Cold: “After a break longer than the cache lifetime, there is no cache left to read, so the summarization request reprocesses the full history as uncached input. This is why /compact costs the most when you resume an old session.”
Against that, one sentence settles the /clear versus /compact question for good: “When you want a fresh start instead of continuity, /clear costs nothing.” If you do not need the history summarised, do not pay to summarise it. And if you simply went down a wrong path, /rewind is cheaper than both: “Rewinding truncates back to a prefix that is already cached, rather than building a new one as compaction does.”
Caching: the mechanism that makes a full window affordable
Prompt caching is why a 500,000-token conversation does not cost 500,000 tokens per message. The API “caches by matching the start of each request, called the prefix, against content it recently processed.” Two constraints matter more than any tip you will read elsewhere: “The match is exact, so a change anywhere in the prefix recomputes everything after it,” and “There is no per-file or per-segment caching.”
When it works, the saving is documented as a rate: cache_read_input_tokens are “billed at roughly 10% of the standard input rate.” That is the entire economics of a long session in one line.
The cache also expires. On a subscription, “Claude Code requests the one-hour TTL automatically, so the cache survives breaks of up to an hour.” Once you exhaust your plan allowance and start drawing on usage credits, “Cache writes cost more at the one-hour TTL than at the five-minute TTL, so Claude Code automatically drops to the shorter one” — you can override that with ENABLE_PROMPT_CACHING_1H=1. On an API key or a cloud provider, “the TTL stays at the cheaper five minutes by default.”
That twelve-fold drop at exactly the moment you start paying per token is the sharpest edge in the whole system, and it is the same one that makes credits worse value than the headline API rate suggests. We work through that arithmetic against OpenAI’s metering in Claude Max versus Codex usage limits.
The eight things that throw the cache away
Anthropic lists them explicitly. Each causes “a one-time slower, more expensive turn, after which the new prefix is cached”:
- Switching models. “Each model has its own cache,” so a
/modelswitch “means the next request reads the entire conversation history with no cache hits, even though the content is identical.” Plan-mode toggling withopusplancounts, because it swaps Opus for Sonnet. - Changing effort level. “The cache is keyed by effort level as well as model.” Claude Code shows a confirmation dialog first.
- Turning on fast mode. It “adds a request header that is part of the cache key.” The cost applies once per conversation.
- Connecting or disconnecting an MCP server — but only when its tools sit in the prefix. With the default deferred loading, “a server connecting, disconnecting, or changing its tool list only appends new content and doesn’t disturb anything already cached.”
- Enabling or disabling a plugin that provides MCP servers. Skills, commands, agents, hooks and themes “never invalidate the cache.”
- Denying an entire tool by adding a bare name like
Bashas a deny rule. Scoped rules likeBash(rm *)leave the prefix intact. - Compacting the conversation. By design.
- Upgrading Claude Code. “A new Claude Code version typically updates the system prompt or tool definitions, so the first request after an upgrade rebuilds the cache from the top.”
Resuming after an upgrade is the worst case and carries its own warning: it “reprocesses the entire conversation history with no cache hits… the first turn back into a long session can be the most expensive request you send.”
Seeing your own window instead of guessing
Three published instruments, in order of usefulness.
/context is the direct one. The cost documentation introduces it in the MCP section — “Run /context to see what’s consuming space” — which is also the clearest statement that MCP servers are a common answer.
The status line. “Use /usage to check your current token usage, or configure your status line to display it continuously.” A continuous readout is the difference between noticing context growth and being surprised by an auto-compact mid-task.
The /usage breakdown. On a paid plan it attributes recent consumption “to skills, subagents, plugins, and individual MCP servers, each shown as a percentage of the total,” and raises behaviour flags “such as long context or cache misses, flagged when one accounts for 10% or more of recent usage.” Long context appearing there is the system telling you your window is the problem. Two caveats from the same page: the figures “are approximate and computed from local session history on this machine,” and usage “from other devices or claude.ai is not included.”
On the API there is a fourth instrument that has no consumer equivalent: some models receive their remaining budget injected directly. “Claude Sonnet 5, Claude Sonnet 4.6, Claude Sonnet 4.5, and Claude Haiku 4.5 have context awareness,” receiving tags such as <system_warning>Token usage: 35000/200000; 165000 remaining</system_warning> after each tool call. “Claude Opus 4.7 and later Opus models, Claude Fable 5, and Claude Mythos 5 don’t receive these injected tags.”
The levers that shrink the window, ranked by published impact
Anthropic’s own list, condensed, with the mechanism attached to each so you can tell which ones apply to you:
- Clear between unrelated tasks. Free, immediate, and the only lever that removes history rather than summarising it. Use
/renamebefore clearing so you can/resumelater. - Delegate verbose work to subagents. “Running tests, fetching documentation, or processing log files can consume significant context. Delegate these to subagents so the verbose output stays in the subagent’s context while only a summary returns to your main conversation.” A subagent “starts its own conversation with its own system prompt and tool set” — though note it “uses the five-minute TTL even on a subscription.”
- Trim MCP servers. Tool definitions are “deferred by default, so only tool names enter context until Claude uses a specific tool,” but Anthropic still recommends CLI tools where they exist because they “don’t add any per-tool listing,” and suggests
/mcpto disable unused servers. - Move instructions out of CLAUDE.md into skills, which “load on-demand only when invoked.”
- Filter tool output with hooks. “Instead of Claude reading a 10,000-line log file to find errors, a hook can grep for
ERRORand return only matching lines, reducing context from tens of thousands of tokens to hundreds.” - Lower the effort level. “Thinking tokens are billed as output tokens, and the default budget can be tens of thousands of tokens per request depending on the model.”
MAX_THINKING_TOKENScaps it on models with a fixed budget; adaptive-reasoning models “ignore nonzero budgets, so use effort levels there instead.” Thinking “cannot be turned off on Fable 5.” - Keep agent teams small. They “use approximately 7x more tokens than standard sessions when teammates run in plan mode, because each teammate maintains its own context window.”
What happens when the window actually overflows
With auto-compaction off, or on a raw API call, the failure is explicit: “If the input alone already exceeds the model’s context window, the API returns a 400 invalid_request_error (‘prompt is too long’) on every model.” Claude Code surfaces the same string as a Prompt is too long error when compaction is disabled and a session hits the 200K boundary.
Generation can also run out mid-answer. “On Claude 4.5 models and newer, if input tokens plus max_tokens exceeds the context window size, the API accepts the request. If generation then reaches the context window limit, it stops with stop_reason: "model_context_window_exceeded".”
In chat, the equivalent is handled for you where code execution is enabled: “When your conversation approaches the context window limit, Claude summarizes earlier messages to make room for new content. This does not count towards your usage limit.” That last clause is worth reading twice — automatic context management in chat is free. Compaction in Claude Code, per the cost documentation, is a real request that you pay for.
Frequently asked questions
How big is Claude Code’s context window?
1M tokens for Sonnet 5, Fable 5, Opus 5, Opus 4.8, Opus 4.7 and Opus 4.6 on a Pro, Max, Team or Enterprise plan — with the caveat that Pro users “need to enable usage credits to access the 1M token context window for Opus models,” and Sonnet 4.6’s 1M window requires credits on every paid plan except usage-based Enterprise.
Does the 1M context window cost extra?
Not as a token premium. “The 1M context window uses standard model pricing with no premium for tokens beyond 200K.” What varies is the gate in front of it: included on Max, Team and Enterprise for Opus; credit-funded on Pro.
Why did my window fill up when I barely said anything?
Because your messages are the smallest part of it. Every request carries the system prompt, CLAUDE.md and memory, every prior message, and every tool result. Anthropic’s guidance for admins puts the coding case plainly: “each Claude Code turn carries file contents, tool calls, and multi-step reasoning, so one debugging session can consume more than a day of chat.”
Is /compact or /clear better?
/clear when you do not need the history — it “costs nothing.” /compact when you need continuity, and preferably at a natural break while the cache is warm, since compaction after a long break “reprocesses the full history as uncached input.”
Does a bigger context window make Claude smarter?
Anthropic says no, in its own words: “more context isn’t automatically better. As token count grows, accuracy and recall degrade.”
What Anthropic does not publish
Four gaps, each of which someone will confidently fill in for you elsewhere:
- The token cost of Claude Code’s system prompt, tool definitions and project context in a real session. Not published as a figure.
- How much of the window is reserved for the response. Stated to exist, size Not published.
- Any default auto-compact threshold other than Sonnet 5’s “about 967K tokens” — every other model is described only as “the model’s context limit.”
- Why the same model gets 500K in chat and 1M in Claude Code. Both figures are published; the reason is Not published.
Sources
Every quotation above was read directly from these pages. Last verified 18 August 2026.
- How large is the context window on paid Claude plans? — Claude Help Center
- How do usage and length limits work? — Claude Help Center, updated 13 July 2026
- Context windows — Claude Platform Docs
- Model configuration — Claude Code docs (extended context, auto-compact window)
- How Claude Code uses prompt caching — Claude Code docs
- Manage costs effectively — Claude Code docs
Anthropic revises these pages without notice and several carry no visible last-updated date. Treat everything here as a snapshot of 18 August 2026, and check /context and Settings > Usage for anything that concerns your own account.
Codex meters the same problem differently: see Codex usage limits by tier.
Update, 3 September 2026: what a large context window costs, and why that answer differs by vendor
This page is about how much context you get and how quickly you fill it. A question we keep being asked underneath that one is what the context costs — and after re-reading both vendors’ pricing pages on 3 September 2026, the answer turns out to be structurally different on each side, in a way that no comparison table we have seen shows.
Anthropic prices the window flat. Its pricing documentation states that Claude 4.6 and later models “include the full 1M token context window at standard pricing”, and spells out the consequence: a 900k-token request is billed at the same per-token rate as a 9k-token request. Prompt caching and batch discounts are stated to apply at standard rates across the whole window. So on Claude Sonnet 5 the numbers on this page do not change as the window fills: $2.00 per million input tokens, $0.20 per million on a cache hit, $10.00 per million output, at 9k tokens and at 900k alike.
OpenAI prices it in two tiers. Its API pricing table publishes a separate long-context column for the GPT-5.6 family. For gpt-5.6-terra the short-context rate is $2.00 input, $0.20 cached input and $12.00 output; the long-context rate for the same model is $4.00, $0.40 and $18.00. For gpt-5.6-sol it is $4.00 / $0.40 / $20.00 short and $8.00 / $0.80 / $30.00 long. Our arithmetic: input and cached input exactly double at the boundary, and output rises by half.
Where the boundary sits is the obvious next question, and here we have to stop. OpenAI’s pricing page annotates its GPT-5.5 and GPT-5.4 rows with “(<272K context length)”, but does not state the threshold for the 5.6 family on that page. We are not going to supply a number the vendor has not published. What we can say without guessing is that on one vendor a growing context changes only how many tokens you are billed for, and on the other it can also change the price of each one.
Two footnotes that matter more than they look. First, gpt-5.3-codex has no long-context row at all — it is listed once at $1.75 input, $0.175 cached input and $14.00 output. If you work through the Codex CLI on its default model, the tier split is not your problem. Second, this is exactly the kind of line that goes missing when a comparison quotes one price per model, which is why we now record the cache-hit and long-context rows separately in our AI coding assistant pricing tables, and why our Codex vs Claude Code comparison carries the same warning.
Finally, the caveat that applies to every cross-vendor per-token figure on this site: Anthropic’s documentation states that Claude 4.7 and later models use a newer tokenizer producing “approximately 30% more tokens for the same text”. Claude Sonnet 5 is in that group. That affects how much of a window a given codebase consumes as well as what it costs, so a window measured in tokens is not directly comparable across vendors either. We have not found a published cross-vendor tokenisation benchmark we would stand behind, so we give no conversion factor. A broader model-by-model view is in AI coding models compared.
Sources, both read 3 September 2026: OpenAI API pricing and Anthropic pricing documentation. All figures are official list prices; ratios derived from them are marked as our arithmetic.
Update, 12 September 2026: three vendors, three completely different ways of charging for a long context
Everything above concerns how a context window gets consumed. This update is about what happens to the bill once it is full, because the three vendors we track have landed on three incompatible answers — and two of them contain a cliff that a per-token price table will never show you. All figures below are read verbatim from each vendor’s own pricing documentation on 12 September 2026.
xAI: crossing the threshold re-prices the entire request
xAI’s pricing page states the rule plainly: models with long context pricing “bill the long context rates for all tokens in a request once its prompt reaches the model’s long context threshold.” Read that carefully. It is not a surcharge on the tokens past the line. It is a re-pricing of the whole request, retroactively, including the tokens that were already under the threshold.
For grok-4.6, with a 500k window and a 200k threshold, the two tiers are $2.00 input / $0.50 cache hit / $6.00 output below the line, and $4.00 / $1.00 / $12.00 at or above it. Every line exactly doubles (our arithmetic). Combined with the all-tokens rule, that produces the sharpest cliff in the group: a prompt of 200,000 tokens costs twice what a prompt of 199,999 tokens costs — a one-token increase in input for a 100% increase in price (our arithmetic). If your agent’s context grows during a session, the bill does not ramp. It steps.
MiniMax: a second cliff, in a different place
MiniMax M3 splits its rate card at 512k of input, and crossing it doubles every line: $0.30 to $0.60 input, $0.06 to $0.12 cache read, $1.20 to $2.40 output. Same doubling as xAI, at a different threshold, and structured as tiers on the pricing page rather than as the whole-request rule xAI documents.
Anthropic: no cliff at all, and the documentation says so explicitly
Anthropic’s pricing documentation states that from Claude 4.6 onward the 1M-token context is billed at standard rates, and it spells out the consequence directly: “A 900k-token request is billed at the same per-token rate as a 9k-token request.” There is no threshold, no tier boundary, and nothing to step over. Claude Sonnet 5 charges $2.00 / $0.20 / $10.00 at nine thousand tokens and the same $2.00 / $0.20 / $10.00 at nine hundred thousand.
The comparison flips as the context grows
This is the part worth sitting with, because the answer to “is grok cheaper than Claude?” changes sign depending on how full your context is (all ratios our arithmetic, from the list prices above).
Under 200k, grok-4.6 and Sonnet 5 charge identical input — $2.00 each — and grok’s output is 40% cheaper ($6.00 against $10.00). grok looks like the better deal.
At or above 200k, grok’s input becomes double Anthropic’s ($4.00 against an unchanged $2.00) and its output crosses over to 20% more expensive ($12.00 against $10.00). The cheaper model became the dearer one without either vendor changing a price — the request simply got longer.
And on the line an agent loop actually hammers, grok never leads at all: a cache hit costs $0.50 against Anthropic’s $0.20, or 150% more, at every context length. This is the same pattern we documented in our breakdown of what the GLM Coding Plan really costs against Claude Code: the advertised discount sits on the rows a coding agent touches least, and evaporates on the row it touches most.
grok-4.6 is now the furthest any model sits from the 10% cache convention
We have been tracking a pricing convention across vendors: a cache hit priced at 10% of fresh input. Anthropic documents it as a flat 0.1x rule, all nine of OpenAI’s text models compute to exactly 10.0%, and Moonshot’s Kimi K3 joined the line at exactly 10.0%. GLM-5.3 sits at 18.6% and MiniMax M3 at 20.0%.
grok-4.6 computes to 25.0% — $0.50 ÷ $2.00, and identically 25.0% in the long-context tier at $1.00 ÷ $4.00 (our arithmetic). That is 2.5x the convention, the widest deviation we have measured from any vendor. For prompt-caching-heavy work, this single ratio matters more than the headline input price that most comparison tables lead with.
One curiosity in the other direction: grok-4.6’s output-to-input ratio is 3.0 in both tiers (our arithmetic), making it the flattest bill shape in the group — flatter than GLM-5.3’s 3.14, MiniMax’s 4.0, and the 5.0 shared by Anthropic’s range and much of OpenAI’s. Flat is friendlier to output-heavy generation, which is a genuinely different workload from the cache-heavy agent loops this page is mostly about.
What this means in practice
If your workload lives comfortably under 200k tokens and is generation-heavy rather than cache-heavy, grok-4.6’s $6.00 output is real money saved. If your context grows past a threshold mid-session — which, as the earlier sections of this page describe, is exactly what long agent runs do — then a vendor with a cliff turns a gradual cost curve into a step function you cannot budget against, while a flat-rate vendor stays predictable. Our full pricing comparison across coding assistants and our Codex versus Claude Code comparison both work through what that predictability is worth on a monthly bill.
The usual caveat, which applies to every number above: these are list prices per token, and a token is not a common unit across vendors. Anthropic states that its tokenizer from Claude 4.7 onward produces “approximately 30% more tokens for the same text,” so a per-token quote from Anthropic and one from xAI are not measuring the same amount of work. We have deliberately not compounded that 30% into any multiplier here. The cache-ratio figures are the exception and the sturdiest numbers on this page, because each is computed inside a single vendor’s own table and so is immune to the tokenizer problem entirely.
Not published by xAI as of this update, and therefore not stated here: whether grok-4.6 is eligible for batch discounting (the pricing page lists batch discounts for grok-4.3 and the grok-4.20 SKUs only), and any release date for grok-4.6. Separately, xAI has documented that from 21 September 2026 at 12:00 PM PT its X Search tool moves from $5 per 1,000 calls to $5 per 1,000 posts fetched plus $10 per 1,000 user profiles fetched, with every post in a fetched thread — including parent and quoted posts — counting toward the total. Anyone costing out an agent that searches X should re-run those numbers after that date.
Update, 15 September 2026: a million tokens of context, and only two vendors decline to charge extra for using it
Advertised context length and usable context length are different products, and the thing that separates them is almost never on the spec sheet. It is on the pricing page, in the footnote about what happens when a request gets long.
Two statements, both read verbatim on 15 September 2026. Anthropic’s pricing documentation: the full 1M token context window is available “at standard pricing”, and “a 900k-token request is billed at the same per-token rate as a 9k-token request.” Alibaba’s model page for qwen3.8-max: context window 1,000,000, maximum output 131,072 — and the price table contains no long-context tier at all, which is the same commitment expressed by omission rather than by sentence.
Set against that, the multipliers recorded elsewhere in this comparison: xAI doubles the rate on the entire request once it crosses 200k tokens, and MiniMax does the same past 512k. The word “entire” is doing the work. It is not a surcharge on the tokens above the threshold; crossing the line reprices everything you sent, including the first byte.
Why the threshold model changes how you write the code, not just what you pay
A flat per-token rate has a pleasant property: the cost of a request is a smooth function of its size, so you can let context grow naturally and watch the bill grow proportionally. A threshold multiplier introduces a cliff. A 199k-token request and a 201k-token request differ by 1% in size and by roughly 101% in price — our arithmetic, on a doubling applied to the whole request.
The practical consequence is that on threshold-priced models you end up building machinery you would not otherwise need: token counters before dispatch, context trimming that fires near the line, retry logic that splits a request rather than letting it cross. That engineering is a real cost, paid in complexity and in the bugs that live in truncation code, and it never appears in a price comparison. On flat-rate models that machinery is optional — you write it when you want to spend less, not to avoid falling off a cliff.
Which is the more useful way to read a context-window spec: not “how much fits” but “what does the last third cost, and is the price continuous”. By that reading the field is much smaller than the marketing suggests. Several vendors will accept a very long request. As of 15 September 2026, on the pricing pages we check daily, two will accept one without repricing it.
Two caveats before anyone builds a plan on this. Anthropic’s own documentation notes that Claude 4.7 and later changed tokenizer and that the same text now yields approximately 30% more tokens — so “1M tokens” buys measurably less text there than the same number does elsewhere, and a window comparison in tokens is not a window comparison in content. And qwen3.8-max is priced differently by region, with Singapore running 21.2% above the other endpoints by our arithmetic; the per-region figures and the cache rows are in our current pricing breakdown, alongside what the Codex plans meter and what they no longer publish.
Update, 18 September 2026: Gemini 3.1 Pro has a 200k pricing cliff, and it is the only one of the four that is not a clean multiple
We have been tracking which vendors charge more once a prompt crosses a length threshold. Google’s Gemini API pricing page, read on 18 September 2026, adds a fourth to that list — and it is the only one that does not simply double everything. The table header for Gemini 3.1 Pro Preview reads, verbatim:
$2.00, prompts <= 200k tokens $4.00, prompts > 200k tokens
| Row (per 1M tokens) | Prompt at or under 200k | Prompt over 200k | Multiplier |
|---|---|---|---|
| Input | $2.00 | $4.00 | 2x |
| Output | $12.00 | $18.00 | 1.5x |
| Cache read | $0.20 | $0.40 | 2x |
Against Sonnet 5, this model is either identical or nearly twice the price, with nothing in between
Claude Sonnet 5 lists at $2.00 input, $10.00 output, $0.20 cache read, and Anthropic’s page states long context is billed at 1M at standard pricing — there is no threshold at all. So the comparison flips entirely on one boundary (all figures below our arithmetic):
- Prompt at or under 200k: input is the same $2.00, cache read is the same $0.20, output is $12.00 against $10.00 — 20% more. Close enough that price is not the deciding factor.
- Prompt over 200k: input costs 100% more, cache read costs 100% more, output costs 80% more. Nothing about the model changed. The prompt got longer.
Read literally, the page classifies the whole prompt, not the excess. A prompt of 200,001 tokens is priced at $4.00 per million across all 200,001 of them, not at $2.00 for the first 200,000 and $4.00 for the last one. Google does not state a marginal alternative anywhere on the page, so we read it as written. Our arithmetic on what that means: the 200,000-token prompt costs $0.40 in input, and the 200,001-token prompt costs $0.80. One token adds forty cents. If you are anywhere near that boundary, the single highest-leverage thing you can do to your bill is trim the prompt — not change model, not change vendor.
The 1.5x looks like a concession. For a coding agent it is worth about three percentage points.
This is the part nobody works out, and it is the reason we think the 1.5x row is misleading rather than generous. Input and cache double, output rises by half. So the multiplier you actually pay is a blend, and the blend depends entirely on how much output your workload produces relative to its input.
Write it out. With input I and output O in millions of tokens, the cost above the cliff is 4I + 18O and the cost the same call would have had below it is 2I + 12O. The effective multiplier is that ratio, and it depends only on r, the ratio of output to input (all of the following is our arithmetic on Google’s published figures):
| Output as a share of input | Effective multiplier | Shape that looks like this |
|---|---|---|
| 0% | 2.00x | Theoretical floor |
| 2% | 1.95x | Agent reading a large repo, emitting a small diff |
| 5% | 1.88x | Code review pass with inline comments |
| 10% | 1.81x | Refactor touching several files |
| 25% | 1.70x | Long summarisation |
| 100% | 1.57x | Output as long as input |
| Unbounded | 1.50x | The number in the table |
You only reach this cliff by having a prompt over 200,000 tokens. That is the trap. To get anywhere near the advertised 1.5x you would need output on the same order as an input that is already enormous — hundreds of thousands of output tokens. Coding agents are the opposite shape by construction: they read a great deal and write very little. The models most likely to cross the 200k boundary are being used in exactly the pattern where the output concession is worth least.
One worked call
Take a single agent turn: 250,000 tokens of input, 5,000 tokens of output. Our arithmetic, on official list prices read 18 September 2026:
- Gemini 3.1 Pro Preview, as billed: $1.00 input + $0.09 output = $1.09
- The same call at the under-200k rates: $0.50 + $0.06 = $0.56 — an effective 1.95x, not 1.5x
- Claude Sonnet 5, same tokens, no threshold: $0.50 + $0.05 = $0.55
Same call, same token counts, 98% more expensive (our arithmetic). At a prompt of 199,000 tokens instead, the two models are within pennies of each other. That is a large financial consequence attached to a property of your context assembly that most teams do not measure and cannot predict from one call to the next.
And note which row the doubling lands on hardest. In a long-running agent loop, cache reads carry most of the volume, and cache read is one of the rows that doubles outright. We have made this point before from the other direction: on GLM’s coding plan against Claude Code, the cache row is where the widely repeated five times cheaper headline quietly reverses. It keeps being the cache row, because the cache row is where the tokens are.
For how the four vendors compare on price across every row rather than just the threshold, see our AI coding assistant pricing breakdown, which we updated the same day with Google’s announced Flash increase for 1 January 2027. For which of these models are realistic substitutes in daily work, see Claude Code alternatives.
Cross-vendor caveat, as always: Anthropic states that Claude 4.7 and later changed tokenizer, producing roughly 30% more tokens for the same text. A 200,000-token threshold is measured in each vendor’s own tokens, which means the amount of source code that trips Google’s cliff is not the same amount that would trip an equivalent threshold elsewhere. Thresholds denominated in tokens are not portable between vendors.
Update, 19 September 2026: xAI puts the same 200k cliff on all seven of its text models, including the ones that advertise a 1M window
Yesterday we added Gemini 3.1 Pro to this page because it was the first cliff we had found whose multiplier was not a clean number. On 19 September 2026 we read xAI’s pricing page (docs.x.ai/developers/pricing, page stamped “Last updated: September 14, 2026”) in full, and it supplies the opposite case — a cliff so uniform that it is the only one on this page you can model with a single constant. It also supplies the most uncomfortable structural fact we have come across in three months of doing this.
The rule, as published
All seven of xAI’s text SKUs carry the same long-context surcharge: it triggers at 200k tokens and doubles the entire document, not the portion above the threshold. Unlike Google’s version, the doubling is applied uniformly to input, cached input and output alike. The seven SKUs and their sub-cliff list prices, per million tokens:
| Model | Window | Input | Cached | Output | Cliff |
|---|---|---|---|---|---|
grok-4.6 | 500k | $2.00 | $0.50 | $6.00 | 2x at 200k |
grok-4.5 | 500k | $2.00 | $0.30 | $6.00 | 2x at 200k |
grok-build-0.1 | 256k | $1.00 | $0.20 | $2.00 | 2x at 200k |
grok-4.3 and the three grok-4.20 variants | 1M | $1.25 | $0.20 | $2.50 | 2x at 200k |
Buying a bigger window does not buy cheaper long context
Look at the last row again. grok-4.3 advertises a 1M-token context window. Its surcharge starts at 200k. Which means 800,000 of the 1,000,000 tokens in the advertised window — four fifths of it — are priced at double the rate in the table (our arithmetic). The window and the price band are set by two different numbers, and only one of them appears in the marketing.
This kills the obvious workaround. The natural reaction to a cliff is to move the long-context work onto a cheaper or longer-window SKU from the same vendor. At xAI that does not help, because every SKU has the cliff and every SKU has it in the same place. The threshold is not a property of the model you chose. It is a property of the price list.
The one cliff on this page that is a single number
Yesterday’s finding on Gemini 3.1 Pro was that its headline 1.5x output concession is worth almost nothing to a coding agent, because Google doubles input and caching but only multiplies output by 1.5, and an agent that reads a large repository and emits a small diff barely touches the output line. Its effective multiplier therefore slides between 1.50x and 2.00x depending on your output-to-input ratio, and lands at about 1.95x for agent-shaped work.
xAI’s is not like that. Because all token types double together, the effective multiplier is exactly 2.00x for every possible workload mix. There is no ratio to compute, no shape of work that does better or worse. Run the same 250k-input / 5k-output agent call we used yesterday through all four:
| Model | One 250k / 5k call | Same tokens at sub-cliff rates | Effective multiplier |
|---|---|---|---|
| Claude Sonnet 5 | $0.55 | $0.55 | 1.00x — no cliff exists |
grok-4.3 | $0.65 | $0.325 | 2.00x exactly |
| Gemini 3.1 Pro Preview | $1.09 | $0.56 | 1.95x (not the 1.50x on the page) |
grok-4.6 | $1.06 | $0.53 | 2.00x exactly |
Two things fall out of that table that are worth more than the ranking itself.
First: the cheapest list price in the table produces the second-most-expensive call. grok-4.3‘s input lists at $1.25 against Sonnet 5’s $2.00 — 37.5% below it. At a 250k prompt it costs 18% more than Sonnet 5 for identical token counts (our arithmetic). Nothing dishonest happened; the surcharge is published, on the same page, a few paragraphs under the price. But a spreadsheet built by copying the price table and nothing else will get this backwards, and most spreadsheets are built that way.
Second: the absence of a cliff is itself a pricing feature, and it is invisible in every comparison table on the internet, because a feature nobody charges for has no row. Anthropic’s flat treatment of long context does not appear as a line item anywhere; it shows up only as the first column of that table not moving. Across the four models above, the entire spread at 250k tokens — $0.55 to $1.09, very nearly 2x — comes from surcharge rules rather than from list prices (our arithmetic). The list prices themselves span a far narrower range.
The portability warning we added yesterday applies here too and gets worse with a fourth vendor in the mix: each vendor’s 200k threshold is counted in that vendor’s own tokens, and Anthropic states that Claude 4.7 and later use a tokenizer producing approximately 30% more tokens for the same text. So the amount of source code that trips xAI’s cliff and the amount that trips Google’s are not the same amount of source code, even though both pages print “200k”. A threshold denominated in tokens is not portable between vendors, and neither is the cliff that hangs off it.
The other three billing clauses on the same xAI page — the batch discount that excludes the flagship, the 2x priority tier, and a per-request fee that is not a function of tokens at all — are covered in our cross-vendor pricing breakdown. The regional-endpoint premium, which stacks on top of everything above, is in Codex vs Claude Code. If you are weighing a cheaper vendor specifically to cut long-context cost, the GLM Coding Plan comparison is the other half of that decision.