Réduire les coûts des tokens d’agent : mise en cache, routage et hygiène du contexte.

Un premier agent commence généralement avec un prompt système de 500 tokens et deux outils, et ces deux chiffres ont tendance à augmenter rapidement. On dit que le prompt système de Claude, qui a fuité, comptait environ 24 000 tokens. Les utilisateurs d’OpenClaw ont rapporté que plus de 150 000 tokens d’entrée ont été envoyés à Gemini 3.1 Pro dès le premier tour, pour une réponse de 29 tokens. Sans optimisation, un agent qui traite 100 messages par jour, avec 166 000 tokens d’entrée par message, coûte environ 996 dollars par mois sur Gemini 3.1 Pro et près de 2 490 dollars sur Claude Opus 4.6. Quelques choix de conception permettent de réduire ce coût à environ 50 à 100 dollars.

Les idées abordées ici sont le stockage en cache des prompts, le stockage en cache sémantique, les outils de chargement différé et les serveurs MCP, le routage et la cascade entre modèles, la délégation à des sous-agents, ainsi que le maintien d’un contexte de travail propre. Chacune de ces méthodes permet d’économiser de l’argent à sa manière, mais chacune comporte un coût en termes de complexité ou de qualité. Aucune n’est gratuite.

Le matériel est divisé en quatre groupes. Le premier concerne la réutilisation des tokens lorsque c’est possible, grâce au stockage en cache des prompts et au stockage en cache sémantique. Le deuxième vise à réduire les tokens toujours présents, tels que la mémoire et les définitions des outils. Le troisième consiste à diriger le travail vers des modèles plus petits ou à recourir à des modèles plus gros, en évaluant le risque pour la qualité par rapport aux économies réalisées. Enfin, il s’agit de maintenir un contexte propre, tant pour les performances que pour les coûts, avec une brève présentation de la compression.

Cessez de payer deux fois pour les mêmes tokens

Les coûts liés aux modèles ne proviennent pas uniquement d’un appel trop fréquent au modèle. Ils découlent également du fait de devoir payer à plusieurs reprises pour traiter du texte identique. Deux mécanismes très différents peuvent aider. Le cache K/V est le fondement du cache des prompts, tandis que le cache sémantique représente une approche distincte. Pour les prompts système longs, le cache des prompts offre des avantages simples ; en revanche, le cache sémantique exige plus d’efforts et comporte davantage de risques.

Fonctionnement du cache K/V

Au préalable de produire quoi que ce soit, le modèle doit traiter le prompt, ce qui nécessite des ressources de calcul, entraînant ainsi des délais et des coûts. Il est logique de ne pas retraiter à plusieurs reprises le même contenu.

Lorsqu’un grand modèle de langage reçoit un prompt, le texte est tokenisé, les tokens sont transformés en vecteurs, et au sein de chaque couche d’attention, ces vecteurs sont projetés en tenseurs K/V.

Le cacheage consiste à conserver ces tenseurs afin qu’ils n’aient pas besoin d’être recalculés. Un moteur d’inférence conserve déjà les tenseurs K/V pendant la génération, car sinon les calculs ne pourraient pas s’effectuer à une vitesse raisonnable. L’étape suivante consiste à conserver le cache après la fin de la réponse sans le supprimer.

Lors de la demande suivante, le système vérifie si le début du texte d’entrée correspond à quelque chose pour lequel il dispose déjà de tenseurs. S’il y a correspondance, il les charge et saute le traitement.

Les avantages économiques sont faciles à comprendre en utilisant des chiffres arrondis. Supposons que le traitement de 2 000 tokens prenne une seconde et que le texte d’instruction du système compte 10 000 tokens. Éviter ce rec calcul permet d’économiser 5 secondes à chaque appel, bien que la véritable vitesse de préremplissage varie beaucoup en fonction des paramètres d’installation.

La correspondance avec le cache stocké doit être parfaite. Si un seul token change, les tenseurs correspondant à cette partie du prompt ne s’appliquent plus et il faut la traiter à nouveau. Les gens se trompent constamment à ce sujet : un espace supplémentaire, une définition d’outil réordonnée ou une date et heure placées au mauvais endroit font échouer la correspondance.

Ainsi, un cache stocké accélère les requêtes et rend donc leurs coûts plus faibles. Cependant, le stockage n’est pas gratuit. Les données K/V mémorisées consomment de la mémoire du côté serveur, c’est pourquoi de nombreux fournisseurs font expirer les entrées après environ 5 à 10 minutes.

Nul n’a besoin de construire cela de zéro, car les frameworks et les fournisseurs d’API s’en chargent, chacun selon ses propres règles. Les équipes hébergeant un modèle open source utilisent généralement un framework de déploiement comme vLLM, qui intègre une couche de cache. Les utilisateurs d’API suivent quant à eux la politique de chaque fournisseur.

Cachage par préfixe dans vLLM

La couche de mise en cache dans vLLM divise la requête en blocs, calcule l’hash de chaque bloc à partir de ses propres tokens ainsi que des tokens qui le précèdent, puis stocke les tenseurs K/V sous ces hashes. Comme dans la plupart des configurations, la partie statique à mettre en cache se trouve au début de la requête.

Trois paramètres sont importants :

• --enable-prefix-caching active cette fonctionnalité.
• --block-size définit le nombre de tokens par bloc. Avec une taille de bloc de 16, le moteur s’arrête après 16 tokens et commence un nouveau bloc.
• --kv-cache-memory-bytes définit explicitement la taille de la mémoire de cache K/V par GPU. Plus de mémoire permet aux blocs en cache de durer plus longtemps, mais de nombreuses requêtes longues simultanées la remplissent plus rapidement et les blocs anciens sont éliminés plus tôt.

D’autres options existent, notamment SGLang avec RadixAttention pour le stockage en cache des préfixes, ainsi que LMCache, conçu pour s’intégrer aux moteurs de diffusion. Le fonctionnement est identique à celui décrit ci-dessus.

Stockage en cache via des fournisseurs d’API

La plupart des équipes utilisent des fournisseurs d’API, chacun ayant des politiques à respecter afin que les requêtes atteignent le cache. La requête doit être structurée en conséquence. OpenAI en est un exemple clair : pour stocker en cache une partie de la requête, il faut une correspondance exacte du préfixe, ce qui signifie que l’entrée statique doit être identique au début. Ainsi, les instructions stables, les exemples et les outils sont placés en premier, tandis que le contenu variable suit.

En envoyant un prompt-cache-key, on peut regrouper des requêtes similaires et augmenter le taux de réussite du cache. Le stockage en cache s’active automatiquement pour les requêtes de 1 024 tokens ou plus, mais les 256 premiers tokens servent à diriger les requêtes vers le même cache ; par conséquent, la partie statique doit faire plus de 256 tokens.

Anthropic fonctionne différemment : le cache doit être activé à l’aide du paramètre cache-control. L’éviction a généralement lieu après 5 à 10 minutes d’inactivité chez les deux fournisseurs, et ce délai peut être prolongé. Anthropic permet d’allonger ce délai à une heure, mais au double du prix.

Lors de l’hébergement propre, le temps économisé se traduit également par des économies financières. Avec les fournisseurs d’API, l’avantage réside dans des tokens d’entrée en cache moins chers. OpenAI applique une remise allant jusqu’à 90 % sur le prix normal des entrées en cache. Anthropic offre la même remise, mais facture également pour le maintien du cache, de sorte que son utilisation abusive peut finir par coûter plus cher que de ne pas utiliser de cache.

Lorsque 90 % d’un prompt est statique et que le cache est utilisé correctement, les coûts diminuent fortement, comme l’indique le graphique.

Une calculatrice interactive a été conçue pour cette comparaison afin de permettre d’ajuster les chiffres. Dans l’ensemble, le cache des prompts est un avantage considérable pour toute personne disposant d’un prompt système long et inchangé.

Cachage sémantique

Le cachage sémantique est quelque chose de complètement différent. Il fonctionne en se basant sur le sens : si une nouvelle requête est suffisamment similaire à une précédente, la réponse stockée est renvoyée. Cela semble simple, mais il existe des pièges évidents.

La correspondance de texte par son sens repose sur des embeddings, qui sont des vecteurs comparés à l’aide de la similarité cosinus. Une forte similarité devrait indiquer un sens similaire, bien que cela dépende du modèle d’embedding utilisé.

La proposition consiste à associer des demandes similaires aux réponses qui existent déjà. Une question comme « Quelle est la capitale de la France ? » et une demande hâtive du type « Vite, donnez-moi la capitale de la France » devraient toutes deux être renvoyées à une même réponse stockée, sans avoir besoin d’appeler un LLM pour la générer à nouveau. Cette approche fonctionne bien lorsque de nombreuses personnes posent des questions générales presque identiques, et que les données sous-jacentes deviennent progressivement obsolètes.

Alors pourquoi ne pas l’appliquer partout ? Parce que de nombreuses choses peuvent mal se passer. La conception doit résoudre plusieurs problèmes :

• Quel seuil de similarité constitue une correspondance.
• Pendant combien de temps une réponse reste valable.
• Comment gérer les conversations à plusieurs échanges.
• Qu’est-ce qui est réellement stocké.
• Si un routeur doit être placé en amont.
• Comment séparer les utilisateurs.
• Que se passe-t-il si une réponse incorrecte est mémorisée.

Le temps de vie mérite une attention particulière, car les informations deviennent obsolètes à des vitesses différentes selon les questions. La mécanique est simple, mais une utilisation en production nécessite des filtres et des étiquettes de métadonnées, tels que l’utilisateur, l’espace de travail, la version du corpus, le profil, le périmètre de la session, un TTL intelligent ainsi que des règles pour déterminer si une correspondance retournée est suffisamment bonne. Cela devient alors un petit projet.

Une conception fonctionnelle utilise l’index sémantique pour trouver une question antérieure et permet à différentes questions de pointer vers la même réponse stockée, ce qui limite l’augmentation de l’espace de stockage. Le TTL peut être adapté à l’utilisation : conserver plus longtemps les entrées fréquemment réutilisées et supprimer le reste. Il est également judicieux de mettre en place ce système après que les journaux aient montré des répétitions, et non au début, car certains cas d’usage ne s’y prêtent tout simplement pas.

De nombreuses bases de données peuvent effectuer ce travail, et des bibliothèques s’occupent des aspects techniques associés, parmi lesquelles semanticcache, prompt-cache, GPTCache, vCache, Upstash semantic-cache et Redis avec LangCache.

Les économies peuvent être réelles. Redis affirme jusqu’à 68,8 % de moins d’appels API et une amélioration de la latence de 40 à 50 %, bien que ce chiffre soit en partie lié à des stratégies marketing, car il provient d’un scénario simple de question-réponse. Les résultats dépendent entièrement de la configuration : un bot Q&R effectuant de nombreux appels redondants permet des économies plus importantes, tandis qu’un agent de codage dont les appels sont tous uniques en permet moins.

Le cache de prompts est particulièrement utile lorsque une question changeante fait partie d’un prompt statique volumineux, tandis que le cache sémantique est efficace lorsque les gens reformulent constamment la même question. Un taux de correspondance sémantique de 15 % ne permet que des économies modestes, mais un taux supérieur à 45 à 50 % commence à sembler intéressant.

Ces deux systèmes diffèrent également quant aux problèmes qui peuvent survenir. Une absence dans le cache des prompts ne coûte que le prix normal, ce qui rend l’échec peu coûteux et facilement détectable. Une absence dans le cache sémantique est également inoffensive, mais un faux résultat positif ne l’est pas : l’utilisateur reçoit une réponse écrite pour une question différente, en toute confiance, sans que rien dans les journaux ne le signale. Cet asymétrie explique pourquoi le cache sémantique exige des seuils de similarité conservateurs, une ciblage des utilisateurs et un moyen d’examiner les résultats positifs, tandis que le cache des prompts nécessite principalement une mise en forme disciplinée des prompts.

Le cache classique mérite également d’être mentionné. Les opérations coûteuses et déterministes, telles que les résultats de requêtes SQL, les sorties d’outils et les résultats de recherche, doivent être mémorisés afin de ne pas être exécutées plus souvent que nécessaire. Un exemple est un outil qui collecte des données de mots-clés pour la rédaction de résumés, les stocke dans le cache jusqu’à ce qu’elles deviennent obsolètes, et ne les exécute à nouveau que lorsque cette procédure est utilisée à nouveau.

Le cache sémantique est un concept intéressant qui permet d’économiser des tokens dans certains cas d’usage, mais le mettre en œuvre efficacement nécessite des compétences d’ingénierie.

Ne préchargez pas les tokens inactifs

Un prompt de système peut devenir volumineux en raison de définitions d’outils lourdes ou d’une mémoire en expansion. Les petits agents ne le ressentent pas, mais les spécifications des agents qui continuent de croître peuvent être allégées en récupérant les informations sur demande, ou du moins en essayant de le faire.

Gardez la couche toujours chargée petite

Lorsque le prompt d’un agent dépasse une certaine taille, la couche qui est toujours chargée doit rester petite et stable, avec les détails supplémentaires stockés séparément. Charger quelques centaines d’outils ou envoyer des descriptions complètes du serveur MCP qui changent constamment rend tout le système bruyant.

Le problème concerne à la fois les performances et le coût. Lorsque chaque couche continue de changer, le mise en cache des prompts devient également beaucoup plus difficile à mettre en œuvre. La couche supérieure doit être compacte et stable, suffisamment pour indiquer au modèle où il se trouve et où aller ensuite, sans devoir transporter toute l’information en amont.

On rapporte que Claude Code suit ce modèle pour gérer sa mémoire. Un fichier d’index est toujours chargé et ne doit pas dépasser 200 lignes, tandis que les fichiers détaillant les sujets se trouvent ailleurs. La manière dont l’agent se comporte dans la pratique par rapport à ce que le système prévoit est une question distincte. Une logique similaire apparaît dans la configuration avancée des outils de Claude, dans la conception en couches des compétences Claude Skills, ainsi que dans les tentatives de chargement différé des outils MCP plutôt que d’inclure toutes les définitions de serveur dans le prompt dès le départ.

Fonctionne-t-il ?

Le principe reste le même : lorsque le contexte devient volumineux, le modèle a plus de mal à choisir l’action appropriée. Ce domaine est encore jeune, donc un outil concret montre comment il peut fonctionner.

Il y a quelques mois, Anthropic a lancé une fonction avancée de recherche d’outils, destinée à réduire la quantité de données dans le contexte, même lorsque le modèle peut accéder à des centaines d’outils. L’entreprise indique avoir observé entre 55 000 et 134 000 tokens de définitions d’outils avant l’optimisation, et que choisir le mauvais outil constitue une erreur fréquente lorsque le contexte atteint de telles dimensions.

Un outil de recherche optimise le contexte en permettant au LLM de rechercher des outils sans avoir à les définir tous à l’avance. Une configuration correspondante se présente comme suit :

tools=[
        {
            "type": "tool_search_tool_bm25_20251119",
            "name": "tool_search"
        },
        {
            "name": "search_contacts",
            "description": "Find a contact by name or email.",
            "input_schema": {
                "type": "object",
                "properties": {
                    "query": {"type": "string"}
                },
                "required": ["query"]
            }
        },
        {
            "name": "send_email",
            "description": "Send an email to one or more recipients.",
            "input_schema": {
                "type": "object",
                "properties": {
                    "to": {"type": "string"},
                    "subject": {"type": "string"},
                    "body": {"type": "string"}
                },
                "required": ["to", "subject", "body"]
            },
            "defer_loading": True
        }
    ]

Une seule outil nommé tool_search est défini, en utilisant une option prête à l’emploi : BM25 ou Regex, ou une solution personnalisée. Ensuite, un seul outil est marqué comme différé à titre d’exemple. Cela n’a de sens que lorsqu’il y a 10 outils ou plus. Anthropic effectue la recherche, de sorte que la manière dont il insère le schéma de l’outil dans le prompt du système ainsi que la recherche elle-même restent invisibles. Lorsqu’un outil correspond, sa définition est ajoutée en ligne dans la conversation sous forme de bloc tool_reference.

L’idée est intéressante, car elle permet un contexte de départ plus réduit au prix d’une étape de recherche supplémentaire. Cependant, des tests menés avec 4 000 outils ont donné des résultats plutôt médiocres, ce qui laisse place à davantage d’essais. Les outils doivent également être suffisamment bien décrits pour être retrouvés, et le débogage devient plus difficile lorsque l’étape intermédiaire est invisible.

Cette approche se retrouve ailleurs sous le simple nom d’ingénierie IA de qualité. Ne soumettez pas l’agent à un contexte trop vaste et chaotique. Donnez-lui un moyen de restreindre les options et permettez-lui d’examiner ou de charger une outil uniquement lorsque c’est nécessaire.

Les économies dépendent du nombre de tokens envoyés au départ. Un deuxième calculateur compare la recherche d’outils à l’utilisation du cache des prompts.

L’exemple ci-dessus montre les économies estimées grâce au cache des prompts combiné à des outils chargés de manière différée. Les deux méthodes permettent des économies, mais leur combinaison ne représente pas une amélioration majeure par rapport à l’une ou l’autre utilisée séparément. La recherche d’outils ne concerne pas seulement les coûts, car elle permet également de maintenir un contexte propre pour améliorer les performances. Pour obtenir des économies, l’adoption d’au moins l’une de ces deux méthodes constitue le meilleur choix.

Utilisez des modèles bon marché pour des tâches peu coûteuses

Cette section traite du routage des demandes vers différents modèles ainsi que de l’utilisation de sous-agents moins coûteux pour certaines tâches. Ces deux approches permettent de réduire les coûts liés aux tokens, mais peuvent également mettre en péril la qualité des réponses. Beaucoup estiment que 60 % ou plus des questions reçues sont simples et n’ont pas besoin du modèle le plus puissant, encore moins d’un modèle capable de raisonnement.

Les produits commerciaux réalisent déjà une partie de cela. On rapporte que ChatGPT dirige les demandes en fonction de critères tels que le type de conversation, sa complexité, les besoins en outils et des intentions explicites comme « réfléchir profondément », tandis que Claude s’appuie sur une délégation basée sur des descriptions ainsi que sur des sous-agents intégrés comme Explore. Le concept est facile à comprendre ; le plus difficile consiste à le mettre en œuvre sans nuire à la qualité. Ce qui suit aborde le routage prédictif et les approches de vérification des résultats, comme les cascades et les sous-agents, tandis qu’un troisième chapitre présente les économies réalisées.

Routage selon la difficulté

Le routage au niveau de la requête estime la difficulté et l’intention avant même qu’aucun résultat ne soit généré. Les avantages sont importants, mais un mauvais choix peut gâcher toute une session, ce qui rend la qualité un véritable enjeu. Un modèle de routage doit donc décider où chaque requête doit être acheminée.

Les signaux de routage d’OpenAI ne sont pas publics, et les utilisateurs ont souvent l’impression d’avoir été redirigés vers un modèle moins performant au mauvais moment. Le monde du logiciel open source offre davantage d’options à examiner. RouteLLM, développé par LMSYS, le groupe de Berkeley derrière Chatbot Arena, apprend à partir de données réelles sur les préférences des utilisateurs collectées dans cette plateforme. Il combine des embeddings standard avec un petit module de routage, ce qui devrait maintenir les coûts d’hébergement faibles ; ses créateurs affirment des réductions significatives de coûts tout en conservant la majeure partie des performances de GPT-4. Cette affirmation n’a cependant pas été testée indépendamment ici.

L’article LLMRouterBench ajoute une remarque préoccupante : de nombreux routeurs appris ne battent à peine que des références simples telles que le routage par mots-clés ou heuristique, ainsi que le routage par voisin le plus proche et de type kNN.

Ces routeurs sophistiqués ne procurent peut-être pas de grande amélioration par rapport à des solutions simples. Les utilisateurs n’ont pas abandonné le routage et continuent d’expérimenter, mais les économies ne sont pas garanties lorsque la qualité des réponses ne suit pas. Il existe également des solutions hébergées, comme OpenRouter Auto et Switchpoint, bien que rien de public ne décrive leurs mécanismes internes de routage ni leur précision. Le calculateur compare LLMRouter, les heuristiques, un classificateur auto-hébergé, LLM-as-router, RouteLLM et OpenRouter Auto. La qualité dans le monde réel exige des tests appropriés avec des chiffres clairs, ce à quoi ce domaine a tout à fait droit.

Commencez petit, passez à des solutions plus avancées en cas de faible confiance

En évitant toute tentative de prédire la difficulté d’une demande à partir de son prompt, le modèle économique peut répondre en premier, puis un vérificateur décide s’il convient de conserver sa réponse ou d’escalader le processus. La documentation de Google sur les « Speculative Cascades » décrit ce compromis : des modèles plus petits sont utilisés en priorité pour des raisons de coût et de vitesse, tandis que les modèles plus gros ne sont activés qu’en cas de besoin.

Le modèle économique génère d’abord une réponse, puis un vérificateur léger analyse des indicateurs tels que les logprobs, l’entropie ou l’incertitude de type marge, ainsi que l’alignement sémantique.

Cette approche est attractive car il est difficile de prédire la difficulté d’un prompt et la plupart des routeurs ne sont pas parfaits, tandis que la qualité d’une réponse est plus facile à évaluer une fois qu’elle existe. Elle n’a de sens que si la plupart des questions peuvent être résolues par le modèle plus simple, car les demandes escaladées entraînent deux appels. Les équipes qui l’utilisent affirment que le délai de validation entre les appels peut rester inférieur à 20 ms.

Une implémentation open source nommée CascadeFlow affirme permettre des économies de 69 % tout en conservant 96 % de la qualité par rapport à GPT-5. Les prompts utilisés pour les tests disposaient de réponses correctes vérifiables, comme des solutions de mathématiques ou des questions à choix multiples. La principale préoccupation est que les petits modèles se trompent souvent de manière affirmée ; il peut donc être judicieux de commencer avec des seuils conservateurs et d’augmenter plus fréquemment ces seuils, ce qui entraîne une hausse des coûts. L’ajout d’un mécanisme en cascade axé sur les solutions peu coûteuses suggère des économies d’environ 50 %, à condition que des modèles plus gros soient nécessaires pour certaines demandes.

Déléguer aux sous-agents

Les sous-agents délèguent le travail à des agents isolés, qui fonctionnent parfois avec de petits modèles, ce qui constitue également une forme de routage. Les économies sont ici plus modestes. La valeur réside également dans le maintien d’un contexte clair, permettant à chaque agent de se concentrer pleinement sur sa propre tâche.

Claude Code est livré avec des sous-agents intégrés. Le sous-agent Explore est explicitement un exécutant Haiku conçu pour explorer et rechercher dans une base de code, ce qui met en pratique l’idée d’utiliser des modèles moins coûteux pour des tâches moins complexes. La session principale délègue également les tâches en correspondance avec des descriptions, de manière invisible, et l’utilisateur ne voit qu’une facture globale réduite. Comme l’orchestrateur reste généralement impliqué dans la planification, la synthèse et les tentatives de relance, les économies réalisées restent inférieures à celles obtenues grâce au routage.

D’après les calculs du générateur, les sous-agents permettent d’économiser environ 11 % par rapport à l’option sans routage, ce qui signifie qu’ils ne constituent pas seuls le principal levier pour réduire les coûts.

Préserver un contexte clair

Une bonne ingénierie du contexte concerne principalement les performances, mais elle peut également avoir un impact sur les coûts. Avec le temps, les agents accumulent des données inutiles : tentatives obsolètes, plans anciens, états dupliqués, journaux d’activité, observations répétées et résultats bruts des outils. Ce phénomène est particulièrement fréquent chez ceux qui créent des agents pour la première fois, car ils continuent d’ajouter des résultats à l’état de travail principal de l’agent.

Cela se produit partout. Les utilisateurs d’OpenClaw se plaignent de l’accumulation de contexte, tout comme les utilisateurs de Claude Code, car ajouter des éléments est plus simple que de les nettoyer.

La partie difficile, c’est le pipeline d’état

Il s’agit d’un problème à deux niveaux. Il ne suffit pas de compresser le chat ; les nouveaux éléments doivent également rester propres lorsqu’ils entrent dans l’état de travail, ce qui représente un travail d’ingénierie fastidieux. Un mauvais schéma se manifeste lorsque l’agent continue d’ajouter des résultats bruts au contexte :

bad state:
agent does work
→ dumps tool output into context
→ reads files
→ dumps files into context
→ runs tests
→ dumps logs into context
→ retries
→ keeps everything

La véritable tâche consiste à préserver l’état correct tout en supprimant les éléments superflus au fur et à mesure. La sortie brute peut être stockée dans un archive, ne conservant que ce qui est nécessaire dans le contexte actif. L’ennemi principal est généralement l’encombrement causé par les sorties des outils ; donc, rendre ces outils moins gourmands en ressources par défaut fait partie de la mission. Un contexte actif plus sain se présente comme ceci :

Good active context

[system rules]
[project rules]
[user task]
[current working state]

Keep:
+ auth flow lives in auth.ts + session.ts
+ bug only happens on refresh path
+ failing test: session_refresh_keeps_user
+ likely overwrite during refresh
+ files in scope: auth.ts, session.ts, auth.test.ts

Drop:
- raw grep results
- full test logs
- duplicate file dumps
- dead-end retries

Certaines parties du contexte peuvent également avoir une durée de vie ou une date d’expiration. Lorsque la compression devient nécessaire, il devient alors plus facile de déterminer ce dont le LLM a réellement besoin.

Les notes d’Anthropic sur les tâches à long terme indiquent que la compression doit préserver les décisions architecturales, les bogues non résolus et les détails d’implémentation. La compression autonome de LangChain permet à l’agent de décider quand compresser, sans attendre que le contexte soit déjà trop volumineux, ce qui semble correspondre à l’approche d’Anthropic. Les équipes commencent à considérer la compression comme un problème de système, avec des benchmarks et des politiques spécifiques à chaque agent, et non plus comme un simple truc de résumé générique.

Une étude récente de Jia et al. affirme qu’avec une compression 6 fois supérieure, ils ont obtenu une réduction de 51,8 à 71,3 % du budget de tokens, ainsi qu’une amélioration de 5,0 à 9,2 % dans la résolution des problèmes sur SWE-bench Verified. Il s’agit donc non seulement de coûts : cela améliore également les performances en général.

La suppression des données inutiles peut raisonnablement libérer de 30 à 70 % d’un contexte, ce qui représente une économie équivalente en dollars. Pour une fenêtre de contexte de 10 k, nettoyer 30 à 50 % des données lors de 100 k d’exécutions peut permettre d’économiser jusqu’à 1 500 $, et ce chiffre monte à 6 000 $ pour une fenêtre de 40 k. Les agents de compression qui utilisent déjà des modèles très petits et bon marché peuvent coûter plus que ce qu’ils permettent d’économiser. Néanmoins, un contexte propre ne sacrifie pas la qualité comme le peuvent le cache sémantique ou le routage, donc s’il est bien mis en œuvre, c’est un avantage clair. Le problème réside dans l’effort nécessaire pour le réaliser.

Choix parmi eux

Il existe quatre façons de réduire les coûts liés aux tokens, et le bon équilibre dépend du cas d’usage :

• Utiliser le cache de prompts avec des prompts système volumineux qui restent inchangés lors des appels répétés à l’LLM.
• Utiliser le cache sémantique pour un bot de Q&R générique qui doit rester peu coûteux.
• Tester le routage lorsque l’agent doit gérer à la fois des questions simples et complexes.

Gardez le contexte aussi propre que possible pour éviter l’envoi de tokens inutiles.