Oh My Opencode Avis : Résultats honnêtes, risques de facturation et quand cela vaut la peine

Que se passe-t-il réellement lorsque vous lancez Ultrawork.

Sommaire

Oh My Opencode promet une « équipe de développement IA virtuelle » : Sisyphus orchestre des spécialistes, les tâches s’exécutent en parallèle et le mot magique ultrawork active tout cela.

Cette promesse se vérifie pour la bonne charge de travail. Pour la mauvaise, elle ajoute des coûts et de la complexité sans améliorer les résultats. Cet article examine ce qui s’est réellement passé lors de tests pratiques et ce que la communauté a découvert après des mois d’utilisation réelle.

agents paresseux travaillant en parallèle

Si vous débutez avec cette pile technologique,

Cet article suppose que vous êtes déjà familier avec le système et souhaitez savoir s’il fonctionne réellement. Pour une vue d’ensemble de la façon dont OMO s’intègre dans la chaîne d’outils de codage IA, consultez la vue d’ensemble des outils pour développeurs IA.

Performances d’Oh My Opencode : Résultats de tests pratiques

J’ai exécuté les mêmes tests que ceux que j’utilise pour OpenCode brut — les mêmes tâches de benchmark LLM que j’ai testées avec OpenCode sur des modèles locaux Ollama et llama.cpp. Cette fois, sur le modèle Big Pickle (GLM 4.6 via OpenCode Zen — niveau gratuit).

La version courte : résultats mitigés, et le mode d’échec était instructif.

Pourquoi Sisyphus évite la délégation sans un prompt explicite Ultrawork

La première chose que j’ai rencontrée, c’est que Sisyphus ne se comportait pas comme un orchestrateur sans un prompting explicite. Même avec le préfixe ulw, il a commencé à faire tout le travail lui-même : lisant les fichiers directement, écrivant du code et sautant complètement les phases de recherche et de planification. Aucune délégation à Oracle, aucune exécution Explore en parallèle, pas d’entretien avec Prometheus.

Pour déclencher réellement l’orchestration, j’ai dû être explicite dans le prompt :

ulw recherchez d'abord le code source,
créez un plan détaillé,
déléguer les tâches d'implémentation,
et n'effectuez un travail direct que lorsque la délégation est déraisonnable

Une fois cela fait, le système s’est comporté comme annoncé. Mais le comportement par défaut, sans ce cadrage, était un OpenCode classique avec une fenêtre de contexte plus lourde. Le mot-clé ultrawork seul ne garantit pas la délégation ; c’est une condition préalable.

Test 1 : Outil CLI IndexNow — Où l’orchestration Oh My Opencode porte ses fruits

La tâche consistait à créer un outil en ligne de commande qui soumet des URL à l’API IndexNow pour l’indexation des moteurs de recherche. C’est une tâche multi-étapes raisonnablement ciblée : lire la spécification de l’API, concevoir la CLI, implémenter, tester.

Avec Oh My Opencode et un prompting d’orchestration explicite, le résultat était nettement meilleur qu’avec OpenCode brut. L’outil final a correctement extrait les URL de sitemap.xml et les a envoyées par lots, en plus de prendre en charge les options CLI standard. L’agent Librarian, qui a récupéré la documentation IndexNow, a apporté un contexte que l’exécution du modèle brut avait manqué.

journal de session oh my opencode indexnow

C’est le genre de tâche pour laquelle OMO est conçu : recherche + implémentation + quelques décisions de conception. La surcharge a payé ici.

Test 2 : Cartographie de migration de pages — Même résultat, trois fois plus de tokens

Le deuxième test était une tâche d’analyse de documents : trier où les pages du site web devaient être migrées en fonction de leurs slugs et d’un document de politique de migration.

Le résultat était identique à l’exécution OpenCode brute — même précision, même structure, mêmes décisions. Mais l’exécution OMO a consommé environ trois fois plus de tokens.

C’est une tâche de raisonnement à fenêtre de contexte unique. Il n’y a pas de parallélisme à exploiter, pas de connaissances spécialisées à tirer d’un sous-agent. La couche d’orchestration a ajouté une surcharge sans ajouter de valeur. Pour cette classe de tâches, OpenCode classique est le meilleur choix.

Sélection de modèle : Pourquoi les modèles plus faibles peinent avec la surcharge d’orchestration

L’exécution sur Big Pickle (un modèle de niveau gratuit) a révélé quelque chose que la communauté a également remarqué : les modèles plus faibles sont plus sensibles à la qualité du harnais que les modèles forts. Claude Opus est assez résilient pour produire de bons résultats même avec une lourde couche d’orchestration autour de lui. Un modèle plus petit comme Big Pickle bénéficie davantage d’un prompt propre et ciblé que d’une configuration multi-agent complexe qui ajoute du bruit au contexte.

Si vous exécutez OMO sur des modèles à budget limité, commencez plus simplement. Utilisez l’orchestration pour les tâches lourdes de recherche où Librarian et Explore ajoutent réellement de l’information. Évitez-la pour les tâches de raisonnement pur où le modèle a juste besoin d’une entrée claire et d’espace pour réfléchir.

Découvertes de la communauté Oh My Opencode : Benchmarks, facturation et mises en garde réelles

Avant de s’engager à fond, il est utile de savoir ce que la communauté a découvert à travers une utilisation réelle — à la fois les succès et les modes d’échec.

Benchmark Oh My Opencode : Taux de réussite de 69 % contre 73 %, 3× plus de requêtes qu’avec OpenCode vanilla

Un membre de la communauté a mené un benchmark systématique sur plus de 120 combinaisons agent/modèle et a publié les résultats. Avec OMO Ultrawork activé, le taux de réussite sur leur évaluation de codage était de 69,2 % — contre 73,1 % pour OpenCode simple sans OMO. L’exécution OMO a pris 10 minutes de plus (55 contre 45 minutes) et a effectué 96 requêtes au lieu de 27.

Leur conclusion : “c’est littéralement juste Opus avec plus d’étapes.” Opus est particulièrement résilient aux différences de harnais — il fournit de solides résultats quel que soit ce qui l’entoure. Les modèles plus faibles ont montré plus de sensibilité au harnais, mais pas nécessairement en faveur de OMO.

Cela ne signifie pas que OMO est inutile. Pour les tâches multi-fichiers importantes, les agents d’arrière-plan parallèles et les flux de travail d’ingénierie complexes, la surcharge paie. Mais pour les tâches de codage qui tiennent dans une fenêtre de contexte unique, OpenCode classique avec un bon modèle matchera souvent ou surpassera une pile d’orchestration complète.

Surcharge de démarrage des tokens : 15 000–25 000 tokens avant tout travail

Une plainte récurrente de la communauté est que OMO injecte de nombreux outils et MCP au démarrage. Un simple message “Hello world” peut consommer 15 000–25 000 tokens rien que pour la configuration de la fenêtre de contexte avant que tout travail réel ne commence. Le mainteneur est conscient de ce problème et travaille sur un chargement différé des outils, mais début 2026, c’est un coût réel à intégrer dans les estimations de prix.

La boucle infinie Gemini de 350 $ — et comment y remédier

En mars 2026, un bug confirmé (problème #2571, étiqueté will-fix) a entraîné une facturation d’environ 438 $ pour un utilisateur en une seule après-midi. Trois problèmes distincts se sont cumulés :

  1. Aucun disjoncteur : OMO n’avait pas de limite maximale d’étapes par sous-agent. Un modèle Gemini est resté bloqué dans une boucle de vérification git diff / read et a exécuté 809 tours consécutifs pendant 3,5 heures sans s’arrêter.

  2. Routage de modèle silencieux : La session parent de l’utilisateur était sur GPT-5.4. Mais une tâche Compose UI déléguée a été acheminée vers Gemini 3.1 Pro via le routage par catégorie (visual-engineering) — un modèle que l’utilisateur n’a jamais sélectionné intentionnellement et sur lequel il n’avait aucune visibilité jusqu’à ce qu’il fouille dans la base de données SQLite après coup.

  3. Affichage de coût incorrect : L’instantané de tarification d’OpenCode pour gemini-3.1-pro-preview manquait la tranche de prix >200K context. Google facture 2× pour les contextes dépassant 200K tokens, mais OpenCode a tout calculé au taux de base. Le coût affiché était moins de la moitié de la facture Google réelle.

Un commentaire de la communauté a résumé la situation : “Gemini tourne constamment en boucle pour moi, c’est pourquoi je l’utilise rarement comme modèle non-lecture.”

Une correction (PR #2590) est en cours — ajout d’une limite d’étapes maximale configurable et d’une détection de boucle. En attendant sa sortie, protégez-vous :

  • Audit de votre configuration de catégorie. Si une catégorie est mappée sur Gemini (y compris visual-engineering par défaut), chaque tâche d’arrière-plan dans cette catégorie utilise Gemini — silencieusement — même lorsque votre session principale utilise un modèle différent.
  • Définissez des limites explicites providerConcurrency pour Gemini dans background_task. Le garder à 1 limite la portée du dégât.
  • Vérifiez vos tableaux de bord de facturation de fournisseur réels, pas seulement le coût affiché par OpenCode, surtout pour Gemini.
{
  "background_task": {
    "providerConcurrency": {
      "google": 1   // plafond strict jusqu'à ce que le disjoncteur soit livré
    }
  }
}

La délégation Ultrawork nécessite le mot-clé — elle n’est pas automatique

Les premiers utilisateurs ont constaté que sans ultrawork, l’agent principal ne délègue souvent pas du tout aux sous-agents spécialisés — il commence simplement à appeler read et grep directement. Le mainteneur a reconnu cela dès le début : “il semble difficile d’atteindre l’appel de l’agent approprié uniquement par des instructions de prompt système sans prompts explicites.”

Le mot-clé ultrawork est ce qui déclenche fiablement l’orchestration. Sans lui, vous exécutez souvent un OpenCode classique avec une fenêtre de contexte plus lourde. Cela correspond à ce que j’ai trouvé dans mes propres tests.

Alternatives plus légères à OMO : OMO Slim et Oh-My-Pi

Si vous souhaitez les crochets d’exécution d’arrière-plan et les améliorations clés d’OMO sans la surcharge d’orchestration d’agent complète, oh-my-opencode-slim est une fourche communautaire qui réduit la gamme de fonctionnalités. Certains utilisateurs ont également migré vers oh-my-pi, qui se concentre sur l’exécution de tâches d’arrière-plan et les crochets tout en gardant la surface de prompt minimale.

Un utilisateur l’a bien dit : “J’aime OMO pour ses crochets et son exécution de tâches d’arrière-plan. Je pense que OMO slim essaie d’optimiser les mauvaises choses. Les prompts de base OpenCode plus des travailleurs d’arrière-plan et des crochets qui auto-promptent le modèle pour continuer quand il décide d’arrêter suffiraient pour moi.”

Le bon choix dépend de votre profil de tâche. Le travail d’ingénierie important et multi-étapes justifie OMO complet. Pour les tâches quotidiennes plus courtes, un harnais plus léger produit souvent de meilleurs résultats avec moins de coûts.

Quand Oh My Opencode surpasse vraiment : Résultats réels des utilisateurs

Pour équilibrer les mises en garde, voici ce que les utilisateurs rapportent comme les victoires les plus claires d’OMO :

  • 8 000 avertissements ESLint résolus en un jour — des agents Explore parallèles scannant le code source tandis que les agents travailleurs exécutent les corrections simultanément
  • Application Tauri de 45k lignes convertie en application web SaaS du jour au lendemain — le mode entretien Prometheus a produit un plan détaillé, Ralph Loop l’a exécuté du début à la fin
  • Fonctionnalités full-stack implémentées bout en bout sans que l’utilisateur touche le clavier au-delà du prompt initial
  • Revues d’architecture sur des bases de code héritées — le rôle consultatif en lecture seule d’Oracle fait surface aux problèmes sans apporter de modifications accidentelles

Le fil conducteur : des tâches qui bénéficient du parallélisme et ont des critères d’acceptation clairs que Prometheus peut vérifier. Les tâches où un modèle unique et concentré suffirait tirent peu de profit de la surcharge d’orchestration.

Oh My Opencode vs OpenCode Vanilla : Quand utiliser chacun

Oh My Opencode n’est pas universellement meilleur qu’OpenCode vanilla. C’est un multiplicateur de force pour une classe spécifique de travail — et une surcharge pour tout le reste.

Utilisez la pile OMO complète (avec ultrawork) lorsque :

  • La tâche s’étend sur plusieurs fichiers et couches
  • Vous avez besoin de recherche, de planification, d’implémentation et de vérification comme phases distinctes
  • Vous bénéficiez d’agents d’arrière-plan parallèles (Explore, Librarian) qui recueillent du contexte pendant que les travailleurs s’exécutent
  • La portée est suffisamment grande pour que vous deviez autrement surveiller l’agent à travers plusieurs prompts séquentiels

Utilisez OpenCode vanilla (ou un harnais plus léger) lorsque :

  • La tâche tient dans une fenêtre de contexte unique
  • Le problème est un raisonnement pur sans recherche externe
  • Vous exécutez des modèles à budget limité — ils bénéficient davantage d’un prompt propre et ciblé que de la complexité d’orchestration
  • Vous voulez une facturation prévisible sans surprises de routage par catégorie

Le risque de facturation est réel et sous-estimé. Jusqu’à ce que le disjoncteur soit mis en place, traitez OMO avec Gemini comme nécessitant une surveillance active — pas comme un système “tirer et oublier”. Pour tout le reste, le système est vraiment impressionnant lorsqu’il est pointé vers le bon problème.

Sources

Discussions et problèmes de la communauté référencés dans cet article :