Claude Code envoie 33 000 tokens avant même de lire le prompt, OpenCode 7 000

• En mesurant à la frontière de l’API avec le même modèle, la même machine et la même tâche, le surcoût fixe de la première requête avec Sonnet 4.5 était d’environ 32 800 tokens pour Claude Code contre environ 6 900 pour OpenCode, soit un écart de 4,7×, réduit à environ 3,3× avec Fable 5
• La majeure partie de l’écart vient des schémas d’outils. Claude Code consommait environ 24 000 tokens pour 27 définitions d’outils, OpenCode environ 4 800 tokens pour 10 outils ; même en désactivant tous les outils, les prompts système représentaient respectivement environ 6 500 et 2 000 tokens
• En configuration réelle, un fichier d’instructions de 72 Ko ajoute environ 20 000 tokens à chaque requête, et un petit serveur MCP environ 1 000 à 1 400 tokens, si bien que la seule première requête peut atteindre 75 000 à 90 817 tokens
• Sur une même tâche de résumé de fichier, Claude Code a généré 5,9 à 54× plus d’écritures de cache qu’OpenCode ; lorsque la tâche a été répartie entre deux sous-agents, l’usage est passé de 121 000 tokens en exécution directe à 513 000 tokens, soit 4,2× plus
• Le surcoût fixe ne suffit pas à juger le coût total. Sur une tâche multi-étapes, Claude Code a regroupé les appels d’outils en parallèle et utilisé environ 121 000 tokens en 3 requêtes, tandis qu’OpenCode a utilisé environ 132 000 tokens avec 9 appels en série

---

Méthode de mesure à la frontière de l’API

• Un proxy de journalisation a été placé entre Claude Code et OpenCode afin d’enregistrer les requêtes JSON exactes envoyées par le harnais et les blocs d’usage renvoyés par l’API
  • Le corps de requête contenait les blocs système, les schémas d’outils et les messages
  • L’usage incluait les tokens d’entrée, les écritures et lectures de cache, ainsi que les tokens de sortie
  • Les corps de requête capturés ont servi de contenu effectivement envoyé, et les blocs d’usage de l’API de base pour la facturation réelle
• La comparaison de base utilise Claude Code 2.1.207 et OpenCode 1.17.18, tous deux fixés sur claude-sonnet-4-5 en juillet 2026
  • Une partie des mesures de surcoût fixe, d’opérations de cache et de tâches multi-étapes a été relancée avec claude-fable-5
  • Les valeurs par défaut ont été isolées avec un nouveau répertoire de configuration, sans serveur MCP, sans paramètres utilisateur ni mémoire, et dans un espace de travail vide sans fichier d’instructions
• Trois tâches ont permis de mesurer différentes structures de coût
  • T1 isolait le surcoût fixe avec Reply with exactly: OK, exécuté 3 fois par harnais
  • T2 demandait de lire et résumer un fichier préparé à l’avance
  • T3 exécutait une procédure d’écriture, exécution, test et correction sur FizzBuzz et un script de vérification
• Pour comparer les prompts système hors schémas d’outils, --tools "" a été appliqué à Claude Code et "tools": {"*": false} à OpenCode
• La passerelle LLM locale ajoutait à chaque requête une enveloppe fixe d’environ 6 200 tokens, qui a été corrigée puis exclue des mesures instrumentées
  • Les chiffres par composant ont été calculés à partir des corps de requête capturés, que la passerelle ne pouvait pas modifier
  • Pour convertir caractères et tokens, un ratio mesuré en cache froid de 1 token pour 4,1 à 4,4 caractères selon le harnais a été utilisé

Des schémas d’outils qui gonflent le surcoût de base

• Lors de la première requête du prompt T1 de 22 caractères, Claude Code a envoyé environ 32 800 tokens, OpenCode environ 6 900
  • Le prompt système de Claude Code comportait 3 blocs et 27 344 caractères, celui d’OpenCode 1 bloc et 9 324 caractères
  • Les 27 schémas d’outils de Claude Code totalisaient 99 778 caractères, contre 20 856 caractères pour les 10 outils d’OpenCode
  • Claude Code insérait avant le prompt réel un bloc <system-reminder> de 7 997 caractères contenant le type d’agent, les compétences disponibles et le contexte utilisateur
  • OpenCode envoyait le bloc système, 10 outils de codage et le prompt utilisateur, sans échafaudage séparé pour le premier message
• Dans les deux cas, les définitions d’outils constituent la part la plus importante
  • Sur les quelque 33 000 tokens de Claude Code, environ 24 000 correspondaient aux définitions d’outils
  • Sur les quelque 6 900 tokens d’OpenCode, environ 4 800 correspondaient aux définitions d’outils
  • Les outils de Claude Code incluent non seulement des fonctions de codage, mais aussi des fonctions d’agent en arrière-plan et d’orchestration comme CronCreate, Monitor, la famille Task, la gestion d’arbres de tâches et les notifications push
• En retirant tous les outils, le prompt système de Claude Code fait 26 891 caractères, soit environ 6 500 tokens, et celui d’OpenCode 8 811 caractères, soit environ 2 000 tokens
  • Dans les deux harnais, le prompt se réduit légèrement lorsque les outils sont désactivés
  • L’écart restant vient des consignes de comportement : ton, directives de sécurité, règles de gestion des tâches, informations d’environnement, etc.
• Avec Fable 5, Claude Code réduit son prompt selon le modèle, ce qui ramène l’écart à environ 3,3×
  • Les instructions système passent de 27 787 caractères avec Sonnet à 10 526 avec Fable
  • En conservant les mêmes 27 outils, les schémas passent aussi de 99 778 à 82 283 caractères
  • Les requêtes d’OpenCode étaient identiques au byte près entre les deux modèles

Un usage total qui varie selon la forme de la tâche

• Dans T2, qui consistait à lire et résumer un fichier, les deux harnais ont produit un résultat exact, mais avec une structure de requêtes différente
  • Claude Code a utilisé 6 requêtes HTTP et environ 199 000 tokens d’entrée cumulés
  • OpenCode a utilisé 4 requêtes et environ 41 000 tokens, avec un appel Haiku supplémentaire pour générer le titre de session
  • L’essentiel de l’usage provenait des lectures de cache, facturées à un dixième du prix des entrées
• Même avec la remise du cache, l’écriture de cache de la première requête, les lectures de cache à chaque tour et l’occupation de la fenêtre de contexte augmentent avec la taille de la charge utile
  • La base de 33 000 tokens occupe déjà environ un sixième d’une fenêtre de 200 000 tokens avant même l’arrivée du code
• Dans T3, une tâche d’écriture, exécution, test et correction, le mode d’appel des outils compense l’écart de surcoût de base
  • Claude Code a regroupé 2 écritures de fichiers et 2 exécutions de scripts dans un seul aller-retour d’outils en parallèle, pour 3 requêtes modèle et environ 121 000 tokens d’entrée cumulés
  • OpenCode n’a appelé qu’un outil par tour, pour 9 requêtes, 1 appel de titre et environ 132 000 tokens d’entrée cumulés
  • L’entrée totale est grosso modo déterminée par le produit entre la base par requête et le nombre de requêtes, auquel s’ajoute l’accroissement de la conversation
• À mesure que la conversation avançait, Claude Code a augmenté les blocs <system-reminder>, passant de 3 au premier tour à 4 au moment du premier aller-retour d’outils
• La charge utile ajoutée par tour dans OpenCode était d’environ 400 à 2 200 caractères, correspondant uniquement à la croissance du contenu de conversation

Les tokens ajoutés par une configuration réelle

• L’ajout d’un AGENTS.md de 72 Ko issu d’un dépôt de production a augmenté les requêtes de plus de 20 000 tokens dans les deux harnais
  • La mesure OpenCode est passée de 13 152 à 33 336 tokens
  • Claude Code est passé de 39 005 à 59 243 tokens
  • Claude Code 2.1.207 ignorait AGENTS.md ; il fallait le renommer en CLAUDE.md pour qu’il soit inséré dans le premier message utilisateur
  • OpenCode lisait les deux noms de fichier et les insérait dans le prompt système
  • Sans vérifier le nom de fichier réellement reconnu par le harnais, un fichier d’instructions peut être ignoré silencieusement
• Un petit serveur MCP public ajoute environ 1 000 à 1 400 tokens par serveur et par requête
  • 5 serveurs ajoutaient 4 900 tokens à la charge utile de Claude Code et 6 967 tokens à la mesure d’OpenCode
  • Le nombre d’outils passait de 27 à 69 dans Claude Code, et de 10 à 52 dans OpenCode
  • Des serveurs de production avec des API riches peuvent envoyer des schémas encore plus volumineux
  • Le mode print de Claude Code ignorait silencieusement le .mcp.json au niveau projet en l’absence de --mcp-config explicite ; il faut donc vérifier la connexion à la frontière de l’API
• Les frameworks de workflow narratif comme BMAD développent via des commandes slash de gros modèles contenant personas, protocoles et checklists
  • Le modèle de 8 405 caractères de l’expérience représente lui-même environ 2 100 tokens, mais il entre dans l’historique de conversation et est donc renvoyé à chaque requête suivante
  • Dans une session de 9 requêtes, le même modèle est embarqué 9 fois ; le coût augmente donc comme taille du modèle × nombre de requêtes
• La première requête d’une configuration réelle était bien plus grosse que le surcoût de base
  • OpenCode, avec 11 serveurs MCP pour e-mail et calendrier, gestion de tâches, gestion bibliographique, analyse produit, etc., ainsi qu’un fichier d’instructions de 72 Ko, a enregistré 179 outils, 277 Ko de schémas et une écriture de cache froid de 90 817 tokens
  • Claude Code, avec 4 serveurs MCP, des plugins installés et le même fichier d’instructions, a enregistré 118 outils, une charge utile de 311 Ko et environ 75 000 tokens
  • Hors enveloppe de passerelle, la configuration OpenCode représentait environ 12× la valeur par défaut d’environ 7 000 tokens

Le coût des sous-agents et du raisonnement étendu

• Lorsque Claude Code a réparti la tâche en parallèle entre deux sous-agents, les 121 000 tokens de l’exécution directe sont passés à 513 000 tokens, soit 4,2× plus
  • Au total, 9 requêtes modèle ont été émises à travers trois types de requêtes : session principale, appels de sous-agents, etc.
  • Les 5 appels de sous-agents s’amorçaient chacun avec leur propre prompt système de 3 554 caractères et 24 des 27 outils de base
  • Chaque sous-agent paie son coût initial, puis le parent relit son historique d’exécution
• Les sous-agents d’OpenCode envoient un profil réduit, avec un prompt système de 1 379 caractères et seulement 5 outils
  • L’exécution via la passerelle ne s’étant pas terminée correctement, l’usage total des sous-agents d’OpenCode n’a pas été quantifié
  • Seule la différence de conception observée dans les charges utiles capturées est comparée
• La sortie de raisonnement étendu est facturée au tarif de sortie, soit 5× le tarif d’entrée, et les blocs de raisonnement sont inclus dans l’historique de conversation puis renvoyés dans les requêtes suivantes
  • En raison de la politique de raisonnement propre à la passerelle, il n’a pas été possible de vérifier que les réglages des deux harnais étaient réellement appliqués ; les chiffres mesurés ne sont donc pas publiés
  • Seule la structure de coût liée à l’entrée des blocs de raisonnement dans l’historique est conservée comme constat

Économie et stabilité du cache de prompt

• Les deux harnais définissent correctement les points de rupture de cache. La charge utile est écrite une fois à 1,25× le prix d’entrée de base avec un TTL de 5 minutes, puis lue ensuite à un dixième du prix
• Trois coûts ne sont pas réduits par le cache
  • Après une pause de plus de 5 minutes, toute la pile doit être réécrite ; les coûts d’écriture réapparaissent donc après une réunion ou un repas
  • Les lectures de cache se répètent autant de fois qu’il y a de requêtes ; les boucles d’outils en série et la répartition entre sous-agents augmentent donc le coût
  • L’occupation de la fenêtre de contexte n’est pas affectée par la remise de cache : un amorçage de 85 000 tokens occupe plus de 40 % d’une fenêtre de 200 000 tokens, et lorsque la compression démarre, des coûts de résumé s’ajoutent
• OpenCode a conservé un préfixe identique au byte près dans toutes les requêtes et exécutions capturées
  • Sur les trois sessions T1, les bytes des outils, du système et des messages étaient identiques, et les réexécutions n’ont provoqué aucune écriture de cache
  • La session T3 de 9 requêtes a elle aussi conservé un seul préfixe stable
• Claude Code crée selon les sessions différents types de requêtes et d’entrées de cache : exploration de préchauffage, conversation principale, appels de sous-agents
  • Même dans le même espace de travail, les bytes système et l’échafaudage du premier message variaient selon les exécutions
  • Sur la même tâche de résumé de fichier, il a écrit 53 839 tokens de cache sur 5 requêtes et réécrit une fois en cours de tâche l’intégralité d’un préfixe d’environ 43 000 tokens
  • L’écriture de cache d’OpenCode sur la même tâche était de 1 003 tokens
• Les grandes réécritures intermédiaires de cache de Claude Code se sont aussi observées dans les expériences répétées
  • Lors des deux premières exécutions, il a réécrit respectivement 43 342 et 36 899 tokens ; lors de la troisième, avec un cache nouvellement préchauffé, il n’a presque rien écrit
  • Avec Fable 5 également, il a réécrit 50 053 tokens sans lecture de cache, créant un écart de 52×, proche des 54× observés avec Sonnet
  • Selon la température du cache, les écritures de cache de Claude Code représentaient 5,9 à 54× celles d’OpenCode
  • Le tarif d’écriture de cache est de 1,25× le prix de base dans le palier 5 minutes et de 2× dans le palier 1 heure
• Un seul cache miss peut venir d’une éviction par la passerelle, mais le phénomène s’est reproduit sur plusieurs exécutions et l’instabilité du préfixe a aussi été constatée dans les bytes capturés avant requête
  • Quand les préfixes sont gros, nombreux, réécrits de manière répétée et auxquels s’ajoutent des sous-agents, le compteur d’usage de Claude Code peut augmenter plus vite

Qualité des résultats et journaux d’audit

• Les deux harnais ont correctement terminé toutes les tâches évaluées
  • Les résultats de résumé de fichier étaient exacts dans tous les cas
  • Les tâches multi-étapes ont passé le script de validation écrit par chaque harnais et se sont terminées normalement
  • Dans ce périmètre, il était possible de comparer le coût en tokens nécessaire pour obtenir le même résultat
• L’étude ne mesure pas si, sur des tâches d’ingénierie réelles plus difficiles, les agents d’arrière-plan, compétences et capacités d’orchestration de Claude Code améliorent la qualité à hauteur de leur coût supplémentaire
  • Pour en juger, il faudrait séparément une suite de tests adaptée, suffisamment d’exécutions répétées et une évaluation du taux de réussite
• Des gaspillages sans rapport avec la qualité ont aussi été observés
  • Réécrire au milieu d’une session un préfixe de cache identique au byte près revient à racheter le même contenu au prix premium
  • Si un harnais ignore silencieusement un fichier d’instructions, aucun bénéfice ne peut être tiré de ce fichier
• Les 185 enregistrements de requêtes et réponses capturés ont été inscrits dans une chaîne de hachage SHA-256 avec la bibliothèque open source @systima/aiact-audit-log
  • La chaîne a été vérifiée de bout en bout sans rupture, avec un résultat d’intégrité VALID
  • La même structure permet de reconstruire les contenus envoyés et reçus, et de fournir à des tiers des éléments d’intégrité
  • C’est le même mode de journalisation structurée que celui fourni pour l’article 12 de l’EU AI Act

Limites de la mesure et méthode de reproduction

• Les résultats sont un instantané de juillet 2026 sur une seule machine, deux versions de harnais et un petit échantillon
  • T1 et T2 ont été exécutées 3 fois chacune, et chaque condition multiplicatrice de configuration 1 fois
  • Les valeurs par défaut et les conditions de cache utilisent Sonnet 4.5 et Fable 5, tandis que les conditions multiplicatrices de configuration n’utilisent qu’un seul modèle
  • Les prompts des harnais changent souvent ; la méthode de mesure à la frontière de l’API survivra plus longtemps que les chiffres individuels
• Une passerelle locale se trouvait sur le chemin de mesure
  • Les chiffres par composant utilisent les corps de requête, que la passerelle ne pouvait pas modifier
  • Les valeurs instrumentées ont été corrigées de l’enveloppe fixe à partir d’un point de référence en cache froid, et les chiffres d’exécutions chaudes dont la cause ne pouvait pas être séparée ont été exclus
  • Comme il est arrivé que la passerelle remplace silencieusement le modèle fixé par un instantané plus récent, le modèle ayant réellement répondu doit lui aussi être vérifié à la frontière
  • Sur le chemin Fable, une reprise d’ancienne session serveur et une exécution d’outils côté hôte ont eu lieu, ce qui a conduit à exclure les résultats multi-étapes de Claude Code avec Fable
• La convergence de coût dans T3 vient d’une seule observation sur un type de tâche donné
  • Pour les tâches nécessitant une exécution séquentielle, le nombre de requêtes et l’usage total de Claude Code peuvent à nouveau augmenter
  • Les conditions de suppression d’outils et de sous-agents d’OpenCode ont reçu de la passerelle un flux invalide ; seule la taille des charges utiles capturées a donc été utilisée
  • Les chiffres de configuration réelle correspondent aux réglages d’un utilisateur et peuvent varier dans d’autres environnements
• Le dispositif de reproduction est un proxy HTTP d’environ 200 lignes de Node
  • Il transmet les requêtes à l’endpoint du modèle tout en enregistrant sur disque, et dans la chaîne d’audit, le corps de requête et les blocs d’usage de réponse
  • Il faut définir ANTHROPIC_BASE_URL vers le proxy, mesurer les valeurs par défaut avec un nouveau répertoire de configuration et un espace de travail vide, puis ajouter un par un le fichier d’instructions, les serveurs MCP et les workflows
  • Si une passerelle est utilisée, il faut d’abord mesurer son enveloppe propre avec une requête minimale et vérifier quel modèle répond réellement
  • En journalisant à la frontière de l’API ce qu’un agent de production a exactement envoyé au modèle à un instant donné, on obtient aussi la comptabilité des tokens

[GN⁺]

Avis sur Hacker News

• Ce qui brûle vraiment énormément de tokens, ce sont les sous-agents. J’ai confié une grosse tâche à Claude Code et il a immédiatement lancé 7 sous-agents, puis a épuisé le budget avant qu’un seul ne termine. Même chose en réessayant 5 heures plus tard.
  Quand on fait exécuter la même tâche séquentiellement par l’agent principal, il n’y a aucun problème. Je ne sais pas si c’est aussi inefficace à cause des coûts de communication et de coordination, ou si Anthropic cherche à augmenter son chiffre d’affaires parce que les utilisateurs de sous-agents sont généralement sur des comptes de grandes entreprises et paient au token.

  • À l’inverse, dans la phase d’exploration et de planification d’un projet complexe, le comportement curieux de Fable peut être exactement ce qu’il faut. Si l’agent de coordination ne se contente pas de découper le prompt en plusieurs angles d’exploration, mais que chaque sous-agent explore la base de code selon cet angle et développe récursivement les nouveaux indices, il est logique d’utiliser Fable à chaque étape.
    En revanche, s’il s’agit d’appliquer en parallèle une tâche bien planifiée à plusieurs cibles, il faut indiquer explicitement aux sous-agents de descendre d’un cran vers un modèle moins curieux. La cohérence des livrables peut aussi s’en trouver améliorée.
  • Chaque sous-agent doit relire une partie de la base de code pour obtenir le contexte nécessaire à sa tâche. Si la tâche dure longtemps, le contexte de l’agent de coordination disparaît aussi du cache, et il faut repayer le coût complet une fois les sous-agents terminés.
    En exécution séquentielle, les fichiers ne sont lus qu’environ une fois chacun, et toutes les requêtes exploitent le même cache de préfixe.
  • Si les clients choisissent une offre plus chère pour contourner le problème, l’entreprise a une incitation négative à le corriger. Même s’il existe quelques ingénieurs ayant une solution, ils peuvent se heurter à l’indifférence du plus grand nombre, à l’obstruction de certains, et parfois à une hostilité active quelque part dans la hiérarchie.
    Dans ce type d’environnement, la meilleure stratégie peut être d’ajouter d’abord les nouvelles fonctionnalités à l’offre la plus chère pour amortir les coûts, puis de les faire descendre vers les offres inférieures, ou de retirer l’échelle derrière soi pour rendre la concurrence difficile.
  • Chaque sous-agent reçoit le même prompt système d’environ 30 000 tokens. Avec Fable/Opus, 7 agents peuvent facilement consommer 30 % de la limite d’utilisation sur 5 heures avant même de commencer à travailler.
  • Depuis que j’ai compris cette astuce, j’interdis explicitement les sous-agents Fable. Hier, après un gros refactoring, j’ai d’abord demandé un plan de revue pour examiner du code complexe ; à la première étape, il a proposé 8 agents Fable et 1 agent pour valider les résultats, ce que j’ai approuvé.
    Mais à l’étape de validation, il voulait lancer 41 agents de validation Fable. Il trouve toujours un détour.

• Je pense que Claude Code consomme beaucoup de tokens parce qu’Anthropic veut gagner plus d’argent et pousser les utilisateurs vers l’abonnement. La politique qui empêche d’utiliser les droits d’abonnement dans d’autres agents de codage va dans ce sens. Moi, j’utilise pi.

  • Une fois qu’on voit Anthropic comme un vendeur de tokens, beaucoup de décisions commencent à s’expliquer. Tant que les utilisateurs ne protestent pas ou ne demandent pas de garde-fous, ils continueront à créer des raisons de consommer davantage de tokens via leurs propres canaux.
  • D’après des documents liés à l’introduction en Bourse, j’ai vu que les revenus d’abonnement seraient très faibles, autour de 5 %. Cela dit, ces 5 % correspondent aux abonnements Claude individuels, et la plupart des abonnements Claude Code sont probablement comptés dans la partie entreprise.
    L’API et l’enterprise représentent 75 à 85 % du chiffre d’affaires total, les abonnements d’entreprise environ 10 à 15 %, et les abonnements individuels environ 5 %.
  • C’est plutôt l’argument inverse. Les abonnés paient un forfait mensuel fixe, donc Anthropic a intérêt à ce que Claude Code utilise moins de tokens.
  • En revanche, ce comportement augmente aussi la consommation de tokens des abonnés ordinaires inclus dans les offres forfaitaires. Cela ressemble moins à de la malveillance qu’à de l’incompétence.

• Comme dans l’analogie pertinente de PUSH_AX, c’est comme si l’entrepreneur A demandait 33 000 dollars et B 7 000 dollars : il faut se demander si nous mesurons bien la bonne chose.
  En conséquence, l’article ajoutera des tâches plus approfondies, une comparaison qualitative des résultats et, autant que possible, des données d’entrée/sortie rapidement reproductibles.

  • Je me demande quelle part des 33 000 tokens correspond à des données de contexte, comme les conversations récentes.

• Le problème ne vient pas seulement des gros prompts système. Les environnements d’exécution des agents de codage utilisent aussi les outils plus agressivement, même pour des demandes triviales. Dans les tests, des prompts comme « Hey » ou « commit » ont parfois déclenché plus de 30 appels d’outils.
  https://quesma.com/blog/the-true-cost-of-saying-hi-to-an-ai-...
  On observe réellement une inflation des tokens, où le nombre de tokens consommés par des tâches simples ne cesse d’augmenter.

  • C’est agaçant quand Opus corrige une faute de frappe dans un commentaire puis lance tout ce qu’il peut exécuter, tests, lint, etc. Il lui arrive même de mettre d’abord les changements actuels de côté pour vérifier préventivement si tous les tests passaient déjà.
    C’est aussi de ma faute, puisque mes règles disent de valider tous les changements par des tests, mais si l’on insiste autant sur le I de IA, on finit par attendre un minimum de jugement, du genre ne pas mettre de tomates dans une salade de fruits.
  • Avec des prompts ambigus comme « Hey » ou « commit », il fouille l’historique de conversation et d’autres contextes pour deviner la tâche souhaitée, ce qui augmente les appels d’outils. Un prompt plus clair est préférable.
  • Pour un commit, on ne peut pas simplement le faire soi-même au lieu de le confier à un LLM ?

• Après 6 mois avec Claude, je suis récemment passé à Codex. Codex est plus ouvert, il est plus facile de suivre le travail du modèle, et l’expérience utilisateur du flux d’approbation est meilleure. Globalement, la transparence est meilleure, et le coût de migration a été presque nul.
  Je n’aime pas le fait que Claude soit devenu plus opaque depuis autour de février, y compris pour le prompt système, et 33 000 tokens me paraît excessif.

  • Pour l’instant, j’utilise les deux, et en pratique ils sont presque interchangeables. J’apprécie aussi que Codex soit open source et qu’OpenAI indique explicitement qu’on peut utiliser les droits d’abonnement dans d’autres agents.
    Récemment, OpenAI est devenu beaucoup plus favorable aux consommateurs.
  • Je serais curieux de savoir quels réglages tu as essayés depuis que c’est devenu plus opaque. Il y a maintenant beaucoup plus d’options de configuration.

• L’agent pi a un prompt système plus court, et son contenu complet est consultable ici
  https://github.com/earendil-works/pi/blob/main/packages%2Fco...

  • C’est peut-être lié à ce minimalisme, mais Pi n’a pas la plupart des outils nécessaires pour qu’un LLM fonctionne de manière efficace et pertinente. Je comprends la philosophie consistant à partir d’une page blanche et à ajouter ce qu’on veut, mais selon mes critères c’est beaucoup trop vide
  • Je me demande si définir la date et cmd à chaque appel du prompt système invalide le cache
    Si l’invalidation ne se produit que lorsque la date ou le répertoire racine change, en pratique cela reste suffisamment rare
  • Si vous avez besoin d’un agent minimal à personnaliser fortement, mieux vaut le créer vous-même plutôt que de tirer plus de 130 dépendances transitives avec le package pi-coder « minimal ». Ce n’est pas difficile, on apprend beaucoup, et on peut demander de l’aide à un autre LLM pour démarrer

• Au final, ce qui compte n’est pas la taille brute du prompt. Sinon, Pi et ses variantes devraient avoir les coûts les plus bas. Le point clé, c’est l’efficacité du prompt, et minimalisme du prompt et efficacité sont souvent confondus. Cela dit, Claude Code paraît tout de même lourd pour ce qu’il fait
  Plus important encore : la qualité des outils. Des outils mauvais ou bogués augmentent fortement les allers-retours, annulant tous les gains que l’on voulait obtenir au départ
  Il y a quelques mois, j’ai fait un benchmark complet de 7 agents sur 8 tâches, avec les données et les traces disponibles sur https://github.com/dirac-run/dirac. Comme je suis directement lié à l’un d’eux, je ne peux pas prétendre être neutre, mais les éléments sont reproductibles. La plupart des tâches portant sur du refactoring, Dirac, qui se distingue par l’ancrage par hachage et l’analyse de l’arbre syntaxique abstrait, l’a largement emporté

  • Il y a beaucoup de concurrents et la compétition est très intense, donc s’il existe une marge d’amélioration, quelqu’un la réalisera, et elle a ensuite de fortes chances de se diffuser rapidement aux autres produits

• Au travail, on m’oblige à utiliser Claude Code, mais avec --system-prompt "" le problème se règle facilement. J’aimerais qu’ils autorisent aussi d’autres environnements d’exécution

  • Si on le vide avec --system-prompt "", est-ce qu’on ne supprime pas même le prompt système de base qui permet au modèle de comprendre les outils disponibles ?
  • Je l’utilise comme ça depuis longtemps, et je ne comprends pas pourquoi tout le monde ne le fait pas
  • Je ne connaissais pas cette option. J’aimerais voir une analyse de l’efficacité réelle avant/après son activation, ou des graphiques de performance en conditions d’usage réelles
  • Je me demande si Claude est lancé avec cette option, ou si elle est transmise à chaque envoi de prompt

• Quand j’ai commencé à expérimenter avec des modèles locaux, je les ai connectés à Claude Code et ça fonctionnait très bien, mais c’était lent
  Avec l’aide de Claude, j’ai configuré mitmproxy et capturé l’intégralité du premier prompt système de Claude Code ; après vérification, il faisait 162 Ko de JSON. C’est ce qui m’a poussé à expérimenter Pi, OpenCode et Hermes

  • Aujourd’hui, si on lance /context dans une nouvelle session Claude Code, il n’utilise que 23 000 tokens sur le contexte d’un million de tokens d’Opus 4.8. L’affichage indique : prompt système 3,9k, outils système 13,9k, agents personnalisés 235, fichier mémoire 28, fonctionnalités 4,9k, messages 8, tampon de compression 3k tokens
    Un prompt système de 4 000 tokens représente environ 15 à 20 Ko. J’aurais envie de te demander de mettre ce que tu as capturé dans un Gist, mais il pourrait contenir des données sensibles, et il est très probable que les 162 Ko visibles ne soient pas uniquement le prompt système

• Ce que j’ai créé en envoie moins : https://maki.sh

  • Il paraît que lorsque le contexte devient trop long, maki supprime les images et les blocs de raisonnement, puis compresse automatiquement l’historique en résumant les conversations précédentes
    Mais le résumé des conversations précédentes n’invalide-t-il pas en pratique le cache de contexte, de sorte qu’on utilise certes moins de tokens, mais des tokens plus chers ?