Deinen Prompt als Bild rendern, um LLM-Kosten um 60% zu senken: genial oder einfach absurd?

Ein Trick macht gerade die Runde: Claude Fable 5 rund 60% günstiger betreiben, indem du die schweren Teile deiner Anfrage, also System-Prompt, Tool-Dokumentation, alte History und eingefügten Code, in ein Bild verwandelst, bevor die Anfrage beim Modell ankommt.

Die Logik klingt absurd, und genau deshalb ist sie viral gegangen. Ein Bild kostet das Modell eine feste Anzahl Tokens, abhängig von seiner Pixelgröße, nicht davon, wie viel Text darin steckt. Du kannst also viele Zeichen in ein dichtes Bild packen und bezahlst für die Pixel, nicht für den Text.

Das Tool, das gerade kursiert, ist pxpipe, ein quelloffener (MIT) lokaler Proxy. Er sitzt zwischen deinem Rechner und der API und rendert den umfangreichen, weitgehend statischen Kontext in dichte PNG-"Seiten", bevor die Anfrage deinen Laptop verlässt. Die Demo im Repository zeigt eine mehrstufige Aufgabe, die als reiner Text 42,21 $ kostet und mit pxpipe 6,06 $. Behauptet wird eine um 59 bis 70% niedrigere End-to-End-Rechnung bei Fable 5 zu aktuellen Listenpreisen.

Also genial oder Unsinn? Die ehrliche Antwort: Die Physik dahinter ist real, die Forschung ist ernst zu nehmen, und der Fehlermodus ist schlimm genug, dass du das Ganze für die meiste Produktionsarbeit nicht standardmäßig einschalten solltest. Hier das ganze Bild, mit den Vorbehalten, die die virale Version weglässt.

Warum das tatsächlich funktioniert: die Preis-Physik

Text und Bilder werden zum selben Preis pro Token abgerechnet, aber sehr unterschiedlich gezählt.

Text wird nach Inhalt tokenisiert. Mehr Zeichen, mehr Tokens, mehr Kosten. Ein Bild bepreist Anthropic stattdessen nach seiner Pixelfläche, mit einer groben Formel von (Breite x Höhe) / 750 Tokens, und die Zahl ist gedeckelt (Bilder werden so skaliert, dass die lange Kante bei rund 1568px bleibt, was am oberen Ende nahe 1.600 Tokens pro Bild liegt). Der springende Punkt: Diese Zahl kümmert sich nicht darum, ob das Bild ein leeres Rechteck oder eine Wand aus Text ist.

Auf echtem Claude-Code-Traffic misst pxpipe, dass dichter Inhalt wie Code und JSON etwa 3,1 Zeichen pro Bild-Token unterbringt, gegenüber rund 1,9 Zeichen pro Text-Token. Sobald dein Text dichter als etwa 19 Zeichen pro Token ist, beginnt sich das Rendern als Bild zu rechnen. Ein Block, der als Text 25k Tokens kosten würde, kommt so als rund 2,7k Bild-Tokens zurück. Daher kommt die 60%-Schlagzeile.

Das bekommt das Modell tatsächlich statt deines Textes zu sehen:

Ein Detail, das die virale Version übergeht: Weil jedes Bild nahe 1.600 Tokens gedeckelt ist, kannst du keinen unbegrenzten Kontext auf eine einzige riesige Fläche kippen. Das Tool rendert viele Seiten, nicht ein Poster. Die Ersparnis ist real, aber sie entsteht durch das Kacheln von dichtem Text über mehrere gedeckelte Bilder, nicht durch Magie.

Das ist kein Hack. Es ist eine Forschungsrichtung.

Der kontraintuitive Teil, dass Bilder von Text günstiger sein können als Text, ist kein Proxy-Tool-Gimmick. Es ist ein aktives Forschungsfeld.

Im Oktober 2025 veröffentlichte DeepSeek DeepSeek-OCR: Contexts Optical Compression und zeigte, dass ein Vision-Modell Text aus einer kleinen Menge visueller Tokens bei rund 10x Kompression dekodieren kann, während es etwa 97% OCR-Genauigkeit hält, solange das Kompressionsverhältnis unter 10x bleibt. Andrej Karpathy griff das auf und argumentierte, dass Text-Tokens vielleicht verschwenderischer "historischer Ballast" seien und dass Modelle mit Bildern von Text effizienter fahren könnten. Folgearbeiten wie Text or Pixels? It Takes Half berichten ähnliche Token-Ersparnisse bei visuellen Text-Eingaben.

Die Idee ist also legitim, und die Long-Context-Ökonomie ist wirklich interessant. pxpipe ist nur ein früher, aggressiver Versuch, das auf heutigen kommerziellen APIs einzulösen, bevor die Modelle darauf trainiert sind, es gut zu machen. Und "bevor die Modelle darauf trainiert sind, es gut zu machen" ist genau der Punkt, an dem der Ärger beginnt.

Der Haken, der es für die meiste Arbeit absurd macht

Text als Bild zu rendern ist verlustbehaftet, und der Verlust ist stumm.

Wenn das Modell ein gerendertes Zeichen falsch liest, wirft es keinen Fehler und meldet keine niedrige Konfidenz. Es erfindet selbstbewusst etwas. Die README von pxpipe dokumentiert das ehrlich: Bei einem Needle-in-a-Haystack-Test, bei dem das Modell exakte 12-stellige Hex-Strings aus dichtem gerendertem Inhalt abrufen sollte, erreichte Fable 5 13 von 15 und Opus 0 von 15. Die README beschreibt einen realen Fall, in dem das Modell den Namen einer Person aus gerenderter Chat-History abrief und ihn selbstbewusst falsch angab.

Das ist das ganze Risiko in einem Satz: Alles, was du byte-genau zurückbekommen musst, muss Text bleiben. IDs, Hashes, Secrets, exakte Zahlen, präzise Namen. pxpipe hält aktuelle Turns und exakte Bezeichner genau deshalb als Text neben den Bildern.

Ein paar Dinge, die die Schlagzeile überspringt:

• Es ist modellabhängig. pxpipe nutzt standardmäßig Fable 5 und GPT-5.6, die Modelle, die dichten gerenderten Text am besten lesen. Opus 4.8 und GPT-5.5 sind nur opt-in, weil sie gerenderten Kontext häufiger falsch lesen. Der Trick, der dir bei einem Modell 60% spart, kann bei einem anderen still den Kontext beschädigen.
• Es fügt Latenz hinzu. Große Anfragen als PNG zu kodieren kostet Zeit, bevor die Anfrage deinen Rechner überhaupt verlässt.
• Es steht in Wechselwirkung mit Prompt-Caching. Dein größter, statischster Kontext, System-Prompt und Tool-Dokumentation, ist zugleich der ideale Kandidat für Prompt-Caching, das wiederholte Tokens bereits stark rabattiert. Auf dem GPT-Pfad verzichtet pxpipe auf native Cache-Marker. Kontext als Bild zu rendern und Kontext zu cachen zielen auf dieselben Tokens, also ist der ehrliche Vergleich der gegen eine sauber gecachte Basis, nicht gegen eine naive.

Wann es sich lohnt, und wann es dich verbrennt

Das ist kein Ja oder Nein. Es ist eine Routing-Entscheidung, dieselbe Disziplin, die wir bei der Modellauswahl anwenden. Passe die Technik an die Nutzlast an.

Wenn dein Workload ein riesiger, stabiler Instruktionsblock ist, der einen Fable-5-Agenten füttert, der meist nur den Sinn braucht, kann Rendern ein echter Gewinn sein. Wenn es ein Compliance-Workflow ist, der exakte Zahlen und Bezeichner bewegt, ist derselbe Trick eine stille Belastung.

Wo das in einen echten Kosten-Stack passt

Kontext als Bild zu rendern ist ein Hebel, und nicht der erste, den wir ziehen würden. Bevor du zu einem verlustbehafteten Trick greifst, gewinnen meist die langweiligen Hebel, und sie riskieren deine Daten nicht:

• Prompt-Caching für das statische Präfix, verlustfrei und ohnehin groß.
• Model-Routing: günstige Modelle für mechanische Arbeit, starke Modelle für Urteilsvermögen. Siehe wie wir Arbeit über Fable, Opus, Sonnet und Haiku routen.
• Kosten pro erledigter Aufgabe messen, nicht Preis pro Token, denn das ist die Zahl auf deiner Rechnung. Siehe günstiger pro Token, teurer pro Antwort.
• Ein Gateway, um Fallback, Caching und Ausgabenlimits zu bündeln. Siehe unseren LLM-Gateway-Vergleich.
• Self-Hosting oder Open Weights, wenn Volumen und Datenresidenz es rechtfertigen, behandelt in den echten Kosten von Self-Hosting von LLMs in der EU.

Kontext als Bild zu rendern sitzt am aggressiven Ende dieser Liste: hohes Sparpotenzial, echtes Korrektheitsrisiko, einen Pilotversuch auf der richtigen Nutzlast wert, sobald die sichereren Hebel stehen.

"Die Preis-Physik ist real und die Forschung ist ernst zu nehmen. Aber eine 60%-Ersparnis, die gelegentlich einen Hash oder einen Namen erfindet, ist keine Ersparnis, sondern aufgeschobenes Debugging. Rendere den Massenkontext, der nur den Sinn braucht, halte jeden exakten Wert als Text, und richte es nie auf ein Modell, das Bilder schlecht liest."