omp : le harnais qui orchestre tes agents de code

Un CLI d’agent nu, c’est un LLM, un shell et un éditeur de texte. Trois problèmes reviennent alors, quelle que soit la qualité du modèle : les edits ratent le format attendu, chaque retry relit tout le contexte, et rien ne se met entre l’agent et le repo. La couche qui règle ces trois problèmes, c’est le harnais. Ce guide documente celui que j’utilise au quotidien, omp (Oh My Pi), et ce qu’il change concrètement.

Pourquoi un harnais au-dessus d’un CLI d’agent ?

La démonstration la plus nette vient du post « the harness problem » du projet : sur un format d’édition que le modèle « mange » en permanence, le taux de réussite d’un même modèle passe de 6,7 % à 68,3 % dès que le harnais corrige le format avant d’éditer. Ce n’est pas le modèle qui change, c’est la couche autour.

Mon vécu rejoint le mécanisme : dans un CLI nu, un rewrite raté ajoute un tour complet de contexte ; dans un harnais où l’édition est vérifiée avant d’être appliquée, l’échec se voit tout de suite et ne coûte pas un cycle entier. C’est le même argument que pour les gates : une règle que le système applique tient, une règle qu’on espère lue s’oublie.

C’est quoi, omp, concrètement ?

omp est un fork de Pi (Mario Zechner), en TypeScript avec un noyau Rust (~80k lignes), licence MIT, ~24k étoiles. Au programme, ce qui change de la concurrence :

• 60+ providers et un routage par rôle : le modèle n’est plus une constante, c’est une variable de config ;
• 31 outils intégrés, dont LSP (14 opérations), DAP (28 opérations), deux noyaux persistants (Python + Bun) qui peuvent rappeler les outils de l’agent ;
• des edits hash-anchored : le patch est vérifié contre le contenu réel avant application ;
• skills, hooks, subagents : la matière de ce guide.

Installation, deux options :

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

# ou via bun
bun install -g @oh-my-pi/pi-coding-agent

Comment omp charge-t-il sa configuration ?

omp lit la config sur plusieurs niveaux, dans cet ordre de priorité :

~/.omp/agent/     → config utilisateur (skills, agents, hooks, config.yml)
<cwd>/.omp/       → config projet, prime sur l'utilisateur
.claude/ .codex/  → sources de compatibilité, lues en priorité moindre

La découverte est déterministe : pour chaque capability (skills, hooks, agents, tools), la source native .omp prime, puis les sources de compat, avec déduplication par nom. Les profils (omp --profile <name>) isolent des configs complètes, pratiques pour séparer un contexte pro d’un contexte perso.

Comment mettre ses règles sous gate ?

Les hooks sont des intercepteurs d’événements : tool_call avant exécution (blocage possible), tool_result après (réécriture possible), plus les événements de session. Un hook est un module TypeScript qui exporte une factory :

import type { HookAPI } from "@oh-my-pi/pi-coding-agent/extensibility/hooks"

export default function (pi: HookAPI): void {
  pi.on("tool_call", async (event, ctx) => {
    if (event.toolName !== "bash") return
    const cmd = String(event.input.command ?? "")
    if (!cmd.includes("rm -rf")) return
    if (!ctx.hasUI) return { block: true, reason: "rm -rf bloqué (sans UI)" }
    const ok = await ctx.ui.confirm("Commande dangereuse", `Autoriser : ${cmd}`)
    if (!ok) return { block: true, reason: "refusé par l'utilisateur" }
  })
}

C’est exactement la bascule guidelines → guardrails : la règle n’est plus un texte que l’agent finira par sortir de sa fenêtre de contexte, c’est une contrainte que le système applique. Mes gates de commit et de push (review avant commit, tests avant push) vivent dans les hooks du repo, et omp les exécute.

Comment organiser ses skills ?

Un skill est un dossier <nom>/SKILL.md avec un frontmatter name + description. Au démarrage, omp n’injecte dans le système prompt que nom et description ; le contenu est lu à la demande via skill://<nom>, ou invoqué en interactif via /skill:<nom>.

~/.omp/agent/skills/
  ├─ morning/SKILL.md          # briefing quotidien
  ├─ review/SKILL.md           # process de review
  └─ veille-postcursors/SKILL.md  # veille éditoriale asynchrone

C’est le point clé pour le coût : un skill ne paie pas de taxe de contexte à chaque tour, il ne coûte que quand il est lu. J’ai pu empiler des dizaines de skills de process sans gonfler le contexte permanent, là où tout mettre dans un fichier d’instructions unique aurait coûté à chaque requête.

Comment orchestrer des subagents ?

Les agents sont des fichiers markdown avec frontmatter, découverts dans ~/.omp/agent/agents/*.md et .omp/agents/*.md :

---
name: reviewer
description: Relit un changement pour la correction.
model: "@review"
---
Relis le changement assigné et rapporte des findings concrets.

Le modèle du rôle se règle dans config.yml, sans toucher aux définitions d’agents :

modelRoles:
  review: openai/gpt-5.4:high

L’orchestration : le tool task fane dans des worktrees isolés, chaque sous-agent a sa surface d’outils, et le résultat final est validé par un schéma. Le hub (raccourci Alt+A) montre le roster vivant : statut, activité, coût, tokens par agent. On peut lire le transcript d’un sous-agent, lui envoyer un message de pilotage, réveiller un agent en pause, ou tuer un agent coincé sans abattre la session parente. Les sous-agents peuvent aussi se parler entre eux (IRC), ce qui permet des vérifications croisées sans remonter à chaque fois dans la session principale.

Comment garder la main sur le budget ?

Le routage par rôle est le levier principal : un rôle review sur un modèle budget, un rôle deep sur un modèle premium. Sur la review de code, j’ai mesuré l’écart en conditions contrôlées (même code, même prompt, en aveugle) :

Ce que ça coûte

Prix relevés le 8 août 2026

deepseek-v4-flash (shallow) 4 bugs HIGH trouvés sur 4

0,012 $/appel

glm 4 bugs HIGH trouvés sur 4

0,21 $/review

grok 4 bugs HIGH trouvés sur 4

0,44 $/review

Le modèle budget a trouvé les 4 bugs HIGH, y compris un que le modèle premium a raté. La profondeur de review est un choix mesurable, pas un dogme : les reviews unitaires partent sur le modèle cheap, les reviews architecturales sur le premium. Les détails chiffrés de ce setup (fenêtres de budget, garde-fous, monitoring par modèle) feront l’objet de dispatches dédiés ; ici, retenez la méthode : le budget se règle dans la config, pas dans la tête.

Qu’est-ce que ça change au quotidien ?

Ce qui est meilleur, en vrac :

• Un seul endroit pour tout : skills, hooks, agents, modèles vivent dans la config, versionnés comme le reste.
• Le hub change la délégation : on ne lance plus un sous-agent à l’aveugle, on le voit travailler, on le corrige en direct.
• Le multi-provider est réel : le modèle du quotidien (deepseek-v4-flash via opencode-go) et le modèle de raisonnement cohabitent dans la même session.
• L’outillage intégré : LSP pour les renommages cross-fichiers, debugger pour les crashs, noyaux pour l’analyse de données, sans quitter le terminal.

Et les cons, parce qu’un guide sans cons n’est pas crédible :

• Couche jeune : fork récent, docs et formats de config bougent encore (des migrations automatiques existent, ce qui prouve que ça bouge).
• Le nom « omp » est ambigu en recherche : il collisionne avec d’autres projets, le référencement passera par le contenu, pas par le nom.
• L’écosystème de skills est plus jeune que celui de Claude Code : on écrit les siens, il y a moins de packs prêts à l’emploi.
• Les modèles budget tiennent grâce au harnais, mais le raisonnement profond sur du legacy complexe reste un travail de modèle premium, le harnais ne compense pas tout.

Par où commencer ?

Pas de big-bang. Cinq gestes, dans l’ordre :

1. Installe (curl ou bun, voir plus haut) et lance omp sur un petit projet.
2. Pointe ta config existante : tes .claude sont lus en compatibilité, tu ne perds rien le premier jour.
3. Pose UN hook qui bloque une commande dangereuse (l’exemple rm -rf ci-dessus est copiable tel quel).
4. Écris UN skill pour un process que tu répètes chaque semaine.
5. Définis UN agent spécialisé avec son rôle de modèle dans config.yml.

Le harnais ne rend pas le modèle plus intelligent ; il rend l’échec visible, le contexte maîtrisé, et les règles appliquées. C’est déjà beaucoup. Pour le reste, les principes d’un workflow agentique et la gestion du contexte multi-agents complètent ce guide.