Un agent découvre en cours de route qu’il lui manque un outil : une recherche dans une base, un accès à un dépôt, un convertisseur de fichiers. Le développeur l’ajoute à la liste, relance la requête, et la facture de tokens (les unités de texte que traite le modèle) repart presque de zéro. Anthropic corrige ce travers avec addTools(), une méthode arrivée dans la version 0.128.0 de son SDK (kit de développement logiciel) TypeScript, publiée en même temps que Claude Opus 5.5.
Qu’une modification aussi anodine ait coûté aussi cher tient à l’ordre dans lequel une requête est lue. Cet ordre décide d’une bonne part du coût d’un agent, et il se conçoit dès la première ligne de code.
Un outil de plus, et tout le contexte à relire
Le cache de prompt évite au modèle de retraiter ce qu’il a déjà vu. Quand deux requêtes successives commencent par la même séquence de tokens, cette partie commune, le préfixe, est reprise telle quelle : moins de calcul, une latence plus faible, une facture allégée. Dans une boucle d’agent, où chaque tour renvoie tout l’historique de la conversation, ce mécanisme porte l’essentiel des économies.
La contrainte vient de la correspondance exacte. Le cache ne reconnaît un préfixe que s’il est identique depuis le tout premier token. Or les définitions d’outils, le tableau tools[] de l’API (interface de programmation), sont placées au début de ce préfixe, avant le prompt système et les messages.
Toucher à tools[], même pour y glisser une seule entrée, modifie donc le tout début de la requête. Tout ce qui suit (instructions, échanges, résultats d’outils accumulés) ne correspond plus. Le cache miss est complet : le modèle relit l’intégralité du contexte comme s’il le découvrait.
Le sommaire et l’addendum
Imaginez un lecteur qui a parcouru un rapport de deux cents pages et en garde tout en mémoire, à une condition : que le document n’ait pas bougé depuis sa première ligne. Ajouter un chapitre au sommaire, placé en ouverture, l’oblige à tout reprendre depuis le début. Agrafer un addendum à la fin ne lui coûte que la lecture de l’addendum.
addTools() procède comme l’addendum. Au lieu de réécrire le tableau tools[], la méthode le laisse intact et insère, à la suite de la conversation existante, un message système contenant un bloc tool_addition. Le préfixe reste identique jusqu’à ce point, et seule la partie ajoutée doit être traitée. Côté agent, l’ajout comme le retrait d’un outil est immédiat.
Un écart qui se creuse à chaque tour
Pour chiffrer le gain, un script Node reproductible a comparé le JSON des requêtes successives dans les deux scénarios. Avec addTools(), la requête suivante partage jusqu’à 98,7 % de son préfixe avec la précédente. Après une modification directe de tools[], la part réutilisable tombe quasiment à zéro.
L’écart grandit avec la longueur de la conversation. Plus l’historique s’allonge, plus la relecture forcée est lourde, et moins l’addendum pèse en face. Sur un agent qui travaille depuis des dizaines de tours, un outil ajouté au mauvais endroit revient à payer une seconde fois toute la session.
Encore faut-il lire correctement cette mesure. Ces 98,7 % décrivent la part commune du JSON de requête, donc ce que le cache peut théoriquement reprendre. Ils ne disent pas combien de tokens seront facturés au tarif réduit sur un cas réel : cela dépend des points de cache posés, de leur durée de vie et du modèle utilisé.
Un header à déclarer soi-même, et quelques angles morts
La fonctionnalité reste en bêta. Elle exige le header ou paramètre inline-tools-2026-09-15, que le runner du SDK n’ajoute pas de lui-même. Il faut donc le déclarer explicitement, et seuls les modèles compatibles en profitent.
D’autres limites subsistent. Certaines tiennent au modèle lui-même, et un cas particulier provoque toujours un cache miss complet : mieux vaut le repérer dans la documentation avant de bâtir une architecture sur cette méthode. Autre subtilité, une pause dans l’exécution retarde la prise en compte des changements d’outils côté cache, alors que l’agent, lui, voit l’ajout ou le retrait immédiatement. Ce décalage risque de dérouter au moment de déboguer une boucle longue.
Ce qui change souvent passe en queue de requête
Cette version rappelle une règle que beaucoup d’équipes découvrent sur leur facture : le coût d’un agent dépend autant de l’ordre des tokens que de leur nombre. Deux agents aux fonctionnalités identiques peuvent afficher des coûts très éloignés, selon que ce qui change souvent se trouve en tête ou en queue de requête. OpenAI, dont le cache repose lui aussi sur un préfixe exact, a pris le problème par l’autre bout : son paramètre allowed_tools restreint les outils utilisables à un tour donné sans toucher au tableau d’outils, à condition de tout déclarer dès le départ.
L’architecture gagne donc à séparer ce qui est stable de ce qui bouge. Le socle d’outils, le prompt système et les consignes durables forment un préfixe qu’on ne touche plus ; les outils découverts en route, les documents récupérés et les résultats intermédiaires s’ajoutent derrière. Charger d’emblée des dizaines d’outils « au cas où », ou reconstruire la liste à chaque tour, deviennent sous cet angle deux réflexes coûteux.
Pour un projet en cours, trois gestes suffisent : conserver le tableau tools[] initial, passer par addTools() pour les ajouts, activer le header bêta sur les modèles qui le supportent. Le chantier suivant concerne les frameworks d’agents, dont beaucoup réassemblent encore la requête entière à chaque tour sans tenir compte de ce que le cache a déjà en mémoire. Ceux-là devront revoir leur plomberie pour que leurs utilisateurs profitent de la méthode.
Sources
Ils m’ont fait confiance
« Il ne se contente pas de corriger les symptômes, il cherche à comprendre l'origine des problèmes et à sécuriser les modifications effectuées. J'ai réellement le sentiment d'avoir trouvé un développeur qui comprend à la fois la technique et les enjeux globaux du projet. »
Évaluation client · projet WordPress · septembre 2026
5,0/5 sur 17 évaluations
Faire appel à mes services →
