O czym jest ten film
- Premiera Haiku 5.5, najmniejszego modelu Anthropic w rodzinie 5.5 — według Theo pierwszy od dawna mały model tej firmy, którego naprawdę opłaca się używać.
- Cennik: średnio ok. 75% taniej niż Haiku 4.5, m.in. 1 cent za milion odczytów z cache i 50 centów za milion tokenów wyjścia. Haczyk: po przekroczeniu 100 tys. tokenów kontekstu stawki rosną pięciokrotnie.
- Przy okazji Anthropic potanıł odczyty z cache w Sonnecie 5.5 z 20 do 10 centów za milion tokenów — zmiana, która według Theo najbardziej porządkuje sensowność całej oferty.
- Wyniki: ponad dwukrotnie lepiej niż Haiku 4.5, ponad dwukrotnie lepiej w kodzie niż GPT-6 Luna (Terminal Bench: niemal 40% kontra 16,4%), zaskakująco mocno w sterowaniu komputerem i bardzo szybko — 100–200 tokenów na sekundę.
- Słaby punkt: praca z wyłączonym rozumowaniem. Tu nadal wygrywają modele OpenAI, co na własnej skórze sprawdził użytkownik Prime.
- Analiza opłacalności: najwięcej inteligencji za dolara dają GPT-6 Luna, GPT-6.1 Sol i Opus 5.5; Haiku trzyma się z nimi łeb w łeb. Sonnet 5.5 na maksymalnym rozumowaniu nie ma ekonomicznego sensu (7,60 dol. za zadanie).
- Demo Anthropic: Opus dyrygujący dziesięcioma podagentami Haiku rozwiązał zadanie szybciej i ponad trzykrotnie taniej niż sam Opus (0,14 dol. wobec 0,47 dol.).
- Nowość dla subskrybentów Claude Code: comiesięczny kredyt na API (200 dol. na planie 200-dolarowym, 100 dol. na planie 5x) oraz wsparcie computer use i browser use w SDK dla Pythona i TypeScriptu.
- Ekonomika praktyczna: samo generowanie kodu jest tanie — drogie jest zbieranie kontekstu, weryfikacja i poprawianie błędów. Do tego Haiku pasuje znakomicie, do pisania kodu lepiej użyć mocniejszego modelu.
- Wnioski końcowe: rodzina 5.5 to spójna, konkurencyjna oferta; Theo zostaje przy duecie Opus + Sol (Sol jako audytor „z innej rodziny”), a na Fable 5.5 czeka z niecierpliwością.
10 najważniejszych takeaways — z kontekstem zastosowania
1.Mały model delegowany, nie wybierany ręcznie
Na czym polega: Haiku 5.5 błyszczy jako podagent — do przeszukiwania repozytorium, kategoryzacji danych, audytu — a nie jako model, który sam wybierasz do własnej pracy w interfejsie.
Jak stosować: w konfiguracji agentów (np. w plikach CLAUDE.md) dopuść Haiku 5.5 do tanich ról: zbieranie kontekstu, wstępna klasyfikacja PR-ów, przeszukiwanie kodu. Decyzję, kiedy po niego sięgnąć, zostaw głównemu modelowi — on lepiej rozpozna właściwy moment.
Na co uważać: nie deleguj mu zadań wymagających sprytu. Gdy model sobie nie radzi, krąży i spala tokeny, więc potrafi wyjść drożej niż mocniejszy model, który rozwiąże problem za pierwszym razem.
2.Pułapka 100 tys. tokenów: ustaw okno kompresji kontekstu
Na czym polega: niskie stawki Haiku 5.5 obowiązują tylko do 100 tys. tokenów kontekstu. Powyżej progu ceny rosną pięciokrotnie — np. z 50 centów do 2,50 dol. za milion tokenów wyjścia.
Jak stosować: w Claude Code ustaw Haiku 5.5 okno automatycznej kompresji kontekstu na 100 tys. tokenów. Ustawienie zapamiętywane jest per model i obejmuje także podagentów, więc daje gwarancję pracy w tańszym przedziale — szczególnie ważne przy rozliczeniach po API lub przez Bedrock.
Na co uważać: przy długich sesjach agentowych limit 100 tys. bywa ciasny, a gwałtowne ścinanie kontekstu może pogorszyć jakość rezultatów — w demie Theo silnie przycięty kontekst oznaczałby tańszą, ale wyraźnie gorszą grę.
3.W kosztach agentów rządzą odczyty z cache
Na czym polega: w pracy agentowej odczyty z cache (ponowne wykorzystanie raz wczytanych fragmentów rozmowy) potrafią stanowić 30–50% rachunku. Anthropic obniżył je w Sonnecie 5.5 z 20 do 10 centów za milion tokenów, a w Haiku 5.5 kosztują 1 cent.
Jak stosować: porównując modele do pracy agentowej, patrz na pełną strukturę kosztów — odczyty, zapisy do cache, wejście, wyjście — a nie tylko na cenę tokenów wejścia i wyjścia z cennika.
Na co uważać: wykresy w skali logarytmicznej zniekształcają proporcje — pokazują tanie modele jako dalsze, a drogie jako bliższe, niż są w rzeczywistości. Przy decyzjach cenowych przełączaj się na skalę liniową.
4.Z wyłączonym rozumowaniem wybierz inny model
Na czym polega: Haiku 5.5 pozwala wyłączyć rozumowanie, ale w tym trybie wypada słabo — modele OpenAI są do takiej pracy trenowane, modele Anthropic nie. Prime, który podmienił Lunę na Haiku bez rozumowania, zanotował gorszą skuteczność i wyższy odsetek błędów.
Jak stosować: do prostej klasyfikacji z wyłączonym rozumowaniem wybieraj tańsze alternatywy (Jev, ewentualnie Luna). Haiku zostaw z rozumowaniem włączonym — tam jego wyniki w swojej półce cenowej są bardzo dobre.
Na co uważać: jeśli zadanie wymaga analizy obrazu, wybór zawęża się do modeli z tą możliwością — wtedy Luna bywa tańsza, zwłaszcza bez rozumowania.
5.Sam kod jest tani — drogie jest wszystko dookoła
Na czym polega: wygenerowanie pliku z kodem, gdy kontekst jest już w cache, kosztuje grosze nawet na najdroższym modelu. Prawdziwe koszty to zbieranie kontekstu, weryfikacja rezultatów, testy, integracje i ponawianie nieudanych prób.
Jak stosować: optymalizuj to, co faktycznie drogie — niech Haiku zbiera kontekst, przeszukuje repozytoria i weryfikuje warianty, a mocniejszy model pisze finalny kod i podejmuje decyzje.
Na co uważać: wyjątkiem są sytuacje z tanią, automatyczną weryfikacją (np. testy) — wtedy generowanie przez Haiku pięciu–ośmiu wersji rozwiązania może się opłacać. Bez takiego systemu — nie.
6.Liczba prób zamiast mądrości pojedynczej próby
Na czym polega: w zadaniach, w których większość odpowiedzi jest zła — np. szukanie jednego pliku, którego nie wyłuska ripgrep — dziesięć równoległych prób Haiku wygrywa z jedną przemyślaną próbą drogiego modelu.
Jak stosować: buduj architekturę „dyrygent i orkiestra”: Opus planuje i nadzoruje, Haiku masowo wykonuje tanie próby. W demie Anthropic skróciło to podejście zadanie z 3,5 minuty do niecałej minuty i obniżyło koszt z 0,47 do 0,14 dol.
Na co uważać: schemat działa tylko tam, gdzie różnica między „próbą na chybił trafił” a przemyślaną próbą jest niewielka. Do zadań wymagających głębokiego rozumowania równoległość nic nie da.
7.Tani model bywa droższy w użyciu
Na czym polega: stawka za token to nie koszt zadania. Jeśli Haiku spali milion tokenów, zanim odkryje, że nie umie, a Opus rozwiąże problem w 100 tys., tani model wychodzi drożej.
Jak stosować: mierz koszt zadania (we własnych logach albo na Artificial Analysis), a nie tylko cennik. Wysokie poziomy rozumowania potrafią rozpędzić zużycie — Sonnet 5.5 na maksimum generował średnio niemal 200 tys. tokenów na zadanie.
Na co uważać: paradoks dotyczy też droższych modeli — przed włączeniem najwyższych poziomów rozumowania sprawdź, czy jakość rezultatów naprawdę tego wymaga.
8.Nie przepłacaj za maksymalny poziom rozumowania
Na czym polega: Sonnet 5.5 w trybie max kosztuje ok. 7,60 dol. za zadanie i według Theo nie ma to ekonomicznego sensu; rozsądny jest poziom x-high (ok. 2,75 dol.). W rodzinie Anthropic najlepiej wygląda duet Haiku (tanio) + Opus (jakość).
Jak stosować: domyślnie ustawiaj średnie poziomy rozumowania i podnoś je punktowo, gdy zadanie wyraźnie tego wymaga. Sonneta w wielu scenariuszach można pominąć całkowicie.
Na co uważać: progi opłacalności zmieniają się z każdą rewizją cennika — po obniżce odczytów z cache w Sonnecie jego pozycja na wykresach wyraźnie się poprawiła. Po każdej takiej zmianie przelicz swoje scenariusze.
9.Audytor z „innej rodziny” złapie to, czego Twój model nie widzi
Na czym polega: modele jednej firmy myślą podobnie — jak zespół pracujący razem na co dzień. Model konkurencji (tu: GPT-6.1 Sol) działa jak kolega z innej firmy: wnosi świeżą perspektywę, zwłaszcza przy audycie kodu.
Jak stosować: schemat „Opus pisze, Sol recenzuje przed wystawieniem PR-a” przyspiesza lądowanie kodu, bo oczywiste błędy są wyłapywane jeszcze przed review. Ustaw takie konsultacje jako stały krok w workflow.
Na co uważać: to architektura na dwóch dostawców. Jeśli z przyczyn umownych siedzisz w jednym ekosystemie, podobną rolę drugiego głosu może pełnić Haiku — modele jednej rodziny lepiej się nawzajem rozumieją.
10.Kredyt API przy subskrypcji — okazja do budowania produktów
Na czym polega: Anthropic doładowuje konta API subskrybentów Claude Code: 200 dol. miesięcznie na planie za 200 dol. (20x) i 100 dol. na planie 5x. Kredyt wydaje się na API, więc można z nim wbudować modele we własne aplikacje.
Jak stosować: jeśli masz subskrypcję, wykorzystaj kredyt do zbudowania i rozesłania znajomym aplikacji z Haiku albo Sonnetem w środku — bez zakładania osobnego rozliczenia po API od zera.
Na co uważać: warto śledzić warunki programu — pierwotny wariant był według Theo znacznie gorszy i zmieniono go dopiero po konsultacjach ze społecznością.
Redakcyjne tłumaczenie
Lata problemów z małymi modelami
Anthropic od dawna robi znakomite duże modele do programowania — wystarczy wymienić Fable i Opusa, a idąc dalej wstecz, Sonneta 3.5, który wraz z wywołaniami narzędzi (tool calls) na trwałe ukształtował sposób, w jaki inżynierowie pracują dziś z AI. W ofercie firmy zawsze świeciła jednak jedna rysa: modele małe. Haiku 4.5 przy premierze budził uznanie, ale wypuszczono go w październiku zeszłego roku i od razu — jak na swoje możliwości — był drogi. Dziś to po prostu żart. Włożyłem sporo pracy w dostrojenie całego otoczenia: plików konfiguracyjnych agentów, CLAUDE.md (Informacja dodatkowa: CLAUDE.md — plik z instrukcjami i preferencjami dla agenta Claude Code) i pozostałych narzędzi tak, żeby każdy agent w moim systemie wiedział, że Haiku 4.5 należy omijać szerokim łukiem, bo się do niczego nie nadaje.
Stąd mój wpis sprzed kilku tygodni: Anthropic nie ma dziś żadnego małego modelu wartego użycia. Przy okazji dorzuciłem złośliwość pod adresem OpenAI — brak dużych modeli wartych uwagi, bo mieli wtedy Astrę i 6.0 Sola, bez 6.1 — a na koniec żarcik, że Google nie ma żadnych wartych uwagi w ogóle.
Mechanizm znamy od lat: Anthropic tradycyjnie wrzucał niemal cały wysiłek w największy model, po czym słabo destylował go na tańsze wersje. Kiedy firma skupiła się na Mythosie i Fable, jakość Opusa runęła — po kolei zobaczyliśmy 4.6, 4.7, 4.8, aż wreszcie fatalnego Opusa 5. Wszystko to był skutek fiksacji na wielkich modelach. To fatum zostało jednak przełamane: i Opus 5.5, i Sonnet 5.5 są udane — i dlatego z takim entuzjazmem czekałem na dzisiejszy debiut Haiku 5.5.
Zapowiadano go od jakiegoś czasu, a moje podejście brzmiało: wysokie nadzieje, niskie oczekiwania. To przecież największa dziura w całym portfolio — model, po który sięgają inne modele, żeby wyszukać pliki, trzykrotnie sprawdzić zmiany i załatwić wszystko to, na co drogi model nie powinien marnować tokenów. Doszedłem do punktu, w którym nauczyłem swojego Claude’a wołać do tanich zadań Sola z OpenAI, żeby oszczędzać — bo nie ufałem mu na tyle, by sam sięgał po Haiku 4.5.
I jak wyszło? Nie chcę zapeszać, ale śmiem twierdzić, że zrobili coś naprawdę fajnego. Cena jest odpowiednia, wydajność wygląda solidnie, a model ma w zanadrzu kilka sztuczek, które czynią go wyjątkowym jak na tak małą skalę.
Zapowiedź: najtańszy, najszybszy i najzdolniejszy
W komunikacie premierowym Anthropic nazywa Haiku 5.5 najtańszym, najszybszym i najbardziej zdolnym małym modelem w historii firmy. Ma obsługiwać masowe, wrażliwe na koszty zadania: streszczenia, skracanie kontekstu, zapytania do baz danych, klasyfikację. Dobrze współgra z Opusem i Sonnetem jako podagent przy pracy nad kodem, a ponieważ to zarazem najszybszy model firmy, pasuje tam, gdzie liczy się reakcja na żywo: obsługa klienta i sterowanie przeglądarką. Średnio kosztuje o ok. 75% mniej niż Haiku 4.5.
I druga wiadomość, dla mnie może najważniejsza: Anthropic obniżył cenę odczytów z cache w Sonnecie 5.5 — to ponowne wykorzystanie fragmentów rozmowy raz już wczytanych do modelu, pozycja, która w pracy agentowej potrafi stanowić 30–50% rachunku. Stawka spadła z 20 do 10 centów za milion tokenów, czyli do poziomu GPT-6.1 Sola. Właśnie za to dostało się im ode mnie w filmie o Sonnecie 5.5: dotąd odczyty kosztowały tyle co w Opusie, więc przy pracy agentowej różnica cen między tymi modelami była mizerna, a Sonnet wypadał słabiej niż 6.1 Sol. Mogłbym opowiedzieć o świecie wycen cache sporo historii, których opowiedzieć nie wolno — kto wie, ten wie.
Przerwa na sponsora
Krótko, bo to część odcinka: przy rosnącej złożoności baz kodu coraz trudniej wychwycić realne problemy bezpieczeństwa, a najlepsze modele często po prostu odmawiają pomocy w takich tematach. CodeRabbit załatwił formalności z dostawcami modeli tak, żeby w pull requestach pojawiały się prawdziwe alarmy bezpieczeństwa wraz z przyciskiem naprawy wykonywanym po stronie serwisu. Funkcja głębokiego skanu całego repozytorium (pół godziny, godzina) wygenerowała mi tyle użytecznych trafień, że zaadresowałem ponad połowę z nich. Przy coraz bardziej skomplikowanym oprogramowaniu pilnowanie bezpieczeństwa staje się tylko ważniejsze.
Cennik: grosze za milion tokenów i jeden haczyk
Cennik Haiku 5.5 wygląda tak: 1 cent za milion tokenów odczytu z cache (dziesięciokrotnie taniej niż dotąd), 12,5 centa za milion zapisu do cache, 10 centów za milion tokenów wejściowych i 50 centów za milion wyjściowych. Dla porównania: Haiku 4.5 płacił tę samą stawkę za odczyty z cache co więksi bracia, a poza tym mniej więcej połowę ich cen; wyjście kosztowało w nim 5 dol. za milion tokenów, a w Sonnecie 5.5 — 10 dol. W praktyce Haiku 5.5 jest więc około dwadzieścia razy tańszy od Sonneta w tokenach wejścia i wyjścia, tyle samo w zapisach do cache, a w odczytach — dziesięciokrotnie.
Jest jednak haczyk: te stawki obowiązują do 100 tys. tokenów kontekstu. Warto przypomnieć, że Anthropic kiedyś podwajał ceny po przekroczeniu ok. 250 tys. tokenów, a niedawno z tego zrezygnował — słusznie, bo w Claude Code nie trzeba teraz mikrozarządzać kontekstem, żeby utrzymać rachunek w ryzach. Ale limit 100 tys. wygląda na ciasny, zwłaszcza przy dłuższej pracy agentowej. I jeszcze gorzej: powyżej progu cena nie rośnie dwukrotnie, tylko pięciokrotnie — z 50 centów do 2,50 dol. za milion tokenów wyjścia, z 10 do 50 centów za milion wejścia i tak dalej. Uzasadnienie infrastrukturalne jest proste: długi kontekst to więcej pamięci operacyjnej do utrzymania, a to kosztuje.
Moja lektura jest taka, że pod spodem siedzą dwa cele. Po pierwsze, główny scenariusz użycia — szybkie odczyty i klasyfikacja — został wyceniony tak tanio, jak się da. Prawdziwym rywalem małego modelu w tych rolach jest przecież Jev (Informacja dodatkowa: tani model konkurencji, którego Theo wskazuje jako naturalnego przeciwnika Haiku w prostych zadaniach klasyfikacyjnych), a przy takich stawkach coraz trudniej uzasadniać doklejanie kolejnego API, skoro można po prostu rzucić tekst Haiku. Po drugie — zabezpieczenie firmy przed sytuacją, w której ludzie wejdą z tym modelem w długie sesje Claude Code i zrujnują jej rachunki. Tanie poniżej progu, rozsądnie drogie powyżej: sterowanie użytkowników ku przewidzianemu zastosowaniu.
Warto przy tym znać poradę od środka: Lydia z Anthropic publicznie podpowiedziała, że w Claude Code można ustawić okno automatycznej kompresji kontekstu Haiku 5.5 na 100 tys. tokenów i zawsze pracować w tańszym przedziale. Ustawienie zapamiętywane jest per model i obejmuje także podagentów — przy rozliczeniu po API albo przez Bedrock daje to gwarancję, że podagenty nigdy nie narobią astronomicznych rachunków.
Benchmarki, prędkość i tryb bez rozumowania
W moim zestawie testów Haiku 5.5 rozgromił Haiku 4.5, w zdecydowanej większości zadań zdobywając ponad dwukrotnie wyższe wyniki. Znajomy z Anthropic przyznał mi z zadowoleniem, że Haiku przestał zerować na Terminal Bench — wyszedł z zera na niemal 40%. Dla skali: GPT-6 Luna uzyskała tam 16,4%. Haiku podwoił więc wynik Lunny w kodzie — więc jeśli należeliście do osób, które uważały, że Luna radzi sobie z kodem przyzwoicie, cóż… mam wątpliwości co do wielu waszych ocen. Tak czy inaczej: macie teraz model, który — jak głoszą liczby — jest ponad dwukrotnie lepszy w kodzie za niewiele wyższą cenę.
Bardzo ciekawy jest wynik ze sterowania komputerem (computer use). OpenAI od jakiegoś czasu wyprzedzał konkurencję właśnie w tej dyscyplinie, a te benchmarki moim zdaniem w ogóle nie pokazują, jak wielka jest przepaść w praktyce. Haiku i tak zmiażdżył rywali — o niemal 40% lepiej od GPT-6 Luna. Na papierze bardzo solidny mały model do sterowania komputerem; sam jeszcze nie próbowałem, ale słyszałem dobre rzeczy. A kiedy zobaczycie prędkości, zrozumiecie moją radość: Haiku 5.5 osiąga od 100 do 200 tokenów na sekundę, zależnie od dostawcy.
Jedno zastrzeżenie: tryb bez rozumowania. Prime tweetnął, że podmienił Lunę na Haiku w automacjach z wyłączonym rozumowaniem — podmiana bez żadnych zmian w konfiguracji — i zobaczył gorszą skuteczność, wyraźnie wyższy odsetek błędów i zauważalnie wolniejsze tempo. Nie dziwi mnie to. OpenAI trenuje swoje modele, żeby radziły sobie bez rozumowania; Anthropic trenuje swoje, żeby sobie nie radziły. W Opusie i Sonnecie 5.5 opcja „bez rozumowania” w ogóle zniknęła — model zawsze musi choć chwilę pomyśleć. Haiku ją zostawił, bo bywa potrzebna odpowiedź natychmiast, tylko że Haiku w tym trybie jest po prostu słaby. Moja szczera rada: jeśli i tak wyłączacie rozumowanie, do kategoryzacji bierzcie Jeva — bawię się ostatnio API decyzyjnym OpenAI i mam o nim sporo do powiedzenia, ale to temat na osobny materiał. Haiku albo Luna mają sens dopiero, gdy potrzebujecie rozpoznawania obrazów — i pewnie Luna, bo jest tańsza, zwłaszcza bez rozumowania. Z rozumowaniem włączonym liczby Haiku wyglądają bardzo dobrze: u mnie, w Claude Code przy zwykłym promptowaniu nad Fish Slap, widziałem około 180 tokenów na sekundę.
Slop Politics: tokeny na zadanie i linia Pareto
(Informacja dodatkowa: Slop Politics — autorskie narzędzie Theo do wizualizacji wyników benchmarków, cen i opłacalności modeli; dane czerpie z serwisu Artificial Analysis, niezależnie porównującego modele AI pod względem jakości i kosztów.)
Zacznijmy od zużycia tokenów na zadanie, bo jest ku temu powód: wygląda na to, że nie mamy do czynienia z typowym rozrzutnym cyrkiem, jaki serwują małe modele OpenAI. Dla skali: Sonnet 5.5 na maksymalnym poziomie rozumowania zużywał średnio niemal 200 tys. tokenów na zadanie — chyba rekord w historii Artificial Analysis — podczas gdy Fable 78 tys., czyli ponad dwukrotnie mniej. Efekt: koszt Sonneta 5.5 wyszedł odrobinę wyżej niż Fable 5.1, a wszystkiemu winne jedno nierozsądne ustawienie: „max”. Na wykresie wystarczy kliknąć to słowo, żeby zniknęło — i nagle zarówno zużycie, jak i ceny za zadanie zaczynają mieć sens. Haiku 5.5 ląduje z lewej strony, tańszy niż cokolwiek innego. Z jednym zastrzeżeniem: GPT-6.1 Sol na niskim poziomie rozumowania jest równie tani jak Haiku na niskim — głównie dzięki znacznie lepszej oszczędności tokenów.
Na wykresie kosztu kontra inteligencja widać coś niezręcznego: w zagregowanych wynikach Sonnet 5.5 wypada gorzej niż Opus przy takim samym, a niekiedy wyższym koszcie. Te modele po prostu nie uzupełniają się tak, jak by się chciało. Ale w samym lewym krańcu, przy Haiku 5.5, robi się ciekawie: wyniki zbliżone, a przebieg Opusem kosztował prawie pięciokrotność.
Mam w narzędziu linię Pareto — najlepszy osiągalny wynik przy danym budżecie. W rodzinie Anthropic najlepiej w swojej półce wypadają Haiku 5.5 na poziomach x-high i max; Sonnet 5.5 na „high” wślizguje się tam niejako przy okazji, bo jest sprytniejszy od Opusa na „low” i tańszy od Opusa na „medium”; wyżej wszystko należy do Opusa 5.5: medium, high, x-high, max.
Po przełączeniu skali na liniową widać, że przepaści nie są tak wielkie, jak sugeruje logarytmiczna — ta maluje tanie modele jako dalsze, a drogie jako bliższe, niż są naprawdę. Sonnet x-high za 2,75 dol. za zadanie to uczciwa propozycja. Sonnet 5.5 max za 7,60 dol. — kompletnie bez sensu. Bardzo proszę: nie używajcie Sonneta 5.5 na maksimum.
Dobrze, ale to wciąż tylko modele Anthropic — i to najnowsze z każdej linii. Co z konkurencją? Gemini 4 Argon — prawie nic. Flash 3.8 — też nic; wygląda, jakby ktoś wziął linię Haiku i przesunął ją w prawo i w dół. Grok 4.7 — wciąż poniżej wszystkiego. GPT-6 Astra na „low” dorzuca punkt, bo ma inteligencję z grubsza na poziomie Sonneta 5.5 na „high”. A potem robi się naprawdę ciekawie: GPT-6 Luna ciągnie linię daleko w lewo, bo Luna jest zawsze tańsza od Haiku — i zawsze głupsza, przynajmniej według tych danych. To modele uzupełniające się idealnie. Gdyby wyłączyć Astrę i Sonneta, zostaje czysta, prosta linia najlepszej wartości za dolara.
I tu wchodzi Sol. Włączenie GPT-6.1 Sol psuje obrazek: przejście z 21,3 na 21,4 centa daje potężny przeskok inteligencji, a po wyłączeniu Haiku linia robi się dużo gładsza. Wniosek czysto benchmarkowy: jeśli optymalizujecie inteligencję za dolara, wasz zestaw to GPT-6 Luna, GPT-6.1 Sol i Opus 5.5. Jest jeszcze jedna perła, o której mało kto mówi: Mimo V26 Pro — niedoceniany model o otwartych wagach, bardzo dobry jak na cenę. Haiku 5.5 jest teraz łeb w łeb z tym gronem; Sol i Luna wciąż zwykle wychodzą odrobinę lepiej w przeliczeniu na dolara.
To jednak nie cała prawda, bo są powody, żeby zostać w jednym ekosystemie: zobowiązania zakupowe u jednego dostawcy, subskrypcja Claude Code bez dokupowanego osobno Codexu, wreszcie fakt, że modele jednej rodziny lepiej się nawzajem rozumieją — Opus pytający Haiku wypada lepiej niż Opus pytający Sola. Nie wiem, ile w tym nauki, a ile praktyki, ale działa.
Na koniec dobra wiadomość: Artificial Analysis zaktualizował dane po obniżce odczytów z cache, więc i ja odświeżyłem swoje. Sonnet przesunął się wyraźnie w lewo i wygląda przekonująco — może nie dramatycznie, ale jego punkt na „high” przestał być taki niezgrabny, a cała pozycja tego modelu przestała uwierać.
Kredyty API i nowe możliwości SDK
W notatkach wydawniczych kryje się rzecz naprawdę fajna. Anthropic chce zachęcić użytkowników Claude Code do budowania na swoich API — a wielu z nas, mnie włącznie, przed tą zapowiedzią chwycił strach, że firma zakręci kran i położy korzystanie z subskrypcji w narzędziach firm trzecich, takich jak moje T3 Code (Informacja dodatkowa: T3 Code — narzędzie Theo do pracy z agentami kodującymi), gdzie subskrypcja Claude Code albo Codexa po prostu działa. Obawialiśmy się, bo takie groźby padały. Nie zrobili tego. Zamiast tego zrobili coś naprawdę eleganckiego: subskrybent planu za 200 dol. (tzw. 20x) dostaje co miesiąc 200 dol. kredytu na API, użytkownicy planu 5x — 100 dol. W praktyce dostajesz klucz API, jak zwykły płatnik, tylko wstępnie naładowany. Chcesz zbudować w Claude Code aplikację z Haiku albo Sonnetem w środku i wysłać ją znajomym? Masz na to co miesiąc świeży budżet.
Rozmawiałem z nimi o tym sporo, kiedy dopracowywali integracje Claude Code SDK i Agent SDK — pierwotny pomysł był dużo głupszy. Jestem wdzięczny, że pytali ludzi takich jak ja i że słuchali, bo z potencjalnej porażki zrobili coś naprawdę dobrego. Jeśli zauważyliście, że jestem dla Anthropic łagodniejszy — to właśnie dlatego: teraz słuchają.
Dwa drobiazgi na deser. Pierwszy: SDK Claude dla Pythona i TypeScriptu dostają obsługę computer use i browser use — to może nam się bardzo przydać, T3 Code ma szansę z tego podrosnąć. Drugi: Elon pogratulował im modelu. Szczerze mówiąc, zdziwiłbym się, gdyby Haiku 5.5 nie był przyjemniejszy w użyciu niż Grok 4.7. No i świeży wykres skokowy Artificial Analysis: Haiku przeskoczył ze skrajnego prawego krańca do realnej konkurencji. Tamci są bezlitośni i nie dają mu linii Pareto, ale danych jest więcej, niż przyznają.
Właściwa rola Haiku: podagent, który nic nie kosztuje
Najlepsze zastosowania Haiku 5.5 nie polegają na klikaniu go w interfejsie ani na wybieraniu w Claude Code do własnej pracy. Polegają na tym, żeby używały go twoje agenty i aplikacje: żeby audytował i porządkował napływające dane, żeby Sonnet albo Opus wołał go do testowania pomysłów i przeszukiwania kodu.
Anthropic przygotował na to zgrabne demo: Opus 5.5 samodzielnie próbował zbudować bezpieczne zrzucanie jajka (klasyczne zadanie inżynierskie: skonstruować ochronę dla jajka zrzuconego z wysokości) w przygotowanej przez firmę emulacji. Obok — Opus 5.5 plus dziesięć podagentów Haiku 5.5. Różnica rzuca się w oczy od razu: samotny Opus działa jednowątkowo i próbuje po jednej rzeczy naraz, a wielowątkowość oznaczałaby dla niego spalenie znacznie większej kasy. Zespół Opusa z dziesiątką Haiku testuje wiele ścieżek równolegle, oszczędza górę pieniędzy i szybciej dobiega do mety.
Konkretne liczby: sam Opus uporał się z zadaniem w trzy i pół minuty, zaprojektował 25 prób i zapłacił 47 centów. Opus dyrygujący dziesiątką Haiku zrobił to w niecałą minutę — 86 prób, bo przy takich cenach i prędkościach mógł sobie pozwolić na znacznie więcej podejść — i kosztowało to 14 centów. Dla zadań, w których większość odpowiedzi jest zła — na przykład szukanie jednego pliku w gąszczu, którego nie wyłuska ripgrep (narzędzie do błyskawicznego przeszukiwania tekstu) — Haiku będzie tańszy i szybszy, bo naraz obsługuje wiele ścieżek bez kosmicznych rachunków. Jeżeli liczba prób znaczy więcej niż ich mądrość, a różnica między chybił-trafił z prostego modelu a przemyślaną próbą mocnego jest niewielka — Haiku zmiecie konkurencję.
To wąski podzbiór pracy. Mam nadzieję, że Opus jest wystarczająco rozsądny, by ten podzbiór rozpoznawać — jeszcze go dość nie przycisnąłem, żeby wiedzieć na pewno. Wiem za to, że idę edytować swojego CLAUDE.md, żeby przestać wymuszać Opusa albo Sola na każdym podagencie, bo przy takich cenach to po prostu zaczyna mieć sens.
Demonstracje społeczności: wideo i design
Moja społeczność od razu rzuciła się robić pokazy wideo — wszyscy wiedzą, że Opus 5.5 zrobił ogromny postęp w programistycznym tworzeniu filmów. Ten przykład przysłał Arshan. Jestem pod ogromnym wrażeniem jak na te pieniądze: film kosztował 60 centów po stronie API i powstał w niecałe dwadzieścia minut.
Duża część zasługi leży w tym, co nazwałbym smakiem: modele Anthropic mają wbudowane dobre wyczucie, zwłaszcza w designie. Podejrzewam, że mają mnóstwo znakomicie dobranych danych projektowych i obsesyjnie przycięli ten zbiór, żeby model miał solidne punkty odniesienia. Widać to jeszcze wyraźniej we front-endzie — dema powstały w narzędziu Which AI przygotowanym przez Darę. Komicznie lepsze od Groka. Animacja pojawiania się tekstu — czegoś takiego w tych pokazach jeszcze nie widziałem. Wersja w stylu „blueprintu” reaguje po najechaniu kursorem i podmienia treść pod spodem; nie zachwyca mnie, ale to coś nowego. Czcionki przyzwoite — model nie sięga już tak często po fonty budzące zażenowanie.
A teraz kluczowy test: co się stanie, gdy wyłączymy umiejętność projektową? Wracamy do klasycznego „projektowania po LLM-owemu”. Ta umiejętność robi dziś ogromną różnicę — ja ją odinstalowałem i zdecydowanie muszę przywrócić, bo jest dużo lepsza niż kiedyś. Dla kontrastu Grok 4.7… wybaczcie, muszę się chwilkę śmiać. Z wyłączoną umiejętnością jest jeszcze gorzej. Ktoś na czacie przyznał, że szczerze sądzi, iż w podstawowej szkole robił w czystym HTML-u lepsze strony niż to, co pokazuje Grok — i trudno się nie zgodzić.
Konkluzja praktyczna: jeśli wybieracie Haiku z pobudek budżetowych — na przykład z planem za 8 dol. w OpenCode — da się na tym pracować. Nie jest wspaniale i nie będę udawał, że to wszystko, czego potrzebujecie do front-endu, ale „przyzwoity” przy takiej cenie to osiągnięcie. Możliwe, że 20-dolarowa subskrypcja Claude wystarczy do kodu. Nie będę zakładał konta, żeby to sprawdzić — mam ich już zdecydowanie za dużo.
Próba bojowa: pull requesty i Fish Slap
Z ciekawości rzuciłem Haiku 5.5 na jedno z moich ulubionych zadań: audyt otwartych pull requestów. T3 Code ma ich teraz trochę poniżej 1500 — a sądząc po tempie napływu, będzie dokładnie 1500, zanim skończę to zdanie. Jedna sesja zajmuje się PR-ami dotyczącymi wydajności, druga przechodzi i porządkuje wszystkie po kolei — przy okazji poprawiałem jej jeszcze polecenia co do modeli podagentów. Na koniec mam dostać elegancką stronę HTML z raportem.
A na czas oczekiwania — mój ulubiony sprawdzian: nowa wersja Fish Slap, gry, na której oglądam modele w boju. Ta odsłona ma problemy. Po pierwsze, brak ruchu myszą: sterowanie tylko spacją, shiftem i klawiszami WSAD. Po drugie, dźwięku brak — i nie dlatego, że mam wyciszone. Było szorstko. Poziom z grubsza jak wersja z Groka, czyli żenująco. Muszę jednak przyznać, że poza zupełnie nieczynną myszą nie ma tu nic rażąco, karygodnie źle zrobionego… nie, cofam: narożniki są po prostu złe. I jeszcze timing drugiego ataku obcych — nie miał prawa przyjść tak wcześnie. Model nie okazuje oryginałowi takiego szacunku, jakbym chciał.
Dla porównania z GPT-6 Astrą: tamta wersja wyglądała olśniewająco, ale mechanika była zła — mysz ślimaczyła się, pętla rozgrywki krzywa, błędy widoczne gołym okiem. Haiku nie ma tak niskich dołów jak Astra, ale jego szczyty są dziesięć razy niższe. Najkrócej: nie podejmuje złych decyzji — po prostu nie podejmuje imponujących.
Rachunek za tę sesję: około dolara. Z tego 9,73 mln tokenów odczytanych z cache, pokaźny zestaw godzinnych zapisów do cache (zawsze zapisuje godzinne, co irytuje), zaledwie 102 nowe tokeny wejściowe — bo cache pracował bez przerwy — i około 30 centów tokenów wyjściowych. Uwaga smaczna: 47 z 51 żądań przekroczyło 100 tys. tokenów wejścia, więc obowiązywał droższy cennik. Gdybym ściął kontekst, wyszłoby dużo taniej — ale gra byłaby pewnie znacznie gorsza.
A, pierwsza rewizja PR już wpadła. Czterdzieści otwartych PR-ów dotyczących wydajności, większość to poprawki serwerowe i mobilne, czystych i naprawdę istotnych jest tylko kilka. Na czele listy lądują te „gotowe do scalenia”, bo GitHub raportuje zieleń — model uznał, że skoro CI mówi „ok”, to jest ok, i sam ich dogłębnie nie przejrzał. Przykład z opisu: ponowne wykonanie polecenia nie zawiesza już serwera, a ponawianie spadło z ponad 18 sekund do 6 milisekund. Postępuję standardowo: otwieram Opusa, wklejam PR i piszę mniej więcej: „Wygląda na zmianę wartą włączenia. Ustal, czy tak jest, popraw wszystko, co wymaga poprawy, i scal, jeśli masz pewność, że jest gotowe. Pełna para.” Ten schemat — krótkie, zdecydowane polecenie — na trwałe zmienił sposób, w jaki buduję.
Dlaczego nie będę pisał nim kodu
Częste pytanie z czatu: czy będę używał tego modelu do kodu? Nie. I chcę to wyraźnie powiedzieć, bo moim zdaniem ogólnie źle o tym myślicie. To nie programowanie czyni LLM-y drogimi. Przejście od promptu do działającego pliku z kodem to nie jest większość waszych kosztów. Kosztuje wszystko inne: zebranie kontekstu potrzebnego do napisania pliku; sprawdzenie, czy zadziałało; napisanie masy kodu testującego zachowania brzegowe; zintegrowanie się z GitHubem, żeby pilnować PR-a; wygenerowanie tej samej rzeczy osiem razy, bo siedem pierwszych podejść było złych. A samo stworzenie pliku przy wejściu trzymanym w cache — nawet na najdroższym Fable — to kilka centów. Wygenerowanie 500 tokenów wyjścia przy już rozliczonym wejściu nie jest drogie.
Mówiąc krótko: nie rozumiem, czemu ludzie szukają głupszego modelu do części „kod”. Kod jest tani. Drogi jest przygotowanie przed nim i weryfikacja po nim — i właśnie jako tanie narzędzie do tych okolic Haiku ma wartość w rękach waszych modeli. Jeżeli środkowa część ma wokół siebie infrastrukturę — chcecie wypróbować pięć wariantów i macie trywialny system, który powie, co działa — generowanie pięciu, ośmiu wersji przez Haiku może się opłacać. Ale przy większości problemów mądrzejszy model piszący kod nie jest drogi i jest po prostu lepszy. Kiedy model ma niepewną teorię i chce sprawdzić cztery hipotezy, przejrzeć osiem otwartych projektów dla porównania albo przekartować dokumentację w poszukiwaniu faktów — wtedy Haiku jest znakomity. Realizacja planu? Jasne: przy naprawdę dokładnym planie z mądrego modelu prostszy model zaimplementuje jego fragmenty. Świetnie. Tylko pieniądze na plan już wydałeś.
Wpądka z limitami GitHuba — i właściwa architektura
No i wpadka, w dużej mierze moja wina. Wybiłem limit zapytań na GitHubie. Skrypt zapisał treść błędu tak, jakby to były dane API, po czym wywalił się na jq. Równoległe pobieranie PR-ów po kolei zżarło większość z 5000 żądań na godzinę, więc na jakieś 50 minut zostałem odcięty od integracji T3 Code z GitHubem. Dane w plikach PR-star.json są ważne, skrypt czeka na reset limitu, ma ponownie pobrać 181 PR-ów i nauczyć się odrzucać odpowiedzi, które nie są tablicą JSON. Problem w tym, że nie zaplanował tego oczekiwania — sesja po prostu umarła, dopóki sam jej nie ruszę. I właśnie dlatego nie lubię prostych modeli: same się zapędzają w kozi róg i utrudniają życie nie tylko sobie, ale i mnie.
Skoro limity i tak leżą, pokażę, jak zrobiłbym to na serio. Ten sam prompt, dwie zmiany. Po pierwsze: „używaj mnóstwa podagentów i workflowów, do wszystkich podagentów w tej pracy bierz Haiku 5.5, a własne działania ogranicz do zebrania danych i dyrygowania”. Po drugie: odpalam to na Opusie — bo w przeciwieństwie do Haiku Opus jest mądry i nie tylko nie powinien wpakować się w limity, ale też powinien umieć je obejść. Oto Opus w akcie rozmyślania: „1495 otwartych PR-ów to ogrom do obsłużenia podagentami. Partie po około 15 PR-ów na agenta Haiku dadzą z grubsza setkę agentów. To wykracza poza typowe wytyczne dla niewielkich workflowów, ale użytkownik wprost prosi o «mnóstwo podagentów»”. Widzicie? Przemyślał to.
Podsumowując architekturę: Haiku jest niesamowicie użyteczny jako narzędzie, które wmontujecie we własny kod i po które wasze agenty mogą sięgać. Nie wybrałbym go natomiast jako modelu w moich agentach programistycznych — siedzę na planie za 200 dolarów i wolę po prostu Opusa. I pamiętajcie: choć różnica cen wygląda ogromnie, model, któremu się nie wiedzie, potrafi wydać więcej. Jeśli Opus rozwiąże problem w 100 tys. tokenów, a Haiku spali milion, zanim zorientuje się, że nie umie — Haiku wyjdzie drożej. Przy wielu zadaniach Haiku nie tylko nie da rady, ale przepali przy tym kasę, próbując nie dać rady. A że cała branża poprawia stosunek ceny do możliwości, różnica między Opusem 5.5 na niskim poziomie rozumowania a Haiku 5.5 na maksymalnym nie jest taka wielka, jak by się wydawało: 20 centów kontra 55.
Kiedy sięgnąć po Sol
No dobrze — a kiedy Sol? Na wykresie to całkiem niezły pomost między Haiku a Opusem, idealnie wpada w środek. Ale tak nie myślę o Solu. Nie traktuję go jako modelu „gdy Haiku jest za prosty, a Opus za drogi”. Traktuję go jako inną rodzinę o podobnej inteligencji. Wyobraź sobie zespół ludzi, z którymi pracujesz codziennie, i naprawdę trudny problem. Pytasz wszystkich dookoła i wszyscy mniej więcej zgadzają się co do kierunku — naturalne, bo razem myślicie. Sol myśli inaczej. To jak zapytać przyjaciela z innej firmy o zdanie: świeża perspektywa. Modele OpenAI wnoszą ją szczególnie w dokładności audytu kodu — uwielbiam 6.1 Sola jako audytora. Ustawiłem wszystkim swoim agentom schemat: Opus pisze kod, a przed wystawieniem PR-a konsultuje się z Solem. Kod ląduje u mnie znacznie szybciej, bo Sol wyławia wszystkie głupoty, które Opus mógł przeoczyć — PR trafia na GitHub już wyczyszczony przez oba modele.
Ja zostaję przy duecie Opus + Sol. Ale kiedy Opus będzie musiał nazbierać danych, przejrzeć tony materiału albo coś porozkładać po kategorii — Haiku będzie świetnym nabytkiem. Sam nie będę go wybierał; ufam, że Opus dobierze go w momentach, w których to ma sens.
Podsumowanie: rodzina 5.5 domknięta
Efekt całości: bardzo przekonujący zestaw modeli. Przyjemnie widzieć, że Anthropic wreszcie robi małe modele realnie użyteczne do prawdziwej pracy — i do dziś trochę nie wierzę własnym oczom, widząc model tej firmy tak daleko na lewo na wykresie kosztu kontra inteligencja, łeb w łeb z Luną. To już nie jest brakujący element portfolio. Gdybyście używali wyłącznie Opusa i Haiku, niewiele byście stracili; Sonneta można śmiało pominąć — na linii Pareto nie oferuje dziś praktycznie nic.
Wracając do tezy z początku: „Anthropic nie ma małych modeli wartych użycia”. Ktoś odpisał mi wtedy pod wpisem, że wszystkie trzy tezy są fałszywe. Odpisałem: „LMAO, ten gość używa Haiku 4.5” — i został rozebrany na drobne w odpowiedziach, bo we wrześniu, a tym bardziej dziś, nie było żadnego powodu, żeby po ten model sięgać. Był ledwie używalny, szybko stał się kartoflem i nikt go nie ruszał, bo firma patrzyła wyłącznie na wielkie modele. Teraz nie patrzy. Proszę bardzo: Anthropic ma teraz jeden mały model, który czasem jest wart użycia. Bardzo miła zmiana.
Zostało mi już tylko jedno: nie mogę się doczekać Fable 5.5. Rozumiem, że pewnie poczeka — nie leży to zupełnie w duchu ich strategii stopniowego przesuwania granic możliwości — ale rodzina 5.5 nastawiła poprzeczkę tak wysoko, że naprawdę mam nadzieję, iż Fable utrzyma poziom Opusa, Sonneta i Haiku.
Anthropic panuje dziś na całej szerokości pola. Gdybym był OpenAI, byłbym bardzo, bardzo przerażony i modliłbym się, żeby następny trening Asty wyszedł niesamowity — bo szczerze mówiąc, mam już problem z wykorzystaniem subskrypcji Codex, skoro subskrypcje Claude są po prostu o wiele użyteczniejsze. Dajcie znać, czy podzielacie to odczucie, czy przesadzam. Do następnego razu — cześć, nerdy!