NEW Fable 5 API Usage Exploit (Reduce Costs Immediately)

O czym jest ten film

1. Autor pokazuje trik obniżający zużycie tokenów w modelu Fable 5 o około 30% — polegający na renderowaniu obszernego kontekstu jako obrazu zamiast tekstu.
2. Mechanizm opiera się na różnicy między rozliczaniem obrazów a rozliczaniem tekstu: koszt obrazu zależy od jego wymiarów w pikselach, a nie od ilości tekstu, który się w nim mieści.
3. Tekst w obrazie można zmniejszyć do bardzo drobnego rozmiaru — musi pozostać czytelny, bo model i tak odczytuje go przez OCR i zamienia na tokeny.
4. W pierwszym teście ten sam prompt kosztował 1,3 dolara jako tekst i 0,69 dolara jako obraz — czyli nieco ponad 30% oszczędności.
5. Model rozpoznał treść z drobnego, skompresowanego obrazu tak samo dobrze jak z tekstu — bez różnicy w jakości odpowiedzi.
6. Technika opłaca się najbardziej przy bardzo dużych, wielokrotnie używanych promptach obsługujących funkcje biznesowe, a nie przy zwykłych, codziennych zapytaniach.
7. Autor pokazuje, jak poleceniem głosowym kazać modelowi Fable zbudować prosty pipeline zamieniający prompt na obraz przed wysłaniem go do modelu.
8. Powstaje skrypt pxpipe.py, który bierze prompt z pliku, generuje z niego obraz i tak podaje go do modelu.
9. W drugim teście — zadanie typu „igła w stogu siana” na ogromnym pliku z danymi — redukcja tokenów wejściowych sięgnęła 68,7%, a kosztu aż 59%.
10. Autor spodziewa się, że tę lukę wkrótce załatają, więc zachęca, by skorzystać z niej od razu przy własnych zasobach biznesowych.

Redakcyjne tłumaczenie

Na czym polega trik

Mam dla was naprawdę zabawny sposób na optymalizację zużycia modelu Fable. Zajmuje jakieś trzydzieści sekund, a pozwala zaoszczędzić około 30% całego zużycia Fable — praktycznie bez żadnych minusów. Wszystko udostępniam poniżej: możecie to pobrać i użyć jednym kliknięciem.

Mówiąc w skrócie: ten trik pozwala obciąć liczbę tokenów wejściowych w Claude Code, renderując obszerny kontekst w postaci obrazu. Dostajecie dokładnie ten sam system prompt, dokumentację narzędzi i historię — tyle że w ułamku tokenów. A wynika to ze sposobu, w jaki Claude obecnie rozlicza obrazy w porównaniu z rozliczaniem tekstu. Koszt tokenowy obrazu jest ustalany na podstawie jego wymiarów w pikselach, a nie tego, ile tekstu się w nim znajduje.

(Informacja dodatkowa: „Fable 5” i „Claude” są tu używane wymiennie — autor mówi o modelu, do którego ma dostęp przez interfejs Claude Code. OCR to optyczne rozpoznawanie znaków, czyli odczytywanie tekstu z obrazu.)

To oznacza, że jeśli jest się sprytnym, można zmniejszyć tekst w obrazie do naprawdę mikroskopijnych rozmiarów. Oczywiście musi on nadal pozostawać czytelny — ale może być bardzo, bardzo mały. Wtedy każecie modelowi odczytać ten obraz, płacicie znacznie mniej, a mimo to dostajecie cały kontekst, który mielibyście normalnie. Stąd te wspomniane 30% oszczędności.

Czy będę stosować ten trik przy każdym zapytaniu? Pewnie nie. Ale jeśli mam naprawdę wielkie zapytania, liczące setki tysięcy tokenów, które mają działać długo, być stale odświeżane i regularnie używane do jakiejś funkcji biznesowej — to jest to szybki i łatwy sposób, żeby od razu zaoszczędzić 30%.

Pierwszy test: tekst kontra obraz

Mam tu otwarty Fable 5 w terminalu o nazwie Ghostty. To dokładnie to samo, co dostaniecie w Claude Desktop, w Antigravity albo gdziekolwiek indziej — akurat eksperymentowałem z Ghostty, bo podoba mi się jego wygląd.

(Informacja dodatkowa: Ghostty to terminal, w którym autor uruchamia narzędzie; wybór terminala nie ma wpływu na sam trik.)

Przepuściłem ten sam prompt w wersji tekstowej i w wersji obrazowej. Wersja tekstowa kosztowała 1,3 dolara, a wersja obrazowa 0,69 dolara. Matematycznie to nieco ponad 30% redukcji zużycia tokenów. Istotne jest to, że zamiast 59 822 tokenów zużyliśmy tylko 38 142. I nie było żadnej różnicy w zdolności modelu do odtwarzania poszczególnych fragmentów tekstu.

Wiem, że brzmi to szalenie, biorąc pod uwagę, że mamy tu teraz mocno skompresowany, malutki obraz. Ale OCR i zdolność Fable do rozumienia tekstu, nawet gdy jest naprawdę drobny, są w tej chwili prawdopodobnie najlepsze na świecie. A dopóki model przekłada to na tokeny, jest to jedno i to samo.

Jak to zbudować u siebie

Jak właściwie zaimplementować coś takiego u siebie? To naprawdę proste. Wyczyszczę tę demonstrację i po prostu odezwę się głosem do terminala Claude Code. Korzystam z darmowego, otwartoźródłowego systemu zamiany mowy na tekst o nazwie Hex. Działa on na Parakeet i całość dzieje się lokalnie na moim komputerze.

(Informacja dodatkowa: Hex to aplikacja do dyktowania, a Parakeet to model rozpoznawania mowy działający na urządzeniu użytkownika, bez wysyłania nagrań do chmury.)

Wciskam przycisk transkrypcji głosowej i po prostu prostymi słowami mówię, czego chcę: „Jest nowa strategia redukcji tokenów. Opisałem ją w repozytorium na GitHubie poniżej. Chcę, żebyś zbudował prosty system, który za każdym razem, gdy podam prompt, najpierw zamieni go na obraz — najlepiej przy użyciu tańszego modelu — a potem poda to do Fable. Budujemy to teraz w Fable, żeby stworzyć samą architekturę. Później chcę móc przekazywać do Fable bardzo długie prompty, żeby robić arbitraż na tokenach”.

(Informacja dodatkowa: „arbitraż na tokenach” to tu obrazowe określenie — chodzi o wykorzystanie różnicy w cenie między rozliczaniem tekstu a rozliczaniem obrazu.)

Następnie podaję samo repozytorium. Cała idea jest taka, że to Fable ma wykonać całą robotę — i to z dużym nakładem pracy, bo chcę zbudować naprawdę wydajny system. Ale potem chcę móc wziąć dowolny bardzo długi prompt i jednym poleceniem zamienić go na obraz przy pomocy skilla.

(Informacja dodatkowa: „skill” to gotowa, wielokrotnego użytku funkcja, którą można wywołać jedną komendą.)

Wyobraźcie sobie sytuację, w której buduję jakąś infrastrukturę biznesową, która opiera się na jakimś potwornie długim promptcie — opisującym każdą możliwą ścieżkę rozmowy albo cokolwiek innego, co akurat robicie. Chcę móc jednym ruchem wrzucić ten ogromny prompt do obrazu za pomocą tego skilla. Model właśnie przegląda repozytorium, streszcza je — za chwilę wrócimy i pokażę wyniki.

Logika pipeline’u

Zamiast podawać prompty bezpośrednio, każemy modelowi Fable zbudować krótki pipeline, jakiś skrypt. Prompty, które chcę uruchomić, będę przechowywać w pliku. Skrypt uruchomi się na tym pliku, wygeneruje obraz — i w ten sposób pipeline znacząco zmniejszy całkowite zużycie tokenów.

Logika jest dość prosta. Obraz o wymiarach 1928 na 1928 pikseli kosztuje mniej więcej określoną liczbę tokenów wizyjnych i mieści określoną liczbę znaków. Tymczasem realny ruch w Claude Code ma średnio pewną liczbę znaków na token. Na tym właśnie polega opłacalność obrazów — robimy po prostu arbitraż między kosztem obrazu a kosztem tokenów.

Jak wspomniałem, prawdopodobnie dość szybko to załatają. Więc jeśli macie jakiekolwiek zasoby biznesowe, na których chcielibyście zaoszczędzić pewnie kilkaset dolarów — a ja, jak Bóg mi świadkiem, w dającej się przewidzieć przyszłości podaję każdy swój prompt właśnie w ten sposób — to zróbcie to teraz.

Mamy już skrypt pxpipe.py. Wymyślę teraz naprawdę długi prompt i pokażę wam, jak używać tego w praktyce.

Drugi test: zadanie „igła w stogu siana”

Stworzyłem właśnie superdługi prompt. Jest ogromny. Zapisałem w jednym wielkim pliku tekstowym praktycznie każde wideo, jakie kiedykolwiek wrzuciłem, wraz z częścią danych o ich wynikach. Teraz zadam mu na tej podstawie mnóstwo pytań i wykorzystam tę wiedzę, żeby znacząco zwiększyć prawdopodobieństwo, na przykład, opracowania jakiejś strategii minimalizowania odejść widzów.

Jednocześnie stworzyłem obrazy. Są bardzo podobne do tego promptu — tyle że zamiast układu tekstowego mają układ obrazowy. Można sobie mocno przybliżyć i zobaczyć, że treść jest jakby skompresowana, ale wciąż czytelna — i to jest kluczowe. Pewnie mógłbym to jeszcze bardziej zoptymalizować, na przykład wyjustować tekst, ale na potrzeby demonstracji po prostu to uruchomię.

Robimy szybki test. Zadamy mnóstwo pytań o treść zawartą w materiale — na przykład: jakie strategie działają naprawdę dobrze? Co członek numer 4289 zrobił inaczej niż pozostali? I tak dalej. Potem porównamy obie wersje i zobaczymy, o ile lepszą techniką optymalizacji tokenów jest ta metoda.

To, co się teraz dzieje, to test bezpośredni. Odbywa się przez przepuszczenie tego przez Fable 5 z cennikiem API — z którego być może i tak wszyscy będziemy musieli korzystać za dwadzieścia cztery godziny.

(Informacja dodatkowa: autor sugeruje, że rozliczanie według cennika API może wkrótce stać się obowiązujące — to jego przewidywanie, nie potwierdzony fakt.)

Ponieważ było to zadanie oparte na wiedzy — dosłownie wyodrębnialiśmy poszczególne elementy z tekstu, łączyliśmy je i tak dalej, a nie wielokrotnie przetwarzaliśmy to samo w kółko — różnica jest ogromna. Mamy 68,7% redukcji tokenów wejściowych. A koszt nie spadł o 25–30%, jak w poprzednim przykładzie — spadł aż o 59%.

To oznacza, że przy zapytaniach typu „igła w stogu siana” korzyść z takiej strategii jest zdecydowanie większa. Żeby maksymalnie ułatwić wam życie, wszystko udostępniam poniżej — róbcie z tym, co chcecie.

To ogłoszenie nie musi być bardziej szczegółowe. Mam nadzieję, że wam się spodobało. Miłego dnia. A jeśli chcecie to pobrać, zajrzyjcie do opisu pod filmem. Sprawdźcie też Maker School — mój dziewięćdziesięciodniowy program, w którym gwarantuję wam pierwszego klienta na sprzedaży takich systemów. Do zobaczenia jutro.

10 najważniejszych takeaways — z kontekstem zastosowania

1.Renderowanie kontekstu jako obrazu obniża koszt o 30–59%

Na czym polega: Zamiast wysyłać obszerny kontekst jako tekst, konwertujesz go na obraz. Koszt tokenowy obrazu zależy od jego wymiarów w pikselach, a nie od ilości tekstu w środku, więc na dużych promptach płacisz znacznie mniej za tę samą treść.

Jak stosować: Wykorzystuj to przy naprawdę dużych, stałych blokach kontekstu — bazach wiedzy, długich instrukcjach, historii — które są używane wielokrotnie. Najpierw zmierz koszt wersji tekstowej i obrazowej na własnym zadaniu, zanim wdrożysz to na produkcji.

Na co uważać: Autor sam zapowiada, że dostawca prawdopodobnie szybko załata tę lukę. Nie buduj na tym trwałej infrastruktury bez planu awaryjnego na wypadek zmiany zasad rozliczania.

2.Największa korzyść dotyczy zadań typu „igła w stogu siana”

Na czym polega: Przy zadaniach polegających na wyszukiwaniu i wyodrębnianiu konkretnych informacji z ogromnego materiału (a nie na wielokrotnym przetwarzaniu tego samego) redukcja kosztów sięgnęła 59%, a tokenów wejściowych — prawie 69%.

Jak stosować: Kieruj tą metodą przede wszystkim zapytania „wyszukaj i wyciągnij”: analizy dużych zbiorów danych, przeszukiwanie dokumentacji, ekstrakcję faktów z długich archiwów.

Na co uważać: Przy zadaniach wymagających intensywnego, wielokrotnego rozumowania nad tym samym tekstem korzyść jest mniejsza (bliżej 30%). Dobór metody do typu zadania decyduje o realnej oszczędności.

3.Tekst w obrazie musi pozostać czytelny

Na czym polega: Oszczędność bierze się z maksymalnego zmniejszenia tekstu w obrazie, ale model odczytuje go przez OCR — jeśli tekst stanie się nieczytelny, jakość odpowiedzi spadnie.

Jak stosować: Zmniejszaj czcionkę tak długo, jak tekst pozostaje wyraźnie rozpoznawalny. Przetestuj, czy model poprawnie odtwarza konkretne, trudne fragmenty (liczby, identyfikatory, nazwy własne).

Na co uważać: Autor deklaruje „zero różnicy” w jakości, ale opiera się na własnych testach. Zweryfikuj to na swoich danych, zwłaszcza przy danych wrażliwych na dokładność, gdzie błąd OCR jest kosztowny.

4.Zbuduj powtarzalny pipeline, nie rób tego ręcznie

Na czym polega: Autor każe modelowi zbudować skrypt (pxpipe.py), który bierze prompt z pliku, generuje obraz i podaje go do modelu — dzięki temu konwersja jest jednym powtarzalnym krokiem.

Jak stosować: Trzymaj prompty w plikach i przepuszczaj je przez jeden skrypt. To eliminuje ręczne przygotowywanie obrazów i pozwala łatwo skalować metodę na wiele zapytań.

Na co uważać: Sam skrypt należy zbudować starannie (autor robi to „z dużym nakładem pracy”). Źle dobrane parametry obrazu — rozmiar, gęstość tekstu — mogą zniweczyć oszczędność albo pogorszyć czytelność.

5.Opłacalność wynika z konkretnej arytmetyki obrazu

Na czym polega: Obraz 1928×1928 pikseli kosztuje ustaloną liczbę tokenów wizyjnych i mieści określoną liczbę znaków; realny ruch tekstowy ma średnio pewną liczbę znaków na token. Różnica między tymi dwiema wartościami to twój zysk.

Jak stosować: Policz, ile znaków upakujesz w obrazie danego rozmiaru, i porównaj z tym, ile tokenów kosztowałyby te znaki jako tekst. Metoda opłaca się dopiero powyżej progu gęstości tekstu.

Na co uważać: Przy krótkich promptach obraz może kosztować więcej niż tekst — stały koszt obrazu się nie zwróci. To narzędzie do dużych bloków, nie do drobnych zapytań.

6.Nie stosuj tego do każdego zapytania

Na czym polega: Autor jasno mówi, że nie użyje tego przy każdym zapytaniu — technika ma sens tylko przy naprawdę wielkich, długo działających, wielokrotnie używanych promptach.

Jak stosować: Zarezerwuj metodę dla funkcji biznesowych opartych na masywnym, stałym kontekście liczonym w setkach tysięcy tokenów. Dla codziennych, krótkich zapytań zostań przy tekście.

Na co uważać: Dodatkowy krok konwersji wprowadza złożoność i możliwość błędu. Przy małych promptach nie warto płacić tej ceny za marginalną (lub żadną) oszczędność.

7.Traktuj to jako okno czasowe, nie trwałą przewagę

Na czym polega: Metoda wykorzystuje bieżącą różnicę w sposobie rozliczania obrazów i tekstu — autor kilkukrotnie podkreśla, że spodziewa się szybkiej „łatki”.

Jak stosować: Jeśli masz konkretne, duże zasoby, na których możesz teraz zaoszczędzić realne pieniądze, wdroż to od razu i zbierz korzyść, póki działa.

Na co uważać: Nie planuj budżetu ani architektury produktu w oparciu o trwałość tej oszczędności. Gdy zasady rozliczania się zmienią, koszty mogą wrócić do poziomu tekstowego z dnia na dzień.

8.Zawsze porównuj wersje w teście bezpośrednim

Na czym polega: Autor nie zakłada oszczędności — uruchamia ten sam prompt w wersji tekstowej i obrazowej, po czym porównuje realne koszty i jakość odpowiedzi (1,3 vs 0,69 dolara; 59 822 vs 38 142 tokeny).

Jak stosować: Zanim przełączysz proces na obrazy, przeprowadź własny test head-to-head na reprezentatywnym zadaniu i zmierz zarówno koszt, jak i trafność odpowiedzi.

Na co uważać: Wyniki zależą od modelu, cennika i rodzaju zadania. Liczby z filmu to punkt odniesienia, nie gwarancja — twoje mogą się różnić.

9.Cennik API może wkrótce stać się domyślny

Na czym polega: Autor wykonuje testy według cennika API i wspomina, że być może „za dwadzieścia cztery godziny” wszyscy będą musieli z niego korzystać.

Jak stosować: Uwzględnij w kalkulacjach scenariusz, w którym płacisz według stawek API. Optymalizacja tokenów staje się wtedy jeszcze istotniejsza dla kosztów operacyjnych.

Na co uważać: To przewidywanie autora, nie oficjalna informacja. Nie przyjmuj konkretnej daty za pewnik — potraktuj to jako sygnał, że warto śledzić zmiany cennika, nie jako fakt.

10.Rozważ dalszą optymalizację układu obrazu

Na czym polega: Autor przyznaje, że pokazana wersja nie jest zoptymalizowana do końca — można by na przykład wyjustować tekst, żeby upakować go gęściej i zyskać więcej.

Jak stosować: Po wdrożeniu podstawowej wersji eksperymentuj z układem: justowaniem, marginesami, gęstością wiersza, rozmiarem czcionki — każdy dodatkowy upakowany znak to większa oszczędność.

Na co uważać: Optymalizacja gęstości działa przeciw czytelności. Za każdym razem sprawdzaj, czy model wciąż bezbłędnie odczytuje treść — zbyt agresywne upakowanie pogorszy jakość i zniweczy sens całej metody.