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

> Configurer MiniMax M3.1 Flash dans OpenCode v2.2.3 : provider complet, ID du modèle, appels d'outils réels et correctifs des erreurs de clé et de contexte.

- Canonical HTML: https://omniakey.com/fr/blog/minimax-m3-1-flash-opencode
- Markdown: https://omniakey.com/fr/blog/minimax-m3-1-flash-opencode.md
- Published: 2026-11-12 (updated 2026-11-12)
- Author: Kiki, COO at OmniaKey
- Language: fr
- Category: API setup
- Reading time: 9 min
- All posts: https://omniakey.com/blog/llms.txt

---

[MiniMax M3.1 Flash](https://omniakey.com/fr/minimax-m3-1-flash) fonctionne dans OpenCode v2.2.3 via un [provider personnalisé compatible OpenAI](https://opencode.ai/docs/providers/). 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](https://opencode.ai/docs/providers/) 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](https://omniakey.com/fr/blog/minimax-m3-1-flash-review) 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.

```json
{
  "$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](https://opencode.ai/docs/models.md). Sans eux, OpenCode suppose un contexte de 200 000 tokens et une entrée d'images. [La page du modèle chez OmniaKey](https://omniakey.com/fr/minimax-m3-1-flash) 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](https://opencode.ai/docs/cli.md) 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é :

```bash
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 :

```bash
# 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 :

```prompt
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 :

|Outil|Fois|Portée|
|-|-|-|
|`read`|5|Liste du dépôt, source, dossier de test, `package.json`, fichier de test|
|`write`|1|`src/normalize.js`|
|`shell`|1|`node --test`|

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é :

```text
ℹ 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](https://platform.minimax.io/docs/guides/text-generation.md) indique que le modèle pense toujours, et sa [référence de l'API compatible OpenAI](https://platform.minimax.io/docs/api-reference/text-openai-api.md) 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.

|Réglage|Valeur testée|Ce qu'il contrôle|
|-|-|-|
|`reasoning_effort`|`medium`|La quantité de réflexion avant la réponse|
|`max_tokens`|`4096`|Plafond de sortie du client par appel|
|`limit.context`|`1000000`|Fenêtre de contexte publiée|

`reasoning_effort` accepte low, medium, high, xhigh et max ; sans valeur, [le guide MiniMax](https://platform.minimax.io/docs/guides/text-generation.md) 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](https://platform.minimax.io/docs/api-reference/text-openai-api.md) 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](https://omniakey.com/fr/minimax-m3-1-flash) et du [guide MiniMax](https://platform.minimax.io/docs/guides/text-generation.md). 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`.

|Symptôme|À vérifier|Correction|
|-|-|-|
|`401` ou `403`|`OMNIAKEY_API_KEY` est-elle dans l'environnement du serveur ?|Exportez-la dans le shell qui lance OpenCode, ou utilisez `--standalone` ; gardez la clé hors du JSON.|
|`Model unavailable` ou modèle introuvable|La clé de la carte et `modelID` valent-elles `minimax-m3.1-flash` ?|Corrigez l'orthographe et la casse ; n'utilisez pas l'ID `MiniMax-M3.1-Flash` du fournisseur ; vérifiez que le provider est activé.|
|`404` renvoyé par la passerelle|`settings.baseURL` est-elle exactement l'adresse OmniaKey ?|Mettez la Base URL exacte ci-dessus et supprimez tout chemin en trop.|
|`400` sur adaptive thinking|Un client a-t-il envoyé un raisonnement désactivé ou `reasoning_effort: "none"` ?|Retirez-le et baissez plutôt l'effort.|
|Arrêt après le premier appel d'outil|Le champ de raisonnement est-il réglé ? L'historique le contient-il ?|Mettez `reasoningField` à `"reasoning_content"` et relancez le même prompt.|
|Contenu vide, `finish_reason: "length"`|La réflexion consomme-t-elle le plafond de sortie ?|Baissez d'abord l'effort, puis montez `max_tokens`.|
|Erreur de contexte sur un prompt de 300K|OpenCode utilise-t-il encore sa valeur de 200K ?|Passez `limit.context` à `1000000` et raccourcissez le prompt.|
|Entrée image ou PDF en échec|La page OmniaKey mentionne-t-elle la vision ?|Envoyez seulement du texte et convertissez le fichier avant.|

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](https://platform.minimax.io/docs/api-reference/text-openai-api.md) 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](https://opencode.ai/docs/models.md) 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](https://omniakey.com/fr/blog/claude-code-setup) d'OmniaKey couvre ce client, et la [documentation des agents de code](https://docs.omniakey.com/en/coding) 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](https://opencode.ai/docs/providers/) — vérifié le 12 novembre 2026
- [OpenCode Models](https://opencode.ai/docs/models.md) — vérifié le 12 novembre 2026
- [OpenCode CLI](https://opencode.ai/docs/cli.md) — vérifié le 12 novembre 2026
- [Guide de génération de texte MiniMax](https://platform.minimax.io/docs/guides/text-generation.md) — vérifié le 12 novembre 2026
- [Référence de l'API compatible OpenAI de MiniMax](https://platform.minimax.io/docs/api-reference/text-openai-api.md) — vérifié le 12 novembre 2026
- [OmniaKey : MiniMax M3.1 Flash](https://omniakey.com/fr/minimax-m3-1-flash) — vérifié le 12 novembre 2026
