A generated hero card titled 'MiniMax-M3.1-Flash: documented, not launched', subtitled '19 October 2026'. Left panel reads 'In the docs: model list, every code sample, 1M context, effort low to max, 200 RPM'. Right panel reads 'Not in the docs: per-token price, release note, model card, weights, independent benchmark'. Footer reads 'Per platform.minimax.io, checked 19 October 2026.'
Guides & Insights

MiniMax-M3.1-Flash: The Docs Already Use It, the Price Page Still Doesn't

Author

Rowan Sterling

Date Published

Latest models · 20View all models →
Benchmarks: Artificial Analysis · updated daily
Back to all posts

On 19 October 2026 a model watcher with a good record posted that M​iniMax is "preparing to release MiniMax-M3.1-Flash," pointing at the vendor's API reference. The API reference is real, and the line it quotes — "Frontier multimodal coding model with 1M context window and tunable thinking depth" — is verbatim from M​iniMax's own documentation. But "preparing to release" undersells what is actually on the page. MiniMax-M3.1-Flash is not a codename waiting in a changelog: it is the model in every code sample on the text-generation guide, it sits above MiniMax-M3 in the model list, it shares M3's rate-limit row, and from today it is the destination M​iniMax auto-routes M2.5 and M2.7 subscription traffic to. What it is not is priced, benchmarked, downloadable, or mentioned once in the vendor's release notes. That gap — documented and callable on one page, absent from every commercial page on the next — is the whole story, and it is worth being precise about which parts are confirmed and which are inference. The documented AI failures and agent incidents behind releases like this one are collected in the OrcaRouter AI Incident Archive where each entry carries its own sources, severity, confidence grade and disputed flag.

What is actually on the vendor's pages today

Four separate M​iniMax pages carry the model name, and they do not all carry it the same way. That disagreement is the most useful evidence available, because each page is written by a different team for a different reader.

• The API reference and the model-invocation guide both list MiniMax-M3.1-Flash as a current model, above MiniMax-M3, with a 1,000,000-token context window and the tunable-thinking-depth description. Every curl, Python and Node sample on those pages sends that exact string.

• The model list under FAQ calls it an available model with no preview qualifier, and its retirement notice — dated 19 October 2026 — names "M3.1 Flash" as where M2.5 and M2.7 requests under M Plan and Token Plan are now routed.

• The rate-limit table puts MiniMax-M3.1-Flash and MiniMax-M3 in one row: 200 requests per minute, 10,000,000 tokens per minute. The M2.7 and M2.5 families it replaces are listed at 500 RPM and 20,000,000 TPM, which is worth remembering if you assumed a migration upward in every dimension.

• The M Plan and Token Plan pages still call the text model "M3.1 Flash Preview" — on the plan overview, the plan FAQ, the Token Plan upgrade notice and the M Plan usage rules, in all four places.

A generated single-column scoreboard titled 'MiniMax-M3.1-Flash — what is documented', with six rows: context window 1,000,000 tokens; thinking always on and cannot be disabled; effort levels low, medium, high, xhigh and max; default effort max; rate limit 200 RPM and 10M TPM; per-token price not published. Footer reads 'Per MiniMax API documentation, 19 October 2026; pricing page lists only MiniMax-M3.'

So the name has lost its "Preview" suffix in the technical documentation and kept it in the commercial documentation. No page announces a rename, a general-availability date, or a launch, and the release-notes page is the tell: its most recent language-model entry is still MiniMax-M3 on 1 June 2026, with the only later entry being H3 on 31 July. Whatever happened to this model in late September, M​iniMax never logged it as a release. Treat "M3.1-Flash has dropped the Preview label" as an observation about documentation, not as news the vendor has announced.

Screenshot of MiniMax's Model Invocation documentation page, showing the Supported Models table with MiniMax-M3.1-Flash listed above MiniMax-M3, both at a 1,000,000-token context window, and a MiniMax M3.1-Flash Key Highlights panel listing 1M-token context, agent and coding workflows, and tunable thinking depth.

The one thing that is genuinely new against MiniMax-M3

Strip away the naming and there is a real capability difference, and it is the one the original post noticed. MiniMax-M3 treats thinking as a switch: omitted means off, {"type": "adaptive"} turns it on, {"type": "disabled"} keeps it off. MiniMax-M3.1-Flash treats thinking as a dial that cannot be turned off at all. Send thinking: {"type": "disabled"} — or reasoning_effort: "none" on the O​penAI-compatible endpoint — and the API returns HTTP 400 with error code 2013 and the message that the model "requires adaptive thinking."

What you get instead is an effort ladder with five rungs: low, medium, high, xhigh, max. The vendor documents that higher levels think more thoroughly and emit more thinking tokens at higher latency. The default, when you omit the field entirely, is max. The field name changes with the protocol — output_config.effort on the A​nthropic-compatible endpoint, reasoning_effort on the O​penAI-compatible one, reasoning.effort on the Responses endpoint — but the ladder is the same five values on all three.

Two details sit next to that ladder and are easy to miss. First, thinking tokens count against max_tokens; M​iniMax's own reference notes that a budget sized for a short answer can be consumed entirely by reasoning and return an empty message with stop_reason: "max_tokens". Second, reasoning_split cannot be set to false on this model, so on the O​penAI-compatible path the thinking always arrives in reasoning_content rather than inside <think> tags in content. If you have a parser that scrapes those tags out of M3 output, it has nothing to do here.

This is a genuine ergonomic gain and a genuine billing hazard at the same time, and the two are the same feature. A routine rename at low and a repository-wide refactor at xhigh are the same model making different trades — that is exactly what a Flash tier should offer. But the default is the most expensive rung, so a caller who never sets the field pays for maximum deliberation on every request, including the trivial ones. Any cost model built on M3's token counts will understate M3.1-Flash until effort is pinned.

What "Flash" means in this line, and what it does not

M​iniMax has used the Flash suffix once before, on the 27 September preview that this model appears to be the continuation of, and the tier's pitch there was everyday development rather than frontier work: fast and reliable, from quick bug fixes to full feature work. That is a plausible brief. It is also, as of today, unmeasured.

The M3 row in the same documentation carries a stated output speed of "approximately 100+ tps." The M3.1-Flash row carries no speed figure at all. The rate-limit table gives both models the same 200 RPM and 10M TPM, so throughput per account is documented and latency per token is not. Independent measurement does not fill the gap: Artificial Analysis lists MiniMax-M3 with an Intelligence Index score, and has no entry for MiniMax-M3.1-Flash — the model page returns a 404 and it does not appear in the model index. There is no vendor benchmark sheet either, so the column is empty rather than merely early. A tier called Flash with no published speed number is a marketing position, not a spec.

Three numbers still missing, and what each one blocks

These are the facts that decide whether the model is usable rather than merely callable, and all three are verifiable in a minute.

• Price. M​iniMax's pricing overview has one language-model row: MiniMax-M3 at $0.30 per million input and $1.20 per million output up to 512,000 input tokens, doubling to $0.60 and $2.40 above that, with cache reads at $0.06 and $0.12. There is no M3.1-Flash row anywhere in the table, standard or priority. What exists instead is subscription pricing — M Plan at $22 a month for Go, $55 for Explore and $132 for Build, all three tiers naming the "M3.1 Flash Preview" text model, with Explore at 3× and Build at 7.5× the Go usage allowance. You can buy access to the model; you cannot compute a per-token rate for it.

• Output ceiling. Context is documented at 1,000,000 tokens. Maximum output is not documented for M3.1-Flash, while our own catalogue entry for MiniMax-M3 records 512,000. A million tokens of reading with an undisclosed writing limit is a promise about input, not output, and for code-generation workloads the output figure is the one that decides whether a single pass can finish the job.

• Weights. There are none. The MiniMaxAI organisation's public repositories top out at M​iniMax-Music3 (updated 14 August 2026) and M​iniMax-H3 (13 August), and a request for a MiniMax-M3.1 checkpoint returns the platform's 401 "not visible to you" response rather than a model card. MiniMax-M3, by contrast, has been downloadable from the MiniMaxAI organisation since 2 June 2026 at roughly 427 billion parameters, under a licence Hugging Face files simply as "other." The open-weight option that made M3 interesting to teams with their own GPUs does not carry over to the successor.

There is a fourth gap that matters to anyone wiring this into an existing stack: key type. The text-generation guide's code samples point api_key at "Get Subscription Key," and M​iniMax's own account FAQ is explicit that Subscription Keys and pay-as-you-go API Keys are separate credentials that cannot be substituted for one another. The M Plan FAQ adds the counterpart rule — for anything outside plan coverage, use a pay-as-you-go key. Nothing in the M3.1-Flash documentation says which of the two reaches the model on a per-token basis. We did not call the endpoint to find out, and a reader should not assume a standard API key works just because the model appears in an O​penAI-compatible code block.

The migration is real, and it started today

Separate from the naming question, M​iniMax has committed to a dated schedule that puts this model in production paths it was never explicitly chosen for. From 19 October 2026, M2.5 and M2.7 requests under M Plan and Token Plan are automatically routed to M3.1 Flash, with existing model names continuing to work for backward compatibility and plan usage allowances unchanged. The two families stop being available to new users the same day. On 18 November 2026 they are retired outright, after which API requests to them stop working; existing pay-as-you-go users keep access until then.

Screenshot of MiniMax's FAQ Model List page: the LLM Available Models table lists MiniMax-M3.1-Flash first, described as a frontier multimodal coding model with a 1M context window and tunable thinking depth, above MiniMax-M3; a collapsed section above it is headed MiniMax M2.5 and M2.7 Model Retirement Notice, and further down are the video model rows for MiniMax-H3 and MiniMax-H3-Max.

The word doing the work in that notice is "automatically." Your client keeps sending MiniMax-M2.7, the request keeps succeeding, the allowance keeps drawing down — and the model on the other end is one that always thinks, defaults to maximum effort, and has a lower per-account request ceiling than the model it replaced. If you log the model you asked for but not the model that answered, nothing in your monitoring will tell you this happened. The one-line mitigation is to pin effort to low or medium for migrated workloads before the token bill finds out for you.

If you want to evaluate it without buying a subscription

This is the awkward part. A model you can only reach through a subscription key, with no per-token price and no published latency, is hard to compare against anything on the axis that matters — cost per finished task. The honest position is that MiniMax-M3.1-Flash is not in the OrcaRouter catalogue as of today; a request for a model page for it returns a 404, and the MiniMax models we serve are the per-token line — minimax/minimax-m3 at $0.30/$1.20 with a 1M context, plus the M2.7, M2.5 and H3 endpoints.

What that is good for is the comparison the subscription model hides. Put the model you can actually meter next to the one you cannot, on the same key and the same prompt set, and you get a cost-per-task number for MiniMax-M3 that you can hold against whatever the M Plan seat is really spending. Prices here are the provider's list rate passed through at 0% markup, so the arithmetic you do is the arithmetic M​iniMax publishes rather than a marked-up version of it. Automatic failover keeps an unproven or subscription-gated dependency beside a production path instead of under it, and the routing DSL lets you pin a cheap model for routine calls and send only the hard ones to something more expensive — which is the same effort-tiering decision M3.1-Flash exposes as a parameter, made one layer up. The MiniMax-M3 model page on our site has the rate card and the specs in one place if you want to start there.

What would turn this into a launch

Three publications would settle it, and none exists today. A price row for MiniMax-M3.1-Flash on the pricing overview would make the model comparable and would tell you whether the Flash suffix means cheaper than M3 or merely faster. A release-notes entry dated after 1 June 2026 would establish that a release happened at all, rather than a documentation edit. A checkpoint on Hugging Face would restore the self-hosting option that M3 offered and this model removes. A fourth, independent one would help most: an Artificial Analysis entry with a latency figure, because "Flash" is a claim about speed and only one party has published no number for it.

Until then the accurate summary is narrower than the original post and more useful than a launch write-up: MiniMax-M3.1-Flash is a documented, subscription-reachable, million-token multimodal model with a five-rung thinking ladder that cannot be switched off; it is receiving migrated M2.5 and M2.7 traffic as of today; and it has no published price, no weights, no output ceiling, no release note and no independent score. That is enough to try, and not yet enough to standardise on.