Meta właśnie dogoniła Anthropic

O czym jest ten film

Meta wypuściła Muse Wonder i większy Muse Wonder Full — według Theo to pierwszy model spoza OpenAI i Anthropic, który realnie gra w czołówce (poziom Fable i Astry).
Pełna wersja na Artificial Analysis minęła wszystkie modele OpenAI, co stawia Metę na trzecim miejscu ogólnego rankingu.
Największe zastrzeżenia: brak ceny dla najlepszej wersji (dostępnej tylko w subskrypcji Muse Code), żenujące nazewnictwo, słaba grafika 3D i fatalne projektowanie interfejsów.
Model trenowano z naciskiem na pamięć i delegowanie — znakomicie pisze prompty do podagentów i sprawdza się w roli „dowódcy” zespołu modeli.
W realnych zadaniach (audyty kodu, recenzje PR-ów) Muse Wonder Full wypada blisko Opusa 5.5 i Astry, ale pracuje około dwukrotnie szybciej i zużywa mniej tokenów.
Mniejszy Muse Wonder, dostępny przez API, wyraźnie odstaje — w audytach ponad 30% słabiej niż wersja pełna; wiele krytycznych opinii w sieci dotyczy właśnie tego wariantu.
Model rzadko popełnia rażące błędy — wg Theo ma najniższą „podłogę głupoty” ze wszystkich modeli, z jakimi pracował.
W teście z prawdziwym bugiem Muse jako jedyny klarownie wyjaśnił przyczynę i znalazł już istniejący, jednolinijkowy PR z naprawą.
Theo radzi nie porzucać subskrypcji Claude Code na rzecz Muse — ceny i limity pozostają nieznane, więc nie ma podstaw do przesiadki.
Wejście trzeciego gracza do czołówki zapowiada ostrzejszą konkurencję, a ta historycznie taniała ceny i podnosiła jakość u liderów; na koniec złośliwy komentarz o wciąż niepublikowanym Gemini 4 Argon.

10 najważniejszych takeaways — z kontekstem zastosowania

1.Dwa modele, jedna nazwa — najpierw ustal, o którym mowa

Na czym polega: Meta wydała Muse Wonder (API, tańszy, wyraźnie słabszy — ponad 30% gorsze wyniki w audytach Theo) oraz Muse Wonder Full (tylko w subskrypcji, model z czołówki). Sporo krytyki w sieci dotyczy słabszego wariantu.

Jak stosować: Przed oceną modelu zweryfikuj wariant i kanał dostępu (API czy subskrypcja). Jeśli testujesz przez API, pamiętaj, że nie testujesz wersji, która zbiera dobre wyniki w benchmarkach.

Na co uważać: Wynikiów z jednej wersji nie przenoś na drugą. Porównania cenowe są na razie niemożliwe, bo cenę pełnej wersji po prostu pominięto w komunikacie.

2.Brak publicznej ceny to sygnał ostrzegawczy

Na czym polega: Najlepszy wariant nie ma ceny w ogóle; znany jest tylko cennik słabszej wersji (4 dolary za milion tokenów wejściowych, 20 za wyjściowe, 20 centów za cache), czyli niemal tyle, co Opus.

Jak stosować: Przy niejawnych cenach licz koszt na własnych zadaniach (tokeny razy czas) i dopiero potem wiąż się subskrypcją. Od dostawców żądaj jawnych cenników — bez nich nie zbudujesz uzasadnionego budżetu.

Na co uważać: Cena mniejszego modelu bliska Opusowi sugeruje, że pełny będzie droższy — może droższy niż Opus 5.5, co według Theo nie ma sensu ekonomicznego.

3.Umiejętności 3D i obsługa komputera są trenowane osobno, nie „wyłaniają się” z inteligencji

Na czym polega: Nagły skok zdolności 3D u wielu modeli pochodzi z podobnych, kupowanych na zewnątrz środowisk treningowych (pierwszy sygnał: Kimi K3), a nie z ogólnego wzrostu mądrości modeli.

Jak stosować: Wybierając model do zadań graficznych lub UI, patrz na testy dedykowane tym zadaniom, a nie na ogólne rankingi. Do UI i 3D wciąż najbezpieczniejszy jest ekosystem Claude.

Na co uważać: Model ogólnie znakomity może rysować fatalne interfejsy (jak Muse) — pojedyncze słabe zadanie nie mówi nic o inteligencji modelu i odwrotnie.

4.Niska „głupota” bywa cenniejsza niż wyższy pułap możliwości

Na czym polega: Theo rozdziela mądrość (pułap) od głupoty (podłogę — destrukcyjne wpadki). Muse ma pułap 8–9/10, ale głupotę 1–2/10, najniższą ze wszystkich modeli, z jakimi pracował.

Jak stosować: Przy długich, słabo nadzorowanych automatyzacjach wybieraj model o wysokiej podłodze; kluczowe decyzje projektowe zlecaj „mądrzejszemu” modelowi w roli recenzenta.

Na co uważać: Wysoka podłoga nie zastąpi mądrości tam, gdzie błędny projekt dużo kosztuje — tam nadal sięgaj po najsilniejszy dostępny model.

5.Orkiestracja i delegowanie to realna przewaga — użyj modelu jako „dowódcy”

Na czym polega: Muse pisze znakomite prompty do podagentów (jasny zakres, wymóg czytania implementacji, zakaz cytowania nieotwartych plików, zakaz edycji) i sprawnie kieruje innymi modelami, także przy dużej liczbie równoległych zadań.

Jak stosować: W narzędziach orkiestrujących agentów ustaw model o najlepszych kompetencjach delegacyjnych jako nadrzędny; każe mu dzielić zadania między tańsze modele i weryfikować ich pracę.

Na co uważać: To zdolność rzadka poza dwoma czołowymi laboratoriami — nie zakładaj jej u każdego modelu z wysokiego miejsca w rankingu.

6.Duet „szybki wykonawca + mądry arbiter” wygrywa z pojedynczym modelem

Na czym polega: W projekcie Lust praca została rozdzielona: Muse bierze większość (poprawki, biblioteka standardowa, fuzzing, recenzje), Opus — krytyczne decyzje projektowe; każdy recenzuje drugiego, a w konfrontacji planów często podstawą zostaje propozycja Muse.

Jak stosować: Jeśli twoje narzędzie obsługuje wiele modeli, przypisz rolę wykonawcy modelowi szybszemu i tańszemu, a arbitra — najmądrzejszemu; wymuszaj wzajemne recenzje i zamianę recenzji na poprawki.

Na co uważać: Modele w roli sędziów nie są bezstronne — potrafią oceniać własny wkład zbyt surowo lub zbyt łaskawie, więc ostateczna ocena powinna należeć do człowieka.

7.Mierz czas i tokeny, nie tylko poprawność

Na czym polega: Muse Wonder Full osiąga wyniki zbliżone do Opusa i Fable przy mniej więcej połowie czasu (ok. 17 minut wobec 30+ u Opusa) i mniejszym zużyciu tokenów (ok. 54 tys. na zadanie).

Jak stosować: Przy masowych zadaniach — audytach dużych baz, seriach recenzji — licz pełny koszt: czas, tokeny, stawka. Szybszy model bywa tańszy w całym cyklu mimo przeciętniejszego pojedynczego wyniku.

Na co uważać: Bez publicznej ceny pełnej wersji rachunek kosztowy jest niepełny — porównuj tokeny i czas, a cennik zweryfikuj po jego publikacji.

8.Czytelność raportu to przewaga w codziennej pracy

Na czym polega: W teście z realnym bugiem Muse jako jedyny jasno opisał przyczynę (dwa zbędne nagłówki w jednym żądaniu) i — co ważniejsze — znalazł już istniejący, jednolinijkowy PR naprawiający problem, którego żaden inny model nie wykrył.

Jak stosować: Do zadań typu „zbadaj i wyjaśnij” (bug reporty, audyty, priorytetyzacja) wybieraj model, którego odpowiedzi da się czytać bez przekopywania się przez tony tekstu. Wymogi co do stylu zapisuj w AGENTS.md.

Na co uważać: Domyślny styl modelu może być zbyt rozwlekły — bez twoich instrukcji dostaniesz gorszą czytelność; a zwięzły raport i tak poddawaj weryfikacji merytorycznej.

9.Recenzent: wybieraj między „dużo znalezisk plus szum” a „mało, ale precyzyjnie”

Na czym polega: W przeglądzie ośmiu PR-ów Opus znalazł 23 rzeczy (21 trafnych, przy tym kupę drobiazgów), Soul ledwie 9 (każde o wadze), Muse 16 — złoty środek, najczęściej pokrywający się z ustaleniami innych.

Jak stosować: Przy jednym recenzencie model typu Muse wykryje najwięcej realnych bugów; przy kodzie krytycznym dołącz model „głębinowy”, który wyłapie problemy niezauważone przez nikogo innego.

Na co uważać: Model uczulony na drobiazgi zaśmieca recenzję; model zbyt oszczędny pomija realne błędy w małych PR-ach. Żadna skrajność nie jest darmowa.

10.Trzeci gracz w czołówce to presja na ceny i jakość

Na czym polega: Pierwsza od lat premiera klasy czołówki spoza OpenAI i Anthropic; konkurencja między dwoma liderami już wcześniej wymuszała spadki cen i wzrosty jakości.

Jak stosować: Buduj pipeline’y niezależne od dostawcy (wymienne modele, ustandaryzowane wywołania), żeby móc szybko przejść na tańszy lub lepszy model. Nowe premiery testuj na własnym, stałym zestawie zadań.

Na co uważać: Entuzjastyczne recenzje nowości bywają efektem „innego smaku” — sam Theo uczciwie przyznaje swoje skrzywienie jako recenzenta. Werdykt wystawiaj na własnych zadaniach.

Redakcyjne tłumaczenie

No i się doczekał

Stało się. Laboratorium inne niż OpenAI czy Anthropic wydało model z tej samej ligi co Fable i Astra. Wiem, że brzmi to nieprawdopodobnie, ale jednak się zdarzyło. Meta wraca do gry w stylu, jakiego się nie spodziewałem. Serią Muse Spark 1.2 zachwycałem się szczerze, wersji 1.3 nie opisywałem, choć była przyzwoita — ale że Muse Wonder ma mnie położyć na łopatki, tego się nie spodziewałem. Używam go od kilku dni i naprawdę robi na mnie wrażenie. Zobaczcie benchmarki, a zrozumiecie dlaczego. Na przykład… o, moment. To grzesznie brzydki interfejs, który Muse wygenerował mi podczas testów metodą vibe codingu. To nie może być prawda. Dobra, przejdźmy do liczb. O, a to cała sterta paskudztw, jakie ludzie wypisują o mnie za to, że model mi się podoba: „Theo dał się kupić, zero wiarygodności”, „Trudno uwierzyć, że Meta ci za to nie zapłaciła”, „Czemu ten gość tweetuje, jakby Meta mu płaciła? Ile ci dali?” — to ostatnie od jakiegoś Tibo, nie wiem, kim jest.

(Informacja dodatkowa: Artificial Analysis, wspomniany niżej, to niezależny serwis porównujący modele AI w ustandaryzowanych testach.)

A prawdziwe liczby wyglądają dobrze. Muse Wonder Full to nie tylko wielki skok nad Sparkiem 1.3 — jego najlepszy przebieg na Artificial Analysis okazał się lepszy od wszystkich modeli OpenAI, co daje Mecie trzecie miejsce w ogólnej klasyfikacji. To zakręcone. Co więc jest grane? Czy ten model naprawdę zepchnął OpenAI z pozycji drugiego laboratorium świata? Czy jest tak dobry, jak podpowiadają testy? A może plecię bzdury, bo mnie opłacili? Wyjaśniam: Meta nie zapłaciła mi centa. Miałem szczęście testować model przed premierą, a płacą za ten film wyłącznie dzisiejsi sponsorzy.

Wszędzie widać ostatnio falę narzędzi typu osobisty asystent: Rockbot z rodziny Meta Muse, Dots od OpenAI i kolejne. Łączy je jedno — nie opierają się na wiedzy zaszytej w modelu. Gdyby odpowiadać mogły tylko tym, co już „wiedzą”, byłyby bezużyteczne. Potrzebują świeżego, szczegółowego kontekstu o rzeczach, nad którymi pracujesz i o których myślisz. I radzą sobie z tym wszyscy tak samo: przez internet. Gdyby szły przez dzisiejszego sponsora, Browserbase, wychodziłoby im to o niebo lepiej.

Nie zliczę problemów, jakie sprawiły mi narzędzia pokroju Rockbota. Nawigacja po sieci — jest. Wyszukiwanie — jest. Ale niech się tylko zalogują na twoje konto, i już jesteś w kropce. Zwykle kończy się na szaleństwach w rodzaju stawiania całej maszyny wirtualnej albo dedykowanego Maca mini. Browserbase wyprzedza tu konkurencję o klasę — szczerze mówiąc, mam nadzieję, że xAI albo OpenAI w końcu ich przejmie. Ich system uwierzytelnień jest świetny i łączy się wprost z 1Password, dzięki czemu agenci logują się do twoich usług we własnej, odseparowanej przeglądarce. Nie potrzebujesz pełnej nawigacji, tylko danych z sieci? Search API jest znakomite — banał dla ciebie i dla twoich agentów. Chcesz zajrzeć głębiej w konkretną stronę? Czeka Fetch API: podajesz adres, dostajesz HTML, JSON albo markdown — co agent woli. A skoro 85% API w sieci nie da się pobrać zwykłym curlem, to funkcja kluczowa, jeśli agenci mają umieć więcej. Daj swoim agentom cały internet: soda.link/browserbase.

Najpierw to, co boli

Wracam. Zrobię coś nietypowego i zacznę od zarzutów, żeby mieć je z głowy. Pierwsze, czego nienawidzę w tej premierze: to nie jest jeden model, tylko dwa. Są Muse Wonder i Muse Wonder Full — tak, gra słów „wonderful”, cudownie. Gdyby chodziło tylko o żenującą nazwę, machnąłbym ręką, ale przepaść między nimi jest gigantyczna. Zwykły Wonder generuje około 120 tokenów na sekundę, pełna wersja około 50 — to ewidentnie inny, większy model. I nie byłoby w tym nic złego, gdyby nie fakt, że przez API — z podaną ceną — dostępny jest wyłącznie mniejszy Muse Wonder. Pełną wersję dostaniemy tylko w subskrypcji Muse Code. Przez to trudno ją rzetelnie mierzyć, zwłaszcza w relacji ceny do jakości: skoro nie znamy ceny, nie ma czego liczyć. Do kompletu w komunikacie premierowym nie podano cen w ogóle. Chwalono się za to świetnymi wynikami najlepszych przebiegów pełnej wersji: pokonuje Fable, Astrę i Opusa 5.5 w całej serii testów.

Jednym z filarów tego modelu jest pamięć. Meta opowiada, że na etapie post-trainingu uczyła go, jak pamięć działa, żeby te mechanizmy naprawdę przyswoił — ciekawe i świeże podejście, jestem ciekaw, co z niego wyrośnie. Wyniki na Terminal-Bench robią wrażenie: miażdżą osiągnięcia Fable 5.1 i zbliżają się do Astry oraz Opusa 5.5. W Deep Sweep i SWE Marathon pełna wersja ustanowiła rekordy — ale znowu: nie znamy ceny. Po prostu jej nie podano. Podobno mocno brakuje im mocy obliczeniowej, ale choćby napisali, ile model kosztuje, żeby świat miał punkt odniesienia. Cóż, trudno.

Mamy za to cennik zwykłego wariantu: 4 dolary za milion tokenów wejściowych, 20 dolarów za milion wyjściowych i 20 centów za odczyt z pamięci podręcznej. To odrobinę taniej niż Opus — i właśnie to boli, bo w większości pokazywanych benchmarków występował nie ten model, lecz pełna wersja, która zresztą najbardziej przypadła mi do gustu. Ten przeceniony wariant to znacznie mniejsza konstrukcja. Skoro mniejszy kosztuje prawie tyle co Opus, pełny może być wyceniony jeszcze wyżej — może wyżej niż Opus 5.5. I tyle pieniędzy nie byłoby to warte.

Grafika 3D: słabo

Zarzutów jest więcej, ale obiecuję, że warto przetrzymać — bo gdy je z siebie wyrzucę, wejdę w tryb zachwytów i pokażę, co w tym modelu kocham, bo szczerze czerpię z niego frajdę. Kolejny problem: grafika trójwymiarowa. Mówię wprost — słabo. Zobaczcie demo z traktorem, porównujące Opusa 5.5 z pełnym Muse Wonder: nie dobrze. Wspomnę też o próbie, którą zwykle trzymam na finał — o teście, w którym model dostaje za zadanie sklecić trójwymiarową grę z rybą, będącym moim stałym sprawdzianem na AI-owy „slop”. Ta próba także wypadła słabo.

(Informacja dodatkowa: „slop” to żargonowe określenie generycznych, szablonowych wytworów AI — tekstów, grafik czy kodu produkowanych masowo i bez polotu.)

Czy aż tak źle jak Grok 4.7? Nie, nawet blisko. Ruch i podstawowa mechanika bronią się przyzwoicie. Ma też animacje, które… no, zdecydowanie już gdzieś widziałem — sporo modeli dostało najwyraźniej ten sam zestaw danych i to samo środowisko treningowe do 3D. Jeśli tak, to wykonali z niego najgorszą robotę, jaką widziałem, bo ten model jest — co ironiczne — tragiczny w modelowaniu trójwymiarowym. To, co wyprodukował w Blenderze, to koszmar; kolorowanie ścian i oświetlenie — beznadziejnie. Ale przynajmniej gra działa, a ruch dobrze się „czuje” — do czego Grok nawet się nie zbliżył. Muse wypadł lepiej niż wersja Haiku, ale Sonnet i Opus zmiotli go z planszy. Fable również go pokonał, choć w 3D sam nie jest mistrzem. I trzeba Mecie przyznać uczciwość: w sekcji o ograniczeniach komunikatu premierowego czytamy wprost, że rozumowanie wizualne i przestrzenne, zwłaszcza zadania 3D, pozostaje znanym mankamentem.

Skąd się biorą umiejętności 3D

Pisałem o tym na Twitterze i część ludzi się oburzyła, więc tu powtórzę z naciskiem: najmądrzejszy model programistyczny świata i tak nie byłby dobry w 3D, dopóki nie wytrenuje się go pod to celowo. Ostatni skok w trójwymiarowych umiejętnościach nie wynika z tego, że modele „nagle zrobiły się takie mądre”. Grafika 3D, obsługa komputera i inne zdolności, które nas zachwycają, nie wyłaniają się ze wzrostu inteligencji. Wpisuje się je w modele osobno, w post-trainingu, w środowiskach szytych na miarę konkretnych zadań. Wszystko wskazuje na to, że jakieś zewnętrzne firmy przygotowały dobre środowisko treningowe do 3D i sprzedają je laboratoriom. Pierwszy raz zauważyłem to przy Kimi K3, gdy dziwiłem się, jak dobrze radzi sobie w Blenderze. Od tamtej pory modele kolejnych czołowych firm zrobiły analogiczny skok.

Najlepiej widać to na parze Fable 5.1 i Opus 5.5. Opus 5.5 jest lepszy w wielu zadaniach, dużo tańszy i — co tu kluczowe — nowszy. Fable 5.1 bywa mądrzejszy, bywa też głupszy, jest wyraźnie droższy, ale nikt nie podważy, że to większy i potencjalnie zdolniejszy model. I właśnie dlatego, mimo że dzieli je różnica rzędu kilku procent w obie strony, skok Opusa 5.5 w grafice trójwymiarowej robi takie wrażenie — a zarazem pokazuje, że ogólna inteligencja modelu nie przekłada się wprost na jego możliwości 3D. Mój punkt widzenia: jeśli model jest przeciętny ogółem, a dobry w 3D — to już osiągnięcie. Jeśli jest dobry ogółem, a słaby w 3D — nadal dobry. Ale jeśli jest przeciętny i ogółem, i w 3D… (Grok 4.7 — przepraszam, kaszlnąłem)… to model raczej beznadziejny.

Więc nazywajcie mnie sprzecznym, ile wlezie: do czegokolwiek trójwymiarowego bym go nie używał. Jeśli 3D jest dla was istotne, wykupcie plan Claude i nie marudźcie — to niewiarygodna wartość za te pieniądze. A jeśli szukacie najlepszego sposobu wydawania dolarów na AI właśnie teraz, to nie będą to lokalne GPU, nie żaden budżetowy plan z chińskiego laboratorium i z pewnością nie dokupowanie tokenów na OpenRouterze. Plan Claude za 200 dolarów miesięcznie to prawdziwy kosmos wartości.

Zostaje pytanie ostatnie: ile zmieścicie na planach Muse Code za 50 i 200 dolarów? Nie wiem. Nie wykupiłem żadnego — wciąż siedzę na kluczu API, który mi nadesłali. Kiedyś sprawdzę, ale nie teraz: chciałem zdążyć z materiałem, bo sporo tego, co krąży o tym modelu w sieci, jest po prostu głupie, a ja chcę pokazać, dlaczego tak mnie oczarował.

SkateBench i nuta Gemini

Czas na pozytywy. Na rozgrzewkę coś błahego: przepuściłem go przez SkateBench, którego dawno nie pokazywałem, bo zwykle wychodzą na nim dziwactwa. Na przykład Opus 5 Max uzyskał 84%, a 5.5 Max — 79%; zauważyłem, że trening ze wzmocnieniem zwykle psuje modelom wyniki na tym teście. Dziwny sprawdzian, ale lubię patrzeć, jak modele się na nim zachowują. Jako jedyna rodzina przekraczała kiedyś próg 90%: Gemini — 3.1 Pro zdobył 96%, podobnie 3.8 Flash High. Nic innego nie zbliżyło się do tych liczb. Do dziś: Muse Wonder Full uzyskał 95%.

Jeśli znacie moje zdanie o Gemini, wiecie, że mogło mnie to zaniepokoić. Ale posłuchajcie. Modele Gemini mają niezwykły dar rozumienia złożonych gramatyk i rozumowania przestrzennego — nie w sensie „zbuduję grę 3D”, tylko w głowie: obracania i przekształcania obiektów w wyobraźni. Świetnie też etykietują obrazy: dostają zdjęcie z prośbą o wskazanie elementów i trafiają we właściwe piksele. Z nieznanych przyczyn ten zestaw cech owocuje tym, że Gemini bezbłędnie nazywają triki skateboardowe. Muse ma w sobie, jak się wydaje, kawałek tej samej osobliwości — i, nie ukrywam, mnie to przeraziło. Bałem się, że jeśli powtórzyli sztuczkę Gemini, to mogli przy okazji okaleczyć model w innych obszarach. Sprawdźmy więc te inne obszary.

Interfejsy: nie ten model

Dobra, skłamałem — jeszcze jedna rzecz na minus, nim ruszymy. Ten model jest fatalny w interfejsach użytkownika. Nie po prostu słaby — okropny. Nie generuje UI „błędnie” tak jak Grok; generuje generyczny, tandetny slop à la Sonnet 3.7. Jeśli marzy wam się model uniwersalny — od debugowania jądra, przez piękne ekrany, po budowanie gier — wracajcie do Claude. Tutaj tego nie znajdziecie.

Audyt Thunderstore: inny smak

Skoro przez ostatnie dziesięć minut jechałem po tym modelu, co właściwie mi się w nim podoba? Zaraz pokażę.

Zacznę od nietypowego miejsca. Ostatnio gram w Reskate — otwartą nakładkę na skate’ową grę EA ze Steama: peer-to-peer, mody, stare mapy, świetna zabawa. Sklep z modami, Thunderstore, indeksuje się jednak strasznie wolno. Projekt jest open source, więc uznałem, że zabawnym sprawdzianem będzie wrzucenie nowego modelu na audyt: niech znajdzie, co spowalnia indeksowanie.

Co mnie zachwyciło? Przemyślana analiza? Zgrabny pakiet zmian? Zgłoszony pull request? Nic z tego. Po prostu przeczytajmy, co napisał: „Audyt zakończony. Pełny raport w pliku. Główne wnioski: konfiguracja CDN jest w porządku. Spowolnienie bierze się z danych, które słabo poddają się cache’owaniu. Sam Reskate jest mały — indeks waży 0,48 megabajta i na rozgrzanym węźle edge ładuje się w 0,78 sekundy. Problemy zaczynają się na zimnych ścieżkach i przy skali.”

Widzicie to, co ja? Czytanie tego nie boli. Co więcej — prawie sprawia przyjemność. Dla jasności: nie twierdzę, że to nie jest slop. Twierdzę, że to inny smak slopu — taki, którego jeszcze nie próbowałem, i nie smakuje jak kolejna destylacja Claude. A to rzadkość i ulga, zwłaszcza gdy uświadomić sobie, ile danych po Claude zebrała Meta, płacąc Anthropic absurdalne rachunki za API. Spodziewałem się, że wszystkie nadchodzące modele Mety będą mówiły i zachowywały się jak Claude, bo mają takich danych po uszy. Ten nie mówi.

Inni opisywali zresztą zupełnie inne doświadczenia z rozmowami z nim. Zrobiłem więc krótki eksperyment: wyciąłem z mojego AGENTS.md wskazówki w stylu „mam ADHD — pisz krótko i przejrzyście, różnicuj długość zdań, używaj uproszczonego angielskiego technicznego tam, gdzie to pomaga”. Bez nich model zrobił się wyraźnie bardziej rozwlekły. Domyślne nastawienie nie jest więc może najprzyjemniejsze w obsłudze — ale gdy odpaliłem go u siebie, bez żadnych zmian, po prostu z moim zwykłym AGENTS.md, od razu został moim ulubionym partnerem do pracy, i to wyłącznie dzięki sposobowi, w jaki się wyraża. A czy płacę za to poważnym uszczerbkiem na inteligencji? Zależy od zadania, ale ogólnie rzecz biorąc: nie.

(Informacja dodatkowa: AGENTS.md to plik z instrukcjami dla agentów kodujących, umieszczany w katalogu projektu.)

Lust: pojedynek Muse z Opusem

Jeden z moich świeżych projektów pobocznych nazywa się Lust: podzbiór Rusta, który ma się kompilować sto razy szybciej. Skoro udało mi się przepisać kompilator TypeScriptu w Rustcie, pomyślałem: czemu by nie napisać własnego kompilatora do własnego języka i nie przekompilować nim TS Rusta? Staram się maksymalnie utrudniać modelom życie, rozumiecie.

Ten wątek ciągnie się już długo i rozkręcił ponad 115 agentów rozbijających pracę na kawałki. W pewnym momencie poleciłem mu uruchamiać każde zadanie równolegle na Muse i na Opusie, a potem zebrać panel sędziów oceniających zmiany z obu stron — chciałem mieć czyste porównanie. Kazałem zdać relację: „Jak ci idzie porównanie Muse z Opusem?”. Odpowiedź w skrócie: Opus pracuje głębiej i poprawniej. Muse robi więcej i szybciej — i jest, niespodzianka, znakomitym recenzentem. W jednym konkretnym zadaniu wszyscy trzej sędziowie, nieznający autorstwa zmian, wybrali Opusa, a różnica średnich okazała się brutalna: 41 kontra 30 punktów na 50. Wersja po Opusie budowała się około dwa i pół raza szybciej, a wersja po Muse wchodziła na buga. Mocne.

Jak to jednak wygląda na dłuższą metę? W codziennej pracy to Muse ląduje najwięcej zmian w repozytorium, a część wyników jest znakomita. Naprawił całą serię rzeczy, przez które testy przechodziły, choć nie powinny. Grzebał w warstwie sterowników, łatał błędy nazewnictwa. Jako recenzent jest dokładny i rzeczowy: napisał 209 sond testowych pod poprawki Opusa i pogrupował je czytelnie. Jako sędzia jest fair — własne zgłoszenie ocenił na drugim miejscu. Parokrotnie kazałem Opusowi i Muse niezależnie przeanalizować ten sam problem, zajrzeć w kod i zaproponować ścieżkę naprawy — i dziwiłem się, jak często Opus wolał plan Muse. W wielu z tych sytuacji Muse zresztą przegrywał, woląc plan Opusa, ale gdy kazałem im ze sobą porozmawiać — co, nie chcę się przechwalać, ale jest naprawdę fajną funkcją T3 Code — po osobnej pracy i wymianie zdań zwykle umawiali się, że bazą będzie plan Muse z poprawkami Opusa. To mnie szczerze zaskoczyło. Po długim wahaniu Opus, prowadzący ten wątek, zdecydował: Muse bierze większość pracy — poprawki, bibliotekę standardową, fuzzing i recenzje; Opus zostaje przy kawałkach hardestych, gdzie błędny projekt wiele kosztuje, jak merge do T2 speed czy poprawki systemu traitów. Każdy recenzuje pracę drugiego, a z każdej recenzji rodzą się poprawki. Opus ocenił Muse na B+, a siebie na A-, dodając, że jest „wyższej jakości przy niższej prędkości i wyższym koszcie”. Tyle że kosztu Muse nie znamy, więc odejmijcie od tej oceny odpowiedni dystans.

(Informacja dodatkowa: T3 Code to autorskie narzędzie Theo, prowadzącego kanał, do zarządzania agentami kodującymi.)

Delegowanie: urodzony dowódca

Porozmawiajmy o tym, jak ten model deleguje pracę i rozmawia z innymi modelami, bo to robi na mnie największe wrażenie. Zrobiłem szybki test: poleciłem mu wystawić trzech delegatów do zbadania różnych zakątków kodu T3 Code — na bieżącym identyfikatorze modelu alfa i Haiku 5.5. Zajrzyjmy, jak sam siebie promptuje: „Wciel się w podagenta badawczego tego zadania. Zbadaj i opisz warstwę kontraktów oraz integrację dostawców i agentów w T3 Code. Zakres: opisz wprost, jak dostawcy oraz MCP i agenty łączą się z serwerem. Wymogi: przeczytaj treść implementacji dla każdego cytowanego twierdzenia. Wyniki wyszukiwania tylko wskazują kandydatów — nie cytuj pliku, którego nie otworzyłeś. Mapa: i tak dalej. Nie edytuj żadnych plików, wyłącznie analizuj.”

To znakomity komunikat do wysłania podagentowi — i właśnie dlatego model tak dobrze znosi orkiestrację: swojej własnej pracy i pracy innych. Sprawdza się jako dowódca; jako pośrednik w komunikacji dobrze koryguje kurs. Krótko mówiąc, umie współdziałać z innymi modelami — co mnie dziwi, bo to jedna z kompetencji, w których laboratoria inne niż Anthropic i OpenAI zwykle kuleją. Tutaj nie kuleje wcale. Ten model naprawdę potrafi zlecić innym robotę i dopilnować efektu. Ogarnia też bardzo dużo równoległych procesów naraz, a to znowu rzadka sztuka.

Trzeci smak czołówki — i skrzywienie recenzenta

I to wszystko składa się na moje odczucie, że model jest z najwyższej półki. Ma swoje dziwactwa i w niektórych miejscach ustępuje konkurencji — jeszcze do tego wrócę — ale to pierwszy model spoza dwóch wiodących laboratoriów, któremu bez oporów powierzyłbym długie zadania. Pierwszy model z innego podwórka, który tak sprawnie orkiestruje podagentów i całe przepływy pracy. Chcę powiedzieć: to trzeci smak czołówki. Ma plusy, ma minusy, będzie miał cenę, która pewnie nie zachwyci — ale jest inny, a tę inność naprawdę smakuję.

I tu musicie doliczyć moje skrzywienie zawodowe. Ktoś, kto recenzuje modele codziennie, z natury ceni wszystko, co inne. Nie mogę pozbyć się skojarzeń z moimi czasami w branży audio: recenzent kolumn potrafi polubić nowy model bardziej, niż na to zasługuje, wyłącznie dlatego, że brzmi inaczej — może nawet dlatego, że w czymś brzmi „źle” — bo jest tak znudzony sprzętem, który brzmi tak samo, tylko trochę głośniej albo odrobinę lepiej w wybranych pasmach, że konstrukcja o zupełnie innym charakterze go porywa. Wiem, że to część powodu mojego zachwytu: ten model mówi, myśli i działa trochę inaczej — a przy tym nie jest głupi.

Podłoga głupoty: rekordowo nisko

Druga rzecz, którą w nim cenię: brak głupoty. Przez cztery, pięć dni katowania go na maksa nie zaliczyłem z nim ani jednej rażącej wpadki — podczas gdy w pół godziny przygotowań do tego materiału z GPT-6.1 Soul i Astrą przeżyłem ich więcej. W jednym wątku z Astrą zobaczyłem więcej dziwactw niż w całej historii pracy z Muse. Nie przesadzam. Poszedłbym dalej: jest odrobinę mniej głupi nawet od Opusa. Mój ranking głupoty: Astra — dziesięć na dziesięć. Beznadziejna. Co nie znaczy, że niemądra: uważam mądrość i głupotę za osobne cechy, można mieć obie. Astra jest bardzo mądra i bardzo głupia. Opus jest jeszcze mądrzejszy i dużo mniej głupi — powiedzmy trzy na dziesięć głupoty i dziesięć na dziesięć mądrości. Muse ustępuje nieco mądrością: pułap wisi trochę niżej, na jakieś osiem, dziewięć na dziesięć. Ale głupota spada jeszcze wyraźniej: jedno, dwa na dziesięć. Ten model po prostu nie robi głupich rzeczy. Robi brzydkie — fatalnie ogrywa front-end, fatalnie trójwymiarówkę — ale nie głupie. Nie spodziewałbym się po nim numerów w stylu usunięcia katalogu, którego ruszać nie wolno, czy wpakowania samego siebie w stan, w którym nic nie działa — a takie widowiska widziałem przynajmniej raz od każdego innego modelu. Po prostu zachowuje się przyzwoicie.

Jeden bug, trzy modele

Dam przykład z życia, który — sądzę — pokaże, dlaczego tak lubię z nim pracować. Niedawno dodałem w T3 Code funkcję zdalnej aktualizacji wszystkich maszyn i ich providerów jednym kliknięciem. Technicznie dwoma: przycisk na dole i potwierdzenie. I zauważyłem, że na zdalnych maszynach nie aktualizuje się sam runtime T3 Code. Przyczyną okazał się dość pokręcony, niszowy bug. Pokażę najpierw przebieg z Opusem. Od razu zauważyłem, że model się gubi: zaglądał w historię i widział, że instancja była aktualizowana. Wtrąciłem więc w trakcie pracy krótką korektę: „aktualizację uruchomiłem ręcznie, już po fakcie” — żeby wiedział, skąd ta aktualizacja w historii się wzięła. Nie była spóźniona; ktoś odpalił ją ręcznie, a nie przez właściwy mechanizm. Od tego momentu model robił wszystko dobrze: znalazł buga i naprawił go. Poprawka leżała niezapisana w drzewie roboczym. „Przyczyna: itd. itd. — ten akapit ma po prostu za dużo tekstu, moim zdaniem. Co pokazały logi? To, co się wydarzyło, istotę poprawki i wykonane testy. Testy nadal padały po cichu: „jeśli NPM jest nieosiągalny, itd. Czy otworzyć PR do tej zmiany?”. Kazałem mu się zatrzymać i ściągnąć mój skill: model zlecił recenzję Soulowi, PR powstał i wszystko wyglądało nieźle.

A jak to samo zadanie ogarnął Soul? Ten sam prompt. Na starcie odpalił za dużo rzeczy i stwierdził: „Ustawienia w panelu bocznym wybierają zdalne aktualizacje według innych reguł”. Najwyraźniej nie zauważył, że ta rzecz właśnie się zmieniła — choć w prompcie stało wprost: „nowy przepływ »update everything« nie aktualizuje środowisk zdalnych”. Słowo „nowy” po prostu do niego nie dotarło. I to jest część tego, co mi nie leży w modelach OpenAI: czasem odnoszę wrażenie, że gubią ważne słowa we własnej głowie — i tu model zgubił wątek, że chodzi o nową zmianę. Potem wpadłem na błąd, bo ich narzędzie pytań asynchronicznych nie dogadywało się z moim proxy. Po części moja wina, po części ich — zwłaszcza że to Soul wcześniej łatał proxy, żeby to w ogóle działało. Nieważne: kazałem iść dalej i wygrzebać się ze stanu awaryjnego. Odpowiedział, że naprawił lokalnie: „panel boczny pomija zdalne serwery, dopóki ich sprawdzanie NPM trwa lub pada” — i usunął to sprawdzanie. To nie jest rozwiązanie. Rozwiązaniem jest ustalenie, którą wersję aplikacji wysłać na zdalne maszyny. Ta „naprawa” oznaczałaby, że po aktualizacji lokalnej aplikacji oraz wszystkich Muse, Cursorów, Claude’ów i Codexów na zdalnych maszynach musiałbyś uruchomić całość drugi raz, żeby zaktualizować serwery — czyli po prostu wepchnęłaby im obecną wersję twojej aplikacji. Źle. Bardzo źle. Zapytałem, jak to się ma do innych PR-ów naprawiających problem i co się stanie, gdyby host był w tyle — i odpowiedź zrobiła się mętna.

Dobra, a jak poradził sobie Muse? Cytuję: „Główny wniosek: przepływ psuje jedno nieudane żądanie webowe. Poprawka już istnieje i jest gotowa. W tym drzewie kodu nie wprowadzam żadnych zmian. W przepływie panelu bocznego, gdy aktualizowany jest zdalny serwer, dodawane jest sprawdzenie npm: ‚czy ta wersja została opublikowana?’. Sprawdzenie korzysta z klienta HTTP biblioteki effects i dokleja do żądania dwa nagłówki śledzenia. Uruchomiłem bieżący kod z testowym zapytaniem — oba nagłówki są w żądaniu.” Widzicie, o ile czytelniej? Ale to nie jest najlepsza część. Przewińmy niżej: „Status poprawki: dwa otwarte PR-y naprawiają to tą samą zmianą w jednej linijce — wyłącz nagłówki śledzenia dla tego jednego żądania.” Dwa PR-y. Te od Opusa i Soula? Nie. Pierwszy napisał ktoś zupełnie obcy, drugi — Opus. Czyli nie tylko odpowiedź Muse była wielokrotnie zrozumialsza: on jeszcze znalazł znacznie mniejszy, czystszy PR, który ktoś już zgłosił i który rozwiązuje problem. Żaden z pozostałych modeli tego PR-a nie znalazł. Żaden nie opisał czytelnie istoty problemu. Żaden nie zaproponował: po prostu zmergujmy gotową naprawę. Przyznacie — to bezdyskusyjnie najlepsza odpowiedź z trzech. Żaden benchmark tego nie zmierzy; takie rzeczy strasznie trudno ubrać w liczby. Jakiż to przyjemniejszy partner do prawdziwej, codziennej roboty — będę mu od dziś sypać zgłoszeniami błędów, żeby zrozumieć, co nie gra, i sprawdzić, czy ktoś już nie zgłosił poprawki.

Własne testy: audyty i przepaść między wariantami

Muszę jednak ponarzekać dalej. Skleciłem parę testów — „benchmarki” to tu słowo zbyt wielkie — w których modele przeczesują moje wielkie bazy kodu, oceniają, co dobre, co złe i co brzydkie, a potem pomagają mi ustawić priorytety. Przykład: wszystkie modele przeszły po architekturze T3 Code i ją skomentowały. Tu Opus zdeklasował stawkę — wynik Opusa 5.5 był oszałamiający. Sonnet 5.5 też spisał się zaskakująco dobrze. Dalej Soul i Astra, a tuż pod nimi Muse. Ciekawostka: Muse i Astra wypadły blisko siebie. Zwykły Muse Wonder — ten bez „Full” — spadł jednak do niespełna połowy wyniku Opusa. Ponad 30 procent różnicy w jakości spostrzeżeń między pełną a zwykłą wersją. Moim zdaniem zwykły Wonder w tej cenie nie ma żadnego sensu i nie wnosi nic porywającego. Podejrzewam, że większość dem krążących w sieci działa właśnie na Wonderze: ludzie biorą API, wpychają je w swoje zwykłe narzędzia i patrzą na słabe wyniki. Rozumiem to. W takim ujęciu Muse Wonder wygląda na zły model. Tymczasem Muse Wonder Full w mnóstwie rzeczywistych zadań idzie łeb w łeb z Astrą i Fablem i jest po prostu przyjemny we współpracy.

Podobny audyt zrobiłem na Lakebed, moim produkcie chmurowym. Tu zdecydowanie najlepiej wypadł GPT-6.1 Soul — dziewiątka od wszystkich sędziów — a Muse Wonder spadł wyraźnie: 5,75. Opus 5.5, GPT-6 Astra i Sonnet wylądowali blisko siebie. Coś tu nie gra, bo Sonnet 5.5 wyżej niż Opus podpowiada, że to nie był najlepszy test. Ale sklecałem je na szybko, tylko żeby zobaczyć.

Czas i tokeny

Z Muse Wonder Full zobaczymy jeszcze jeden zabawny trend: ile czasu i ilu tokenów trzeba, żeby dojść do wyniku. Audyt Lakebed: 16 minut — prawie o połowę krócej niż GPT-6.1 Soul i ponad dwukrotnie krócej niż Opus. Sonnet potrzebował 80 minut. Nieciekawie. Podobne rozstępy wyszły przy TS Rust, a to nie jest mała baza. Muse Wonder Full uzyskał tam wynik niemal identyczny z Fablem 5.1: 17 minut i przeciętna punktacja, ale ponad 10 minut szybciej niż część rywali i śmiesznie szybciej niż Sonnet i Opus — niemal o połowę. Zwykły Wonder: znów przeciętny wynik, za to 5 minut 9 sekund. Chcę powiedzieć jedno: te modele są szybkie i dość oszczędne w tokenach.

Widać to na Slop Politics. Nie znamy kosztu pełnej wersji, więc o stosunku kosztu do inteligencji mowy nie ma — zostaje zużycie tokenów. I widać, że Muse pali ich mniej niż Opus 5.5 na trybie X High, osiągając niemal identyczne wyniki. Gdyby z zestawienia wykluczyć modele „Max” — co niestety wykłada modele Muse Wonder, otagowane jako Max, choć formalnie są to X High, o ile pamiętam — Wonder byłby najlepiej punktowanym modelem poza grupą Max, tuż za 5.5 X High. Wynik absurdalnie dobry. Na wykresie słupkowym Gemini 4 Argon pali odrobinę więcej tokenów, ale praktycznie wszystko inne, na czym dziś realnie zależy — poza modelami OpenAI — pali znacznie więcej, w tym Opus i Fable. A gdyby doliczyć Sonneta, wyszedłby rekord wszech czasów. Imponujące — Muse pobił pod tym względem nawet Groka. Nie spodziewałem się takiej oszczędności po tej premierze. Ciekawostka: Wonder i Wonder Full zużyły niemal tyle samo — 53,8 tys. tokenów na zadanie dla wersji pełnej i 54,2 tys. dla zwykłej. Dziwne, że zachowują się tak podobnie, skoro zwykły Wonder jest dużo słabszy. Boże, jak ja nienawidzę tych nazw.

Recenzowanie PR-ów: trzy filozofie

Kontekst, żeby to wszystko grało. Kazałem Opusowi wybrać osiem losowych, jeszcze niezmergowanych PR-ów w T3 Code o różnej złożoności, a potem każdy z trzech modeli — GPT-6.1 Soul, Wonder Full i Opus 5.5 — recenzował wszystkie. Następnie porównywałem spostrzeżenia, weryfikowałem je i sprawdzałem, który model wyciągnął najwięcej nowego i trafnego.

Wyniki. Opus 5.5 znalazł w tych PR-ach 23 rzeczy, z czego 21 zasadnych; jedna wątpliwa, jedna błędna; osiem to drobiazgi. GPT-6.1 Soul znalazł tylko dziewięć — ogromna przepaść — w tym siedem zasadnych i dwie błędne; jego nowatorski dorobek zamknął się czterema spostrzeżeniami. Muse: szesnaście — idealnie pośrodku między Opusem a Soulem — w tym pięć nowych. Wniosek prosty: Opus wciąż znajduje najwięcej świeżego, ale dosypuje do raportu kupę drobiazgów. Soul drobiazgów nie dosypuje, ale też nie znajduje prawie nic. Jeśli Soul jest waszym jedynym recenzentem, dobierzcie mu wsparcie. Muse okazał się zaskakująco udanym środkiem. Zaznaczę jeszcze, że Muse nie znalazł tylu poważnych problemów co Soul i Opus, ale sama ta obserwacja jest bardzo użyteczna.

Podsumowanie tego testu: Opus wyłapał najwięcej problemów nieznanych nikomu innemu, w tym cztery średniej wagi; pisze średnio jednego drobiazgu na PR, a w jednym PR oznaczył zamierzone zachowanie jako bug — bardzo w jego stylu. Soul nie napisał ani jednego drobiazgu, więc każde jego spostrzeżenie miało wagę; w trzech z czterech małych PR-ów nie znalazł nic, choć realne drobiazgi tam były; jego unikalne wnioski brały się z drążenia — na przykład z czytania źródeł zewnętrznych w dokumentacji hyperdrive. Muse najczęściej trafiał na bugy znalezione też przez innych, więc jeśli ma być jedynym recenzentem, sprawdza się dobrze; wyłapał problem z unieważnianiem tokenów przy ponownym otwarciu, którego Opus nie widział; większość jego unikalnych spostrzeżeń to niska waga, a raz zażądał zmian z powodu braku, który był już odnotowany w opisie PR-a. Nie idealnie, ale bardzo solidnie.

Priorytetyzacja: czytelność decyduje

To porównanie jest może moim ulubionym. Poprosiłem Opusa i Muse — każdego u siebie — o „niesamowicie głębokie zanurzenie” w bazie T3 Code i w feedback z GitHuba: zgłoszenia, PR-y, dyskusje. „Pomóż mi ustalić, nad czym pracować dalej”. Opus nakręcił masę agentów i napisał górę materiału. Zapytanie poszło o 10:33, odpowiedź przyszła o 11:04 — pół godziny później — w postaci wielkiego raportu: „T3 Code: nad czym pracować dalej? Dziesięć agentów zrobiło audyt; dziewięć przeczytało wszystkie otwarte zgłoszenia, wszystkie PR-y i dyskusje, plus bazę kodu; dziesiąty…”. Przepraszam, robię, co mogę, ale to po prostu za dużo tekstu o rzeczach, które nic nie znaczą. Streszczenie ma po cztery zdania na punkt: „Wypuśćcie V2 na stabilny kanał — bezpiecznie i szybko; wąskim gardłem jest mergowanie, nie pisanie kodu; około połowy października…”, „Użytkownicy chcą niezawodności, nie funkcji; największy ból: uruchomienia utknięte w stanie »running«, zabijanie zasobów serwera…”, „Tydzień pierwszy: merge i drobne poprawki”. Kategoryzuje przyzwoicie, robi tabele, ale tekstu jest po prostu za dużo. Sekcja o „bramce jakości dla V2 stable” — czytelność żadna. Napisał górę.

A teraz odpowiedź Muse. Zapytanie poszło o 9:19. Proces najwyraźniej zawiśł i zrobił reset, więc nie znam łącznego czasu i nie podam uczciwych znaczników. Po restarcie zadanie ruszyło o 10:24 i skończyło się o 10:31 — razem jakieś 17 minut, mniej więcej połowa czasu Opusa. To zgadza się z moim ogólnym doświadczeniem: szybko, sprawnie, bez palenia ton tokenów i bez sprawdzania dziesięciu głupich miejsc, zanim trafi we właściwe. Najlepszy opis, jaki znam: ten model ma dobrą intuicję. Wie, gdzie patrzeć, i znajduje to, czego szuka, w krótkim czasie. Nie mam pojęcia, jak oni to zrobili — może wytrenowali go na gigantycznej wewnętrznej bazie Meta i zgromadzili świetne dane — ale on naprawdę wie, gdzie sprawdzać najpierw. Na starcie potrafi dorzucić błahą uwagę: „To jest plan, nie tryb specjalny. Nie rozpocząłem implementacji” — widać, że trenowano go na koncepcji plan mode i sam ją sygnalizuje; widziałem to parę razy przy prośbach o plany. Ale przeczytajmy samą treść.

„Cel: wybrać kolejne prace dla T3 Code na podstawie realnych dowodów. Dziesięć agentów badawczych przejrzało zgłoszenia, PR-y, dyskusje i kod. Jeden krytyk próbował obalić najważniejsze tezy. Następnie samodzielnie przeliczyłem kluczowe liczniki z GitHuba i sprawdzenia w kodzie.” Już ten wstęp jest o niebo czytelniejszy niż początek raportu Opusa. „Stan w liczbach: otwarte zgłoszenia, bugi, szybkość, review” — wciąż trochę za dużo jak na mój gust, ale zaraz schodzimy do rzeczy. „Kluczowe decyzje: 1) Zamroź nowych dostawców i nowe usługi, dopóki nie zejdą P0 poniżej — i tak to szerokość oferty dostawców napędza największe klastry zgłoszeń: Claude — 118 trafień w tytułach, code — 76. 2) Uśmierć stary panel boczny — dwa panele podwajają koszt każdej poprawki; nie trzymaj obu. 3) Traktuj dyskusje jako niewiarygodne, dopóki nie sprawdzisz, co realnie wydano — dyskusje nie zamykają się same. 4) Próbkuj backlog PR-ów, zanim go ocenisz — tablica kanban nie dowodzi, że review kuleje.” Nie ideał, ale czyta się znakomicie. A teraz lista tego, co moim zdaniem mam robić — bardzo jasna i lekka. Sekcja P0, najbliższe dwa tygodnie:

Napraw dwa zawieszenia serwera (rozmiar M + M). Przy zgłoszeniu informacja, co w nim istotne; inne zgłoszenie pokazuje, że jeden zablokowany provider potrafi zatrzymać wszystkie cztery workery effects — rozmiar puli to cztery, w tym pliku. Dodać izolację na poziomie workera przy przekroczeniu czasu.
Zatrzymaj spalanie limitów i payloadów przy PR-ach (rozmiar S–M). Zgłoszenie opisuje 2800 wywołań Bitbucketa w 100 minut i 22 423 wywołania GitLaba w 12,5 godziny: przestać pobierać od nowa po odzyskaniu fokusa, cache’ować per PR, wycofywać się przy błędach limitów. Kolejne zgłoszenie: migawka wątku ważąca 17 megabajtów. Może jestem po prostu zmęczony claude’owskim slopem, ale to czytam sto razy łatwiej. Zdania zaczynają się pogrubieniem, które od razu mówi, co ważne.
Napraw pierwsze użycie dostawcy — OpenCode pokazuje tylko 29 wbudowanych modeli. To problem dostawców, którzy nie zdążają przesłać aplikacji właściwych modeli, więc pokazujemy zły zestaw. Bardzo dobrze to ujął.
Napraw ugrzęźnięcie zakresów u korzenia, a nie osobno dla każdego zakresu (rozmiar S dla buga, M dla systemu). Szczerze: ten punkt jest mniej czytelny od reszty — sam bym zajrzał do zgłoszenia. Zajrzyjmy: „iOS: konta dostawców padają, gdy przy świeżych tokenach T3 Connect brakuje uprawnień provider-manage”. Czyli w niektórych sytuacjach połączenie przez aplikację iOS z T3 Connect nie działa. Dobre.
Przeprowadź tygodniowy przegląd zgłoszeń utraty danych i błędów bilingowych. Ostatnie tytuły: zniszczone pliki środowisk, cofające się edycje ustawień, podrachunki rozliczane po anulowaniu. Liczby małe, waga duża, dowodów mało — odtwórz każde na obecnym nightly. Uczciwie: model powiedział wprost, że zgłoszeń jest mało, ale waga jest duża i dowodów brakuje, więc trzeba je odtworzyć.

Potem sekcja P1 z rzeczami prostszymi i P2: „później albo wcale”. Tekstu o połowę mniej, czytelności kilkukrotnie więcej.

Werdykt: nie porzucaj Claude, ale obserwuj Metę

Można więc powiedzieć tak: ten model może nie jest najmądrzejszy i może nie znajduje najwięcej, ale przeszedł mój próg użyteczności z ogromnym zapasem — o niebo wyżej, niż oczekiwałbym po czymś z rodziny Gemini czy Groka. Szczerze: to pierwszy od czasów Fable model spoza Anthropic i OpenAI, który wyobrażam sobie w codziennym użyciu — i po który faktycznie sięgam. Przy najtrudniejszych tematach wciąż wyciągam Opusa; często to sam Muse każe potem Opusowi sprawdzić swoją pracę. Godzę się na nieco niższy pułap możliwości, bo cenię podniesioną podłogę: model rzadziej robi głupoty, a jego odpowiedzi mają nowy, świeży smak. Sposób, w jaki do mnie mówi, jest — przynajmniej dla mnie — dużo czytelniejszy i po prostu przyjemniejszy.

Czy porzucić przez to subskrypcję Claude Code? Zdecydowanie nie. Nie mam nawet pojęcia, jak wyglądają limity na ich planach — nie sposób wiedzieć, skoro nie publikują ceny modelu, który mi się podoba. W tej premierze jest mnóstwo żenady i widać, że Meta nie przywykła do posiadania modelu, o którym warto rozmawiać. Ale ja się przejmę. Ten model mi się podoba i będę go używał, dopóki nie odetną mi klucza API — potem pewnie wykupię subskrypcję, stwierdzę, że limity są za ciasne, i wrócę do Opusa. Ale jeśli cena i limity okażą się sensowne, widzę, że mógłbym sporo na nim usiedzieć. Gratulacje dla zespołu w Mecie — naprawdę nie widziałem tego nadchodzenia. Po drobnych wypuszczeniach w stylu serii Spark nie przypuszczałem, że sięgnę po ich model przeciwko czołówce. A jednak: ugotowali.

Nawet jeśli ten model was nie porywa, powinna porywać sama wiadomość, że Meta dogoniła czołówkę. Przyszłość staje się o wiele bardziej konkurencyjna — a jeśli pamiętacie, o ile lepsze i tańsze zrobiły się modele Anthropic i OpenAI, odkąd zaczęły się ścigać, to wiecie, jak wiele może zmienić trzeci gracz. Zostaje więc jedna sprawa: ustalić, co, u licha, dzieje się w DeepMind. Serio, koledzy — jak długo można szykować Geminiego 4 Argon? Gdzie on jest? Kiedy go dostaniemy? Kiedy będę mógł opowiadać o jego mocnych i słabych stronach? Lista rzeczy wydanych przed Geminiem 4 Argon będzie już niedługo dłuższa niż lista rzeczy wydanych przed GTA 6. Nie wiem, co się dzieje w Google. Wiem za to, co się dzieje w Mecie — a wygląda to całkiem, całkiem nieźle. Jestem podekscytowany tą premierą. Ciekaw jestem waszego zdania: przegiąłem z entuzjazmem? Dałem się kupić znajomym z Mety, którzy kiedyś stworzyli Reacta, a dziś model, który mi się podoba? Dajcie znać w komentarzach. Do następnego razu — cześć.