Plongée approfondie et guide des modèles des agents spécialisés Opencode

Faites la connaissance de Sisyphus et de son équipe d'agents spécialisés.

Sommaire

Le saut de capacité le plus important dans OpenCode provient des agents spécialisés : séparation délibérée de l’orchestration, de la planification, de l’exécution et de la recherche.

Oh My Opencode intègre cette idée dans un harnais complet, où Sisyphus coordonne une véritable “équipe virtuelle” d’agents dotés de permissions, de prompts et de préférences de modèles différents.

oh my opencode agents

Voici une analyse approfondie des agents et du routage des modèles. Si vous êtes au début de votre parcours :

Pour le contexte plus large de la chaîne d’outils de codage IA, consultez la vue d’ensemble des outils de développement IA.

Qu’est-ce que Oh My Opencode et comment cela étend OpenCode

OpenCode est un agent de codage IA open-source conçu pour le terminal. Il est livré avec une interface en ligne de commande (TUI), et le CLI lance cette TUI par défaut lorsque vous exécutez opencode sans arguments. Il est flexible quant au fournisseur : il prend en charge un large catalogue de fournisseurs, y compris des modèles locaux, expose la configuration du fournisseur via son fichier de configuration et son flux /connect, et gère tout, des API cloud aux points de terminaison Ollama, sans nécessiter de correctifs.

Oh My Opencode (également connu sous le nom de oh-my-openagent, ou simplement “omo”) est un plugin communautaire qui transforme OpenCode en un système d’ingénierie multi-agent complet. Il ajoute :

  • le système d’orchestration Sisyphus avec une exécution parallèle en arrière-plan
  • 11 agents spécialisés avec des rôles distincts, des prompts optimisés par famille de modèles et des permissions d’outils explicites
  • LSP + AST-Grep pour un refactoring de qualité IDE à l’intérieur des agents
  • Hashline : un outil d’édition ancré par hachage qui élimine les erreurs de lignes obsolètes (voir ci-dessous)
  • MCP intégrés : Exa (recherche web), Context7 (documentation officielle), Grep.app (recherche GitHub), tous activés par défaut
  • /init-deep : génère automatiquement des fichiers AGENTS.md hiérarchiques dans tout votre projet pour une injection de contexte légère

Une particularité de nommage : le dépôt amont est maintenant brandisé comme oh-my-openagent, mais le paquet du plugin et les commandes d’installation utilisent toujours oh-my-opencode. Le mainteneur suggère de l’appeler “oh-mo” ou simplement “Sisyphus”.

Pourquoi Oh My Opencode attribue différents modèles à différents agents

Oh My Opencode est construit autour d’une idée fondamentale : les modèles pensent différemment, et chaque prompt d’agent est écrit pour un seul modèle mental. Claude suit des prompts mécaniques — des listes de contrôle détaillées, des modèles, des procédures étape par étape. Plus de règles signifie plus de conformité. GPT (surtout 5.2+) suit des prompts axés sur les principes — des principes concis, une structure XML, des critères de décision explicites. Donnez un prompt Claude de 1 100 lignes à GPT et il se contredira. Donnez un prompt GPT de 121 lignes à Claude et il dérive.

Ce n’est pas une particularité que vous pouvez contourner par configuration. C’est la conception du système.

La conséquence pratique : lorsque vous changez le modèle d’un agent, vous changez le prompt qui s’exécute. Les agents qui prennent en charge plusieurs familles de modèles (Prometheus, Atlas) détectent automatiquement votre modèle à l’exécution via isGptModel() et basculent les prompts automatiquement. Les agents qui ne le font pas (Sisyphus, Hephaestus) ont des prompts écrits pour une seule famille — et les remplacer par la mauvaise famille dégrade considérablement la sortie.

Comment les agents spécialisés de Oh My Opencode collaborent

Les quatre groupes de personnalités d’agents

Les agents se répartissent en quatre groupes en fonction de la famille de modèles pour laquelle ils sont optimisés. Cela compte à la fois pour la compréhension du système et pour les décisions d’auto-hébergement.

Groupe 1 — Communicateurs (Claude / Kimi / GLM) : Sisyphus et Metis. Des prompts longs et mécaniques (~1 100 lignes pour Sisyphus). Ils ont besoin de modèles qui suivent de manière fiable des instructions complexes et multicouches sur des dizaines d’appels d’outils. Claude Opus est la référence. Kimi K2.5 et GLM-5 sont des alternatives solides et rentables qui se comportent de manière similaire. Ne remplacez pas ces agents par d’anciens modèles GPT.

Groupe 2 — Double Prompt (Claude préféré, GPT supporté) : Prometheus et Atlas. Ils détectent automatiquement votre famille de modèle à l’exécution et basculent vers le prompt approprié. Claude obtient la version mécanique complète. GPT obtient une version compacte et axée sur les principes qui atteint le même résultat en ~121 lignes. Sans risque d’utiliser l’un ou l’autre ; le système gère le basculement.

Groupe 3 — GPT-Natif (GPT-5.3-codex / GPT-5.4) : Hephaestus, Oracle, Momus. Style d’exécution autonome axé sur les principes. Leurs prompts supposent un raisonnement indépendant et axé sur les objectifs — ce pour quoi GPT est conçu. Hephaestus n’a pas de solution de repli et nécessite un accès GPT. Ne remplacez pas ces agents par Claude ; le comportement se dégrade.

Groupe 4 — Exécuteurs Utilitaires (vitesse plutôt qu’intelligence) : Explore, Librarian, Multimodal Looker. Ils effectuent des recherches, des recherches et des récupérations. Ils utilisent intentionnellement les modèles les plus rapides et les moins chers disponibles. “Améliorer” Explore avec Opus, c’est comme embaucher un ingénieur senior pour remplir des formulaires administratifs. Ce sont aussi les meilleurs candidats pour le remplacement par des modèles locaux.

Mécanismes de délégation

Oh My Opencode utilise deux outils complémentaires pour la délégation :

  • task()délégation basée sur la catégorie : choisissez une catégorie comme visual-engineering ou deep, injectez éventuellement des compétences et exécutez éventuellement en arrière-plan
  • call_omo_agent()appel direct d’un agent spécifique par son nom, contournant le routage par catégorie

Les deux prennent en charge l’exécution parallèle en arrière-plan, avec une concurrence imposée par fournisseur et par modèle.

Les catégories sont des préréglages de routage de modèles

Lorsque Sisyphus délègue à un sous-agent, il choisit une catégorie, pas un nom de modèle. La catégorie est mappée au bon modèle automatiquement.

Catégorie À quoi ça sert Modèle par défaut
visual-engineering Frontend, UI/UX, CSS, design Gemini 3.1 Pro (high)
artistry Créatif, approches novatrices Gemini 3.1 Pro → Claude Opus → GPT-5.4
ultrabrain Logique difficile, décisions d’architecture GPT-5.4 (xhigh) → Gemini 3.1 Pro → Claude Opus
deep Codage profond, logique complexe multi-fichiers GPT-5.3 Codex → Claude Opus → Gemini 3.1 Pro
unspecified-high Travail complexe général Claude Opus → GPT-5.4 (high) → GLM-5
unspecified-low Travail standard général Claude Sonnet → GPT-5.3 Codex → Gemini Flash
quick Modifications de fichier unique, tâches simples Claude Haiku → Gemini Flash → GPT-5-Nano
writing Texte, documentation, prose Gemini Flash → Claude Sonnet

Les catégories sont aussi la bonne abstraction pour l’auto-hébergement : mappez une catégorie à un modèle local et chaque tâche routée vers cette catégorie l’utilisera automatiquement.

Ordre de résolution des modèles

Demande d'Agent → Décalage Utilisateur (si configuré) → Chaîne de repli → Défaut du système

Priorité des fournisseurs lorsqu’un même modèle est disponible via plusieurs fournisseurs :

Natif (anthropic/, openai/, google/) > Kimi for Coding > GitHub Copilot > Venice > OpenCode Go > Z.ai Coding Plan

Agents Oh My Opencode : Catalogue complet avec rôles et exigences de modèles

Orchestrateurs

Sisyphus

But : Orchestrateur principal. Planifie, délègue et mène les tâches à terme grâce à une exécution parallèle agressive.
Groupe : Communicateur (Claude / Kimi / GLM)
Rôle : Le chef d’équipe qui coordonne sur tout le codebase — son prompt mécanique d’environ 1 100 lignes a besoin d’un modèle capable de suivre chaque étape sur des dizaines d’appels d’outils sans perdre le fil.

⚠️ Ne remplacez jamais Sisyphus par d’anciens modèles GPT. GPT-5.4 a un chemin de prompt dédié mais n’est pas la valeur par défaut recommandée. Claude Opus est la référence.

Chaîne de repli : anthropic/claude-opus-4-6 (max) → opencode-go/kimi-k2.5k2p5gpt-5.4glm-5big-pickle
Auto-hébergé : Sisyphus est l’agent le plus difficile à exécuter localement. La complexité de son prompt le rend dépendant de modèles avec un fort suivi d’instructions sur de longues séquences d’appels d’outils. Un Qwen3-coder local ou DeepSeek-Coder-V3 peut fonctionner pour des tâches simples, mais attendez une dégradation sur les flux de travail nécessitant une coordination multi-agents. Si vous vous auto-hébergez, testez avec une tâche à agent unique avant d’activer l’exécution parallèle.


Atlas

But : “Orchestrateur de liste de tâches.” Garde un plan structuré en mouvement en imposant l’achèvement et la séquençage.
Groupe : Double prompt (Claude préféré, GPT supporté)
Rôle : Tandis que Sisyphus gère la grande image, Atlas conduit la liste de contrôle. Détecte automatiquement votre famille de modèle à l’exécution et bascule les prompts en conséquence.

Chaîne de repli : anthropic/claude-sonnet-4-6opencode-go/kimi-k2.5
Auto-hébergé : Un modèle de codage local rapide et fiable gère raisonnablement bien le travail de type “conduire la liste de contrôle” d’Atlas car les tâches sont plus structurées que l’orchestration de Sisyphus. Qwen3-coder avec un contexte de 32k+ est un point de départ fonctionnel.


Agents de planification

La couche de planification impose “réfléchir avant d’agir” : la collecte des exigences, la détection des lacunes et la critique du plan ont tous lieu avant qu’un agent d’exécution ne voie la tâche.

Prometheus

But : Planificateur stratégique avec un flux de travail de type interview. S’active lorsque vous appuyez sur Tab ou exécutez /start-work.
Groupe : Double prompt (Claude préféré, GPT supporté)
Rôle : Vous interviewe comme un vrai ingénieur — identifie le périmètre, fait surface aux ambiguïtés et produit un plan vérifié avant qu’une seule ligne de code ne soit touchée. La version GPT atteint le même résultat en ~121 lignes ; la version Claude utilise ~1 100 lignes sur 7 fichiers.
Collabore avec : Metis (détection des lacunes) et Momus (validation du plan) avant de passer la main à l’exécution.

Chaîne de repli : anthropic/claude-opus-4-6 (max) → openai/gpt-5.4 (high) → opencode-go/glm-5google/gemini-3.1-pro
Auto-hébergé : Fonctionnel avec un modèle local fort en suivi d’instructions à faible température. La qualité de la planification se dégrade lorsque le modèle ne peut pas maintenir vos contraintes et critères d’acceptation dans le contexte sur une longue interview multi-tours. Fenêtre de contexte minimale de 64k recommandée.


Metis

But : Consultant de pré-planification et analyste de lacunes. S’exécute à une température plus élevée que la plupart des agents pour encourager la détection créative des lacunes.
Groupe : Communicateur (Claude préféré)
Rôle : Revueur “Qu’avons-nous manqué ?” avant l’exécution — pas un travailleur d’écriture de code, mais partie de l’histoire de contrôle qualité du plan.
Collabore avec : Appelé par Prometheus avant que le plan ne soit finalisé.

Chaîne de repli : anthropic/claude-opus-4-6 (max) → opencode-go/glm-5k2p5
Auto-hébergé : Un modèle local capable de raisonnement suffit. Gardez la température non nulle si vous voulez que Metis fasse réellement surface aux cas limites — mettez-la à 0 et elle devient un cachet de validation automatique.


Momus

But : Reviseur de plans impitoyable. Impose la clarté et les normes de vérification. Peut fonctionner comme une porte stricte “OK ou rejet”.
Groupe : GPT-natif
Rôle : Critique mental QA pour les plans. Les restrictions d’outils le maintiennent en mode revue plutôt qu’en mode exécution.
Collabore avec : Utilisé après la création du plan pour remettre en question la faisabilité avant le début des travaux.

Chaîne de repli : openai/gpt-5.4 (medium) → anthropic/claude-opus-4-6 (max) → google/gemini-3.1-pro (high)
Auto-hébergé : Si vous vous auto-hébergez, gardez l’échantillonnage très bas. Tout l’intérêt de Momus est une critique stable et reproductible — la créativité est la dernière chose que vous voulez ici. Un modèle de raisonnement local fort à une température de 0,1 ou moins est la bonne configuration.


Agents ouvriers

Hephaestus

But : Ouvrier profond autonome. Donnez-lui un objectif, pas une recette.
Groupe : GPT-natif — GPT-5.3 Codex uniquement
Rôle : Le spécialiste qui reste dans sa pièce à coder toute la journée. Explore le codebase, recherche des motifs et exécute de bout en bout sans surveillance constante. Le mainteneur l’appelle “l’Artisan Légitime” (une référence délibérée à la décision d’Anthropic de bloquer OpenCode).

⚠️ Aucune chaîne de repli — nécessite un accès GPT. Il n’y a pas de prompt Claude pour cet agent. L’exécuter sans OpenAI ou GitHub Copilot signifie qu’il ne peut pas s’exécuter. “GPT-5.3-codex-spark” existe mais est explicitement déconseillé — il compacte le contexte si agressivement que la gestion de contexte de Oh My Opencode se brise.

Chaîne de repli : openai/gpt-5.3-codex (medium) — aucun repli
Auto-hébergé : Il n’y a pas de remplacement local viable pour Hephaestus aujourd’hui. Son prompt est construit autour du style d’exploration autonome et axé sur les principes de GPT-Codex. Si vous avez besoin d’un ouvrier profond sur une pile entièrement locale, utilisez Sisyphus-Junior avec la catégorie deep à la place (qui route vers GPT-5.3 Codex, ou bascule vers Claude Opus si c’est ce que vous avez).


Sisyphus-Junior

But : Exécuteur généré par catégorie utilisé par le système de délégation.
Groupe : Hérite de la catégorie qui l’a lancé
Rôle : Le “contractant spécialisé” qui hérite de son modèle de la configuration de catégorie. Créé dynamiquement via task(), souvent avec des compétences injectées, et peut être exécuté en arrière-plan pour le parallélisme. Considérez-le comme un ouvrier à la page blanche dont la capacité est déterminée entièrement par la catégorie que vous lui assignez.

Chaîne de repli : anthropic/claude-sonnet-4-6 (par défaut) ; hérite de la catégorie de lancement en pratique
Auto-hébergé : Sisyphus-Junior est l’endroit le plus pratique pour commencer l’auto-hébergement. Mappez chaque catégorie à un modèle local dans oh-my-opencode.jsonc et chaque tâche générée par catégorie l’utilisera automatiquement. Commencez par quick (tâches simples), vérifiez que cela fonctionne, puis étendez à unspecified-low avant de toucher à quoi que ce soit qui route vers deep ou ultrabrain.


Sous-agents spécialistes

Oracle

But : Consultation en lecture seule pour les décisions d’architecture et le débogage complexe.
Groupe : GPT-natif
Rôle : Architecte senior et débogueur “dernier recours”. Intentionnellement restreint des outils d’écriture et de délégation pour que sa sortie reste consultative. Appelez Oracle après un travail majeur, après des échecs répétés ou avant de prendre une décision architecturale à haut risque.

Chaîne de repli : openai/gpt-5.4 (high) → google/gemini-3.1-pro (high) → anthropic/claude-opus-4-6 (max)
Auto-hébergé : Si vous auto-hébergez Oracle, choisissez votre modèle de raisonnement local le plus fort et gardez l’échantillonnage très bas. La différence de qualité de sortie entre un raisonneur local capable et GPT-5.4 est significative pour les questions d’architecture complexes. Dans une configuration hybride, Oracle est l’un des agents qu’il vaut la peine de garder sur un modèle cloud tout en déplaçant le travail utilitaire vers le local.


Librarian

But : Documentation externe et recherche open-source.
Groupe : Exécuteur utilitaire
Rôle : Collecteur de documentation et de preuves. Les restrictions d’outils empêchent la modification, donc il reste concentré sur la sourcing et la synthèse. Conçu pour s’exécuter en parallèle avec Explore pour une collecte de preuves combinée “dans le repo + hors du repo”.

Chaîne de repli : opencode-go/minimax-m2.5minimax-m2.5-freeclaude-haiku-4-5gpt-5-nano
Auto-hébergé : Le meilleur agent à déplacer entièrement en local dès le premier jour. Le travail de Librarian est la récupération et la synthèse, pas le raisonnement profond. N’importe quel modèle local avec un appel d’outils fiable le gère bien. Même un modèle de 7B ou 13B suffit s’il peut suivre le modèle “rechercher, collecter, rapporter” sans dériver.


Explore

But : Grep contextuel et recherche rapide de codebase.
Groupe : Exécuteur utilitaire
Rôle : L’agent “trouve-moi les fichiers et motifs pertinents”. Lancez 10 de ces agents en parallèle pour des questions non triviales, chacun limité à une zone différente du codebase, puis laissez l’orchestrateur synthétiser les résultats.

Chaîne de repli : grok-code-fast-1opencode-go/minimax-m2.5minimax-m2.5-freeclaude-haiku-4-5gpt-5-nano
Auto-hébergé : Avec Librarian, Explore est le meilleur point de départ pour l’inférence locale. Son travail est la correspondance de motifs et la rapport structurée — le modèle n’a pas besoin de raisonnement profond, juste d’un appel d’outils rapide et fiable et d’un bon suivi d’instructions. Un petit modèle de codeur local (Qwen2.5-Coder-7B ou similaire) à haut débit fonctionne bien.


Multimodal Looker

But : Analyste visuel et “lecteur de diagrammes”. Analyse les images et PDF via un flux de travail look_at.
Groupe : Exécuteur utilitaire (vision requise)
Rôle : Lourdement restreint par les outils (lecture seule) pour éviter les effets secondaires et rester purement interprétatif. Utilisé lorsque vous devez alimenter des captures d’écran d’interface, des diagrammes d’architecture ou des pages PDF dans le flux de travail.

Kimi K2.5 est spécifiquement cité comme excellent en compréhension multimodale — c’est pourquoi il se situe haut dans cette chaîne de repli.

Chaîne de repli : openai/gpt-5.4opencode-go/kimi-k2.5zai-coding-plan/glm-4.6vgpt-5-nano
Auto-hébergé : La vision locale nécessite un modèle multimodal avec un bon appel d’outils et assez de contexte. Si votre pile locale n’est pas encore là, gardez Multimodal Looker sur un modèle cloud — un pipeline de vision local mal configuré produit des déchets silencieux, pas des erreurs utiles.


Routage des modèles Oh My Opencode : Chaînes de repli et priorité des fournisseurs

Défauts par agent et conception “pas de modèle global unique”

Oh My Opencode est livré avec des modèles par défaut par agent et des chaînes de repli, pas un modèle global unique. La conception est délibérément opinionée :

  • Explore et Librarian utilisent les modèles les moins chers et les plus rapides car ils n’ont pas besoin de raisonnement profond
  • Oracle et Momus utilisent les modèles les plus capables car leurs sorties commandent l’exécution
  • Sisyphus et Prometheus obtiennent les meilleurs modèles de classe orchestration par défaut

Le niveau OpenCode Go (10 $/mois)

OpenCode Go est un niveau d’abonnement qui fournit un accès fiable aux modèles de pointe chinois via l’infrastructure d’OpenCode. Il apparaît au milieu de nombreuses chaînes de repli comme un pont entre les fournisseurs natifs premium et les alternatives du niveau gratuit.

Modèle via OpenCode Go Utilisé par
opencode-go/kimi-k2.5 Sisyphus, Atlas, Sisyphus-Junior, Multimodal Looker
opencode-go/glm-5 Oracle, Prometheus, Metis, Momus
opencode-go/minimax-m2.5 Librarian, Explore

Si vous n’avez pas d’abonnements Anthropic ou OpenAI, OpenCode Go plus GitHub Copilot couvre la majeure partie de la chaîne de repli à faible coût.

Mappings des fournisseurs pour GitHub Copilot

Lorsque GitHub Copilot est le meilleur fournisseur disponible, les attributions d’agents sont :

Agent Modèle
Sisyphus github-copilot/claude-opus-4-6
Oracle github-copilot/gpt-5.4
Explore github-copilot/grok-code-fast-1
Librarian github-copilot/gemini-3-flash

Les variantes de prompt suivent les familles de modèles

Si vous changez un agent de Claude à GPT ou Gemini, Oh My Opencode n’utilise pas le même prompt. Les agents qui prennent en charge plusieurs familles (Prometheus, Atlas) détectent automatiquement via isGptModel() et basculent. Les agents qui ne prennent pas en charge plusieurs familles (Sisyphus, Hephaestus) ont un seul prompt — remplacez-les par la mauvaise famille et la sortie se dégrade.

Si les sorties de votre agent semblent incorrectes après un changement de modèle, vérifiez si vous avez franchi une frontière de famille de modèles et faites une version antérieure.


Exécution de Oh My Opencode avec des modèles auto-hébergés et locaux

Il y a deux couches à configurer :

  1. OpenCode doit connaître votre fournisseur local et les IDs de modèle
  2. Oh My Opencode doit être informé de quel agent utilise quel modèle (car la plupart des agents ignorent votre modèle sélectionné dans l’UI par conception)

Ce que vous pouvez réellement exécuter localement aujourd’hui

Agent Viabilité locale Approche recommandée
Explore ✅ Excellent N’importe quel modèle de codeur local rapide (Qwen2.5-Coder-7B+)
Librarian ✅ Excellent N’importe quel modèle local rapide avec un appel d’outils fiable
Sisyphus-Junior (catégorie quick) ✅ Bon Petit modèle de codeur pour les tâches rapides
Atlas ⚠️ Fonctionnel Modèle de taille moyenne (13B+), contexte 32k+
Prometheus ⚠️ Fonctionnel Fort suivi d’instructions, contexte 64k+, faible température
Metis ⚠️ Fonctionnel Capable de raisonnement, gardez la température non nulle
Momus ⚠️ Fonctionnel Capable de raisonnement, très faible température
Sisyphus ⚠️ Partiel Uniquement pour des tâches simples à agent unique ; l’orchestration multi-agents a besoin de modèles de classe Claude
Oracle ❌ Non recommandé Gardez sur le cloud ; l’écart de qualité est significatif pour les requêtes complexes
Hephaestus ❌ Aucun chemin local Nécessite GPT-5.3-codex ; aucun équivalent Claude ou local

Étape 1 — Ajouter un fournisseur local à OpenCode

OpenCode prend en charge les modèles locaux et les valeurs baseURL personnalisées dans la configuration du fournisseur — Ollama, vLLM et tout point de terminaison compatible OpenAI sont des options de première classe. Le démarrage rapide d’OpenCode couvre l’authentification des fournisseurs en détail.

{
  "$schema": "https://opencode.ai/config.json",
  "provider": {
    "ollama": {
      "npm": "@ai-sdk/openai-compatible",
      "name": "Ollama",
      "options": {
        "baseURL": "http://localhost:11434/v1"
      },
      "models": {
        "qwen2.5-coder:7b": { "name": "qwen2.5-coder:7b" },
        "qwen2.5-coder:32b": { "name": "qwen2.5-coder:32b" }
      }
    }
  }
}

Pour vLLM ou LM Studio, le même modèle s’applique — pointez simplement baseURL vers le point de terminaison /v1 de votre serveur et listez les modèles que vous avez chargés.

OpenCode nécessite au moins une fenêtre de contexte de 64k pour les agents d’orchestration. Tout ce qui est plus petit et vous verrez des erreurs de troncature en milieu de flux de travail.

Étape 2 — Remplacer les modèles d’agents dans la configuration de Oh My Opencode

Emplacements de configuration (le projet prend la priorité sur le niveau utilisateur) :

  • .opencode/oh-my-opencode.jsonc (niveau projet, priorité la plus élevée)
  • ~/.config/opencode/oh-my-opencode.jsonc (niveau utilisateur)

Une configuration hybride pratique — inférence locale pour les agents utilitaires, cloud pour le raisonnement :

{
  "$schema": "https://raw.githubusercontent.com/code-yeongyu/oh-my-openagent/dev/assets/oh-my-opencode.schema.json",

  "agents": {
    // Agents utilitaires : un modèle local rapide est plus que suffisant
    "explore":    { "model": "ollama/qwen2.5-coder:7b",  "temperature": 0.1 },
    "librarian":  { "model": "ollama/qwen2.5-coder:7b",  "temperature": 0.1 },

    // Sisyphus-Junior en mode quick : le local va bien
    // (contrôlé via les catégories ci-dessous)

    // Gardez les agents de raisonnement sur le cloud
    "oracle":  { "model": "openai/gpt-5.4",          "variant": "high" },
    "momus":   { "model": "openai/gpt-5.4",          "variant": "xhigh" },
    // Hephaestus : ne touchez pas — il a besoin de GPT-5.3-codex, pas de repli
  },

  "categories": {
    // Routez les tâches simples générées vers un modèle local
    "quick":   { "model": "ollama/qwen2.5-coder:7b" },
    "writing": { "model": "ollama/qwen2.5-coder:7b" },

    // Gardez le raisonnement lourd sur le cloud
    "deep":         { "model": "openai/gpt-5.3-codex", "variant": "medium" },
    "ultrabrain":   { "model": "openai/gpt-5.4",       "variant": "xhigh" }
  },

  "background_task": {
    "defaultConcurrency": 2,
    "providerConcurrency": {
      "ollama": 4,    // le point de terminaison local peut gérer plus de parallélisme
      "openai": 2,    // restez dans les limites du plan
      "anthropic": 2
    },
    "modelConcurrency": {
      "ollama/qwen2.5-coder:7b": 4
    }
}

L’alternative économique à l’auto-hébergement complet

Avant de vous engager dans une configuration GPU locale, envisagez la pile OpenCode Go + Kimi for Coding. À environ 11 $/mois au total, elle couvre :

  • Kimi K2.5 pour Sisyphus et Atlas (qualité d’orchestration de classe Claude à faible coût)
  • GLM-5 pour Prometheus, Metis et Momus (raisonnement solide, niveau gratuit disponible)
  • MiniMax M2.5 pour Librarian et Explore (récupération rapide)

Pour la plupart des charges de travail, c’est moins cher que d’exécuter un serveur d’inférence local et ne nécessite pas de matériel GPU.


Outils intégrés de Oh My Opencode : Hashline, Init-Deep, Ralph Loop et MCPs

Hashline — outil d’édition ancré par hachage

L’une des améliorations les plus pratiques de Oh My Opencode est la façon dont il gère les modifications de code. Chaque ligne que l’agent lit revient avec un hachage de contenu :

11#VK| function hello() {
22#XJ|   return "world";
33#MB| }

Lorsque l’agent modifie en référence à ces balises, si le fichier a changé depuis la dernière lecture, le hachage ne correspondra pas et la modification sera rejetée avant toute corruption. Cela élimine toute la classe d’erreurs de “ligne obsolète” où les agents modifient avec confiance des lignes qui n’existent plus. Le taux de réussite de Grok Code Fast sur les tâches de modification est passé de 6,7 % à 68,3 % simplement grâce à ce changement.

/init-deep — injection de contexte hiérarchique

Exécutez /init-deep et Oh My Opencode génère des fichiers AGENTS.md à chaque niveau pertinent de votre arbre de projet :

project/
├── AGENTS.md              ← contexte global du projet
├── src/
│   ├── AGENTS.md          ← contexte spécifique à src
│   └── components/
│       └── AGENTS.md      ← contexte spécifique au composant

Les agents lisent automatiquement le contexte pertinent à leur portée. Au lieu de charger l’ensemble du repo dans le contexte au début de chaque exécution, chaque agent ne récupère que ce qui est pertinent pour l’endroit où il travaille.

Mode de planification Prometheus — /start-work

Pour les tâches complexes, ne tapez pas simplement un prompt et espérez. Appuyez sur Tab pour entrer dans le mode Prometheus ou utilisez /start-work. Prometheus vous interviewe comme un vrai ingénieur : identifie le périmètre, fait surface aux ambiguïtés, construit un plan vérifié avant qu’un agent d’exécution ne s’exécute. La norme “Décision Complète” signifie que le plan ne laisse aucune décision à l’implémenteur.

Ralph Loop — /ulw-loop

Une boucle d’exécution auto-référencielle qui ne s’arrête pas tant que la tâche n’est pas à 100 % terminée. Utilisez ceci pour les tâches grandes et multi-étapes où vous voulez que le système s’auto-vérifie et continue sans votre implication. C’est agressif — assurez-vous que vos limites de concurrence sont définies avant de l’exécuter sur un fournisseur cloud coûteux.

MCPs intégrés

Trois serveurs MCP sont préconfigurés et toujours activés :

  • Exa — recherche web
  • Context7 — recherche de documentation officielle
  • Grep.app — recherche de code GitHub dans les dépôts publics

Vous n’avez pas besoin de configurer ceux-ci. Ils sont disponibles pour tous les agents par défaut.


Pour des résultats pratiques et des benchmarks communautaires sur la façon dont ces agents performants en pratique, consultez l’article d’expérience Oh My Opencode. Pour installer le plugin à partir de zéro, commencez par le démarrage rapide Oh My Opencode.