Omnigent est un meta-harness open source pour piloter plusieurs agents IA depuis une couche commune. Mon verdict court : l’idée est solide et utile pour des équipes DevOps ou sécu qui jonglent déjà avec Claude Code, Codex et des agents maison, mais le produit reste en alpha et demande encore de la patience.
J’ai installé le dépôt, configuré un proxy OpenAI local, lancé un vrai prompt via le harness OpenAI Agents, puis tenté un cas plus ambitieux avec accès fichiers. Résultat : Omnigent produit bien une réponse exploitable, sa configuration fournisseur est claire, mais le chemin outillé a cassé sur un problème de protocole tool-call.
Omnigent, c’est quoi ?
Omnigent se présente comme une couche d’orchestration au-dessus de plusieurs runtimes d’agents : Claude Code, Codex, Cursor, OpenCode, Hermes, Pi, Qwen, Goose et des agents déclarés en YAML.
L’intérêt n’est pas de remplacer ces outils. L’intérêt est de les faire entrer dans un cadre commun :
- même commande pour lancer un agent,
- choix de harness et de modèle séparé du prompt,
- serveur local pour suivre les sessions,
- agents déclaratifs en YAML,
- politiques de contrôle pour limiter les actions risquées,
- possibilité de travailler depuis le terminal, le navigateur ou une app desktop.
Dans une équipe qui teste plusieurs agents, c’est typiquement le genre de brique qui évite de refaire toute l’intégration à chaque changement de fournisseur.
| Point testé | Observation |
|---|---|
| Langage principal | Python 3.12+, avec une UI web Node/Vite |
| Installation source | Réussie en mode API seulement |
| Harness testé | openai-agents |
| Proxy LLM | OpenAI compatible local |
| Cas réussi | Génération d’un plan d’audit DevOps en français |
| Cas limité | Agent avec outils fichiers bloqué par une erreur tool-call |
Installation de Omnigent
Le README propose une installation simple avec un script shell ou via uv. Dans mon conteneur, les prérequis n’étaient pas parfaits : Python système en 3.11, Node en 20, pas de tmux, pas de bwrap. Omnigent demande Python 3.12 et recommande Node 22 pour construire l’UI.
J’ai donc utilisé uv pour tirer Python 3.12, puis j’ai installé le dépôt en editable. Le build complet de l’UI web a échoué à cause de l’environnement : Node trop ancien, manque de place pendant l’installation npm, puis erreur d’exécution de tsc. Le projet prévoit ce cas avec une variable pour installer sans UI web, ce qui m’a permis de continuer en mode API et CLI.
Les commandes importantes de mon test :
git clone https://github.com/omnigent-ai/omnigent /tmp/omnigent
export OPENAI_BASE_URL=http://172.17.0.1:8790/v1
export OPENAI_API_KEY=sk-proxy
export OPENAI_API_BASE=http://172.17.0.1:8790/v1
export OPENROUTER_BASE_URL=http://172.17.0.1:8790/v1
export OPENROUTER_API_KEY=sk-proxy
export OMNIGENT_SKIP_WEB_UI=true
uv run --python 3.12 --with-editable . omnigent --help
Ensuite, j’ai créé une configuration isolée avec un provider gateway local : base URL du proxy, clé factice, modèle openai/gpt-4o-mini, API en mode chat.
Omnigent à l’usage
Mon premier test concret était volontairement simple, mais pas vide : demander à Omnigent de lancer le harness OpenAI Agents et de produire un mini plan d’audit DevOps pour un dépôt Python.
Commande utilisée :
omnigent run --harness openai-agents --model openai/gpt-4o-mini --no-log -p "Crée un mini plan d'audit DevOps en 5 points pour un dépôt Python, avec un exemple de commande shell inoffensive. Réponds en français et termine par le mot FIN."
Ce que j’ai observé : Omnigent démarre son serveur local, prépare l’agent, se connecte, lance le harness, puis imprime la réponse. La sortie contenait bien un plan en 5 points, avec dépendances, analyse statique, tests, CI/CD, logs, et le mot final demandé.
Ce n’est pas juste un binaire qui affiche une aide. Il y a bien un aller-retour LLM via la configuration proxy, piloté par le runtime Omnigent.
J’ai ensuite tenté un cas plus réaliste : un mini dépôt Python avec requirements.txt, une app Flask et un workflow GitHub Actions. L’objectif était de faire inspecter le dossier par un agent YAML avec os_env, puis de lui faire écrire audit_report.md.
Là, le run a échoué. L’agent a commencé, mais le proxy a renvoyé une erreur : un message assistant avec tool_calls n’était pas suivi des messages outil correspondants. En clair, le chemin avec outils fichiers n’a pas abouti dans cette combinaison Omnigent, OpenAI Agents SDK, gateway chat et proxy.
Ce que j’aime dans Omnigent
Le premier bon point, c’est la séparation nette entre agent, harness et provider. Dans beaucoup de stacks IA, le prompt finit collé au fournisseur, au modèle et à la façon d’exécuter les outils. Omnigent essaie de découpler tout ça.
J’aime aussi le format YAML pour décrire un agent. On peut exprimer le rôle, le harness, les outils, les sous-agents et le sandboxing sans écrire une application complète. Pour un freelance sécu ou DevOps, c’est pratique : un agent d’audit, un agent de doc, un agent de revue peuvent devenir des artefacts versionnés.
Autre point positif : le projet pense déjà aux garde-fous. Le README parle de politiques pour demander validation avant certaines actions, bloquer des commandes dangereuses ou limiter le coût. C’est exactement le genre de détail qui manque quand on passe du prototype IA à un usage opérationnel.
Enfin, la CLI donne une impression de produit ambitieux : run, server, host, attach, resume, wrappers pour plusieurs agents, configuration des credentials. On voit une vraie vision de plateforme, pas seulement une lib Python.
Les limites de Omnigent
La première limite est l’installation. Dans un environnement minimal, le build web peut vite coincer. Le mode API seulement m’a sauvé le test, mais un utilisateur grand public qui suit juste le README risque de tomber sur Node 22, npm, espace disque, tmux ou bwrap.
La deuxième limite est la maturité. Le projet annonce lui-même un statut alpha. Mon test avec outils fichiers n’a pas produit le rapport attendu. Ce n’est pas forcément un bug unique d’Omnigent, car le gateway et l’API chat entrent aussi dans l’équation, mais pour l’utilisateur final le résultat est simple : le scénario outillé n’a pas marché.
La troisième limite est la densité conceptuelle. Omnigent parle de harness, provider, family, server local, runner, agent YAML, native wrappers, policies, sandboxes. Pour une équipe d’ingénieurs, c’est cohérent. Pour un non spécialiste, il faudra une couche de documentation très guidée.
J’ai aussi noté que certains tests du dépôt demandent des dépendances de dev non installées par défaut. En ajoutant pytest, j’ai pu lancer un test ciblé sur le listing de modèles OpenAI compatible, et il est passé.
Est-ce que Omnigent marche vraiment ?
Oui, pour le chemin simple testé : installation source en mode API, configuration gateway, lancement d’un agent OpenAI Agents, réponse LLM concrète.
Non, pas encore de façon lisse pour le chemin outillé que j’espérais valider. L’agent déclaratif avec accès au dossier n’a pas écrit son rapport à cause d’une erreur de protocole autour des tool calls. Je préfère le dire clairement : je ne vendrais pas aujourd’hui Omnigent comme une solution prête à opérer sans supervision.
En revanche, je ne jetterais pas le projet. La structure est sérieuse, les abstractions sont pertinentes et le fait que le cas LLM simple fonctionne déjà via un proxy local est encourageant.
Faut-il adopter Omnigent ?
Mon verdict : à essayer, pas encore à adopter en production sans filet.
Omnigent est utile si vous êtes dans un de ces cas :
- vous comparez plusieurs agents de code,
- vous voulez versionner des agents YAML,
- vous avez besoin de policies et de sandboxing autour de vos agents,
- vous construisez une plateforme interne d’orchestration,
- vous acceptez de debugger une stack alpha.
Je le déconseille si vous cherchez un outil simple pour discuter avec un LLM, ou si votre besoin principal est une UI web prête à l’emploi sur n’importe quel poste. Là, le rapport complexité bénéfice n’est pas encore favorable.
Comme freelance sécu/DevOps, je garderais Omnigent dans ma veille active. Pas comme brique stable à mettre demain chez un client, plutôt comme projet à surveiller pour industrialiser des agents spécialisés.
FAQ
Omnigent remplace-t-il Claude Code ou Codex ?
Non. Omnigent sert plutôt de couche de pilotage au-dessus de ces outils. L’objectif est de changer ou combiner les harnesses sans réécrire toute l’orchestration.
Peut-on utiliser Omnigent avec OpenRouter ou un proxy local ?
Oui, c’est prévu via les providers gateway. Dans mon test, un proxy OpenAI compatible local a suffi pour faire produire une réponse au harness OpenAI Agents.
Omnigent est-il prêt pour la production ?
Pas à mon avis. Le projet est en alpha, l’installation dépend fortement de l’environnement, et mon scénario avec outils fichiers a échoué. Pour un lab ou une équipe très technique, il mérite clairement un essai.