MiniMax M2.5 and M2.7 Retirement: What to Migrate Before November 18

MiniMax's retirement notice sets November 18, 2026 as the cutoff for M2.5 and M2.7 pay-as-you-go API access. M Plan and Token Plan requests follow a different path: the old names route to M3.1 Flash. Before changing a model string, establish which billing route your application actually uses.

There is an important documentation conflict. The same official model list already labels these families retired, while its notice gives existing pay-as-you-go users until November 18. Treat that date as the published migration deadline, not a guarantee that your account can still call an old model. This guide follows the documented contract; it does not claim account-level API testing.

Which requests need a model change?

The notice says new users lost access on October 19. Existing pay-as-you-go users must migrate before November 18, after which requests to those models will stop working. Subscription users have been routed to M3.1 Flash since October 19, with old names retained for compatibility and plan allowances unchanged.

A successful request does not prove the old model is still serving it. If your evaluation dashboard groups results by the model name your application sent, subscription results may look like M2.7 performance even though the provider has changed the backend. Keep the requested name and the access route in your migration record, and do not infer the served model from the request label alone.

Check both application configuration and the gateway that supplies credentials. A developer's coding subscription and a production service's pay-as-you-go key should not be assumed to have the same migration behavior. Third-party inference providers also need their own availability check; this notice concerns MiniMax's platform.

Find old names without exposing credentials

Search the repository for model identifiers before making changes. This command lists matching filenames rather than printing potentially sensitive configuration values:

rg -l --hidden \
  -g '!.git/**' -g '!node_modules/**' -g '!.venv/**' \
  'MiniMax-M2\.(5|7)(-highspeed)?' .

Inspect matches locally. Check deployment configuration, scheduled jobs and gateway defaults separately because they may not live in the repository. Include fallback routes: changing the primary model while leaving an unavailable fallback can turn an otherwise recoverable failure into an outage.

For each caller, record its owner, environment, billing route, requested model, replacement and acceptance test. That small inventory is more useful than a global search-and-replace because it tells you which service still needs verification.

Choose reasoning settings deliberately

The M3.1 Flash invocation guide documents always-on reasoning. Supported effort levels are low, medium, high, xhigh and max; omission defaults to max. Disabling thinking or requesting none returns a 400 error.

The setting depends on the protocol: use output_config.effort for the Anthropic-compatible route, reasoning_effort for Chat Completions, and reasoning.effort for Responses. Audit your wrapper's defaults instead of assuming a model-name replacement updates those fields too.

Start with an explicit setting and compare it against a higher one on representative work. A support-ticket classifier and a repository repair task need different evidence of success. Record elapsed time, billed usage and accepted results so that a successful HTTP response does not become your only migration criterion.

Test the second tool turn, not just the first answer

MiniMax's Anthropic-compatible reference says to preserve the complete assistant response, including thinking and tool-use blocks, in multi-turn function calls. It also says thinking consumes the output-token allowance: a small max_tokens budget can end with a token-limit stop and no text answer.

Run a synthetic workflow that asks for a lookup, returns a controlled tool result, then requests a final answer. Verify that the second request retains the required blocks and that your application handles an exhausted output budget without displaying an empty success message. Repeat with streaming enabled if that is how production runs.

Check the compatibility table for controls your application relies on. For example, this interface documents stop_sequences as ignored and only auto for tool_choice. If your workflow depends on either behavior, a passing text-only smoke test is insufficient. Keep tool permissions and business rules enforced in application code.

Make rollback possible after retirement

Use a small, reversible rollout before moving all traffic. For a ticket workflow, that might mean a fixed set of synthetic cases first, then a limited production slice under your normal data policy. Compare classifications and tool actions against expected results, not just whether the prose sounds reasonable.

The rollback target needs to remain available after November 18. Keeping an old model name in a feature flag is not a recovery plan if that endpoint has stopped serving requests. Validate an alternate supported route or a manual fallback now, and assign someone to remove the obsolete configuration once the new path is stable.

The deadline is easy to put on a calendar. The harder part is proving that the application still behaves correctly when a familiar model name no longer means the same thing.

I'm Paras. I work at the intersection of AI, engineering and distribution.

I help AI teams turn migrations, technical decisions and product changes into clear developer content people can use.

Book a 30-minute call.