Un agent avec une fenêtre de 16K atteint 70,2 % sur SWE-bench Verified en réinitialisant son contexte à chaque étape

On a pris l'habitude de penser qu'un agent chargé d'une tâche longue a besoin d'une immense fenêtre de contexte : plus elle est grande, mieux c'est. Un nouveau travail, « You don't need long context » (Belčak, Molchanov et coauteurs), affirme le contraire : une fenêtre courte suffit si l'on construit correctement le harnais, c'est-à-dire la couche d'orchestration autour de l'agent.

Ce que proposent les auteurs

L'idée est simple. Au lieu d'accumuler l'historique de la conversation jusqu'à saturation, le harnais le réinitialise périodiquement et démarre une nouvelle session. Seule une synthèse de travail structurée est transmise. Les gros fichiers ne sont pas chargés intégralement dans le contexte : l'agent cherche ce dont il a besoin avec des utilitaires Bash comme grep et lit par fenêtres limitées.

Il existe deux modes. End-of-Conversation Compaction (EoCC) condense la conversation lorsqu'un seuil de tokens est atteint. Single-Action Compaction (SAC) est plus radical : il réinitialise le contexte après chaque action.

Imaginez un développeur qui corrige un bug dans un grand dépôt. Il ne relit pas toute la base de code à chaque étape. Il tient des notes : ce qu'il a déjà vérifié, ce qui est cassé, ce qu'il a essayé en vain. Ici, c'est la même chose, sauf que c'est le harnais qui tient les notes.

Résultats

Sur des benchmarks à long horizon et à gros documents, la fenêtre courte conserve la précision, et l'améliore parfois. Le coût de décodage sur GPU baisse jusqu'à 7 fois en passant de 256K à 16K tokens. Même dans le mode strict SAC, Claude Opus 4.5 résout 70,2 % des tâches de SWE-bench Verified.

Les auteurs ont aussi eu la bonne idée de décrire le format de la synthèse. Il s'agit d'un handoff brief en six parties : objectif, faits vérifiés séparés des hypothèses, modifications effectuées, vérifications exécutées, impasses et plan des étapes suivantes. Séparer les faits des hypothèses évite qu'une simple supposition, à force d'être reformulée, devienne une « vérité établie ».

Un skill pour Claude Code

L'article ne fournit pas de code. Jemal Khamidoun, des gonzo-obzory, a donc demandé à Claude de construire un skill reproduisant l'approche. Il se trouve dans le dépôt short-context-agent. Le skill apprend à l'agent à ne pas charger les gros fichiers dans le contexte, mais à y chercher et à les lire par fenêtres, et à tenir ce fameux brief lors des tâches longues en plusieurs étapes.

La réinitialisation du contexte reste pilotée par Claude Code : autocompaction par seuil, /compact ou /clear manuels. Un hook du plugin réinjecte le brief et l'agent reprend là où il s'était arrêté. On obtient ainsi le mode EoCC. Le mode SAC n'est pas reproductible dans Claude Code : il n'existe que dans le harnais de référence du dépôt, avec EoCC et une baseline sans compaction. L'auteur prévient honnêtement qu'il n'a pas testé à fond, que des bugs sont possibles et que les PR sont les bienvenues.

Limites

Premièrement, la réinitialisation du contexte casse le cache de prompts. Chaque nouvelle session démarre avec un préfixe froid : vous pouvez donc ne rien économiser, même si le gain GPU au décodage est réel. Le gain d'un facteur 7 concerne le coût de décodage, pas votre facture chez le fournisseur.

Deuxièmement, les modèles ouverts plus faibles peuvent décrocher. Si un modèle est verbeux, il épuise le budget strict de la fenêtre avant d'avoir terminé la tâche. Les résultats obtenus avec Opus 4.5 ne se transposent pas automatiquement à n'importe quel modèle.

Troisièmement, le skill est non officiel et brut : ce n'est pas une implémentation validée par les auteurs.

Que faire en pratique

Si vous construisez des agents, vérifiez trois points. N'obligez pas l'agent à lire intégralement les gros fichiers : qu'il cherche et lise par fenêtres. Mettez en place une synthèse explicite qui sépare les faits des hypothèses. Et calculez le coût réel en tenant compte de la perte du cache, pas seulement la taille de la fenêtre. Pour les modèles auto-hébergés, l'idée est encore plus intéressante : entraîner et exécuter un modèle avec une fenêtre de 16K à 50K est nettement moins cher que de courir après le million de tokens.