Vos agents IA brûlent 85 % de tokens en trop : le tuto PTC

Le mois dernier j'ai laissé tourner un agent d'analyse documentaire sur une pile de contrats clients. Douze outils branchés, une boucle par document, un modèle correct. À la fin de la semaine, la facture API m'a fait tousser : l'agent rapatriait dans son contexte l'intégralité des résultats intermédiaires — 200 Ko de données brutes pour en garder 1 Ko d'utile. Je payais trois fois le transport pour livrer une enveloppe.

La réponse tient dans deux mots que Anthropic et OpenAI ont poussés à quelques semaines d'écart : programmatic tool calling (PTC). L'idée est bête et redoutable. Au lieu de faire un aller-retour modèle pour chaque appel d'outil, le modèle écrit du code qui orchestre vos outils dans un bac à sable. Seul le résultat final remonte dans le contexte facturé. Le reste vit et meurt dans le sandbox.

Voici comment je l'ai branché, côté Claude et côté GPT-5.6, avec les chiffres que j'ai constatés et l'endroit précis où j'ai galéré.

Pourquoi vos agents IA paient trois fois pour rien

Le tool calling classique fonctionne en tour par tour. Le modèle demande un outil, votre code l'exécute, le résultat revient dans le contexte du modèle, le modèle repart. Chaque résultat intermédiaire est facturé en tokens d'entrée au tour suivant. Tant que vous appelez deux ou trois outils, personne ne le sent.

Le problème arrive avec les boucles. Reprenez mon agent : cinq étapes, chacune enroulant une boucle de dix appels. Ça fait cinquante invocations modèle facturées, et à chaque tour on recharge tout l'historique. OpenAI le résume sans détour dans sa doc : « un agent à cinq étapes où chaque étape enroule une boucle de dix appels, c'est cinquante invocations facturées ». Le coût ne monte pas linéairement, il compose.

Sur mes contrats, la mécanique était limpide : l'agent tirait le texte complet de chaque document, le réinjectait pour comparer, puis recommençait. 90 % des tokens payés servaient à trimballer de la donnée que le modèle n'avait pas besoin de lire — juste de traiter.

Programmatic tool calling : ce que le sandbox change vraiment

Avec le PTC, on inverse la charge. Le modèle génère du code (Python chez Anthropic, JavaScript chez OpenAI) qui appelle vos outils, enchaîne les boucles, filtre, agrège — le tout dans un environnement d'exécution isolé. Les résultats des appels ne rentrent jamais dans le contexte du modèle. Seule la sortie finale du code y revient.

Concrètement, sur mon cas d'analyse budgétaire de test : 200 Ko de données brutes réduites à 1 Ko de résultat avant de toucher le modèle. Le filtrage, l'addition, le tri se passent dans le code, là où ça ne consomme pas un token de modèle.

Activer le PTC sur Claude : beta header et code_execution

Côté Anthropic, trois éléments à poser. Le beta header, l'outil de code execution, et le marquage des outils autorisés à être appelés depuis le code.

Le squelette d'appel ressemble à ça :

[[terminal:client.beta.messages.create( betas=["advanced-tool-use-2025-11-20"], model="claude-sonnet-4-5-20250929", max_tokens=4096, tools=[ {"type": "code_execution_20250825", "name": "code_execution"}, { "name": "get_budget", "description": "...", "input_schema": {...}, "allowed_callers": ["code_execution_20250825"] } ] )]]

Les trois points à ne pas rater :

• betas=["advanced-tool-use-2025-11-20"] — sans ce header, l'API ignore le PTC et retombe en tool calling classique. J'ai perdu vingt minutes là-dessus, persuadé que ça ne marchait pas alors que je payais plein pot en silence.
• L'outil code_execution (type code_execution_20250825) doit être présent dans la liste des tools. C'est lui le runtime.
• allowed_callers sur chaque outil que vous voulez rendre appelable depuis le code. Un outil sans ce champ reste en mode classique — utile quand vous voulez qu'une action sensible passe par une validation modèle.

Ensuite, Claude génère du Python qui enchaîne les appels, souvent en parallèle via asyncio.gather. Vous ne l'écrivez pas : vous le récupérez, il s'exécute, vous encaissez le résultat filtré.

Combien coûte le PTC sur Claude en pratique

Les chiffres publiés par Anthropic, croisés avec ce que j'ai mesuré : sur un agent de gestion de projet à 75 outils, 38 % de tokens d'entrée facturés en moins, à précision de tâche identique. Sur des tâches de recherche complexes, la conso moyenne tombe de 43 588 à 27 297 tokens, soit 37 %. Et le cas extrême cité dans le cookbook : 110 473 tokens en classique contre 15 919 en PTC, à nombre d'appels API égal — 85,6 % d'économie. Bonus non négligeable, la précision grimpe aussi sur certains benchmarks (récupération de connaissances de 25,6 à 28,5 %), parce que le modèle n'est plus noyé sous du contexte parasite.

GPT-5.6 côté OpenAI : du JavaScript dans un V8 isolé

OpenAI a livré la même logique avec GPT-5.6 (Sol, Terra, Luna), passé en disponibilité générale le 9 juillet 2026. La différence : le modèle écrit du JavaScript exécuté dans un sandbox V8 sans accès réseau. Vos outils déclarés restent le seul chemin vers l'extérieur, donc la surface de sécurité ne bouge pas.

Ça passe par la Responses API. Le modèle compose loops, conditionnels et agrégation, et là où un enchaînement de 12 appels séquentiels demandait 12 cycles de réponse facturés, il tient désormais en un seul. OpenAI annonce des réductions de tokens de 38 % à 63,5 % sur ses clients nommés — Clio cite 38 % sur de l'analyse documentaire multi-étapes, sans perte de qualité.

Ce qui a coincé chez moi

Deux frustrations honnêtes, parce que le tuto parfait n'existe pas.

Le debug devient opaque. Quand le modèle orchestre lui-même dans le sandbox, vous ne voyez plus chaque appel défiler. Sur mon premier run, une requête sur trois échouait silencieusement à cause d'un mauvais typage de date, et le code avalait l'exception. En tool calling classique, je l'aurais vu au premier tour. Ma parade : logguer côté outil (pas côté modèle) et faire remonter les compteurs d'erreurs dans la sortie finale.

Le gain n'est pas systématique. Sur un agent à trois outils qui fait deux appels, le PTC n'apporte rien — parfois il coûte un chouïa plus cher à cause du runtime de code. Le seuil de rentabilité, d'après mes tests, c'est autour de 8-10 outils ou dès qu'il y a une boucle qui rapatrie de gros volumes. En dessous, restez en classique.

Autrement dit : le PTC n'est pas un interrupteur magique à activer partout. C'est une optimisation pour les agents qui brassent du volume. Sur les autres, vous complexifiez pour rien.

Par où commencer sans tout casser

Ma recette pour migrer un agent existant sans repartir de zéro :

• Repérez l'agent le plus cher du mois. Regardez sa conso de tokens d'entrée, pas de sortie — c'est là que le PTC frappe.
• Vérifiez qu'il boucle sur des outils ou agrège de gros résultats. Si oui, candidat parfait.
• Ajoutez le beta header et l'outil code_execution (Claude), ou basculez sur la Responses API en mode programmatique (GPT-5.6).
• Marquez d'abord UN outil en allowed_callers, mesurez, puis étendez. Pas de big bang.
• Comparez la facture sur 100 exécutions avant/après. Le chiffre parle mieux que la doc.

Si vous pilotez déjà vos automatisations via un orchestrateur type n8n, la logique se combine : le PTC réduit le coût par exécution, l'orchestrateur gère le déclenchement. J'en ai détaillé le câblage dans notre tuto MCP + n8n.

Pour tester le PTC sans écrire une ligne d'infra, le plus rapide reste de partir d'un compte développeur Claude et de reprendre le cookbook officiel — c'est là que j'ai décollé le plus vite.

Le verdict après trois semaines

Sur mon agent contrats, la facture d'entrée a fondu de 41 % en gardant la même qualité de sortie. Pas de magie, juste le refus de payer pour transporter de la donnée que le modèle n'a pas à lire. Pour une PME qui fait tourner deux ou trois agents multi-outils en production, on parle de centaines d'euros par mois récupérés sans toucher au résultat métier.

Le prix à payer : un debug moins lisible et une exigence accrue sur la qualité de vos schémas d'outils. Pour un agent à trois outils qui tourne dix fois par jour, ça n'en vaut pas la peine. Pour un agent qui brasse des dizaines d'appels par run, c'est le premier levier à activer avant même de penser à changer de modèle.