MiniMax-M3.1-Flash répond désormais à vos appels M2.7 : ce qui a changé le 19 octobre

Si vous envoyez MiniMax-M2.7 à une clé M​iniMax M Plan ou Token Plan aujourd’hui, le modèle derrière ce nom a changé. L’avis de retrait de modèles de M​iniMax fixe au 19 octobre 2026 la date à laquelle les requêtes adressées à MiniMax-M2.7 et MiniMax-M2.5 sur ces offres sont automatiquement routées vers MiniMax-M3.1-Flash — le même ID de modèle dans votre code, mais un modèle différent de l’autre côté, avec un budget de réflexion défini au maximum par défaut et aucun moyen de désactiver complètement la réflexion. Le modèle lui-même n’est pas nouveau : MiniMax-M3.1-Flash figure dans la documentation du fournisseur depuis le 27 septembre 2026, date à laquelle nous l’y avons confirmé pour la première fois sous le nom MiniMax-M3.1-Flash-Preview. Ce qui est nouveau, et daté d’aujourd’hui, c’est la substitution — et le fait que deux familles de modèles plus anciennes y sont intégrées selon le même calendrier. Les défaillances d’IA et incidents d’agents documentés qui sous-tendent des versions comme celle-ci sont recueillis dans l’OrcaRouter AI Incident Archive où chaque entrée comporte ses propres sources, sa gravité, sa note de confiance et un indicateur de contestation.

Ce à quoi l'avis s'engage réellement

M​iniMax publie le calendrier dans sa propre documentation de liste de modèles, et il est d’une précision inhabituelle pour une dépréciation. Trois dates font tout le travail.

• 19 octobre 2026 — les familles M2.5 et M2.7 cessent d’être disponibles pour les nouveaux utilisateurs. • 19 octobre 2026 — toute requête adressée à M2.5 ou M2.7 au titre de M Plan et de Token Plan est automatiquement acheminée vers M3.1 Flash. Les noms de modèles existants continuent de fonctionner, et le fournisseur indique que les quotas d’utilisation des plans restent inchangés. • 18 novembre 2026 — les deux familles sont retirées. Les requêtes API qui leur sont adressées cessent totalement de fonctionner.

Le paiement à l’usage est traité séparément : M​iniMax indique que les utilisateurs existants en paiement à l’usage conservent l’accès jusqu’à la date de mise hors service, tandis que les nouveaux utilisateurs sont privés d’accès dès aujourd’hui. Le conseil de l’entreprise est celui auquel on s’attend — vérifier si vos applications dépendent de ces modèles et commencer à planifier la migration — ce qui arrive un peu tard pour quiconque avait son trafic de production pointé vers M2.7 ce matin.

Le mot important dans l’avis est automatiquement. Il ne s’agit pas d’une dépréciation qui renvoie une erreur et force une modification du code. C’est une substitution silencieuse : votre requête continue de réussir, votre consommation continue de puiser dans la même enveloppe, et ce qui produit les tokens est différent. Si vous journalisez le modèle demandé mais pas le modèle qui a répondu, votre supervision affichera un service sain exécutant un modèle que vous n’avez pas choisi.

Trois choses changent dans la réponse

La référence API du fournisseur documente les deux modèles sur la même page, ce qui permet d’énoncer précisément l’écart. MiniMax-M3.1-Flash est un modèle de codage multimodal de pointe doté d’une fenêtre de contexte de 1 000 000 de jetons et d’une profondeur de réflexion ajustable ; MiniMax-M2.7 est un modèle hérité texte et outils avec une fenêtre de 204 800 jetons.

• Contexte — 1 000 000 de tokens sur MiniMax-M3.1-Flash contre 204 800 sur MiniMax-M2.7, soit environ cinq fois plus. • Entrées — texte, image et vidéo sur MiniMax-M3.1-Flash contre texte et appels d'outils uniquement sur la famille M2.x, que la note du fournisseur relative aux modèles hérités indique explicitement comme n'acceptant pas les entrées image ou vidéo. • Réflexion — toujours activée et non désactivable sur MiniMax-M3.1-Flash ; l'envoi de thinking: {"type": "disabled"} renvoie une erreur HTTP 400 avec le code d'erreur 2013. • Profondeur de réflexion — effort accepte low, medium, high, xhigh et max, et prend la valeur max par défaut lorsqu'il est omis. M2.7 n'a pas de contrôle équivalent. • Sortie de raisonnement — renvoyée dans reasoning_content sur le protocole compatible OpenAI et dans un bloc thinking sur le protocole compatible Anthropic. reasoning_split: false n'est pas accepté, donc la réflexion ne peut pas être réinjectée dans content au moyen de la balise <think>. • Plafond de sortie — 131 072 tokens recommandés et un maximum absolu de 524 288 pour la génération sur MiniMax-M3.1-Flash, contre 204 800 de contexte total sur M2.7. • Niveaux d'admission — service_tier: "priority" (le niveau d'admission 1,5× plus rapide) n'est pas pris en charge sur MiniMax-M3.1-Flash. Une charge de travail qui reposait sur l'admission prioritaire en est privée. • Échantillonnage — top_p vaut 0,95 par défaut sur MiniMax-M3.1-Flash, contre 0,9 sur les modèles M2.x.

Deux d'entre eux sont cosmétiques. Les valeurs par défaut de la réflexion ne le sont pas. Une charge de travail conçue pour M2.7 n'avait jamais eu à se soucier de l'effort de raisonnement, car il n'y avait rien à définir. La même charge de travail, inchangée, s'exécute désormais à l'effort maximal à chaque requête — et M​iniMax compte les jetons de réflexion dans la limite de génération, ce qui explique pourquoi la documentation du fournisseur elle-même avertit qu'un max_tokens trop petit donne un motif d'arrêt max_tokens sans aucune sortie de texte.

La valeur par défaut correspond au réglage coûteux.

Voici le piège en une phrase : l’avis de migration indique que vos quotas d’utilisation sont inchangés, et c’est vrai, mais ce n’est pas le cas du nombre de jetons que consomme chaque requête.

La FAQ du M Plan de M​iniMax indique explicitement que la consommation dépend de la profondeur de réflexion, et qu’une profondeur plus élevée pour M3.1 Flash génère davantage de contenu de réflexion et consomme plus. Avec effort défini par défaut sur max, une charge de travail M2.7 migrée tourne désormais au réglage le plus coûteux proposé par le modèle, que personne n’a choisi.

Une illustration approximative, avec des chiffres ronds et clairement présentée comme de l’arithmétique plutôt qu’une mesure : prenez 40 000 requêtes par jour, un prompt de 6 000 jetons et 3 000 jetons de réflexion à max contre environ 600 à low. Cela représente 96 millions de jetons de réflexion supplémentaires par jour, soit environ 2,9 milliards par mois. Au tarif de sortie publié de MiniMax-M3 de 1,20 $ par million de jetons — le tarif publié le plus proche qui existe, car MiniMax ne publie aucun tarif par jeton pour M3.1 Flash — cet écart représente un peu plus de 3 400 $ par mois. Modifiez deux de ces hypothèses et le chiffre change beaucoup ; l’essentiel est que le signe, lui, ne change pas.

La correction consiste en un seul champ, et il diffère selon le protocole : output_config.effort sur le point de terminaison compatible avec A​nthropic, reasoning_effort sur celui compatible avec O​penAI, reasoning.effort sur le point de terminaison Responses. Les guides d'outils de codage propres à M​iniMax recommandent exactement cela — réduire l'effort pour les tâches simples plutôt que de tenter de désactiver le raisonnement, car le désactiver n'est pas une option.

Il existe un effet de second ordre qu'il vaut la peine de vérifier avant de régler quoi que ce soit. Si votre client envoie max_tokens dimensionné pour une réponse M2.7, un modèle à effort maximal peut dépenser tout le budget en raisonnement et renvoyer un message vide. La référence compatible avec A​nthropic de M​iniMax vous indique de définir explicitement output_config.effort à max ; le tableau des paramètres de la même page avertit que les jetons de réflexion comptent dans max_tokens. Ces deux affirmations se trouvent à quelques lignes d'écart, et c'est cette combinaison qui vous donne une réponse 200 sans rien dedans.

Il n'y a toujours pas de prix par token

C’est la partie qui rend la migration difficile à chiffrer plutôt que difficile à coder. Le tableau tarifaire à l’usage de MiniMax ne liste qu’un seul modèle linguistique : MiniMax-M3, à 0,30 $ par million de tokens d’entrée et 1,20 $ par million de tokens de sortie pour les prompts allant jusqu’à 512 000 tokens d’entrée, ces tarifs doublant à 0,60 $ et 2,40 $ au-delà, avec une remise permanente de 50 % déjà appliquée aux tarifs catalogue barrés. Les lectures du cache de prompts sont à 0,06 $ et 0,12 $ par million respectivement. MiniMax-M3.1-Flash n’apparaît pas du tout dans ce tableau.

Ce qui est publié, ce sont les tarifs d’abonnement. M Plan coûte 22 $ par mois pour Go, 55 $ pour Explore et 132 $ pour Build, les trois incluant le modèle textuel M3.1 Flash Preview, Explore disposant d’une limite d’utilisation trois fois supérieure à celle de Go et Build de sept fois et demie. Token Plan existe toujours pour les abonnés existants, mais n’est plus vendu aux nouveaux, et la note de mise à niveau du fournisseur indique que les plans conservent leur prix et leurs limites de texte actuels dans les deux cas.

Donc, la réponse honnête à « combien coûte M3.1 Flash par token » est que personne en dehors de M​iniMax ne peut encore vous le dire, parce que le chiffre ne figure pas sur la page. Si vous avez besoin d’un chiffre par token pour bâtir un business case cette semaine, la seule approche défendable est de mesurer : exécutez un ensemble d’évaluation fixe à chaque niveau d’effort, relevez l’usage dans la réponse, et convertissez selon le tarif que votre offre implique. Un fournisseur qui publie la fiche du modèle mais pas la grille tarifaire vous fait comprendre qu’il veut la conversation sur l’abonnement, pas celle sur la facturation à l’usage.

Quel ID de modèle envoyez-vous réellement ?

La documentation de M​iniMax ne concorde pas avec elle-même, et cela tombe exactement au pire moment. La référence de l'API, le guide d'invocation des modèles et la liste des modèles désignent tous le modèle MiniMax-M3.1-Flash. Les pages M Plan, le guide de configuration de C​laude Code et le guide de configuration de Codex le désignent tous par MiniMax-M3.1-Flash-Preview, y compris une configuration de C​laude Code qui définit quatre variables d'environnement distinctes à MiniMax-M3.1-Flash-Preview[1m].

Aucune des deux appellations n’est signalée comme obsolète, et aucune page de la documentation n’annonce de date de disponibilité générale ni de changement de nom. Cela mérite d’être dit clairement plutôt que de spéculer : à ce jour, le fournisseur utilise les deux chaînes, et nous n’avons pas pu établir, à partir de la documentation publique, laquelle une clé de paiement à l’usage acceptera. Le seul test qui tranche prend environ dix secondes et ne coûte rien :

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

Lisez les ID renvoyés et utilisez l'un d'eux tel quel. Si vous intégrez le modèle dans C​laude Code, Cursor, Codex ou OpenCode, les guides du fournisseur s'attendent à la forme -Preview, et le guide de C​laude Code précise en outre que l'outil doit signaler MiniMax-M3.1-Flash-Preview comme modèle actif lorsque la configuration est correcte.

Si vous hébergez vous-même, rien de tout cela ne vous parvient.

MiniMax-M2.7 est un modèle à poids ouverts. Son checkpoint est disponible sur Hugging Face depuis avril 2026 sous l’organisation MiniMaxAI, et l’avis qui met hors service le point de terminaison API ne concerne pas une copie exécutée sur votre propre matériel. Il en va de même pour M2.5. Si votre trafic M2.7 est servi depuis votre propre cluster ou un déploiement privé, le changement de routage d’aujourd’hui est le problème de quelqu’un d’autre.

MiniMax-M3.1-Flash n’occupe pas cette position. Les deux dépôts publics les plus récents de l’organisation MiniMaxAI sont M​iniMax-Music3, créé le 7 août 2026, et M​iniMax-H3, créé le 28 juillet 2026, et une recherche Hugging Face pour M3.1 ne renvoie rien. Il n’existe ni checkpoint, ni fichier de licence, ni solution de repli en auto-hébergement pour le modèle vers lequel vous êtes désormais routé. Si les poids ouverts étaient la raison pour laquelle vous avez choisi M2.7, la migration constitue une véritable régression en matière d’autonomie, même lorsqu’elle représente une amélioration des capacités.

La liste de contrôle de migration, dans l’ordre qui compte

• Aujourd’hui — vérifiez si vous utilisez une clé d’abonnement ou une clé de paiement à l’usage. Le routage automatique s’applique à M Plan et Token Plan ; le paiement à l’usage continue de servir M2.5 et M2.7 aux utilisateurs existants jusqu’au 18 novembre. • Aujourd’hui — consignez l’ID de modèle renvoyé par l’API, et pas seulement celui que vous avez envoyé, afin qu’une substitution silencieuse devienne visible dans vos données. • Cette semaine — définissez effort explicitement à chaque appel. Choisissez le niveau selon la classe de tâche plutôt que d’hériter de max. • Cette semaine — augmentez max_tokens ou max_completion_tokens avant d’augmenter effort, et vérifiez les complétions vides avec un motif d’arrêt max_tokens. • Avant le 18 novembre — si vous avez encore besoin du comportement de M2.7, portez-le vers un checkpoint auto-hébergé ou acceptez le comportement du nouveau modèle. Après cette date, le point de terminaison n’existe plus. • Avant le 18 novembre — retestez tout ce qui utilisait service_tier: "priority". Cette option n’est pas disponible sur M3.1 Flash, le profil de latence change donc même si le modèle ne change pas.

Là où une couche de routage justifie sa présence

La leçon de cette semaine n’est pas que M​iniMax a livré un meilleur modèle. C’est qu’un identifiant de modèle dans votre code est une promesse que le fournisseur peut réécrire, et que cette réécriture ne s’accompagne pas d’une entrée de journal des modifications dans l’historique de vos déploiements.

C'est l'argument en faveur du placement du choix du modèle derrière un routeur plutôt que du codage en dur d'une chaîne de fournisseur dans douze services. Sur OrcaRouter, MiniMax-M3 ainsi que les points de terminaison M2.5 et M2.7 côtoient plus de 200 autres modèles derrière une seule clé, avec 0 % de marge — le prix catalogue du fournisseur est répercuté tel quel, ce qui explique pourquoi MiniMax-M3 apparaît aux mêmes 0,30 $ et 1,20 $ par million de tokens que le fournisseur facture, et pourquoi un changement de prix du fournisseur prend effet le jour même plutôt qu'au cycle de facturation suivant.

Deux choses qui sont véritablement utiles ici. Premièrement, le DSL de routage permet d'épingler un modèle spécifique pour une classe de tâches et de basculer vers un second lorsque le premier est indisponible, de sorte qu'une évaluation d'un modèle non éprouvé s'exécute aux côtés du modèle en place plutôt que de le remplacer. Deuxièmement, le basculement automatique entre fournisseurs signifie qu'un après-midi difficile en amont se traduit par une route dégradée plutôt que par une panne.

Une chose doit être claire : MiniMax-M3.1-Flash ne figure pas dans notre catalogue à ce jour. Ce que nous proposons, c’est la gamme M​iniMax facturée au token — M3, M2.7, M2.5 et H3 — donc si vous voulez comparer le modèle vers lequel vous venez d’être migré à celui que vous venez de quitter, le modèle sortant n’est qu’à une seule clé. Le nouveau modèle, lui, est accessible via les formules propres à M​iniMax.

Qu'est-ce qui changerait cette lecture ?

Trois publications feraient passer cela d'un récit de migration à un récit de lancement, et aucune d'elles n'existe encore. Un prix par token pour MiniMax-M3.1-Flash permettrait à quiconque de chiffrer réellement le basculement. Un checkpoint sur Hugging Face rétablirait l'option d'auto-hébergement que les utilisateurs de M2.7 perdent. Une entrée sur Artificial Analysis donnerait au modèle son premier score d'intelligence indépendant — MiniMax-M3 se situe à 29,2 sur cet indice, et la propre documentation de M​iniMax revendique des résultats de pointe sur SWE, BrowseComp et xBench pour M3.1 Flash sans publier le moindre chiffre à l'appui.

D’ici là, traitez le modèle pour ce qu’il est : appelable, documenté, non benchmarké et sans tarif par token, recevant désormais un trafic qu’il n’a pas demandé sous son nom. Les équipes qui s’en sortent bien sont celles qui ont remarqué dès le premier jour que leur ID de modèle était devenu un alias.