Compaction ou optimiseur de tokens : ce que chacun économise

La compaction native et un optimiseur de tokens ne sont pas concurrents : la compaction nettoie le contexte une fois qu'il est plein, l'optimiseur ralentit la vitesse à laquelle il se remplit. Utilisez les deux. Si vous ne pouvez changer qu'une chose, changez ce qui entre dans le contexte, car la compaction ne rembourse jamais les tours déjà payés.

La distinction paraît théorique jusqu'à ce qu'on regarde une longue session. Un log de tests de 20 000 tokens arrivé au tour 10 voyage dans chaque requête jusqu'à la prochaine compaction. /compact finit par le réduire à une phrase. Il ne fait rien pour les trente tours qui l'ont transporté en entier.

Cette page fait partie du pilier réduire la consommation de tokens de Claude Code. Pour la mécanique de coût de /compact lui-même (cache chaud, cache froid, ce qui survit), lisez d'abord /compact dans Claude Code : ce que ça coûte, ce qui survit. Je ne la répète pas ici.

Compaction ou optimiseur de tokens : l'essentiel

Comportement de /compact, de l'auto-compact et de la compaction en veille : lu dans la documentation de Claude Code (fenêtre de contexte, coûts, référence des réglages) et celle de Codex (référence de configuration, commandes slash), consultées le 15/10/2026. Chiffre Tokenade : benchmark THOL, méthodologie ici.

Comment je les ai comparés

Je développe Tokenade, gardez-le en tête en lisant. J'ai comparé les deux sur quatre questions : à quel moment chacun agit, ce qu'il retire, ce qu'il coûte à faire tourner, et ce que le modèle y perd.

Je n'ai pas comparé de pourcentages d'économie. La compaction n'a pas d'« économie » unique à citer : tout dépend de la taille de l'historique et de ce que le résumé a gardé. Le seul chiffre mesuré de cette page est celui de Tokenade, et c'est un coût de session complète, pas un gain par outil.

Ce que fait réellement la compaction native

La compaction remplace l'historique de la conversation par un résumé écrit par le modèle. Claude Code la lance quand vous tapez /compact, automatiquement « à l'approche de la limite, pour qu'une fenêtre de contexte pleine ne mette pas fin à votre session », selon la documentation sur la fenêtre de contexte, et aussi pendant que vous êtes absent.

Ce dernier cas, c'est la compaction en veille. La référence des réglages indique qu'elle compacte une longue conversation « peu avant l'expiration de son cache de prompt », après environ 54 minutes d'inactivité, sur les sessions au cache d'une heure dont le contexte a dépassé un seuil fixé par défaut à 200 000 tokens. Votre message suivant envoie alors un résumé au lieu de toute la conversation.

Codex a la même paire de mécanismes. Sa liste de commandes slash décrit /compact comme « résumer la conversation visible pour libérer des tokens », et la référence de configuration expose model_auto_compact_token_limit, le « seuil de tokens qui déclenche la compaction automatique de l'historique », non défini par défaut pour que chaque modèle applique sa propre valeur.

Claude Code fait aussi un ménage plus fin. La page des coûts mentionne l'effacement des « anciens résultats d'outils du contexte » et compte l'échec de cache qui en résulte comme une reconstruction attendue. Même famille : on retire un contenu déjà entré, donc déjà facturé.

Ce que fait réellement un optimiseur de tokens

Un optimiseur de tokens traite chaque résultat d'outil avant que le modèle ne le voie. Rien n'est résumé après coup. La sortie de commande, la lecture de fichier ou le manifeste d'outils arrive déjà réduit, et le reste à chaque tour suivant qui le renvoie.

Tokenade le fait avec des hooks sur les appels d'outils de l'agent, ou un proxy local quand l'agent n'a pas de hooks exploitables. Concrètement :

• Les sorties de commandes sont filtrées : barres de progression, lignes répétées et tests qui passent disparaissent, les erreurs et leur entourage restent. Voir le filtrage des sorties de commandes.
• Les lectures de fichiers reviennent structure d'abord, signatures avant les corps, quand l'agent a seulement besoin de s'orienter. Voir la compression squelette des lectures de fichiers.
• Les manifestes MCP sont différés sur les agents qui chargent toutes les descriptions d'outils d'emblée. Claude Code diffère désormais les définitions d'outils MCP par défaut, selon sa page des coûts, donc le gain y est moindre.

Anthropic recommande la même idée, à la main. La page des coûts suggère un hook qui cherche ERROR dans un log au lieu de laisser Claude lire 10 000 lignes, et parle de réduire le contexte « de dizaines de milliers de tokens à quelques centaines ». C'est leur exemple, sur un log, pas un chiffre de session. Un optimiseur de tokens, c'est ce hook, écrit pour tous les outils courants.

Ce que chacun économise

La compaction économise les tokens de tout ce qui vient après elle ; un optimiseur en économise à chaque tour, dès le premier. Cette différence de moment, c'est toute la comparaison.

Chaque tour renvoie la conversation entière, et c'est pour ça que la fenêtre de contexte fait votre facture. Un gros résultat d'outil est donc payé une fois à son arrivée, puis à chaque tour suivant, surtout au prix de lecture du cache, jusqu'à ce que quelque chose le retire.

La troisième ligne s'oublie facilement. La compaction est elle-même une requête au modèle qui lit tout votre historique, au prix du cache s'il est chaud, au prix plein sinon. L'article sur /compact donne le calcul. Un optimiseur tourne sur l'ordinateur où vous travaillez et n'appelle jamais le modèle.

Voici la partie mesurée. Sur le benchmark THOL publié, Tokenade réduit le coût des longues sessions de 39 %, par rapport à aucun outil. La mise en place des sessions et du groupe témoin est décrite sur la page méthodologie.

Ce que chacun perd

La compaction perd des détails dont vous ignoriez avoir besoin ; un optimiseur perd ceux que le filtre a jugés inutiles. Les deux sont avec perte. Ils échouent différemment.

La compaction est la plus risquée des deux, pour trois raisons :

• Elle résume au pire moment. Le billet d'Anthropic sur la gestion des sessions note qu'« à cause du context rot, le modèle est au plus bas de son intelligence au moment de compacter ». Voir context rot.
• Elle abandonne des catégories entières par conception : règles limitées à des chemins, fichiers CLAUDE.md imbriqués, contexte injecté par des hooks, et le contenu de tout fichier relu de plus de 5 000 tokens, selon la documentation sur la fenêtre de contexte.
• Elle ne peut pas deviner où vous allez. Un avertissement ignoré au tour 12 a disparu quand vous posez la question au tour 40.

Le risque d'un optimiseur est plus étroit : il retire une ligne de log ou le corps d'une fonction dont l'agent avait vraiment besoin. L'agent relance alors la commande ou relit le fichier, ce qui coûte un tour. Tokenade garde la sortie complète sur votre ordinateur et laisse l'agent la récupérer par référence : un mauvais filtre coûte une consultation, pas une relance.

L'optimiseur a aussi un argument de qualité. Un contexte avec moins de bruit se dégrade plus lentement, donc le résumé que vous finissez par obtenir est écrit par un modèle plus lucide.

Pourquoi ils se cumulent

Ils agissent à des moments différents sur des contenus différents, donc aucun n'annule l'autre. L'optimiseur réduit ce que chaque tour ajoute. La compaction remet à zéro ce qui s'est accumulé. Avec les deux, vous avez des tours plus légers, une montée plus lente, et des compactions moins nombreuses et moins chères.

Imaginez la courbe de la taille du contexte au fil d'une session. Sans optimiseur, elle monte vite, touche le seuil d'auto-compact, retombe, remonte. Avec, la pente est plus douce. Le seuil arrive plus tard, vous compactez moins souvent, et chaque compaction lit un historique plus court.

Rien ne change côté compaction native. Laissez l'auto-compact et la compaction en veille activés, et continuez à lancer /compact avec une consigne de focus aux pauses naturelles. L'optimiseur change seulement ce que ces mécanismes ont à nettoyer.

Le seul point de contact : ce que l'optimiseur a réduit est aussi ce que la compaction résumera plus tard. Aucun problème. Le résumé d'un log filtré ne vaut pas moins que celui du log brut, et il a coûté moins cher à transporter.

Est-ce différent pour Codex et les autres agents ?

Non, le partage des rôles est le même. Tous les agents de code sérieux ont aujourd'hui une forme de compaction de l'historique, car sans elle une longue session s'arrête net à la limite de fenêtre. Codex a /compact et model_auto_compact_token_limit ; Claude Code a /compact, /autocompact et la compaction en veille.

Ce qui varie, c'est ce que chaque agent fait au niveau des outils. Claude Code diffère les définitions d'outils MCP par défaut ; d'autres chargent chaque manifeste avant votre premier message. Là où l'agent en fait moins, l'optimiseur a plus à gagner.

Si vous travaillez avec un abonnement plutôt qu'une clé API, la même logique vaut pour vos limites. Moins de tokens par tour, c'est une fenêtre de cinq heures qui dure plus longtemps, le sujet de Limites de Claude Code : comment rester en dessous.

Sur lequel compter ?

• Sessions courtes, une tâche chacune : la compaction native suffit, et /clear entre deux tâches fait plus que les deux.
• Longues sessions pleines de builds, de tests et de logs : ajoutez un optimiseur ; c'est là que les sorties d'outils dominent la facture.
• Grosses bases de code où l'agent lit des fichiers entiers : ajoutez un optimiseur pour les lectures structure d'abord.
• Sessions laissées en pause une heure : laissez la compaction en veille travailler, c'est moins cher qu'une compaction à froid.
• Tout le monde : lancez /compact vous-même aux pauses naturelles plutôt que d'attendre le seuil.

FAQ

L'auto-compact suffit-il à contenir les coûts de Claude Code ?

Il garde la session en vie, ce qui est un autre objectif. L'auto-compact se déclenche près de la limite de fenêtre : chaque gros résultat d'outil arrivé avant est renvoyé à chaque tour. Il coûte en plus sa propre requête, qui lit tout l'historique. Il plafonne le contexte ; il ne réduit pas ce que chaque tour ajoute.

Un optimiseur de tokens remplace-t-il /compact ?

Non. Un optimiseur ralentit la croissance du contexte, mais une session assez longue finit quand même par atteindre la limite. Gardez /compact et l'auto-compact activés. Avec un optimiseur, ils se déclenchent simplement moins souvent et résument un historique plus court.

Un optimiseur de tokens peut-il dégrader la compaction ?

Pas en pratique. La compaction résume ce qui se trouve dans le contexte. Si un log a déjà été réduit à ses erreurs, le résumé a moins de bruit à trier. Le vrai risque, c'est que l'optimiseur retire un détail dont l'agent avait besoin, qu'il va alors rechercher.

Codex compacte-t-il comme Claude Code ?

L'idée est la même : une commande /compact qui résume la conversation, plus une compaction automatique à un seuil de tokens réglé par model_auto_compact_token_limit dans config.toml. Sans valeur, Codex applique celle du modèle. Les seuils et ce qui survit varient d'un agent à l'autre, vérifiez la documentation de chacun.

Voir aussi

• /compact dans Claude Code : ce que ça coûte, ce qui survit : la mécanique de coût sur laquelle s'appuie cette page
• Comment la fenêtre de contexte fait votre facture : pourquoi chaque tour renvoie tout
• Le filtrage des sorties de commandes : le levier principal avant le contexte
• La compression squelette des lectures de fichiers : les lectures structure d'abord en détail
• Limites de Claude Code : comment rester en dessous : où les deux interviennent quand vous approchez d'une limite d'abonnement