A lightweight way to make agents talk without paying for API usage

À propos de A lightweight way to make agents talk without paying for API usage

L’article « A lightweight way to make agents talk without paying for API usage » (publié sur juanpabloaj.com) ne décrit pas un produit commercial classique, mais plutôt un pattern d’orchestration légère permettant à plusieurs agents d’intelligence artificielle déjà existants de collaborer sans engendrer de coûts supplémentaires d’API. L’auteur propose une approche pratique pour faire dialoguer des outils comme Claude, Codex ou Gemini en exploitant leurs clients en ligne de commande (CLI) et leurs mécanismes de session persistante. L’idée centrale est de capitaliser sur les abonnements ou les offres gratuites déjà souscrits, afin d’éviter de payer des requêtes API additionnelles pour la coordination multi‑agents.

Cette méthode se destine aux développeurs et aux utilisateurs techniques qui souhaitent mettre en place des workflows agentiques simples, sans infrastructure lourde ni framework propriétaire. Le concept repose sur une orchestration par ligne de commande avec reprise de contexte, ce qui permet aux agents de conserver l’historique de leurs échanges d’une étape à l’autre. L’article insiste sur la légèreté et la simplicité de mise en œuvre, limitant le besoin à un terminal et à quelques scripts.

Fonctionnalités principales

Bien qu’il ne s’agisse pas d’un outil clé en main, le pattern décrit s’appuie sur plusieurs fonctionnalités distinctes.

Orchestration multi‑agents légère.
Un agent (l’orchestrateur) produit ou révise un brouillon, puis invoque un autre agent, par exemple via :

• codex exec resume --last "prompt"
• gemini -r latest -p "prompt"

L’agent sollicité critique ou améliore le contenu, et l’orchestrateur décide de la suite. Les agents itèrent jusqu’à l’obtention d’un résultat jugé satisfaisant.

Invocation via CLI avec reprise de session.
La commande resume (ou son équivalent) est essentielle : elle permet de reprendre la dernière session plutôt que d’en démarrer une nouvelle. Cela garantit que le contexte de la conversation est préservé d’un appel à l’autre, sans coût API additionnel puisque l’agent utilise sa propre gestion de contexte interne.

Deux modes d’utilisation.

• Mode non‑interactif (automatisation) : les appels CLI s’enchaînent dans des scripts, sans interface graphique.
• Mode tmux : l’utilisateur garde plusieurs agents visibles dans des fenêtres ou panneaux distincts, ce qui facilite le suivi et le débogage des échanges.

Collaboration entre agents de différents fournisseurs.
L’auteur mentionne explicitement la possibilité de faire travailler ensemble Claude, Codex, Gemini, etc., à condition que chacun dispose d’un client CLI avec gestion de sessions. Aucun connecteur propriétaire n’est nécessaire ; on réutilise les outils déjà installés et configurés.

Aucune nouvelle API propriétaire.
Le pattern n’introduit pas de couche intermédiaire payante. Il exploite uniquement les mécanismes existants des agents (abonnements, tiers gratuits) et l’infrastructure locale (terminal, tmux, scripts).

Tarification

Il n’existe pas de plan tarifaire formel associé à ce pattern. Le coût réel dépend entièrement des outils que l’utilisateur a déjà souscrits ou utilise gratuitement. Par exemple :

• Un abonnement à un agent de codage comme Claude Code ou Codex est facturé environ 20 $ US par mois, soit ≈ 27 $ CA/mois.
• L’accès à Gemini via son offre gratuite peut ne rien coûter, mais avec des quotas et des limites de fair‑use.
• L’infrastructure locale (terminal, tmux, scripts) n’engendre aucun frais supplémentaire.

L’intérêt principal de cette approche est d’éviter des frais d’API additionnels pour la collaboration multi‑agents. L’utilisateur paie déjà pour ses agents ; il n’a pas de surcoût pour les faire dialoguer, puisque les échanges sont réalisés dans le cadre des sessions déjà incluses dans l’abonnement ou le niveau gratuit. Aucun plan « Free », « Pro » ou « Enterprise » n’est proposé par l’auteur, car il ne s’agit pas d’un service commercial.

Cas d’utilisation

Relecture et amélioration de code.
Un agent (par exemple Codex) génère ou modifie du code. Il appelle un autre agent (Gemini) qui critique le code, propose des améliorations ou exécute des tests. L’orchestrateur intègre les retours et relance le cycle. Ce scénario convient au pair‑programming multi‑agents, au refactoring et aux revues automatisées.

Rédaction et révision de texte.
Le premier agent produit un brouillon (documentation technique, spécification, courriel complexe). Un second agent effectue une critique ciblée sur la clarté, le style ou la cohérence. Les itérations successives permettent d’obtenir un texte de haute qualité sans intervention humaine.

Workflows de recherche et de brainstorming.
Un agent collecte de l’information ; un autre structure ou synthétise ; un troisième vérifie la robustesse des arguments. L’orchestrateur combine les résultats pour livrer une réponse finale. Ce mode est utile pour la veille, l’analyse ou la génération d’idées.

Petits workflows multi‑agents sans infrastructure lourde.
L’auteur souligne que ce pattern est parfait pour des expérimentations ou des automatisations ponctuelles, là où des frameworks complexes seraient disproportionnés.

Notre avis

Forces.
Le principal avantage est la réduction significative des coûts : on évite de payer des requêtes API supplémentaires en réutilisant les sessions déjà incluses dans les abonnements ou les offres gratuites. La légèreté de l’orchestration est également un atout : pas besoin d’un serveur distant, d’un framework lourd ou d’une infrastructure cloud. La mise en œuvre est rapide pour toute personne à l’aise avec la ligne de commande et le concept de session persistante. L’indépendance vis-à-vis des fournisseurs permet de combiner plusieurs outils sans crainte de verrouillage.

Faiblesses et limites.
L’approche n’est pas clé en main. Il faut maîtriser la CLI, tmux et le scripting. La fiabilité dépend du bon fonctionnement des clients existants : si un fournisseur modifie ses options de session (ex. resume), le workflow peut casser. La traçabilité des échanges est moins structurée qu’avec un orchestrateur dédié (logs, dashboards). La sécurité et la conformité (gestion des secrets, données sensibles) incombent entièrement à l’utilisateur. Enfin, le pattern est conçu pour des petits workflows ; au‑delà de quelques agents, la coordination via CLI et tmux devient difficile à maintenir.

Public cible.
Ce pattern s’adresse avant tout aux développeurs et aux utilisateurs techniques (devops, data scientists) qui utilisent déjà des coding agents et souhaitent les faire collaborer sans multiplier les abonnements ni payer d’API. Il convient aussi aux petites équipes, aux indépendants et aux laboratoires qui veulent prototyper à moindre coût.

Recommandation.
Pour un développeur déjà équipé de Claude Code, Codex ou Gemini, cette méthode est efficace et économique : elle permet de réaliser des workflows multi‑agents en quelques minutes, sans infrastructure supplémentaire. En revanche, si vous recherchez une solution plus industrialisée ou une interface graphique, orientez‑vous vers des frameworks comme OpenAI Agents SDK, Swarm ou des stacks locales (Ollama + LangChain), quitte à payer des coûts API ou à investir dans du matériel local. Dans tous les cas, le pattern présenté dans l’article constitue une excellente base pour comprendre les mécanismes de collaboration entre agents et pour démarrer sans frais.