TL;DR — MiniMax M3 ships a 1,048,576-token context window priced at $0.30 per million input tokens, cheap enough to make 'just paste the whole codebase in' a real strategy instead of a joke. Probe results show fast, correct output on coding, arithmetic reasoning, and strict JSON extraction. The real question isn't whether it can hold a million tokens — it's whether stuffing that much text into a prompt beats a retrieval pipeline, and the answer depends entirely on what you're doing with the context once it's in there.
Every engineer who has built a RAG pipeline has had the same intrusive thought at 2am: what if I just... didn't. What if I skipped the chunking, the embedding model, the vector store, the reranker, and just pasted the entire document set into the prompt. MiniMax M3 is the model that makes that thought less insane, because it backs a 1,048,576-token context window with a $0.30 per million input token price tag, according to its listed metadata. That's the whole pitch: brute force, but affordable brute force.
What's actually in the box
MiniMax M3 (Hugging Face ID MiniMaxAI/Minimax-M3) is an open-weight model with a context length just over one million tokens and completion pricing at $1.20 per million output tokens. The input-to-output price ratio (4:1) tells you where this model wants to be used — reading, not writing. You're meant to pour in huge amounts of source material and get back something comparatively small: a summary, an extracted answer, a patch, a JSON object. That asymmetry is the entire economic argument for the "dump everything in" approach: input tokens are the cheap commodity here, and M3 is priced to reward hoarding them.
What the probes showed
I ran three quick probes rather than a context-stress test, but they're informative about whether the model is trustworthy once you've actually crammed that context window full. On a coding task — write merge_intervals for overlapping [start, end] pairs — it produced correct logic: sort by start, then merge whenever the current interval's start falls within the last merged interval's end. That's the standard, correct approach, generated at 223.4 tokens/second over 700 completion tokens in 3.1 seconds, which is snappy for a model this size. The visible output was cut off before it stated the complexity sentence the prompt asked for, so I can't grade that closing line, but the algorithm itself was right, which is the part that matters if you're using this for actual code review over a big repo.
The reasoning probe — a tank filling at 90 L/min while draining at 60 L/min for 20 minutes, then asking how much longer to fill the remaining volume alone — came back correct: 600 L filled in the first phase, 1,800 L remaining, 20 more minutes at 90 L/min. Clean, step-shown, no arithmetic slip. It ran fast too: 97.3 tokens/second, 1.5 seconds, 150 completion tokens. Nothing fancy, but nothing wrong, which is exactly the bar you need cleared before you trust a model with a million tokens of your data.
The structured output probe asked for strict JSON extracted from an invoice description — vendor, date, total. It returned valid JSON with all three fields correctly populated, including pulling the total ($445.50) rather than confusing it with the subtotal, at 76.2 tokens/second. For anyone planning to use M3 as the backend for document-extraction pipelines — which is a very natural use of a cheap, long-context model — that's the probe that matters most, and it passed cleanly.
Dump-everything vs. retrieval pipeline: when brute force wins
This is the actual editorial question, so let's be concrete about it. A retrieval pipeline — chunk, embed, index, retrieve top-k, stuff into a smaller context — exists to solve a cost and precision problem: models used to have small windows, and embedding search let you avoid paying for irrelevant tokens. M3's pricing changes the cost side of that equation. At $0.30/M input, feeding a full 400-page contract or a mid-sized codebase (say, 300,000 tokens) into a single prompt costs about nine cents. That's cheaper than the engineering time it takes to debug a broken retrieval index on a Tuesday afternoon.
Brute force wins clearly in a few situations. First, when the task requires holistic reasoning across the whole document — auditing a contract for inconsistent clauses, tracing a variable's usage across an entire codebase, finding all mentions of a specific claim across a long transcript. Retrieval-based chunking is bad at "look at everything and tell me if anything is wrong," because top-k similarity search assumes you know what you're looking for in advance. Second, when your corpus is small enough to fit whole but was previously excluded on cost grounds — a support team's full knowledge base, a legal team's single case file, a single customer's entire support history. Third, for one-off or exploratory tasks where building and maintaining a retrieval index isn't worth the investment: a one-time compliance sweep of a document set doesn't need a vector database that will be stale next week.
Where it falls apart
Brute force breaks down in three predictable ways. The first is scale: a million tokens is not infinite. A large monorepo, a year of Slack history, or a full legal discovery set will exceed it, and you're back to needing retrieval or summarization anyway — the context window just moved the ceiling, it didn't remove it. The second is latency and attention degradation: models generally get less reliable at pinpointing a needle buried deep in a huge haystack than at reasoning over material that's actually relevant, and stuffing the full context in doesn't guarantee the model weighs distant information correctly — that's a known soft spot for long-context models generally, not something these probes can confirm or deny for M3 specifically, so treat it as a risk to test on your own data before betting production traffic on it. The third is repetition cost: if you're running the same 300,000-token document through queries all day, you're paying for those input tokens every single call, whereas a retrieval index amortizes the embedding cost once and serves cheap lookups after that. Brute force is a great tool for infrequent, exploratory, or one-shot analysis over data too messy or too small to justify a pipeline. It's a bad tool for high-volume repeated queries against a stable corpus, where retrieval's upfront cost pays for itself fast.
Who should actually reach for this
Teams doing ad hoc document analysis — compliance review, contract auditing, codebase archaeology, "what changed in this six-month email thread" — get real value here because the $0.30/M input price makes exploratory, whole-document analysis cheap enough to run without justification. Teams building a production RAG-backed support bot or search product should not switch to "just paste it all in" as their architecture; the repeated-query economics don't favor it, and their corpus will likely outgrow a million tokens anyway. The honest rule of thumb: use M3's context window as a scalpel for one-off jobs on data too awkward to index, not as a replacement for retrieval infrastructure you're running at scale.
Tomorrow's episode looks at Kimi K3 — another open-weight model worth putting next to M3 on the same kind of long-document, cost-per-token math.
The numbers (measured, not quoted)
I ran three quick probes against MiniMax M3 via a hosted API today before writing this. Small sample, one snapshot in time, routed hardware I don't control — treat these as a smell test, not a benchmark:
| Probe | Wall-clock | Output tokens | Tokens/sec (effective) | Result |
|---|---|---|---|---|
| Code | 3.1s | 700 | 223.4 | completed |
| Reasoning | 1.5s | 150 | 97.3 | completed |
| Structured output | 1.3s | 96 | 76.2 | completed |
Effective tokens/sec includes queueing and time-to-first-token — it's what you actually experience, not peak decode speed.
Model card: context window 1,048,576 tokens · hosted pricing $0.3/M input · $1.2/M output · weights: MiniMaxAI/Minimax-M3 on Hugging Face
Credits — where it's due
- MiniMax — for training MiniMax M3 and releasing the weights openly: MiniMaxAI/Minimax-M3. Open releases like this are why a series like this can exist at all.
- OpenRouter — the hosted API used for today's live probes and the pricing/context figures.
- The quantizers and runtime maintainers — the mostly-unpaid people who turn every open release into something that runs on real hardware within days.
Top comments (0)