Prompt caching ou compression de tokens : lequel réduit le plus ?

Fait partie de : Réduire l'utilisation de tokens des agents de coding IA. Le mode d'emploi du caching lui-même se trouve dans Prompt caching : comment réduire votre facture d'input ; cette page est la comparaison.

Prompt caching ou compression de tokens, en une phrase

Le caching rend chaque token moins cher à relire ; la compression fait qu'il y a moins de tokens à lire. Ce ne sont pas des concurrents, et vous voulez les deux. Le seul vrai conflit entre eux, c'est un compresseur mal placé qui réécrit du contenu déjà en cache, et transforme une remise en surcoût.

Les prix et règles de cache des fournisseurs cités ici ont été lus dans la documentation d'Anthropic et d'OpenAI le 15 octobre 2026. Le seul chiffre Tokenade de cette page vient du benchmark THOL, dont la méthode est décrite sur la page méthodologie.

Comment je les ai comparés

J'ai regardé ce que chaque levier fait à une ligne précise de la facture d'un vrai agent, pas les pourcentages d'accroche. Une session d'agent a quatre lignes : écritures de cache, lectures de cache, input hors cache et output.

Je développe un optimiseur de tokens, j'ai donc un parti pris. Les chiffres de caching sont les tarifs publiés par les fournisseurs, attribués et datés. Les calculs sont illustratifs, avec les hypothèses affichées pour que vous puissiez les refaire avec vos propres logs.

Que réduit vraiment le prompt caching ?

Il réduit le prix unitaire des tokens que le fournisseur a déjà vus, et rien d'autre. Le fournisseur stocke un préfixe tokenisé de votre requête ; la requête suivante qui commence par les mêmes octets relit ce préfixe à prix réduit.

D'après la documentation prompt caching d'Anthropic (lue le 15 octobre 2026), les tarifs sur Claude Opus 5.5 sont :

• Input de base : 4 $ par million de tokens (MTok).
• Écriture de cache 5 minutes : 5 $/MTok, soit 1,25x l'input.
• Écriture de cache 1 heure : 8 $/MTok, soit 2x l'input.
• Lecture en cache : 0,20 $/MTok, soit 0,05x l'input. Anthropic indique 0,1x comme multiplicateur standard pour la plupart des autres modèles.

Le guide prompt caching d'OpenAI (lu le 15 octobre 2026) distingue désormais les générations. À partir de GPT-5.6, OpenAI facture l'écriture de cache 1,25x le tarif d'input hors cache et la lecture 0,1x sur la plupart des modèles. GPT-5.5 n'a pas de surprime d'écriture. La durée de vie est d'au moins 30 minutes sur GPT-5.6+, contre 5 minutes par défaut chez Claude, renouvelée à chaque lecture.

Ce que le caching ne touche pas compte tout autant :

• Les nouveaux tokens. Un résultat d'outil qui entre dans la conversation pour la première fois est facturé plein pot, en écriture de cache.
• L'output. La génération est toujours facturée au tarif d'output.
• La fenêtre de contexte. Un token en cache occupe quand même une place dans la fenêtre. 150 000 tokens en cache, ce sont 150 000 tokens de contexte.
• Les démarrages à froid. Quand le TTL expire, tout le préfixe est réécrit au tarif d'écriture.

Que réduit la compression de tokens ?

Elle réduit le nombre de tokens qui entrent dans la conversation. Sur un agent IA de développement, ce volume entrant est dominé par trois sources dont le modèle n'a jamais eu besoin en entier.

• Les sorties de commandes. Une suite de tests, un build, un git log : des milliers de lignes, dont le modèle a besoin des échecs. C'est le filtrage de sortie.
• Les lectures de fichiers. L'agent ouvre un fichier de 2 000 lignes pour en modifier quatre. Une lecture par la structure et la recherche sémantique renvoient la partie demandée.
• Les manifestes MCP. Les définitions d'outils de chaque serveur connecté voyagent à chaque tour, utilisées ou non.

La compression travaille sur un autre axe que le caching. Elle ne se soucie pas de savoir si un token est en cache ; elle décide s'il existe. Chaque token qu'elle retire n'est jamais écrit en cache, jamais relu, et ne prend jamais de place dans la fenêtre.

Pourquoi le caching seul laisse le vrai coût en place

Parce que le cache fait payer moins cher les relectures, mais il les multiplie toujours : chaque token que vous laissez entrer est payé une fois au tarif d'écriture, puis à chaque tour jusqu'à la fin de la session ou au compactage. Voici un log de tests suivi sur une session Opus 5.5.

Hypothèses illustratives : un log de tests de 12 000 tokens arrive au tour 10 d'une session de 50 tours, le cache reste chaud, tarifs ci-dessus.

Le caching fait le gros du travail sur la première marche ; personne ne devrait s'en passer. Mais sur la deuxième, la facture de ce log reste dix fois plus élevée que nécessaire, et les 12 000 tokens occupent toujours la fenêtre de contexte pendant ces 40 tours.

Ce coût de fenêtre, le caching ne peut pas l'atteindre. Une fenêtre plus pleine, c'est un compactage qui arrive plus tôt, et le compactage reconstruit de zéro la couche conversation du cache. Un gros préfixe rend aussi chaque démarrage à froid plus cher : après une pause, 150 000 tokens réécrits à 5 $/MTok, c'est 0,75 $ avant que l'agent ait fait quoi que ce soit.

L'ordre des opérations est donc : mettre en cache tout ce qui est stable, puis arrêter de laisser entrer ce qui n'avait pas besoin d'y être. Comment la fenêtre de contexte pilote votre facture de tokens détaille le côté fenêtre.

Sur le benchmark THOL, Tokenade réduit de 39 % le coût des longues sessions, par rapport à l'absence d'optimiseur.

Le piège : la compression qui casse le préfixe en cache

Tout compresseur qui réécrit du contenu déjà envoyé au modèle invalide le cache à partir de ce point, et vous repayez l'écriture sur tout ce qui suit. Le cache est une correspondance de préfixe. Un octet modifié près du début, et chaque token en dessous devient un cache miss.

La documentation d'Anthropic est explicite sur la hiérarchie : le cache se construit dans l'ordre tools, puis system, puis messages, et un changement à un niveau invalide ce niveau et tous les suivants. Modifier des définitions d'outils — noms, descriptions, paramètres — invalide tout le cache.

Les pratiques de compression qui tombent dans ce piège :

• Résumer ou élaguer d'anciens résultats d'outils sur place. Ça ressemble à une économie. Ça réécrit le milieu de l'historique.
• Changer les définitions d'outils MCP en cours de session. Ajouter, retirer ou compresser une description d'outil après la première requête modifie le haut du préfixe.
• Recompresser les fichiers mémoire ou les instructions système entre deux tours. Même problème, un niveau plus haut.
• Injecter du texte dynamique en tête : horodatages, compteurs de tokens, bandeaux « économies réalisées ».

Chiffrons le premier. Vous élaguez 20 000 tokens d'un historique en cache de 100 000 tokens sur Opus 5.5. Les 80 000 restants doivent être réécrits : 0,40 $. Votre gain, c'est 20 000 lectures en cache de moins par tour : 0,004 $ par tour. Il faut environ 95 tours de plus pour rentrer dans vos frais. La plupart des sessions se terminent, ou se compactent, bien avant.

Claude Code lui-même est construit autour de cette contrainte. Sa documentation sur le prompt caching (lue le 15 octobre 2026) indique qu'il conserve la liste d'outils de la première requête pendant toute la conversation, et qu'un serveur MCP qui se connecte plus tard fournit ses outils sous forme de définitions différées, chargées à la demande. L'outil évite de toucher au préfixe ; votre optimiseur devrait faire pareil.

La règle que j'impose à Tokenade est simple : compresser à l'entrée, ne jamais réécrire au retour. Il compacte un résultat d'outil à la frontière de l'outil, avant que ce résultat ne fasse partie de la conversation. Une fois qu'un token est dans le préfixe en cache, la chose la moins chère à faire, c'est de ne plus y toucher.

Quand le caching est-il le bon levier, et quand est-ce la compression ?

Le caching gagne quand le même gros bloc est relu de nombreuses fois ; la compression gagne quand de gros blocs n'arrêtent pas d'arriver. La plupart des sessions d'agent ont les deux profils, d'où la réponse habituelle : les deux.

Le caching fait l'essentiel du travail quand :

• Le préfixe est gros et stable : long system prompt, schémas d'outils fixes, docs épinglées.
• Les appels arrivent en rafales rapprochées, dans le TTL.
• Vous maîtrisez la structure de la requête — voir le mode d'emploi.

La compression fait l'essentiel du travail quand :

• L'agent lance des commandes bavardes : tests, builds, installations, logs.
• Il lit des fichiers entiers pour en modifier quelques lignes.
• Vous avez plusieurs serveurs MCP connectés et n'utilisez que quelques-uns de leurs outils.
• Les sessions sont assez longues pour que la pression sur la fenêtre, plus que le prix par token, soit ce qui fait mal.

Lequel choisir ?

• Développeur d'API avec un system prompt fixe et des appels courts : le caching d'abord ; la compression compte moins.
• Utilisateur de Claude Code, Codex ou Cursor sur de longues sessions : les deux — le caching est déjà actif dans l'outil, la compression est donc le levier qui reste.
• Gros utilisateur de MCP : la compression pour les manifestes, et vérifiez que rien ne recharge les définitions d'outils en cours de session.
• Vous comparez des optimiseurs : demandez à chacun s'il lui arrive de réécrire du contenu déjà envoyé. Les meilleurs optimiseurs de tokens pour Claude Code classe le terrain sur le coût de session mesuré.

FAQ

La compression de tokens casse-t-elle le prompt caching ?

Seulement si elle réécrit du contenu que le modèle a déjà vu. Compresser un résultat d'outil avant qu'il n'entre dans la conversation ne pose aucun problème : c'est la version compressée qui est mise en cache. Résumer d'anciens tours, modifier des définitions d'outils ou recompresser le system prompt en cours de session change le préfixe et force une nouvelle écriture de cache sur tout ce qui suit.

Si une lecture en cache coûte 0,05x à 0,1x, la compression vaut-elle encore le coup ?

Oui, pour trois raisons. Chaque nouveau token est d'abord facturé en écriture de cache, à 1,25x l'input chez Claude et sur GPT-5.6+. Les tokens en cache sont relus à chaque tour suivant, donc la remise est multipliée par la longueur de la session. Et les tokens en cache remplissent quand même la fenêtre de contexte, ce qui avance le compactage.

Claude Code utilise-t-il déjà le prompt caching ?

Oui, automatiquement. Sa documentation indique que les abonnés bénéficient d'un TTL d'une heure sur la conversation principale dans les limites de leur forfait, et les utilisateurs d'une clé API de cinq minutes. Le caching étant déjà actif, le levier qui reste pour la plupart des utilisateurs de Claude Code, c'est le volume de ce qui entre dans le contexte.

Le prompt caching réduit-il les output tokens ?

Non. Le caching ne s'applique qu'à l'input. L'output est facturé plein tarif quel que soit l'état du cache, ce qui explique que ni le caching ni la compression de l'input ne remplacent des réponses courtes du modèle, là où c'est acceptable.

Voir aussi

• Prompt caching : comment réduire votre facture d'input — le mode d'emploi : structure, breakpoints, TTL.
• Comment la fenêtre de contexte pilote votre facture de tokens — pourquoi une fenêtre en cache reste une fenêtre chère.
• Claude Code /compact : ce qu'il coûte et ce qui survit — ce que le compactage fait au cache.
• Filtrage de sortie : alléger les logs de commandes pour les agents — le plus gros gain de compression sur la plupart des sessions.
• Les meilleurs optimiseurs de tokens pour Claude Code — le classement du terrain.