Fable लागत में 60% कटौती: कोड को इमेज में बदलकर मॉडल से OCR करवाना

 (github.com/teamchong)
4 पॉइंट द्वारा GN⁺ 5 시간 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • pxpipe Claude Code अनुरोधों के बड़े context को लोकल proxy में PNG इमेज में बदलकर input tokens घटाता है, और Fable की मौजूदा सूची कीमत के आधार पर end-to-end बिलिंग को लगभग 59~70% कम करने का दावा करता है
  • इसका मुख्य सिद्धांत यह है कि image token की लागत इमेज के भीतर मौजूद टेक्स्ट की मात्रा से नहीं, बल्कि pixel size से तय होती है; कोड, JSON और tool output जैसे dense text में वास्तविक Claude Code ट्रैफ़िक पर प्रति image token लगभग 3.1 अक्षर, जबकि text token पर लगभग 1 अक्षर समाते हैं
  • compression के लक्ष्य बड़े tool_result, पुरानी folded history, और static system prompt व tool documentation हैं; हाल की turns, user messages, model output, sparse prose और allowlist के बाहर के models जैसे-के-तैसे text में पास होते हैं
  • यह lossy तरीका है, इसलिए सटीक 12-अक्षरीय hex string recall में Fable 5 ने 15 में 13 और Opus ने 15 में 0 स्कोर किया; छूटी हुई चीज़ें error की तरह नहीं बल्कि विश्वसनीय गलत जवाब की तरह दिख सकती हैं, इसलिए ID, hash और secret जैसे byte-accurate मान text में ही रखने चाहिए
  • डिफ़ॉल्ट target models claude-fable-5,gpt-5.6 हैं; Opus 4.7/4.8 और GPT 5.5 को image context पढ़ने की कमज़ोर क्षमता के कारण केवल opt-in रखा गया है, और वास्तविक लागू होना व बचत की मात्रा ~/.pxpipe/events.jsonl में per-request देखी जा सकती है

pxpipe किस लागत को घटाना चाहता है

  • pxpipe Claude Code के input tokens कम करने के लिए बड़े context को इमेज के रूप में render करने वाला लोकल proxy है
  • इसका लक्ष्य system prompt, tool docs, पुरानी history और बड़े tool outputs जैसे request body के bulky input blocks हैं
  • model output compress नहीं किया जाता, और response streaming सामान्य रूप से काम करती है
  • इमेज की token लागत इमेज के भीतर के अक्षरों की संख्या से नहीं, बल्कि pixel size से तय होती है
    • वास्तविक Claude Code ट्रैफ़िक में dense content में प्रति image token लगभग 3.1 अक्षर समाते हैं
    • text token लगभग 1 अक्षर के स्तर पर मापा गया
  • उदाहरण render में लगभग 48k अक्षरों का system prompt और tool docs एक 1573×1248 इमेज में रखे गए, और text के रूप में लगभग 25k tokens, जबकि image के रूप में लगभग 2.7k image tokens लगे

रन करना और 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
  • proxy 127.0.0.1:47821 पर चलता है
  • dashboard http://127.0.0.1:47821/ पर उपलब्ध है
    • बचाए गए tokens
    • text→image conversion का side-by-side comparison
    • kill switch
    • real-time model chips
  • हाल की turns text में रखी जाती हैं, जबकि system prompt, tool docs और पुरानी बड़ी history को image में बदला जाता है

डेमो में दिखे नतीजे

  • Fable 5 डिफ़ॉल्ट है, और README में इसे 100/100 readability model के रूप में दिखाया गया है
    • 39 image-converted filler files में सटीक token count 10/10 सही रहा
    • grep results से line-by-line मेल खाता है
    • multi-step ledger arithmetic सही रहा
    • session cost pxpipe के साथ $6.06, और plain text में $42.21 बताई गई
    • pxpipe वाले केस में मांगे गए one-line output format से मिलाने के लिए एक बार nudging करनी पड़ी
  • Opus 4.8 डिफ़ॉल्ट रूप से disabled है
    • text needle दोनों तरफ पढ़ा गया
    • image-converted phrase-count, Opus नहीं पढ़ पाया, और pxpipe ने संख्या गढ़ने के बजाय failure को दिखाया
    • इसी misread rate के कारण Opus opt-in है

सटीकता और lossy nature

  • pxpipe lossy compression का तरीका है
  • dense image content में सटीक 12-अक्षरीय hex string recall का परिणाम model के अनुसार बहुत अलग था
    • Fable 5: 13/15
    • Opus: 0/15
  • misses error की तरह नहीं बल्कि शांत confabulation के रूप में आ सकते हैं
  • ID, hash और secret जैसे byte-level accuracy वाले मान text में ही रखने चाहिए
  • dedicated verbatim-risk guard अभी built-in नहीं है
  • allowlist से बाहर के model का उपयोग करने वाले subagent को text में passthrough किया जा सकता है
    • CLAUDE_CODE_SUBAGENT_MODEL=claude-sonnet-4-6
    • agent frontmatter का model: sonnet

बेंचमार्क और माप

  • नए random-number problem आधारित benchmark में ऐसे प्रश्न उपयोग किए गए जिनके model द्वारा पहले से याद होने की संभावना कम है
टेस्ट N टेक्स्ट pxpipe इमेज टोकन
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 -
  • SWE-bench Lite pilot दोनों तरफ 10/10 था, और request size −65% रही
  • SWE-bench Pro में ON 14/19, OFF 15/19 था, और request size −60% रही
    • verdict 18/19 मामलों में एक जैसा था
    • एक split case replication runs में 3/3 बार फिर हल हुआ
    • README इसे compression issue नहीं बल्कि runs के बीच variability मानता है
    • sample size छोटा होने की caveat दी गई है
  • GSM8K image-converted state में 96% था, लेकिन यह training data में हो सकता है, इसलिए README novel-number evaluation को प्राथमिकता देता है

यह कैसे काम करता है

tool_result string ──► wrap at 1928px-wide columns ──► pack ~92,000 chars/page ──► PNG[]
  • proxy /v1/messages को intercept करता है और उपयुक्त बड़े inputs को image block के रूप में फिर से लिखता है
  • बदले गए blocks cache-friendly तरीके से दोबारा डाले जाते हैं, और static prefix सुरक्षित रखा जाता है ताकि prompt caching काम करती रहे
  • 1928×1928 इमेज लगभग 4,761 vision tokens लेती है और लगभग 92,000 अक्षर रखती है
  • text को जीतने के लिए लगभग 19 chars/token से ऊपर जाना होगा, जबकि Claude Code ट्रैफ़िक N=391 के आधार पर लगभग 1.91 मापा गया
  • per-request estimator तय करता है कि image conversion लागू होगा या नहीं, और sparse prose text में रखी जाती है
  • events ~/.pxpipe/events.jsonl में रिकॉर्ड होते हैं

क्या compress होता है और क्या वैसा ही रहता है

  • compression के लक्ष्य तीन तरह के input blocks हैं, और सभी profitability gate के बाद ही लागू होते हैं
    • लगभग 6k अक्षरों से बड़े token-dense tool_result bodies
    • live tail के पीछे की पुरानी folded history
    • static system prompt और tool docs slab
  • कुछ चीज़ें स्पष्ट रूप से वैसी ही पास होती हैं
    • user messages
    • हाल की turns
    • model output
    • sparse prose
    • बहुत छोटे blocks जिनमें लाभ नहीं है
    • allowlist से बाहर के models
  • डिफ़ॉल्ट scope Fable 5 और GPT 5.6 है
  • Opus 4.8 और GPT 5.5 को image content पढ़ने की कमज़ोर क्षमता के कारण dashboard या PXPIPE_MODELS से स्पष्ट रूप से enable करना पड़ता है
  • PXPIPE_MODELS=off image conversion को disable कर देता है
  • GPT path में tool definitions native JSON में रहती हैं और Anthropic cache_control marker का उपयोग नहीं होता

लागत की गणना कैसे होती है

  • headline savings rate सिर्फ input slice नहीं बल्कि पूरे बिल के आधार पर है
  • 13,709 request snapshots में $100 घटकर लगभग $41 हुआ, जिसे 59% बचत के रूप में गिना गया
  • बाद के 8,904 compressed request traces में यह लगभग 70% मापा गया
  • केवल compressed requests को अलग देखें तो 72~74% स्तर आता है, लेकिन README इसे headline नहीं बनाता
  • हर /v1/messages POST पर मूल uncompressed body के लिए एक मुफ्त count_tokens counterfactual समानांतर चलाया जाता है
  • वास्तविक billed usage Anthropic response के usage block से पढ़ी जाती है
  • मूल और वास्तविक usage दोनों एक ही ~/.pxpipe/events.jsonl पंक्ति में रिकॉर्ड होते हैं ताकि turn-count या run-to-run confound से बचा जा सके
  • dollar conversion के लिए Fable 5 list-price ratio का उपयोग होता है
    • input ×1.0
    • cache write ×1.25
    • cache read ×0.1
    • output ×5
  • cache pricing दोनों तरफ समान रूप से लागू होती है, इसलिए cache discount को बचत में दोबारा नहीं गिना जाता

लाइब्रेरी के रूप में उपयोग

import { renderTextToPngs, transformAnthropicMessages } from "pxpipe";

const imgs = await renderTextToPngs(toolResultText);            // RenderedImage[]
const { body, applied, info } = await transformAnthropicMessages({
  body: requestBytes,
  model: "claude-fable-5",
});
  • इसे proxy के बिना library के रूप में भी इस्तेमाल किया जा सकता है
  • options.keepSharp(block) किसी खास block को text में स्थिर रखता है
  • options.emitRecoverable image-converted block का मूल लौटाता है
  • runtime Pure JS है और Node व edge/Workers को support करता है
  • @napi-rs/canvas सिर्फ build time पर उपयोग होता है
  • पूरा API src/core/index.ts में है

वास्तविक failures और सीमाएँ

  • कई हफ्तों के रोज़मर्रा उपयोग में एक बार image-converted chat history से किसी व्यक्ति का नाम याद करते समय मॉडल ने पूरे विश्वास के साथ गलत जवाब दिया
  • coding sessions इस failure mode को सह सकती हैं क्योंकि edit से पहले files फिर पढ़ी जाती हैं, लेकिन pure chat recall में ऐसी verification नहीं होती
  • legibility audit render pages पर exact string recall मापता है
    • dense identifiers की blind read अधिकतम 63% थी
    • सभी misses glyph-confusability matrix से अनुमानित थीं
    • API resample cap के अनुरूप page geometry सीमित करने वाला mitigation लागू किया गया
    • SHA और numbers जैसे exact identifiers को text के रूप में साथ ले जाया जाता है
  • limitations भी साफ़ लिखी गई हैं
    • image-based verbatim recall पर भरोसा करना मुश्किल है
    • बड़े requests में transmission से पहले PNG encoding delay जुड़ती है
    • ASCII/Latin-1 अच्छी तरह test किया गया है
    • CJK काम करता है, लेकिन conservative तरीके से handle किया जाता है

डेवलपमेंट और रोडमैप

pnpm install && pnpm test
pnpm run build                # regenerates dist/
  • development commands में install, test और build शामिल हैं
  • license MIT है
  • roadmap को सिर्फ hypotheses के रूप में पेश किया गया है; जब तक numbers और sample size न हों, उन्हें claim नहीं माना जाता
    • और अधिक sharp glyph rendering
    • क्या image-converted bulk उसी 1M window में effective context को लगभग 2x बढ़ा सकता है
    • क्या छोटा active context लंबे कामों में accuracy बढ़ाता है

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 5 시간 전
Hacker News की राय

  • Gemini को ही देखें तो, मेरी समझ में PDF प्रोसेस करते समय वह पहले OCR करता है, फिर टेक्स्ट और इमेज को साथ में मॉडल में डालता है, और टेक्स्ट token की लागत चार्ज नहीं करता
    अगर Claude backend भी यही कर रहा है, तो यह hack token billing के तरीके की खामी जैसा है, और अगर Claude Gemini की तरह व्यवहार करता है तो आगे चलकर इसके बंद होने की संभावना काफी है

    • यह बात वाकई दिलचस्प है। पहले मैंने सोचा था, “वैसे भी अंदरूनी तौर पर यह कभी न कभी text tokens में बदलेगा, इसलिए Claude के नजरिए से वास्तविक execution cost सस्ती होने का सवाल ही नहीं उठता”
      लेकिन नीचे वाली टिप्पणी में DeepSeek ने visual tokens के जरिए compression ratio काफी बेहतर किया है, ऐसी बात आती है: https://news.ycombinator.com/item?id=48777848
      मैं अंदरूनी तकनीकी details पूरी तरह नहीं समझता, इसलिए OCR path कुल power या compute cost में कमी ला सकता है, यह बात अभी भी मुझे ठीक से समझ नहीं आती
    • जरूरी नहीं। paper DeepSeek-OCR: Contexts Optical Compression देखें: https://arxiv.org/abs/2510.18234
      किसी image को LLM में डालने का एक तरीका यह है कि image को tiles में बांटा जाए, उन tiles को vision encoder neural network से गुजारकर visual tokens बनाए जाएं, और फिर उन्हें text tokens की तरह LLM में input किया जाए। जाहिर है, vision encoder और LLM को इस तरह train किया जाता है कि वे एक-दूसरे को समझें। ऐसे तरीके को end-to-end OCR model कहा जाता है
      एक बार ऐसा trained model मिल जाए, तो document image को बड़ा या छोटा करके उसी text document को represent करने में इस्तेमाल होने वाले visual tokens की संख्या बदली जा सकती है, और patch size या vision encoder की complexity जैसे parameters भी adjust किए जा सकते हैं
      नतीजे काफी अच्छे थे, और कुछ tests में input tokens 90% कम करते हुए भी output performance 97% बनी रही
    • Claude Science में PDF extract करने का tool है, लेकिन वह सच में OCR करता है या नहीं, यह मुझे ठीक से नहीं पता

  • पिछले साल OpenAI models के साथ यही चीज़ आजमाई थी; उस समय prompt tokens घटाने में तो फायदा हुआ, लेकिन completion tokens बहुत ज्यादा चाहिए पड़े, इसलिए आखिर में यह ज्यादा महंगा और धीमा पड़ा
    https://pagewatch.ai/blog/post/llm-text-as-image-tokens/

  • आह, आंखें दुख रही हैं। यह vibe-coded README जैसा है

    • LLM से compressed explanation पढ़ना बेहद तकलीफदेह होता है। ठीक-ठीक किस वजह से, कहना मुश्किल है, लेकिन तुरंत पता चल जाता है, और समझने में सचमुच दोगुनी मेहनत लगती है
      उदाहरण के लिए:

      Honest caveat, visible in the clip: the pxpipe arm answered the count first and needed one follow-up nudge to also print the ledger balance in the requested one-line format; the plain arm followed the format on the first try. Legibility is solved on Fable — single-reply format compliance is the remaining rough edge.
      इसे चार बार दोबारा पढ़ने पर आप अंदाजा लगा सकते हैं कि लगभग क्या हुआ था, लेकिन ज्यादातर जानकारी बेकार और उलझाने वाली है
      सभी models किसी हद तक ऐसे लिखते हैं, लेकिन Claude खास तौर पर ज्यादा ऐसा करता दिखता है। GPT 5.5 थोड़ा ज्यादा concise है और ज्यादा valuable information compress करता हुआ लगता है

    • जब कोई अपने बनाए हुए काम को share करना चाहता है और मुझे vibe coding README दिखता है, तो मैं इसे इस बात का मजबूत signal मानता हूं कि वह व्यक्ति अपने बनाए हुए को इतना नहीं समझता कि authority के साथ समझा सके
      AI से सच में उपयोगी चीजें बनाई जा सकती हैं, खासकर उस field में जहां आपके पास पहले से expertise हो। लेकिन फिर 1) यह बताना चाहिए कि AI की मदद ली गई है और 2) अपनी भाषा में समझाना चाहिए कि आखिर बनाया क्या है। AI के साथ काम करने की limitations तक बता सकें तो और बेहतर
      तभी भरोसा बनता है कि “इस व्यक्ति की बनाई चीज़ try करने लायक है, और यह अपने बनाए हुए को अच्छी तरह समझता है”
      आजकल जो 99% चीजें आ रही हैं, वे ऐसे क्षेत्रों में लोगों के काम का नतीजा हैं जिन्हें वे बिल्कुल नहीं समझते, इसलिए ऐसा README दिखते ही मैं बस tab बंद कर देता हूं

  • यह resources जलाने वाला pricing hack जैसा दिखता है। अगर loophole बंद हो जाए तो क्या OCR की कीमत बढ़नी नहीं चाहिए?

    • यह loophole नहीं है; बात यह है कि जानकारी को optical tokens में encode करना text की तुलना में कहीं ज्यादा efficient है
    • जरूरी नहीं। यह तरीका वास्तव में ज्यादा resources इस्तेमाल कर रहा हो, ऐसा भी नहीं है। उल्टा, शायद एक मूलभूत inefficiency हट रही हो
      सोचें तो बात समझ आती है। इंसान भी code को word-by-word पढ़ते हैं, लेकिन आम तौर पर skim करते हुए pattern recognition से मोटे तौर पर समझ लेते हैं कि वह क्या कर रहा है। किसी specific सवाल का जवाब देना हो तभी किसी खास हिस्से पर ध्यान देते हैं
      मेरे हिसाब से इंसान भी स्वाभाविक रूप से इसी तरह की workaround optimization करते हैं

  • संबंधित पोस्ट: https://blog.can.ac/2026/06/10/snapcompact/

  • इस तरीके के साथ सावधान रहना चाहिए। लागत घटने की वजह असल में यह हो सकती है कि यह कम performance वाले किसी दूसरे model पर switch कर देता हो
    ऊपर से यह Fable जैसा दिख सकता है, लेकिन असल में न हो। ऐसे में आप बेवजह extra काम कर रहे होंगे, और शायद model को opus 4.8 पर वापस लाना बेहतर हो

  • लगता है Oh-My-Pi(OMP.sh) context compression के लिए images इस्तेमाल करता है। OMP, Pi coding agent के ऊपर बनाया गया है

  • इस technique पर DeepSeek का white paper भी है: https://www.seangoedecke.com/text-tokens-as-image-tokens

  • पहले किसी का tweet देखा था, शायद Carmack, Geohot, या Karpathy में से किसी का, जिसमें कहा गया था कि image बेहतर विकल्प हो सकती है
    उसके बाद से agent को यह बताने के लिए कि अभी क्या हो रहा है, मैं बहुत simple sentence वाले prompt के साथ images इस्तेमाल करता आया हूं, और कभी-कभी prompt में बिल्कुल text नहीं डालता
    असर बहुत अच्छा रहा
    हालांकि यह ठीक वही नहीं है जो Karpathy कह रहे थे। फिर भी उस idea ने बेहतर workflow तक पहुंचाया

  • माफ करें, लेकिन यह बेतुका है। यह काम करता है और चालाक है, लेकिन साफ तौर पर pricing failure को bypass करने का तरीका है
    जैसे सांपों पर bounty की वजह से लोगों ने सांप पालना शुरू कर दिया था, यह waste का फायदा उठाता और उसे बढ़ावा देता है
    आखिरकार इसकी जिम्मेदारी Anthropic की खराब pricing system पर है, जिसने ऐसी arbitrage संभव बनाई। लेकिन जब तक इसे ठीक नहीं किया जाता, इसका दुरुपयोग करने वाले लोग टूट पड़ेंगे, और पूरी तरह गैरजरूरी digital कचरे की और बाढ़ आना भी घिनौना है