A handful of frontier models advertise context ceilings in the hundreds of thousands to low millions of tokens, and the leader changes with each release cycle. That is the short answer. It is also the least useful part of the answer, because the number you just looked up is a stated maximum measured under the vendor’s own conditions — not a commitment that the model attends evenly across that span, retrieves accurately from the middle of it, or holds latency and cost steady when you actually fill it.
That gap matters at exactly the moment you try to act on the figure. Looking up the leader is a five-second task. Deciding which model to put in front of your own 400-page contracts is not, and the spec sheet does not carry the evidence that decision needs.
What is a vendor actually measuring when it publishes a maximum token count?
It is publishing an input ceiling: the largest number of tokens the API will accept in one call without erroring. That is a real, checkable property, and it is worth knowing. What it is not is a performance measurement. A model can accept a million tokens and still degrade sharply in retrieval accuracy over the middle of that window, or slow down enough at full length that the call becomes unusable inside an interactive product.
Two consequences follow, and both are cheap to check before commitment:
- Mid-context recall is not implied by the ceiling. Accuracy on a fact placed in the middle of a long input is a separate property from the maximum accepted length, and it has to be measured on your own document shapes.
- Cost and latency scale with tokens actually sent, not with the advertised maximum. Sizing context to your real working-document distribution rather than the vendor ceiling directly reduces tokens billed per call.
Free tiers and open-weight releases complicate the ranking further. A large advertised window on a free offering usually arrives alongside throughput caps, silent truncation, or shorter retention — limits that live in the terms rather than the headline. Worth reading before treating the number as equivalent to a paid frontier ceiling.
How to read the headline number
| The number says | The number does not say | What to check instead |
|---|---|---|
| Max tokens accepted per call | Whether attention is even across that span | Recall on facts planted at 25%, 50%, 75% depth in your own documents |
| A ceiling exists | Latency at that ceiling | p95 latency at your realistic input length, not at 2K tokens |
| Capacity is available | Cost of using it | Tokens billed per call at your actual document distribution |
| Frontier and open-weight models both quote large windows | That they behave alike at length | Same depth-recall test run on both, same inputs |
| A free tier quotes a large window | Throughput, truncation and retention limits | The rate limits and data-retention terms, not the marketing page |
A useful sizing exercise: take the documents your workload genuinely handles, measure their token counts, and look at the distribution rather than the worst case. Most teams we work with find the 95th percentile sits well below the ceiling they were shopping for — which changes the shortlist.
The deeper mechanics of why long-context behaviour diverges from the stated maximum are covered in our broader treatment of what an LLM context window is and why the advertised size misleads. The measurement discipline behind claims like these — that a stated spec is not a measured result until someone runs it under declared conditions — is the same one we apply to hardware in LynxBenchAI.
The minimum evidence bar
Before a context-window figure influences a shortlist, gather three things on your own inputs: depth-placed recall accuracy at your realistic length, p95 latency at that length, and tokens billed per representative call. That is a short eval, not a research project, and it converts a looked-up number into a decision you can defend.
So the honest answer to “which LLM has the largest context window” is: whichever one shipped most recently, and you should not let that decide anything on its own. The better question is how much context your workload actually needs — and whether the model you are considering still retrieves reliably at that depth.
