← 返回首页

Une astuce virale pour réduire les coûts de Fable 5 : diminuez vos factures jusqu’à 70 % grâce au contexte basé sur des images

pxpipe montre une méthode ingénieuse pour réduire les coûts d’entrée de Fable 5 : convertir un contexte lourd en jetons en images compactes, puis laisser le modèle lire ces images via sa capacité de vision. Pour les charges de travail de programmation denses, cela peut réduire de manière significative l’utilisation de jetons côté requête et diminuer le coût global de bout en bout. Le compromis, c’est que cette méthode est avec perte. Elle peut préserver suffisamment de sens pour de nombreux flux de travail de programmation et de suivi d’état, mais il ne faut pas lui faire confiance pour une restitution exacte au byte près d’identifiants, de hachages, de secrets ou de nombres précis. L’idée plus générale est que le texte n’a pas toujours besoin de rester du texte au sein des systèmes d’IA. CLIPPO, DeepSeek-OCR et pxpipe convergent tous vers la même idée : les pixels peuvent devenir une couche de compression pratique pour les contextes longs. **Le meilleur cas d’usage est clair : compresser les contextes volumineux à faible précision, tout en conservant les valeurs exactes critiques sous forme de texte normal.**

发布于 2026年7月8日•general•GEO 评分: 0•7 次阅读
Réduction des coûts de Fable 5pxpipeRéduction des tokens de Claude CodeCompression des tokens d’imageProxy pour Claude CodeCompression du contexteContexte de l’image à partir du texteTokens d’imageAPI Messages d’AnthropicOCR DeepSeekCLIPPOCompression contextuelle optiqueOptimisation des coûts de codage IA

选择语言

العربيةDeutschEnglishEspañolFrançaisItaliano日本語한국어PortuguêsРусский中文
L’image est un visuel promotionnel pour une astuce d’économie de coûts de Fable 5, avec un fond en dégradé sombre et un motif rayonnant orange sur la droite. Dans le texte de l’image, la partie « Cost-Saving » de « Fable 5 Cost-Saving Trick » est en dégradé orange et violet, tandis que « Use pxpipe to Reduce Claude Code Token Bills by Up to 70% » apparaît en blanc. En bas, trois icônes sont visibles : une icône de fichier à gauche, une icône cylindrique avec une grille au centre, et une autre icône de fichier à droite. Cette image fait écho au contenu du document, qui explique comment pxpipe réduit jusqu’à 70 % des coûts en convertissant le contexte de Claude Code en images PNG compactes afin de diminuer l’utilisation des jetons d’entrée de Fable 5.

Une astuce d’économie sur Fable 5 devient virale : réduisez vos coûts jusqu’à 70 % grâce au contexte basé sur l’image

Introduction

Une astuce étonnamment old school a commencé à attirer l’attention dans la communauté Fable 5 : transformer un long contexte textuel en images denses, puis laisser le modèle relire ces images via sa capacité de vision.

Cela ressemble presque à la fabrication d’une petite antisèche pour un examen. Mais ici, l’« antisèche » n’est pas destinée à une personne. Elle est destinée à un modèle multimodal capable de lire des captures d’écran. Un développeur a constaté qu’en convertissant le contexte de Claude Code en images PNG très compactes, la facture de jetons en entrée pouvait baisser d’environ 59 % à 70 % sur les charges de travail testées.

L’image montre un tweet publié par @IntCyberDigest indiquant qu’en convertissant le contexte de Claude Code en images et en le faisant lire par l’OCR de Fable, il est possible de réduire le coût de Fable 5 d’environ 70 %. À gauche figure une image dense en niveaux de gris ; à droite, un texte présente pxpipe, en expliquant qu’il réduit les jetons d’entrée en rendant le contexte sous forme d’image. Le coût en jetons de l’image dépend principalement de ses dimensions en pixels plutôt que de la quantité de texte. Pour les contenus denses (code, JSON, etc.), chaque image permettrait d’économiser environ 3,1 jetons. pxpipe est un proxy local capable de réécrire les gros blocs de contenu d’une requête — invite système, documentation des outils, etc. — en images PNG compactes.

L’idée de base est simple : les invites système, la documentation des outils, les sorties de commande, les journaux et l’historique plus ancien de la conversation sont souvent extrêmement gourmands en jetons. Si ces blocs sont rendus sous forme d’images, leur coût en jetons d’image dépend principalement des dimensions de l’image, plutôt que de la quantité de texte qu’elle contient.

Cet article explique ce que fait pxpipe, pourquoi cette méthode peut faire économiser de l’argent, dans quels cas elle échoue, et comment elle s’inscrit dans la continuité de recherches antérieures comme CLIPPO ainsi que de travaux plus récents sur la compression optique du contexte, comme DeepSeek-OCR.

Note sur la source

Cet article s’appuie sur l’article original en chinois publié sur BAAI Hub, qui précise que la source provenait de QbitAI sur WeChat. Les liens de référence d’origine incluent le dépôt GitHub de pxpipe et l’article de recherche CLIPPO. Les images conservées ci-dessous sont des captures d’écran, démonstrations, schémas et captures de discussions sociales pertinents pour l’article. Les codes QR, incitations promotionnelles à suivre le compte, appels à l’engagement et éléments décoratifs sans rapport avec le sujet ont été supprimés.

Transformer le contexte en « antisèche » et réduire la facture

La méthode devenue virale s’appelle pxpipe. Il s’agit d’un proxy local open source qui réécrit le contexte d’entrée volumineux de Claude Code avant que la requête ne quitte votre machine.

Selon la description du projet, pxpipe réduit l’usage des jetons en transformant de grands blocs de texte en images. La même invite système, la documentation des outils, les sorties d’outils et l’historique plus ancien peuvent tenir dans une empreinte de jetons bien plus réduite lorsque le modèle est suffisamment capable pour lire un texte dense rendu visuellement.

L’image présente l’invite système et la documentation des outils après traitement par pxpipe, sous forme d’image. Le texte en haut indique qu’environ 48 000 caractères d’invite système et de documentation des outils nécessiteraient 25k jetons en texte brut, tandis qu’une fois rendus dans cette image, ils ne coûteraient qu’environ 2,7k jetons d’image. En dessous figure l’image réellement produite par le pipeline ; le modèle peut la lire de manière fiable, et son effet de compression donne de bons résultats dans 100/100 tests de référence. Cette illustration montre de façon intuitive la fonction centrale de pxpipe : convertir le texte en image pour réduire le nombre de jetons et donc les coûts, en écho à la présentation précédente de pxpipe comme solution de réduction des jetons par rendu d’images de gros blocs textuels.

Dans un exemple, environ 48 000 caractères d’invite système et de documentation des outils représenteraient autour de 25 000 jetons sous forme de texte brut. Rendu dans une image de 1573 × 1248, le même contenu aurait coûté environ 2 700 jetons d’image.

C’est de cette différence que provient la réduction des coûts.

L’estimation approximative

La logique est la suivante :

  1. Le coût en jetons du texte augmente avec la quantité de texte.
  2. Le coût en jetons des images est largement déterminé par leurs dimensions en pixels.
  3. Le code dense, le JSON, les sorties d’outils, les invites système et les journaux contiennent souvent beaucoup de jetons par ligne.
  4. Si le modèle peut tout de même lire l’image compressée de manière fiable, le même contexte peut devenir moins coûteux à envoyer.

Certains développeurs ont plaisanté en disant qu’il s’agissait d’un cas littéral de « une image vaut mille mots ». Dans ce cas, la blague est inhabituellement proche de la réalité technique.

L’image montre un tweet publié par Rishabh Poddar, nom d’utilisateur @rishpoddar, il y a 20 heures. Le contenu du tweet est : “A picture is worth a thousand words. Literally 😂” ainsi que « Une image vaut mille mots. Littéralement 😂 », accompagné d’un emoji rieur. Ce tweet est lié à la technologie pxpipe présentée dans le document, qui réduit l’utilisation de jetons en convertissant de grands blocs de texte en images. Le document mentionne que certains développeurs estiment qu’« une image vaut mille mots », et ce tweet en est une expression humoristique.

L’image montre une interface de tweet. En haut, on voit l’utilisateur Roman avec un badge bleu de vérification, nom d’utilisateur @romxdev, publié le 5 juillet. Le contenu du tweet est : “Don't show this to Dario 😅 Ne montre pas ça à Dario 😅”, accompagné de deux emojis rieurs. En dessous figurent 350 commentaires, et en haut à droite de l’interface, des icônes en forme de loupe et de trois points. Cette image est liée au contenu du document présentant les astuces d’économie de coûts avec pxpipe ; il s’agit peut-être d’un développeur partageant sur Twitter une anecdote ou un commentaire à propos de pxpipe.

Ce que fait réellement pxpipe

pxpipe n’est pas un nouveau modèle, et ce n’est pas un moteur OCR traditionnel. Il fonctionne comme un proxy local entre Claude Code et l’API du modèle.

Avant qu’une requête ne soit envoyée, pxpipe recherche de grands blocs adaptés à la compression. Il convertit ensuite ces blocs en pages PNG compactes et les réinsère dans la requête comme entrées d’image. Le modèle lit ces pages à l’aide de son canal de vision habituel.

L’image présente le contenu de présentation du projet pxpipe. Le titre est « About » et explique que pxpipe réduit l’utilisation de jetons dans Fable 5 en présentant le contenu textuel sous forme d’images. Le projet comprend un Readme, une licence MIT, des informations d’activité, ainsi que des données telles que 3k étoiles, 15 abonnés et 201 forks. En bas figure l’option « Report repository ». Cette image fait écho aux informations ci-dessus sur pxpipe en tant que proxy local et sur la compression de blocs de texte, et présente de manière visuelle les informations liées au projet pxpipe.

L’image montre la page GitHub du projet pxpipe. À gauche se trouve la barre de navigation du projet avec les options Code, Issues, Pull requests, Actions, Projects, Security & quality et Insights. À droite apparaît la liste des fichiers du projet, affichant plusieurs fichiers et dossiers comme gpt2, gpt2-1.5, gpt2-2.0, etc., dont certains avec une date de modification. En haut à droite de la page se trouvent le bouton « Go to file », et en bas à droite le bouton « Code ». Cette image est liée au contenu ci-dessus présentant pxpipe comme un proxy local entre Claude Code et l’API du modèle, chargé de traiter des contextes longs, et montre de façon intuitive l’interface GitHub du projet pxpipe.

En termes simples, pxpipe se comporte comme une micro-imprimante automatique pour les contextes longs. Il ne fait pas « OCRiser » le texte au modèle au sens strict de l’ingénierie. Il s’appuie plutôt sur la capacité intégrée du modèle à lire des entrées visuelles de type capture d’écran.

Le README de pxpipe explique qu’il se concentre sur des contextes d’entrée volumineux tels que :

  • Les grands corps de tool_result, y compris les lectures de fichiers, les sorties de commandes et les journaux.
  • Les anciennes portions repliées de l’historique de conversation.
  • Les invites système statiques et la documentation des outils.

Il évite délibérément de tout convertir. Les échanges récents, les messages utilisateur, les identifiants exacts, les petits blocs, la prose aérée et les sorties du modèle restent du texte.

Pourquoi cela peut permettre d’économiser autant

Le décalage fondamental de tarification est que les entrées d’image et le texte

les entrées sont mesurées différemment.

Pour les flux de travail de développement très axés sur le texte, le matériau source est souvent dense en tokens. Le code, les journaux, le JSON, les traces de pile et les schémas d’outils peuvent coûter cher lorsqu’ils sont envoyés en texte brut. L’auteur de pxpipe estime que, dans le trafic réel de Claude Code, le contenu dense peut atteindre environ 3,1 caractères par token d’image, contre environ 1 caractère par token de texte.

Ce ratio laisse à pxpipe une marge pour réduire les coûts lorsque le texte est suffisamment dense.

L’auteur a également partagé une démonstration comparative. Dans la version texte d’origine, une exécution de test se serait terminée avec une facture de 42,21 $ et une fenêtre de contexte presque pleine. Dans la version pxpipe, la même tâche a été accomplie pour 6,06 $, avec beaucoup plus d’espace de contexte restant.

L’image montre une comparaison des économies de coût avant et après l’utilisation de pxpipe dans Fable 5. À gauche, la version texte d’origine affiche une facture de 42,21 $ à la fin de l’exécution du test, avec une fenêtre de contexte presque pleine. À droite, la version pxpipe montre que la même tâche est terminée avec une facture de 6,06 $ et un espace de contexte largement disponible. L’image est étroitement liée au contexte et illustre de façon claire l’effet de pxpipe sur la réduction des coûts, en montrant par des données concrètes que pxpipe peut diminuer significativement les dépenses dans les flux de travail de développement à forte densité textuelle.

Le point important est que pxpipe ne compresse que la partie requête. La réponse du modèle continue d’être renvoyée normalement sous forme de texte. Il ne compresse pas les tokens de sortie.

Résultats du benchmark et principale réserve

La méthode est impressionnante, mais elle n’est pas sans perte. Le contexte d’image dense dépend fortement de la capacité du modèle à lire visuellement.

La capture d’écran du benchmark pxpipe montre que Fable 5 obtient de bons résultats sur plusieurs tâches de contexte image, notamment l’arithmétique inédite, le rappel de l’idée générale, le suivi d’état et certains tests de rappel sur des rendus denses. Mais le rappel exact de chaînes de caractères est un point faible, surtout sur les modèles qui ne sont pas de bons lecteurs de texte dense.

L’image présente des données de performance de Fable 5 sur différentes tâches de test. Le tableau contient des colonnes telles que test, nombre d’échantillons N, texte, pxpipe (image) et tokens. Par exemple, dans le test « novel arithmetic », les résultats texte pour claude-fable-5 et claude-opus-4-8 sont tous deux de 100 %, tandis que pxpipe (image) est respectivement à 100 % et 93 %, avec dans les deux cas une variation des tokens de -38 %. On y trouve aussi des données pour « gist recall A/B », « state tracking » et d’autres tests. Cette image est étroitement liée au contexte et offre une représentation visuelle directe des performances de Fable 5 dans les tâches image-texte décrites dans le document.

Une version simplifiée du tableau de benchmark rapporté ressemble à ceci :

Test N Texte Image pxpipe Variation des tokens
Arithmétique inédite, claude-fable-5 100 100 % 100 % -38 %
Arithmétique inédite, claude-opus-4-8 100 100 % 93 % -38 %
Rappel de l’idée générale A/B, Fable 5 98 par groupe 98/98 98/98 —
Suivi d’état, Fable 5 18 par groupe 18/18 18/18 —
Confabulation sur des faits jamais énoncés, Fable 5 16 par groupe 0/16 0/16 —
Rappel mot à mot d’un hexadécimal de 12 caractères, Opus 15 15/15 0/15 —
Rappel mot à mot d’un hexadécimal de 12 caractères, Fable 5 15 — 13/15 —

Le danger est clair : le contexte basé sur l’image peut être suffisant pour une compréhension sémantique globale, le suivi d’état et de nombreuses tâches de codage, mais il peut mal lire silencieusement des chaînes exactes.

Les identifiants, hachages, secrets, nombres fixes et autres valeurs exactes au byte près ne devraient pas être intégrés dans des images denses. Les propres notes de pxpipe soulignent ce point : le compromis est sérieux, et le mode d’échec peut prendre la forme d’une réponse assurée mais erronée plutôt que d’une erreur évidente.

L’image montre deux publications sur X. La publication du haut, postée par @IntCyberDigest, avertit que lors de l’utilisation de pxpipe, il existe un risque à intégrer dans des images denses des chaînes exactes telles que des identifiants, des hash, des clés secrètes, etc., car les données peuvent se perdre pendant la transmission et être mal interprétées.

Le tweet ci-dessous est une réponse de @sanixdarker, qui affirme que cette pratique n’a rien de nouveau : il procède ainsi depuis la sortie d’Opus, et cela n’a pas de lien direct avec la série Fable. L’image est étroitement liée au contexte et illustre de façon intuitive la discussion sur les risques potentiels liés à l’injection de certaines données dans des images denses.](https://we0-cms.oss-cn-beijing.aliyuncs.com/cms-assets/image/2026/07/8d83ec15-fc8e-4019-8909-2d441f51f258-10-af6628e8-7211-4ee2-8a25-33b3a4e2a529.png)

Ce que pxpipe conserve sous forme de texte

Comme la compression est avec perte, pxpipe ne convertit pas aveuglément chaque bloc d’entrée en image. Il conserve sous forme textuelle les contenus sensibles et ceux pour lesquels la précision est essentielle.

Voici des exemples de contenus qui devraient rester sous forme de texte normal :

  • Les identifiants et les hachages.
  • Les secrets et les clés.
  • Les valeurs numériques exactes.
  • Les tours de conversation récemment actifs.
  • Les messages des utilisateurs.
  • Le texte peu dense, qui n’est pas assez riche en jetons pour en tirer un bénéfice.

C’est aussi pour cette raison que le projet présente les économies comme dépendantes de la charge de travail. Si la requête consiste principalement en longs textes en langue naturelle, la compression peut ne pas être rentable. Si, en revanche, la requête contient beaucoup de code, de JSON, de journaux et de sorties d’outils, les économies peuvent être bien plus importantes.

Comment essayer pxpipe

L’auteur propose une procédure de démarrage très simple. Exécutez le proxy localement, puis pointez Claude Code vers ce proxy.

npx pxpipe-proxy                                  # proxy sur 127.0.0.1:47821
ANTHROPIC_BASE_URL=http://127.0.0.1:47821 claude  # faire pointer Claude Code dessus

Après le démarrage, pxpipe expose également un tableau de bord local :

http://127.0.0.1:47821/

Le tableau de bord peut afficher les économies de jetons, des conversions texte-image côte à côte, un interrupteur d’arrêt et des étiquettes de modèle en direct. Cela permet de voir plus facilement exactement ce qui est compressé et ce qui passe inchangé.

L’article CLIPPO de Google en 2022 allait déjà dans cette direction

Après la diffusion de pxpipe, certains chercheurs ont souligné que l’idée de base n’était pas entièrement nouvelle.

Une ligne de recherche connexe est apparue dans l’article de Google de 2022, CLIPPO: Image-and-Language Understanding from Pixels Only. L’idée centrale de CLIPPO est de traiter le texte comme des pixels plutôt que comme un flux de texte tokenisé distinct.

L’image montre un tweet de Lucas Beyer au sujet des techniques de réduction des coûts de Fable 5. Il y explique que lorsque des laboratoires de pointe réduisent soudainement les coûts ou affirment avoir « trouvé un moyen de réduire massivement la mémoire nécessaire à l’inférence », le secret est que la vision finit toujours par l’emporter. L’image présente également l’article CLIPPO publié par Google Research, dont l’idée centrale est de traiter le texte comme des pixels plutôt que comme un flux textuel distinct ; en faisant passer à la fois les images et le texte rendu par un Vision Transformer partagé, CLIPPO peut, à nombre de paramètres égal, accomplir des tâches d’image, de texte et multimodales par rapport aux modèles traditionnels de type CLIP, tout en divisant par deux le temps d’entraînement.

Les modèles traditionnels de type CLIP utilisent souvent deux branches : une pour les images et une pour le texte. CLIPPO supprime cette séparation en restituant le texte sous forme d’images RVB et en envoyant à la fois les images et le texte rendu dans un Vision Transformer partagé.

L’image montre une comparaison des architectures de modèles CLIP et CLIPPO. À gauche, dans le modèle CLIP, l’image passe par une couche CONV avant d’entrer dans le Vision Transformer, tandis que le texte passe par WORD EMB et TOK avant d’entrer dans le Text Transformer ; les deux interagissent ensuite de manière contrastive. À droite, dans le modèle CLIPPO, l’image et le texte passent tous deux par une couche CONV avant d’entrer dans le Transformer, supprimant ainsi le traitement séparé de l’image et du texte. Cette figure est étroitement liée au contexte et illustre de manière intuitive l’idée centrale de CLIPPO, qui consiste à traiter le texte comme une image RVB et à utiliser un Vision Transformer partagé ; c’est un exemple clé pour comprendre l’architecture du modèle CLIPPO.

L’idée essentielle est importante : le texte n’a pas toujours besoin d’entrer dans un modèle sous forme de jetons textuels discrets. Il peut aussi être converti en pixels et traité via des voies visuelles.

DeepSeek-OCR et la compression optique du contexte

La discussion aussi

a évoqué DeepSeek-OCR, qui se concentre sur la compression optique pour les contextes longs. Son dépôt décrit le projet comme « Contexts Optical Compression ».

L’image montre deux publications sur X. Celle du haut, publiée par JQ, indique qu’il y a environ un an, DeepSeek avait tenté dans son projet DeepSeek OCR une technique consistant à traiter le texte comme une image, ce qui avait alors suscité de l’enthousiasme quant aux possibilités de compression. En dessous, Lucas Beyer répond qu’il s’en souvient vaguement. Ces deux publications sont liées à la discussion du document sur pxpipe, DeepSeek-OCR et des techniques similaires, et montrent que pxpipe n’est pas seulement une astuce ponctuelle pour réduire les coûts, mais s’inscrit aussi dans la tendance de la compression optique.

L’image montre une page GitHub dont le titre est « deepseek - ai/DeepSeek - OCR: Contexts Optical Compression ». La page indique 1 contributeur, 248 issues, 23 k étoiles et 2 k forks. En dessous figure un commentaire de Matthew Campbell mentionnant que DeepSeek avait déjà publié quelque chose de similaire en octobre 2025, sans qu’il soit clair ce qu’il y a de nouveau cette fois-ci. Cette image est liée à la discussion du document sur pxpipe et DeepSeek-OCR, et suggère que pxpipe présente des similitudes avec DeepSeek-OCR en matière de compression optique, ce qui amène à s’interroger sur leur relation.

En ce sens, pxpipe n’est pas simplement une astuce ponctuelle de réduction des coûts. Il s’inscrit dans plusieurs tendances :

  1. CLIPPO a montré que le texte peut être traité comme des images.
  2. DeepSeek-OCR a exploré la compression optique pour les contextes longs.
  3. Fable 5 semble assez performant en lecture visuelle dense pour que cela devienne utile dans de vrais workflows de programmation.

Il reste toutefois une limite majeure : la fiabilité des chaînes exactes. Certains commentateurs ont suggéré que le problème pourrait simplement s’améliorer en augmentant l’échelle de modèles vision-langage plus puissants.

Cette image montre un échange de deux publications sur un réseau social discutant de problèmes techniques liés à pxpipe. Shardul souligne dans sa publication l’inconvénient de la perte d’information : des éléments qui exigent une exactitude totale, comme les identifiants ou les valeurs de hachage, peuvent être mal interprétés. Lucas Beyer répond brièvement dans une autre publication qu’il suffirait d’augmenter la taille du modèle pour résoudre ce problème. Cet échange correspond au passage du document mentionnant la limite de pxpipe en matière de « fiabilité des chaînes exactes » et la nécessité de l’améliorer à l’aide de modèles vision-langage plus puissants.

Points pratiques à retenir

pxpipe est surtout utile lorsque le contexte est volumineux, dense et ne demande pas une précision critique. Les sessions de programmation s’y prêtent naturellement, car les agents relisent souvent les fichiers avant de les modifier, ce qui peut réduire le risque d’agir sur la base d’un bloc d’image mal interprété.

Il est moins adapté aux workflows où le rappel exact au caractère près est important. Si une tâche dépend d’identifiants, de valeurs de hachage, de secrets d’authentification, d’un libellé juridique exact, de chiffres financiers ou d’autres contenus similaires sensibles à la précision, la compression basée sur l’image doit être utilisée avec prudence.

Une manière raisonnable d’utiliser pxpipe consiste à le garder comme couche d’optimisation, et non comme frontière de confiance. Laissez-le compresser les contextes volumineux là où l’économie est réelle, mais conservez les valeurs critiques sous forme textuelle et consultez le tableau de bord lorsque vous déboguez un comportement étrange du modèle.

FAQ

Qu’est-ce que pxpipe ?

pxpipe est un proxy local qui réduit l’usage de tokens en convertissant les entrées contextuelles volumineuses de Claude Code en images PNG compactes. Il est conçu pour les contextes denses tels que les sorties d’outils, les journaux, le code, les prompts système et l’historique plus ancien des conversations.

Comment pxpipe réduit-il les coûts de Fable 5 ?

Il exploite le fait que le coût en tokens des images dépend principalement des dimensions en pixels, tandis que le coût en tokens du texte augmente avec la quantité de texte. Si un modèle peut lire de manière fiable du texte dense rendu visuellement, de gros blocs peuvent coûter moins cher sous forme d’images que sous forme de texte brut.

Est-ce que pxpipe compresse la sortie du modèle ?

Non. pxpipe compresse uniquement certains blocs d’entrée sélectionnés avant l’envoi de la requête. Le modèle၏

la réponse continue d’être diffusée normalement sous forme de texte, donc les jetons de sortie ne sont pas réduits.

La compression du contexte basée sur l’image est-elle sans perte ?

Non. Il s’agit d’une méthode de compression avec perte. Elle peut bien fonctionner pour le contexte général, le suivi d’état et de nombreuses tâches de programmation, mais les chaînes exactes telles que les identifiants, les hachages, les secrets et les nombres précis peuvent être mal interprétées.

Puis-je utiliser pxpipe avec n’importe quel modèle ?

Pas en toute sécurité. La propre documentation de pxpipe considère que la prise en charge des modèles est limitée et dépend de la charge de travail. Certains modèles lisent beaucoup moins bien le texte dense rendu en image que d’autres ; les modèles non pris en charge ou plus faibles devraient donc rester en texte, sauf activation explicite.

Quels types de contenu doivent rester sous forme de texte ?

Les identifiants, les hachages, les secrets, les nombres exacts, les messages des utilisateurs, les échanges récents et les autres blocs nécessitant une grande précision doivent rester sous forme de texte. pxpipe convient mieux aux contenus longs, denses et moins sensibles à l’exactitude octet par octet, comme les journaux, la documentation d’outils et l’ancien historique.

Comment exécuter pxpipe en local ?

Démarrez le proxy avec npx pxpipe-proxy, puis lancez Claude Code avec ANTHROPIC_BASE_URL=http://127.0.0.1:47821 claude. Le tableau de bord local est disponible à l’adresse http://127.0.0.1:47821/.

Outils associés

  • pxpipe : Un proxy local qui convertit le contexte volumineux de Claude Code en images PNG afin de réduire l’utilisation des jetons d’entrée.
  • Claude Code : L’outil de codage agentique d’Anthropic pour les flux de travail dans le terminal, l’IDE, le bureau et le navigateur.
  • Anthropic Messages API : L’interface API par laquelle transitent les requêtes de type messages au format Claude.
  • Anthropic Token Counting : La référence API officielle pour estimer le nombre de jetons dans les requêtes de messages.
  • DeepSeek-OCR : Un projet open source explorant la compression optique pour le texte à long contexte.

Liens associés

Résumé

pxpipe montre une manière ingénieuse de réduire les coûts d’entrée de Fable 5 : convertir un contexte lourd en jetons en images compactes et laisser le modèle lire ces images grâce à sa capacité de vision. Pour les charges de travail de programmation denses, cela peut réduire de manière significative le côté requête

utilisation de jetons et coût global de bout en bout réduit.

Le compromis, c’est que la méthode est avec perte. Elle peut préserver suffisamment de sens pour de nombreux flux de travail de codage et de suivi d’état, mais on ne doit pas lui faire confiance pour une restitution exacte à l’octet près des identifiants, hachages, secrets ou nombres précis.

L’idée plus générale est que le texte n’a pas toujours besoin de rester du texte au sein des systèmes d’IA. CLIPPO, DeepSeek-OCR et pxpipe convergent tous vers la même idée : les pixels peuvent devenir une couche de compression pratique pour les longs contextes.

Le meilleur cas d’usage est clair : compresser un contexte volumineux et de faible précision, tout en conservant les valeurs exactes critiques sous forme de texte normal.

A Fable 5 Cost-Saving Trick Goes Viral: Cut Bills by Up to 70% with Image-Based Context