Pi vs. Claude Code : deux frameworks d'agents à l'épreuve de l'exploitation

Pi vs. Claude Code : deux frameworks d'agents à l'épreuve de l'exploitation

TL;DR : Pi et Claude Code ne se disputent pas la même place. Ce sont deux architectures : une boucle d'agent fine et agnostique du modèle contre un système d'agent intégré. Nous ne les avons pas comparés sur une liste de fonctionnalités mais dans notre propre exploitation : sur les 30 derniers jours, nous avons exécuté 3041 tâches cron avec un taux de réussite de 87 pour cent, 393 exécutions en échec et une durée médiane de 149 secondes. Ces chiffres montrent où une stack d'agents casse en production continue et ce que coûte réellement une boucle fine par rapport à un harnais lourd.

Les frameworks d'agents se vendent d'habitude comme des listes de fonctionnalités : qui a le plus d'outils, qui est le plus autonome, qui a la plus belle intégration IDE. Cette liste ne répond pas à la question qui compte en exploitation : que devient la stack quand elle tourne 24h/24, traite des milliers de tâches et finit par produire des erreurs que plus personne ne voit ?

C'est exactement ce que nous avons mesuré. Nous exploitons un parc d'agents sur OpenClaw avec 84 tâches cron configurées, dont 51 actives, toutes sur le modèle gx10/qwen3.8-flash-next-nvfp4. Les 30 derniers jours de cette exploitation constituent notre base de données, et ils permettent un regard sur les deux classes de frameworks qui ne vient pas de slides marketing.

Ce que sont réellement les deux frameworks

Pi est un agent de codage minimal : quatre outils (read, write, edit, bash) dans une boucle serrée, agnostique du modèle, relié au modèle de votre choix par une simple configuration. La philosophie : l'agent est un outil que le développeur contrôle entièrement. Pas de dashboard, pas de verrouillage fournisseur, pas de modèle propriétaire imposé.

Claude Code, c'est l'inverse : un agent intégré qui assume une grande partie de l'orchestration. Revues, permissions, limites de coûts, frontières de confiance multi-agents : tout est intégré et préconfiguré. La question n'est pas de savoir ce que l'agent sait faire, mais combien il vous épargne.

Les deux approches sont souvent racontées comme une rivalité pour la même place. Elles ne le sont pas. Ce sont deux réponses à deux questions : voulez-vous garder le contrôle de l'agent ou voulez-vous qu'il vous décharge ? Nos données d'exploitation permettent de répondre avec des chiffres plutôt qu'avec des opinions.

Notre mesure

Le tableau suivant vient de notre propre exploitation. Nous lisons ~/.openclaw/cron/jobs.json (read-only), ~/.openclaw/cron/runs/*.jsonl et ~/.openclaw/healer-metrics.sqlite, évalués le 19/10/2026 à 10h00 CEST.

Trois observations pertinentes pour la comparaison :

Le taux d'erreur baisse, mais pas jusqu'à zéro. 393 exécutions en échec sur 30 jours, soit environ 13 par jour. Les classes d'erreur les plus fréquentes : FallbackSummaryError (70), Agent couldn't generate a response (61), litellm.APIConnectionError (55) et FailoverError (49). Des thèmes d'exploitation classiques : logique de fallback, erreurs de connexion, cascades de failover. Exactement les erreurs dont une boucle fine ne vous protège pas et qu'un harnais lourd prend en charge en partie.

L'auto-healer est obligatoire, pas optionnel. Sur 30 jours : 365 erreurs de classe PATTERN, 268 FATAL, 56 CLUSTER, 55 TIMEOUT. L'healer a déclenché 206 redémarrages, émis 56 avis de cluster, appliqué 27 extensions de délai. 29 interventions réussies ou appliquées. Sans cette automatique, le taux de réussite serait nettement plus bas.

Les tâches diminuent, elles ne s'améliorent pas. 3533 exécutions avant, 3041 maintenant. La baisse correspond à la consolidation et à la désactivation de tâches (51 actives sur 84). Une stack fine demande plus de soin actif par tâche ; une stack lourde gère plus de tâches mais avec plus de surcoût par exécution.

Là où une boucle fine casse en exploitation

Un agent minimal comme Pi a un avantage imbattable : vous voyez tout. Chaque lecture, chaque écriture, chaque appel bash est traçable. Le prix : tout ce qui dépasse la boucle nue, vous devez le construire ou l'exploiter vous-même.

Notre stack le montre dans les classes d'erreur. FallbackSummaryError et FailoverError sont les symptômes d'une chaîne de failover que nous avons construite nous-mêmes. litellm.APIConnectionError montre la fragilité de la couche de connexion quand on l'assemble soi-même. Ce ne sont pas des problèmes propres à Pi, c'est le coût du contrôle : qui construit la stack la répare aussi.

L'auto-healer est notre réponse. 365 erreurs PATTERN sur 30 jours, détectées et en grande partie corrigées automatiquement, seraient du travail manuel dans une configuration minimale. Les 268 erreurs FATAL seraient des escalades vers l'équipe. Les 206 redémarrages automatiques auraient été lancés à la main.

Là où un harnais lourd produit du surcoût

De l'autre côté, le modèle intégré. Claude Code et ses cousins apportent orchestration, revues et permissions. Le prix, c'est le prompt système : d'après les signalements, les prompts système des grands agents de codage pèsent 7000 à 10000 tokens avant la première requête. Ce coût revient à chaque appel API, ce n'est pas une dépense unique.

Dans notre exploitation, la différence se voit dans la durée médiane : 149 secondes par exécution. Une partie est du surcoût pur : des appels au modèle qui ne servent qu'à maintenir le contexte de l'agent, décrire les outils, résumer l'historique. Une boucle fine à quatre outils a moins de contexte à entretenir et moins de moyens de se perdre elle-même.

Le compromis est honnête : le harnais lourd gère plus de tâches en parallèle et décharge l'équipe. La boucle fine est plus rapide par exécution mais demande plus de soin. Nos chiffres suggèrent que l'effort doit porter sur le soin à mesure que le nombre de tâches grandit.

Ce que nous en tirons pour le choix

Choisir entre Pi et Claude Code n'est pas une déclaration d'amour à un framework. C'est une question de modèle d'exploitation :

• Vous voulez le contrôle et la portabilité : prenez l'agent fin. Vous apportez votre propre modèle, vous voyez chaque étape, la stack vous appartient. Le prix : failover, logique de retry et monitoring sont à construire. Notre auto-healer est exactement cet investissement.
• Vous voulez du débit et de la commodité : prenez l'agent intégré. Orchestration, revues et permissions sont intégrées, l'agent gère plus de tâches en parallèle. Le prix : surcoût de tokens à chaque appel et moins de granularité dans le débogage.

Un nombre croissant d'équipes fera les deux : l'agent fin pour les charges sensibles ou critiques pour les coûts, l'intégré pour le reste. La vraie compétence n'est pas la fidélité à un framework mais de savoir quelle tâche va dans quelle stack.

Questions fréquentes

Quelle est la différence pratique entre Pi et Claude Code ?

Pi est une boucle d'agent minimale à quatre outils que vous contrôlez entièrement et que vous reliez au modèle de votre choix. Claude Code est un agent intégré qui apporte orchestration, revues et permissions et prend en charge davantage de travail. En exploitation, la différence se voit dans les classes d'erreur et le surcoût, pas dans la liste des fonctionnalités.

Que coûtent réellement les prompts système des grands agents de codage ?

D'après les signalements, 7000 à 10000 tokens avant la première requête. Ce coût n'est pas unique : il revient à chaque appel API et réduit le contexte disponible. Une boucle fine comme Pi réduit ce surcoût au minimum.

À quoi ressemble la réalité des erreurs d'une exploitation d'agents ?

Dans notre stack : 3041 exécutions en 30 jours, 393 échecs, classes principales FallbackSummaryError, erreurs de connexion et problèmes de failover. Une exploitation sans auto-healing ni monitoring produit ces erreurs invisiblement. Le taux de réussite est de 87 pour cent, pas de 100.

Faut-il un auto-healer pour une stack d'agents fine ?

Si la stack tourne jour et nuit : oui. Nous avons eu 365 erreurs PATTERN, 268 erreurs FATAL et 55 timeouts en 30 jours, détectés automatiquement par l'healer. 206 redémarrages déclenchés. Sans cette automatique, cela aurait été du travail manuel ou de l'indisponibilité.

Quand est-ce que faire tourner les deux framework en parallèle a du sens ?

Quand des charges de travail différentes ont des exigences différentes : tâches sensibles ou critiques pour les coûts sur l'agent fin, tâches à haute fréquence ou orchestrées sur l'intégré. La décision se prend par tâche, pas par équipe. Nos données d'exploitation suggèrent que la forme mixte est plus fréquente que la forme pure.

Sources

1. earendil-works/pi, dépôt GitHub : https://github.com/earendil-works/pi
2. Site officiel de Pi : https://pi.dev
3. Owain Lewis, Is Pi better than Claude Code? : https://newsletter.owainlewis.com/p/is-pi-better-than-claude-code
4. Pawel Jozefiak, AI coding harness agents 2026 : https://thoughts.jock.pl/p/ai-coding-harness-agents-2026
5. byteiota, Pi coding agent minimal harness : https://byteiota.com/pi-coding-agent-minimal-harness
6. MCPlato, Pi Hermes Codex Claude Code : https://mcplato.com/en/blog/pi-agent-hermes-codex-claude-code-mcplato
7. Données d'exploitation propres : ~/.openclaw/cron/jobs.json, ~/.openclaw/cron/runs/*.jsonl, ~/.openclaw/healer-metrics.sqlite, évaluées le 19/10/2026 à 10h00 CEST.