omp (Oh My Pi) + JoinGonka Gateway : agent avec rôles de modèles

Étape 1 : installer omp. Les méthodes officielles du README du projet :

# macOS and Linux
curl -fsSL https://omp.sh/install | sh

# Homebrew
brew install can1357/tap/omp

# via Bun (requires Bun 1.3.14 or newer)
bun install -g @oh-my-pi/pi-coding-agent

# Windows (PowerShell)
irm https://omp.sh/install.ps1 | iex

Étape 2 : obtenir une clé. Inscrivez-vous sur gate.joingonka.ai/register, confirmez l'adresse et créez une clé avec le préfixe jg- dans la section « Clés API ». Une seule clé et un seul solde fonctionnent pour tous les modèles du réseau.

Étape 3 : lancer l'installateur.

npx @joingonka/setup --tool omp

L'installateur demandera la clé — elle n'est pas transmise dans les arguments de la ligne de commande, pour ne pas rester dans l'historique du shell — et fera quatre choses :

• il enregistrera le fournisseur joingonka dans ~/.omp/agent/models.yml : l'adresse de la passerelle, le protocole openai-completions, la clé en clair et trois modèles du réseau avec leurs vraies fenêtres de contexte et plafonds de réponse ; le fichier recevra les droits 600 ;
• il définira le modèle par défaut — modelRoles.default dans ~/.omp/agent/config.yml — sur DeepSeek V4 Flash, mais uniquement si le rôle est vide ou pointe vers un modèle qui a quitté le réseau : il n'intercepte pas le choix d'autrui, mais indique comment basculer ;
• avant d'écrire, il fera une sauvegarde du fichier précédent, et laissera les autres fournisseurs, rôles et commentaires tels quels ;
• à la fin, il enverra une requête en direct à la passerelle et dira clairement si la clé, l'adresse et le modèle sont acceptés.

Un autre modèle par défaut est défini par le flag --model avec l'abréviation deepseek, glm ou minimax — un modèle explicitement indiqué est toujours enregistré. Pour les dotfiles et les serveurs, il existe un mode sans questions, où la clé est prise dans une variable d'environnement :

JOINGONKA_API_KEY=jg-your-key npx @joingonka/setup --tool omp --model glm --non-interactive

L'installateur tient compte lui-même d'un emplacement non standard des configs : un profil nommé (OMP_PROFILE) et un répertoire d'agent déplacé (PI_CODING_AGENT_DIR). Il transfère l'héritage models.json vers models.yml exactement comme le ferait omp lui-même — les anciens fournisseurs ne disparaîtront pas. Et si un ancien settings.json sans config.yml se trouve à côté, l'installateur ne créera pas de config.yml, pour qu'omp ne manque pas sa propre migration de paramètres : il demandera de lancer omp une fois et de répéter la commande.

Tout ce que fait l'installateur peut être écrit à la main. Deux fichiers, chacun son rôle : models.yml décrit les fournisseurs et les modèles, config.yml contient les réglages — notamment quel modèle occupe quel rôle.

# ~/.omp/agent/models.yml
providers:
  joingonka:
    baseUrl: https://gate.joingonka.ai/v1
    api: openai-completions
    apiKey: jg-your-key
    models:
      - id: deepseek-ai/DeepSeek-V4-Flash-0731
        name: DeepSeek V4 Flash (Gonka)
        input: [text]
        contextWindow: 380000
        maxTokens: 32768
        reasoning: true
      - id: zai-org/GLM-5.3-Flash
        name: GLM-5.3 Flash (Gonka)
        input: [text]
        contextWindow: 390000
        maxTokens: 8192
        reasoning: true
      - id: MiniMaxAI/MiniMax-M2.7
        name: MiniMax M2.7 (Gonka)
        input: [text]
        contextWindow: 200000
        maxTokens: 8192

# ~/.omp/agent/config.yml
modelRoles:
  default: joingonka/deepseek-ai/DeepSeek-V4-Flash-0731

La clé en clair reste l'option la plus simple : omp démarre depuis n'importe quel environnement, et il suffit de protéger le fichier avec chmod 600 ~/.omp/agent/models.yml. Vous préférez garder la clé hors du fichier ? Indiquez dans apiKey le nom de la variable, par exemple JOINGONKA_API_KEY, et exportez-la dans le shell depuis lequel vous lancez omp : c'est exactement cet ordre de résolution de la clé que décrit la documentation du projet.

Le champ facultatif cost (prix par million de tokens) ne sert qu'à estimer le coût d'une session dans l'interface d'omp. L'installateur y inscrit le tarif réel de la passerelle au moment de l'installation ; dans une config manuelle, on peut l'omettre — cette estimation n'a aucun effet sur votre facture, la consommation réelle s'affiche dans votre espace client.

Le sélecteur de modèle s'écrit provider/model-id. Le nom du fournisseur se découpe à la première barre oblique, c'est pourquoi les identifiants du réseau qui contiennent eux-mêmes une barre oblique s'écrivent tels quels : joingonka/deepseek-ai/DeepSeek-V4-Flash-0731. Plutôt que de modifier config.yml, vous pouvez assigner un rôle depuis l'interface — avec la commande /model en session ou dans l'assistant omp setup.

Dans omp, on ne choisit pas une seule modèle pour tout, mais par rôle — c'est le levier de configuration principal. Les rôles intégrés pour le dialogue sont : default, smol, slow, plan, commit, task, tiny, memory, advisor et vision. Il n'est pas nécessaire de tous les assigner : les rôles smol et slow non définis utilisent par défaut le modèle du rôle default, les sous-agents sans rôle task fonctionnent avec le modèle de la session en cours, commit et tiny suivent smol. Une configuration avec une seule ligne default est parfaitement fonctionnelle.

Diviser les rôles entre les modèles du réseau n'est pas fait pour économiser — le prix est le même pour DeepSeek V4 Flash, GLM-5.3 Flash et MiniMax M2.7 — mais pour des raisons de comportement et de capacité : un modèle de raisonnement planifie mieux, un modèle avec une réponse longue écrit mieux, et il est inutile de mettre les petites tâches de fond dans la même file d'attente que la tâche principale.

# ~/.omp/agent/config.yml
modelRoles:
  default: joingonka/deepseek-ai/DeepSeek-V4-Flash-0731
  slow: joingonka/zai-org/GLM-5.3-Flash
  plan: joingonka/zai-org/GLM-5.3-Flash
  tiny: joingonka/MiniMaxAI/MiniMax-M2.7

retry:
  fallbackChains:
    default:
      - joingonka/zai-org/GLM-5.3-Flash

Le bloc retry.fallbackChains est une assurance pour les heures de pointe : lorsque le modèle principal répond obstinément 429, omp transmet le reste de l'action à la chaîne suivante, puis revient au principal après une pause. La clé de la chaîne peut être un rôle, un modèle spécifique ou tout le fournisseur (joingonka/*).

Pour une exécution unique, le rôle est redéfini par un drapeau : omp --model slow lance la session sur le modèle du rôle slow, et --smol, --slow et --plan remplacent le modèle du rôle lui-même. Dans la session, Ctrl+P parcourt les modèles des rôles, et /model ouvre la sélection ; dans l'onglet Roles, vous pouvez également assigner des rôles et leurs alternatives.

Vous pouvez ajouter un niveau de réflexion à la valeur du rôle — :low, :medium, :high. C'est la syntaxe d'omp, et la manière dont chaque modèle interprète le niveau dépend de lui-même : GLM-5.3 Flash, par exemple, utilise un commutateur binaire — détails dans la présentation du modèle. Et un dernier détail utile : les rôles peuvent être redéfinis pour un seul dépôt via le fichier <repo>/.omp/config.yml avec le même bloc modelRoles. Les fournisseurs et les clés restent dans le répertoire personnel, donc la clé ne sera pas incluse dans le dépôt.

Commencez par vérifier que omp voit bien le fournisseur :

omp models joingonka

En réponse, vous recevez un tableau de trois lignes avec les fenêtres de contexte et les plafonds de réponse issus de models.yml, arrondis au millier (sortie tronquée : omp possède aussi les colonnes thinking et images) :

joingonka (3)
model                                context  max-out
deepseek-ai/DeepSeek-V4-Flash-0731      380K      33K
MiniMaxAI/MiniMax-M2.7                  200K     8.2K
zai-org/GLM-5.3-Flash                   390K     8.2K

Ensuite, un test ponctuel sans interface. Placez dans un répertoire vide un fichier contenant une erreur évidente et demandez-lui de la trouver :

omp -p "Read calc.py and tell me in one sentence whether it has a bug."

L'agent doit appeler lui-même l'outil de lecture et répondre de manière concrète — en indiquant l'expression où se trouve l'erreur. Lors de notre essai du 21 septembre 2026, ce cycle — requête, appel d'outil, résultat, réponse — a été franchi proprement par DeepSeek V4 Flash et GLM-5.3 Flash ; pour MiniMax M2.7, voir la dernière ligne du tableau ci-dessous.

Troisième vérification, côté passerelle : dans la console, à la section « Utilisation », la requête apparaîtra dans la répartition « Par modèles », et dans le bloc « Par clés », l'heure de la dernière requête sera mise à jour. Si c'est vide, omp s'adresse à un autre fournisseur : vérifiez ce qui est attribué aux rôles avec la commande omp config get modelRoles.

Si quelque chose ne tourne pas rond, le diagnostic se lit généralement directement dans le message :

L'outil agent consomme des jetons différemment d'un chat : pour chaque phrase, omp ajoute un prompt système et des descriptions d'outils, et une tâche nécessite généralement plusieurs étapes. Lors de nos tests, même avec un seul outil de lecture activé, chaque étape consommait environ 3 500 jetons d'entrée ; avec l'ensemble complet, c'est encore plus. Le coût par jeton est donc déterminant ici.

Via JoinGonka Gateway, les jetons coûtent $0.0069 par million en entrée et $0.021 par million en sortie — le prix est identique pour tous les modèles du réseau et est récupéré sur cette page à partir d'une source en temps réel.

Les estimations dans la colonne de droite sont basées sur les prix de septembre 2026. À titre de comparaison, voici comment payer pour les modèles dans omp :

La barre d'état d'omp affiche une estimation du coût de la session. Elle est calculée via le champ cost dans models.yml : le programme d'installation y inscrit le prix de la passerelle au moment de l'installation, et le prix en dollars sur le réseau fluctue avec le taux du GNK, donc l'estimation est une indication. La consommation exacte et le solde restant sont consultables dans l'espace client, sections « Utilisation » et « Facturation ». La raison pour laquelle le choix par défaut s'est porté sur DeepSeek V4 Flash est expliquée en détail dans l'aperçu du modèle.

Mode de confirmation. Par défaut, omp fonctionne en mode yolo : il approuve lui-même la lecture, l'écriture et l'exécution des commandes. Sur votre propre projet, c'est pratique ; sur du code tiers, c'est une raison de durcir le mode ou de passer en conteneur :

omp config set tools.approvalMode write

En mode write, l'agent ne demande l'autorisation que pour l'exécution des commandes ; en always-ask, il la demande aussi pour l'écriture. Pour un seul lancement, le drapeau --approval-mode remplit la même fonction. C'est une propriété d'omp lui-même, indépendante du fournisseur du modèle.

Pi et omp — des cousins aux configurations distinctes. La configuration d'un outil ne se transmet pas à l'autre : répertoires, formats et noms de champs leur sont propres.

Plusieurs environnements. Un profil nommé (omp --profile work ou la variable OMP_PROFILE) déplace toute la configuration vers ~/.omp/profiles/<name>/agent — pratique pour séparer les clés professionnelles et personnelles. Le répertoire actuel de l'agent s'affiche avec omp config path.

Si vous voulez l'agent dans votre éditeur. omp sait fonctionner dans Zed via le protocole ACP — c'est le même agent avec la même configuration, inutile de reconfigurer le fournisseur et les rôles.