Best Model for Long Context Tasks: Match the Task Shape

People ask which model is best at long context as though it were one capability. It is not. There are three distinct task shapes hiding under that phrase, and they stress completely different properties of a model.

Getting the shape right first is what makes the model choice easy. Getting it wrong is why teams buy a million-token window and find it does not help.

Shape one: find the needle

You have a large document set and one specific fact in it. A clause in a contract, a config value in a stack of YAML, one log line among fifty thousand.

The relevant property is retrieval accuracy at depth — whether the model reliably uses a fact regardless of where it sits in the prompt. This is the shape that needle-in-a-haystack evaluations measure, and modern models are broadly good at it for a single needle.

They degrade on multiple needles that must be combined, and they degrade with distractors: near-miss content that resembles the target. Both are common in real corpora and rare in the published evaluations, so test on your own material.

Honestly, though, this shape usually should not be a long context problem at all. If the answer lives in one paragraph, retrieving that paragraph and passing 4K tokens is faster, cheaper and more accurate than passing 900K. RAG versus long context covers where the crossover sits.

Shape two: synthesise across the whole thing

This is the shape that genuinely requires a long window. Summarise this entire codebase's architecture. Find every place this invariant is violated. Compare these forty documents for inconsistencies.

There is no subset to retrieve, because the answer depends on relationships spread across the whole input. Chunking actively destroys the thing you are asking about.

The property that matters here is uniform attention across the input, and this is where the gap between advertised and effective context bites hardest. Attention concentrates at the beginning and end of a prompt and thins in the middle, so a model may faithfully synthesise the first and last fifth of a long document while treating the middle superficially. The output looks complete, which is the dangerous part. The lost in the middle problem covers the mechanism.

Test this directly rather than trusting the specification. Plant three findings in a long document — one near the start, one at the midpoint, one near the end — and see how many come back. The results will surprise you and they vary considerably by model.

Shape three: the long agentic session

The most common shape in practice, and the one people least often recognise as a context problem. Nothing you pass is individually long. But forty turns of tool calls, file reads and command output accumulate, and by turn thirty you are at 400K tokens without ever having pasted a large document.

Here the binding property is not retrieval or attention — it is whether the model still follows its original instructions after the transcript has grown. Instruction adherence decays as context fills, and a model that obeyed a constraint on turn four routinely forgets it by turn twenty-eight.

Long-horizon benchmarks measure roughly the right thing. Kimi K3 reports 88.3 on Terminal-Bench 2.1 and 81.2 on FrontierSWE; GLM-5.2 reports 81.0 on Terminal-Bench 2.1. These are extended unattended runs, so they capture the compounding failure that single-turn scores miss.

The best fix is architectural rather than model choice: compact the transcript as it grows, summarise completed sub-tasks, and drop raw tool output once it has been used. Context compaction strategies covers the mechanics.

What the specifications actually give you

Capacity is close to commoditised at the top. Kimi K3, GLM-5.2, both DeepSeek V4 variants and MiniMax M3 all ship one-million-token windows. Kimi K2.6 is the notable exception at 256K, which is still ample for most work but rules it out of whole-codebase synthesis.

Because capacity no longer differentiates, the specification sheet has stopped being a useful filter. Every serious candidate clears the bar, so the decision moves entirely to how well the window is used and what filling it costs.

Max output length is the specification worth checking that people overlook. GLM-5.2 supports 128K max output, which matters if you are asking for a long generated artefact rather than a long analysis. Reading a million tokens and writing four hundred is a very different job to reading a hundred thousand and writing eighty thousand.

Cache economics decide the bill

The cost of long context is not the window. It is that you pay for the whole prompt on every turn.

An agent holding 300K tokens of context across thirty turns pays for 9M input tokens, which on Kimi K3 at $3 per million is $27 for a single session. Nobody budgets for that, and then the invoice arrives.

Caching changes the picture entirely, provided your prompt has a stable prefix. K3 prices cached input at $0.30 per million against $3 uncached — an order of magnitude. Structure your prompts so the unchanging material comes first and the varying material last, and the same session costs a fraction.

Below the frontier, DeepSeek V4 Flash at roughly $0.14 in per million makes long-context reading almost free before any caching. For survey and triage work over large inputs that is often the correct answer regardless of what the leaderboards say. Context window cost tradeoffs works the arithmetic through.

Choosing

For whole-corpus synthesis where attention quality decides the answer, Kimi K3. For long agentic sessions on a budget, GLM-5.2 — strong long-horizon numbers, MIT licensed, effort levels to control spend. For high-volume reading and triage over large inputs, DeepSeek V4 Flash, where the price makes the volume irrelevant.

For finding a specific fact in a large corpus, use retrieval and a small prompt, not a large window. That is the one shape where the long-context answer is usually the wrong one.

Before committing, run the planted-findings test on your own material at the depth you actually intend to use. A window you can fill is not the same as a window the model reads, and only your own data will tell you which you have. The 1M context model comparison covers how the current field stacks up on paper.