Omnigent : orchestrer plusieurs agent CLIs

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 que vous avez 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 même session, 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 fournisseur. Rien d’autre ne change dans votre configuration, 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 meta-harness et en quoi diffère-t-il d’un framework ?

Un harness est le programme qui place un modèle dans une boucle d’exécution. 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 et il fonctionne de manière autonome.

Un framework est une bibliothèque pour laquelle vous écrivez du code. Vous l’importez, vous définissez les étapes en Python et votre programme devient l’agent. Changer de fournisseur implique alors de modifier votre code, car le client du fournisseur est intégré à votre programme.

Un meta-harness se situe un niveau au-dessus des deux. C’est un superviseur qui exécute des harnesses comme processus enfants. Omnigent démarre le CLI du fournisseur, lui transmet le travail et lit le résultat renvoyé. Vous conservez le CLI déjà installé, ainsi que l’abonnement ou la clé API (application programming interface) qui le finance déjà. C’est toute la différence. Elle détermine le public visé par 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 ne coûte qu’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 au lieu de réécrire le code.
• La revue peut faire intervenir plusieurs fournisseurs. Un diff généré par un modèle est lu 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 central. 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. Une seule transcription couvre le travail effectué par plusieurs CLI. Vous pouvez donc relire ce qui s’est passé sans assembler quatre historiques de terminal.

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 phase alpha, ce coût est réel, et non théorique.

Où situer un orchestrateur multi-agents par rapport aux outils à 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 le cas d’un agent unique de bout en bout. C’est la configuration qu’Omnigent suppose que vous avez déjà. Le domaine plus large des agents d’IA auto-hébergés vous permet de choisir les agents eux-mêmes. Si ce vocabulaire est nouveau pour vous, commencez plutôt par comprendre le fonctionnement réel des agents.

Omnigent se situe également sur un autre axe qu’une couche de connecteurs. Les solutions permettant de donner aux agents accès à vos propres sources de données concernent 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 à la fois. Ces fonctions ne se recouvrent pas.

Ce qu’il vous faut avant l’installation

• Python 3.12 ou version ultérieure. Le package publié déclare requires-python >= 3.12.
• tmux, car les harnesses du terminal s’exécutent à l’intérieur.
• 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 inclut les assets web compilés. L’installation standard ne nécessite donc pas Node.

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 breaking changes 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 en premier 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 modèle, et le flag se répète : --extra e2b --extra kubernetes sur 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 d’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 celui-ci afin que le trafic ne quitte jamais la machine.

Un run minimal multi-agent

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 codage multi-agent fourni avec le dépôt. Sa configuration déclare des sous-agents nommés claude_code, codex, opencode, cursor, hermes et pi. Elle contient aussi une règle qui justifie à elle seule l’exécution de cet exercice : la revue est toujours effectuée par un fournisseur différent de celui qui a réalisé l’implémentation. Polly n’écrit pas de code elle-même. Elle établit le plan, divise l’objectif en tâches, délègue chacune d’elles, 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 CLIs 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 le diff. Installez-en donc au moins deux avant d’évaluer le résultat. Debby, l’autre exemple fourni, est un agent de débat à 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 il lui faut les 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 définit 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 avec type: agent et son propre exécuteur. C’est le mécanisme qui permet tout ce qui précède.

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èles proviennent de l’exemple docs/AGENT_YAML_SPEC.md du projet. Ce sont des noms de modèles hébergés par Databricks. Remplacez harness et model par les valeurs 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. Elle 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 qui leur est attribuée. Si le prompt d’un codeur lui demande de faire la modification minimale qui fonctionne, il remet à son reviewer un diff suffisamment court pour être réellement lu. Ici, ce point compte davantage que le modèle choisi pour l’un ou l’autre rôle.

Pourquoi une orchestration longue doit 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, relire, puis réviser. Fermer le capot d’un ordinateur portable arrête tout. Un VPS (serveur privé virtuel) reste disponible 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 instance est en cours d’exécution, et omnigent stop l’arrête. Dans les releases antérieures à v0.7.0, il fallait utiliser omni server start. Cette commande a été supprimée. Les anciens articles et les anciennes captures d’écran ne correspondront donc pas à ce qu’affiche votre terminal.

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 firewall est une opération classique, 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 est simplement un service supplémentaire suivant le même modèle.

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. Dans les conteneurs, OMNIGENT_AUTH_ENABLED utilise 1 par défaut. C’est le choix approprié pour tout service accessible depuis l’extérieur.

Concernant le dimensionnement, les notes de déploiement évaluent l’ensemble de travail du serveur entre 512 MB et 1 GB. La configuration Fly.io fixe cette valeur à 1 GB. Cette estimation concerne uniquement le supervisor. 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 du nombre d’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 en cours depuis un autre appareil.

Isolez chaque sous-agent avant de vous en désintéresser

Omnigent fournit un sandbox au niveau du système d’exploitation, appelé Omnibox. Sous Linux, il utilise des namespaces bubblewrap et seccomp. La limite est donc appliquée par le kernel, et non par le prompt de l’agent. Un agent auquel une injection de prompt a été soumise ne peut pas contourner une règle du kernel en la reformulant. 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 jusqu’à ce que vous le listiez dans write_paths. Ainsi, un agent défaillant ne peut pas écrire en dehors du workspace. 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 en deny par défaut, chaque règle étant écrite sous la forme "METHODS host/path-glob". credential_proxy va plus loin : l’agent ne détient jamais que placeholder, et le proxy le remplace par le secret réel au moment où la requête sort. Une transcription divulguée ne contient ainsi 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/. Un reviewer peut donc être privé du réseau tandis que l’implementer le conserve.

La limite est indiquée dans la documentation, et elle est importante. Le sandbox du système d’exploitation s’applique aux appels d’outils sys_os_* et aux terminaux. Il ne couvre pas les serveurs MCP ni le processus supervisor d’Omnigent lui-même. Un serveur MCP que vous avez démarré s’exécute en dehors du sandbox avec vos permissions. C’est pourquoi le modèle le plus sûr reste une machine temporaire par agent. C’est le sujet de exécuter des coding agents dans une VM temporaire. L’autre partie du problème concerne les credentials. garder les secrets hors de portée d’un agent devient plus difficile, et non plus facile, lorsque six sous-agents partagent le même hôte.

Les limites de dépense 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]

Une exécution qui planifie avec un fournisseur, implémente avec un deuxième et effectue la review avec un troisième dépense simultanément à trois endroits. Définissez donc le plafond avant la première exécution sans supervision, et non après la première facture. Les fonctions intégrées comprennent é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 notes sur maîtriser les coûts des agents IA sur un VPS s’appliquent directement ici, et encore davantage, car des sous-agents parallèles multiplient le burn rate.

À 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
  }
]

Voici les dates de publication indiquées sur la page des releases du projet, relevées 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 est sortie le même jour que la release précédente. La première release, 0.1.1, publiée le 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 à quoi je ne ferais pas encore confiance

En août 2026, le dépôt compte environ 8.1k stars, 1.2k forks et près de 350 issues ouvertes, alors que la 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 prendre cette mention au sérieux.

• 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 policy, 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 TLS devant.
• Je ne considérerais pas encore le fichier YAML de l’agent comme stable entre les versions mineures. Épinglez donc la version et lisez les release notes avant toute mise à niveau.

Voici un autre point à connaître avant d’être pris au dépourvu : 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 des travaux clients.

Aujourd’hui, Omnigent est réellement bon dans le domaine pour lequel il a été conçu. Vous avez trois ou quatre agent CLIs, vous les payez déjà et vous voulez que l’un écrive pendant qu’un autre relit. Cela fonctionne maintenant, sur une seule machine, avec un véritable sandboxing 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 meta-harness : il démarre les vendor CLIs que vous avez déjà installés, comme Claude Code, Codex ou OpenCode, attribue une tâche à chacun 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 avec 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 authentifié au moins un vendor CLI, car Omnigent pilote ces programmes au lieu de les remplacer. Pour l’exemple Polly fourni, vous devez en utiliser au moins deux provenant de vendors différents. La règle de Polly veut que la revue soit toujours effectuée par un vendor différent de celui qui a réalisé l’implémentation. Avec un seul CLI présent, aucun second vendor ne peut donc recevoir le diff.

Comment installer une version précise d’Omnigent plutôt que la dernière version ?

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

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

Il est efficace dans son périmètre et explicite sur ce qu’il ne couvre pas. Sous Linux, il utilise bubblewrap et seccomp. Le kernel impose donc les limites concernant les fichiers et le réseau, et l’agent ne peut pas les désactiver. La documentation indique que cela s’applique aux appels d’outils sys_os_* et aux terminaux, mais pas aux serveurs MCP ni au processus supervisor 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 offre toujours une isolation plus forte.

De combien 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 fixe cette valeur à 1 GB. Cela couvre uniquement le supervisor et l’interface web sur le port 6767. Chaque sub-agent est un processus distinct avec sa propre working copy et son propre model client. Les exécutions de type Polly utilisent également des git worktrees 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.