Best Long Context LLMs
Context window is the one dimension on this site that can be ranked purely objectively, and this page does exactly that: models ordered by their advertised maximum context, with quality evidence and pricing shown alongside. Two caveats belong next to any such table. Advertised maximums are creator claims, and a given deployment may serve less than the model theoretically supports.
Second, effective context differs from advertised context: retrieval quality degrades toward the middle of very long windows on most models, and long prompts are billed per token, so a million-token window used carelessly is mostly a large bill. The AA-LCR column shows measured long-context reasoning where a published result exists, which is precisely the evidence that separates a big window from a usable one. The right question is usually the smallest context that fits the workload, not the largest available.
The top pick
The strongest measured fit for this task right now, taken from the live ranking below.
The ranking
Ordered from live catalog data; the note beneath the table states exactly how. Missing values are shown as missing, never estimated.
| # | Model | Quality index | Intelligence Index | AA-LCR | Context |
|---|---|---|---|---|---|
| 1 | cohere | No data | No data | No data | 5M |
| 2 | minimax | No data | No data | No data | 4M |
| 3 | openai | 98.6 | 52.7 | 80.7% | 1.1M |
| 4 | openai | 97.6 | 51.8 | 83.0% | 1.1M |
| 5 | openai | 96.2 | 47.6 | 83.7% | 1.1M |
| 6 | openai | 95.7 | 47.0 | 84.0% | 1.1M |
| 7 | openai | 91.9 | 42.1 | 83.0% | 1.1M |
| 8 | openai | 87.6 | 39.0 | 82.0% | 1.1M |
| 9 | openai | 86.6 | 38.4 | 84.3% | 1.1M |
| 10 | openai | 85.6 | 38.1 | 83.3% | 1.1M |
This list is ordered by advertised context window, an objective specification, across the 577 models with a published figure. The ordering makes no quality claim; the quality index is shown for context where measured evidence exists. Advertised maximums are what creators publish, and a given deployment may serve less.
marks models served through the Inferbase API. Missing values are shown as No data rather than estimated.
Also worth evaluating
The next ranks after the top ten, for teams that want a wider shortlist.
Or stop choosing manually
The honest answer changes as benchmarks and prices move. Routing makes the choice per request instead of once.
Send model="auto" to one OpenAI-compatible endpoint and each request is served by the best fit from the same quality and price data behind this ranking, with the decision disclosed per request.
Every routed request records the task it was classified as, the models that qualified, the one that won and why, so a pick made here can be checked against what the router chose in production. A model pinned by name is served as named, with no routing decision.
from openai import OpenAI
client = OpenAI(
base_url="https://api.inferbase.ai/v1",
api_key="YOUR_INFERBASE_KEY",
)
# Let routing pick the best model per request,
# or pin any model id from GET /models.
response = client.chat.completions.create(
model="auto",
messages=[{"role": "user", "content": "..."}],
)Frequently asked questions
How this ranking works and how to act on it.
No. Long-context recall degrades non-uniformly on most models, long prompts multiply per-request cost, and latency grows with input length. A model with a smaller window plus retrieval over your documents frequently beats stuffing everything into a giant window.
Because the figure is the creator’s published maximum, and serving deployments sometimes provision less. Inferbase tracks both the advertised maximum for display and the per-route servable context for actual routing decisions, and this page is explicit about showing the former.
Input tokens times the input price: a 200K-token prompt on a model priced at $3 per million input tokens costs about $0.60 before any output. The price column here makes that arithmetic immediate for each model.
Whole-codebase reasoning, long legal or technical documents where cross-references matter, and multi-document synthesis that retrieval fragments poorly. For needle-in-haystack lookups, retrieval remains cheaper and usually more accurate.
Yes, automatically. Routing measures what each request actually needs (the messages, any images, and the requested output) and drops every candidate whose servable context cannot hold it, so a request is never sent to a model that would truncate it. If nothing in the pool is large enough the request fails loudly with a 413 rather than silently losing your prompt. There is no separate setting to configure: the constraint comes from the request itself.
The maximum number of tokens a model can take in one request, prompt and response together. A larger window lets a model read more at once, a long document, a codebase, a conversation history, without retrieval. It is an advertised maximum: a given deployment may serve less, and the model page shows what the creator published.
The model at the top of this table, ordered by advertised context on the date shown; the leading models advertise a million tokens or more. The ranking is by specification, not quality, so read the quality index and the long-context reasoning column beside it before choosing on the headline number.
The context window bounds the whole request, what the model reads plus what it writes. Max output tokens bounds the response alone, and is usually far smaller than the window. A model with a million-token window may still cap a single answer at a few tens of thousands of tokens; both figures are on every model page.
Related rankings
The same evidence-first method, applied to other tasks.
Put intelligence in the middle.
One gateway in front of every model, with your policies applied and every decision on record. Start on the free plan with 5,000 requests a month, no card required.