Claude Opus 5.5 tworzy teledysk za jednym podejściem: co właściwie daje „Plan a Video"

Sygnał opublikowany na X 23 września 2026 r. głosi: „Plan Claude'a: wideo autorstwa Opus 5.5 za jednym podejściem”, z dołączonym wyrazem uznania dla @jeffgwoah. To twierdzenie o demo, a nie o wydaniu — i lokuje się po niewłaściwej stronie tego, co zwykle ma znaczenie. Claude Opus 5.5 nie jest niewydanym modelem, którego trzeba wytropić w przecieku. Anthropic wprowadziło go na rynek 22 września 2026 r. w cenie 4 dolarów za milion tokenów wejściowych i 20 dolarów za milion tokenów wyjściowych. Jest zaledwie dzień po premierze, jest ogólnie dostępny i już znajduje się w cenniku. Zatem interesujące pytanie nie brzmi, czy Opus 5.5 istnieje. Brzmi ono: co właściwie pokazują te posty o „wideo za jednym podejściem”, ponieważ to określenie znaczy coś węższego, niż brzmi, a różnica decyduje o tym, czy możesz z tego cokolwiek wykorzystać.

Oto krótka wersja, a to jest część, którą większość repostów pomija: w demach, które wytrzymują dokładne sprawdzenie, Claude Opus 5.5 nie generuje pikseli. Pisze kod, który maluje piksele. Wynik to program, nie plik wideo.

Co tak naprawdę robiły dwa krążące dema

Za tą klasą twierdzeń stoją dwa publiczne artefakty, a oba są sprawdzalne, ponieważ oba opublikowały swoje źródła.

Pierwszy to 156,6-sekundowy teledysk do utworu zatytułowanego „I'm Upping My P(doom)”, repozytorium o nazwie PDoomVideo opublikowane na GitHubie 22 września 2026 r. — tego samego dnia, w którym zadebiutował Opus 5.5. W jego README czytamy, że teledysk „powstał w dwóch generacjach, obu w Claude Code”, przy czym pierwsza została przypisana Claude Opus 5.5 (Medium), a druga Claude Opus 5.5 przy domyślnym poziomie wysiłku. Czytamy tam również, że „wszystko w tym repozytorium zostało wygenerowane przez model” oraz że „nie określono żadnych pomysłów na sceny” — jedynym wskazaniem było użycie konkretnego projektu postaci i nadanie każdej linijce tekstu interesujących wizualizacji i przejść.

Drugi to opublikowane 23 września 2026 r. repozytorium z demem trzech gier, które bliżej do kontrolowanego eksperymentu niż do pokazu: trzy grywalne gry 3D w przeglądarce, każda z jednozdaniowym promptem, wygenerowane w jednej sesji przy — jak opisuje repozytorium — zerowej liczbie ręcznych zmian w kodzie, a następnie wdrożone. Gry to pojedyncze pliki HTML bez zewnętrznych zasobów — modele, tekstury, animacja i dźwięk są generowane proceduralnie przez kod. Jedna z trzech wymagała, aby model wyszukał oficjalny układ mapy gry i odtworzył jej geometrię na podstawie tych poszukiwań, zanim napisał cokolwiek.

Żadne z tych repozytoriów nie jest publikacją dostawcy. Oba są artefaktami stron trzecich, deklarowanymi samodzielnie, a twierdzenie o „zerowej liczbie ręcznych zmian” w szczególności dotyczy historii gita, a nie czegoś, co poddała audytowi niezależna strona. Opis procesu traktuj jako relację autora, a same artefakty jako dowód.

Scenorys to rzeczywisty wynik.

Szczegół, który rozstrzyga, czy „one-shotted” to uczciwy opis, to plik w pierwszym repozytorium o nazwie STORYBOARD.md. To nie jest lista ujęć sporządzona przez człowieka. To dokument, który model napisał dla siebie po pierwszym przebiegu generowania, i jest naprawdę konkretny: reguła, że w każdym ujęciu „coś dzieje się na ekranie”, instrukcja, by nie umieszczać tekstu w kadrach, obsada postaci z nazwami i stałymi projektami, paleta przechodząca od ciepłego kremu przez kosmiczny fiolet do alarmowej czerwieni i z powrotem, reguła, że mimika postaci płynnie się przekształca, a nie zmienia skokowo, oraz wymóg, by każde cięcie było umotywowane akcją — ugryzienie przechodzące w czerń, upadek, najazd przez oko.

Ten dokument jest planem, na który wskazuje tekst sygnału. Model utworzył brief reżyserski, a następnie uruchomił względem niego podagentów równolegle, po jednym na rozdział, z których każdy zapisywał plik JavaScript malujący własny segment osi czasu.

Potok renderowania jest zwyczajny i warto powiedzieć to wprost, ponieważ to tutaj załamuje się narracja „AI zrobiło wideo”: klatki są malowane na stronie przy użyciu p5.js i biblioteki pędzli akwarelowych, skrypt Node steruje tą stroną w bezgłowym Chrome i wykonuje zrzut ekranu każdej klatki, a ffmpeg łączy klatki ze ścieżką audio. Przy 24 klatkach na sekundę przez 156,6 sekundy daje to około 3 760 klatek renderowanych jedna po drugiej.

Tak więc poprawne zdanie nie brzmi: „Claude Opus 5.5 wygenerował wideo”. Brzmi ono: „Claude Opus 5.5 napisał, a następnie wyreżyserował program, który renderuje wideo”. To rozróżnienie nie jest pedanterią — to cały powód, dla którego ta technika jest przydatna dla każdego, kto nie tworzy teledysku.

Dlaczego linia „dwóch generacji" ma większe znaczenie niż linia „one-shot"

Ten sam README podważa własny nagłówek. Film powstał w dwóch generacjach, nie w jednej. Pierwszy przebieg dał rezultat, który autor następnie posunął dalej; storyboard i przewodnik animacji — dokumenty, które czynią drugi przebieg spójnym — zostały napisane po tym pierwszym przebiegu, a nie przed nim.

Taki jest uczciwy kształt każdego poważnego zadania generowania o długim horyzoncie i warto to powiedzieć, ponieważ jednorazowe ujęcie tworzy oczekiwanie, którego artefakty nie spełniają. Prompt był jedną wiadomością. Praca nie była jednym przebiegiem. To, co zrobił model, polegało na tym, że utrzymał duży, wieloplikowy, wielogodzinny proces budowania w wystarczającej spójności, aby drugi przebieg był rewizją, a nie restartem — co jest prawdziwą i znacznie mniej efektowną zdolnością niż „jeden prompt, jedno wideo”.

Jest niezależna liczba, która opisuje to lepiej niż dema. Artificial Analysis zmierzyła Claude Opus 5.5 w swoim Intelligence Index na 58 przy maksymalnym wysiłku — najwyższy wynik, jaki odnotowała, o kilka punktów wyprzedzający kolejne modele — i podała, że model zużywa około 119 000 tokenów wyjściowych na zadanie w Indexie, wobec około 73 000 w przypadku Claude Opus 5 i około 78 000 w przypadku Claude Fable 5.1. Zużywa około 1,6 razy więcej tokenów wyjściowych, a koszt na zadanie pozostaje w przybliżeniu taki sam (~5,98 USD wobec ~5,86 USD), mimo o 20% niższej ceny za token. Generowanie długiego horyzontu to właśnie tak wygląda z zewnątrz ten profil tokenów: model wydaje budżet na samego siebie.

Gdzie artefakty przestają być użyteczne

Tryby awarii w tego rodzaju pracy są spójne, a oba repozytoria z różnych kierunków wskazują na to samo.

• Wynikiem jest program, a nie plik. Jeśli potrzebujesz pliku MP4, który możesz komuś przekazać, nadal potrzebujesz Node'a, przeglądarki i ffmpeg. Model wytworzył renderer, a nie render. To zależność kompilacyjna, którą będziesz utrzymywać już na zawsze.

• Skaluje się wraz z liczbą klatek, a nie z promptami. 3760 klatek zajęło skryptowy przebieg przez noc na sprzęcie autora. Nic w Opus 5.5 nie zmienia kosztu wygenerowania klatki numer 2000.

• Determinizm jest wymogiem, a nie miłym dodatkiem. Klatki renderują się równolegle i poza kolejnością, więc każda klatka musi być czystą funkcją swojego znacznika czasu — bez przenoszonego stanu, bez losowości bez ziarna. Model, który tego nie przyswoił, tworzy wideo, które migocze. Oba repozytoria sobie z tym radzą; nic w prompcie tego nie wymusza.

• One-shot nie oznacza bez audytu. Najlepszym dowodem jest praca nad grą w drugim repozytorium: model musiał zbadać układ istniejącej mapy, zanim ją zbudował, co oznacza, że sam uznał, iż jego pierwsza odpowiedź byłaby błędna.

• Nikt nie wycenił porażki.Żadne z repozytoriów nie podaje, ile prób wymagało, ile tokenów spaliło ani ile z drugiej generacji poświęcono na poprawianie pierwszej. To liczba, której zespół faktycznie potrzebuje, zanim się zobowiąże.

Co to dla ciebie zmienia, a co nie

Jeśli liczyłeś na model do generowania wideo, Claude Opus 5.5 nim nie jest, a żadna ilość nagrań demonstracyjnych nie sprawi, że nim będzie. Materiał premierowy Anthropic nie zawiera możliwości generowania wideo; opublikowane ewaluacje modelu dotyczą programowania agentowego, korzystania z komputera i pracy opartej na wiedzy. To, co pokazują dema, to długohoryzontowe generowanie kodu na podstawie kreatywnego briefu — ta sama zdolność, która pojawia się w migracji 680 000 linii i w porcie z C na Rust, które Anthropic cytuje we własnym wpisie premierowym, tylko skierowana na coś, co można obejrzeć.

Jeśli to jest zdolność, której chcesz, praktyczne pytanie przestaje brzmieć „który model?”, a zaczyna: „jak uruchomić coś takiego, nie angażując w to ścieżki produkcyjnej?”. Generowanie w długim horyzoncie jest kosztowne, a jego tryb awarii jest cichy — dostajesz wiarygodnie wyglądający program, który renderuje się przez cztery minuty, a potem się psuje. Rozsądnym sposobem przetestowania tego jest skierowanie pracy przez endpoint, który już masz, a nie przez nowy kontrakt: Opus 5.5 jest dostępny w OrcaRouter w cenie katalogowej Anthropic z 0% narzutu, obok pozostałych modeli z rodziny, więc nocne uruchomienie generowania może opierać się na tym samym kluczu i tych samych regułach przełączania awaryjnego co wszystko inne, co wywołujesz. Jeśli uruchomienie padnie na klatce 3000, to problem routingu, a nie przebudowa architektury.

Dwie rzeczy warto mieć na oku, zanim zaczniesz to planować. Anthropic zapowiedziało, że Sonnet 5.5 i Haiku 5.5 pojawią się „w nadchodzących tygodniach”, co zmieni kalkulację przy długim renderze — tańszy model, który potrafi utrzymać spójność wieloplikowej budowy, sprawiłby, że nocny przebieg stałby się rutyną, a nie czymś godnym uwagi. A sam wzorzec storyboardu jest przenośny: nic w tym dokumencie nie jest specyficzne dla Opus 5.5 i nic nie stoi na przeszkodzie, by mniejszy model napisał gorszy.

Na razie uczciwa interpretacja „Claude's Plan a video by opus 5.5 one shotted” jest węższa, niż to brzmi, i bardziej użyteczna, niż wygląda. Model napisał listę ujęć, poinstruował własnych podagentów, a potem napisał renderer — a fakt, że taki plan przetrwał zetknięcie z 3,760 klatkami, jest tezą wartą sprawdzenia, nie samo wideo.