How Much Every AI Model Can Read and Write at Once

Model limits answer two different questions: how much the model can read in one request, and how much it can write back in one response. The original census puts both numbers together for 54 models from 13 vendors, using direct API documentation checked on August 30, 2026.

The practical finding is that a large context window does not guarantee a long answer. In the August 30 baseline, OpenAI's reasoning models publish a 128,000-token output ceiling, Google's text models 65,536, and many consumer or reseller surfaces publish no output limit at all. Here, a surface means the particular API, app, or marketplace where you use a model; a SKU is the specific model entry sold there.

Start with the half that is missing from the genre. Our own archive has four narrative posts about the context-window race and none about output ceilings, which is a fair reflection of the market. The expectation going in was that max output would be scattered and hard to find. It is not. It is three different things at once, and the three are worth separating because they have three different causes.

First: on API surfaces it is uniform and boring. OpenAI publishes 128,000 max output tokens on every current reasoning SKU — Sol, Terra, Luna, Cyber, 5.5, 5.5 Pro, 5.4, 5.4 Pro, 5.4 mini, 5.4 nano and the surviving Codex variant. Not one of them deviates. Google publishes 65,536 on all seven current Gemini text models, across Flash, Flash-Lite and Pro, and across GA and Preview alike. Anthropic publishes 128K on Fable 5, Opus 5 and Sonnet 5, and 64K on Haiku 4.5 — one exception in an otherwise flat line. Three frontier labs, three flat numbers.

Second: wherever anyone else publishes it, it varies enormously. Moonshot documents Kimi K3 at a default of 131,072 tokens and a ceiling of 1,048,576 — the entire context window, the most permissive figure anywhere in this census. MiniMax documents M3 at a recommended 131,072 and a maximum of 524,288. DeepSeek’s whole V4 line is 384K. Z.ai’s GLM-5.3 is 128K. Tencent’s Hy4 preview caps output at 64K on a 1M context, which is a 16:1 read-to-write asymmetry and the widest of the six Chinese labs.

Third: it is systematically absent from whole vendors and whole surfaces. xAI publishes no max output figure on its model list, on any per-model page, or in its API reference. Meta’s Muse models page has a context-window column and no output column. AWS Bedrock model cards publish a Max output tokens line for Anthropic and Amazon models and omit it for xAI models on the same docs template — so the gap tracks the model vendor rather than the reseller. And neither ChatGPT’s pricing page nor Google’s Gemini app help article states an output limit for any plan.

So the honest headline is not that nobody publishes this. It is that max output is well published on API surfaces, wildly inconsistent between the vendors that publish it, and systematically absent from the surface most people actually use. Those three statements have three different remedies, and only the second one is a standardisation problem.

One boundary before the data. This page is the numbers. What actually happens when a generation runs into one of these ceilings — the truncated JSON, the tool call that never closes, the response that ends mid-sentence with a length finish reason and no error — is the subject of our companion piece on silent output truncation in agent pipelines, not of this one. The failure modes live there. The limits live here.

The hard part of a limits census is not the cells you can fill. It is deciding what to do with the ones you cannot, because deleting them turns a vendor’s silence into our omission. Every unfilled cell in this table is kept in, and carries one of three labels that say which kind of failure it is.

This is the single most important mechanic on the page, and it is invisible in every side-by-side comparison we have seen. OpenAI and Google both advertise a million-token context window. They are not measuring the same thing.

OpenAI’s model pages publish three numbers for GPT-5.6 Sol: a context window of 1,050,000, a maximum input of 922,000, and a maximum output of 128,000. Those add up exactly. The headline context figure is the sum of the read budget and the write budget, which means the usable input is 922,000 tokens and never the advertised million. Google’s model pages publish an input token limit of 1,048,576 and an output token limit of 65,536, and the second is on top of the first.

Set those side by side and the comparison inverts depending on which column you read. On the read side Google’s window is 126,576 tokens larger than OpenAI’s usable input. On the total-tokens side OpenAI’s envelope is 1,050,000 against Google’s 1,114,112. Neither vendor is being misleading on its own page; the misleading step is the comparison table that puts “1,050,000” next to “1,048,576” and calls them a tie. A census table without an explicit does-this-include-output column misleads about precisely the thing it exists to clarify, which is why the one below has one.

Two structural details follow from the same source pages. OpenAI runs two shapes and only two: 1,050,000 / 922,000 / 128,000 for the flagship and Pro tiers, and 400,000 / 272,000 / 128,000 for mini, nano, Codex and Cyber. The max input on the smaller shape is 272,000 — which is exactly the threshold at which OpenAI’s long-context pricing kicks in. The cheap and specialised SKUs stop at the precise point where the expensive ones start charging double. That is not a coincidence worth over-reading, but it is a genuine design fact: you cannot accidentally trigger long-context billing on a mini model, because the model will not accept a long-context prompt. What that threshold costs on the models that do accept it is the subject of our analysis of long-context pricing cliffs; here it matters only as the shape of a limit.

Google, meanwhile, is perfectly uniform. All seven current text models carry 1,048,576 in and 65,536 out — Flash, Flash-Lite and Pro, GA and Preview, the cheapest model and the dearest. Google differentiates its tiers entirely by price and does not differentiate them by limit at all.

Put those together and the usual framing is backwards. The number the market treats as the headline spec, the context window, is the one that varies — 1,050,000 or 400,000 at OpenAI, 1M or 200K at Anthropic, 500,000 or 1,000,000 at xAI, 256k across Mistral’s own line. The number the market ignores, the output ceiling, is the one that holds still. If you are writing a routing layer that has to degrade gracefully, the write ceiling is the constant you can code against and the read window is the variable you have to look up.

September 9 supplement: 12 OpenRouter routes

These exact route records were observed September 9, 2026 in the all-modality OpenRouter snapshot. They add September-listed models and their batch or contributor surfaces to this maintained reference. The original 54 direct-provider rows below remain dated August 30; their values are not silently replaced with aggregator limits.

A catalog maximum is not a guarantee that the selected endpoint accepts every request at that limit. The snapshot does not establish a separate maximum-input allowance for these routes, so none is invented here. Context and maximum output must not be added together to claim a larger supported window. Batch and contributor suffixes are separate surfaces, not new base model families.

Rows are grouped by vendor, and each group header names the first-party page the group’s figures came from. The column that does the most work is Context includes output? — without it, the ratio column and the context column cannot be compared across vendors. Cells reading UNVERIFIED (a), UNVERIFIED (b) or UNVERIFIED (c) are kept in deliberately; see the methodology above for what each one means.

Two reference points sit outside the table because they are Azure’s figures for a model router rather than a model. Microsoft documents the router’s max output values as 32,768 for the GPT-4.1 series, 100,000 for o4-mini, 128,000 for the GPT-5 reasoning models and 16,384 for gpt-5-chat. That last figure is the lowest current max output we found at either OpenAI or Google, and it belongs to the chat-optimised variant — the one closest to what a consumer product would route to.

For the money side of the same 54 models, our frontier model API price index is the companion asset, published the same day and maintained on the same cadence. It carries the promotional rates and their end dates in their own column; this page carries no prices at all.

The most useful sentence anyone has written about these numbers was not written by a model lab. It is in Microsoft’s Azure AI Foundry documentation, describing the max output column of its own model table, and it is the thing readers most often get wrong.

Read the census again with that in mind and several rows stop looking like contradictions. Qwen publishes a 1M context, a 991K max input and a 131K max output for qwen3.8-max. Those three do not sum — 991K of input leaves nowhere near 131K of room inside a one-million-token window. They are not meant to sum. Each is an independent ceiling that binds only when the other two are well below their own. Fill the input to 991K and the output you actually get will be a fraction of 131K, with no error and no warning that the documented ceiling was never available.

OpenAI’s numbers behave differently, and the difference is visible precisely because the census records the relation. 922,000 plus 128,000 is 1,050,000 exactly, so OpenAI’s two figures do partition the window: the output budget is genuinely reserved against the context total. Google’s do not interact at all, because the output limit sits outside the input limit. Three vendors, three different relationships between the same two numbers, and only one of them documented in a way a reader would notice.

The practical consequence is that a max output figure tells you what the model will never exceed and nothing about what it will produce on any given call. That gap between the documented ceiling and the achievable one is where output truncation comes from, and it is the subject of our companion post on why long agent outputs fail silently. The numbers on this page are the input to that analysis, not a substitute for it.

The strongest single fact in this census does not require leaving one vendor. Anthropic publishes a support article on how large Claude’s context window is, and the answer is different in each of its own products. Claude Opus 4.6 gets a 1M token context in Claude Code, 500K in Claude chat, and 200K in Claude Cowork — same model, same paid plan, three ceilings, all documented by Anthropic on one page.

Three things in that table are invisible to a check-the-vendor’s-page approach. Opus 4.6 spans five-fold across three of one vendor’s own products. A context window can be a paywall inside a paid plan: Pro subscribers must switch on usage credits — that is, opt into metered API-rate billing — to reach 1M on Opus in Claude Code, so the plan price does not buy the ceiling. And “1M” can mean “compacts at 500K”, which Anthropic documents for Sonnet 5 in Cowork. The published ceiling and the behavioural ceiling are different objects, and the vendor says so.

Newer is not larger. xAI’s own model pages put Grok 4.6 at a 500,000-token context window and Grok 4.3 at 1,000,000. The newer flagship, released August 12, 2026, halved the window of the model it succeeded — and also lost Batch API support and the eu-west-1 region that Grok 4.3 carries. A reader who assumes the later version number implies the larger window is simply wrong, and no amount of reading the launch post would tell them.

The consumer split is real and it is asymmetric. OpenAI’s API window is 1,050,000 tokens; ChatGPT Pro gets 400K in reasoning mode and 128K in instant mode, Plus and Go get 256K and 54K, and Free instant gets 27K. That last figure is about 2.6% of the API window — a factor of roughly 39. Google runs the other way entirely: the Gemini app on AI Pro or AI Ultra is documented at 1 million tokens, essentially parity with the developer API, with AI Plus at 128k and no plan at 32k. Google’s paying consumer gets the developer window. OpenAI’s does not.

One detail makes the ChatGPT rows harder to use than they look. OpenAI’s consumer page labels its two modes “GPT Instant” and “GPT Reasoning”, not model IDs, and publishes no mapping from those labels to gpt-5.6-sol or chat-latest. A ChatGPT subscriber therefore cannot look up their own limits in the API documentation, because the two surfaces do not share a vocabulary.

Reseller catalogues lag, and keep selling the dropped. xAI’s direct API is on Grok 4.6. Microsoft Foundry’s newest Grok is Grok 4.2, four model generations behind, and it still meters Grok-3, Grok-3 Mini, Grok-4 and Grok4 Fast. Google Vertex AI still sells Grok 4.1 Fast, which xAI’s own model list no longer carries. AWS Bedrock’s own “model launch date” for Grok 4.3 is June 15, 2026 against xAI’s April 17 release — a listing date, not a release date. So a question as simple as “what is this model’s context window” has no answer until you say where you bought it. The pricing consequences of that same lag are catalogued in our ledger of AI coding plan limit changes.

An absence is only a finding if you say exactly what you checked. The table below narrows each one to the specific pages fetched on August 30, 2026, and names the method. None of these is a claim that a figure exists nowhere in the world; each is a claim that it is not on the pages a developer or a subscriber would actually consult.

One row in that table is worth reading twice, because it makes the point better than any argument could. Mistral publishes a max output field on the third-party model it resells and omits that field entirely from its own model cards. The template is identical. The field renders on the Z.ai GLM 5.2 card at 128k and does not render on Medium 3.5, Small 4 or Large 3. This is not a fetch artifact — it was confirmed on two independent methods. Whatever the reason, the practical result is that a Mistral customer can learn the write ceiling of the model Mistral did not build and not of the three it did.

The AWS case has the same shape at a different layer. Bedrock model cards publish a Max output tokens line for Anthropic and Amazon models — that is where Nova Pro’s 5K and Nova Premier’s 25K in the census come from — and omit it for xAI models rendered from the same docs template. The gap tracks the model vendor, not the reseller. Which means the absence is not a platform policy; it is whatever each model vendor hands over.

Divide the context window by the max output and you get a single number that says how lopsided a model is between reading and writing. Across the whole census it runs from 1:1 to 60:1 — a sixty-fold spread in what the same nominal “large context model” category will actually let you produce.

The bar chart below reads output as a percentage of the model’s own context figure, which is the same ratio inverted and easier to compare visually. One caution attaches to every bar: the Google row is computed against an input limit rather than a total window, so its 6.3% is not the same measurement as Tencent’s 6.3%. That is the include-output column doing its job — a ratio is only comparable across vendors once you know which quantity is in the denominator.

Three readings come out of that spread. First, within the six Chinese labs — all of which advertise a nominal one-million-token window — the write ceiling varies sixteen-fold, from Kimi K3’s 1,048,576 down to Tencent Hy4’s 64K. Same headline read spec, sixteen times the difference in output. Second, the widest asymmetry anywhere in the census is not Chinese at all: Amazon Nova Pro pairs a 300K window with a 5,000-token output ceiling, 60:1. A model that can read a 300-page document and is capped at roughly four pages of reply is a summariser by construction, whatever else it is marketed as.

Third, and least obvious: a low ratio is not automatically better. A 1:1 ratio, as at Kimi K3, means the write ceiling is the whole window, which is generous and also means output consumes the space your prompt needed. Moonshot documents exactly that — the API rejects any request where input plus max_completion_tokens exceeds the window. A ratio tells you the shape of the trade, not which side of it you want. Both of the older context-window guides in our archive — the 1M-to-10M comparison and the arms-race guide — are about the read side only, which is exactly the omission this census exists to close.

Looking forward, the direction of travel is legible in the census itself. The three labs that publish max output most consistently also hold it constant across their entire lineup, which is what you do when a number has become a platform commitment rather than a per-model spec. The labs where it varies sixteen-fold are the ones still treating it as a serving parameter. If that pattern holds, the interesting question over the next few quarters is not whether context windows grow past 1M — they will — but whether the write ceiling converges the way the read window has, or whether it stays the quiet differentiator it is today.

A reference table is only as good as the four or five habits it makes easier. These are the ones this data supports, and the ones it does not.

The limitation to hold onto is that everything above is a record of what vendors publish, not of what endpoints return. We did not probe a single API for this page. That is a deliberate boundary — a published-figures census can be re-verified by anyone against the same URLs, and a measured census cannot — but it means the numbers describe the contract rather than the behaviour. Where the two diverge is precisely where truncation bugs live.

If a limit in this table sits between your team and a workload that has to ship — a document pipeline that keeps stopping short, a migration whose model choice hinges on a write ceiling nobody published, an agent that has to route around a 16,384-token cap it did not expect — that is the kind of problem our AI transformation engagements open with. The census is free and the model selection is the easy part; designing around the ceiling is the work.