Ein Open-Source-Tool namens pxpipe nutzt eine Besonderheit in Anthropics Preismodell aus: Bilder werden nach Pixelgröße abgerechnet, nicht nach ihrem Textinhalt. Der Entwickler Steven Chong hat daraus einen lokalen Proxy für Claude Code gebaut, der umfangreiche Texteingaben in kompakte PNG-Bilder umwandelt, bevor sie an die Anthropic-API gehen – mit dem Ziel, die Token-Rechnung spürbar zu senken.
Wie pxpipe funktioniert
Laut der Projektbeschreibung auf GitHub berechnet Anthropic ein 1568 Pixel breites Bild pauschal, unabhängig davon, wie viel Text darin steckt. Bei dichten Inhalten wie Code, JSON oder Terminal-Ausgaben lassen sich dadurch etwa 3,1 Zeichen pro Bild-Token unterbringen, gegenüber rund einem Zeichen pro Text-Token bei echtem Claude-Code-Datenverkehr.
pxpipe setzt sich als lokaler Proxy zwischen den Claude-Code-Client und die Anthropic-API. Er fängt Anfragen an den /v1/messages-Endpunkt ab und rendert die umfangreichen, sich wiederholenden Teile einer Anfrage – System-Prompt, Tool-Dokumentation, ältere Chat-Historie – als PNG-Seiten, bevor er sie weiterleitet. Aktuelle Nachrichten, jüngere Gesprächsverläufe und die Modell-Ausgaben selbst bleiben davon unberührt und werden unverändert als Text übertragen.
Die Ersparnis im Detail
Nach Angaben des Projekts sinkt die Gesamtrechnung dadurch im Schnitt um 59 bis 70 Prozent, gemessen am realen Produktionslog von 13.709 Anfragen. Der niedrigere Wert von 59 Prozent bezieht sich auf die komplette Rechnung inklusive der rund 6.000 kleinen Anfragen, die pxpipe unangetastet lässt; bei den 7.756 tatsächlich komprimierten Anfragen sinken die Kosten laut Repository um 72 Prozent. In einem dokumentierten Beispiel mit Claude Fable 5 sanken die Sitzungskosten von 42,21 auf 6,06 US-Dollar.
Das Verfahren ist dabei nicht auf reine Bildgröße ausgelegt, sondern folgt einer im Repository beschriebenen Profitabilitätsschwelle: Nur Inhalte, bei denen sich die Umwandlung in ein Bild nach den gemessenen Zeichen-pro-Token-Werten tatsächlich lohnt, werden komprimiert. Locker geschriebener englischer Fließtext etwa wird als Bild teurer statt billiger und bleibt deshalb als Text erhalten.
Genauigkeit: Wo es Probleme gibt
Das Verfahren ist laut Projektbeschreibung ausdrücklich verlustbehaftet. In einem sogenannten Needle-in-Haystack-Test zur Wiedergabe exakter 12-stelliger Hexadezimal-Zeichenketten aus gerenderten Bildern erreichte das Modell Opus 0 von 15 korrekten Antworten, Fable 5 immerhin 13 von 15. Der dokumentierte Fehlermodus ist dabei nicht ein erkennbarer Fehler, sondern eine „stille Konfabulation”: Das Modell gibt einen plausiblen, aber falschen Wert zurück, ohne dies zu kennzeichnen. Für Informationen, die byte-genau erhalten bleiben müssen – IDs, Hashes, Geheimnisse, exakte Zahlen –, empfiehlt das Projekt deshalb, diese als Text zu belassen.
Standardmäßig unterstützt pxpipe deshalb nur Claude Fable 5 und GPT 5.6. Bei Opus 4.7 und 4.8 kommt es laut den im Repository dokumentierten Auswertungen bei rund 7 Prozent der gerenderten Bilder zu Lesefehlern; auch GPT 5.5 schneidet bei Bildinhalten schlechter ab. Beide Modelle sind deshalb nicht automatisch aktiviert, sondern lassen sich nur manuell über eine Konfigurationsoption zuschalten. In Benchmarks mit neuen, dem Modell unbekannten Zufallszahlen erreicht Fable 5 dagegen 100 Prozent Genauigkeit bei Rechenaufgaben – sowohl als Text als auch als gerendertes Bild.
Praxistests mit SWE-bench
Über reine Genauigkeitsbenchmarks hinaus hat das Projekt auch die Auswirkung auf komplette Programmieraufgaben getestet. Bei einem Testlauf mit zehn Aufgaben aus dem leichteren SWE-bench-Lite-Datensatz löste Claude Code mit und ohne pxpipe jeweils 10 von 10 Aufgaben, bei einer Reduktion der Anfragegröße um 65 Prozent. Bei 19 abgeschlossenen, anspruchsvolleren Paaren aus SWE-bench Pro wurden mit pxpipe 14 von 19 Aufgaben gelöst gegenüber 15 von 19 ohne Kompression, bei einer Reduktion der Anfragegröße um 60 Prozent. Die Bewertungen stimmten dabei in 18 von 19 Fällen überein; der einzige abweichende Fall ließ sich laut Projekt bei dreifacher Wiederholung durchgehend reproduzieren und wird als gewöhnliche Schwankung zwischen einzelnen Agenten-Durchläufen eingeordnet, nicht als Folge der Bildkompression.
Kein völlig neuer Gedanke
Die Idee, Text in komprimierter Bildform an KI-Modelle zu übergeben, hat einen Vorläufer: DeepSeek hat mit DeepSeek-OCR ein Modell veröffentlicht, das Textdokumente über eine 2D-Bild-Repräsentation komprimiert. Laut dem zugehörigen technischen Paper erreicht das Modell bei einem Kompressionsverhältnis von unter dem Zehnfachen eine Dekodierungsgenauigkeit von rund 97 Prozent, bei einem zwanzigfachen Verhältnis sinkt sie auf etwa 60 Prozent.
Der KI-Kommentator Chubby (@kimmonismus) ordnete pxpipe auf X entsprechend ein: DeepSeek habe das Problem als Modell- beziehungsweise Architekturfrage behandelt, pxpipe dagegen als reinen Infrastruktur-Kniff, der ausnutzt, dass aktuelle Modelle Bilder bereits gut genug lesen können. Das mache den Ansatz weniger elegant und verlustanfälliger, aber dennoch bemerkenswert.
Einordnung
pxpipe zeigt vor allem eine Lücke im aktuellen Preismodell auf, nicht primär einen technischen Durchbruch: Solange Bild-Tokens pauschal nach Pixelgröße und nicht nach Informationsgehalt abgerechnet werden, lässt sich diese Differenz für dichte, tokenreiche Inhalte wie Code gezielt ausnutzen. Die eigenen Benchmarks des Projekts dokumentieren dabei ebenso offen die Grenzen des Verfahrens – von der um rund 7 Prozent erhöhten Fehlerrate bei Opus-Modellen bis zur grundsätzlichen Ungeeignetheit für Inhalte, die byte-genau erhalten bleiben müssen. Ob sich das Preisgefüge der Modellanbieter als Reaktion auf solche Tools verändert, bleibt abzuwarten.
