Claude Code répond trois fois plus vite, et le mérite revient à gzip, un outil né en 1992

Anthropic annonce que Claude Code commence à répondre trois fois plus vite qu’en août. Aucun nouveau modèle derrière ce gain : l’outil compresse désormais ce qu’il envoie avec gzip, un format publié en octobre 1992, et les sessions cloud démarrent dès la première frappe.

L’essentiel

• En local, l’attente avant le premier token (p90, hors temps de calcul du modèle) passe de 4,07 s à 1,33 s.
• Depuis la version 2.1.300 du 14 octobre 2026, les grosses requêtes vers l’API partent compressées en gzip, même télémétrie désactivée.
• La variable CLAUDE_CODE_GZIP_REQUEST_BODIES=0 coupe cette compression en cas de souci.
• Les tokens facturés et la fenêtre de contexte ne bougent pas : seuls les octets transférés diminuent.
• Les sessions cloud tombent de 16,99 s à 6 s, car le conteneur se lance pendant que vous tapez.

Le modèle n’était pas le goulot d’étranglement

À chaque tour, Claude Code renvoie à l’API l’intégralité de la conversation : vos messages, les réponses, le contenu des fichiers lus, les sorties de commandes. Rien n’était compressé jusqu’ici. Sur une longue session, chaque requête pèse entre 500 Ko et plus de 1 Mo.

Le problème avait été documenté le 28 août 2026 dans une demande ouverte sur le dépôt GitHub de Claude Code. Son auteur y détaille ses relevés : un corps de requête de 594 750 octets descend à 289 145 octets une fois compressé, un rapport d’environ 2,1. Sur trois heures d’utilisation courante, une seule machine a évité 185 Mo d’envoi. La compression gzip au niveau 6 ne coûte que quelques millisecondes par requête.

Sur une connexion montante lente (une 4G en partage de connexion, une box ADSL, un Wi-Fi d’hôtel), ce transfert passe avant même que le modèle lise le premier mot de votre demande. Diviser le volume par deux raccourcit directement cette attente.

Les chiffres d’Anthropic, surface par surface

Anthropic a publié ses relevés comparant août et octobre 2026 sur le compte ClaudeDevs. Les indicateurs ne sont pas les mêmes selon les lignes, ce qui interdit de comparer les surfaces entre elles.

Le p90 décrit les 10 % de requêtes les plus lentes, celles qui donnent l’impression d’un outil qui rame. C’est là que gzip pèse le plus, puisque les sessions longues produisent les requêtes les plus lourdes.

Côté cloud, le gain vient surtout d’un autre levier : le conteneur qui exécute la session démarre dès que vous commencez à taper, au lieu d’attendre l’envoi du message.

Ce chantier prolonge celui du mois précédent. Anthropic avait alors revendiqué des applications web et bureau trois fois plus rapides, après un sprint de deux semaines et plus de 3 000 modifications fusionnées. Au 75e percentile, le chargement de Claude.ai jusqu’à une page où l’on peut écrire était passé de 3,1 s à 0,55 s. La course à la vitesse n’a rien de neuf chez l’éditeur, qui mettait déjà en avant la rapidité de Claude 3.5 Haiku fin 2024.

Pourquoi gzip, et pas Brotli ou Zstandard ?

Brotli et Zstandard compressent mieux le texte que gzip, et plus vite pour Zstandard. Le choix ne s’est pas fait sur la performance mais sur la compatibilité. Dans les tests rapportés sur GitHub en août, l’API d’Anthropic acceptait les corps de requête en gzip, mais renvoyait une erreur 400 Bad Request pour zstd, br et deflate. Gagner quelques octets supplémentaires ne sert à rien si le serveur ne sait pas les décoder.

Gzip a été écrit par Jean-loup Gailly et Mark Adler, et publié le 31 octobre 1992. Il devait remplacer le programme compress, dont l’algorithme LZW était couvert par des brevets d’Unisys et d’IBM. Son format est décrit dans la RFC 1952 et repose sur l’algorithme DEFLATE. Trente-quatre ans plus tard, presque tous les serveurs web et les bibliothèques HTTP le comprennent. C’est précisément ce qui en fait le choix le plus sûr pour un outil installé sur des millions de postes.

Ce que vous avez à faire : presque rien

La compression est active par défaut. Trois vérifications suffisent :

1. Contrôlez votre version avec claude --version. Il faut la 2.1.300 ou une version ultérieure.
2. Si vous passez par un proxy d’entreprise, une passerelle API ou un ANTHROPIC_BASE_URL maison, vérifiez qu’il accepte les requêtes avec l’en-tête Content-Encoding: gzip. Certains intermédiaires mal configurés les rejettent ou les altèrent.
3. En cas d’erreurs inexpliquées après la mise à jour, coupez la compression le temps du diagnostic :

bash

export CLAUDE_CODE_GZIP_REQUEST_BODIES=0

Un point à garder en tête : la compression agit sur le transport, pas sur le contenu. Le modèle reçoit exactement le même texte, donc le nombre de tokens facturés ne change pas, ni la consommation de la fenêtre de contexte. Si votre facture ou vos limites d’usage vous préoccupent, gzip n’y change rien. C’est une différence de nature avec les optimisations de prompt ou de cache.

Les développeurs qui tirent le plus de bénéfice de la mise à jour sont ceux qui travaillent en mobilité, avec un débit montant faible, sur des sessions longues. Sur une fibre symétrique, le gain existe mais se remarque moins. La même logique vaut pour tous les assistants de code qui renvoient tout leur contexte à chaque échange, de Claude Code à GitHub Copilot.

La prochaine seconde à gagner sera plus dure

Gzip a réglé un problème de tuyauterie. Il reste 1,33 s d’attente en local au p90, et le principe de départ demeure : Claude Code renvoie toujours toute la conversation à chaque tour, simplement sous une forme plus compacte. Pour aller plus loin, il faudra réduire ce que l’outil envoie, et non plus seulement la façon dont il l’emballe. Le gain de cette mise à jour aura été obtenu avec un logiciel de 1992 : la suite demandera sans doute plus qu’un format de compression.