MiniMax-M3.1-Flash Is Now Answering Your M2.7 Calls: What Changed on October 19

If you are sending MiniMax-M2.7 to a M​iniMax M Plan or Token Plan key today, the model behind that name has changed. M​iniMax's own model-retirement notice sets October 19, 2026 as the date requests addressed to MiniMax-M2.7 and MiniMax-M2.5 on those plans are automatically routed to MiniMax-M3.1-Flash — the same model ID in your code, a different model on the other end, with a thinking budget that defaults to maximum and no way to turn thinking off at all. The model itself is not new: MiniMax-M3.1-Flash has been in the vendor's documentation since 27 September 2026, when we first confirmed it there under the name MiniMax-M3.1-Flash-Preview. What is new, and what is dated today, is the substitution — and the fact that two older model families get folded into it on the same schedule. 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 the notice actually commits to

M​iniMax publishes the schedule in its own model-list documentation, and it is unusually specific for a deprecation. Three dates do all the work.

• October 19, 2026 — the M2.5 and M2.7 families stop being available to new users. • October 19, 2026 — every request to M2.5 or M2.7 under M Plan and Token Plan is automatically routed to M3.1 Flash. Existing model names keep working, and the vendor states plan usage allowances are unchanged. • November 18, 2026 — both families are retired. API requests to them stop working entirely.

Pay-as-you-go is treated separately: M​iniMax says existing pay-as-you-go users keep access until the retirement date, while new users are cut off today. The company's advice is the one you would expect — check whether your applications rely on these models and start planning the migration — which is a little late for anyone whose production traffic was pointed at M2.7 this morning.

The important word in the notice is automatically. This is not a deprecation that returns an error and forces a code change. It is a silent substitution: your request keeps succeeding, your usage keeps drawing down the same allowance, and the thing producing the tokens is different. If you log the requested model but not the responded model, your monitoring will show a healthy service running a model you did not choose.

Three things change inside the response

The vendor's API reference documents both models on the same page, which makes the delta easy to state precisely. MiniMax-M3.1-Flash is a frontier multimodal coding model with a 1,000,000-token context window and tunable thinking depth; MiniMax-M2.7 is a legacy text-and-tool model with a 204,800-token window.

• Context — 1,000,000 tokens on MiniMax-M3.1-Flash vs 204,800 on MiniMax-M2.7, roughly a fivefold increase. • Inputs — text, image and video on MiniMax-M3.1-Flash vs text and tool calls only on the M2.x family, which the vendor's legacy note says explicitly does not accept image or video input. • Thinking — always on and not disableable on MiniMax-M3.1-Flash; sending thinking: {"type": "disabled"} returns HTTP 400 with error code 2013. • Thinking depth — effort accepts low, medium, high, xhigh and max, and defaults to max when omitted. M2.7 has no equivalent control. • Reasoning output — returned in reasoning_content on the O​penAI-compatible protocol and in a thinking block on the A​nthropic-compatible one. reasoning_split: false is not accepted, so thinking cannot be pushed back into content as <think> tags. • Output ceiling — a recommended 131,072 tokens and a hard maximum of 524,288 for generation on MiniMax-M3.1-Flash, against 204,800 total context on M2.7. • Admission tiers — service_tier: "priority" (the 1.5× faster-admission tier) is not supported on MiniMax-M3.1-Flash. A workload that relied on priority admission loses it. • Sampling — top_p defaults to 0.95 on MiniMax-M3.1-Flash, against 0.9 on the M2.x models.

Two of those are cosmetic. The thinking defaults are not. A workload built for M2.7 never had to think about reasoning effort, because there was nothing to set. The same workload, unchanged, now runs at maximum effort on every request — and M​iniMax counts thinking tokens against the generation limit, which is why the vendor's own documentation warns that a too-small max_tokens yields a max_tokens stop reason with no text output at all.

The default is the expensive setting

Here is the trap in one sentence: the migration notice says your usage allowances are unchanged, and that is true, but the tokens each request consumes are not.

M​iniMax's M Plan FAQ is explicit that consumption depends on thinking depth, and that a higher depth for M3.1 Flash generates more thinking content and consumes more. With effort defaulting to max, a migrated M2.7 workload is now running at the most expensive setting the model offers, chosen by nobody.

A rough illustration, using round numbers and clearly labelled as arithmetic rather than measurement: take 40,000 requests a day, a 6,000-token prompt, and 3,000 thinking tokens at max against roughly 600 at low. That is 96 million extra thinking tokens a day, or about 2.9 billion a month. Priced at MiniMax-M3's published output rate of $1.20 per million tokens — the closest published rate there is, because M​iniMax publishes no per-token rate for M3.1 Flash — that difference is a little over $3,400 a month. Change two of those assumptions and the number moves a lot; the point is that the sign does not.

The fix is one field, and it differs by protocol: output_config.effort on the A​nthropic-compatible endpoint, reasoning_effort on the O​penAI-compatible one, reasoning.effort on the Responses endpoint. M​iniMax's own coding-tool guides recommend exactly this — lower the effort for simple tasks rather than trying to disable thinking, because disabling it is not an option.

There is a second-order effect worth checking before you tune anything. If your client sends max_tokens sized for an M2.7 answer, a max-effort model can spend the entire budget on reasoning and return an empty message. M​iniMax's A​nthropic-compatible reference tells you to set output_config.effort to max explicitly; the same page's parameter table warns that thinking tokens count toward max_tokens. Those two statements sit a few lines apart, and the combination is how you get a 200 response with nothing in it.

There is still no per-token price

This is the part that makes the migration hard to cost rather than hard to code. M​iniMax's pay-as-you-go price table lists one language model: MiniMax-M3, at $0.30 per million input and $1.20 per million output for prompts up to 512,000 input tokens, doubling to $0.60 and $2.40 above that, with a permanent 50% discount already applied to the struck-through list rates. Prompt-cache reads are $0.06 and $0.12 per million respectively. MiniMax-M3.1-Flash does not appear in that table at all.

What is published is subscription pricing. M Plan runs $22 a month for Go, $55 for Explore and $132 for Build, all three including the M3.1 Flash Preview text model, with Explore carrying three times Go's usage allowance and Build seven and a half times. Token Plan still exists for existing subscribers but is no longer sold to new ones, and the vendor's upgrade note says plans keep their current price and text limits either way.

So the honest answer to "what does M3.1 Flash cost per token" is that nobody outside M​iniMax can tell you yet, because the number is not on the page. If you need a per-token number to build a business case this week, the only defensible approach is to measure: run a fixed eval set at each effort level, record usage from the response, and convert at whatever rate your plan implies. A vendor that publishes the model card but not the rate card is telling you it wants the subscription conversation, not the metered one.

Which model ID do you actually send?

M​iniMax's documentation does not agree with itself, and this bites at exactly the wrong moment. The API reference, the model invocation guide and the model list all call the model MiniMax-M3.1-Flash. The M Plan pages, the C​laude Code setup guide and the Codex setup guide all call it MiniMax-M3.1-Flash-Preview, including a C​laude Code configuration that sets four separate environment variables to MiniMax-M3.1-Flash-Preview[1m].

Neither naming is annotated as deprecated, and no page in the documentation announces a general-availability date or a rename. That is worth stating plainly rather than guessing at: as of today the vendor is using both strings, and we could not establish from public documentation which one a pay-as-you-go key will accept. The only test that settles it takes about ten seconds and costs nothing:

curl https://api.minimax.io/v1/models -H "Authorization: Bearer $YOUR_KEY"

Read the IDs that come back and use one of those verbatim. If you are wiring the model into C​laude Code, Cursor, Codex or OpenCode, the vendor's guides expect the -Preview form, and the C​laude Code guide additionally notes that the tool should report MiniMax-M3.1-Flash-Preview as the active model when the configuration is correct.

If you self-host, none of this reaches you

MiniMax-M2.7 is an open-weight model. Its checkpoint has been on Hugging Face since April 2026 under the MiniMaxAI organisation, and the notice that retires the API endpoint does not touch a copy running on your own hardware. The same is true of M2.5. If your M2.7 traffic is served from your own cluster or a private deployment, today's routing change is somebody else's problem.

MiniMax-M3.1-Flash is not in that position. The MiniMaxAI organisation's two most recent public repositories are M​iniMax-Music3, created 7 August 2026, and M​iniMax-H3, created 28 July 2026, and a Hugging Face search for M3.1 returns nothing. There is no checkpoint, no licence file and no self-host escape hatch for the model you are now being routed onto. If open weights were the reason you picked M2.7, the migration is a genuine downgrade in autonomy even where it is an upgrade in capability.

The migration checklist, in the order that matters

• Today — confirm whether you are on a subscription key or a pay-as-you-go key. The auto-routing applies to M Plan and Token Plan; pay-as-you-go keeps serving M2.5 and M2.7 to existing users until 18 November. • Today — log the model ID the API returns, not just the one you sent, so a silent substitution becomes visible in your data. • This week — set effort explicitly on every call. Pick the level per task class rather than inheriting max. • This week — raise max_tokens or max_completion_tokens before you raise effort, and check for empty completions with a max_tokens stop reason. • Before 18 November — if you still need M2.7 behaviour, port it to a self-hosted checkpoint or accept the new model's behaviour. After that date the endpoint is gone. • Before 18 November — re-test anything that used service_tier: "priority". It is not available on M3.1 Flash, so the latency profile changes even when the model does not.

Where a routing layer earns its keep

The lesson this week is not that M​iniMax shipped a better model. It is that a model ID in your code is a promise the vendor can rewrite, and that the rewrite does not come with a changelog entry in your deploy history.

That is the case for putting model choice behind a router rather than hard-coding a vendor string in twelve services. On OrcaRouter, MiniMax-M3 and the M2.5 and M2.7 endpoints sit alongside 200+ other models behind one key, at 0% markup — provider list price passed straight through, which is why MiniMax-M3 shows up at the same $0.30 and $1.20 per million tokens the vendor charges, and why a vendor price change lands the same day rather than at the next billing cycle.

Two things that is genuinely useful for here. First, the routing DSL lets you pin a specific model for a task class and fall over to a second one when the first is unavailable, so an eval of an unproven model runs next to the incumbent rather than replacing it. Second, automatic failover across providers means a bad afternoon upstream is a degraded route rather than an outage.

One thing to be clear about: MiniMax-M3.1-Flash is not in our catalogue as of today. What we serve is the per-token M​iniMax line — M3, M2.7, M2.5 and H3 — so if you want to compare the model you were just migrated onto against the one you were migrated off, the incumbent side is a single key away. The new model itself you reach through M​iniMax's own plans.

What would change this read

Three publications would move this from a migration story to a launch story, and none of them exists yet. A per-token price for MiniMax-M3.1-Flash would let anyone actually cost the switch. A checkpoint on Hugging Face would restore the self-hosting option that M2.7 users are losing. An entry on Artificial Analysis would give the model its first independent intelligence score — MiniMax-M3 sits at 29.2 on that index, and M​iniMax's own doc claims state-of-the-art results on SWE, BrowseComp and xBench for M3.1 Flash without publishing a single number alongside them.

Until then, treat the model as what it is: callable, documented, unbenchmarked and unpriced per token, now receiving traffic it did not ask for by name. The teams that come out of this well are the ones who noticed on day one that their model ID had become an alias.