Anthropic dévoile les causes de la dégradation de Claude Code et réinitialise les quotas des utilisateurs

L'équipe d'ingénierie d'Anthropic a publié une autopsie détaillée des pannes système de Claude Code, cibles de plaintes massives de développeurs ces dernières semaines. L'enquête interne a démontré que le sentiment partagé d'une régression du modèle n'avait rien de subjectif. Il résultait de la superposition de trois modifications distinctes, déployées dans le code entre début mars et mi-avril. Tous les problèmes ont affecté l'interface Claude Code, le SDK Claude Agent et Claude Cowork, sans toucher l'API de base. Au 20 avril, les équipes ont colmaté l'ensemble des brèches dans la version v2.1.116 et ont réinitialisé les compteurs de quotas de tous les abonnés en guise de compensation.

Le piège du compromis entre latence et profondeur d'analyse

Le premier coup porté à la qualité est survenu le 4 mars, lorsque le niveau de réflexion par défaut (reasoning effort) d'Opus 4.6 a été basculé du mode high à medium. Les ingénieurs cherchaient à réduire la latence : à charge maximale, la génération s'éternisait et le terminal semblait figé. Si l'écart paraissait négligeable sur les tests synthétiques internes, la précision s'est effondrée sur les enchaînements algorithmiques complexes en conditions réelles de développement. Les utilisateurs modifiant rarement ces réglages manuellement via la console, ils sont restés sur ces paramètres dégradés. Le 7 avril, la valeur par défaut a été rétablie, et le curseur a même été poussé au niveau maximal xhigh pour le modèle phare Opus 4.7.

Un effacement de mémoire en cascade lors des longues sessions

Bien plus critique s'est avéré un défaut de mise en cache masqué, introduit le 26 mars. Pour économiser des tokens et accélérer la reprise du travail après une heure d'inactivité, le système devait purger une seule fois les anciens blocs de réflexion via l'en-tête clear_thinking. Or, au lieu d'un nettoyage unique, cet indicateur technique restait actif jusqu'au terme de la session. Dès la deuxième requête, Claude Code rejetait sa chaîne de raisonnement à chaque étape. Si l'utilisateur envoyait une commande pendant l'exécution d'un outil, le modèle perdait instantanément le fil de ses actions précédentes. S'ensuivaient alors des boucles de répétition, des modifications aberrantes et une explosion de la consommation de quotas due aux défauts de cache constants.

Métriques clés et chronologie de l'incident :

• 4 mars — bascule du reasoning effort par défaut vers medium pour pallier les blocages de l'interface ;
• 26 mars — déploiement de l'optimisation du cache introduisant le bug critique de réinitialisation permanente du contexte de raisonnement ;
• 10 avril — sortie du correctif v2.1.101 résolvant la perte de mémoire de l'agent lors des sessions prolongées ;
• 16 avril — intégration d'une limite stricte dans le prompt système (25 mots maximum entre les appels d'outils et 100 mots maximum en conclusion) ;
• 20 avril — annulation de la directive du prompt après la détection d'une baisse de performance de 3% sur les benchmarks étendus, et sortie de la v2.1.116 ;
• Configurations concernées — Claude Sonnet 4.6, Opus 4.6 et Opus 4.7 dans les environnements clients.

Un prompt système répressif et une perte de cohérence

Le troisième facteur tient à une tentative d'endiguer artificiellement la verbosité du nouveau modèle Opus 4.7. En préparant la version du 16 avril, les développeurs ont injecté des contraintes draconiennes dans le prompt système : pas plus de 25 mots d'explication entre deux appels d'outils, et 100 mots au maximum pour la réponse finale. Si les tests préalables au déploiement n'avaient rien révélé, des analyses d'ablation rétrospectives à grande échelle ont mis en évidence une chute de 3% de la qualité globale sur deux modèles majeurs. Ainsi bridé, le modèle ne parvenait plus à analyser correctement les choix d'architecture et supprimait les justifications contextuelles pourtant indispensables aux refactorisations complexes.

Le post-mortem d'Anthropic illustre la fragilité des architectures combinant outillage agentique, cache et instructions système. Vouloir rogner discrètement sur les coûts d'inférence en tronquant le contexte et en bridant le raisonnement finit inévitablement par briser la logique autonome des agents. Les développeurs concevant leurs propres solutions basées sur des LLM devront revoir leurs méthodes de supervision : les benchmarks synthétiques passent à côté de régressions critiques dès lors qu'ils n'intègrent pas l'accumulation d'erreurs de mémoire sur des scénarios réels à étapes multiples.