MiniMax M3.1: What the Leaked Preview Documents Say — and What Nobody Has Confirmed

There is a 250 GB checkpoint on Hugging Face named MiniMax-M3.1-preview-private that no one outside a handful of inference partners can open. There is a document dated 22 September that reads exactly like the vendor's architecture note, circulating in a public partner-engineering repository rather than on the vendor's own site. And on 26 September, a widely followed model watcher posted that MiniMax M3.1 is "the next upcoming model for coming week" and that they are already testing a preview of it. Put those three together and you have the entire public record of MiniMax M3.1 — a model whose name, architecture deltas, weight count and week of arrival are all in circulation, and none of which the vendor has said a word about in public. The predecessor it descends from, MiniMax M3, is a different story: that one shipped, and it is the reason anyone cares about this one.

This is what an unreleased model looks like from the outside, and it is worth being precise about the shape of the evidence, because the three strands are not equally strong. The checkpoint's existence is corroborated: multiple independent lines point at the same private repository name and the same file count. The architecture document is not corroborated in that way — it is a third party's transcription, and it could be genuine, stale, or partly invented. The "coming week" claim is a person's expectation, not a schedule. Everything in this article is labelled at the strength it actually has, and nothing here should be read as a release announcement.

What makes MiniMax M3.1 worth an article before it exists is the predecessor. MiniMax M3 was, by most accounts, the strongest open-weight model MiniMax had shipped — a 1M-token, text-image-video model that reached the Artificial Analysis Intelligence Index at 29.2 and is still one of the few open models that will hold a genuinely long context together. If M3.1 lands in the last week of September, the numbers that matter to a developer are not the leak's plausibility but what changed in the layers and what it costs to serve — and on both of those, the leaked document is unusually specific.

What is confirmed, and what is only in circulation

The honest split, as of 27 September 2026:

• Confirmed: no public version of MiniMax M3.1 exists. The MiniMaxAI organisation on Hugging Face returns 401 — the platform's "not found or not visible to you" response — for MiniMaxAI/MiniMax-M3.1, MiniMaxAI/MiniMax-M3.1-preview and MiniMaxAI/MiniMax-M3.1-preview-private alike. Its newest public uploads are still MiniMax-Music3 (7 August 2026) and MiniMax-H3 (28 July 2026).

• Confirmed: MiniMax M3.1 is not routable anywhere we can check. It is absent from the OrcaRouter model catalogue and from the public listings we monitor; the MiniMax model you can actually call today is MiniMax M3, at minimax/minimax-m3.

• Confirmed: MiniMax has published nothing. No model card, no blog post, no pricing page, no weights, no API model ID. There is no press coverage of a launch because there has been no launch.

• In circulation: the architecture document. It is reproduced verbatim in a public repository — longsco/innoferra-eval, a partner onboarding suite for hosted model endpoints, created 23 September 2026 — under the filename PREVIEW-20260922.md, with a header describing it as a vendor document shared on 25 September and a caveat that "model name, provider release date and public launch remain subject to the actual release." That is the document's own hedge, not ours, and it is the right one: a third party's copy of a vendor note is not a MiniMax statement.

• In circulation: the 250 GB checkpoint and its second drop. The repository's onboarding spec records a private multimodal checkpoint at MiniMaxAI/MiniMax-M3.1-preview-private — 62 files, 48 safetensors files, roughly 250 GB, architecture string MiniMaxM3SparseForConditionalGeneration — and then a larger second drop, MiniMax-M3.1-preview2-dspark-private, at 101 files and about 236 GB, which added a 2.3 GB fp8 speculative draft. Both are private. We cannot open either, and neither can you.

• In circulation: the timeline. The 26 September post is the only public dating anyone has offered, and "coming week" is an expectation. Treat the week of 28 September as the window to watch, not as a date.

The one document that carries the engineering detail

Everything specific that is known about MiniMax M3.1's design traces back to that one markdown file, plus two companions in the same repository: an SGLang demo document describing how the checkpoint is meant to be served, and a spec.yaml that a partner endpoint is supposed to satisfy. Read the repository as a whole and it looks like an inference provider doing exactly what an inference provider does — receiving an early drop from MiniMax, writing down what changed, and building a validation suite for it. The repository is not a press kit and it is not written to persuade anyone.

That is a point in its favour, and it is also the limit of what it proves. Nothing in it is signed by MiniMax. The three documents agree with each other in the way real documents agree — the same quantisation constants, the same environment-variable names, the same launch flags — and disagree in the way real drops disagree: the 22 September preview says the new speculative-decoding method has no confidence head, and the second checkpoint drop shipped a draft configuration with enable_confidence_head set to true. A fabrication would not usually include a correction arc. But "unusually coherent" is not "confirmed", and the failure mode for a reader is to absorb the constants below as MiniMax's published design when they are, at most, MiniMax's private design as read by someone else.

The five engineering changes, per that document

Here is the delta between MiniMax M3 and MiniMax M3.1 as the document describes it. Every line is vendor-derived and unaudited — no independent party has measured a MiniMax M3.1 output of any kind.

• Attention coverage. Full attention in the first three layers is replaced with sparse attention, so all layers are sparse. On MiniMax M3, the first three layers were the full-attention anchor of the sparse stack.

• Attention precision — "Q8KV4". Queries, including the indexer's queries, come out of the projection in BF16 and are cast to FP8 E4M3. Keys and values — again including the indexer's — are quantised to E2M1, four bits, in blocks of 16, with a per-block E4M3 scale of amax/6 clamped to [1/512, 448]. The document is emphatic that the ladder is round-half-to-even with asymmetric thresholds, that the outer tensor scale is exactly 1, and that a zero magnitude must encode as positive zero. M3 used an eight-bit KV path of the same family, so this halves KV bytes again.

• Expert precision. The MoE routed experts move from MXFP8 to W4A4 NVFP4, with the shared expert deliberately excluded. The two expert projections get different activation schemes: FC1 uses a dynamic per-row scale of 2688 divided by the row's absolute maximum, with the row scale applied after the GEMM but before the activation function; FC2 uses a fixed outer scale of 16. The practical consequence, spelled out in the partner README, is blunt: "a provider that runs the checkpoint through a generic NVFP4 path without these will produce silently different numerics."

• Speculative decoding. The EAGLE-style multi-token-prediction head is gone, replaced by a method MiniMax calls DSpark — a vanilla Markov head, and in the 22 September document, no confidence head. This is the change with the largest effect on what a served endpoint feels like, because it is the only per-stream speed lever in the design. The demo engine MiniMax shipped alongside the checkpoint does not include DSpark, and the provider measured the gap: on the same 80,000-token frame with no speculation, per-stream throughput is 63.9 tokens per second at concurrency 1 and falls under 60 by concurrency 4, so the document's own conclusion is that without DSpark the stack cannot hold its latency target under load.

• A new request field. MiniMax M3.1 adds a top-level reasoning_effort field taking max, xhigh, high, medium or low, injected into the system prompt as an effort tag by the chat template. M3 had only a thinking switch with adaptive and disabled. The document notes, oddly and specifically, that the field is carried with no validation and no required default — which the provider read as permission to either accept or reject an unlisted value, and which means two compliant endpoints could behave differently on the same request.

Two details in the checkpoint are worth flagging separately because they are the kind of thing a launch post omits. First, the checkpoint ships both an image preprocessor configuration and a video preprocessor configuration — MiniMax M3.1 is a multimodal model by construction, not a text model with vision bolted on later, and the provider's own guidance is not to reject image inputs on the new stack. Second, the second checkpoint drop removed the MTP and NEXTN keys entirely and added nothing that substitutes for them, which is why the DSpark draft had to arrive as a separate 2.3 GB artifact. There is no draft head in the main weights to switch on.

Why there are no M3.1 benchmark numbers, and why that is not an oversight

Every leak write-up eventually reaches the part where it either invents a benchmark table or admits it has none. MiniMax M3.1 has none. The partner specification says so explicitly, in a field that exists purely to stop someone making the mistake:

• "No 3.1 baselines published yet; do not reuse M3 numbers as acceptance bars."

That instruction is the most useful sentence in the whole corpus, because the lazy version of this article writes MiniMax M3's Artificial Analysis scores under a MiniMax M3.1 heading. It should not. The same repository runs AIME-25 and GPQA-Diamond probes against MiniMax's own M3.1 endpoint and records them as teammate-versus-vendor comparisons with the scores not settled: on GPQA-Diamond, 0.904 for the team's run against 0.813 for the vendor's, and on a 600-question MMLU-Pro subset, 0.898 against 0.821. Those are two runs of the same evaluation disagreeing, not a model result, and they are labelled as a preview with repeats counted. Anyone quoting a single MiniMax M3.1 benchmark number today is quoting something that does not exist yet.

What MiniMax M3 is, so the sequel can be sized

MiniMax M3 shipped at the end of May 2026 and went up on Hugging Face on 2 June — 428 billion total parameters with 23 billion active, 60 layers, 128 routed experts with top-4 routing, 4 KV heads against 64 attention heads, and a context window of 1,048,576 tokens with a maximum output of 512,000. On the independent side, Artificial Analysis scores it 29.2 on the Intelligence Index, placing it 60th of 145 sampled models, with 58.6 on the coding index and a p50 of 3,348 milliseconds to first token in our own routing telemetry. MiniMax's own headline number for it is 83.5 on BrowseComp, which is a vendor figure and unaudited as such.

Pricing is the part that ages best in a leak cycle. MiniMax M3 is $0.30 per million input tokens and $1.20 per million output tokens, with cached reads at $0.06 — and it is live on OrcaRouter as minimax/minimax-m3, at the provider's list rate with 0% markup, so if MiniMax prices M3.1 the same way the new rate is live on our side the day it exists rather than a billing cycle later.

The point of restating all that is not nostalgia. It is that the whole reason anyone is refreshing a Hugging Face organisation page this week is that MiniMax M3 was good enough that its successor is a production question rather than a spectator sport — and that a 428-billion-parameter model with a 1M context at $0.30/$1.20 sets a price-performance bar M3.1 has to clear, not just a capability bar.

The anonymous-listing angle, and why it may already have been answered

One thread from earlier in September is worth closing here. An anonymous stealth listing appeared on a third-party coding platform with a 1,000,000-token context, $0 pricing and mandatory reasoning levels, and we covered it under the name Space Bunny Alpha, noting the base rate that every anonymous listing of this kind eventually gets claimed by a vendor — Pony Alpha became a Zhipu model, Hunter Alpha became Xiaomi's, Ox Alpha became a MiniMax release of a different name. The tokenizer and anomaly fingerprints in that listing pointed at a MiniMax preview checkpoint. If MiniMax M3.1 does arrive this week, the most likely reading is that the anonymous listing was its field test, and the mystery resolves by announcement rather than by further forensic work. That is inference, not evidence, and it is the last inference in this piece.

What to watch for, and what to do this week

The signals that would turn this from a leak into a launch are specific and checkable, and they are not the ones most commentary tracks. A public Hugging Face repository under the MiniMaxAI organisation — not a private one — with a model card is the strongest single indicator; the organisation's upload history is public and dates every release to the day. A MiniMax model page or API model ID is the second. A published price is the third, and the one that matters to a budget. A benchmark table on Artificial Analysis dated after the release is the fourth, and the only one that is independent.

Until then, the practical position for anyone building is unchanged from any other pre-release week: the model you can route today is MiniMax M3, one API key reaches it alongside 200+ other models, automatic failover means an endpoint wobble does not become your outage, and a pinned or blended route through the routing DSL or a panel of models answering together through model fusion is how you de-risk a model you have not productionised. If M3.1 arrives, that is a swap of one model ID, not a migration — which is the entire argument for not building a bespoke integration against a leak.

One thing this article will not do is pretend to know when. The checkpoint is real, the documents are specific, and the most recent public claim is a person saying "next week." Of the three, only the first two are things you can verify yourself.