Fable 5 wurde von Nutzern im Internet eine geniale Geldspar-Methode entlockt, mit der man bis zu 70 % sparen kann.
Es war unerwartet, dass die alte Methode der Menschen, mit Mikrodruck Notizen zu machen, auch bei großen Modellen funktioniert.
In den letzten Tagen hat ein kluger Kerl festgestellt, dass man, wenn man den Kontext von Fable 5 in Bilder mit dicht gedruckten Texten umwandelt und das Modell diese Bilder über OCR lesen lässt, die Token-Eingabekosten um bis zu 70 % senken kann.
Noch verrückter ist, dass nicht nur normale Gespräche, sondern auch Systemhinweise, Hilfedokumente und Verlaufsdaten allesamt in die Bilder gepackt werden können.
Um es zu belegen, hat der Kerl tatsächlich ein Beispiel gegeben:
Etwa 48.000 Zeichen lange Systemhinweise und Hilfedokumente würden, wenn sie direkt als Text eingegeben werden, etwa 25.000 Token benötigen.
Wenn man sie jedoch in ein Bild der Größe 1573×1248 rendert, werden nur etwa 2700 Image-Token benötigt.
Nach den aktuellen Preisen von Fable 5 hat sich die End-to-End-Rechnung in der Praxis um 59 % bis 70 % verringert.
Dieses Bild sagt mehr als tausend Worte und erinnert wirklich an die alten Zeiten, in denen man Notizen mikroskopisch klein schrieb, um sie in die Prüfung zu nehmen.
Das ist wahrhaftig: Komprimierung ist Intelligenz.
Nachdem die Netizens das gesehen haben, haben sie direkt gesagt: Dieser Trick darf Dario auf keinen Fall bekannt werden.
(Du willst doch nicht, dass deine Fable 5 die Bildhochladung einschränkt.)
Den Kontext als Notiz machen und die Rechnung um 70 % senken
Die am Anfang erwähnte Methode, Fable 5 auf unkonventionelle Weise zu nutzen, heißt pxpipe und hat bisher auf GitHub mehr als 3000 Sterne erhalten.
In der Beschreibung hat der Autor direkt gesagt:
Dieser Trick besteht darin, den Textkontext von Fable 5 in Bilder zu rendern, um den Token-Verbrauch zu reduzieren.
Der Grund, warum diese "unkonventionelle Methode" funktioniert, liegt in einem Preisunterschied:
Die Token-Kosten für Bilder werden hauptsächlich von der Pixelgröße und nicht von der Anzahl der in das Bild gepackten Wörter bestimmt.
Dies bedeutet, dass solange das Modell die Wörter im Bild lesen kann, es möglicherweise billiger ist, denselben Text in ein dicht gedrucktes PNG-Bild zu komprimieren als ihn direkt als Text einzugeben.
Insbesondere Inhalte wie Code, JSON, Werkzeugausgaben, Systemhinweise und Hilfedokumente sind sehr Token-intensiv.
Nach der Schätzung des Autors von pxpipe können in realen Claude Code-Traffiken solche Inhalte, wenn sie als Bilder eingegeben werden, etwa 3,1 Zeichen pro Image-Token aufnehmen.
Wenn sie jedoch als Text eingegeben werden, entspricht dies nur etwa einem Zeichen pro Text-Token.
Und dies gibt pxpipe Raum für Manipulation.
Im Wesentlichen ist pxpipe ein lokaler Proxy: Es interceptiert die Anfragen von Claude Code und formatiert den sperrigen und komprimierbaren Kontext in kompakte PNG-Bilder um, bevor die Anfrage das lokale Gerät verlässt, und fügt sie dann wieder in die Anfrage ein, um sie an das Modell zu senden.
Das Modell liest diese Bilder über denselben visuellen Kanal – den gleichen Kanal, den die Computer-Nutzungsfunktion von Anthropic bei der Lesung von Bildschirmfotos nutzt.
Mit anderen Worten, pxpipe lässt das Modell nicht "echt OCR" durchführen, sondern nutzt die bereits vorhandene Fähigkeit des Modells, Bilder zu lesen, um den langen Kontext als Screenshot zu füttern.
Einfach ausgedrückt, ist es ein automatischer Mikrodruck-"Drucker".
Später hat der Autor, um zu beweisen, dass dieser Trick nicht nur eine Idee ist, ein Vergleichs-Demo veröffentlicht.
Bei der gleichen Aufgabe hat die Originaltext-Version am Ende eine Rechnung von 42,21 US-Dollar und den Kontextfensterplatz zu 96 % ausgeschöpft. Die pxpipe-Version hat hingegen nur 6,06 US-Dollar gekostet und nur 73,5k/1M des Kontextplatzes genutzt.
Das heißt, neben der Kosteneinsparung wurde die Aufgabe auch erfolgreich abgeschlossen. Fable 5 kann immer noch die Schlüsselinformationen aus dem bildlichen Kontext lesen und Zählungen und mehrstufige Buchhaltungsberechnungen durchführen.
Allerdings ist dies kein Allheilmittel. Der Autor hat das gleiche Experiment mit Opus 4.8 durchgeführt. Bei normalem Text funktioniert es problemlos, aber bei der Wortfrequenzzählung in bildlichen Inhalten scheitert Opus.
Zugleich bedeutet dies, dass es sich um eine verlustbehaftete Komprimierung handelt, die stark von der visuellen Lesefähigkeit des Modells abhängt.
Fable 5 kann noch schwerfällig genaue Zeichenketten in dichten Bildern lesen, aber Opus macht schnell Fehler. Noch gefährlicher ist, dass es möglicherweise keine Fehlermeldung gibt, sondern es sich einfach ein scheinbar plausibles Ergebnis ausdenkt.
(Hinweis: Diese Benchmark zeigt, dass das Rendern von hochdichtem Kontext in Bilder bei Fable 5 die semantische Verständnis und die Zustandserkennung im Wesentlichen nicht beeinträchtigt und die Token einsparen kann. Bei der wörtlichen Lesung genauer Zeichenketten wird jedoch das Risiko der verlustbehafteten Komprimierung sichtbar.)
Deshalb macht pxpipe nicht alle Inhalte bildlich, sondern behält IDs, Hashwerte, Schlüssel, genaue Zahlen und die letzten Gesprächsrunden bei und komprimiert nur die "langen und dichten" Inhalte wie Systemhinweise, Hilfedokumente, frühere Verlaufsdaten und große Werkzeugausgaben.
Am Ende ist es auch ganz einfach, es selbst auszuprobieren. Der Autor hat nur zwei Zeilen zum Starten angegeben:
- npx pxpipe-proxy # proxy on 127.0.0.1:47821ANTHROPIC_BASE_URL=
- http://127.0.0.1:47821 claude # point Claude Code at it
Nach dem Start gibt es auch ein Dashboard auf dem lokalen Gerät:
http://127.0.0.1:47821/
Darin kann man sehen, wie viele Token gespart wurden, den Vergleich zwischen Text und Bild bei jeder Umwandlung, den Abschaltschalter und die Bezeichnung des aktuellen Modells.
Es ist zu beachten, dass pxpipe nur die Anfragen komprimiert, nicht die Modellausgaben. Das heißt, die Antworten werden immer noch normal als Stream zurückgegeben. Es verändert nur die großen Kontextinhalte auf der Eingabeseite.
Ein altes Google-Papier aus 2022 hat es bereits bewiesen
Nach der Veröffentlichung dieses Projekts ist ein großer Rummel losgebrochen, vor allem wegen der hohen Kosten von Fable 5.
Einige Netizens haben gesagt, dass sie diesen Trick schon lange nutzen.
Einige Wissenschaftler haben ein altes Google-Papier aus 2022, CLIPPO, hervorgeholt.
Einfach ausgedrückt, ähnelt CLIPPO pxpipe. Die Kernidee von CLIPPO ist, Wörter auch als Bilder zu behandeln.
Traditionelles CLIP verwendet normalerweise zwei Codierer: einen für Bilder und einen für Text.
CLIPPO rendert den Text direkt in RGB-Bilder, sodass ein einziger Vision Transformer sowohl reale Bilder als auch Textbilder verarbeiten kann. Selbst Bilder + Fragen können zu einem Bild zusammengefügt und zusammen eingegeben werden.
Somit benötigt das Modell keine Tokenizer, Text-Tower und Word-Embedding mehr, aber es erreicht immer noch nahezu die Leistung von CLIP-ähnlichen Modellen bei der Bildklassifizierung und der Bild-Text-Suche, nur 1 - 2 Punkte hinterher.
Dies bedeutet, dass Wörter nicht unbedingt in Form von Token in das Modell eingegeben werden müssen, sondern auch zu Pixeln werden können.
Außerdem haben in der Kommentarzone viele Netizens DeepSeek-OCR erwähnt.
Bei DeepSeek OCR geht es darum, langen Kontext optisch zu komprimieren. In der pxpipe-Dokumentation wird es speziell zur Erklärung dieser Methode verwendet. Bei einer Komprimierung von weniger als 10x kann es eine Decodierungsgenauigkeit von etwa 97 % erreichen, bei nahezu 20x sinkt es auf etwa 60 %.
Deshalb ist der Rummel um pxpipe möglicherweise nicht nur durch ein "Kostenspar-Tool" ausgelöst worden.
Es scheint eher, dass es mehrere Linien der letzten Jahre plötzlich miteinander verbindet: CLIPPO hat bewiesen, dass Wörter wie Bilder behandelt werden können. DeepSeek-OCR hat bewiesen, dass Kontext optisch komprimiert werden kann.
Und die Fable 5-Generation von Modellen lässt normale Benutzer erstmals in einem echten Produktionswerkzeug diesen Gewinnspielraum wahrnehmen.