Claude Code a régressé pendant un mois : trois bugs en cascade

Le 23 avril, Anthropic a publié un post-mortem qui confirme ce que beaucoup de praticiens sentaient depuis mars : Claude Code est devenu mesurablement plus bête pendant six semaines. Trois changements distincts dans la couche produit ont dégradé Sonnet 4.6, Opus 4.6 et brièvement Opus 4.7, sans que les poids des modèles ne bougent. Le post détaille chaque bug, sa date d'apparition et sa date de correction¹.

L'enchaînement compte plus que chaque bug pris isolément. Comme les changements se sont superposés sur des slices de trafic différentes et à des dates différentes, les utilisateurs voyaient une dégradation incohérente, impossible à reproduire en évaluation interne. Anthropic admet avoir mis plus d'un mois à remonter la cause racine¹.

Le réglage d'effort par défaut, baissé en silence

Premier coupable : le 4 mars, Anthropic a fait passer l'effort par défaut de Claude Code de high à medium. La logique était valable sur le papier, certaines sessions en mode high voyaient l'UI figée par des temps de réflexion trop longs. La conséquence non valable : pour la majorité des tâches, le modèle réfléchissait moins, donc codait moins bien.

Le réglage est remonté à high (et xhigh pour Opus 4.7) le 7 avril après remontées clients. Mais entre le 4 mars et le 7 avril, ceux qui n'avaient jamais touché à /effort tournaient sous-allocés.

Ce détail vaut la peine d'être retenu. La qualité du modèle n'est pas seulement la qualité des poids. C'est aussi la valeur du paramètre effort que l'orchestrateur envoie à l'API. Si vous pilotez Claude Code dans un studio ou en équipe, vous avez probablement plusieurs développeurs qui n'ont jamais ouvert /effort. Pendant cinq semaines, c'est exactement eux qui ont travaillé avec un modèle bridé.

Le bug de cache qui effaçait la mémoire de session

Deuxième couche : le 26 mars, Anthropic a déployé une optimisation qui devait nettoyer les anciens blocs de raisonnement quand une session restait inactive plus d'une heure. L'idée était propre, on parle d'une réduction des tokens non cachés à la reprise.

Le bug, lui, ne l'était pas. Au lieu de purger une seule fois, l'implémentation effaçait l'historique de raisonnement à chaque tour pour le reste de la session. Claude continuait à exécuter des outils mais perdait progressivement la mémoire de ce qu'il avait décidé deux tours plus tôt.

C'est exactement ce que les utilisateurs décrivaient : Claude qui se répète, qui choisit des outils incohérents, qui revient sur des décisions déjà prises. Le bug a aussi vidé les usage limits plus vite que prévu, parce que chaque cache miss forçait l'envoi de nouveaux tokens non cachés à chaque tour. Correctif déployé le 10 avril en v2.1.101¹.

Anthropic note que le bug s'était glissé à travers code review, tests unitaires, tests end-to-end et dogfooding interne. Il fallait être dans une session restée idle plus d'une heure puis reprise pour le déclencher. C'est un cas d'école sur les régressions silencieuses des optimisations de cache.

Le system prompt qui muselait Opus 4.7

Troisième couche, et la plus subtile. Opus 4.7 a été lancé le 16 avril avec une consigne dans son system prompt qui limitait à 25 mots les commentaires entre tool calls et à 100 mots la réponse finale¹. Anthropic l'a calibrée parce qu'Opus 4.7 est plus verbeux par construction. La consigne est passée à travers les évaluations internes sans déclencher d'alerte.

Quand la dégradation a forcé une nouvelle vague d'ablations, l'équipe a découvert que cette ligne précise faisait perdre 3% sur des évaluations de code, sur Opus 4.6 comme sur 4.7¹. Le revert est tombé en v2.1.116 le 20 avril, soit quatre jours après la mise en production.

C'est la couche où la lecture critique se sépare le plus du discours d'Anthropic. Jakub Kontra, dans une analyse publiée deux jours plus tard, fait remarquer que deux des trois "incidents" étaient des décisions délibérées de réduction de compute, pas des bugs au sens strict². L'effort par défaut est descendu volontairement. La consigne de verbosité est passée en production volontairement. Seul le bug de cache était un vrai bug. L'analyse rappelle qu'Anthropic n'a pas pris l'engagement d'annoncer en amont les changements délibérés qui pèsent sur la qualité, ce qui aurait couvert deux des trois incidents.

Ce que cela change pour les builders qui shippent avec Claude Code

Notre article du 17 avril sur Opus 4.7 parlait d'ajuster prompts, budgets tokens et permissions Claude Code. La consigne de verbosité existait déjà, on ne la connaissait pas, et elle dégradait la qualité du code généré. C'est une bonne illustration du fait qu'auditer son propre prompt ne suffit pas. Le system prompt en amont, l'orchestration du cache et le réglage d'effort sont autant de leviers sur lesquels le builder n'a aucun contrôle.

Pour ceux qui pilotent Claude Code en studio, il faut tirer trois leçons opérationnelles. D'abord, fixer explicitement /effort dans CLAUDE.md plutôt que de faire confiance au défaut produit. Le défaut peut bouger sous vos pieds sans changelog visible. Ensuite, méfiance sur les optimisations de cache. Tester périodiquement des sessions longues qui survivent à des pauses, pour vérifier qu'on ne perd pas le fil du raisonnement. Enfin, considérer l'API directement quand la production l'exige. L'API a été épargnée par les trois incidents, parce que tout le harnais Claude Code (système prompt, gestion du cache, réglage d'effort) vit au-dessus.

Du côté positif, Anthropic publie un post-mortem détaillé avec dates précises, versions concernées et commits de correctif¹. Fortune relève qu'Anthropic a aussi remis à zéro les usage limits de tous les abonnés au 23 avril en compensation³. C'est un niveau de transparence rare dans l'industrie, et ça vaut la peine d'être noté quand on choisit son fournisseur de modèle. Reste à voir si les engagements pris (ablations systématiques par modèle, soak periods, rollouts graduels pour tout changement qui touche à l'intelligence) tiendront sur la durée.