Claude Sonnet 5.5: benchmarki, cena i migracja z Sonneta 5

Claude Sonnet 5.5 wyszedł 28 września 2026 i pierwsza liczba, która rzuca się w oczy, jest trochę podejrzana: 70.6% na Terminal-Bench 4.0, czyli więcej niż Opus 5.5 (66.4%), który kosztuje dwa razy tyle.

Anthropic sam studzi ten entuzjazm w tym samym ogłoszeniu: w ich testach i u zewnętrznych testerów “Opus 5.5 pozostaje wyraźnie mocniejszy w złożonej, otwartej pracy wymagającej ciągłego osądu”. Benchmark mierzy jedno, a codzienna praca drugie.

Ciekawsze rzeczy są gdzie indziej. Cena się nie zmieniła, ale model zużywa dużo mniej tokenów na to samo zadanie. Poziomy effort znaczą teraz coś innego niż w Sonnecie 5. I jest jedna zmiana w API, która zwróci 400 każdemu, kto wyłączał myślenie.

Podstawowe fakty

Dostępność: Claude API, Amazon Bedrock, Google Cloud, Microsoft Foundry (hostowany na Azure) i Claude Platform on AWS. Jest też wariant bez przechowywania danych (zero data retention), jak w Opusie 5.5.

Cena jest identyczna jak w Sonnecie 5. To ma znaczenie, bo Sonnet 5 startował z ceną “wprowadzającą” $2 / $10 do końca sierpnia i miał potem podrożeć do $3 / $15. 10 sierpnia Anthropic odwołał podwyżkę i $2 / $10 zostało na stałe.

I jeszcze jedno zestawienie, które ustawia całą rozmowę: GPT-6 Sol kosztuje dokładnie tyle samo - $2 / $10 i $0.20 za odczyt z cache. Pierwszy raz od dawna środkowa półka Anthropic i OpenAI stoi na tej samej cenie co do centa, więc porównanie jest proste: który model zrobi Twoje zadanie w mniejszej liczbie tokenów i kroków.

Benchmarki

Liczby z ogłoszenia Anthropic:

Wzór jest czytelny: Sonnet 5.5 prawie wszędzie ląduje 1-3 punkty za Opusem 5.5, a na Terminal-Bench go wyprzedza. Na GDPval-AA, teście pracy zawodowej w 44 zawodach, różnica to 2 punkty Elo. Wobec GPT-6 Sol, w tej samej cenie, Sonnet 5.5 wygrywa na FrontierCode i wyraźnie na pracy biurowej (1844 vs 1487 Elo).

Do wyników GPT-6 Sol są dwa zastrzeżenia z przypisów: OpenAI niedawno naprawiło błąd, który psuł rozumienie obrazów w Solu, a oficjalne wyniki Artificial Analysis mogły jeszcze tego nie uwzględnić. Artificial Analysis nie spodziewa się dużego wpływu na GDPval i AA-Briefcase. Z kolei Terminal-Bench dla GPT-6 Sol nie został opublikowany, więc Anthropic porównuje się tam z GPT-5.6 Sol.

Sonnet 5 z wynikiem 10.3% na Terminal-Bench wygląda jak błąd pomiaru, ale to liczba z oficjalnej tabeli. Anthropic jej nie komentuje. Dlatego wolę patrzeć na FrontierCode i CursorBench, gdzie skok jest duży (+10 i +21 punktów), ale w normalnej skali.

Przypis, który warto zapamiętać: więcej effortu dało gorszy wynik

Na FrontierCode Sonnet 5.5 przy effort max ma 46.2%, a przy xhigh 52.1%. Wyższy effort, niższy wynik.

Anthropic tłumaczy to w przypisie. FrontierCode sprawdza, czy zmianę dałoby się zmergować bez poprawek człowieka, i karze za zmiany poza zakresem zadania - nawet jeśli są dobre. Przy max model częściej odpalał skill do code review w Claude Code, który rozdziela przegląd na wielu subagentów. W dwóch przypadkach przeanalizowanych przez Cognition skończyło się to timeoutem albo dodatkowymi edycjami poza zadaniem.

To jest znajomy problem z pracy z agentami, tylko tym razem udokumentowany na benchmarku: agent, który “przy okazji” poprawia sąsiedni kod, robi PR, którego nikt nie chce reviewować. Wniosek praktyczny: max to nie jest ustawienie “najlepiej”, tylko “najdłużej”. Jeśli Twoja miara sukcesu to mały, mergowalny diff, zmierz xhigh i high, zanim zostawisz max na stałe.

Koszt zadania, nie tokena

Cennik stoi w miejscu, ale Anthropic podaje, że zadanie kosztuje do 30% mniej niż na Sonnecie 5, bo model potrzebuje mniej tokenów. Konkretniej:

• Na kilku benchmarkach Sonnet 5.5 przy effort low albo medium przebija najlepszy wynik Sonneta 5 za mniej więcej jedną dziesiątą kosztu zadania.
• Na FrontierCode przy high ma o 10 punktów więcej niż Sonnet 5 przy tym samym ustawieniu, za ok. 1/15 kosztu.
• Testerzy zauważyli, że częściej łączy wywołania narzędzi w paczki, więc robi mniej kroków.

Cytaty firm z ogłoszenia idą w tę samą stronę:

• Balyasny Asset Management, 2441 zadań finansowych: ok. 121 tys. tokenów na odpowiedź zamiast 497 tys. na Sonnecie 5, przy lepszym wyniku.
• Base44, 118 realnych buildów aplikacji: jakość na poziomie Opusa 5, średnio 3.6 iteracji na build zamiast 7.7 i najmniej nieudanych wywołań narzędzi.
• Lovable: o jedną trzecią mniej wywołań narzędzi i mniej więcej o połowę mniej uruchomień shella na zadanie.
• Slack: lepiej niż Sonnet 5 na prawie wszystkich evalach, bez zmiany promptów, z ok. 14% mniej tokenów wyjściowych.
• CodeRabbit: znikła skłonność Sonneta 5 do zbyt częstego sięgania po web search i jego wysokie zużycie tokenów. Proste i średnie review przenoszą od razu.

To są wypowiedzi klientów w materiałach Anthropic, więc traktuj je jako kierunek, nie gwarancję. Ale mechanizm jest wiarygodny i łatwy do sprawdzenia u siebie: licz koszt ukończonego zadania, nie cenę za milion tokenów. Model, który kończy w 4 krokach zamiast 8, jest tańszy nawet przy tej samej stawce - i szybszy, bo każdy krok to kolejne wywołanie z całym kontekstem.

Effort: te same nazwy, inne znaczenie

To jest zmiana, którą najłatwiej przeoczyć przy migracji, bo nic nie wybucha.

Poziomy effort zostały przekalibrowane. high na Sonnecie 5.5 nie daje tej samej ilości myślenia co high na Sonnecie 5. Jeśli po prostu podmienisz model ID i zostawisz stare ustawienie, dostaniesz inny profil kosztu i opóźnienia niż ten, który kiedyś wymierzyłeś.

Punkty startowe z dokumentacji effort:

• high (domyślny w API), jeśli zadanie nie jest agentowe ani wrażliwe na opóźnienie.
• medium do agentowego kodowania i wieloetapowej pracy z narzędziami, gdy zadanie jest dobrze opisane. Przy trudniejszych albo dłuższych przejdź na high. Skala oszczędności z ogłoszenia: na Terminal-Bench Sonnet 5.5 przy medium wyraźnie przebija najlepszy wynik Sonneta 5 za mniej niż jedną dziesiątą kosztu zadania.
• medium albo low do czatu i innych zadań, w których liczy się opóźnienie.
• xhigh i max tylko tam, gdzie zmierzyłeś zysk. Przypis o FrontierCode pokazuje, że nie jest on oczywisty.

Dwie obserwacje z przewodnika po promptowaniu Sonneta 5.5, które mają praktyczne konsekwencje.

Od medium w górę model myśli przed prawie każdą odpowiedzią, nawet przed “cześć”. To wydłuża czas do pierwszego tokena. Prośba w system prompcie “myśl mniej” na tych poziomach prawie nic nie daje. Jeśli masz interaktywny czat i liczy się opóźnienie, obniż effort do low zamiast pisać instrukcje.

Przy low model czasem ogłasza zmianę w kodzie jako gotową, zanim ją sprawdzi. Bez npm install, więc testy i type-checker nigdy się nie uruchomiły. Albo tylko sprawdzenie składni. Albo ciche zatrzymanie, gdy brakuje narzędzia do builda. Jeśli puszczasz agenta kodującego na low - a przy tej cenie kusi - dodaj do system promptu instrukcję, którą proponuje sam Anthropic:

When you change code that can be run, built, or type-checked, run a real check
that exercises the change before reporting it done: the project's tests,
type-checker, or build, or the changed command itself. A syntax-only check,
or a check command that failed to start, does not count; if all that is missing
is the project's declared dependencies, install them with its own package manager
and lockfile (e.g. npm install, pip install -r requirements.txt), never via sudo
or the system package manager, unless told not to. Only if
no real check can run here, say which one you did not run and why instead of
reporting the change as done.

Albo, co lepsze, niech Twój harness sam uruchamia testy po każdej zmianie. Agent, który raportuje sukces bez dowodu, to ten sam problem, o którym pisałem przy pomiarze pracy agentów: liczy się zmiana, która działa, a nie zmiana, którą model uznał za skończoną.

Migracja z Sonneta 5: co zwróci 400

Ta sekcja dotyczy kodu, który woła Messages API bezpośrednio. Jeśli używasz Sonneta w Copilocie, Claude Code albo w aplikacji Claude, niczego nie migrujesz - wybierasz model z listy. W Claude Managed Agents wystarczy zmienić nazwę modelu.

Przewodnik migracji Anthropic wymienia pięć zmian łamiących. Po kolei, od najczęstszej. W Claude Code część pracy zrobi za Ciebie /claude-api migrate. Podmienia model ID i parametry, które zwracają 400, a na koniec zostawia listę rzeczy do ręcznego sprawdzenia.

1. thinking: disabled nie działa

Na Sonnecie 5 wyłączenie myślenia było jednym polem. Na Sonnecie 5.5 zwraca błąd (sekcja „Turn off up-front thinking” w przewodniku migracji):

"thinking.type.disabled" is not supported for this model. Use "thinking.type.between_tools"
for the lowest thinking setting, or "thinking.type.adaptive" and "output_config.effort"
to control thinking behavior.

Zamiennikiem jest nowe ustawienie between_tools, najniższy poziom myślenia na tym modelu. Zanim jednak po nie sięgniesz, sprawdź adaptacyjne myślenie przy low - według dokumentacji model pomija wtedy myślenie przy większości prostych zapytań. Zmierz czas do pierwszego tokena i jakość na własnym ruchu:

// Było - działa na Sonnecie 5, na Sonnecie 5.5 zwraca 400
{ "model": "claude-sonnet-5", "thinking": { "type": "disabled" } }

// Preferowane - adaptacyjne myślenie (domyślne) przy niskim effort
{ "model": "claude-sonnet-5-5", "output_config": { "effort": "low" } }

// Gdy trasa musi zostać bez myślenia
{
  "model": "claude-sonnet-5-5",
  "thinking": { "type": "between_tools" },
  "output_config": { "effort": "high" }
}

between_tools ma cztery ograniczenia, każde kończy się 400:

• działa tylko przy effort high lub niższym, przy xhigh i max trzeba zostać przy adaptacyjnym myśleniu;
• żadne inne pole w thinking (display, budget_tokens, block_binding) nie jest dozwolone;
• effort nie może się zmienić w trakcie rozmowy;
• akceptuje go tylko Sonnet 5.5. Serwerowy fallback Anthropic sam zamienia go na disabled, gdy ponawia żądanie na Sonnecie 5. Ale jeśli masz własny router albo retry, który wysyła to samo body do innego modelu, musi najpierw usunąć to pole. To jest ten rodzaj błędu, który wychodzi dopiero w dniu, w którym fallback faktycznie zadziała.

Przy okazji usuń z promptów instrukcje typu “nie myśl, odpowiadaj od razu”. Według Anthropic zwiększają ryzyko, że model wypisze wewnętrzne tagi XML w widocznej odpowiedzi.

2. Wymuszone tool_choice zwraca 400

tool_choice: {"type": "any"} i {"type": "tool", ...} już nie działają, także w endpoincie do liczenia tokenów. Zamiennik według Anthropic: tool_choice: {"type": "auto"} plus strict: true na narzędziu, żeby wejście zgadzało się ze schematem. Model może wtedy odpowiedzieć bez wywołania, więc opisz w prompcie, kiedy ma go użyć, i sprawdź w kodzie, czy wywołanie faktycznie nastąpiło. Na Bedrocku strict tool use nie jest dostępny dla Sonneta 5.5 - tam zostaje samo auto i walidacja wejścia po Twojej stronie.

3. Bloki myślenia są przywiązane do modelu i rozmowy

Żaden inny model nie czyta bloków myślenia Sonneta 5.5. Jeśli router przełączy rozmowę na inny model albo zadziała fallback, kolejne tury lecą bez rozumowania z poprzednich. Żądanie się uda, nic nie wybuchnie - model po prostu straci kontekst swojego myślenia.

Dla kont API założonych od 31 sierpnia 2026 API sprawdza też, czy historia rozmowy nie była edytowana. Jeśli Twój harness przepisuje wcześniejsze wiadomości, np. przycina stare wyniki narzędzi albo podmienia system prompt, żądanie z blokiem myślenia po takiej edycji dostanie 400. Harness musi być append-only. Anthropic rozszerzył ten mechanizm także na konta: myślenia nie da się oddzielić od konta, które je wygenerowało, więc przełączanie kont w trakcie sesji w Claude Code też jest objęte zmianą.

4. Computer use tylko przez nowy toolset

Na Claude API i Google Cloud computer_20251124 zwraca 400, trzeba przejść na computer_toolset_20260801. Bedrock nadal przyjmuje starą wersję.

5. Advisor tool przyjmuje mniej doradców

Jeśli używasz advisor tool, Sonnet 5.5 jako wykonawca nie przyjmie już Opusa 4.8, 4.7, 4.6, Sonneta 5 ani Sonneta 4.6 jako doradcy. Rada wraca też zaszyfrowana, jako blok advisor_redacted_result, więc nie przeczytasz jej treści w odpowiedzi.

Zmiana, która nic nie psuje, ale wycisza UI

Tekst, który model pisze między wywołaniami narzędzi, na Sonnecie 5 wracał jako bloki text. Na Sonnecie 5.5 dłuższe notatki wracają jako bloki thinking, domyślnie puste. Jeśli Twój interfejs renderuje tylko text, agent nagle “zamilknie” między krokami. Rozwiązanie: thinking.display: "updates" (beta) albo "summarized" przy adaptacyjnym myśleniu. Przy between_tools notatki wracają z tekstem od razu.

Jedna zmiana na plus: minimalny prompt, który da się zcache’ować, spadł z 1024 do 512 tokenów, więc krótsze system prompty też załapią się na tańszy odczyt z cache.

Bezpieczeństwo: pierwszy Sonnet z zabezpieczeniami cyber

Sonnet 5.5 ma możliwości w cyberbezpieczeństwie porównywalne z Opusem 5, więc jako pierwszy Sonnet dostał zabezpieczenia podobne do tych w Opusie 5.5:

• zwykłe znajdowanie i naprawianie błędów w kodzie działa bez zmian;
• zadania cyber o podwyższonym ryzyku widocznie przechodzą na Sonneta 5;
• obrońcy będą mogli wkrótce aplikować do rozszerzonego Cyber Verification Program.

W API odmowa to zwykłe HTTP 200 ze stop_reason: "refusal" i kategorią w stop_details. Kategorii jest pięć: cyber, bio, frontier_llm, reasoning_extraction i general_harms. Serwerowy fallback (fallbacks: "default") ponawia tylko odmowy cyber i frontier_llm na Sonnecie 5. Pozostałe musisz obsłużyć sam - sprawdzaj stop_reason, zanim sięgniesz po treść odpowiedzi.

Dwie nowości wymierzone w destylację, czyli wyciąganie możliwości modelu przez tysiące fałszywych kont: klasyfikatory blokujące wyciąganie rozumowania i rozszerzone preserved thinking. Jeśli masz w prompcie “wypisz swoje rozumowanie krok po kroku” jako zamiennik myślenia, usuń to. Takie polecenie zaprasza odmowy w kategorii reasoning_extraction, a podsumowanie rozumowania dostaniesz przez display: "summarized".

W alignmencie Anthropic przetestował model na ok. 1850 scenariuszach. Sonnet 5.5 jest blisko Opusa 5.5 w tym, jak rzadko próbuje uciec z sandboxa, i najrzadziej ze wszystkich modeli Anthropic próbuje badać granice swoich kontenerów. Dla agenta z dostępem do terminala to ważniejsza liczba niż wynik na benchmarku. Nie zwalnia z własnych guardrailsów, ale mniej rzeczy musi na nie trafić.

Sonnet 5.5 w GitHub Copilot

Od 28 września Sonnet 5.5 jest ogólnie dostępny w GitHub Copilot dla planów Pro, Pro+, Max, Business i Enterprise - w VS Code, Visual Studio, JetBrains, Xcode, Eclipse, Copilot CLI, coding agencie, aplikacji Copilot, na github.com i w GitHub Mobile.

Jedna różnica ważna dla indywidualnych użytkowników: Sonnet 5.5 jest w planie Pro, a Opus 5.5, GPT-6 Sol i GPT-6 Astra zaczynają się od Pro+.

GitHub w testach zauważył to samo, co Anthropic: jakość na poziomie Sonneta 5 w kodowaniu, przy wyraźnie mniejszej liczbie kroków, tokenów i wywołań narzędzi. Rozliczenie idzie po cenniku dostawcy w modelu usage-based. W organizacjach Business i Enterprise nowe modele włączają się automatycznie, o ile administrator nie wyłączył tej opcji - warto zajrzeć do polityk modeli, zanim zespół zacznie przełączać się masowo. Jak ograniczać agentom dostęp szerzej, opisuję w tekście o granicach dostępu agentów Copilota.

Sonnet 5.5, Opus 5.5 czy GPT-6 Sol

Aktualizacja 29 września 2026: dzień po Sonnecie 5.5 OpenAI wypuściło GPT-6.1 Sol w tej samej cenie $2 / $10, z odczytem z cache za $0.10. Porównanie obu modeli, łącznie z dopłatą OpenAI za kontekst powyżej 272K: GPT-6.1 Sol vs Claude Sonnet 5.5.

Heurystyka, którą najlepiej oddaje jeden z cytatów w ogłoszeniu: Opus projektuje, Sonnet implementuje. Kevin Ngo z Creator ujął to tak, że gdy Opus 5.5 ustawi architekturę gry, spokojnie oddałby implementację Sonnetowi 5.5.

• Sonnet 5.5 - dobrze zdefiniowane zadania: nowa funkcja z jasną specyfikacją, poprawka błędu, review prostych i średnich PR-ów, dokumenty, slajdy i arkusze. Wszędzie tam, gdzie liczy się szybkość iteracji. Przy medium to prawdopodobnie Twój nowy domyślny model do kodowania.
• Opus 5.5 - zadania otwarte, gdzie trzeba ocenić trade-offy, zaprojektować architekturę albo prowadzić długą pracę bez dokładnej specyfikacji. Kosztuje dwa razy więcej, ale na niejasnym zadaniu tańszy model, który pójdzie w złą stronę, wyjdzie drożej.
• GPT-6 Sol - ta sama cena, więc decyduje ekosystem i Twoje evale. Jeśli pracujesz w Codeksie, Sol jest naturalnym wyborem. Na benchmarkach z tabeli Anthropic Sonnet 5.5 prowadzi, ale to tabela Anthropic.
• Haiku 5.5 ma dołączyć w najbliższych tygodniach, do dużego wolumenu i zadań wrażliwych na koszt.

Jedno praktyczne zastrzeżenie przy łączeniu modeli: bloki myślenia Sonneta 5.5 nie przechodzą do innych modeli. Jeśli planujesz architekturę “Opus planuje, Sonnet wykonuje” w jednej rozmowie, przekazuj między nimi jawny plan w tekście, a nie licz na to, że drugi model odczyta rozumowanie pierwszego.

FAQ

Ile kosztuje Claude Sonnet 5.5?

$2 za milion tokenów wejściowych i $10 za milion wyjściowych, tyle samo co Sonnet 5. Odczyt z cache kosztuje $0.20, zapis do cache $2.50 (5 minut) albo $4 (1 godzina). Anthropic podaje, że zadanie kosztuje do 30% mniej niż na Sonnecie 5, bo model zużywa mniej tokenów.

Czy Sonnet 5.5 jest lepszy od Opus 5.5?

Na Terminal-Bench 4.0 tak (70.6% vs 66.4%), na pozostałych benchmarkach z tabeli jest 1-3 punkty niżej. Anthropic zaznacza, że w złożonej, otwartej pracy wymagającej osądu Opus 5.5 pozostaje wyraźnie mocniejszy. Sonnet 5.5 najlepiej sprawdza się w dobrze zdefiniowanych zadaniach.

Dlaczego po zmianie na Sonnet 5.5 dostaję błąd 400 przy thinking disabled?

Sonnet 5.5 nie obsługuje thinking: {"type": "disabled"}. Najpierw spróbuj adaptacyjnego myślenia przy effort low. Jeśli trasa musi zostać bez myślenia, wyślij thinking: {"type": "between_tools"} przy effort high lub niższym, bez innych pól w obiekcie thinking. Szczegóły i przykłady przed/po są w przewodniku migracji Anthropic.

Jaki effort ustawić na Sonnet 5.5?

Poziomy są przekalibrowane względem Sonneta 5, więc ustaw effort jawnie i zmierz go na własnych zadaniach. Anthropic proponuje medium do dobrze opisanych zadań agentowego kodowania (high przy trudniejszych), medium albo low do czatu i zadań wrażliwych na opóźnienie, a high do pozostałych. W API domyślny jest high, w Claude Code i aplikacjach Claude medium.

Czy Sonnet 5.5 jest dostępny w GitHub Copilot?

Tak, od 28 września 2026 dla planów Copilot Pro, Pro+, Max, Business i Enterprise. W przeciwieństwie do Opus 5.5 i GPT-6 Sol jest dostępny także w planie Pro.

Czym różni się Sonnet 5.5 od GPT-6 Sol?

Oba kosztują $2 / $10 za milion tokenów i $0.20 za odczyt z cache. W tabeli Anthropic Sonnet 5.5 prowadzi na FrontierCode (52.1% vs 49.3%) i wyraźnie w pracy zawodowej na GDPval-AA (1844 vs 1487 Elo). Wybór zależy głównie od ekosystemu: Claude Code czy Codex, i od wyników na Twoich zadaniach. 29 września następcą GPT-6 Sol został GPT-6.1 Sol z tańszym cache ($0.10), więc aktualne porównanie jest w tekście GPT-6.1 Sol vs Claude Sonnet 5.5.

Źródła: Anthropic - Introducing Claude Sonnet 5.5 (benchmarki, cena, bezpieczeństwo, cytaty testerów), Anthropic - Migrating to Claude Sonnet 5.5 (zmiany łamiące, between_tools), Anthropic - Prompting Claude Sonnet 5.5 (effort, weryfikacja przy low), Anthropic - Effort (rekomendowane poziomy), GitHub Changelog - Claude Sonnet 5.5 in GitHub Copilot, Claude na X - stała cena Sonneta 5, MarkTechPost - Claude Sonnet 5.5.

EfektywnyDev pisze o AI w praktyce - o tym, co zmienia się w rachunku i w kodzie po podmianie model ID, a nie tylko o tym, co pokazano na premierze.