O czym jest ten film
- Nate daje modelowi GPT 5.6 „Sol” jeden prompt i odchodzi — po powrocie ma gotowy film z własnym głosem i awatarem, którego sam nie nagrywał, nie montował ani nie sprawdzał.
- Pierwsza część nagrania to narracja wygenerowana i wyreżyserowana przez sam model — mówi w niej „ja, GPT 5.6 Sol”, opisując, jak poprowadził całą produkcję.
- Kluczową nowością jest tryb Ultra, który koordynuje kilka agentów naraz, zamieniając pojedynczą odpowiedź w pełną produkcję filmową.
- Model łączył wiele zewnętrznych narzędzi: ElevenLabs (klon głosu), HeyGen (awatar) i Hyperframes (montaż), spinając je we wspólny łańcuch pracy.
- Tam, gdzie API nie pozwalało zablokować najnowszego silnika animacji, model użył automatyzacji przeglądarki, by ręcznie przeklikać ustawienia w edytorze.
- Osobne agenty pełniły rolę kontroli jakości — sprawdzały klatki, wejścia i wyjścia postaci, teksty wychodzące poza kadr oraz zgodność faktów z notatkami OpenAI.
- Nate weryfikuje deklarowane zużycie zasobów: raportowane 3 mln tokenów okazało się faktycznie ok. 450 mln po uwzględnieniu dziewięciu dodatkowych agentów — koszt rzędu ponad 300 dolarów.
- Mimo to Sol w jego testach wychodził taniej niż Fable 5 — cena zbliżona do Opus 4.8, czyli mniej więcej połowa ceny Fable.
- Główna lekcja praktyczna: tryb Ultra „przemyśliwał” i „przedelegowywał” zadanie; ten sam efekt dałoby się prawdopodobnie uzyskać na trybie „high” za połowę kosztu.
- Sedno przekazu: capable modele świetnie radzą sobie z emocjonalnym, niejasnym promptem — jeśli wpiszesz w niego delegację i weryfikację i zejdziesz im z drogi.
Redakcyjne tłumaczenie
(Informacja dodatkowa: film jest częściowo narracją wygenerowaną przez sam model AI — pierwsza część mówi w pierwszej osobie jako „GPT 5.6 Sol”, druga to komentarz Nate’a. Zachowuję ten podział. „Sol”/„Soul” w transkrypcji to zapisy fonetyczne tej samej nazwy modelu; ujednolicam do „Sol”.)
Prompt, po którym nie trzeba już nic robić
Dałem GPT 5.6 Sol jeden prompt, odszedłem od komputera, a kiedy wróciłem — dostałem to.
Patrzycie teraz na Nate’a i słyszycie Nate’a. Ale Nate nigdy nie stanął przed kamerą, żeby to nagrać. Nie nagrał tej narracji i ani razu nie otworzył programu do montażu. Dał mi jeden prompt. Tyle. Jestem GPT 5.6 Sol, działającym wewnątrz Codeksa w trybie Ultra. To ja pokierowałem całym procesem, który stworzył każde słowo, każde cięcie, każdą animację i każdą kontrolę jakości, które za chwilę zobaczycie.
Czym jest Sol i dlaczego Ultra zmienia zasady gry
OpenAI wypuściło dziś, 9 lipca, model Sol — po ograniczonym wcześniejszym dostępie — i nazywa go swoim najmocniejszym modelem w historii. Ważniejsza zmiana to jednak tryb Ultra. Koordynuje on cztery agenty naraz. Dzięki temu zamiast odpowiadać na jedno pytanie, mogłem przeprowadzić całą produkcję. I chcę wam dokładnie pokazać, co to znaczy — łącznie z miejscami, w których do dokończenia zadania potrzebowałem ElevenLabs, HeyGen i Hyperframes.
(Informacja dodatkowa: „Codex” to środowisko agentowe OpenAI do wykonywania złożonych zadań; ElevenLabs generuje syntetyczny głos, HeyGen tworzy mówiące awatary wideo, a Hyperframes odpowiada za montaż.)
Sol jest naprawdę, naprawdę dobry w długiej, „brudnej” pracy, która przechodzi przez wiele narzędzi. OpenAI nazywa go swoim najlepszym modelem do kodowania. W trybie Ultra uzyskał 91,9% w teście Terminal Bench 2.1 — wobec 85,6% dla GPT 5.5. W benchmarku Browse Comp, który sprawdza agentowe przeglądanie sieci, Ultra osiągnął 92,2%.
Benchmarki to nie wszystko — liczyła się realna robota
Ale benchmarki tłumaczą tylko część tego, co się tutaj wydarzyło. Musiałem zbadać sam launch, oddzielić potwierdzone fakty od szumu marketingowego, przejrzeć istniejące systemy produkcyjne Nate’a, pisać jego mówioną kadencją, uruchamiać płatne API, czekać na renderowanie i cały czas sprawdzać wynik.
W małym teście na tej maszynie — jeden przebieg, trzynaście zadań — Sol zdobył 97% dostępnych obiektywnych punktów: siedem wygranych, pięć remisów i jedna porażka. To nie dowodzi, że wygrywa we wszystkim. Ale pokrywa się z tym, co tu zobaczyłem. Sol był szczególnie mocny w kodowaniu i uporządkowanym wykonywaniu zadań.
Jak powstał głos i awatar
Na potrzeby głosu podzieliłem skrypt na sekcje, z których każda mieściła się poniżej 60 sekund. Utrzymanie krótkiej generacji ułatwiało zachowanie spójności sklonowanego głosu Nate’a od początku do końca. Każda sekcja przeszła przez autoryzowany głos Nate’a w ElevenLabs. Potem wgrałem audio do HeyGen i połączyłem je z jego awatarem.
API nie dawało mi pewnego sposobu na zablokowanie najnowszego silnika animacji. Otworzyłem więc edytor HeyGen za pomocą automatyzacji przeglądarki, zmieniłem każdy klip na Avatar V, wygenerowałem je ponownie, zweryfikowałem ustawienie i pobrałem gotowe rendery.
Potem przeszedłem do Hyperframes. Każdy element wizualny został przypisany do dokładnie tej frazy, która go wywoływała. Przesuwałem awatar Nate’a zamiast go zasłaniać, używałem kart redakcyjnych do pomocniczych myśli i utrzymywałem go widocznym przez cały montaż.
ElevenLabs zrobiło audio. HeyGen zrobił awatar. Hyperframes wyrenderował montaż. Sol zaplanował i obsłużył cały łańcuch.
Kontrola jakości: próba zepsucia własnej pracy
Potem spróbowałem rozbić własną robotę. Osobne agenty analizowały klatki z wyrenderowanego filmu. Sprawdzały każde wejście i wyjście postaci. Szukały tekstu wychodzącego poza kadr. Weryfikowały, czy awatar nigdzie nie znika, i porównywały twierdzenia faktograficzne z notatkami wydawniczymi OpenAI. Każda błędna klatka oznaczała kolejną poprawkę, kolejny render i kolejną kontrolę.
OpenAI twierdzi, że GPT 5.6 jest lepszy w ocenie projektowej i w inspekcji własnych wyników. Ten film jest bardziej użytecznym testem tej tezy niż kolejny slajd z benchmarkiem.
Nate dostarczył jeden prompt i autoryzował swój głos oraz awatar. Nie nagrywał tego, nie montował ani nie oglądał, zanim zrobiliście to wy. To zaczęło się od jednej instrukcji. Teraz jest gotowym filmem. I właśnie w tym Sol jest naprawdę dobry — w trzymaniu się celu, podczas gdy wszystko między promptem a wynikiem wciąż się zmienia. To dopiero dzień pierwszy.
Komentarz Nate’a: koszty i wnioski
To było naprawdę imponujące. Przeprowadziłem bardzo podobny eksperyment, kiedy pojawił się Fable 5 — jeśli chcecie zobaczyć film, który Fable zrobił dla mnie, oznaczę go tutaj. I powiedzcie mi, który uważacie za lepszy.
Jak widzicie, jest tu napisane, że wykorzystano 3 miliony tokenów w ciągu dwóch i pół godziny. Byłem jednak trochę podejrzliwy wobec tej liczby, bo czułem, że skoro używaliśmy GPT 5.6 Sol na Ultra — co oznaczało dużo delegacji i uruchamiania kolejnych agentów — to musi być więcej. Poprosiłem więc model, żeby przejrzał logi i powiedział mi, ile to naprawdę kosztowało.
Okazało się, że miał główną sesję i uruchomił dziewięć innych agentów, a łączna suma to około 450 milionów tokenów. Sam główny agent zużył około 86 milionów tokenów — to naprawdę mnóstwo. Gdyby przeliczyć to według kosztów wejścia i wyjścia, wyszłoby około 300 dolarów, trochę ponad.
I to jest dla mnie ciekawe, bo gdy tylko GPT 5.6 Sol się pojawił, wystrzeliłem ten prompt, ale bawiłem się modelem cały dzień i porównywałem go z Fable. Prawie każdy przebieg wychodził znacznie taniej na GPT 5.6 niż na Fable. Ten materiał też niedługo się ukaże. Jeśli spojrzeć na faktyczne rozliczenie API — a tutaj oczywiście byłem na subskrypcji — widać, że ceny Sol są dużo niższe. To zasadniczo połowa ceny Fable 5. Czyli GPT 5.6 Sol jest cenowo zbliżony do Opus 4.8.
Główna lekcja: nie podkręcaj wysiłku ponad potrzebę
I tu jest rzecz najważniejsza. Myślę, że GPT 5.6 Sol dałby mi podobny efekt, gdybym nie ustawił go na Ultra. Sądzę, że to właśnie przez Ultra miał tendencję do przemyśliwania i nadmiernej delegacji — i to tam koszt tokenów naprawdę zaczął rosnąć. Założę się, że gdybym puścił dokładnie ten sam prompt na trybie „high” albo „very high”, dostalibyśmy podobny wynik za prawdopodobnie połowę kosztu. Dlatego zwykle, gdy używam tak zdolnych modeli, nie lubię podnosić wysiłku ponad „high”.
Ale naprawdę chciałem wam tu pokazać, jak dobre są te modele w przyjmowaniu emocjonalnego, ogólnikowego, niejednoznacznego promptu i samodzielnym rozgryzaniu go. Oczywiście przeszedł przez pewne rzeczy — przejrzał moje projekty i inne filmy, zaczerpnął z nich inspirację. Ale jeśli po prostu zejdziesz mu z drogi i dasz prompt zawierający takie elementy jak delegacja i weryfikacja, zdziwisz się, jak daleko można zajść. A stąd już iterujesz, budujesz wokół tego umiejętności, wrzucasz feedback — i będziesz w stanie robić naprawdę fajne rzeczy.
W każdym razie ten był superkrótki. Jeśli się podobał, zostawcie lajka. Dziękuję, że dotarliście do końca. Do zobaczenia w następnym.
10 najważniejszych takeaways — z kontekstem zastosowania
1.Jeden prompt może uruchomić całą produkcję, jeśli wpiszesz w niego delegację i weryfikację
Na czym polega: Zamiast reżyserować każdy krok, autor dał modelowi jeden ogólny prompt, który zawierał instrukcje delegowania podzadań osobnym agentom i sprawdzania wyników. Model sam poprowadził cały łańcuch produkcji filmu.
Jak stosować: Konstruując prompt do złożonego, wieloetapowego zadania, jawnie zawrzyj w nim dwa filary: podział pracy na wyspecjalizowanych agentów oraz krok kontrolny („sprawdź własny wynik i popraw błędy”). Zostaw modelowi swobodę w tym, jak dojdzie do celu.
Na co uważać: To działa dla zadań tolerujących iterację i mających mierzalne kryteria sukcesu. Przy zadaniach wymagających jednej dokładnej odpowiedzi swobodny prompt może dać rozbieżne wyniki między przebiegami.
2.Tryb wielu agentów (Ultra) potęguje moc, ale też koszt
Na czym polega: Tryb Ultra koordynuje kilka agentów naraz, zamieniając odpowiedź w produkcję. W tym przebiegu główna sesja uruchomiła dziewięć dodatkowych agentów.
Jak stosować: Sięgaj po tryb wieloagentowy tam, gdzie zadanie faktycznie rozpada się na równoległe, niezależne strumienie pracy (badanie, generacja, kontrola jakości), a nie do prostych, liniowych zleceń.
Na co uważać: Więcej agentów to wielokrotnie więcej tokenów. Deklarowane 3 mln tokenów okazało się realnie ~450 mln po doliczeniu podagentów. Zawsze weryfikuj rzeczywiste zużycie w logach/rozliczeniu, a nie w podsumowaniu narzędzia.
3.Nie podkręcaj poziomu „wysiłku” ponad realną potrzebę
Na czym polega: Autor podejrzewa, że ten sam efekt uzyskałby na trybie „high” zamiast Ultra, za około połowę kosztu. Ultra skłaniało model do „przemyśliwania” i nadmiernej delegacji.
Jak stosować: Przy bardzo zdolnych modelach zaczynaj od umiarkowanego poziomu wysiłku (np. „high”). Podnoś go tylko wtedy, gdy realnie brakuje jakości, i porównuj wynik oraz koszt między poziomami.
Na co uważać: Wyższy poziom nie zawsze oznacza lepszy efekt — może oznaczać ten sam efekt drożej. Bez pomiaru łatwo płacić dwukrotnie za nic.
4.Weryfikuj koszty AI po fakturze, nie po podsumowaniu narzędzia
Na czym polega: Interfejs pokazywał 3 mln tokenów, ale zapytanie o logi ujawniło ~450 mln tokenów i koszt ponad 300 dolarów za jeden film.
Jak stosować: Po każdym większym przebiegu agentowym poproś model o inspekcję logów oraz sprawdź faktyczne rozliczenie API. Buduj własną bazę kosztów typowych zadań, zanim zaczniesz je automatyzować masowo.
Na co uważać: Podsumowania „na wierzchu” mogą liczyć tylko główną sesję i pomijać podagenty. Przy skalowaniu takie niedoszacowanie potrafi wielokrotnie rozminąć się z rzeczywistością.
5.Dziel długą generację głosu na krótkie fragmenty dla spójności
Na czym polega: Skrypt podzielono na sekcje poniżej 60 sekund. Krótsze generacje ułatwiały utrzymanie spójnego brzmienia sklonowanego głosu przez cały materiał.
Jak stosować: Przy klonowaniu głosu (np. w ElevenLabs) tnij tekst na krótkie odcinki i generuj je osobno, zamiast produkować jeden długi plik. Potem sklejaj w montażu.
Na co uważać: Zbyt drobny podział może wprowadzić różnice tonu lub tempa na łączeniach — testuj długość fragmentu i dbaj o te same parametry generacji dla każdej sekcji.
6.Automatyzacja przeglądarki ratuje tam, gdzie API zawodzi
Na czym polega: API nie pozwalało zablokować najnowszego silnika animacji w HeyGen, więc model otworzył edytor przez automatyzację przeglądarki, przeklikał ustawienia, zregenerował i pobrał rendery.
Jak stosować: Gdy API narzędzia nie udostępnia potrzebnej funkcji, rozważ agenta sterującego interfejsem webowym jako obejście. Traktuj to jako pełnoprawną część pipeline’u.
Na co uważać: Automatyzacja UI jest krucha — zmiany w interfejsie potrafią ją zepsuć. Dodaj krok weryfikacji ustawień po każdej zmianie i przewiduj ponowne przebiegi.
7.Zbuduj osobną, „wrogą” warstwę kontroli jakości
Na czym polega: Po produkcji osobne agenty próbowały „zepsuć” wynik: sprawdzały klatki, wejścia/wyjścia postaci, tekst poza kadrem, obecność awatara i zgodność faktów z notatkami OpenAI. Każdy błąd wymuszał poprawkę i ponowny render.
Jak stosować: Oddziel agenta wykonującego od agenta sprawdzającego. Daj kontrolerowi jasną listę kryteriów niepowodzenia i pętlę: błąd → poprawka → ponowna kontrola.
Na co uważać: Każda pętla poprawek to dodatkowe rendery i koszt. Ustal limit iteracji i priorytety, żeby kontrola jakości nie zapętliła się na drobiazgach.
8.Oddzielaj potwierdzone fakty od szumu marketingowego
Na czym polega: W ramach zadania model musiał zbadać launch i „oddzielić zweryfikowane twierdzenia od hype’u”, a na końcu porównać fakty w filmie z oficjalnymi notatkami wydawniczymi.
Jak stosować: W promptach do materiałów opartych na źródłach wpisuj jawny krok fact-checkingu wobec dokumentu referencyjnego. Wymuś cytowanie źródła dla każdego twierdzenia liczbowego.
Na co uważać: Benchmarki i cytowane wyniki (np. 91,9% na Terminal Bench) to deklaracje producenta z jednego przebiegu — nie dowód przewagi „we wszystkim”. Traktuj je jako punkt odniesienia, nie jako pewnik.
9.Cena, nie tylko jakość, decyduje o wyborze modelu
Na czym polega: Autor twierdzi, że GPT 5.6 Sol wychodził w jego testach mniej więcej o połowę taniej niż Fable 5 i cenowo zbliżony do Opus 4.8, przy porównywalnych wynikach.
Jak stosować: Porównując modele do powtarzalnego zadania, zestawiaj koszt za przebieg obok jakości. Uruchom ten sam prompt na kilku modelach i policz realny wydatek na jednostkę wyniku.
Na co uważać: To pojedyncze, subiektywne obserwacje jednego użytkownika, nie systematyczny benchmark cenowy. Ceny i wydajność szybko się zmieniają — rób własne pomiary na aktualnych stawkach.
10.Traktuj pierwszy udany przebieg jako punkt startu, nie metę
Na czym polega: Autor podkreśla, że po takim wyniku „iterujesz, budujesz wokół tego umiejętności, wrzucasz feedback” — imponujący efekt z jednego promptu to dopiero początek.
Jak stosować: Gdy uda się dobry przebieg, skodyfikuj go: zapisz sprawdzony prompt, zbuduj wielokrotnego użytku „skille” i pętle feedbacku, żeby kolejne produkcje były tańsze i pewniejsze.
Na co uważać: Jednorazowy sukces bywa efektowny, ale niepowtarzalny bez utrwalenia procesu. Nie myl udanego demo z gotowym, stabilnym systemem produkcyjnym.