I Tested GPT 5.6 Sol vs Fable 5. What You Need To Know.

O czym jest ten film

1. Autor przez cały dzień testował obok siebie dwa modele — GPT 5.6 Sol (przez Codex) i Fable 5 (przez Claude Code) — na realnych zadaniach, zamiast tylko cytować benchmarki.
2. W trzech „ślepych” testach kreatywnych (gra rowerowa, efektowna strona, pięć różnych elementów wizualnych) porównał jakość, czas i koszt każdego modelu.
3. W dwóch pierwszych testach jako lepszy wyszedł Fable 5, mimo że kosztował wielokrotnie więcej; w trzecim autor przyznał punkt Solowi za różnorodność pomysłów.
4. Sol jest dramatycznie tańszy i znacznie bardziej oszczędny w tokenach — często kilkanaście–dwadzieścia razy tańszy w zadaniach agentowych.
5. W szybkich zapytaniach jednorazowych przez API Sol wygrał 24 do 3, ale głównie dlatego, że Fable wielokrotnie odmawiał odpowiedzi; przy faktycznie udzielonych odpowiedziach jakość obu była niemal równa.
6. Autor pokazuje różnicę w wielkości „przewagi kosztowej”: przy API luka jest niewielka, przy pracy agentowej — bardzo duża.
7. Główna teza: Fable to lepszy „menedżer” i strateg, Sol to bardzo dobry „wykonawca” — idealnie sprawdziłby się układ, w którym Fable orkiestruje wielu agentów Sol.
8. Mocne strony Sola: cena, obsługa komputera (computer use), szybkość, ostrożna weryfikacja i wyłapywanie błędów.
9. Mocne strony Fable: kreatywność, pisanie, doradztwo strategiczne, mniejsza skłonność do nadinżynierii, wyższa „czysta” jakość.
10. Wniosek praktyczny: dobór modelu to kwestia zadania i „wyczucia” — do prostszych, powtarzalnych zadań wystarczy tańszy Sol, do trudnej pracy koncepcyjnej autor wciąż wybiera Fable.

Redakcyjne tłumaczenie

(Informacja dodatkowa: film jest hands-onowym porównaniem modeli. „Sol”, „Terra” i „Luna” to warianty rodziny GPT 5.6; „Fable 5” to konkurencyjny model najwyższej klasy. Autor testuje modele przez dwa środowiska agentowe: Codex uruchamia GPT 5.6 Sol, a Claude Code uruchamia Fable 5.)

Wstęp: benchmarki to za mało

Mamy wreszcie GPT 5.6 Sol, a wraz z nim warianty Terra i Luna. Benchmarki są imponujące — pokazują, że Sol wyraźnie wyprzedza Opusa i Fable, a przy tym jest znacznie tańszy. Pokażę kilka z nich na ekranie, ale nie chcę zatrzymywać się na samych benchmarkach, bo to według mnie nudne. Cały dzień bawiłem się tymi modelami, stawiałem je obok siebie — GPT 5.6 i Fable 5 — i prowadziłem na nich swoją codzienną pracę. Dzięki temu mogę powiedzieć, który model wolę do jakich zastosowań i dlaczego.

Zanim przejdziemy dalej — sama strona startowa premiery jest naprawdę udana. Podobają mi się planety Sol, Terra i Luna w tle, a wewnątrz nich dryfują małe „piątki” i „szóstki”. Ładny detal. Ale przejdźmy do tego, co faktycznie dziś robiłem.

Przeprowadzę was przez moje eksperymenty, a na końcu omówię wady i zalety każdego modelu oraz mój ogólny werdykt.

Test 1: grywalna gra rowerowa w przeglądarce

Po lewej mam Claude’a z Fable 5, po prawej Codex z GPT 5.6 Sol. Dałem obu dokładnie ten sam prompt: zbuduj naprawdę fajną, grywalną grę o rowerze w otwartym świecie, działającą w przeglądarce. Dorzuciłem kilka zasad, ale dałem im też pełną swobodę twórczą. Nie mówię wam, która wersja jest która — najpierw zobaczymy obie, potem odkryję karty.

Pierwsza wersja: sterowanie WD, spacja do bunny hopa, Q i E do trików w powietrzu, shift do przyspieszenia. Wskakujemy. Da się poruszać, mamy miasto. Kamera jest trochę trudna w obsłudze, widok z góry (z lotu ptaka) nieszczególnie mi się podoba i sterowanie bywa niewygodne. Ale od strony funkcjonalnej działa nieźle: monety zbierają się, sterowanie działa, przeskoczyłem właśnie budynek, bunny hop jest. Wygląda całkiem znośnie jak na czas, w jakim to powstało.

Druga wersja ma podobne sterowanie, ale to bardziej styl 3D, prawie widok z perspektywy pierwszej osoby. Mogę skakać, obracać się. Jestem w mieście, mam monety, próbuję wjechać na rampę — no, wjechałem z niewłaściwej strony. Ta wersja ma bardziej klimat gry pokroju GTA — otwarty świat, który da się eksplorować, mapa wydaje się znacznie większa. To zdecydowanie zwycięzca.

Zwycięska druga wersja to Fable 5 (po lewej). Zajęła 21 minut i 37 sekund, podczas gdy GPT Sol — 23 minuty. Czasowo podobnie. Ale koszt: uruchomienie Fable to około 14,22 dolara, a Sol — 4,50 dolara. Najciekawsze są tokeny wyjściowe: Fable wygenerował około 90 tysięcy, a Sol tylko około 31 tysięcy. Konsekwentnie widać, że Codex i GPT są znacznie oszczędniejsze w tokenach — czasem to zaleta, czasem nie. Tutaj uważam, że oszczędność zaszkodziła, bo wynik Fable był nie tylko trochę, ale znacząco lepszy.

Test 2: efektowna, interaktywna strona internetowa

Drugie zadanie: „zbuduj najbardziej efektowną, interaktywną, zatrzymującą przewijanie stronę, jaką potrafisz sobie wyobrazić”. Znów pełna swoboda twórcza. Obie wersje mają dźwięk.

Pierwsza wersja to „10 miliardów lat” — przewijając w dół, przechodzimy przez swego rodzaju podróż, a całe tło jest interaktywne i trójwymiarowe, reaguje na ruch myszy. Zaczynamy od chmury, potem kolaps, kosmiczne, galaktyczne efekty 3D, opowiadające historię tego, jak doszliśmy do miejsca, w którym jesteśmy. Potem pierwsze światło, pęcznienie gwiazdy, kończy się paliwo, wielki huk supernowej (z mocnym dźwiękiem) — aż docieramy na sam koniec, do „nas”. Bardzo efektowne.

Druga wersja to „Vesper archive” — podobny pomysł, z dźwiękiem, trójwymiarowym interaktywnym tłem i opowiadaną historią. Obie są niezłe, ale pierwsza ma zdecydowanie więcej efektu „wow”, jest bardziej wciągająca. Druga ładnie opowiada historię i ma ciekawe rozwiązania, ale pierwsza jest po prostu na innym poziomie.

Pierwsza wersja to Fable — i znów zrobił lepszą robotę. Fable zajął 23 minuty, a Sol niecałe 7 minut. Koszt: Fable — 19,24 dolara przy 80 tysiącach tokenów wyjściowych, Sol — nieco ponad dolara przy 20 tysiącach tokenów. Nasuwa się pytanie: gdyby Sol pracował na tyle długo, by wydać tyle co Fable, czy jego wynik byłby równie dobry, a może lepszy? Być może. Sol jest znacznie tańszy, a do tego z zasady zużywa mniej tokenów — pewnie przez środowisko (harness) i sposób trenowania. To była różnica prawie dwudziestokrotna na korzyść portfela. Pytanie brzmi: czy wynik Fable był dwudziestokrotnie lepszy? Nie sądzę. Ale skoro oceniam czystą jakość, i tu wybrałbym wynik Fable.

Test 3: pięć fundamentalnie różnych elementów wizualnych

Trzeci eksperyment jest ciekawy. Prompt: „zaprojektuj mi pięć fundamentalnie różnych elementów wizualnych” — mogą być gry, prezentacje, strony, symulacje, cokolwiek. Chciałem zobaczyć, co model zrobi z bardzo niejednoznacznym poleceniem. Tym razem od razu mówię, co jest czym: pierwsza wersja to Fable, druga to Sol. Każdy wygenerował jedną stronę-galerię z pięcioma osobnymi „światami”.

Fable — „Galeria. Pięć samodzielnych światów”:

• „Singularity” — niejasne: przesuwaj, by zakrzywić czasoprzestrzeń, przytrzymaj, by karmić, spacja detonuje. Nacisnąłem spację i coś wysadziłem. Nie do końca wiadomo, o co chodzi.
• „Terra” — coś w rodzaju symulatora lotu: sterowanie myszą, W/S przyspiesza i zwalnia, można zmieniać porę dnia. Fizyka niezła, choć renderowanie jest trochę dziwne. W porządku jak na spontaniczny pomysł.
• „Orbit” — gra zręcznościowa: dwa pierścienie, jedno wejście, klikasz, by przełączać pierścienie, zbierasz monety i unikasz przeszkód. Gra się płynnie i responsywnie, ale jest błąd: menu nie znika w trakcie rozgrywki.
• „Inkflow” — klikasz po nowy element, zmieniasz paletę, zapisujesz jako PNG. Trochę losowy gadżet.
• „The Descent” — interaktywna historia: przewijasz od oświetlonej słońcem powierzchni w głąb oceanu, zmienia się tło, mijamy stworzenia, schodzimy głębiej niż Titanic, zmieniają się ciśnienie, światło i temperatura. Kolejna „podróż”.

Podsumowując Fable: nic przytłaczająco imponującego.

Sol — „Impossible objects. Pięć małych światów, bez frameworków” (już na pierwszy rzut oka wygląda lepiej, a wręcz — co zabawne — jak wynik zaprojektowany przez Claude’a):

• „Aurora Orchestra” — zabawa zorzą polarną: zmieniasz głos, niebo, przytrzymujesz dla intensywności, zmieniasz kolor zorzy. Część opcji (trzy i cztery, a potem także jeden i dwa) przestaje działać — błąd.
• „Atlas of Lost Echoes” — mapa, kursor wskazuje północ, klikasz miejsca („Sleeping Sea”), zbierasz pięć „ech”. Po zebraniu: „Atlas complete. Keep exploring”. Nie do końca czytelne, o co chodzi.
• „The Glyph Heist” — gra w pisanie: siatka ukrywa „przemycane słowa”, trzeba je wpisać, zanim namierzy cię system. Punkty w lewym górnym rogu, ale mało czytelny feedback, część „słów” to nie słowa (chyba celowo, by zmylić). Ładny klimat i estetyka, ale bugi: nie wiadomo, jak się traci i jak gra się kończy, a wynik „high score” był już wcześniej ustawiony.
• Talia slajdów — pięć slajdów, całkiem dobrze zaprojektowanych. Znów wygląda jak coś, co wygenerowałby Claude — czcionka i kolorystyka mają ten charakter.
• „Tide pool” — symulacja: „życie czeka, dotknij wody, by zacząć”. Wrzucam nasiona, populacja 320, różnorodność 2, mogę dać słońce albo świeży deszcz. Zaczyna spowalniać komputer, ale symulacje podobają mi się najbardziej.

Tu naprawdę nie wiem, komu przyznać koronę. Chyba jednak Solowi — bo miał ogólnie lepsze wyczucie różnorodności i doświadczenia użytkownika. Ciekawy jest czas i koszt: myślałem, że przy „pięciu bardzo różnych rzeczach” ten test potrwa najdłużej, może pięć razy dłużej niż poprzednie. Tymczasem był najszybszy z wszystkich. Fable — 15 minut, Sol — 7 minut. Koszt: Fable około 15 dolarów przy 65 tysiącach tokenów wyjściowych, Sol znów około dolara przy 22 tysiącach tokenów.

Testy przez API: szybkie zapytania jednorazowe

Eksperymenty agentowe (Claude Code i Codex) to jedno — i tak zwykle będę używał tych modeli. Ale chciałem też porozmawiać z modelami wprost przez API. To były głównie zapytania „na jeden strzał”: „co to jest, daj odpowiedź”, a nie wieloetapowe pętle rozumowania.

Wynik jest ciekawy: Sol wygrał 24 razy, Fable trzy razy. Wielokrotnie jednak Fable po prostu odmawiał odpowiedzi — nie przesyłał jej wcale. Odmawiał, co jest o tyle interesujące, że zabezpieczenia (guardrails) są w nim wpieczone bardzo mocno. Spójrzmy też na koszt: przy tych krótkich zadaniach Sol wygrał 24 do 3, a kosztował 16 dolarów, podczas gdy Fable 63 dolary.

Ale co do samej zdolności — kiedy Fable faktycznie odpowiadał, było dość równo. Sol zdominował głównie dlatego, że Fable często nie odpowiadał. Wynik „przy udzielonej odpowiedzi”: Sol 0,98, Fable 0,966. To bardzo podobne modele i idealny przykład ekonomiki jednostkowej zadania. Załóżmy, że zadanie ma trudność 5. Czy potrzebujesz modelu na 10? Raczej nie — wystarczy model na 5 albo 6. Przy szybkich, prawdopodobnie bezstanowych zapytaniach API Sol miażdży Fable. A od strony tokenów wejścia/wyjścia Sol kosztuje mniej więcej połowę tego co Fable.

Jeśli porównać Sola z Opusem 4.8, są niemal identyczni — tyle samo na wejściu i bardzo podobnie na wyjściu. To dla mnie ciekawe: uczciwszym pojedynkiem byłoby Sol 5.6 kontra Opus 4.8, a nie Sol 5.6 kontra Fable 5. Uważam, że to nie modele z tej samej półki jako modele nowej generacji.

(Informacja dodatkowa: autor spekuluje o nazewnictwie — dlaczego „5.6”, a nie pełne „6”.) Fable przeskoczył do „piątki”. Sol, rzekomo ich najbardziej zdolny model, dostał tylko oznaczenie 5.6 — dlaczego nie Sol 6? Skoro miałby być tak dobry, czy nie zasługiwałby na pełny krok wyżej? To każe się zastanawiać, co jeszcze przygotowują i co być może szykują jako następcę — prawdziwe GPT 6. Bo dopiero wtedy, moim zdaniem, dostaniemy model, który faktycznie stanie w szranki z Fable. Dziś uważam, że Sol tego nie robi.

Wielkość przewagi kosztowej: API kontra praca agentowa

Przy wyniku ogólnym Sol wygrał, przy wyniku „gdy odpowiedział” było znacznie bliżej — to kwestia niezawodności. Po stronie kosztów wywołań API Sol był tańszy (około 9 dolarów wobec około 14). Co ciekawe, luka nie jest tu duża — około pięciu dolarów, a procentowo jeszcze mniejsza. Za to przy faktycznym rozumowaniu agentowym (Claude Code jako środowisko Fable, Codex jako środowisko Sola) różnica w koszcie była znacznie większa. Ogólnie Fable jest dużo droższy od Sola.

Sprawa tokenów jest fascynująca: nawet gdyby Fable i Sol kosztowały dokładnie tyle samo za token wejścia i wyjścia, Sol i tak wychodziłby wyraźnie taniej, bo jest po prostu oszczędniejszy w tokenach. Nie wiem dokładnie dlaczego, ale tak jest. Pewnie sporo zawdzięcza Codeksowi — w moich wcześniejszych porównaniach Codex zawsze był szybszy i oszczędniejszy niż Claude Code.

Ciekawa jest też szybkość. Przez API mediana opóźnień Sola była niższa niż Fable, ale średnia — wyższa. To znaczy, że Sol jest bardziej rozstrzelony: niektóre przebiegi bardzo długie, inne bardzo szybkie. Fable trzymał się konsekwentnie okolic 20 sekund — dlatego jego mediana była wyższa, a średnia niższa. Za to przy budowach agentowych Fable był praktycznie zawsze wolniejszy.

Werdykt: menedżer kontra wykonawca

Po tych wszystkich testach — zabawowych, projektowych, przez API, plus codzienna praca — oto do czego doszedłem.

Ogólnie Fable to lepszy menedżer — tak o nim myślę. Traktuję go jak współzałożyciela, jak menedżera. Sol to naprawdę bardzo dobry wykonawca. Układ, w którym Fable orkiestruje wielu agentów Sol, byłby świetny.

Co przypisałbym Solowi jako jego przewagi: cena, zdecydowanie lepsza obsługa komputera (computer use), lepsze granie rolą adwokata diabła — jest ostrożniejszy w wyszukiwaniu błędów i patrzeniu na sprawy z różnych stron. Dałbym mu też weryfikację, właśnie ze względu na computer use i tę ostrożność: naprawdę myśli o tym, co powiedział użytkownik, co ma zrobić, i robi dokładnie to. Fable częściej trochę się stawia, bywa „bardziej pyskaty” — nie zawsze chce po prostu wziąć polecenie i je wykonać, czasem woli oponować i wejść w rolę konsultanta. To dobra cecha, dlatego nazywam go menedżerem — ale ma to swoje plusy i minusy. Solowi przypisałbym też szybkość.

Fable jest za to znacznie bardziej kreatywny. Sprawia wrażenie lepszego w pisaniu, w burzy mózgów, w doradzaniu — jest naprawdę strategiczny. Do pracy umysłowej przez cały dzień wciąż wolę Fable, choć nie zawsze da się uzasadnić jego koszt. Wydawał się też lepszy w tworzeniu filmów — nagrałem ostatnio dwa materiały na YouTube: jeden pod tytułem „Fable 5 zrobił cały ten film”, drugi (opublikowany dziś) „Sol zrobił cały ten film”. Oba modele stworzyły filmy od zera; mnie bardziej podobał się ten Fable.

Fable jest też lepszy w nienadinżynierowaniu, bo Sol uruchamia mnóstwo testów — co samo w sobie jest ciekawe w kontekście tokenów: jak może być tak oszczędny, skoro pisze tyle testów? Bywa, że przekombinuje, zwłaszcza gdy odpalałem Sola w trybie Ultra — potrafił iść i iść bez końca. Czasem to dobre, czasem złe; zawsze są plusy i minusy.

Ale co do czystej zdolności — nie ma dyskusji. Fable 5 jest w innej lidze, po prostu na innym poziomie. Sol jest bardzo dobry, moim zdaniem bardziej porównywalny z Opusem 4.8. Jest wyraźnie lepszy od GPT 5.5, ale to nie jest Fable 5. I szczerze: gdyby był na poziomie Fable 5, byłby wyceniony jak Fable 5. A nie jest — jest wyceniony jak Opus.

Podsumowując: Fable jest dobry do rozumowania i oceniania, a Sol to model do dowożenia i wykonywania.

Żeby to zobrazować, spróbowałem ułożyć, gdzie plasuje się czwórka omawianych modeli. GPT 5.5 i Opus są bardzo do siebie zbliżone; ponieważ większość pracy prowadzę na Opusie, GPT 5.5 postawiłbym odrobinę za nim. Sol jest wyraźnie przed obydwoma — to bardzo dobry model. Ale między Solem a poziomem Fable wciąż jest spora luka.

Na koniec: jedno to patrzeć na benchmarki, a co innego naprawdę pobrudzić sobie ręce — wykonać realną, codzienną pracę. To kwestia wyczucia. Jedni od razu powiedzą „Sol jest lepszy od Fable, bezdyskusyjnie”, inni w ogóle się z tym nie zgodzą. Wszystko zależy od twojego przypadku użycia, wyczucia, sposobu instruowania modelu oraz od tego, jak masz skonfigurowane środowisko i umiejętności. Każdy jest trochę inny — ale takie są moje wnioski po całym dniu z tymi modelami.

10 najważniejszych takeaways — z kontekstem zastosowania

1.Nie dobieraj modelu po benchmarkach, tylko po własnej pracy

Na czym polega: Benchmarki pokazywały Sola jako lidera, ale w praktycznych zadaniach autora Fable regularnie wygrywał jakością. „Wyczucie” na realnych zadaniach dało inny obraz niż tabele wyników.

Jak stosować: Zanim wybierzesz model do stałej pracy, przepuść przez oba dokładnie te same, reprezentatywne dla ciebie zadania i porównaj wyniki obok siebie (najlepiej „na ślepo”, bez sugerowania się nazwą).

Na co uważać: Benchmarki bywają dobierane pod marketing premiery. Twoje zadania, sposób instruowania i konfiguracja środowiska potrafią całkowicie odwrócić ranking.

2.Dopasuj klasę modelu do trudności zadania (ekonomika jednostkowa)

Na czym polega: Jeśli zadanie ma trudność „5”, model na „10” jest przepłacony. Przy prostych, jednorazowych zapytaniach tańszy Sol dawał wyniki niemal równe droższemu Fable.

Jak stosować: Podziel swoje zadania na proste/powtarzalne i trudne/koncepcyjne. Do pierwszej grupy używaj tańszego, oszczędnego modelu, drogi rezerwuj na to, co naprawdę tego wymaga.

Na co uważać: „Wystarczający” model bywa mniej niezawodny — patrz punkt o odmowach. Oszczędność na złym typie zadania potrafi kosztować więcej poprawek.

3.Rozdziel role: model-menedżer i model-wykonawca

Na czym polega: Autor traktuje Fable jak menedżera/współzałożyciela (strategia, ocena, kreatywność), a Sola jak bardzo dobrego wykonawcę (szybkie, tanie dowożenie).

Jak stosować: Buduj przepływy, w których droższy, „mądrzejszy” model planuje i ocenia, a tańszy wykonuje kroki. Autor wprost wskazuje układ „Fable orkiestruje agentów Sol” jako idealny.

Na co uważać: Taka architektura wymaga dobrego przekazywania kontekstu między modelami; źle zaprojektowana orkiestracja może zjeść oszczędności na tanim wykonawcy.

4.Oszczędność tokenów to realna, ale nie jedyna oszczędność

Na czym polega: Sol zużywał 3–4 razy mniej tokenów wyjściowych i bywał kilkunastokrotnie tańszy w zadaniach agentowych — częściowo dzięki środowisku (Codex), częściowo przez sposób trenowania.

Jak stosować: Przy porównywaniu kosztów patrz nie tylko na cenę za token, ale i na to, ile tokenów model realnie zużywa na twoje zadania. Mierz koszt całego przebiegu, nie stawkę cennikową.

Na co uważać: Mniejsze zużycie tokenów potrafi oznaczać uboższy wynik. U autora tańszy przebieg bywał zauważalnie słabszy jakościowo — oszczędność nie zawsze się opłaca.

5.Uważaj na odmowy odpowiedzi (guardrails) przy zadaniach API

Na czym polega: W szybkich zapytaniach API Fable często w ogóle nie zwracał odpowiedzi — jego mocno wbudowane zabezpieczenia powodowały odmowy. Przewaga Sola „24 do 3” wynikała głównie z tych odmów, bo przy udzielonych odpowiedziach jakość była niemal równa.

Jak stosować: Testując model do zautomatyzowanych zapytań, mierz odsetek udzielonych odpowiedzi (reliability), a nie tylko jakość tych, które się pojawiły. Dla automatyzacji niezawodność bywa ważniejsza niż szczytowa jakość.

Na co uważać: Model, który świetnie odpowiada „gdy odpowie”, może być bezużyteczny w automatyzacji, jeśli regularnie odmawia. Rozdziel metrykę „jakość” od metryki „czy w ogóle odpowiedział”.

6.Przewaga kosztowa rośnie wraz ze złożonością zadania

Na czym polega: Przy krótkich wywołaniach API różnica kosztu między modelami była niewielka (kilka dolarów), ale przy wieloetapowej pracy agentowej luka dramatycznie się powiększała.

Jak stosować: Szacując koszt, rozróżniaj zadania jednostrzałowe od długich pętli agentowych. Przy tych drugich tańszy model daje znacznie większe realne oszczędności — tam decyzja o modelu waży najwięcej.

Na co uważać: Nie przenoś intuicji kosztowej z prostych zapytań na złożone przepływy — tam proporcje wydatków są zupełnie inne.

7.Droższy model musi być lepszy proporcjonalnie do ceny, nie tylko „lepszy”

Na czym polega: Fable bywał ~20 razy droższy od Sola, ale — zdaniem autora — nie był 20 razy lepszy. Wybór Fable był uzasadniony tylko tam, gdzie liczyła się czysta jakość.

Jak stosować: Przy decyzji o modelu pytaj nie „który jest lepszy”, tylko „czy jest lepszy na tyle, by uzasadnić różnicę w koszcie dla tego konkretnego zadania”.

Na co uważać: Łatwo domyślnie sięgać po najdroższy model „dla świętego spokoju”. Przy skali (wiele wywołań) taka wygoda potrafi się bardzo mocno zsumować.

8.Do weryfikacji i „adwokata diabła” wybieraj model ostrożniejszy

Na czym polega: Sol lepiej grał rolę adwokata diabła — ostrożniej szukał błędów, patrzył z różnych stron i robił dokładnie to, o co proszono. Fable częściej oponował i wchodził w rolę konsultanta.

Jak stosować: Do etapów sprawdzania, testowania i wyłapywania błędów przydziel model bardziej skrupulatny i posłuszny instrukcji; do etapów doradczych i strategicznych — ten, który potrafi się zdrowo postawić.

Na co uważać: Ostrożny wykonawca bywa nadgorliwy — Sol potrafił przekombinować i uruchamiać nadmiar testów (zwłaszcza w trybie Ultra), co wydłuża przebieg.

9.Do pracy kreatywnej i strategicznej model, który potrafi oponować

Na czym polega: Fable wypadał lepiej w pisaniu, burzy mózgów, doradztwie i tworzeniu filmów; jego skłonność do „stawiania się” bywa zaletą, bo działa jak konsultant, a nie tylko wykonawca poleceń.

Jak stosować: Do zadań otwartych i koncepcyjnych wybieraj model bardziej kreatywny i skłonny do kwestionowania twojego pomysłu — zyskujesz jakość i perspektywę.

Na co uważać: Ta sama „pyskatość” bywa uciążliwa, gdy chcesz po prostu szybko wykonać jasne polecenie. Dobierz model do tego, czy oczekujesz posłuszeństwa, czy sparingu.

10.Numeracja i cena zdradzają pozycjonowanie modelu

Na czym polega: Autor zwraca uwagę, że Sol dostał oznaczenie „5.6” (a nie „6”) i cenę na poziomie Opusa, co sugeruje, że dostawca sam nie stawia go w jednej lidze z modelem najwyższej klasy — prawdziwy skok rezerwując na następną generację.

Jak stosować: Czytaj sygnały pozycjonowania — numer wersji i poziom cennika często mówią, do jakiej klasy dostawca faktycznie zalicza model. Cena bywa uczciwszą wskazówką niż komunikat marketingowy.

Na co uważać: To interpretacja, nie fakt techniczny. Nie wyciągaj z nazwy ani ceny twardych wniosków o możliwościach — i tak zweryfikuj model na własnych zadaniach.