MiniMax M3.1 Flash dans OpenCode : configuration testée et appels d'outils

MiniMax M3.1 Flash fonctionne dans OpenCode v2.2.3 via un provider personnalisé compatible OpenAI. Le nom exact du modèle côté OpenCode est omniakey/minimax-m3.1-flash, la Base URL est https://api.omniakey.com/v1, et la configuration ci-dessous a mené à bien une vraie tâche de dépôt le 12 novembre 2026 : cinq lectures, une écriture, un node --test et 12 tests sur 12 au vert.

OpenCode parle le format OpenAI Chat Completions avec un provider personnalisé, et OmniaKey sert ce format sous /v1. Tout tient dans un fichier de projet, mais trois détails décident du succès : l'ID du modèle doit reprendre l'orthographe d'OmniaKey, la clé doit être visible par le processus serveur d'OpenCode, et la configuration du provider doit conserver le champ de raisonnement d'un appel d'outil à l'autre.

Ce qu'il faut avant de commencer

Utilisez OpenCode V2. La version testée est la v2.2.3. V2 place les providers personnalisés dans un objet providers de premier niveau ; les exemples V1 ont une autre forme. Vérifiez donc la documentation des providers V2 et opencode --version avant de copier la configuration.

• OpenCode : v2.2.3, testé le 12 novembre 2026.
• ID du modèle chez OmniaKey : minimax-m3.1-flash.
• Référence dans OpenCode : omniakey/minimax-m3.1-flash.

Créez une clé OmniaKey et placez-la dans OMNIAKEY_API_KEY. Le JSON ci-dessous nomme la variable et ne contient jamais le secret. Prenez un petit dépôt avec une commande de test existante ; l'essai a utilisé un exemple Node avec src/normalize.js, un fichier de test et un script de test.

L'API propre à MiniMax utilise l'ID à casse mixte MiniMax-M3.1-Flash. OmniaKey utilise la forme minuscule minimax-m3.1-flash. Dans opencode.jsonc, mettez l'ID en minuscules d'OmniaKey aux deux endroits, la clé de la table models et modelID ; une autre casse ne correspond pas à l'ID d'OmniaKey.

Si vous choisissez encore un modèle, la critique de MiniMax M3.1 Flash réunit ses benchmarks, les informations de lancement et le raisonnement toujours actif.

La configuration OpenCode V2 testée

Placez ce fichier à la racine du projet sous le nom opencode.jsonc. C'est la forme publique de la configuration utilisée pendant l'essai.

{
  "$schema": "https://opencode.ai/config.json",
  "model": "omniakey/minimax-m3.1-flash",
  "share": "disabled",
  "update": "disable",
  "warming": false,
  "snapshots": false,
  "enabled_providers": ["omniakey"],
  "providers": {
    "omniakey": {
      "name": "OmniaKey",
      "env": ["OMNIAKEY_API_KEY"],
      "package": "@opencode/ai/providers/openai-compatible",
      "settings": {
        "baseURL": "https://api.omniakey.com/v1"
      },
      "models": {
        "minimax-m3.1-flash": {
          "modelID": "minimax-m3.1-flash",
          "name": "MiniMax M3.1 Flash",
          "body": {
            "reasoning_effort": "medium",
            "max_tokens": 4096,
            "stream_options": {"include_usage": true}
          },
          "limit": {
            "context": 1000000,
            "output": 4096
          },
          "capabilities": {
            "tools": true,
            "input": ["text"],
            "output": ["text"],
            "freeform": [],
            "reasoning": {
              "supported": true,
              "effort": ["low", "medium", "high", "xhigh", "max"]
            }
          },
          "compatibility": {
            "reasoningField": "reasoning_content",
            "requireReasoning": true,
            "maxTokensField": "max_tokens"
          }
        }
      }
    }
  },
  "permissions": [
    {"action": "*", "resource": "*", "effect": "deny"},
    {"action": "read", "resource": "*", "effect": "allow"},
    {"action": "glob", "resource": "*", "effect": "allow"},
    {"action": "grep", "resource": "*", "effect": "allow"},
    {"action": "edit", "resource": "src/normalize.js", "effect": "allow"},
    {"action": "shell", "resource": "node --test", "effect": "allow"},
    {"action": "shell", "resource": "git diff *", "effect": "allow"},
    {"action": "external_directory", "resource": "*", "effect": "deny"}
  ]
}

Le tableau env indique à OpenCode quelle variable d'identification lire : OMNIAKEY_API_KEY vient de l'environnement du processus serveur. modelID est l'ID envoyé à OmniaKey, tandis que la clé de la carte models est l'ID qu'OpenCode utilise dans les références provider/model. En gardant minimax-m3.1-flash aux deux endroits, la recherche reste sans ambiguïté.

Les blocs limit et capabilities remplacent les valeurs par défaut d'OpenCode pour un modèle inconnu. Sans eux, OpenCode suppose un contexte de 200 000 tokens et une entrée d'images. La page du modèle chez OmniaKey indique un contexte de 1M tokens et aucune entrée de vision. La configuration fixe donc la limite de contexte à 1000000 et l'entrée au texte seul. Le 1M correspond à la fenêtre publiée, pas à une taille que cette petite tâche a épuisée.

Le bloc body contient les deux valeurs testées : un effort de raisonnement medium et un plafond max_tokens de 4096. La liste effort de capabilities reprend les cinq niveaux décrits par le guide MiniMax ; medium est la valeur utilisée pendant l'essai.

Le bloc permissions est volontairement étroit pour le dépôt de démonstration. Il refuse tout, puis autorise la lecture, glob et grep, une modification de src/normalize.js, la commande node --test et git diff. Il refuse aussi les dossiers externes. Remplacez le chemin et les commandes par les règles de votre projet. Une autorisation globale d'édition ou de shell donne à l'agent beaucoup plus d'accès qu'une tâche bornée n'en demande.

Lancer avec la clé dans le shell du serveur

OpenCode démarre ou retrouve normalement un serveur partagé en arrière-plan. Ce serveur garde les sessions, la configuration et l'exécution des outils, et lit les variables env du provider dans son propre environnement. Une clé exportée dans un autre terminal ne lui parvient pas. La documentation de la CLI OpenCode décrit le serveur partagé et l'option --standalone.

Pour un premier essai prévisible, prenez un serveur privé depuis un shell qui possède la clé :

export OMNIAKEY_API_KEY="your-omniakey-api-key"
opencode --standalone models

La commande models testée ne prend pas d'argument provider. Elle liste omniakey/minimax-m3.1-flash. Lancez ensuite une tâche. L'essai a utilisé cet argument de modèle et le bloc de prompt ci-dessous ; remplacez le repère par le texte exact :

# Replace <task prompt> with the text from the prompt block below.
opencode --standalone run --model omniakey/minimax-m3.1-flash '<task prompt>'

L'option --standalone démarre un serveur privé depuis ce shell : il hérite de la clé et lit la configuration du projet. Un serveur partagé lancé plus tôt ne voit que son propre environnement. La ligne de clé ci-dessus est un repère ; le fichier de configuration ne contient toujours aucun secret.

Si un serveur partagé tourne déjà dans un environnement qui possède OMNIAKEY_API_KEY, vous pouvez l'utiliser. Quand cet environnement n'est pas clair, le serveur privé est la voie reproductible.

Vérifier la boucle lecture, écriture et test

Un petit exemple Node suffit pour voir si les appels d'outils fonctionnent. L'exemple contenait src/normalize.js avec un stub qui ne faisait que trier, un fichier de test à 12 cas et un script node --test. Avant la correction, 3 tests passaient et 9 échouaient.

Voici le prompt utilisé pendant l'essai, tel quel :

Fix src/normalize.js in this small JavaScript repository. Read the source and existing tests, then implement normalizeIntervals: accept valid half-open numeric intervals [start,end], drop empty intervals, sort them, and merge overlapping or touching ranges. Return fresh arrays without mutating the input. Do not change tests or configuration. Run `node --test` and summarize the result. Work only in this repository; do not read any credentials, network resources or files outside it. Use at most 8 tool calls.

L'essai a produit sept opérations d'outil sur six requêtes HTTP, toutes revenues en 200 :

Le premier tour a envoyé deux lectures en parallèle, une pour la liste du dépôt et une pour la source. Les deux tours suivants ont lu le dossier de test, le fichier de paquet et le fichier de test. L'écriture a remplacé la source. L'appel shell a lancé les tests. L'ensemble a duré 70,172 secondes.

L'appel de test dans la boucle a rapporté :

ℹ tests 12
ℹ suites 0
ℹ pass 12
ℹ fail 0
ℹ cancelled 0
ℹ skipped 0
ℹ todo 0
ℹ duration_ms 52.316459

La réponse finale a nommé le fichier modifié et le résultat 12/12. Les six blocs usage totalisent 20 739 tokens d'entrée, lectures de préfixe en cache comprises, et 803 tokens de sortie. La plus longue completion fait 363 tokens : le plafond de 4096 n'a jamais été atteint.

Un processus de relais local a envoyé le corps de la requête et la réponse en streaming à OmniaKey sans modification. C'est une petite tâche : elle confirme que la boucle lecture, écriture et test fonctionne sur ce dépôt, pas que le modèle soit rapide ou propre sur n'importe quel code.

Régler l'effort, le contexte et la sortie

Le raisonnement est obligatoire sur M3.1 Flash. Le guide de génération de texte de MiniMax indique que le modèle pense toujours, et sa référence de l'API compatible OpenAI renvoie HTTP 400 si un client envoie thinking: {"type": "disabled"} ou reasoning_effort: "none". Laissez le raisonnement actif et baissez l'effort quand vous voulez un tour plus court.

reasoning_effort accepte low, medium, high, xhigh et max ; sans valeur, le guide MiniMax indique max par défaut. Medium a suffi pour cette tâche bornée. Un effort plus bas raccourcit la réflexion, mais ne l'éteint pas.

Les paramètres d'échantillonnage ne font rien sur ce modèle. La référence API de MiniMax indique que M3.1 Flash utilise toujours 1 et 0,95 ; retirer temperature et top_p est plus propre que de régler des valeurs ignorées.

Le contexte de 1M tokens vient de la page du modèle chez OmniaKey et du guide MiniMax. La limite de sortie de 4096 est un plafond de sécurité choisi côté client pour cet essai, pas un maximum publié par le fournisseur. Les tokens de réflexion comptent dans ce plafond : un long tour de raisonnement peut donc finir avec finish_reason: "length" et peu ou pas de texte final. Baissez d'abord l'effort, puis montez le plafond si la tâche a besoin de plus de place.

Corriger les erreurs de clé, d'ID et de reprise

L'essai réussi n'a produit aucune erreur. Cette liste suit la documentation OpenCode et MiniMax liée plus haut. La Base URL exacte est https://api.omniakey.com/v1.

La reprise peut échouer à cause de la configuration alors qu'elle ressemble à un problème de modèle. La référence API de MiniMax demande d'ajouter la réponse complète de l'assistant aux tours suivants, tool_calls et la réflexion renvoyée dans reasoning_content compris. Le réglage reasoningField d'OpenCode lit ce champ dans le flux et le restaure au moment d'envoyer l'historique.

Dans cet essai, chaque requête de suivi portait le champ reasoning_content sur les messages d'appel d'outil de l'assistant, les six requêtes ont abouti et chaque résultat d'outil est entré dans le tour suivant.

Coût, permissions et étapes suivantes

OmniaKey facture au token selon les tarifs en vigueur sur la page du modèle. Les six appels ont utilisé 20 739 tokens d'entrée, lectures de préfixe en cache comprises, et 803 tokens de sortie. Pour estimer une tâche similaire, séparez l'usage en entrée non cachée, entrée lue dans le cache et sortie, puis multipliez chaque partie par son tarif actuel. Le total d'entrée ne se multiplie pas par un tarif unique.

Dans votre dépôt, partez de la règle qui refuse tout et ajoutez seulement les dossiers et commandes dont la tâche a besoin. Gardez l'autorisation d'édition sur les fichiers que la tâche modifie et celle du shell sur la commande de test. C'est la partie à réécrire pour chaque projet ; les blocs provider et modèle peuvent rester tels quels.

Le même schéma de clé et de Base URL vaut pour d'autres clients. Le guide de configuration de Claude Code d'OmniaKey couvre ce client, et la documentation des agents de code liste les étapes par outil.

Questions fréquentes

Cette configuration fonctionne-t-elle avec OpenCode V1 ?

La version testée est OpenCode v2.2.3 et la configuration utilise l'objet providers au pluriel de V2. Les pages V1 ont une autre forme ; vérifiez la version avant de la copier dans une installation ancienne.

opencode --standalone models a-t-il besoin d'un filtre de provider ?

Non. La commande testée est exactement opencode --standalone models, sans argument de provider. Elle liste omniakey/minimax-m3.1-flash.

Puis-je envoyer des images ou des PDF à ce modèle via OmniaKey ?

La page du modèle chez OmniaKey ne mentionne pas la vision et la configuration testée ne déclare que l'entrée texte. Envoyez du texte et convertissez d'abord les images ou les PDF. Le modèle MiniMax en amont accepte les images, mais cela n'ajoute pas d'entrée image à la page OmniaKey du modèle.

Puis-je dépasser max_tokens 4096 ?

Oui, le plafond côté client peut monter. 4096 est la valeur testée et les pages actuelles n'indiquent pas de maximum fixe pour ce modèle. La réflexion compte dans ce plafond : surveillez une coupure par longueur ou un contenu vide, baissez d'abord l'effort, puis montez le plafond.

Sources vérifiées

• OpenCode Providers — vérifié le 12 novembre 2026
• OpenCode Models — vérifié le 12 novembre 2026
• OpenCode CLI — vérifié le 12 novembre 2026
• Guide de génération de texte MiniMax — vérifié le 12 novembre 2026
• Référence de l'API compatible OpenAI de MiniMax — vérifié le 12 novembre 2026
• OmniaKey : MiniMax M3.1 Flash — vérifié le 12 novembre 2026