Context Windows Compared: Input, Output and What It Costs

Context window comparisons usually stop at the headline number, which by August 2026 makes them almost useless: five of the major open-weight models advertise exactly one million tokens. Comparing them on that figure produces a five-way tie.

The differences that survive are the ones nobody puts in the table. What it costs to fill the window. What the model will let you generate out of it. And whether the window survives a second request unchanged.

The input side, and the one exception

Kimi K3, GLM-5.2, DeepSeek V4 Pro, DeepSeek V4 Flash and MiniMax M3 all ship 1M input context. Kimi K2.6 is the exception at 256K, which is a large window by any historical standard and a four-fold step down from its own family sibling.

That intra-family gap is the one that causes production incidents. A pipeline designed against K3's million tokens does not degrade gracefully when routed to K2.6 for cost reasons — it errors on anything past 256K. Any router that moves traffic between them needs an explicit length check at the boundary.

The broader point is that context limits do not track model families, generations or price tiers in any reliable way. Check the specific model, and check it again when you change versions. How context windows work covers the mechanics underneath the number.

What filling the window costs

This is the comparison that actually differentiates the field, and it is simple arithmetic on published input rates.

• DeepSeek V4 Flash — around $0.14 per million input tokens, so a full window costs about fourteen cents.
• DeepSeek V4 Pro — around $0.44, so roughly forty-four cents for a full million.
• GLM-5.2 — around $1.40 per million.
• Kimi K3 — $3.00 per million uncached, or $0.30 at the cached input rate.
• Kimi K2.6 — around $0.95 per million, and its 256K ceiling means a full window is roughly twenty-four cents.

MiniMax M3 is deliberately absent from that list: published pricing disagrees between sources by roughly a factor of two, so check the vendor page rather than trusting any table including this one.

A twenty-fold spread between the cheapest and most expensive way to read the same input is the real story. It means "use the big window" is a cheap default on one model and a line item requiring justification on another.

The output ceiling nobody checks

Input context is quoted everywhere. Maximum output is quoted almost nowhere, and it is a separate, usually much smaller limit.

Most models will accept an enormous input and then cap generation far below it. You find the ceiling by hitting it: a truncated file, a test suite that stops halfway through, a migration missing its last three steps, and no error explaining what happened.

GLM-5.2's 128K maximum output is unusual in the current field and is the reason to choose it for generative work specifically — whole files, complete test suites, full migrations, entire translated documents. If your workload produces large artefacts rather than analysing them, check the output limit before the input one. The GLM family explained covers where that ceiling pays off.

Caching changes the arithmetic more than the window does

The cached input rate is the most consequential number in long-context work and the one least often compared.

Kimi K3 charges $3.00 per million input tokens uncached and $0.30 cached — a tenth. If your workload resends a large, stable prefix, that turns the most expensive window in the field into one of the cheaper ones. If it does not, you pay the full rate every time.

The workloads that benefit are specific and common: an agent loop resending its system prompt and accumulated history each turn, a document assistant answering many questions against one large corpus, a code assistant holding the same repository slice across a session. The workloads that do not are one-shot requests over inputs that never repeat.

Before comparing headline input rates, work out what fraction of your input is a repeated prefix. That fraction, applied against the cached rate, is your real cost. The arithmetic of prompt caching works through it properly.

Advertised is not usable

The advertised figure is the largest input the model accepts without an error. It says nothing about whether the model reliably attends to a detail at the 600,000-token mark.

Degradation across long inputs is universal and uneven. Attention tends to be strongest at the beginning and end of a prompt and weakest in the middle — a pattern established well enough to have a name. A fact at 5 percent depth is retrieved far more reliably than the same fact at 50 percent. The lost-in-the-middle problem covers why.

So five models advertising 1M does not mean five equivalent capabilities. It means five models that accept the same input size and then behave differently across it. Comparing the 1M models on usable window covers a retrieval probe you can run in an afternoon on your own data.

How to actually choose

Work backwards from the shape of your workload rather than forwards from the specification.

Reading enormous inputs on a budget points at DeepSeek V4 Flash, where a full window costs about fourteen cents and long-context reading stops needing justification. Generating enormous outputs points at GLM-5.2 and its 128K ceiling. Interleaved images and text at length points at MiniMax M3, with pricing verified at the vendor. Agent loops with a stable prefix point at whichever model has the best cached rate for your prefix ratio.

And whatever you pick, confirm both limits and measure retrieval at depth before designing a pipeline that assumes the advertised number holds. The cost trade-offs of long context covers when a smaller window is simply the better engineering decision.