A million tokens of context is open-weight now. Keep chunking anyway.

MiniMax shipped M3 on 1 June with a million-token context window and native multimodality, under open weights. Within a week I had two clients ask the same question in nearly the same words: do we still need the retrieval layer, or can we just put the whole corpus in the prompt?

The honest answer is that long context changes where the work happens, not how much of it there is.

What long context genuinely retires

Some of our RAG plumbing was always a workaround for small windows, and it deserves to go:

• Aggressive chunk sizing. Tuning 512 versus 1024 tokens with a 40-token overlap was never modelling anything real about the document. It was budget management.
• Multi-hop stitching for one document. If a 90-page insurance policy fits whole, you stop paying for the retriever to guess which four passages the definition clause lives in.
• Summarise-then-answer chains over a single long file. One pass, no lossy intermediate.

For document-scoped questions - "does this contract permit assignment?" - dropping the whole file in is now the simpler and often better architecture. We do it.

What it does not retire

The corpora I actually work with are not one long document. They are 2.4 million pages of mixed PDFs, SQL rows, SharePoint sites and certified PEC mail, per tenant. A million tokens is roughly 1,500 pages. The corpus does not fit, and it never will, because it grows faster than context windows do.

So retrieval survives, and with it the parts that were never about window size:

• Tenant isolation. The retriever is where I enforce that tenant A's embeddings are physically unreachable from tenant B's query. A prompt-stuffing architecture moves that guarantee into "we assembled the context correctly," which is not a guarantee I want to defend to an auditor.
• Citations that point at something. Regulated users need "page 34 of policy 8811-C," not a model's recollection of it. Retrieval gives me the anchor for free; long context makes me reconstruct it.
• Permissions. The answer must differ by who asked. That filter belongs in the query path, before the model sees anything.
• Cost and latency. A million-token prefill is not free, and repeated per-turn it is brutal. Retrieval is a cache with an access-control policy attached.

Where the effort moved

The interesting shift is that long context turns retrieval from a precision problem into a selection problem. I no longer need the retriever to find the exact passage. I need it to find the right ten documents and hand them over whole. That is a much easier target, and it removes the single worst failure mode in enterprise RAG: the retriever returns four relevant chunks, misses the fifth that contained the exception, and the model answers confidently from an incomplete picture.

Same for grounding checks. With whole documents in the window, "is this claim supported by the source?" becomes verifiable in one pass rather than against a bag of fragments.

What I told both clients

Keep the retriever. Widen what it returns. Retrieve documents, not chunks, and let the long window absorb the slack. Budget the prefill deliberately, because at sustained volume it is real money on a bare-metal GPU just as it is on an API.

The rule I keep coming back to: long context is a better reader. It is not an index, and it is not an access-control layer. Anything you were doing for compliance reasons rather than window reasons, keep doing.