Wczoraj, dokładnie w dniu, w którym OpenAI ogłosiło GPT-5.5, Anthropic opublikował oficjalny postmortem Claude Code. Tekst Borisa Cherny’ego wyjaśnia, co się stało z jakością modeli Opus 4.6 i 4.7 w ostatnich tygodniach. Firma przyznaje trzy odrębne błędy, które łącznie trwały ponad 50 dni. W efekcie Anthropic musi kilka razy wycofywać wprowadzone zmiany, a dodatkowo resetuje limity wszystkim użytkownikom jako kompensacja. Ten czas publikacji nie jest oczywiście przypadkiem. W tle mamy bowiem GPT-5.5, do którego użytkownicy Claude Code masowo migrują, a także falę skarg z Reddita, na które oficjalne kanały Anthropic przez miesiąc nie odpowiadały. Dlatego warto zrozumieć, co się naprawdę stało.
Trzy bugi, które zabrały miesiąc produktywności
Anthropic przyznaje w postmortemie trzy oddzielne problemy. Każdy z nich dotyczył innego obszaru Claude Code, a ponadto każdy trwał zupełnie innym tempem.
Bug 1: Obniżony reasoning effort (4 marca – 7 kwietnia)
Pierwszy problem trwał 34 dni i dlatego był najdłuższy. Anthropic 4 marca zmienił domyślny poziom reasoning effort z high na medium w Claude Code. Powód podany w postmortemie to “UI freeze”, ponieważ w trybie high latencja była tak duża, że interfejs sprawiał wrażenie zawieszonego. W efekcie rozwiązaniem miało być obniżenie trybu myślenia.
Problem w tym, że firma sama przyznaje, że medium był gorszy. Cytat z postu: “In our internal evals and testing, medium effort achieved slightly lower intelligence”. Przetłumaczyłbym to jako “tak, wiedzieliśmy że to obniża inteligencję, ale zrobiliśmy to dla wygody UI”. Zmiana dotyczyła Sonnet 4.6 i Opus 4.6, natomiast Anthropic cofnął ją dopiero 7 kwietnia.
Bug 2: Bug w cachingu myślenia (26 marca – 10 kwietnia)
Drugi problem trwał 15 dni, jednak był chyba najbardziej szkodliwy dla użytkownika. Anthropic 26 marca wdrożył optymalizację API, która miała czyścić starsze “thinking” z sesji bezczynnych ponad godzinę. Niestety bug polegał na tym, że flaga keep:1 w headerze clear_thinking_20251015 czyściła historię myślenia na każdym kolejnym turnie, a nie raz.
Efekt w praktyce? Claude był “zapominalski”, ponadto powtarzał się i ekspresowo zjadał limity. Boris Cherny tłumaczy mechanizm na przykładzie. Masz sesję z 900 tysiącami tokenów w kontekście, zostawiasz ją na godzinę i wracasz z nowym zapytaniem. W tym momencie system zapisuje całe 900 tysięcy tokenów do pamięci podręcznej jednym strzałem. W rezultacie potrafiło to pożreć znaczący procent dziennego limitu. Dlatego fix pojawił się dopiero 10 kwietnia w wersji v2.1.101.
Bug 3: Skrócone odpowiedzi (16 kwietnia – 20 kwietnia)
Trzeci problem trwał tylko 4 dni, ale właśnie o nim najgłośniej było na Reddicie. Anthropic 16 kwietnia dodał do system prompta Claude Code instrukcję: “keep text between tool calls to ≤25 words. Keep final responses to ≤100 words”. Dzięki temu model miał być bardziej zwięzły.
Jednak efekt mierzalny, który Anthropic podaje sam, mówi coś innego. To 3% spadek wydajności dla Opus 4.6 i 4.7. W dodatku dla najnowszego modelu, który firma świeżo wprowadziła 16 kwietnia z hukiem marketingowym, celowo wprowadzono konfigurację obniżającą jakość. Dlatego instrukcja została wycofana już 20 kwietnia w wersji v2.1.116.
Trzy bugi: 34 dni, 15 dni, 4 dni. W tym czasie Anthropic wypuścił Claude Opus 4.7 jako flagowy model, ogłosił Claude Design, dostał 25 miliardów dolarów od Amazona. A oficjalny komunikat o jakości wyszedł dopiero w dniu premiery GPT-5.5.
Cisza na oficjalnych kanałach i tweety Borisa
Tutaj zaczyna się najciekawsza część. Problemy z jakością Claude Code użytkownicy zgłaszali już od końca marca. Na Reddicie i w X/Twitter pojawiały się setki postów. Model był zapominalski, limity wyparowywały w kilka godzin, a Opus 4.7 po premierze pracował gorzej niż 4.6 przed. Mimo to oficjalne kanały Anthropic przez cały ten czas milczały.
Boris Cherny, który jest autorem postmortemu, odpowiadał w tym czasie na pojedyncze tweety użytkowników. Robił to jednak casualnie, bez koordynacji i bez oficjalnego potwierdzenia problemu. Komentator z HN napisał o tym wprost: “You had random developers tweet and reply at random times to random users while all of your official channels were completely silent”. Co więcej, inny użytkownik dodał, że zmiany w cachingu nie zostały udokumentowane w oficjalnym changelog Claude Code, który zwykle jest dość gadatliwy.
Cała sytuacja wygląda tak: Inżynierowie Anthropic wiedzieli o bugach od marca i spokojnie je naprawiali po kolei. Oficjalny komunikat jednak czekał, ponieważ akurat ruszała premiera Opusa 4.7 i przeprosiny popsułyby marketing. Dopiero gdy OpenAI 23 kwietnia ogłosił GPT-5.5, trzeba było jakoś zareagować. Wtedy post wyszedł ze szuflady. Data nie jest przypadkiem.
Pisaliśmy zresztą o tym spadku jakości już 14 kwietnia w analizie degradacji Claude Opus 4.6. Wtedy Anthropic oficjalnie milczał, natomiast my opisywaliśmy mechanizmy na podstawie obserwacji użytkowników. Dzisiaj wiemy już, że te obserwacje były precyzyjne. Opus myślał bowiem 73% krócej niż wcześniej, dokładnie przez ten verbosity prompt i caching bug.
Co to wszystko znaczy dla zwykłego użytkownika
Trzy bugi obniżające jakość modeli na 50 dni w okresie, w którym firma chwali się flagowym Opus 4.7 i zbiera 25 miliardów dolarów od Amazona, to kiepskie połączenie. Reset limitów dla wszystkich subskrybentów, który Anthropic ogłosił 23 kwietnia, to wprawdzie ładny gest kompensacyjny. Problem jednak w tym, że rozwiązuje on tylko jeden wymiar strat, czyli zjedzone quota. Nie rozwiązuje natomiast kwestii tego, że użytkownicy przez tygodnie pisali kod, który nie był optymalny, ponieważ model był obniżony celowo.
Dla firm korzystających z Claude Code w produkcji są dwa sensowne wnioski. Po pierwsze, plan B nadal jest rozsądny. Jeśli bowiem Twój workflow zależy od jednego dostawcy AI, a ten dostawca przez miesiąc nie informuje Cię, że obniża jakość modelu, masz problem strukturalny, a nie narzędziowy. Po drugie, warto przetestować nowy GPT-5.5 OpenAI równolegle, ponieważ to właśnie ten model zabiera teraz klientów Anthropic.
Techniczne ograniczenia też są ciekawe. Komentator z HN, podający się za pracownika Microsoft AI, wyjaśnił w dyskusji źródło problemu. Otóż całe zamieszanie z cachingiem wynika z fundamentalnego ograniczenia sprzętowego. Pamięć myślenia trzeba bowiem trzymać w GPU, a to jest ekstremalnie rzadki zasób. DeepSeek 3FS rozwiązuje to elegancko przez rozproszony system plików. Natomiast Anthropic wybrał prostszą drogę czyszczenia historii i wpadł na drobny bug z flagą keep:1. Ten detal dobrze pokazuje, jak cienka jest granica między optymalizacją a regresją w LLM-ach.
Kurs n8n 2.0 · Kodożercy
Od zera do własnych automatyzacji – bez doświadczenia
Kurs n8n 2.0 od Kodożerców przeprowadzi Cię krok po kroku przez budowanie prawdziwych automatyzacji. Od webhooków, przez integracje z API, po własne przepływy danych – wszystko bez programowania.
Sprawdź kurs n8n 2.0 →

FAQ – co użytkownicy pytają o Claude Code postmortem
Które modele były dotknięte bugami?
Wszystkie trzy problemy dotyczyły Sonnet 4.6 i Opus 4.6. Trzeci bug (verbosity prompt) dotknął też Opus 4.7, który został wprowadzony 16 kwietnia 2026 roku. Starsze modele nie były dotknięte.
Dlaczego Anthropic nie poinformował wcześniej?
Firma w postmortemie nie tłumaczy opóźnienia. W komentarzach pod postem na HN Boris Cherny przyznał, że odpowiadał na pojedyncze zgłoszenia użytkowników na Twitterze, ale nie było to działanie koordynowane z oficjalnym komunikatem. Pierwszy bug (reasoning effort) był w produkcji 34 dni bez informacji dla klientów.
Czy reset limitów rekompensuje wszystkie straty?
Reset limitów dotyczy wszystkich subskrybentów i jest powszechny. Nie rekompensuje jednak pracy wykonanej przy obniżonej jakości modelu – kod napisany w tym czasie, który wymagał więcej iteracji, albo zwiększonego czasu pracy programistów, nie jest objęty kompensacją.
Czy Claude Opus 4.7 nadal ma 3% niższą wydajność?
Nie. Verbosity prompt został wycofany 20 kwietnia 2026 roku w wersji v2.1.116. Od tego momentu Opus 4.7 działa z pełną wydajnością zgodnie z oficjalnymi benchmarkami.
Jak Anthropic ma zapobiec takim problemom w przyszłości?
W postmortemie firma obiecuje lepszy monitoring regresji oraz większą transparentność w komunikacji zmian. Konkretnych mechanizmów (np. publiczny changelog dla zmian system prompta) nie podano.
Podsumowanie
Anthropic oficjalnie przyznał w postmortemie z 23 kwietnia 2026 roku, że trzy odrębne bugi obniżały jakość Claude Code przez łącznie ponad 50 dni. Najdłuższy problem (reasoning effort medium zamiast high) trwał 34 dni i dotknął Sonnet 4.6 oraz Opus 4.6. Drugi (caching bug) trwał 15 dni i powodował szybkie zużycie limitów. Trzeci (verbosity prompt) trwał 4 dni i obniżył wydajność Opus 4.7 o 3%.
Techniczne wyjaśnienia Borisa Cherny’ego są uczciwe, konkretne i zawierają liczby, których zwykle w takich postach się nie dostaje. Problem leży jednak gdzie indziej. W miesięcznej ciszy oficjalnych kanałów, w tym, że zmiany system prompta nie trafiły do changelogu, oraz w niewygodnym zbiegu okoliczności. Postmortem wychodzi akurat w dniu premiery GPT-5.5.
Dla użytkowników produkcyjnych wniosek jest jeden – plan B nadal ma sens. Nie dlatego, że Claude Code jest złym narzędziem. Raczej dlatego, że jest w pełni zależny od jednego dostawcy. A ten dostawca przez miesiąc nie uznał za konieczne powiadomić Cię o obniżeniu jakości modelu, za który płacisz.
Newsletter · DevstockAcademy & Kodożercy
Bądź na bieżąco ze światem IT, AI i automatyzacji
Co wtorek: newsy z branży, praktyczne tipy i narzędzia które warto znać. Zero spamu.



