La version courte
Le context engineering en 2026, c'est décider ce que le modèle voit à chaque appel : ce qui reste dans la fenêtre, ce qui est jeté ou compacté, et ce qui vit à l'extérieur dans des fichiers ou un index de recherche. Nos évaluations sur un tuteur IA en production ont montré qu'avec le prompt caching, tout garder est souvent moins cher, plus rapide et meilleur pour se souvenir que résumer. La compaction devrait donc être une réponse délibérée à une contrainte nommée plutôt qu'un réglage par défaut.
- Avec le prompt caching moderne, garder l'historique complet a battu toutes les stratégies de summarisation qu'on a testées sur le coût, la latence et le rappel mémoire en même temps. Résumer réécrit le préfixe en cache, donc vous payez plein prix pour recalculer exactement ce que vous tentiez d'économiser.
- C'est l'étage pas cher de la compaction qui rapporte. Plafonner chaque sortie d'outil à une taille stable a coupé notre coût par tour de 38% sans perte mesurable de mémoire, parce que ça réduit le contexte sans réécrire le préfixe dont dépend le cache.
- La compaction n'est pas morte, elle est conditionnelle. Nommez d'abord votre contrainte : une fenêtre qui ne suffit pas, un prix d'entrée en cache au-dessus d'environ 0,55 $ par million de tokens, ou une dégradation de qualité mesurée. Chacune mène à un correctif différent.
- Mesurez sur votre propre système. Nos réglages de production avaient l'air raisonnables, ils obtenaient 38% aux sondes de mémoire, coûtaient deux fois plus cher que de ne rien faire, et produisaient quand même des réponses qu'un juge à l'aveugle trouvait bonnes. C'est cette combinaison qui rend l'estimation à l'œil impossible.
Vous avez donné une seule règle à l’agent au tour 1. Il a accepté. Quarante-cinq tours de greps, de diffs et de logs plus tard, il fait exactement ce que vous lui avez dit de ne pas faire, et il l’annonce fièrement. Si vous avez déjà mené une longue session avec un agent, vous avez vécu ça. J’ai ouvert notre atelier avec cette conversation précise parce que tout le monde dans la salle reconnaît immédiatement son propre terminal.
Le modèle n’est pas devenu plus stupide. Son contexte, oui.
À l’AI Engineer World’s Fair, Omar Solano, Samridhi Vaid et moi avons donné un atelier sur quoi faire avec ça : le context engineering en 2026, démontré sur notre tuteur IA open source plutôt que sur des exemples jouets. On a mené les expériences, dépensé quelques centaines de dollars en évaluations, et obtenu des résultats qui contredisaient notre propre configuration de production. Cet article couvre tout ce qu’il y avait dans la présentation, plus les constats qu’on a dû survoler sur scène et quelques-uns arrivés après. L’atelier complet est aussi disponible en vidéo, en anglais, et l’article continue plus bas.
Tout ici est open source : le code complet du tuteur, la démo en direct avec tous les résultats des expériences et les diapositives. Vous pouvez fouiller chaque chiffre que je mentionne.
Pourquoi un tuteur est un problème de context engineering
Chez Towards AI, nous bâtissons des formations pour ingénieurs IA, et nous fournissons un tuteur IA qui répond aux questions des étudiants en s’appuyant sur nos leçons. Ce tuteur est l’étude de cas de tout ce qui suit, et il avait cinq exigences fermes : des réponses ancrées dans notre contenu plutôt que dans les connaissances générales du modèle, cadrées sur le cours actuel de l’étudiant, capables de soutenir de longues sessions de débogage avec des relances, capables de lire et d’écrire du code, et assez rapides pour que la latence ne gâche pas l’expérience. La vitesse de streaming, c’est de l’UX pour un tuteur.
Si on échoue là-dessus, l’expérience étudiante devient l’histoire du git push plus haut, sauf que la personne à l’autre bout a payé pour le cours. Pendant l’atelier, j’ai illustré où ça mène avec une diapositive sur des étudiants qui demandent un remboursement. Ça a fait rire, mais c’est vraiment l’enjeu d’affaires : un agent qui oublie en pleine session coûte de l’argent réel.
Deux propriétés des LLMs créent tout le problème. D’abord, la fenêtre de contexte est finie, et tout se dispute un seul budget d’attention : les instructions, les leçons récupérées, les sorties d’outils, le code. Ensuite, le modèle est sans état. Chaque appel repart de zéro, et entre les sessions rien ne persiste tout seul. À l’intérieur d’une session, ça vous donne la gestion du contexte. Entre les sessions, la mémoire. L’atelier, et cet article, se concentrent sur la première, parce qu’on ne peut pas avoir une bonne mémoire multi-sessions si une seule session s’écroule déjà.
Ce que le modèle voit vraiment, à chaque appel
Voici la partie que les gens sous-estiment le plus, selon moi. À chaque appel, le modèle relit le prompt système, les définitions d’outils, tout l’historique de conversation, chaque ancienne sortie d’outil, les extraits de cours récupérés, et finalement la question de l’étudiant. La question est habituellement le plus petit morceau, sauf que les étudiants collent des logs d’erreur, donc pas toujours.
Dans notre tuteur, le segment qui gonfle, ce sont les anciennes sorties d’outils : extraits récupérés devenus périmés, paires appel d’outil et résultat d’outil, fichiers que l’agent a ouverts en chemin. Notre tout premier constat a été que ce sont ces charges de recherche, et non l’historique de conversation, qui dominent l’entrée. On laissait chaque appel se remplir jusqu’à 100k tokens de matériel récupéré, et les tours arrivaient autour de 200k tokens en entrée. La conversation n’a jamais été la partie coûteuse. Ça compte, parce que la plupart des conseils sur les longues sessions d’agents visent à rogner l’historique, qui dans notre système était une erreur d’arrondi.
Et une fenêtre qui grandit fait mal trois fois. La qualité se dégrade quand les faits sont enfouis, le classique effet du « perdu au milieu » qu’on classe maintenant sous le context rot. Le graphique que j’ai montré sur scène pour ça est pire que ce que la plupart des gens imaginent : sur une fenêtre de vingt documents, la précision part autour de 75%, s’affaisse au milieu de la quarantaine pour les faits situés au centre, et cette baisse passe sous ce que le même modèle obtient sans aucun document. Lui donner le bon matériel à la mauvaise position était pire que ne rien lui donner.
Le coût grimpe aussi, parce que tout l’historique est renvoyé et refacturé à chaque tour. Et le temps jusqu’au premier token grimpe avec la taille de l’entrée, parce que le modèle retraite la fenêtre à chaque appel. Nos propres mesures situent le temps médian jusqu’au premier token autour de 22 secondes sous 100k tokens en entrée, et autour de 76 secondes au-dessus de 800k. Les utilisateurs le sentent.
Remarquez l’ordre dans lequel je les ai mis, par contre. On est entrés là-dedans en pensant gérer le contexte pour la qualité. Les expériences vont montrer que, pour notre charge de travail, la dépense et la vitesse étaient les vraies raisons. Gardez ça en tête.
La boîte à outils de la compaction, du gratuit au sophistiqué
La compaction est une idée simple : garder le plus petit contexte qui contient encore ce dont vous avez besoin pour répondre, et jeter ou déplacer le reste. Les techniques forment une échelle, et j’aime la présenter selon ce qu’elles vous coûtent : les outils triviaux d’abord, puis dépenser des tokens pour économiser des tokens, puis déporter.
L’étage trivial n’a besoin d’aucun LLM. La troncature d’observation coupe une sortie d’outil absurdement grosse pour n’en garder que la tête et la queue, comme la trace de pile de 300 lignes d’un étudiant où seules la commande et l’erreur finale comptent, avec une note qui dit au modèle qu’il peut la redemander au besoin. Le rognage, ou fenêtre glissante, garde les N derniers tours et jette les plus vieux. L’effacement de résultats d’outils remplace les sorties déjà consommées par un espace réservé qu’on peut recharger, tout en gardant la trace de l’appel. Pas cher, prévisible, et honnêtement là où la plupart des gens devraient commencer. Retenez cet étage, parce qu’il gagne plus loin.
Ensuite, vous pouvez dépenser des tokens pour en économiser davantage, avec un modèle, et il n’a même pas besoin d’être gros. La rétention sélective garde les contraintes, les décisions et les tâches ouvertes en écartant les culs-de-sac et les doublons. La summarisation remplace continuellement le vieil historique par un résumé courant, avec perte par conception. Et la compaction complète, la manœuvre de Claude Code, écrase tout l’historique en un seul résumé neuf et repart de là quand vous atteignez la limite. Il y a aussi la summarisation delta, où vous ne résumez que les nouveaux tours et les ajoutez, ce qui compte surtout quand vous lancez des sous-agents. Notre tuteur fonctionne très bien en un seul agent, donc on a sauté cette complexité, la même position « commencez simple » que je défends dans la plupart de mes vidéos.
Le troisième étage est mon préféré : ne supprimez pas, déplacez. Déportez les détails vers des fichiers ou un outil de mémoire et gardez un pointeur dans le contexte. C’est entièrement réversible, rien n’est perdu, et la recherche ramène les choses juste à temps. C’est l’idée du « LLM wiki » de Karpathy, une arborescence de fichiers que l’agent maintient et relit, et c’est la même forme vers laquelle Claude Code et les autres ont convergé avec CLAUDE.md et les skills : des fichiers durables plus une petite fenêtre vivante.
On utilise une recette concrète tirée de la production pour ça : écrire les extraits dans des fichiers, reliés entre eux par des pointeurs, garder un seul fichier index qui les répertorie tous, puis laisser l’agent ne lire que cet index. Il se fraye un chemin vers les détails selon la tâche, donc une question complexe en tire plus et une question simple en tire moins. Le contexte grandit avec la complexité de la tâche au lieu de grandir avec la longueur de la session.
Une petite parenthèse sur les skills, parce qu’on le voit avec chaque client avec qui on travaille : le domaine converge vers beaucoup de petites skills ciblées plutôt qu’un seul gros fichier d’instructions. Les noms et les courtes descriptions restent visibles, les corps ne se chargent qu’à l’usage. La divulgation progressive, appliquée aux instructions. Le même principe que tout ce qui précède.
Un aparté honnête sur GraphRAG, puisque les gens posent constamment la question. On l’a construit et comparé au RAG hybride classique sur 41 cas réels. Les deux citaient la bonne source 100% du temps, ils faisaient match nul sur le rappel de leçons à 76%, et la recherche classique avait en fait un meilleur rang réciproque moyen, 0,70 contre 0,65. GraphRAG envoyait 61% plus de tokens en entrée et coûtait 44% plus cher par tour. Bâtir l’index sur 90 documents a coûté environ 45 $, et le faire sur tout le corpus aurait frôlé les 2 000 $. Donc on ne l’utilise pas. Si votre dataset est un réseau d’entités interconnectées, testez-le. Le nôtre, ce sont des leçons et de la documentation, et la recherche hybride classique suffisait.
Le retournement : le prompt caching change le calcul
Tout ça, l’index GraphRAG, les appels de reclassement, le budget de recherche, suppose que les tokens coûtent ce que la page de tarifs dit qu’ils coûtent. Ce n’est pas le cas, et c’est là que la partie 2026 embarque vraiment : le conseil standard du domaine s’est discrètement inversé.
À peu près tous les fournisseurs sérieux offrent maintenant le prompt caching. Quand vous renvoyez un contexte que le fournisseur a déjà traité, ces tokens sont facturés à une fraction du prix : environ 90% de rabais chez Gemini, et chez DeepSeek le tarif en cache tombe de 0,14 $ à 0,0028 $ par million de tokens, soit à peu près 50 fois moins cher. Les tokens en cache sont aussi déjà calculés, donc le premier token revient beaucoup plus vite. Une partie est implicite et automatique, ce sur quoi roule notre tuteur, et une partie s’épingle explicitement, comme les blocs cache_control d’Anthropic, où la garantie vient avec un TTL et un loyer de stockage.
Ce diagramme vient d’un fil de @its_ao que je recommande sincèrement de lire au complet.
Maintenant, reliez ça à la compaction. Le cache ne fonctionne que si le contexte précédent est renvoyé inchangé. Dès que vous résumez, compressez ou réécrivez l’historique de quelque façon, le fournisseur voit un préfixe tout neuf et facture chaque token plein prix. Votre transformation astucieuse pour économiser des tokens vient de jeter un rabais de 50 fois. Face au tarif en cache de DeepSeek, un résumé doit réduire le contexte de plus de 50 fois juste pour atteindre le seuil de rentabilité, et bonne chance pour y arriver sans perdre le détail exact que l’étudiant demandera ensuite.
C’est pourquoi la summarisation est potentiellement un piège. Manus AI l’a formulé aussi fermement que possible dans son texte sur la construction de l’agent : « Si je devais choisir une seule métrique, je dirais que le taux de succès du cache KV est la métrique la plus importante pour un agent IA en production. » Quand j’ai lu cette phrase la première fois, ça sonnait exagéré. Après notre facture d’évaluations, plus du tout.
Les harnais sérieux reflètent tous ça maintenant, et on sait comment ils se comportent grâce à la fuite d’un côté et au fait que Codex est open source de l’autre. Claude Code compacte rarement et structurellement, en rognant les sorties d’outils sans appel de modèle et en ne remplaçant l’historique par un résumé qu’à l’approche de la limite de la fenêtre, avec CLAUDE.md et les skills qui survivent à la remise à zéro. Codex fait écrire un résumé de passation par un modèle local. Anthropic et OpenAI livrent tous les deux de la gestion de contexte directement dans l’API, où les vieux tours sont jetés pendant que le prompt système reste en cache. Remarquez le motif : ils compactent tous rarement, délibérément et en tenant compte du cache, pas continuellement.
L’hygiène pratique qui découle de tout ça, et c’est ce qu’on fait nous-mêmes maintenant : repartez une session neuve quand vous changez de tâche, cadrez serré le contexte de fichiers, débranchez les outils inutilisés, ne compactez que si nécessaire, optimisez pour les succès de cache, routez les tâches simples vers des modèles moins chers, et journalisez tout. Ce dernier point est le plus négligé et le plus facile à régler. J’ai simplement demandé à Claude de brancher Opik dans notre stack et il l’a fait. Suivez le taux de succès du cache, suivez les sorties anormalement longues, suivez la frustration des utilisateurs.
Tout ça ensemble, c’est ce que veut dire le context engineering aujourd’hui : décider ce que le modèle voit, à chaque appel. Le prompt engineering est devenu adulte, et la compaction, la mémoire et la recherche ont déménagé sous un même toit.
Le tuteur, construit et mesuré
Omar a pris le relais pour la deuxième partie de l’atelier avec ce que j’aimerais voir dans plus de conférences : le système réel et le harnais qui le note.
L’agent lui-même est délibérément ennuyant. Un seul agent bâti avec create_agent de LangChain et un point de contrôle en mémoire, une pile de middlewares qui peut plafonner, effacer, résumer et cadrer, un backend FastAPI, et une interface de conversation Next.js qui diffuse vers l’étudiant. C’est tout. Pas d’essaim d’agents.
L’agent est petit exprès. C’est l’ancrage qui en fait un tuteur : un corpus bâti à partir de 14 sources, nos cinq formations plus neuf ensembles de documentation comme LangChain, LlamaIndex, OpenAI et la documentation de Claude Code. Aucune fenêtre ne contient ça, donc on encode une fois et on récupère par question.
Le premier outil d’ancrage, retrieve_tutor_context, est un pipeline hybride classique, et chaque nombre dedans a été réglé par des expériences antérieures plutôt qu’au feeling. Il cadre sur la source choisie par l’étudiant, puis lance en parallèle une recherche dense par embedding et une recherche par mots-clés BM25, top 15 et top 30. Le reciprocal rank fusion fusionne les deux listes, Cohere reclasse pour descendre au top 5, tout ce qui note sous 0,10 est jeté, et ce qui survit remplit un budget allant jusqu’à 100k tokens.
Le deuxième outil d’ancrage est le plus amusant. run_kb_command donne à l’agent un shell en lecture seule sur le corpus, exactement comme les agents de code fouillent une base de code : rg, grep, find, ls, sed, head, cat, wc. Il est enfermé dans le dossier de la base de connaissances, avec un délai de 8 secondes, un plafond de sortie de 40k caractères et une limite de 20 commandes par tour, donc il peut regarder autour mais il ne peut pas s’enfuir. La base de connaissances a trois couches : des miroirs markdown bruts de tout, des index générés par machine des titres et des symboles de code, et un wiki de sujets et de frameworks qu’un agent a écrit hors ligne en lisant le corpus brut. Quand on ajoute une formation, un agent met le wiki à jour en suivant un fichier de maintenance. Le tuteur ne fait jamais que lire.
Il y a un article qui défend correctement cette approche, et ça se lit bien. Il appelle ça l’interaction directe avec le corpus : laisser l’agent fouiller le corpus brut avec des outils de terminal, sans aucun embedding ni index vectoriel, et ça bat de solides références en recherche éparse, dense et par reclassement sur plusieurs benchmarks. L’argument est qu’un seul appel top-k est une interface avec perte, et que les preuves écartées tôt ne peuvent pas être récupérées ensuite, peu importe la qualité de votre raisonnement.
On voulait que ce soit vrai pour nous. Et voici le résultat que je tiens à partager, parce que les résultats négatifs ne sont presque jamais partagés : l’agent adorait l’outil, il s’en servait dans environ 89% des tours, à peu près 7,7 appels à la base de connaissances par tour contre 0,9 appel de recherche. Puis on l’a désactivé et l’ancrage a à peine bougé. Les vraies questions d’étudiants ne sont simplement pas assez multi-sauts pour en avoir besoin. C’était plaisant à construire. Ça a mesuré presque rien. On garde le code et on livre avec l’outil éteint.
Celle-là nous a aussi appris quelque chose sur la mesure. Notre première lecture de cette expérience ressemblait à une grande victoire pour la désactivation de l’outil, avec un rappel qui passait de 50% à 96%, et c’était un artefact : notre métrique de rappel ne comptait que l’outil de recherche, donc un agent qui trouvait la bonne leçon en grepant était noté comme un échec. Une fois les deux chemins comptés équitablement, la configuration avec fouille était à 100% et celle sans à 96%. Les mêmes runs, la conclusion inverse. La plupart de nos bogues de mesure se sont avérés être de ce genre, des angles morts dans les étiquettes et la télémétrie plutôt que des maths fausses.
Pour la gestion du contexte, la configuration de production du tuteur empilait trois middlewares : effacer les vieilles sorties d’outils passé 5k tokens en gardant les résultats de recherche et les cinq dernières, résumer les vieux tours passé 30k tokens en gardant les 20 derniers messages, et une préférence de source pour cadrer le corpus.
Omar a été franc sur la partie gênante : on a choisi ces réglages parce qu’ils avaient l’air sensés. De la production qui roule sur des réglages jamais éprouvés. Alors, quelle configuration est réellement la meilleure?
Le harnais : exécuter, noter, filtrer, rapporter
Il faut mesurer, parce que comme on l’a découvert, avec le caching moderne le geste évident peut s’inverser, et l’espace de configurations est bien trop grand pour être jugé à l’œil. Petit vocabulaire, puisque je vais m’appuyer sur ces mots pour le reste du texte : une configuration est un réglage du tuteur avec tout le reste fixé, un type de tâche est un jeu de tests, un run est une configuration essayée sur un modèle sur un type de tâche, et un bundle est ce qui est sauvegardé à chaque tour, la réponse plus chaque appel d’outil, source, compte de tokens et chronométrage derrière elle.
On a testé sur deux types de tâches bâtis à partir de vrais étudiants. Tour unique : 60 questions posées une fois, retenues sur 151 vraies publications de l’académie après avoir retiré les doublons et les prémisses que notre corpus avait dépassées, notées sur la recherche, les faits clés, et si la réponse était du bon type, enseigner plutôt que rediriger. Omar avait fait racler ça par Codex depuis notre forum d’académie, ce qui était plutôt méta. Une règle là-dedans que je pousserais à quiconque bâtit des évaluations : on n’écrit jamais nos propres réponses de référence. La vérité terrain est la vraie réponse du personnel, distillée en une poignée de points clés atomiques et vérifiables de façon binaire.
Les sessions sont la moitié intéressante. On plante un fait au tour 0, on fait grandir la conversation avec de vraies questions de cours jusqu’à ce que le seuil de summarisation se déclenche, puis on sonde pour le fait planté.
Une session, du début à la fin : le tour 0 plante « Je suis développeur Unity. Mon point faible est l’évaluation du RAG. Le dialogue doit se diffuser en moins de 300 ms. » Dix tours de vraies questions poussent la conversation au-delà du seuil. Le tour 11 demande : « Une soirée libre, quel sujet je travaille, et nomme deux métriques? » La réponse attendue est l’évaluation du RAG, le taux de succès, le MRR.
Le harnais a quatre étapes : run_battery pilote le vrai code de l’agent de production, un bundle par tour, et c’est la seule étape qui coûte de l’argent. Grade fait tourner des vérifications de code gratuites plus un juge LLM, et une note pratique d’Omar ici : faire passer le juge par un abonnement Claude Code ou Codex coûte présentement moins cher que de payer les tarifs d’API. Check_triggers est le filtre : si la compaction ne s’est jamais déclenchée avant la sonde, le run est rejeté, parce que la sonde ne testerait pas la mémoire. Report génère des tableaux côte à côte et des courbes de tokens par tour.
Le juge ne voit que la question, la réponse et le critère de notation, jamais quelle configuration l’a produite, donc il ne peut pas favoriser une stratégie. Il s’accordait avec nos étiquettes humaines 98% du temps, et Omar a noté à la main les 96 sondes de session sans une seule correction. Comme les bundles sont sauvegardés, on évalue une fois et on peut renoter quand on veut, ce qui est exactement comment plusieurs de ces constats ont été corrigés plus tard sans dépenser un dollar de plus. On a fait tourner 11 configurations en deux rondes : un criblage large de huit configurations à un essai chacune, puis un suivi plus serré qui passait les trois plus importantes à deux essais. full_history et la production servaient de points de repère, et les variantes comprenaient la fenêtre glissante, la compression de prompt, la rétention sélective et la remise à zéro du contexte. Même modèle, même prompt, même recherche, même dataset. 660 tours, zéro erreur d’API, environ 88 $ pour le criblage large et 62 $ pour le suivi, et près de 590 $ pour tout le programme Gemini. Plus que ce qu’Omar prévoyait, et cette facture devient un point d’intrigue dans la troisième partie.
La surprise : la compaction n’a pas rapporté
Voici le rappel mémoire en session pour chaque méthode qu’on a testée, sur Gemini 3.5 Flash :
Ne pas toucher au contexte du tout était la meilleure stratégie, autant dans le criblage large que dans le suivi plus approfondi. Notre configuration de production, celle que de vrais étudiants utilisaient, se tenait à 58% dans le criblage large et à 38% dans le suivi plus serré à deux essais. Les réglages qu’on croyait assez bons étaient pires que de ne rien faire. Avec un et deux essais, les pourcentages exacts sont bruités, et l’équipe a été claire là-dessus sur scène, mais c’est l’ordre qui compte.
Puis le duel qui a donné son titre à cet article. Sur des sessions de 11 à 13 tours, full_history contre la production :
Tout garder a gagné les trois d’un coup. Moins cher, plus rapide et meilleur pour se souvenir. Notre configuration qui compactait envoyait environ 41% moins de tokens et payait quand même à peu près deux fois plus, parce que full_history faisait facturer environ 87% de son entrée au rabais du cache alors que chaque summarisation réécrivait le préfixe et payait plein prix. Et les sorties d’outils effacées empiraient les choses d’une deuxième façon : l’agent récupérait de nouveau de l’information qu’il avait déjà eue. Payer, jeter, payer encore.
Deux détails de cet effondrement valent plus que le chiffre principal. D’abord, les dégâts suivaient le nombre de réécritures avec perte, pas la taille du contexte vivant. Les runs sans événement de compaction répondaient à toutes les sondes. Ceux avec deux ou trois y répondaient encore. Ceux avec cinq ou six répondaient à une sur trois. Chaque événement écrasait environ 150k tokens en à peu près 1,7k, donc disons quatre-vingt-dix pour un, et la perte se compose chaque fois que vous recommencez par-dessus le résumé précédent.
Ensuite, et c’est la partie qui m’a mis mal à l’aise : au moment de la sonde, les configurations qui compactaient répondaient depuis des contextes de 95k à 195k tokens et échouaient, tandis que full_history répondait depuis 363k à 879k tokens et ne ratait jamais. Un plus gros contexte n’était pas le problème. Le réécrire, oui.
Et voici le constat que je tatouerais sur quiconque livre un agent. Quand on a noté ces mêmes réponses de façon globale, en demandant à un juge à l’aveugle « est-ce une bonne réponse de tuteur », la configuration de production obtenait 97% à 99% alors que son rappel mémoire dans ce même criblage était à 58%. Sur les tours précis où le tuteur avait démontrablement perdu le fait planté, le juge trouvait la réponse bonne 100% du temps. Chacune d’entre elles. Le mode de défaillance n’est pas un plantage visible ni une hallucination évidente. C’est une réponse confiante, bien écrite, dans le sujet, qui ignore silencieusement ce que l’étudiant vous a dit dix tours plus tôt. Si votre évaluation est un score de qualité global, vous ne verrez jamais ça. On l’a vu seulement parce qu’on plantait des faits et qu’on notait uniquement ceux-là.
Je veux être juste envers la compaction ici, comme on a essayé de l’être sur scène : ce sont des résultats pour des sessions de 11 à 13 tours, sur un modèle cloud avec cache, sur notre charge de travail. C’est précisément ce qui met la table pour la suite.
La partie de la compaction qui a rapporté
Tuer la summarisation n’est pas la même chose que tout garder pour toujours, et cette distinction est d’où vient notre vraie victoire en production.
Souvenez-vous de l’étage trivial, les techniques qui n’ont besoin d’aucun appel de modèle. On a fait un vrai deux par deux sur DeepSeek, 414 tours par branche sur trois essais : plafonner les sorties d’outils ou non, résumer ou non. Le plafonnement seul a fait passer le coût par tour de 0,189 $ à 0,117 $, une coupe de 38%, et il a gagné dans 14 des 15 trajectoires appariées. Le taux de succès du cache a à peine bougé, de 96,0% à 95,9%, et la précision aux sondes de mémoire était identique au run sans plafond. Ça fait 38% gratuits.
La summarisation, elle, ajoutait du coût par-dessus l’une ou l’autre des références. À peu près 50% de plus que l’historique complet brut, et encore 32% de plus que l’historique complet plafonné. Ajouter un appel de modèle pour économiser des tokens empirait la facture dans toutes les configurations qu’on a essayées.
La raison pour laquelle le plafond fonctionne et le résumé non est la même qu’avant. Un plafond stable et déterministe rend le préfixe plus court mais le laisse identique octet pour octet d’un tour à l’autre, donc le cache fonctionne encore. Un résumé rend le préfixe plus court en le rendant différent, donc le cache rate. Réduisez le contexte, ne le réécrivez pas.
On a même essayé de réparer la summarisation selon ses propres termes. Codex fait quelque chose d’astucieux : au lieu de remplacer l’historique, il envoie l’historique inchangé plus une seule instruction qui demande un résumé de point de contrôle, ce qui garde le cache intact pour l’appel du résumeur lui-même. On l’a construit, et ça a fonctionné exactement comme annoncé. Le taux de succès du cache sur l’appel du résumeur est passé de pratiquement zéro à 94%, et le coût de résumer a chuté de 87%. Le coût total est quand même arrivé 14% sous le résumeur naïf et 14% au-dessus du simple fait de plafonner et de tout garder. On a rendu la compaction aussi peu chère qu’elle peut l’être, et elle a encore perdu contre l’option ennuyante.
Alors quand la compaction compte-t-elle vraiment?
La partie de Samridhi répondait à la question que tout le monde devrait poser ensuite : tout garder a gagné, mais l’historique complet sur un modèle au prix des modèles de pointe est cher, et quelques centaines de dollars de factures d’évaluation, ça pique. Elle a donc poussé les mêmes tests dans trois régimes : des modèles avec cache moins chers, des documents et des sorties d’outils, et des modèles locaux à l’échelle. Un cadrage de sa section que je trouve l’idée la plus réutilisable de tout l’atelier : le contexte n’est pas une seule chose. Un historique de conversation grandit à chaque tour. Un document collé ou une énorme sortie d’outil peut faire éclater la fenêtre d’un coup. Chaque forme casse différemment et demande un correctif différent.
Premier levier, un modèle moins cher. Remplacez Gemini 3.5 Flash par DeepSeek V4 Flash, relancez les mêmes sessions, et le coût par tour tombe d’environ 18 fois, passant de près de 0,11 $ à près de 0,006 $, aidé par ce rabais de cache de 50 fois. Tout garder gagnait encore sur le coût. La question plus importante était de savoir s’il se souvenait toujours, et oui : 95% des sondes de mémoire passaient avec l’historique complet, contre 32% quand on résumait d’abord.
Mon graphique préféré de toute l’étude est le suivant, parce que ça sonne impossible jusqu’à ce que le caching fasse tilt : le run le moins cher est celui qui envoie le plus de tokens. L’historique complet faisait facturer le plus de tokens de toutes les branches, près de 296k par tour dont 97% en succès de cache, et il ressortait quand même le moins cher à 0,0063 $ par tour. Sur une conversation de 36 tours, ça fait 1,78 million de tokens envoyés. Toutes les alternatives coûtaient plus cher pour envoyer moins : la configuration agressive 0,0133 $, la configuration de production qui résume 0,0196 $, la mémoire de profil 0,0235 $. Deux à quatre fois le prix.
Et le context rot, alors? Pour notre tâche, il ne s’est à peu près pas manifesté, et l’histoire de comment on l’a appris est un bon avertissement. Notre premier run sur le context rot montrait un rappel au milieu du contexte qui s’effondrait passé 200k tokens, exactement le résultat que tout le monde attend, donc on a presque publié ça comme un constat. C’était un artefact de notre propre plafond de réponse : on avait limité les réponses à 300 tokens, et le modèle se faisait couper avant d’arriver au fait.
Une fois corrigé, le rappel des faits distinctifs, noms de code et dates, tenait jusqu’à 800k tokens de contexte avec la recherche désactivée. Les faits ambigus ont bel et bien baissé, environ de moitié, donc ce n’est pas gratuit. Et le détail rassurant : les erreurs étaient le modèle qui refusait de répondre plutôt que d’inventer avec aplomb. Le mur dur est réel par contre. Passé un million de tokens, DeepSeek rejette la requête au complet au lieu de compresser discrètement pour la faire entrer.
Donc trouver un détail enfoui est exactement ce dont un tuteur a besoin, et cette tâche est facile pour les modèles modernes même dans d’énormes contextes. Le raisonnement sur un long historique est un problème d’agent de code. Sachez laquelle est la vôtre.
Puis le tournant économique. Pas cher par tour ne veut pas dire pas cher à l’échelle : à 100k ou 1M de tours par jour, même DeepSeek atterrit entre 18 000 $ et 180 000 $ par mois. Plus près de nous, à quelques milliers d’étudiants et environ 10k tours par jour, le même calcul donne autour de 34 000 $ par mois sur Gemini contre 1 900 $ sur DeepSeek. Le changement de modèle est de loin le plus gros levier disponible. Passé ça, c’est la facture au token qui vous pousse vers votre propre matériel.
Et c’est là que tout bascule. Le matériel local veut dire un petit modèle, et sur le MacBook qu’on a testé, une fenêtre de contexte de 32k. Nos leçons à elles seules sont plus grosses que ça, et les étudiants collent des logs qui dépassent. Si le contexte ne rentre pas, il n’y a rien à mettre en cache, et toute la stratégie du tout garder s’évapore. Essayez de garder le contexte complet et il se fait tronquer, à chaque tour. Forcées de compacter, toutes les techniques ont atterri dans une triste plage de 27 à 40% de mémoire, et passer d’un modèle 7B à un 32B sur une machine bien plus grosse n’en sortait pas. C’est la fenêtre la limite, pas le modèle.
Pour les documents, par contre, le local a une réponse propre : récupérez, ne bourrez pas. Bourrer une longue leçon dans la fenêtre débordait à toutes les tailles de modèle et retournait un bout de réponse d’un seul token après environ 340 secondes de préremplissage. Le RAG répondait à 100% en 25 à 65 secondes, environ cinq fois le débit, à partir d’un contexte d’environ 3k tokens au lieu de 38k.
Et si vous récupérez, rendez ça hybride. Ce résultat est la raison pour laquelle je vais répéter « gardez un chemin par mots-clés » jusqu’à ce que les gens en soient écœurés : la recherche dense seule tenait environ 80% de rappel sur les faits enfouis jusqu’à 200k de corpus, puis s’écrasait à 0% à 400k, parce que le reclasseur ne faisait jamais remonter l’aiguille parmi des centaines d’extraits. Un nom de code inventé ne veut à peu près rien dire pour un embedding. La recherche par mots-clés BM25 tenait 100% partout où on a testé. Notre configuration hybride de production existe à cause de graphiques comme celui-là.
Côte à côte, le local n’égale pas le cloud sur la mémoire de conversation, environ un tiers contre un peu plus de 90% du côté du cloud, et un premier token peut prendre de 20 à 350 secondes. Ces chiffres de mémoire sont directionnels plutôt qu’un vrai duel apparié, et la diapositive le disait en note de bas de page, ce que j’apprécie plus qu’un graphique à l’air propre. Ce que le local livre vraiment, c’est une facture au token à zéro et des questions-réponses privées sur documents par RAG avec une précision complète. Le local, c’est une question de confidentialité et de débit. À notre échelle, ce n’est pas une question de coût.
Le seul chiffre qui tranche pour vous
Après tous ces runs, on est arrivés à une règle que je peux vraiment vous donner, et elle est venue du fait de refacturer des traces existantes plutôt que de lancer quoi que ce soit de neuf.
Prenez les mêmes runs enregistrés, tout garder contre compacter, et facturez-les aux tarifs de différents fournisseurs. Aux prix de DeepSeek, où l’entrée en cache coûte 0,0028 $ par million de tokens, tout garder gagne de 13%. Refacturez les traces identiques aux tarifs de pointe où l’entrée en cache tourne à 0,50 $ par million, et les deux branches font essentiellement match nul. Les lectures de cache passent d’environ un quart de la facture à 60% de celle-ci. Résolvez pour le point de croisement et vous obtenez un seuil : garder l’historique complet gagne tant que l’entrée en cache coûte moins qu’environ 0,55 $ par million de tokens.
Ce seul chiffre fait beaucoup de travail. DeepSeek se situe deux cents fois en dessous, ce qui explique pourquoi tout garder n’est même pas serré là. Les modèles de pointe se situent pile dessus, ce qui explique pourquoi la réponse bascule selon la longueur de la conversation : dans cette refacturation, l’historique complet gagnait encore une session de 22 tours et perdait celle de 36 tours. Aucune falaise tarifaire là-dedans, juste un historique plus long qui franchit la ligne.
Alors allez vérifier le prix d’entrée en cache de votre fournisseur avant d’écrire une seule ligne de code de summarisation. Cette seule vérification vous en dira plus que n’importe quel billet de blogue, celui-ci compris.
Ce qu’on fait rouler maintenant, et ce que vous devriez en retenir
Après tout ça, la configuration de notre tuteur est presque anticlimatique, ce que je considère comme un compliment envers le processus. Modèle : DeepSeek V4 Flash, un modèle cloud avec cache, parce que le caching fait de tout garder l’option la moins chère à notre volume. Recherche : hybride, dense plus BM25 plus reclassement. Mémoire : tout garder, avec un plafond stable sur chaque sortie d’outil pour que le contexte grandisse lentement sans jamais être réécrit. L’effacement de sorties d’outils est désactivé. Le seuil de summarisation, qui se déclenchait avant à 30k tokens, est maintenant à 800k, ce qui veut dire en pratique qu’il ne se déclenche presque jamais. Nos longues sessions culminent autour de 287k, donc je vais être honnête : ce seuil de 800k reste lui-même non validé en production. C’est un garde-fou qu’on n’a pas touché, pas un paramètre réglé.
La leçon transférable : ne compactez pas par défaut. Nommez d’abord la contrainte. Si le contexte ne rentre pas dans la fenêtre, vous êtes en territoire de modèle local, donc récupérez. Si la facture ne tient pas l’échelle, comparez votre prix d’entrée en cache à ce seuil de 0,55 $ et passez à un modèle avec cache moins cher avant de sortir les résumés. Si la qualité se dégrade vraiment, mesurez où, parce que la nôtre tenait jusqu’à 800k sur la tâche qui comptait. Trois contraintes différentes, trois correctifs différents, et un seul d’entre eux est la compaction. Et quand vous avez vraiment besoin de réduire le contexte, commencez par l’étage qui n’a pas besoin de modèle : plafonner, tronquer, rogner. Réduisez le préfixe, ne le réécrivez pas.
Le dépôt contient l’agent complet, l’outillage de la base de connaissances et le harnais d’évaluation, y compris le journal des constats où chacun de ces résultats est écrit dans l’ordre, corrections incluses. L’espace Hugging Face contient le tuteur en direct et chaque expérience, y compris celles qui n’entraient pas dans la présentation. Les diapositives sont publiques aussi. Et si vous voulez bâtir exactement ce tuteur de bout en bout, évaluations comprises, c’est ce que notre formation Full Stack AI Engineering parcourt sur environ 60 heures pratiques. Ce texte va bien avec mon article précédent sur le long contexte contre le RAG, qui posait la question à laquelle ces expériences ont fini par répondre avec des reçus.
Alors mesurez sur votre propre système, avec les questions de vos propres utilisateurs. Chaque réglage confiant qu’on avait livré, le seuil d’effacement à 5k, le résumeur à 30k, le bel outil de fouille, avait l’air intelligent et a perdu contre ne rien faire ou faire moins. Pire, les pertes étaient invisibles de l’extérieur, parce que le tuteur continuait d’écrire des réponses qui avaient l’air bonnes tout en oubliant des choses en silence. Je préfère apprendre ça d’une facture d’évaluations que d’un étudiant qui demande un remboursement.
C’est quoi la contrainte dans votre système : la fenêtre, la facture, ou une vraie dégradation? Sincèrement curieux de savoir combien d’entre vous payez la taxe de la summarisation sans l’avoir mesurée. Merci d’avoir passé ce temps ici, et on se retrouve dans la prochaine.
FAQ
Qu'est-ce que le context engineering?
Le context engineering consiste à décider ce que le modèle voit à chaque appel : le prompt système, les définitions d'outils, l'historique de conversation, les anciennes sorties d'outils, les documents récupérés et la question de l'utilisateur se disputent tous un seul budget d'attention limité. Ça couvre la gestion du contexte à l'intérieur d'une session et la mémoire persistante entre les sessions. C'est le prompt engineering devenu adulte, avec la compaction, la mémoire et la recherche sous un même toit.
Devrais-je compacter ou résumer l'historique de mon agent?
Pas par défaut. Dans nos évaluations, la summarisation a fait chuter le rappel mémoire en session de 92% à environ un tiers tout en coûtant à peu près deux fois plus cher que de tout garder, parce que réécrire l'historique casse le cache du fournisseur. Compactez seulement quand vous pouvez nommer la contrainte : le contexte ne rentre pas dans la fenêtre, l'entrée en cache coûte assez cher pour que renvoyer ne soit plus économique, ou la qualité se dégrade de façon mesurable.
Pourquoi le prompt caching rend-il la summarisation coûteuse?
Les fournisseurs facturent beaucoup moins les tokens qu'ils ont déjà traités, jusqu'à environ 50 fois moins chez DeepSeek et autour de 90% de rabais chez Gemini. Ce rabais s'applique seulement quand le contexte précédent est renvoyé inchangé. Résumer réécrit ce préfixe, donc le cache rate et chaque token est refacturé plein prix. Pour qu'une summarisation soit rentable face à un rabais de cache de 50 fois, elle doit réduire énormément le contexte sans perdre les détails dont vous avez besoin.
Y a-t-il une technique de compaction qui reste payante?
Oui, la sorte pas chère. Plafonner chaque sortie d'outil à une taille fixe avant qu'elle entre dans l'historique a coupé notre coût par tour de 38% dans une comparaison appariée, a gagné dans 14 trajectoires sur 15, et a laissé la précision aux sondes de mémoire identique, parce qu'un plafond stable réduit le contexte sans réécrire le préfixe dont dépend le cache. La troncature, le rognage et l'effacement sont au même étage et ne demandent aucun appel de modèle.
Le context rot est-il un vrai problème?
Ça dépend de la tâche. Les modèles perdent effectivement des faits enfouis dans de longs contextes sur certaines tâches, et le graphique classique est brutal : la précision au milieu d'une longue fenêtre peut tomber sous ce que le même modèle obtient sans aucun document. Mais sur notre tâche à nous, le rappel des faits distinctifs tenait jusqu'à 800k tokens de contexte, et les erreurs étaient le modèle qui refusait de répondre plutôt que d'inventer. Les faits ambigus ont baissé de moitié environ, donc le facteur déterminant était l'ambiguïté plus que la longueur.
Quand un modèle local vaut-il la peine pour un produit à base d'agents?
Quand la confidentialité ou l'économie par token vous y forcent, pas avant. À 100k ou 1M de tours par jour, même une API pas chère comme DeepSeek atterrit entre 18 000 $ et 180 000 $ par mois, et c'est là que posséder le matériel commence à se défendre. Mais un modèle local sur du matériel grand public veut dire une petite fenêtre de contexte, 32k dans nos tests, donc tout garder cesse de fonctionner et vous devez récupérer. Le RAG local répondait aux questions sur documents à 100% dans nos runs, alors que bourrer la fenêtre débordait à toutes les tailles de modèle.
Comment savoir si la compaction nuit discrètement à mon agent?
Ne faites pas confiance à un score de qualité global, parce que le nôtre restait entre 97% et 99% alors que le rappel mémoire était à 58%. Plantez un fait précis tôt dans une session, faites grandir la conversation au-delà de votre seuil de compaction, puis sondez pour ce fait exact et notez seulement celui-là. Sur les tours où notre tuteur avait perdu le fait, un juge à l'aveugle trouvait quand même la réponse bonne à chaque fois. Le mode de défaillance est une réponse bien formée qui ignore silencieusement ce que l'utilisateur vous a dit.