O czym jest ten film
- Tydzień po słabo przyjętych GPT-6 Soul i GPT-6 Luna OpenAI wypuszcza GPT-6.1 Soul — model, który według Theo realnie odpowiada na dominującego Opusa 5.5 od Anthropic.
- W benchmarkach (Terminal Bench 4, Deep SWE) nowość osiąga wyniki klasy frontier — na niektórych poziomach remisuje z Opusem 5.5 przy jednej siedemdziesiątej ceny i jednej dziesiątej czasu.
- Największa zmiana jest w cenniku: pierwszy raz w historii OpenAI obniżyło cenę odczytu z cache — z 90% do 95% zniżki względem zwykłego odczytu.
- Theo spekulatywnie twierdzi, że model „nie miał być wersją 6.1”: jest wyraźnie sprytniejszy od GPT-6 Soul, ma wolniejsze tokeny na sekundę (ślad większego modelu), a wpis analityka Tibo o zmianie zasad subskrypcji Pro za 200 dolarów pasuje do „doraźnej” premiery.
- Model niemal pozbył się „huśtawki jakości”, która psuła Astrę — mniej napadów głupoty, ale też niższe szczyty możliwości.
- Najmocniejsza strona: głębokie audyty kodu, code review i zadania o jasno określonym zakresie; najsłabsza: długa praca bez nadzoru (blokuje się na własnych regułach i nie prosi o pomoc) oraz frontendy.
- Opus 5.5 ocenił nowość „w ciemno”, pod zmienioną nazwą — uznał ją za model klasy frontier i określił realną cenę jako „bardzo agresywną”; po przeliczeniu sesji Thea koszt spadł z 5 700 do 1 550 dolarów.
- Case study: po miesiącach bez postępu w porcie TypeScript→Rust Opus doprowadził pracę do końca w dobę, a 6.1 Soul w audycie wykrył, że 1,3 mln z 1,8 mln linii to martwy kod.
- W autorskim teście „fish slop” model pokazał najlepszą grafikę 3D w historii testu (świetny też w Blenderze) i jednocześnie najbardziej zawalone, przeładowane tekstem UI.
- Werdykt: nie zdetronizuje Opusa jako codziennego narzędzia, ale czyni Sonnet zbędnym — a zmiana warunków subskrypcji może oznaczać początek końca ery subsydiowania.
10 najważniejszych takeaways — z kontekstem zastosowania
1.Prawdziwy koszt agenta to odczyt z cache, nie stawki z cennika
Na czym polega: W pętlach agentowych około 96% żądań to odczyty z cache. OpenAI po raz pierwszy obniżyło ich cenę — do 10 centów za milion tokenów (zniżka z 90% do 95%). To ta pozycja, a nie „2 dolary wejście / 10 wyjście”, zdecydowała, że sesje Thea potaniały z 5 700 do 1 550 dolarów.
Jak stosować: Przy wyborze modelu licz koszt całej pętli z uwzględnieniem trafień w cache i utrzymuj stabilny, powtarzalny prefiks promptów (system prompt, reguły projektu), żeby trafień było jak najwięcej.
Na co uważać: Nagłówki cenowe za milion tokenów sugerują znacznie mniejsze oszczędności, niż daje praktyka — porównuj koszt pełnych sesji, nie same stawki.
2.Duet zamiast jednego modelu: tani śledczy plus drogi wykonawca
Na czym polega: Theo zostawia Opusa 5.5 jako głównego wykonawcę, a 6.1 Soula konfiguruje jako recenzenta i śledczego (szukanie przyczyn błędów, triage, audyty). Opus ma móc sam go wywoływać.
Jak stosować: W narzędziach z konfigurowalnymi modelami (np. Claude Code) ustaw droższy model jako piszącego, a tańszy jako sprawdzającego; opinie recenzenta przekazuj wykonawcy do domknięcia przed merge’em.
Na co uważać: Tańszemu modelowi nie każ „lądować” własnego kodu — Theo wprost nie ufa mu przy committowaniu zmian, ufa dopiero po review.
3.Dopasuj model do typu pracy: zakres tak, maraton nie
Na czym polega: W zadaniach typu „znajdź, co nie tak, i powiedz prawdę” nowość jest top klasy frontier. W długiej pracy bez nadzoru wypada poniżej — trzyma się reguł procesu nawet wtedy, gdy całkiem blokują postęp, i nie prosi o pomoc.
Jak stosować: Tnij pracę na krótkie, dobrze określone zadania z jasnym kryterium ukończenia; długie przepisywania i maratony zostaw silniejszemu modelowi lub pilnuj ich osobiście.
Na co uważać: Pętla bez nadzoru potrafi spalić gigantyczną liczbę tokenów bez żadnego efektu — port TS→Rust stał w miejscu miesiącami mimo setek tysięcy dolarów wydanych na tokeny.
4.Benchmark bez ceny i czasu nie mówi prawie nic
Na czym polega: Na Deep SWE 6.1 Soul zremisował z Opusem 5.5 przy jednej dziesiątej czasu i jednej siedemdziesiątej ceny. Sam wynik liczbowy ukrywałby najważniejszą informację o tym wydaniu.
Jak stosować: Przy ocenie modeli zawsze dopisuj do wyniku koszt zadania i czas trwania; porównuj efektywność kosztową na własnych, powtarzalnych zadaniach.
Na co uważać: Własne uruchomienia benchmarków łatwo popsuć — Theo zepsuł dwa pierwsze biegi, część zadań trwa ponad osiem godzin, a niektóre wymagają sprzętu klasy H100.
5.Niezawodność ważniejsza niż szczytowe możliwości
Na czym polega: Astra była inteligentniejsza od modeli Anthropic, ale miewała nagłe zjazdy w „najgłębszą głupotę roku”. 6.1 Soul ma niższe szczyty, ale bez tych zjazdów — i właśnie dlatego nadaje się do odpowiedzialnych zadań (np. przygotowywania przelewów).
Jak stosować: Testuj kandydata na własnym repozytorium i codziennych czynnościach; odnotowuj katastrofalne wpadki, nie tylko sukcesy, bo to one dyskwalifikują model do pracy produkcyjnej.
Na co uważać: Jedno udane demo nie świadczy o stabilności — różnice ujawniają się dopiero po tygodniach codziennego użytkowania.
6.Oszczędność tokenów potrafi zniwelować różnicę w stawkach
Na czym polega: 6.1 Soul zrobił trzy rundy pracy za mniej więcej połowę kosztu jednej rundy Sonneta. Średnio czytał około 110 tys. tokenów na żądanie wobec 360 tys. u Sonnet 5 — mniej wywołań rozdmuchujących kontekst i mniej narastających śmieci.
Jak stosować: Mierz średnią liczbę tokenów na żądanie w swoich pętlach; model, który zarządza kontekstem oszczędniej, wychodzi taniej nawet przy podobnych stawkach.
Na co uważać: Przy dogłębnych audytach ten sam model potrafi spalić więcej tokenów niż konkurencja — rachunek zawsze zależy od rodzaju zadania.
7.Automatyczny routing między modelami może drogo kosztować
Na czym polega: Jev Router z OpenRouter kierował około 60% żądań do DeepSeeka 4.1 Flash, był droższy niż GPT-6 Astra na niskim poziomie i pięciokrotnie wolniejszy (104 kroki na zadanie wobec 19). Model, który sam nie potrafi rozumować, nie oceni trudności zadania bez kontekstu.
Jak stosować: Jeśli chcesz oszczędzać, rób routing ręcznie — na podstawie własnych statystyk, który typ zadań który model załatwia najtaniej.
Na co uważać: Obietnica „najniższego kosztu przy danym wyniku” to marketing; weryfikuj własnym, powtarzalnym testem przed wdrożeniem.
8.Budżetuj na realne ceny, nie na subsydiowane limity
Na czym polega: Plany za 200 dolarów pozwalały wyciągnąć 8–12 tys. dolarów użycia miesięcznie, a zmiana sposobu liczenia użycia w planie Pro netto obniża to do połowy. Theo odczytuje to jako sygnał kurczących się subsydiów.
Jak stosować: Model kosztowy firmy opieraj na cenach API i realnych rachunkach, a limity subskrypcyjne traktuj jako bonus, który może zniknąć.
Na co uważać: Limity różnią się per konto i trudno je precyzyjnie zmierzyć; warunki mogą się zmienić bez zapowiedzi — nie podpisuj długich zobowiązań w oparciu o nie.
9.Grafika tak, interfejs nie: gustu trzeba wnieść samemu
Na czym polega: W teście „fish slop” model wyprodukował najładniejszą oprawę graficzną w historii testu — opakowaną w najgorzej zaprojektowane, zasrane tekstem UI. To kolejna regresja w kwestii frontendów.
Jak stosować: Modelowi zostaw logikę, backend i grafikę 3D; przy interfejsach podawaj konkretny design system albo sam projektuj i traktuj model wyłącznie jako wykonawcę.
Na co uważać: Niski koszt wygenerowania nic nie mówi o jakości użytkowej — ruch i płynność rozgrywki były wyraźnie gorsze niż u konkurencji mimo ładniejszej oprawy.
10.Tanie, dobre 3D zmienia prototypowanie — zwłaszcza gier
Na czym polega: Model świetnie radzi sobie z Blenderem: z samego zrzutu ekranu odtwarza obiekt 3D przez wiersz poleceń. Pełna gra „fish slop” kosztowała 5 dolarów generacji; gdy dojdą szybsze tryby, twórczość na żądanie stanie się realna.
Jak stosować: Wykorzystuj do szybkiego prototypowania zasobów, wizualizacji i proof-of-conceptów, gdzie liczy się czas i koszt, nie poler.
Na co uważać: Mechanika i „feel” rozgrywki wciąż kuleją — pętli gry i optymalizacji wydajności nie oddawaj modelowi bez nadzoru.
Redakcyjne tłumaczenie
Wracamy do gry
Znowu się zaczęło. Szybkie przypomnienie: w zeszłym tygodniu Anthropic pokazał Opusa 5.5 i był niesamowicie dobry. Tak dobry, że OpenAI w pośpiechu wypuściło dwie nowości — GPT-6 Soul i GPT-6 Lunę. Może zauważyliście, że nie nagrałem o nich materiałów. Nie bez powodu: żadna nie zrobiła na mnie wrażenia i nie miałem zbyt wiele do powiedzenia. Był jednak jeszcze jeden byt, do którego dostałem przedpremierowy dostęp, a który właśnie stał się ogólnodostępny. Nazywa się GPT-6.1 Soul — i to przez niego tak trudno było nagrywać film o Sonnecie 5.5, bo wiedziałem, co nadchodzi: coś zaskakująco taniego, zaskakująco zdolnego i, co najzaskakujące, lepszego od Astry. Mam o tym sporo do powiedzenia.
Nagrywam o drugiej w nocy, tuż po materiałach o Sonnecie, więc wybaczcie potknięcia. Chcę to wydać, zanim zdąży się everything przefiltrować przez cudze opinie — dostajecie mój szczery osąd, a nie wersję przetartą przez wszystkich pozostałych. Jak zawsze przypominam: mam wczesny dostęp, ale nikt mi w żadnej formie nie płaci. OpenAI nie ma wpływu na to, co i jak mówię — wyłącznie na to, kiedy. Grzecznie poprosili, bym poczekał z opiną do premiery, co jest w pełni zrozumiałe.
Segment sponsora: Depot
Żeby budować dobre oprogramowanie z agentami, potrzebujesz informacji zwrotnej — a spora jej część, bądźmy szczerzy, pochodzi z CI. Stąd nasze rosnące rachunki i rosnąca frustracja z GitHub Actions. Sponsor tego odcinka, Depot, bierze na siebie obie te sprawy: CI do dziesięciu razy szybszy, buildy Dockera do czterdziestu razy szybsze (zwłaszcza przy pobieraniu cache), niższe ceny i lepszy feedback dla agentów. Wszystko dzięki własnej infrastrukturze bare metal z procesorami AMD EPYC, znacznie szybszej niż to, co dają tradycyjni dostawcy CI. Można go wstawić w miejsce GitHub Actions jeden do jednego, ale API jest na tyle lepsze, że warto z niego korzystać — daje równoległość i, co najważniejsze, odporność na nagłe, bez Powodu awarie GitHuba. Gdy Ben przenosił Pick Thing na Buna, od razu wysypały się buildy — normalnie byłyby to nieczytelne sterty tekstu, które agenci muszą rozgrzebywać, a Depot analizuje błędy i podpowiada rozwiązania. Agent z dostępem do CLI nie musi już pchać zepsutego kodu i czekać na build, żeby dostać feedback — odpala narzędzie i dostaje ten sam wynik. Dostajecie też rozkład, co właściwie zwalnia wasze runsy. Szybszy Docker, szybsze buildy, szybsze CI, niższy rachunek — wszystko pod linkiem w opisie.
Liczby, które robią wrażenie
Porozmawiajmy o tym modelu, bo nie jest do końca tym, czego się spodziewałem — i pewnie też nie tym, czego wy się spodziewaliście, zwłaszcza że GPT-6 Soul wyszedł dosłownie tydzień temu. Dystans między „6.0” a „6.1” to dokładnie jeden tydzień.
Zastrzeżenie: liczby, które pokazuję na ekranie, raczej nie są w stu procentach dokładne. Terminal Bench odpalam sam — dwa pierwsze biegi popsułem, trzeci idzie znacznie lepiej. Poziomu medium nie uruchomiłem wcale, a max jest niekompletny, więc tam, gdzie max się pomylił lub jeszcze nie skończył, uzupełniam wyniki z x-high; niektóre zadania trwają ponad osiem godzin. Ten benchmark jest szalony. Szczerze: im więcej takich rzeczy odpalam sam, tym bardziej jestem sceptyczny wobec benchmarków w ogóle.
Mimo to wyniki robią wrażenie. Na Terminal Bench 4 mamy wynik stanu sztuki; Deep SWE też, choć tu jest dziwniej — wynik spada na poziomach x-high i max, a na low i high jest płasko, przy czym owe wyniki z low odpowiadają mniej więcej temu, co Astra osiągała na high. Różnica? Ta nowość robi to za śmiesznie mniejsze pieniądze. Na skali logarytmicznej widać to od razu: 21 centów na poziomie low wobec 1,46 dolara u Astry na low — a Opus 5.5 na maxie wyciągnął ten sam wynik za 14,65 dolara. Deep SWE daleko odbiega od idealnego testu codziennej pracy z kodem, ale fakt, że nowy model punktuje jak Opus i przy tym jest 73 razy tańszy, przynajmniej zasługuje na uwagę.
I wciąż nie mówi to nic o prawdziwej pracy z kodem, więc do tego wrócimy. Najpierw koszty w samym benchmarku, bo te już mówią dużo: najdroższy bieg 6.1 Soula kosztował mnie około 1,38 dolara za zadanie, najtańszy bieg Opusa 5.5 — 5,12 dolara. Cztery do pięciu razy różnicy między najtańszym Opusem a najdroższym Soulem. Zakładam, że w tym momencie modlicie się, żeby ten model był naprawdę dobry i mógł zastąpić Opusa w codziennej robocie. Obiecuję, że odpowiedź na to nadejdzie — ale najpierw musimy porozmawiać o zachowaniu.
„6.1” prawdopodobnie nie miało być „6.1”
Teraz powiem rzeczy, których pewnie mówić nie powinienem. GPT-6 Soul miał premierę w zeszły wtorek, 6.1 Soul — w ten. Rozsądny wniosek: 6.1 Soul w ogóle nie było planowane jako „kropka jeden”. Jestem tu na cienkim lodzie, więc potraktujcie to też jako dowód, że OpenAI mnie nie opłaca.
Po pierwsze: 6.1 jest wyraźnie sprytniejszy od GPT-6 Soul — a to wyklucza zwykły, inkrementalny „plus 0.1”. Dzieje się tu coś zasadniczo innego. Po drugie: ma zauważalnie wolniejsze tokeny na sekundę, co zwykle wskazuje na większy model. Trudno powiedzieć na pewno, ale wygląda na to, że to co innego. Po trzecie, najważniejsze: tweet Tibo.
(Informacja dodatkowa: Tibo to znany w branży analityk śledzący na bieżąco cenniki i limity OpenAI.)
Tuż przed nagraniem wrzucił długi wpis. Najpierw dobra wiadomość: wraca subskrypcja Pro za 200 dolarów. Ale kluczowe jest inne zdanie — zmienia się sposób liczenia użycia w planie, co w przeliczeniu wychodzi do połowy wydatków w porównaniu do starego planu Pro za 200. Po co robić coś takiego właśnie teraz, gdy — jeśli wierzyć plotkom — w firmie trwa wewnętrzny „code red”, bo Opus 5.5 jest tak dobry i uczynił plan Claude Code za 200 dolarów niewiarygodną okazją? Jedyne sensowne wytłumaczenie: nadchodzi model, na którym marże są gorsze, więc zdolność do subsydiowania spada. Przypomnijmy skalę: na planie Claude Code da się wyciągnąć 8–9 tysięcy dolarów użycia miesięcznie, na planie Codex ponad dwanaście. Po premierze Astry, według moich rachunków, realnie wyszło bliżej ośmiu tysięcy — trudno to zmierzyć precyzyjnie, bo każdy ma inne limity, ale rząd wielkości jest właśnie taki.
Cennik, który zmienia zasady gry
I tu wchodzi cena tego modelu: 2 dolary za milion tokenów wejściowych, 10 za milion wyjściowych. To znacznie taniej niż 5.6 Soul na premierze, połowa ceny 5.6 Soula po rabatach, dokładnie tyle, co GPT-6 Soul — i jedna piąta ceny Astry. Ale to nie jest cała historia, bo kluczowe są odczyty z cache (tzw. cache read, czyli ponowne czytanie tych samych, zbuforowanych fragmentów kontekstu — chleb powszedni pętli agentowych). I tu model wyceniono na 10 centów za milion.
To duża sprawa. O ile wiem, OpenAI nigdy wcześniej nie zmieniało ceny odczytu z cache — zawsze wynosiła dokładnie 10% zwykłej stawki, czyli zniżka 90%. Teraz jest 95%. Przecięli ten koszt dokładnie na pół, co miażdży wydatki w realnej pracy agentowej — czyli w tym, do czego te modele używamy najczęściej. Nowość jest przez to absurdalnie tania w praktycznej pracy z kodem, co niemal na pewno oznacza cięcie we własnych marżach. Plotki przypisują im historycznie marże rzędu 95% — z każdej wydaje 50 centów. Brzmi szaleńczo, ale ma sens, gdy się pomyśli, ile kosztuje wytrenowanie tych rzeczy. Taka marża dawała im pole manewru — i właśnie z niego teraz korzystają. Bo gdyby subsydiowali subskrypcje na dotychczasowym poziomie, koszt mocy obliczeniowej przekroczyłby to, co płacimy abonamentem. Rozumiem więc, że musieli coś zmienić. Szczegów nie podali — zostawili nam je do samodzielnej rekonstrukcji, więc interpretujcie, jak chcecie. Sama szybkość premiery wskazuje, że to nie jest zwykły nowy snapshot GPT-6.
Koniec z huśtawką?
Porozmawiajmy o zachowaniu, bo model należy do rodziny GPT-6, a ta ma swoje smaczki. Rzecz, która doprowadzała mnie do białej gorączki w Astrze, to nie brak inteligencji — Astra była inteligentniejsza od najlepszych modeli Anthropic i, jak bym argumentował, w wielu wymiarach nadal jest. Problem w tym, że była zarazem głupia. Inteligentna i głupia równocześnie. GPT-6 Astra potrafiła bez powodu runąć w najgłupsze zachowanie, jakie widziałem w tym roku u dużego modelu — gorsze niż niektóre małe modele open-weight, z którymi się bawię. I to frustruje podwójnie, bo gdy działała, była niewiarygodna. Te zjazdy doprowadziły do tego, że w praktyce z niej zrezygnowałem: subskrypcje Codex zostawiłem tylko do sterowania komputerem, a całą codzienną robotę przerzuciłem na Fable 5.1, a potem oczywiście na Opusa 5.5.
Czy 6.1 Soul naprawił to, co mnie tak denerwowało? Powiedziałbym, że w większości. Nie w całości, ale w dużej mierze tak — to znacznie lepszy model. Jego szczyty nie sięgają tak wysoko: nie ma rewolucyjnych możliwości 3D, które pokazała Astra; w większości takich rzeczy postawiłbym go odrobinę poniżej Opusa 5.5. W sterowaniu komputerem też nie jest tak dobry jak Astra — ale na tyle blisko, że chętnie używam go do całej codziennej roboty. Kazałem mu przejrzeć całą moją skrzynkę i wyłapać faktury, o których zapomniałem albo zalegałem — głównie rzeczy inwestycyjne. Założył osobną kartę w Chromie dla każdej inwestycji wymagającej przelewu, wypełnił wszystkie dane i zostawił mi tylko kliknięcie „wyślij”. Nie pomylił się ani razu i wyłapał dodatkowe rzeczy, które na pewno bym przeoczył. Czyli realnie ufam mu przy przelewaniu pieniędzy. Astrze — przez tę huśtawkę — pewnie bym nie zaufał. Pozostali testerzy są podobnego zdania: Julius i Ben przeszli na 6.1 Soulu znacznie lepiej niż na Astrze. Julius nazwał go „niesamowitym”. Ben — „niesamowicie nudnym”. I myślę, że to najlepsze miejsce, w którym model może się znaleźć przy takiej premierze.
Są jednak zadania na samym skraju jego możliwości, przy których zaczyna wariować. Większość czasu jest w porządku, ale po Opusa wciąż sięgam sporo — o porównaniu jeszcze porozmawiamy.
Rottweiler do audytów kodu
Domyślam się, że czekacie na ocenę prawdziwej pracy z kodem — ale najpierw sterowanie komputerem, bo to mój domyślny use case dla tego modelu. Nie mogę się doczekać, aż Ultra Fast będzie realnie dostępny dla modeli OpenAI, bo ten model na nim oszaleje: już teraz radzi sobie z nawigacją po komputerze zupełnie nieźle, a jeśli nagle zrobi to sześć razy szybciej, będzie niewiarygodnie fajnie. Nadal nieco gorzej niż Astra — ale różnica w cenie jest na tyle duża, że nie muszę się nawet zastanawiać.
Druga rzecz, do której chętnie sięgam po tego Soula zamiast po Astrę: głębokie przeglądy kodu. Modele OpenAI mają naturę rottweilera — wczepią się w problem i trzęsą nim, aż wyleci z niego wszystko, co złe. W 6.1 Soulu jest to niesamowicie silne. Kazałem mu więc przeprowadzić głębokie audyty Orchestratora V2 i innych fragmentów moich prawdziwych kodów. W audycie Orchestratora V2 wypadł niemal identycznie z Astrą — w drugiej analizie minimalnie wyżej — ale za około połowę ceny: 297 wobec 584 dolarów. Sonnet wyszedł jeszcze taniej, Opus nieco taniej, ale żaden z nich nie analizował nigdzie tak dogłębnie. Soul dopychał w głąb, żeby znaleźć problemy, i właśnie dzięki temu dorównał Astrze — choć, przyznaję, spalił przy tym znacznie więcej tokenów.
Inne zadanie, na którym dobrze się bawiłem: znajdowanie okazji do ulepszenia bazy kodu, konkretnie kodu D3. To ten test, w którym Grok 4.7 wypadł podejrzanie dobrze — 80,7 wobec 83,8 u Astry. A GPT-6.1 Soul poszybował: 87,4. Cen nie wszystkich biegów zachowałem, ale Opus 5.5 kosztował pięć dolarów, Sonnet 5.5 prawie dziewięć — a Soul 2,15. Stawka za token jest niższa niż u Sonneta, a jednocześnie model zachowuje openai-owską oszczędność w ich zużyciu. Efekt: szalony stosunek ceny do możliwości.
Opus ocenia model w ciemno
Ten wątek bawił mnie najbardziej. Kazałem Opusowi 5.5 zrecenzować prace tego modelu pod zmienioną nazwą, żeby nie wiedział, co ocenia (historię rozmowy podredagowałem potem). Szybko uznał, że to model klasy frontier. Jego recenzje i reprodukcje błędów trafIAły w fixy, które później weszły do repozytorium; pierwsze szkice kodu miały realne bugi, które wyłapały boty review’owe; lokalny zespół do przeglądu kodu potwierdził klasę frontier. W ślepym teście dziesięciu modeli na tym samym poleceniu 6.1 Soul zajął pierwsze miejsce z wynikiem 87,4 — jakość odrobinę poniżej Astry, Opusa 5.5 i Sonneta 5.5, co zaraz pokażę na przykładzie fish slopa. Ale spójrzcie na cenę: siedem dolarów wobec piętnastu u Sonneta i pięćdziesięciu u Opusa.
Szczery werdykt Opusa brzmiał tak: „incredible for scoped work, top of the frontier” — niesamowity w zadaniach o jasno zakreślonym zakresie, czołka klasy frontier. „Znajdź, co nie tak, i powiedz prawdę — wybrałbym go ponad Astrę, mniej więcej na poziomie Opusa”. I: „długa praca bez nadzoru — poniżej frontier: trzyma się reguł procesu nawet wtedy, gdy całkowicie blokują postęp, i nie prosi o pomoc”.
To ostatnie sam mocno odczułem. Pisałem już kilka razy, że port TypeScripta na Rusta idzie mi z Opusem 5.5 znacznie lepiej niż szedł wcześniej z Astrą i Soulem. Z tym modelem port działał przez dłuższy czas i nie ruszył z miejsca — spalił kupę tokenów, nie poprawiając kompilatora ani o jotę. Opus wznowił pracę od zera i doprowadził ją do działania w jedną dobę — po tym, jak spędziłem na niej miesiące i setki tysięcy dolarów w tokenach z tym modelem, Astrą i 5.6 Soulem. Opus zrobił to za jakieś tysiąc dolarów, w jedną noc, na dwóch subskrypcjach Claude. Przy długim, bezobsługowym przepisywaniu Anthropic jest dziś po prostu śmiesznie przed wszystkimi.
Przy zarządzaniu moją flotą — czyli wszystkim komputerom, na których odpalam agentów, bo jednego MacBooka daleko nie wystarcza — też zdarzało mu się strzelić głupotę. W是其 fairnessie Opus też. Astra jako jedyna nie robiła ich zbyt wielu, ale powiem szczerze: po tym modelu całkowicie kończę z Astrą.
Wróćmy do wątku z Opusem, bo jest zabawniejszy. Po całym tym review zapytałem go, ile jego zdaniem ten model powinien kosztować. Strzelił: 5 dolarów za milion wejścia, 50 centów z cache, 30 za wyjście — czyli mniej więcej ceny Opusa. Uzasadnił to tym, że model pracuje jak Opus, jest szybki (za co należy się premia), a nie jest „modelem pro” z taryfami rzędu setki dolarów za wyjście — choć modele „pro” już właściwie nie istnieją, jeździmy dziś na Fable i Astrze, ale rozumiecie, o co chodzi. A potem przyszła perełka: „Gdyby OpenAI chciało, żeby ludzie go przyjęli, ustaliłbym 3 dolary za milion wejścia, 30 centów cache i 20 za wyjście. To wciąż uczciwa cena za to, co robi”. Odpowiedziałem: a gdybym ci powiedział, że jest 2 i 10, a cache po 10 centów? — „Nazwałbym to bardzo agresywną ceną”. Przy tym, jak go używam, koszt to około ćwierci tego, co zgadł. Całą robotę odwalają stawki z cache: obciążenia agentowe to w 96% odczyty z cache, więc 10 centów znaczy więcej niż nagłówki „2 i 10”. Po przejrzeniu wszystkich moich sesji Opus pierwotnie wyceniłby je na 5 700 dolarów — po nowych cenach przeliczył na 1 550. To potężny spadek. A zadania typu przegląd PR-ów, które szacował do 10 dolarów, realnie kosztują do 3 — i to przy ciężkich zmianach liczących dziesiątki tysięcy linii.
Wnioski Opusa (winny Opus, nie ja — narzekajcie do niego): po pierwsze, ten model staje się domyślnym wyborem do zadań zakresowych. Po drugie, przerośnięte systemowe prompty przestają mieć znaczenie — przy takiej cenie cache to szum. Po trzecie, długie pętle wciąż są złym pomysłem, ale nie przez pieniądze: port TS→Rust przepalił cztery dni bez żadnego postępu. I po czwarte — Opus podejrzewa, że ta cena nie potrwa i wzrośnie. Nie jestem w stanie wyobrazić sobie, by OpenAI kiedykolwiek podniosło cenę modelu, ale to, że Opus tak myśli, jest zabawne i pokazuje dobitnie, jaki to dobry interes.
Jeszcze o oszczędności: GPT-6.1 Soul zrobił trzy rundy pracy za mniej więcej połowę kosztu jednej rundy Sonneta. Dużo przez to, jak zarządza kontekstem — jest po prostu znacznie wydajniejszy, więc robi mniej wywołań, które rozdmuchują kontekst, i generuje mniej tokenów narastających z czasem. Średnia liczba czytanych tokenów na żądanie wyszła około 110 tysięcy wobec 360 tysięcy u Sonneta 5. W rezultacie zużył mniej niż połowę tokenów wejściowych konkurenta.
Jev Router, czyli dlaczego automatyczny routing nie działa
Chcę jeszcze chwilę pogadać o Deep SWE, bo dołączyłem go do testów z innego powodu — nie dla porównania z 6.1 Soulem, tylko z nowością OpenRoutera: Jev Routerem. OpenRouter dodał go, żeby optymalizować koszty zapytań, i od razu uznałem to za bardzo głupi pomysł. Benchmarki potwierdziły: bardzo głupi pomysł. Okazuje się, że model, który nie potrafi rozumować i dostaje polecenie bez kontekstu, nie jest w stanie dobrze ocenić, jak trudne jest zadanie. Jev Router w zdecydowanej większości biegów okazał się po prostu DeepSeekiem 4.1 Flash — około 60% wszystkich żądań poleciało prosto do tego modelu. Teoretycznie kierował też do sprytniejszych, co powinno mu pomagać, ale wyszło drożej niż GPT-6 Astra na poziomie low i cztery–pięć razy wolniej: Astra low robiła zadanie w 4,6 minuty, Jev Router w 20; 104 kroki na zadanie wobec 19. Cała obietnica z etykiety brzmiała „tak tanio, jak się da, przy danym wyniku” — czy wierzycie w nią, to już wasza sprawa, nie moja. Fakt pozostaje faktem: mimo że Jev Router wybierał najtańsze małe modele open weight od wszystkich, którzy oddają je za darmo, 6.1 Soul na poziomie low uzyskał ten sam wynik za jedną ósmą ceny. OpenAI przyszło tu po prostu odebrać każdemu wszelkie przewagi w efektywności. Ukończenie tego benchmarka w 4,8 minuty za 21 centów, z drugim najwyższym wynikiem, jaki na nim widziałem — remis z Opusem 5.5, który na maksie brał 50 minut na zadanie. Dziesiąta część czasu, siedemdziesiąta część ceny, ten sam wynik.
Jeśli wasza praca mieści się w tym, co 6.1 Soul robi dobrze — prawdopodobnie używajcie go do wszystkiego. Jeśli nie — zostańcie przy Opusie, a najlepiej dajcie Opusowi możliwość samodzielnego wołania 6.1 Soula do konkretnych zadań. Ja niemal na pewno tak to ustawię: Opus 5.5 będzie delegował do Soula śledztwa w kodzie — szukanie przyczyn źródłowych błędów, analizę baz kodu pod kątem „co trzeba ruszyć i dlaczego” — pomoc w triage’owaniu realnej roboty i review własnej pracy. Zdradzam zakończenie, prawda? Przy Opusie zostaję. Ale zanim wyjaśnię dlaczego — czas na rzecz, na którą czekam najbardziej.
Fish slop, czyli piękno i koszmar
(Informacja dodatkowa: „fish slop” to autorski, powtarzalny test Theo — prośba do modelu o napisanie gry akwarium; „slop” to jego określenie na bezwartościowe wypluwiny modeli, tu dodane do samej nazwy.)
Pierwsze, co zauważycie, to „slop” w nazwie. Ten model zrobił okropną rzecz, której nienawidzę: opakował grę w stertę absolutnie śmieciowego UI. I po demku Sonneta 5.5 boli to podwójnie — Sonnet nie narysował grafiki nigdzie tak ładnej, ale przynajmniej interfejs miał niezłomnie lepszy. I gdyby na tym się kończyło… Włączam dźwięk. O Boże, ryczy. Ale wygląda to oszałamiająco. Ryby to jedne z najlepszych, jakie były. Model okrętu dużo lepszy. Śruby działają znacznie lepiej. Wyciszam, bo to brzmi coraz gorzej. Kurczę, wygląda pięknie. Ale gdy się w to gra, jedną z pierwszych rzeczy, które czujecie, jest ruch — wyraźnie gorszy niż w wersjach Opusa i Sonneta, które pokazywałem. Porusza się szarpano. Klatkuje też wyraźnie częściej, choć ma wyższą wierność graficzną, więc to logiczne — modele roślin są znacznie lepsze niż u Sonneta. Detale dodatków w zbiorniku są absolutnie zabawne.
Ale mój Boże, jak ja jestem zmęczony zbędnym tekstem wszędzie. Ten model robi to gorzej niż niemal każdy, jakiego widziałem. „Take a breather”. „Paused”. „Your little world can wait”. „Back to the reef”. „Start a new tank”. „Slot 01”. „Feeder submarine”. „A little underwater chaos”. „The big little goal”. „Your little ecosystem”. „Little fish become big earners”. „Four meals and they’re all grown up”. „Make the family a little bigger”. „A little golden overachiever”. Jest tego ponad dwadzieścia. Obiecuję: ledwo to zobaczyłem, zrobiłem screenshot, wysłałem do OpenAI i urwałem się na Slacku, bo nie jestem w stanie pojąć, jak mogli tego nie naprawić. Ten model jest nieakceptowalnie fatalny w UI — kolejna regresja. Jeśli szukacie modelu, który zrobi frontend nie ssący — idźcie wydawać pieniądze gdzie indziej. Ten model nie umie frontendu. Nie umie designu. Nie ma smaku. Gust musicie wnieść sami.
Za to, przyznaję, jest naprawdę dobry w Blenderze. Dajcie mu screenshot rzeczy, którą chcecie odtworzyć w 3D, i powiedzcie: „masz Blendera przez wiersz poleceń, do dzieła” — zrobi. I zrobi to porządnie. Ale mechaniki swoich gier nigdy bym mu nie oddał, bo gra się źle czuje, a pętla rozgrywki jest znacznie uboższa. Przy pierwszej próbie demo przed nagraniem dostałem po prostu „game over” w pierwszych trzydziestu sekundach, nikomu nie mówiąc dlaczego. Chociaż — technicznie chyba wygrałem. Mam ochotę wziąć tę wersję, oddać ją Opusowi albo Sonnetowi i powiedzieć: „grafika jest dobra, ale zróbcie z tego grę, którą chce się grać”.
A teraz policzmy: ta cała gra kosztowała, zdaje się, pięć dolarów generacji. To już samo w sobie szalone. A jeśli dołożyć do tego Ultra Fast — o ile kiedyś nadejdzie — nagle będziecie w stanie zrobić grę na żądanie w kilka minut. Właśnie przekraczamy próg, za którym rozwój gier stanie na głowie: modele w końcu rozumieją przestrzeń trójwymiarową i potrafią obsługiwać narzędzia potrzebne do takich rzeczy. To się dzieje.
Prawdziwa praca: model jako recenzent
Jak zwykle w oknie testowym nie mogłem wrzucać kodu napisanego tym modelem do T3 Code ani innych projektów open source. Musiałem więc używać go wyłącznie na projektach wewnętrznych, jak Lakebed, oraz do audytowania innej pracy — co w praktyce oznacza, że głównie nim audytowałem. I jestem bardzo pozytywnie zaskoczony.
Miałem realny PR naprawiający buga: nowe okno konfiguracji worktree, pojawiające się w nowym wątku T3 Code, znikało, jeśli się wyszło i wróciło. Claude Code nad tym pracował, ale problem sięgał głęboko — chciałem więc, żeby rozwiązanie było bardzo, bardzo dobrze sprawdzone. Sam wciąż nie ufam temu modelowi przy pisaniu kodu, który mam wmergować — ale do recenzowania ufam mu całkowicie. (Napis „GPT-6 Soul” na ekranie to tylko placeholder, ignorujcie.) Gdy kazałem 6.1 Soulowi przejrzeć ten PR, znalazł realne problemy, które kompletnie umknęły Fable i Opusowi. Po pierwsze: wiadomości follow-up potrafią pozostać zablokowane po starcie agenta — bardzo denerwujące, gdy chce się zakolejkować polecenie. Po drugie: odzyskiwany postęp konfiguracji znikał zbyt wcześnie. Wszystko to wywnioskował łącząc czytanie kodu z analizą i sterowanie komputerem. Uchronił mnie przed wmergowaniem realnej regresji do T3 Code. Po prostu wkleiłem te uwagi Claude’owi i kazałem spojrzeć jeszcze raz. Odpowiedź: „Lepiej, ale domknę jeszcze dwie małe dziury”. Pamiętacie — nie mogłem wtedy używać tego modelu do pisania kodu w tym projekcie — więc znowu wkleiłem odpowiedź do Claude’a, i tak w kółko, aż w końcu wyszło wystarczająco dobrze i wmergowałem. Właśnie do tego polubiłem tego Soula i nie mogę się doczekać, żeby przepchnąć jego granice w faktycznym kodowaniu. Choć, powiem szczerze, z kodu, który miałem nieszczęście czytać: jego zmiany trudniej uzasadnić przed merge’em niż zmiany Opusa.
Port TS→Rust i 1,3 miliona martwych linii
Zwykle kazałbym wam czekać na film „Opus versus Soul”, ale zdradzę szczegóły od razu. Lubię ich używać w parze: Soul jest znacznie lepszy w recenzowaniu i grzebaniu w szczegółach, a Opus jest przyjemniejszym współpracownikiem i znacznie lepszy w faktycznym wdrażaniu kodu — bez ciągłego blokowania się po drodze. I dokładnie ten sam wzorzec widzę teraz przy przepisywaniu TypeScripta na Rusta: Opus 5.5 pcha i pcha, doprowadzając bazę do działania, a potem Soul wchodzi i robi audyt.
I teraz najlepsza część. Pamiętacie — mówiłem, że nad tym portem z Astrą i Soulami pracowałem efektywnie miesiącami? Opus wszedł od nowa i wzniósł go z 83,7% do 100% w mniej niż dobę. Byłem zalany — somehow odblokował to, na czym utknęły Astra i Soule, w tym 6.1 Soul; wziął dorobek 5.6 Soula, 6.1 Soula i Astry z całych miesięcy, ruszył dalej tam, gdzie stało w miejscu od tygodni, i skończył. Ale jeszcze bardziej zaskoczył mnie audyt: kazałem 6.1 Soulowi obejrzeć tę pracę i ją skrytykować. I to, co wyłonił, brzmiało tak: z 1,8 miliona linii kodu — 1,3 miliona było nieużywanych. Powód? Opus uznał, że cały kod pozostałych agentów to bezwartościowe śmieci bez szans na ratunek, i po cichu przepisał wszystko od zera w osobnym crate’ie. Z jednej strony: jedynym powodem, dla którego kod działa, był Opus. Z drugiej: jedynym powodem, dla którego śmieci wciąż leżały w repo, był też Opus. Musiałem wprowadzić tego Soula, żeby posprzątał bałagan po innych modelach OpenAI — bo Opus nawet nie zauważył, że bałagan wciąż tam jest.
Chcę przez to powiedzieć: ten model zdecydowanie ma swoje miejsce w waszych workflow. Mógłby nawet być waszym domyślnym modelem do kodu i nie mielibyście z nim większych problemów — ale Opus pozostaje dla mnie lepszym współpracownikiem. Z drugiej strony nie mam już prawie żadnego powodu sięgać po Sonneta, bo 6.1 Soul skutecznie zajmie jego miejsce. Iბуда się założycie: w momencie premiery idę prostować konfigurację Claude’a, bo już mam ustawione, żeby Soul działał wewnątrz Claude Code — chcę, żeby Opus wiedział, że to jest model, który ma recenzować jego pracę i badać, co się dzieje w bazie kodu.
Werdykt o trzeciej nad ranem
To jest cholernie dobry model i naprawdę cieszę się, że go mam. Chciałbym czegoś większego, sprytniejszego, bardziej wszechstronnego. Liczyłem na coś, co realnie zdetronizuje Opusa 5.5 w codziennej pracy. To nie to — w związku z tą premierą nie planuję anulować żadnej subskrypcji Claude, ale planuję wciągnąć znacznie więcej subskrypcji Codex do codziennej roboty. I, szczerze mówiąc, właśnie w Claude Code. Świetne wydanie i niewiarygodna cena za to, co dostajecie — ale być może oznacza też początek końca ery subsydiowania. Zapiszcie się na kanał, żeby być na miejscu, gdy będę to wszystko omawiał.
Boże, mam nadzieję, że mnie za to nie zje internet. Poza garstką testerów z wczesnym dostępem nie wiem, co myślą inni. Szczerze nie wiem, czy to pokochacie, znienawidzycie, czy wylądujecie gdzieś pośrodku. Dowiem się za kilka godzin — jest trzecia nad ranem. Idę spać. To był męczący odcinek. Mam nadzieję, że dałem radę — dajcie znać w komentarzach. Do następnego razu: pa, nerdzi.