Anthropic a publié un post-mortem d'ingénierie détaillé expliquant les six semaines de plaintes sur la qualité de Claude Code qui ont couru de mars à mi-avril. Trois changements de couche produit sans rapport ont été livrés entre le 4 mars et le 16 avril, chacun affectant une tranche de trafic différente selon son propre calendrier — c'est pourquoi les utilisateurs rapportaient des symptômes sauvagement différents selon le moment où ils utilisaient Claude Code et les fonctionnalités sur lesquelles ils s'appuyaient. De manière critique, l'API et les poids du modèle sous-jacent n'ont pas été affectés. Les trois problèmes sont résolus à partir de Claude Code v2.1.116 le 20 avril, et Anthropic a réinitialisé les limites d'usage pour tous les abonnés. La divulgation honnête est la partie qui distingue ça du communiqué « on améliore le produit » classique : dates précises, commits précis, chiffres de qualité précis, et responsabilité nommée par l'équipe Claude Code.
Les trois changements se décomposent proprement. Premièrement, le 4 mars, l'effort de raisonnement par défaut est passé de high à medium pour corriger les blocages UI durant les longues périodes de réflexion — Anthropic reconnaît que c'était « le mauvais compromis » et a fait machine arrière le 7 avril. Tous les modèles défaut maintenant en high ou xhigh. Deuxièmement, le 26 mars, une optimisation pour effacer les vieilles sections de pensée des sessions inactives (sessions inactives 1h+, où un cache miss complet était de toute façon inévitable) avait un bug qui déclenchait l'effacement à chaque tour au lieu d'une seule fois. Claude continuait d'exécuter mais de plus en plus sans mémoire de pourquoi il avait choisi son approche actuelle. Boris Cherny sur Hacker News a nommé le cas extrême : un utilisateur avec 900K tokens en contexte inactif pendant une heure ferait face à un cache miss complet sur le message suivant, consommant un pourcentage significatif des rate limits — particulièrement pour les utilisateurs Pro. Corrigé le 10 avril. Troisièmement, le 16 avril aux côtés d'Opus 4.7, Anthropic a ajouté une limite de verbosité au system prompt instruisant le modèle à « garder le texte entre les appels d'outils à 25 mots ou moins » et « garder les réponses finales à 100 mots ou moins ». Les tests internes n'ont trouvé aucune régression. Des ablations plus larges menées durant l'enquête ont révélé une baisse de qualité de 3 % sur Opus 4.6 et 4.7. Annulé le 20 avril. Comme méta-trouvaille, l'outil de Code Review d'Anthropic a été back-testé sur les PR fautives : Opus 4.7 a trouvé le bug de cache quand on lui donnait un contexte de repo suffisant ; Opus 4.6 non.
La critique communautaire vaut la peine d'être pondérée à côté du post-mortem. Les commentateurs de Hacker News ont questionné si la réduction de latence était le vrai moteur du pruning de session inactive, ou si la réduction de coût était l'objectif réel avec la latence comme couverture. Plusieurs ont flaggé que publier des benchmarks contre un ancien system prompt et ensuite expédier un nouveau sans divulgation « se sent trompeur ». Fortune a rapporté que les utilisateurs se sont sentis « gaslightés » par les démentis initiaux d'Anthropic. La réponse d'Anthropic à Fortune incluait la ligne « le compute est une contrainte à travers toute l'industrie » aux côtés du pitch de partenariat de scaling. Deux problèmes que le post-mortem n'aborde pas valent aussi la peine d'être suivis : des utilisateurs Reddit rapportent que Claude Code délègue plus souvent qu'attendu au modèle Haiku moins cher — visible seulement dans le logging verbose — ce qui est une classe de risque qualité silencieuse dans les pipelines automatisés mais évidente en usage interactif. Et au moins un utilisateur Reddit a indépendamment confirmé que les instructions de verbosité sont restées dans le system prompt après le revert annoncé du 20 avril, construisant un script de pre-tool hook qui contrait cinq modes d'échec spécifiques autour de la re-lecture de source sautée et de la sortie confiante-mais-mismatch. Le fait que le workaround construit par l'utilisateur a amélioré la qualité est en soi une validation du diagnostic du post-mortem que la limite de verbosité dégrade la qualité.
Pour les builders qui font tourner Claude Code en production : les correctifs canoniques sont en v2.1.116. Si tu as des workflows CI ou automatisés qui tournaient durant mars-avril, audit n'importe quel output pour l'empreinte des trois changements — surtout les longues sessions inactives (bug de cache) et tout output autour du 16-20 avril (prompt de verbosité). Pour les builders qui livrent des produits backed-LLM en général, la leçon d'ingénierie levée directement : les évals internes n'ont attrapé aucun des trois problèmes parce que le personnel interne utilisait des builds différents de la release publique, le bug de cache ne se manifestait que dans un état spécifique (sessions périmées) non exercé en éval, et la suite d'éval était trop étroite pour détecter une baisse de qualité de 3 % sur les changements de system prompt. La remédiation déclarée d'Anthropic — personnel interne sur les builds publics exacts, suites d'éval per-modèle plus larges pour chaque changement de system prompt, périodes de trempage et déploiements graduels, versioning soigné des changements de system prompt — est une base raisonnable pour l'industrie. L'aveu « le compute est une contrainte » compte aussi : si Anthropic fait des compromis coût/latence qui dégradent visiblement la qualité, la même logique s'applique à chaque vendor, et les équipes de procurement produit devraient demander explicitement des décisions latence-vs-qualité dans les SLAs vendor.