Fable 5.1 osiąga 52,6% w Terminal-Bench-Science, a Paint.NET testuje 180 tys. linii bez pełnego review

Dzisiejsze dwa tematy łączy ten sam problem: imponujący wynik agenta nie mówi jeszcze, jak szeroko można mu zaufać. Fable 5.1 wykonał ponad połowę zadań w naukowym benchmarku terminalowym, ale test obejmował cały system agentowy i gęstą informację zwrotną. Paint.NET dostał eksperymentalne wsparcie Wine dzięki ogromnej implementacji Direct2D, której autor nie był w stanie w całości przeczytać.

Fable 5.1 osiąga 52,6% w Terminal-Bench-Science

Co się wydarzyło

Anthropic wydał 1 września modele Claude Fable 5.1 i Claude Mythos 5.1. To ten sam model bazowy z różnymi zabezpieczeniami: Fable jest wersją ogólnodostępną, a Mythos ma mniej ograniczeń w zadaniach biologicznych i cyberbezpieczeństwie i trafia do zweryfikowanych odbiorców.

Najciekawsza liczba z premiery to 52,6% w Terminal-Bench-Science 0.1. Benchmark składa się z 70 zadań naukowych wykonywanych w terminalu, od bioinformatyki i chemii obliczeniowej po fizykę oraz modelowanie. Poprzedni Fable 5 uzyskał w powtórzeniu Anthropic 24,7%, więc nowy model poprawił wynik ponad dwukrotnie.

Nie jest to jednak czysty test modelu. Wynik dotyczy pary model–harness: Fable 5.1 pracował w Claude Code, z maksymalnym poziomem wysiłku i narzędziami dostępnymi w przygotowanym środowisku. Dla każdego zadania wykonano dziesięć prób, łącznie 700 przebiegów.

Co potwierdzają źródła

Terminal-Bench-Science jest publicznym projektem z zadaniami uruchamianymi w odizolowanych kontenerach i ukrytymi testami sprawdzającymi artefakty. Autorzy benchmarku zebrali 920 propozycji, zatwierdzili 464 i ostatecznie połączyli 70 zadań. Repozytorium, format zadań i kod oceny są dostępne na licencji Apache 2.0.

Karta systemowa Anthropic podaje dla Fable 5.1 wynik 52,6% oraz błąd standardowy rzędu 3,5–4,5 punktu procentowego. Dwie trzecie zadań miało charakter niemal binarny: dany model rozwiązywał je w co najmniej 80% prób albo w najwyżej 20%. Niepewność wyniku wynika więc bardziej z doboru 70 zadań niż z losowości pojedynczego uruchomienia.

Porównanie ze starszymi modelami wymaga ostrożności. Publiczny leaderboard podawał 21,4% dla Fable 5 i 30,0% dla Opus 5. Anthropic powtórzył testy i uzyskał odpowiednio 24,7% oraz 29,0%; autorzy karty uznają różnice za mieszczące się w szumie pomiarowym. GPT-5.6 Sol ma na publicznej tablicy 22,4%, lecz działał z innym harnessem — Codexem — dlatego ranking nie izoluje wpływu samego modelu.

Axios i TechCrunch niezależnie potwierdzają premierę, strukturę dwóch wariantów oraz niezmienioną cenę bazową API. Nie dostarczają jednak osobnego powtórzenia wyniku 52,6%. Najmocniejszy zewnętrzny sprawdzian opisany w karcie przeprowadził METR na Mythos 5.1. Po dziesięciu dniach dostępu i małej serii własnych ewaluacji badacze ocenili, że model jest mocny tam, gdzie dostaje częsty, obiektywny sygnał sukcesu, ale pozostaje poniżej poziomu eksperta w zadaniach wymagających osądu badawczego. Ich zdaniem nie potrafi jeszcze niezawodnie automatyzować wielotygodniowych projektów badawczo-rozwojowych.

Co mówi dyskusja

W dyskusji na Hacker News praktycy skupili się mniej na rekordzie, a bardziej na kosztach, ograniczeniach bezpieczeństwa i jakości pracy w długich sesjach. Relacje są sprzeczne: jedni opisują mniej irytujących odmów, inni nadal trafiają na blokady; część użytkowników widzi niższy koszt dzięki cache, a część szybkie zużycie limitów. To wczesne, samoselekcyjne obserwacje bez wspólnych logów, więc nie można z nich wyliczyć typowego efektu.

Na Reddicie uwagę zwrócił inny wynik z karty: w FrontierCode maksymalny poziom wysiłku dał Fable 5.1 nieco niższy wynik łączny niż poziom średni, choć częściej kończył właściwe zadanie. Model tracił punkty za zmiany wykraczające poza zakres polecenia. To dobrze pasuje do oceny METR: więcej wykonanej pracy nie zastępuje osądu, kiedy należy przestać.

Wnioski

Skok z 24,7% do 52,6% jest zbyt duży, by sprowadzić go do błędu pomiarowego. Fable 5.1 zrobił wyraźny postęp w zadaniach naukowych, które da się zamknąć w terminalu i sprawdzić testami. Wynik nie oznacza jednak, że model samodzielnie prowadzi badania. Pokazuje sprawność w środowisku, które dostarcza narzędzia, limituje problem i rozstrzyga sukces.

Dla zespołu wdrażającego agenta praktyczna lekcja jest prosta: testować model z tym samym harnessem, uprawnieniami i poziomem wysiłku, których użyje produkcja. W zadaniach z dobrym oracle warto dać mu więcej prób. W pracy wymagającej smaku projektowego trzeba osobno mierzyć zmiany poza zakresem, koszt oraz jakość decyzji o zakończeniu pracy.

Czego jeszcze nie wiemy

Nie ma jeszcze niezależnego powtórzenia wyniku Fable 5.1 w Terminal-Bench-Science. Nie wiadomo też, jak rezultat przełoży się na wielodniowy projekt z niepełnymi wymaganiami, drogimi eksperymentami i opóźnioną informacją zwrotną. Deklarowana przez Anthropic oszczędność dzięki tańszym odczytom cache zależy od rzeczywistego wzorca użycia; nie jest obniżką podstawowej ceny tokena.

Źródła

Źródła pierwotne

Niezależne analizy i relacje

Dyskusje publiczne

Paint.NET uruchamia się przez Wine dzięki zarządzanej implementacji Direct2D

Co się wydarzyło

Paint.NET 5.2 Alpha, build 9739, dostał eksperymentalną ścieżkę uruchamiania przez Wine na Linuksie. Program nie czeka już na pełną implementację Direct2D w Wine. Zamiast niej ładuje własny, napisany od zera odpowiednik w zarządzanym kodzie z biblioteki PaintDotNet.Windows.Direct2D1.Managed.dll.

Autor Paint.NET twierdzi, że Claude napisał większość z około 180 tys. linii tej biblioteki w trzy tygodnie. Sam przejrzał zmiany integrujące komponent z aplikacją, lecz nie cały wygenerowany kod. Opisuje też konkretne błędy wykryte podczas nadzoru: brak odpowiednika AddRef() dla obiektów COM oraz złe decyzje architektoniczne. To build alfa, który według autora jest wolny, niestabilny i niegotowy do zwykłej pracy.

Co potwierdzają źródła

Oficjalne wydanie na GitHubie potwierdza datę, numer buildu, dostępność paczki portable i osobną instrukcję dla Wine. Konfiguracja wymaga co najmniej Wine 11.14, DXVK, nadpisania biblioteki d3dcompiler_47 oraz uruchomienia programu z parametrem /wine. Wcześniejszy build 9719 dodał przełączniki wyłączające niedziałające elementy animacji i kompozycji właśnie z myślą o tym porcie.

Oddzielny projekt społecznościowy Paint.NETOnWine dokumentował przeszkodę jeszcze przed premierą. Nowe wersje aplikacji mocno zależą od niedokończonych w Wine implementacji Direct2D i UIAnimation; w opisie projektu seria 5.2 nadal kończyła pracę przy starcie. Repozytorium pokazuje również, że wysiłek nie zaczął się od pojedynczej sesji z modelem: wcześniej powstawały patche Wine, skrypty uruchomieniowe i poprawki kilku ludzkich współtwórców.

Pierwsze niezależne potwierdzenie działania jest wąskie, ale konkretne. Użytkownik zgłosił w WineHQ błąd zbyt szerokiego okna narzędzi w buildzie 9739, podał wersję Wine 11.16 i sumę pobranego archiwum. To dowód, że aplikacja się uruchomiła, nie test poprawności renderowania. Chiński serwis Solidot opisał premierę i wymagane kroki instalacji, lecz nie przeprowadził własnej analizy komponentu.

Twierdzeń o 180 tys. linii, udziale Claude'a i czystej implementacji clean-room nie da się niezależnie sprawdzić. Kod Paint.NET oraz nowej biblioteki nie jest publiczny, a automatycznie dodane do wydania archiwum „source code” nie zawiera źródeł. W tych punktach mamy udokumentowaną relację autora, nie audyt.

Co mówi dyskusja

Starsze wątki użytkowników Wine i Paint.NET konsekwentnie wskazywały Direct2D oraz UIAnimation jako powód, dla którego współczesne wydania nie działają na Linuksie. Nowy build odpowiada więc na realną, wieloletnią blokadę. Bieżąca dyskusja jest jednak zbyt mała, by ocenić zgodność efektów, stabilność na różnych dystrybucjach albo wydajność.

Najważniejszy spór dotyczy sposobu weryfikacji. Autor porównuje wyniki renderowania z wersją referencyjną i testuje zachowanie aplikacji, bo ręczny przegląd 180 tys. linii jest niewykonalny. Takie testy dobrze łapią błędny obraz, ale gorzej wykrywają problemy z czasem życia obiektów, wycieki zasobów i konstrukcję, która utrudni dalsze utrzymanie. Wspomniany błąd AddRef() pokazuje dokładnie tę lukę.

Wnioski

To nie jest historia o zastąpieniu zespołu programistów jednym promptem. Człowiek wybrał architekturę, przygotował środowisko, korygował błędy i włączył komponent do istniejących 700 tys. linii aplikacji, a wcześniejsza praca społeczności rozpoznała przeszkody po stronie Wine. Agent radykalnie skrócił natomiast pracę, której autor bez takiego wsparcia nie planował wykonać.

Przypadek Paint.NET pokazuje też cenę tej prędkości. Kiedy objętość wygenerowanego kodu przekracza możliwość review, zaufanie przesuwa się na testy porównawcze, obserwowalność i ograniczony zakres wdrożenia. Etykieta „eksperymentalne” jest tu kontrolą ryzyka, a nie skromnością marketingową.

Czego jeszcze nie wiemy

Nie ma publicznych wyników zgodności z Direct2D, pomiarów wydajności ani statystyk awarii. Nie wiadomo, jaka część kodu przeszła testy, jak zostanie utrzymana oraz czy rozwiązanie trafi kiedykolwiek do stabilnego wydania. Zamknięte źródła uniemożliwiają też zewnętrzne sprawdzenie deklaracji clean-room i ryzyka licencyjnego. Pojedynczy raport z WineHQ nie wystarcza do potwierdzenia działania na szerszej grupie konfiguracji.

Źródła

Źródła pierwotne

Niezależne analizy i relacje

Solidot: Paint.NET eksperymentalnie wspiera Wine/Linux

Dyskusje publiczne

Wykorzystuję treści generowane przez AI jako część mojego codziennego procesu nauki.

Fable 5.1 osiąga 52,6% w Terminal-Bench-Science, a Paint.NET testuje 180 tys. linii bez pełnego review