Résumé technique : La réduction de jetons n'est pas une réduction de coût

Énoncé du problème

Les agents de codage basés sur des API (par exemple, Claude Code, SWE-agent) fonctionnent en invoquant de manière itérative des outils et en réinjectant le texte résultant dans un grand modèle de langage (LLM). Ce processus crée une fenêtre de contexte en croissance constante. Pour gérer les coûts, l'industrie a développé des « couches de réduction de contexte » telles que des compresseurs de sortie de commande, des classificateurs de recherche (rankers) et des proxys de bordure d'API.

La métrique industrielle prédominante pour évaluer ces couches est la réduction de jetons (par exemple, ratios de compression, jetons supprimés). Ce document soutient que la réduction de jetons est un indicateur incomplet et souvent trompeur de la métrique qui importe réellement aux praticiens : le coût facturé par le fournisseur par tâche accomplie avec succès. Les auteurs postulent que la réduction du contexte ne réduit pas linéairement le coût en raison de trois mécanismes :

1. Économie de cache : Les fournisseurs modernes facturent le contexte mis en cache à des tarifs nettement réduits. Supprimer du texte d'un prompt qui est déjà mis en cache (ou qui le sera) économise bien moins que ce que suggère le nombre brut de jetons.
2. Boucles de rétroaction de trajectoire : Si la compression supprime un contexte dont le modèle aura besoin plus tard, l'agent peut initier des tours de diagnostic supplémentaires, relisant des fichiers ou effectuant de nouvelles recherches. Ces tours additionnels retransmettent l'intégralité du préfixe de contexte, annulant les économies initiales.
3. Corruption en aval : La compression peut corrompre des formats de données requis par des consommateurs non-modèles (par exemple, des pipelines shell attendant une sortie grep brute), entraînant des échecs silencieux ou des réponses incorrectes.

Méthodologie

L'étude est fondée sur une campagne appariée, avec un hachage figé, de 2 908 exécutions facturées par le fournisseur (2 848 analysées) à travers 103 tâches, 7 dépôts et 3 modèles (Claude Haiku 4.5, Sonnet 5, Opus 4.8). La dépense totale mesurée était d'environ 643 $, avec 8 263 évaluations de composants à coût d'inférence nul supplémentaires.

Conception expérimentale

• Bras : L'étude a comparé une base de référence (sans compression) à trois couches d'optimisation :
  1. RTK : Une couche déterministe intégrée, basée sur des hooks, qui réécrit les commandes shell via un proxy CLI.
  2. RTK-ML : Une architecture ajoutant neuf capacités à déclenchement par drapeaux (propagation de requête, routage de recherche, score lexical/embedding, recherche structurelle, etc.) au-dessus de RTK.
  3. Headroom : Un proxy de bordure d'API qui optimise les charges utiles en transit (boîte noire pour le harnais).
• Appariement : Les exécutions ont été effectuées par blocs où les quatre bras tournaient sur des copies de travail fraîches et identiques de la même tâche, randomisées dans l'ordre pour atténuer les biais.
• Métriques : La métrique primaire était le Coût Par Exécution Réussie (CPS), défini comme le coût total facturé divisé par le nombre d'exécutions réussies. L'étude a également suivi la longueur de la trajectoire (tours), les taux de réussite et une décomposition des coûts en quatre composantes.
• Modèle de coût : Les auteurs ont reconstruit les coûts facturés en utilisant les champs d'utilisation des fournisseurs et les prix standards, décomposant les coûts en : (1) Entrée non mise en cache, (2) Création de cache, (3) Lecture de cache, et (4) Sortie générée.

Études additionnelles

• Étude de fondement en un seul coup (Single-Shot) : Un programme distinct sur des tâches Go dérivées de SWE-bench a testé l'impact de la compression sur les « ancres d'édition verbatim » (contexte exact au bit près requis pour les correctifs SEARCH/REPLACE).
• Campagne de longue session : Une lignée distincte de 529 sessions sur de grands dépôts synthétiques pour observer les effets à long terme.

Principales conclusions

1. Anatomie du coût : Dominance du cache

L'étude révèle que le trafic de cache de prompt domine la composition des coûts.

• La création et la lecture de cache ont représenté environ 87 % de la décomposition des quatre composantes du coût reconstruit (environ 80 % de la facture réelle).
• La sortie générée (la réponse du modèle) n'a représenté qu'environ 10 %.
• L'entrée non mise en cache était négligeable (~1,3 %).
• Il y avait un résidu pondéré par le dollar de 8,7 % explicitement quantifié et non attribué par le modèle standard, qui augmentait avec le paramètre de « l'effort de réflexion » sur Haiku 4.5, suggérant que les frais de réflexion sont intégrés dans le résidu plutôt que dans les champs de sortie standard.

Implication : Supprimer les jetons de sortie des outils supprime souvent du texte qui est déjà mis en cache ou qui sera mis en cache à un tarif réduit. Par conséquent, une réduction de 38 % des jetons bruts de sortie d'outil ne se traduit pas par une réduction de coût de 38 %.

2. Découplage entre réduction de jetons et réduction de coût

L'étude fournit une preuve directe que la réduction de jetons et la réduction de coût sont découplées.

• Le bras RTK-ML a réduit les jetons bruts estimés de sortie d'outils de 38,4 %.
• Cependant, ce bras a entraîné une augmentation de coût appariée de +6,8 % (IC à 95 % [+2,8, +11,3]) par rapport à la base de référence.
• La réduction de jetons par tâche était un faible prédicteur du changement de coût facturé (corrélation de Pearson r = 0,15).
• Headroom (le proxy d'API) a subi une pénalité de coût massive de +48,4 % sans gain statistiquement significatif du taux de réussite.

3. La compression peut nuire à l'achèvement des tâches

Dans l'étude de fondement en un seul coup sur les tâches Go :

• La compression agressive a détruit les ancres d'édition verbatim nécessaires à l'application des correctifs.
• Les taux d'application de correctifs sont passés de 27/40 (brut) à 15/40 (compressé).
• Bien que le bras compressé ait eu un coût par tentative plus faible, le coût par ligne résolue était plus élevé (0,515 $ contre 0,248 $) car le taux de réussite s'est effondré.
• Le fondement par octet près (fournir des fenêtres de contexte brutes) a considérablement amélioré les taux de résolution, tandis que la compression les a dégradés.

4. Hétérogénéité et effets de trajectoire

• Longueur de trajectoire : Le coût augmente avec le nombre de tours. Toute couche qui ajoute des tours (en raison de boucles de récupération ou de relecture) doit compenser le coût de la retransmission de l'intégralité du préfixe mis en cache.
• Sensibilité au modèle/effort : Les résultats variaient selon le modèle et le niveau d'effort. Par exemple, RTK-ML a montré des augmentations de coût sur les tâches de haute intensité de Haiku mais des économies sur d'autres, indiquant qu'il n'y a pas de victoire universelle pour les « modèles faibles ».
• Familles de tâches : Les économies étaient hétérogènes ; RTK a montré des économies sur le traçage de dépendances mais des coûts sur la recherche sémantique.

Contributions

1. Anatomie du coût calibrée : Une décomposition en quatre composantes montrant que le trafic de cache (création + lecture) constitue ~87 % du coût reconstruit, remettant en question l'accent mis sur les nombres bruts de jetons.
2. Preuve appariée à grande échelle : Une comparaison rigoureuse, basée sur les coûts facturés par le fournisseur, des couches de réduction de contexte à travers près de 3 000 exécutions, démontrant que la réduction de jetons ne prédit pas la réduction de coût.
3. Documentation des modes de défaillance : Identification de modes de défaillance spécifiques où la compression corrompt les pipelines shell et détruit les ancres d'édition, entraînant des échecs d'application de correctifs.
4. Taxonomie de la preuve par couches : Une proposition d'un nouveau standard pour évaluer les revendications d'efficacité de jetons, passant des métriques de composant (L1-L2) au coût facturé ajusté au succès (L7).

Signification et revendications

Le document affirme que l'accent mis par l'industrie sur les « jetons supprimés » est activement trompeur. Les auteurs soutiennent que la réduction de jetons n'est pas une réduction de coût.

• Le mythe du « repas gratuit » : L'étude ne trouve aucune preuve d'un « repas gratuit » où la compression réduirait considérablement les coûts sans compromis. Dans de nombreux cas (RTK-ML, Headroom), la compression a augmenté les coûts.
• Métrique de décision : Les auteurs proposent le Coût Facturé Ajusté au Succès (Coût par Exécution Réussie) comme seule métrique de niveau de décision pour évaluer les couches d'optimisation des agents.
• Limites : Le document est modeste quant à la généralisabilité. L'étude de fondement en un seul coup est petite et spécifique aux tâches Go et aux formats SEARCH/REPLACE. Les résultats de longue session proviennent d'une lignée binaire différente. Cependant, la conclusion centrale — que l'économie de cache et les boucles de rétroaction de trajectoire découplent les comptes de jetons des coûts facturés — est présentée comme un fait empirique robuste dérivé de la campagne faisant autorité.

Les auteurs concluent que les praticiens doivent évaluer les couches d'optimisation en fonction du coût ajusté au succès de bout en bout plutôt que sur les ratios de compression par composant, car ces derniers ne parviennent pas à rendre compte de l'économie complexe du cache de prompt et des boucles de rétroaction comportementales des agents autonomes.