Omnigent : orchestrer plusieurs CLI d’agents

Ce qu’est Omnigent

Omnigent est un meta-harness open source : une couche d’orchestration qui pilote les outils en ligne de commande (CLI) des agents déjà installés. Il ne remplace pas Claude Code, Codex, Cursor, OpenCode, Hermes ou Pi. Il les démarre, attribue une tâche à chacun et supervise le résultat dans une session unique, avec un seul ensemble de règles. Databricks a publié le dépôt en juin 2026 sous licence Apache 2.0, et la page d’accueil affiche toujours Status: alpha.

La promesse pratique est limitée et mérite d’être formulée clairement. Vous décrivez un agent une seule fois, en YAML, puis vous indiquez le harness qui l’exécute. Modifiez cette seule ligne pour exécuter le même agent avec le CLI d’un autre éditeur. Rien d’autre dans votre configuration ne change, car Omnigent contrôle la boucle au-dessus des agents, et non la boucle à l’intérieur de ceux-ci.

Qu’est-ce qu’un méta-harness et en quoi diffère-t-il d’un framework ?

Un harness est le programme qui exécute un modèle en boucle. Il lit votre prompt, appelle des outils, modifie des fichiers et renvoie le résultat. Claude Code est un harness. Codex est un harness. Vous l’installez, vous vous connectez, puis il fonctionne de manière autonome.

Un framework est une bibliothèque contre laquelle vous écrivez du code. Vous l’importez, vous définissez les étapes en Python, puis votre programme devient l’agent. Pour changer de fournisseur, vous devez modifier votre code, car le client du fournisseur est intégré à votre programme.

Un méta-harness se situe à un niveau supérieur aux deux. C’est un superviseur qui exécute des harness comme processus enfants. Omnigent démarre le CLI du fournisseur, lui transmet le travail et lit sa réponse. Vous conservez le CLI déjà installé, ainsi que l’abonnement ou la clé d’API (application programming interface) qui le finance déjà. C’est toute la différence. Elle détermine le public de l’outil : les personnes qui utilisent déjà plusieurs CLI d’agents et qui en ont assez de les piloter un terminal à la fois.

Quel problème une couche d’orchestration résout-elle ?

• Changer de fournisseur se résume à une ligne. La définition de l’agent contient harness et model sous forme de données. Pour déplacer un rôle d’un fournisseur à un autre, il suffit donc de modifier le fichier YAML, sans réécrire le code.
• La revue peut faire intervenir plusieurs fournisseurs. Un diff généré par un modèle est examiné par un modèle d’une autre entreprise. Deux modèles de la même famille ont tendance à partager les mêmes angles morts. Un second avis du même fournisseur a donc moins de valeur.
• La stratégie a un emplacement unique. Les plafonds de dépenses et les demandes d’approbation sont déclarés dans le fichier de l’agent. Ils s’appliquent à tous les sous-agents qui en dépendent.
• La session ne dépend d’aucun outil particulier. Un même transcript couvre le travail effectué par plusieurs CLI. Vous pouvez donc relire ce qui s’est passé sans regrouper quatre historiques de défilement.

Le coût est la couche elle-même. Chaque bug dans Omnigent devient un bug qui s’interpose entre vous et un agent qui fonctionnait auparavant de manière autonome. En alpha, ce coût est réel, et non théorique.

Où se situe un harness multi-agents par rapport aux outils pour agent unique

Si vous n’avez pas encore exécuté un agent sur un serveur, commencez par là. Notre guide sur l’exécution d’un agent de programmation sur un VPS couvre entièrement le cas d’un agent unique. C’est la configuration qu’Omnigent suppose déjà en place. Le domaine plus vaste des agents IA auto-hébergés vous aide à choisir les agents eux-mêmes. Comprendre le fonctionnement réel des agents est un meilleur point de départ si ce vocabulaire ne vous est pas familier.

Omnigent répond aussi à un besoin différent de celui d’une couche de connecteurs. Un travail comme donner aux agents accès à vos propres sources de données concerne les ressources auxquelles un agent peut accéder. Omnigent détermine quel agent s’exécute, dans quel ordre et avec quelles limites. Vous pouvez avoir besoin des deux en même temps, mais leurs fonctions ne se recouvrent pas.

Prérequis d’installation

• Python 3.12 ou version ultérieure. Le package publié déclare requires-python >= 3.12.
• tmux, car les outils de terminal s’exécutent à l’intérieur de celui-ci.
• Au moins une CLI de fournisseur, déjà installée et authentifiée.
• Node.js 22 uniquement si vous construisez depuis un checkout Git. Le wheel publié sur PyPI contient déjà les ressources web compilées ; l’installation normale ne nécessite donc pas Node.js.

Installer une version figée, pas main

curl -fsSL https://raw.githubusercontent.com/omnigent-ai/omnigent/main/scripts/install_oss.sh | sh -s -- --version 0.7.0

La partie sh -s -- n’est pas décorative. Sans elle, sh interprète --version comme sa propre option et l’installateur ne voit jamais le flag. Vous obtenez donc la version la plus récente du jour. Pour un dépôt qui introduit des changements incompatibles toutes les quelques semaines, c’est la différence entre un serveur reproductible et une mauvaise surprise.

L’installateur utilise uv, le gestionnaire de paquets Python d’Astral, et propose d’installer uv s’il est absent. Si uv est déjà installé, ignorez le script :

uv tool install --force --python 3.12 "omnigent==0.7.0"

Les extras suivent le même principe, et le flag doit être répété : --extra e2b --extra kubernetes avec le script, ou "omnigent[e2b,kubernetes]" avec uv. Notez que le tag git est v0.7.0, tandis que la version du paquet sur PyPI est 0.7.0.

uv place le binaire dans le répertoire indiqué par uv tool dir --bin, généralement ~/.local/bin, et l’installateur propose d’ajouter ce répertoire à votre shell profile. Si la commande est introuvable juste après une installation propre, c’est la raison. Vérifiez ce qui a été installé :

omni upgrade --check

Cette commande compare la version installée avec la dernière version publiée et indique si une mise à niveau est disponible, sans l’effectuer. omni et omnigent désignent le même programme sous deux noms.

Pointez-le vers un fournisseur de modèles

omni setup

L’assistant recherche les identifiants déjà présents dans votre environnement et vous demande ceux qui manquent. Il prend en charge les clés API, les abonnements des fournisseurs, les gateways comme OpenRouter ou Ollama, ainsi que les espaces de travail Databricks. Si vous exécutez déjà un serveur de modèles local avec Ollama sur la même machine, configurez un gateway vers ce serveur : le trafic ne quitte jamais la machine.

Une exécution multi-agents minimale

Les agents d’exemple se trouvent dans le dépôt. Clonez donc le même tag que celui que vous avez installé, plutôt que main.

git clone --depth 1 --branch v0.7.0 https://github.com/omnigent-ai/omnigent.git
cd omnigent
omnigent run examples/polly/

Polly est l’orchestrateur de génération de code multi-agents fourni avec le dépôt. Sa configuration déclare des sous-agents nommés claude_code, codex, opencode, cursor, hermes et pi, ainsi qu’une règle qui justifie à elle seule l’exécution de l’exercice : la revue est toujours réalisée par un fournisseur différent de celui qui a effectué l’implémentation. Polly n’écrit pas de code lui-même. Il planifie le travail, le découpe en éléments, délègue chacun d’eux, puis transmet chaque diff à un reviewer d’un autre fournisseur.

Avant toute délégation, Polly effectue un contrôle préalable pour vérifier quels CLI de sous-agents sont réellement présents sur la machine. Si un seul CLI de fournisseur est installé, personne ne peut prendre en charge la revue du diff. Installez-en donc au moins deux avant d’évaluer le résultat. Debby, l’autre exemple fourni, est un agent de débat doté de deux têtes : l’une utilise Claude et l’autre GPT :

omni debby

C’est un moyen rapide de confirmer que deux fournisseurs sont configurés, car Debby a besoin des deux pour produire une réponse.

Les sous-agents sont déclarés comme des outils

Le fichier de l’agent est au format YAML. executor contient le harness, le modèle et l’authentification. tools contient les serveurs MCP (model context protocol), les fonctions Python et les sous-agents. Un sous-agent est un outil doté de type: agent et de son propre exécuteur. C’est le mécanisme qui se trouve derrière tous les éléments précédents.

name: orchestrator
prompt: |
  You coordinate coding and review tasks.

executor:
  harness: claude-sdk
  model: databricks-claude-sonnet-4-6

tools:
  coder:
    type: agent
    prompt: Write and test code.
    executor:
      harness: claude-sdk
      model: databricks-claude-opus-4-7
  reviewer:
    type: agent
    prompt: Review proposed changes.
    executor:
      harness: claude-sdk
      model: databricks-claude-sonnet-4-6

omnigent run path/to/my_agent.yaml

Ces identifiants de modèle proviennent de l’exemple docs/AGENT_YAML_SPEC.md du projet. Il s’agit de noms de modèles hébergés par Databricks. Remplacez harness et model par les valeurs de omni setup configurées sur votre machine. La spécification inclut également antigravity, copilot, kimi, qwen et acp:<slug> pour tout composant utilisant le protocole générique. La spécification prend aussi en charge pass_history: true sur un sous-agent. Cette option lui transmet la conversation parente. Elle consomme des tokens à chaque délégation. Laissez-la donc désactivée pour les sous-agents qui n’ont besoin que de la tâche en cours.

Pourquoi les orchestrations longues doivent s’exécuter sur un VPS

Une exécution multi-agent ne se résume pas à une commande de deux minutes. Il faut planifier, déléguer, attendre les worktrees Git parallèles, examiner les résultats, puis les corriger. Fermer l’écran d’un ordinateur portable interrompt tout. Un VPS (serveur privé virtuel) reste actif et conserve sa connexion réseau. La session continue donc pendant que vous ne la surveillez pas.

omnigent server --background
omnigent server status

Le serveur héberge une interface web sur le port 6767. omnigent server status indique si une interface est active, et omnigent stop l’arrête. Dans les versions antérieures à v0.7.0, il s’agissait de omni server start. Cette commande a été supprimée. Les anciens articles et les anciennes captures d’écran ne correspondront donc pas à ce que votre terminal affiche.

Ne publiez pas le port 6767 sur une adresse publique. Deux configurations sont sûres. Laissez le port fermé dans le firewall et transférez-le via SSH avec ssh -N -L 6767:localhost:6767 you@your-server, puis ouvrez l’interface web à l’adresse http://localhost:6767 sur votre propre machine. Vous pouvez aussi terminer TLS (transport layer security) en amont et activer l’authentification :

OMNIGENT_AUTH_ENABLED=1 omnigent server --background

La partie concernant le firewall est une opération courante, décrite dans les bases du firewall ufw pour un VPS. Si le serveur exécute déjà des conteneurs derrière Traefik devant plusieurs applications Docker Compose, Omnigent constitue un service supplémentaire dans la même configuration.

Pour un déploiement en conteneur, le répertoire deploy/ du dépôt contient une configuration Compose : ./bootstrap.sh génère les secrets dans .env, puis docker compose up -d démarre Omnigent et Postgres sur le port 6767. DATABASE_URL sélectionne Postgres ou SQLite. À l’intérieur des conteneurs, OMNIGENT_AUTH_ENABLED utilise par défaut 1, ce qui est le choix approprié pour tout service accessible depuis l’extérieur.

Concernant le dimensionnement, les notes de déploiement estiment l’ensemble de travail du serveur entre 512 MB et 1 GB, et la configuration Fly.io fixe cette valeur à 1 GB. Ce chiffre concerne uniquement le superviseur. Chaque sous-agent est un processus distinct qui conserve son propre checkout et son propre client de modèle. Dimensionnez donc le serveur en fonction des agents. Une fois le serveur opérationnel, omnigent login https://your-host suivi de omnigent host https://your-host enregistre votre ordinateur portable auprès de celui-ci, et omnigent attach <session_id> reprend une session active depuis un autre appareil.

Isoler chaque sous-agent avant de quitter le système

Omnigent fournit une sandbox au niveau du système d’exploitation appelée Omnibox. Sous Linux, elle utilise des namespaces bubblewrap et seccomp. Le noyau applique donc la séparation, et non le prompt de l’agent. Un agent manipulé par une injection de prompt ne peut pas contourner une règle du noyau en formulant une demande. Installez d’abord la dépendance :

sudo apt install bubblewrap

La configuration se trouve sous os_env dans le fichier de l’agent :

os_env:
  type: caller_process
  cwd: .
  sandbox:
    type: linux_bwrap
    write_paths: [.]
    write_files: []
    read_paths: []
    allow_network: true
    cwd_allow_hidden: [.venv]
    env_passthrough: []
    egress_rules: []
    credential_proxy: []

Le répertoire de travail est en lecture seule tant que vous ne le listez pas dans write_paths. Ainsi, un agent qui déraille ne peut pas écrire en dehors de l’espace de travail. Les dotfiles restent masqués, sauf si vous les indiquez dans cwd_allow_hidden. Une autorisation de lecture étendue n’expose donc pas implicitement .ssh ni .aws. Définissez egress_rules pour faire passer tout le trafic HTTP et HTTPS par un proxy dont la politique par défaut est deny, chaque règle étant écrite sous la forme "METHODS host/path-glob". credential_proxy va plus loin : l’agent ne détient jamais que le placeholder, et le proxy remplace celui-ci par le secret réel au moment où la requête sort. Une transcription divulguée ne contient donc aucun secret exploitable. Dans une configuration avec plusieurs harness, chaque sous-agent possède son propre bloc de sandbox dans son propre fichier de configuration sous agents/. Vous pouvez ainsi refuser le réseau au reviewer tout en le laissant accessible à l’implementer.

La documentation précise cette limite, qui est importante. La sandbox du système d’exploitation s’applique aux appels d’outils sys_os_* et aux terminaux. Elle ne couvre pas les serveurs MCP ni le processus superviseur d’Omnigent lui-même. Un serveur MCP que vous démarrez s’exécute en dehors de la sandbox avec vos permissions. Cette limite explique pourquoi le modèle le plus sûr reste une machine temporaire par agent. C’est le sujet de exécuter des agents de codage dans une VM temporaire. L’autre aspect concerne les identifiants, et empêcher un agent d’accéder aux secrets devient plus difficile, et non plus facile, lorsque six sous-agents partagent le même hôte.

Les limites de dépenses sont des policies déclarées dans le même fichier :

policies:
  budget:
    type: function
    handler: omnigent.policies.builtins.cost.cost_budget
    factory_params:
      max_cost_usd: 5.00
      ask_thresholds_usd: [1.00, 3.00]

Un run qui planifie avec un premier fournisseur, implémente avec un deuxième et effectue la revue avec un troisième dépense simultanément auprès de trois fournisseurs. Définissez donc la limite avant le premier run sans supervision, et non après la première facture. Les fonctions intégrées incluent également max_tool_calls_per_session et ask_on_os_tools, qui demandent une approbation avant les opérations sur les fichiers et le shell. Nos recommandations sur maîtriser les coûts des agents IA sur un VPS s’appliquent directement ici, et encore davantage, car les sous-agents parallèles multiplient le rythme des dépenses.

À quelle vitesse ce dépôt évolue-t-il ?

[
  {
    "version": "v0.2.0",
    "released": "2026-06-19",
    "interval": 3
  },
  {
    "version": "v0.3.0",
    "released": "2026-06-27",
    "interval": 8
  },
  {
    "version": "v0.4.0",
    "released": "2026-07-03",
    "interval": 6
  },
  {
    "version": "v0.5.0",
    "released": "2026-07-10",
    "interval": 7
  },
  {
    "version": "v0.5.1",
    "released": "2026-07-10",
    "interval": 0
  },
  {
    "version": "v0.6.0",
    "released": "2026-07-21",
    "interval": 11
  },
  {
    "version": "v0.7.0",
    "released": "2026-07-27",
    "interval": 6
  }
]

Il s’agit des dates de publication indiquées sur la page des releases du projet, consultée le 3 août 2026. 7 releases taguées ont été publiées entre 2026-06-19 et 2026-07-27, et l’intervalle le plus long entre deux releases était de 11 jours. v0.5.1 a été publiée le même jour que la release précédente. La première release, 0.1.1 du 16 juin 2026, n’apparaît pas dans le graphique, car aucun tag précédent ne permet de mesurer l’intervalle.

Deux de ces releases ont cassé des commandes déjà documentées dans des guides. v0.7.0 a supprimé omni server start au profit de omni server --background. v0.6.0 a renommé l’extra omnigent[memory] en omnigent[hindsight] ; une ligne d’installation copiée depuis un article de juin échoue donc sur un build de juillet. C’est la raison d’utiliser --version dans votre commande d’installation et un tag dans votre git clone, et non une simple préférence de style.

Ce que je ne lui confierais pas encore

En août 2026, le dépôt compte environ 8.1k stars, 1.2k forks et environ 350 issues ouvertes, alors que sa première release publique date de sept semaines. Les stars mesurent l’intérêt, pas la maturité. Le projet se présente comme alpha, et l’historique des releases ci-dessus montre qu’il faut le prendre au pied de la lettre.

• Je ne l’exécuterais pas sur un hôte qui contient des credentials de production, car le sandbox ne couvre ni les serveurs MCP ni le supervisor.
• Je ne laisserais pas une exécution sans surveillance sans définir de cost_budget, car trois vendors peuvent facturer en parallèle et rien d’autre ne les en empêche.
• Je n’exposerais pas le serveur sur une adresse IP publique sans configurer OMNIGENT_AUTH_ENABLED et placer un proxy TLS devant lui.
• Je ne considérerais pas encore le YAML de l’agent comme stable entre les versions mineures. Épinglez donc la version et lisez les release notes avant toute mise à niveau.

Autre point à connaître avant d’être surpris : v0.6.0 a ajouté une télémétrie d’utilisation anonymisée, documentée par le projet sur une page dédiée à la télémétrie. Lisez cette page et prenez votre décision en connaissance de cause si la machine traite du travail client.

Aujourd’hui, Omnigent est réellement efficace pour le cas d’usage auquel il est destiné. Vous disposez de trois ou quatre CLI d’agents, vous les payez déjà et vous voulez que l’un écrive pendant qu’un autre effectue la revue. Cela fonctionne dès maintenant, sur une seule machine, avec un sandboxing réel sous Linux. Considérez tout ce qui va au-delà comme prometteur, mais encore inachevé.

FAQ

Omnigent est-il un agent ou un outil qui exécute des agents ?

Il exécute des agents. Omnigent est un méta-harness : il démarre les CLI des fournisseurs que vous avez déjà installées, comme Claude Code, Codex ou OpenCode, attribue une tâche à chacune et supervise les résultats dans une même session. Il n’intègre aucun modèle qui lui soit propre. C’est ce qui le distingue d’un framework, dans lequel vous écrivez du Python autour d’une bibliothèque et où votre propre programme devient l’agent.

Dois-je installer Claude Code et Codex avant qu’Omnigent soit utile ?

Vous devez avoir installé et connecté au moins une CLI de fournisseur, car Omnigent pilote ces programmes au lieu de les remplacer. Pour l’exemple Polly fourni, vous devez en utiliser au moins deux provenant de fournisseurs différents. La règle de Polly est que la revue est toujours effectuée par un fournisseur différent de celui qui a réalisé l’implémentation. Avec une seule CLI disponible, aucun second fournisseur ne peut donc recevoir le diff.

Comment installer une version précise d’Omnigent au lieu de la dernière version ?

Passez --version au script d’installation avec sh -s --, comme dans sh -s -- --version 0.7.0. Sans -s --, l’option est consommée par sh lui-même et le script installe la dernière release. Si uv est déjà installé, uv tool install --force --python 3.12 "omnigent==0.7.0" effectue la même opération. Le tag git est v0.7.0, tandis que la chaîne de version PyPI est 0.7.0.

Le sandbox Omnibox est-il suffisant pour exécuter des agents sans intervention ?

Il est robuste pour ce qu’il couvre et indique clairement ce qu’il ne couvre pas. Sous Linux, il utilise bubblewrap et seccomp. Le kernel impose donc les limites d’accès aux fichiers et au réseau, et l’agent ne peut pas les désactiver. La documentation précise que cela s’applique aux appels d’outils et aux terminaux sys_os_*, mais pas aux serveurs MCP ni au processus superviseur d’Omnigent. Un serveur MCP s’exécute donc avec vos permissions habituelles. Pour les tâches sans intervention, une machine virtuelle éphémère par agent reste ainsi la solution d’isolation la plus robuste.

De quelle quantité de mémoire un serveur Omnigent a-t-il besoin sur un VPS ?

Les notes de déploiement du projet indiquent un working set d’environ 512 MB à 1 GB pour le serveur, et sa configuration Fly.io réserve 1 GB. Cela couvre uniquement le superviseur et l’interface web sur le port 6767. Chaque sous-agent est un processus distinct, avec sa propre copie de travail et son propre client de modèle. Les exécutions de type Polly utilisent également des worktrees git parallèles. Dimensionnez donc la RAM et le disque selon le nombre d’agents que vous prévoyez d’exécuter simultanément, et non selon les seuls besoins du serveur.