Úvod
Anthropic přiznal, že po zhruba měsíc produkuje horší výsledky v Claude Code; postmortem mapuje tři překrývající se příčiny. To není jen technický report — je to pohled na to, jak produktová optimalizace a chyby dohromady mohou vypadat jako „nerfing“ (záměrné oslabení schopností služeb).
Co se přesně stalo
Tři nezávislé změny, které se sešly časově tak, že to vypadalo jako plošný propad. První byla product změna: 4. března Anthropic potichu změnil defaultní "reasoning effort" (hloubku uvažování) z high na medium u Opus 4.6 — argument: o něco nižší inteligence za výrazně nižší latenci a spotřebu tokenů. Druhý byl nasazený caching bug (26. března): optimalizace, která měla jednorázově promazat starší „thinking“ bloky u dlouho nečinných sezení, místo toho mazala thinking historii při každém dalším turnu, takže model postupně „zapomínal“, opakoval se a chybně volal nástroje. Tenhle bug opravili 10. dubna (v2.1.101). Třetí změna byla opět product rozhodnutí: 16. dubna přidali do system promptu cap na délku výstupů (mezi příkazy max ~25 slov, konečné odpovědi max ~100 slov), aby se snížila verbosity a tedy spotřeba tokenů; revertováno 20. dubna (v2.1.116), protože ablační testy ukázaly ~3% pokles kvality kódu.
Postup oprav: 7. dubna zrušení změny default effortu (nový default xhigh pro Opus 4.7 a high pro ostatní), 10. dubna oprava caching bugu, 20. dubna revert verbosity cap, 23. dubna reset usage limitů a vydání postmortemu, který agreguje tyto události.
Proč mě to zaujalo
Dvě z těch tří příčin byly úmyslné optimalizace zaměřené na snížení tokenových nákladů; jediný opravdový bug byl caching. To znamená, že namísto „model zhloupnul“ šlo často o produktová rozhodnutí, která měla pomoci s latencí a náklady. Mně to připadá důležité, protože mnohé týmy spoléhají na konzistentní chování modelu — a když provider upraví prompt nebo defaulty kvůli úsporám, projeví se to přímo v produkčních výsledcích partnerů.
Zajímavé je i to, že dopad nebyl omezen jen na Claude Code: stejné vrstvy promptů a harnessu používají Claude Agent SDK a Claude Cowork, takže degradace zasáhla i agenty a asynchronní asistenty třetích stran.
Co mě v tom zaráží (a co bych po providerovi chtěla vidět jinak)
Interní dogfooding neodhalil caching bug, protože paralelní interní experimenty a změny v "display thinking" potlačily jeho projev. To znamená, že prostředí, ve kterém Anthropic testuje, nemuselo odpovídat produkci. Pro firmu, která se prodává i přes spolehlivost modelu, je to nepříjemné — a trochu překvapivé.
Opakující se vzorec "tři překrývající se problémy" se už objevil i v postmortemu ze září 2025. Méně benevolentní interpretace je, že podobná struktura vysvětlení se stává pohodlným rámcem pro míchání technických chyb a záměrných produktových trade-offů. Rád(a) bych viděla jasné rozlišení mezi bugem a designovým kompromisem, transparentnější changelogy a výraznější upozornění uživatelům při změně defaultních nastavení ovlivňujících kvalitu.
Co si z toho odnést — pro týmy, které Claude používají
- Monitorujte telemetrii: sledujte metriky kvality generovaného kódu a depth-of-reasoning po každé aktualizaci poskytovatele.
- Pinujte konfigurace: kde je to možné, explicitně nastavujte reasoning effort a system prompt, místo spoléhat na defaulty, které se mohou změnit.
- Testujte v produkci-like prostředí: interní dogfooding nemusí pokrýt produkční kombinace experimentů.
- Mějte plán pro incidenty: pokles kvality modelu může znamenat nutnost rollbacku nebo dočasného omezení funkcí u vlastní služby.
Závěr
Tenhle případ není jen o jednom bugu — je to lekce o tom, jak produktová rozhodnutí, drobné chyby a nedostatečně synchronizované testy mohou společně vytvořit měsíční degradaci pro koncové uživatele. Anthropic část problémů opravil a resetoval limity; otázka je, zda si z toho vezme dost poučení, aby se podobné situace opakovaly méně často.
Zdroje
- Článek na VibeCoding: https://www.vibecoding.cz/articles/claude-code/anthropic-priznal-mesicni-degradaci-claude-code-co-se-stalo/ (24. 4. 2026)