- pxpipe indique réduire les tokens d’entrée en convertissant en images PNG, via un proxy local, les grands contextes des requêtes Claude Code, ce qui abaisse d’environ 59 à 70 % le montant facturé de bout en bout aux tarifs actuels de Fable
- Le principe clé est que le coût en tokens d’une image dépend non pas de la quantité de texte qu’elle contient, mais de sa taille en pixels ; dans le trafic réel de Claude Code, les textes denses comme le code, le JSON ou les sorties d’outils contiennent environ 3,1 caractères par token image, contre environ 1 caractère par token texte
- La compression cible les gros
tool_result, l’ancien historique replié, les prompts système statiques et la documentation des outils ; les tours récents, les messages utilisateur, les sorties du modèle, la prose peu dense et les modèles hors liste d’autorisation passent tels quels en texte
- Comme il s’agit d’une méthode avec perte, le rappel exact de chaînes hexadécimales de 12 caractères atteint 13/15 avec Fable 5 et 0/15 avec Opus ; les omissions peuvent apparaître non pas comme des erreurs, mais comme des réponses plausibles mais fausses, si bien que les valeurs devant être exactes au byte près — ID, hash, secrets — doivent rester en texte
- Les modèles ciblés par défaut sont
claude-fable-5,gpt-5.6 ; Opus 4.7/4.8 et GPT 5.5 ne sont utilisables qu’en opt-in en raison de performances moindres pour lire le contexte image, et l’application réelle ainsi que les économies par requête sont vérifiables dans ~/.pxpipe/events.jsonl
Le coût que pxpipe cherche à réduire
- pxpipe est un proxy local qui rend les grands contextes sous forme d’images afin de réduire les tokens d’entrée de Claude Code
- Il cible les blocs d’entrée volumineux du corps de requête, comme le prompt système, la documentation des outils, l’historique passé et les grandes sorties d’outils
- Les sorties du modèle ne sont pas compressées, et le streaming des réponses fonctionne normalement
- Le coût en tokens d’une image est déterminé par sa taille en pixels, et non par le nombre de caractères qu’elle contient
- Dans le trafic réel de Claude Code, un contenu dense contient environ 3,1 caractères par token image
- Les tokens texte ont été mesurés à environ 1 caractère
- Un rendu d’exemple place environ 48 000 caractères de prompt système et de documentation d’outils dans une seule image de 1573×1248 ; il faut environ 25 000 tokens en texte, contre environ 2 700 tokens image
Exécution et dashboard
npx pxpipe-proxy # proxy on 127.0.0.1:47821
ANTHROPIC_BASE_URL=http://127.0.0.1:47821 claude # point Claude Code at it
- Le proxy s’exécute sur
127.0.0.1:47821
- Le dashboard est disponible à l’adresse
http://127.0.0.1:47821/
- Nombre de tokens économisés
- Comparaison côte à côte texte→image
- Kill switch
- Chip de modèle en temps réel
- Les tours récents restent en texte, tandis que le prompt système, la documentation des outils et les anciens historiques volumineux sont transformés en images
Résultats observés dans la démo
- Fable 5 est le choix par défaut et le README le présente comme un modèle de lecture 100/100
- Il retrouve correctement 10/10 comptages de tokens exacts dans 39 fichiers filler transformés en images
- Il correspond ligne par ligne au résultat de
grep
- Il réussit une arithmétique de ledger en plusieurs étapes
- Le coût de session est présenté à 6,06 $ avec pxpipe, contre 42,21 $ en texte standard
- Côté pxpipe, un nudging a été nécessaire une fois pour respecter le format de sortie sur une ligne demandé
- Opus 4.8 est désactivé par défaut
- Les needles textuels sont lus des deux côtés
- Le comptage de phrases transformé en image n’a pas été lu par Opus, et pxpipe a signalé l’échec sans inventer de nombre
- En raison de ce taux de mauvaise lecture, Opus est réservé à l’opt-in
Précision et caractère avec perte
- pxpipe est une méthode de compression avec perte
- Dans du contenu image dense, les résultats de rappel exact de chaînes hexadécimales de 12 caractères varient fortement selon le modèle
- Fable 5 : 13/15
- Opus : 0/15
- Les omissions peuvent ne pas se manifester comme des erreurs, mais comme une confabulation silencieuse
- Les valeurs nécessitant une exactitude au byte près, comme les ID, hash et secrets, doivent rester en texte
- Aucun guard dédié au risque de verbatim n’est encore intégré
- Un subagent utilisant un modèle hors liste d’autorisation peut être laissé en texte
CLAUDE_CODE_SUBAGENT_MODEL=claude-sonnet-4-6model: sonnet dans le frontmatter de l’agent
Benchmarks et mesures
- Un benchmark fondé sur de nouveaux problèmes à nombres aléatoires utilise des questions que le modèle a peu de chances d’avoir mémorisées
| Test |
N |
Texte |
Images pxpipe |
Tokens |
novel arithmetic, claude-fable-5 |
100 |
100% |
100% |
−38% |
novel arithmetic, claude-opus-4-8 |
100 |
100% |
93% |
−38% |
| gist recall A/B, Fable 5 |
98/arm |
98/98 |
98/98 |
- |
| state tracking, Fable 5 |
18/arm |
18/18 |
18/18 |
- |
| never-stated facts confabulation, Fable 5 |
16/arm |
0/16 |
0/16 |
- |
| verbatim 12-char hex recall, dense render, Opus |
15 |
15/15 |
0/15 |
- |
| verbatim 12-char hex recall, dense render, Fable 5 |
15 |
- |
13/15 |
- |
- Le pilote SWE-bench Lite atteint 10/10 des deux côtés, avec une taille de requête réduite de 65 %
- SWE-bench Pro donne ON 14/19 et OFF 15/19, avec une taille de requête réduite de 60 %
- Le verdict concorde sur 18/19 cas
- Le cas de split a été résolu à nouveau en 3/3 lors d’exécutions répliquées
- Le README traite cela comme une variabilité entre exécutions, et non comme un problème de compression
- Il est accompagné d’une réserve liée à la petite taille de l’échantillon
- GSM8K atteint 96 % avec l’imagerie, mais comme il peut être inclus dans les données d’entraînement, le README met en avant l’évaluation novel-number
Fonctionnement
tool_result string ──► wrap at 1928px-wide columns ──► pack ~92,000 chars/page ──► PNG[]
- Le proxy intercepte
/v1/messages et réécrit les entrées volumineuses appropriées en image block
- Les blocs convertis sont réinsérés de manière favorable au cache, avec préservation du préfixe statique afin que le prompt caching continue de fonctionner
- Une image de 1928×1928 utilise environ 4 761 vision tokens et contient environ 92 000 caractères
- Pour que le texte soit avantageux, il faudrait dépasser environ 19 caractères/token, alors que le trafic Claude Code a été mesuré à environ 1,91 sur N=391
- Un estimateur par requête décide s’il faut transformer en image ; la prose peu dense reste en texte
- Les événements sont enregistrés dans
~/.pxpipe/events.jsonl
Ce qui est compressé et ce qui reste inchangé
- Trois types de blocs d’entrée sont ciblés pour la compression, tous derrière un seuil de rentabilité
- Corps
tool_result denses en tokens d’environ 6 000 caractères ou plus
- Ancien historique replié derrière le live tail
- Slab statique de prompt système et de documentation d’outils
- Les éléments qui passent tels quels sont également explicités
- Messages utilisateur
- Tours récents
- Sorties du modèle
- Prose peu dense
- Blocs trop petits pour apporter un gain
- Modèles hors liste d’autorisation
- Le périmètre par défaut couvre Fable 5 et GPT 5.6
- Opus 4.8 et GPT 5.5 lisant moins bien le contenu image, ils doivent être explicitement activés via le dashboard ou
PXPIPE_MODELS
PXPIPE_MODELS=off désactive la transformation en images- Sur le chemin GPT, les définitions d’outils restent en JSON natif et n’utilisent pas les marqueurs
cache_control d’Anthropic
Méthode de calcul des coûts
- Le taux d’économie affiché en headline se base non pas uniquement sur les tranches d’entrée, mais sur le montant total facturé
- Sur un snapshot de 13 709 requêtes, 100 $ descendent à environ 41 $, soit 59 % d’économie
- Sur une trace ultérieure de 8 904 requêtes compressées, le taux mesuré est d’environ 70 %
- En ne considérant que les requêtes compressées, l’économie atteint 72 à 74 %, mais le README ne l’utilise pas comme headline
- Pour chaque POST
/v1/messages, un counterfactual gratuit count_tokens est exécuté en parallèle sur le corps original non compressé
- L’usage réellement facturé est lu dans le bloc
usage de la réponse Anthropic
- L’original et l’usage réel sont enregistrés sur la même ligne de
~/.pxpipe/events.jsonl, afin d’éviter les biais de nombre de tours ou de variation d’une exécution à l’autre
- La conversion en dollars utilise les ratios du tarif public de Fable 5
- input ×1.0
- cache write ×1.25
- cache read ×0.1
- output ×5
- Les tarifs de cache étant appliqués de façon identique des deux côtés, la remise de cache n’est pas comptée deux fois comme une économie
Utilisation comme bibliothèque
import { renderTextToPngs, transformAnthropicMessages } from "pxpipe";
const imgs = await renderTextToPngs(toolResultText); // RenderedImage[]
const { body, applied, info } = await transformAnthropicMessages({
body: requestBytes,
model: "claude-fable-5",
});
- Il peut aussi être utilisé comme bibliothèque sans proxy
options.keepSharp(block) force certains blocs à rester en texteoptions.emitRecoverable retourne l’original des blocs transformés en images- Le runtime est en pur JS et prend en charge Node ainsi que les environnements edge/Workers
@napi-rs/canvas n’est utilisé qu’au build time- L’API complète se trouve dans
src/core/index.ts
Échecs réels et limites
- En quelques semaines d’usage quotidien, un cas s’est produit où un nom de personne a été rappelé de façon assurée mais incorrecte depuis un historique de chat transformé en image
- Les sessions de code tolèrent ce mode d’échec, car les fichiers sont relus avant modification, mais le rappel en chat pur ne bénéficie pas de la même vérification
- Le legibility audit mesure le rappel exact de chaînes depuis les pages rendues
- La lecture à l’aveugle d’identifiers denses a atteint au maximum 63 %
- Tous les ratés étaient prédits par une matrice de confusion de glyphes
- Une mitigation limite la géométrie des pages pour respecter le cap de resampling de l’API
- Les identifiers exacts comme les SHA et les nombres sont également inclus en texte
- Les limites sont aussi explicitées
- Le rappel verbatim à partir d’images est peu fiable
- Les grosses requêtes ajoutent un délai d’encodage PNG avant l’envoi
- ASCII/Latin-1 est bien testé
- CJK fonctionne, mais est traité de façon conservatrice
Développement et roadmap
pnpm install && pnpm test
pnpm run build # regenerates dist/
- Les commandes de développement couvrent l’installation, les tests et le build
- La licence est MIT
- La roadmap est présentée uniquement sous forme d’hypothèses ; sans chiffres ni taille d’échantillon, elle ne doit pas être traitée comme une claim
- Rendu de glyphes plus net
- Vérifier si les bulk transformés en images peuvent approximativement doubler le contexte effectif dans la même fenêtre de 1M
- Vérifier si un active context plus petit améliore la précision des tâches longues
1 commentaires
Commentaires sur Hacker News
Rien qu’avec Gemini, il me semble que lors du traitement d’un PDF, il fait d’abord de l’OCR, puis envoie ensemble le texte et les images au modèle, sans facturer le coût des jetons de texte
Si le backend de Claude fait la même chose, ce hack ressemble davantage à une faille du mode de facturation des jetons, et si Claude se met à fonctionner comme Gemini, il y a de fortes chances que cela soit bloqué plus tard
Mais dans un commentaire ci-dessous, quelqu’un dit que DeepSeek a fortement amélioré le taux de compression avec des jetons visuels : https://news.ycombinator.com/item?id=48777848
Je ne comprends pas tous les détails techniques internes, donc j’ai encore du mal à voir comment la voie OCR pourrait réellement réduire la consommation électrique ou le coût de calcul global
Lorsqu’on envoie une image à un LLM, une méthode consiste à la découper en tuiles, à faire passer ces tuiles dans un réseau neuronal vision encoder pour produire des jetons visuels, puis à les injecter dans le LLM comme des jetons de texte. Bien sûr, le vision encoder et le LLM sont entraînés pour se comprendre mutuellement. On appelle ce type d’approche un modèle OCR de bout en bout
Une fois qu’un modèle entraîné de cette manière existe, on peut agrandir ou réduire une image de document pour faire varier le nombre de jetons visuels utilisés pour représenter le même document texte, et on peut aussi ajuster des paramètres comme la taille des patchs ou la complexité du vision encoder
Les résultats étaient plutôt bons, et sur certains tests, ils ont réduit les jetons d’entrée de 90 % tout en conservant 97 % des performances en sortie
J’ai essayé la même chose l’an dernier avec des modèles OpenAI, et à l’époque cela aidait à réduire les jetons du prompt, mais il fallait beaucoup plus de jetons de complétion, donc au final c’était plus cher et plus lent
https://pagewatch.ai/blog/post/llm-text-as-image-tokens/
Aïe, ça fait mal aux yeux. On dirait un README codé en vibe
Par exemple :
On peut vraiment créer des choses utiles avec l’IA, surtout dans un domaine où l’on a déjà de l’expertise. Mais dans ce cas, il faut 1) indiquer qu’on a utilisé l’aide de l’IA et 2) expliquer avec ses propres mots ce qu’on a exactement construit. Pouvoir aussi parler des limites quand on travaille avec l’IA, c’est encore mieux
C’est ce qui inspire confiance et fait penser : « ce que cette personne a créé mérite qu’on s’y intéresse, elle comprend bien ce qu’elle a construit »
Aujourd’hui, 99 % de ce qui sort vient de gens qui travaillent dans des domaines qu’ils ne comprennent pas du tout, donc quand je vois ce genre de README, je ferme simplement l’onglet
Ça ressemble à un hack de tarification qui brûle des ressources. Si la faille est colmatée, le prix de l’OCR ne devrait-il pas augmenter ?
En y réfléchissant, c’est logique. Les humains lisent aussi le code mot par mot, mais la plupart du temps, on le parcourt rapidement et on comprend grossièrement ce qu’il fait par reconnaissance de motifs. On ne se concentre sur des parties précises que lorsqu’il faut répondre à une question spécifique
On peut dire que les humains appliquent eux aussi naturellement une optimisation par contournement similaire
Article connexe : https://blog.can.ac/2026/06/10/snapcompact/
Il faut faire attention avec cette approche. Si les coûts baissent, c’est peut-être simplement parce qu’on bascule en réalité vers un autre modèle moins performant
En apparence, cela ressemble à Fable, mais en pratique, ce n’en est peut-être pas un. Dans ce cas, on fait du travail supplémentaire pour rien, et il vaudrait peut-être mieux revenir au modèle opus 4.8
Il semble que Oh-My-Pi(OMP.sh) utilise déjà des images pour la compression du contexte. OMP est construit au-dessus de l’agent de code Pi
Il existe aussi un livre blanc DeepSeek sur cette technique : https://www.seangoedecke.com/text-tokens-as-image-tokens
J’ai vu il y a quelque temps le tweet de quelqu’un — probablement Carmack, Geohot ou Karpathy — qui disait qu’une image pourrait être une meilleure option
Depuis, quand j’explique à un agent ce qui se passe à l’instant T, j’utilise des images avec des prompts composés de phrases très simples, et il m’arrive même de ne mettre aucun texte dans le prompt
Les résultats ont été très bons
Cela dit, ce n’est pas exactement la même chose que ce dont parlait Karpathy. Mais cette idée m’a quand même conduit à un meilleur flux de travail
Désolé, mais c’est absurde. Ça fonctionne et c’est malin, mais c’est clairement une manière de contourner un échec de tarification
Comme avec une prime aux cobras qui pousse les gens à élever des serpents, cela exploite et encourage le gaspillage
Au fond, je pense que c’est la mauvaise structure tarifaire d’Anthropic qui est responsable de cette possibilité d’arbitrage. Mais jusqu’à ce que ce soit corrigé, voir des gens se ruer dessus et déverser encore plus de déchets numériques totalement inutiles est écœurant