A screenshot is cheaper than the text inside it. In July 2026, a small open-source tool called pxpipe started making the rounds for a trick that sounds like a joke until you see the invoice. It runs as a local proxy in front of Claude Code and similar tools, and instead of sending your system prompt, tool documentation, and old chat turns to the model as plain text, it renders the bulky, static parts onto a densely packed PNG image first. Source: the-decoder.com, "Open-source tool pxpipe hides text in PNGs to cut Claude Code and Fable 5 token costs up to 70%," July 2026 Recent messages and model output still go through as normal text. Everything else gets flattened into a picture of itself before it leaves your machine. The reason this works at all has nothing to do with compression in the usual sense. Vision-capable models bill image input by pixel area, not by what the pixels depict. Anthropic's own vision documentation gives the formula directly: image tokens are estimated as (width in pixels x height in pixels) / 750. Source: Anthropic, "Vision," Claude Platform Docs That formula doesn't know or care whether the picture is a photo of a cat or a screenshot of 40 pages of API documentation. Plain text, by contrast, costs roughly one token per handful of characters, scaling directly with how much you wrote. Pack enough dense text onto one image and you've found a gap between two unrelated pricing models, and the gap is not small. Bar chart: the same 48,000-character system prompt costs about 25,000 tokens as text but about 2,700 tokens rendered onto one dense PNG page, a 9.3x reduction. A measured session dropped from $42.21 text-only to $6.06 with pxpipe; a production trace of 13,709 requests landed 59% to 70% cheaper. The numbers that made it spread. pxpipe's own README, and the coverage that followed it, are specific about the size of the win. Source: teamchong/pxpipe, GitHub README A single measured Claude Fable 5 session went from $42.21 running text-only to $6.06 with imaged context, an 86% drop with the same task completed. Across a production trace of 13,709 requests, total spend fell 59%, from roughly $100 to about $41; a later snapshot of 8,904 compressed requests showed closer to 70%. On the requests that actually got imaged, the savings run 72% to 74%. The character-level math behind that: the same 48,000 characters of system prompt and tool documentation cost about 25,000 tokens as text and about 2,700 tokens as one dense image, a 9.3x difference for content that is, character for character, identical. On SWE-bench, the coding-task correctness didn't obviously suffer at the aggregate level. On SWE-bench Lite, pxpipe matched the text-only baseline exactly, 10/10 to 10/10, at 65% less request size. On the harder SWE-bench Pro, it landed one task worse, 14/19 against 15/19, at 60% less request size. Source: teamchong/pxpipe, GitHub README That's the kind of number that makes a viral cost trick look like a free lunch: task success barely moved, and the bill fell by more than half. What the bill doesn't show you. Buried in the same README is the number that matters more than any of the savings figures. pxpipe's own test suite includes a check that asks each model to read back an exact 12-character hex string from imaged, densely packed context, no meaning to infer, no pattern to guess from, just a string that is either read correctly or isn't: | Model | Dense hex strings correct (of 15) | |---|---:| | Gemini 3.6 Flash | 14/15 | | Claude Fable 5 | 13/15 | | Claude Opus 5 | 2/15 | | Claude Opus 4.8 | 0/15 | | Grok 4.5 | 0/15 | Source: teamchong/pxpipe, GitHub README Horizontal bar chart of exact hex-string recall from imaged context across five models: Gemini 3.6 Flash 14/15, Claude Fable 5 13/15, Claude Opus 5 2/15, Claude Opus 4.8 0/15, Grok 4.5 0/15. Every model scored 100/100 on arithmetic and 0/16 on a separate confabulation-detection check in the same test run. Read that table next to the rest of the test suite and the shape gets stranger. Every one of these same models scored 100/100 on arithmetic questions over the same imaged context, and 0/16 on a check designed to catch the model admitting it was guessing. Source: teamchong/pxpipe, GitHub README In other words: fluent, confident, and completely unable to tell you when it just made up a hex string it couldn't actually read off the pixels. The README itself is direct about what this means, calling the wrong answers "silent confabulations, not errors," and explicitly warning that byte-exact values, IDs, hashes, secrets, anything requiring character-for-character recall, should never go through the image path at all. Why a lossy-cost hack is a different animal than an expensive one. This blog has already measured several ways a token-saving move can quietly cost more than doing nothing: a cache write billed as a premium that's never earned back, a compressor that corrupts the exact edit anchors a coding agent needs to apply its own patches, a caching strategy that adds latency instead of removing it. Every one of those failures shows up somewhere you can see it, a bigger invoice, a failed patch, a slower response. pxpipe's failure mode doesn't. A confabulated hex string arrives with the same tone, the same confidence, the same formatting as a correct one. The only way to catch it is to already know the right answer, which defeats the reason you asked in the first place. That's a fundamentally different kind of bet than the compression tradeoffs this blog usually covers. An expensive mistake shows up on a dashboard. An invisible one shows up in production, later, as a mystifying support ticket about an order ID that never matched anything. The research pxpipe is riding on, and the research that pushes back. The idea that vision encoders can compress text isn't new, and it isn't wrong exactly, it's just narrower than the pricing arbitrage makes it look. DeepSeek-OCR, published in October 2025, showed that a dedicated vision encoder trained for this purpose can hit around 97% OCR precision at a 10x compression ratio, degrading to roughly 60% at 20x. Source: DeepSeek-AI, "DeepSeek-OCR: Contexts Optical Compression," arXiv:2510.18234 VIST, presented at NeurIPS 2025, built a slow-fast architecture that renders distant context into images for a lightweight vision encoder to skim, and reported beating the strongest text-encoder-based compression baseline by 7.6% on average across several QA benchmarks. Source: "Vision-centric Token Compression in Large Language Model," NeurIPS 2025, arXiv:2502.00791 Both are real, peer-reviewed results, and both involve a model purpose-built and trained to read its own compressed images, not a general-purpose vision-language model asked to make do. That distinction is exactly what a more skeptical paper from December 2025 goes after. "Optical Context Compression Is Just (Bad) Autoencoding" argues that rendering token embeddings to pixels and then compressing through a generic vision encoder discards learned language representations in favor of an image the model then has to visually reconstruct from scratch, an unnecessarily lossy round trip. Source: "Optical Context Compression Is Just (Bad) Autoencoding," arXiv:2512.03643 Tested against simple baselines, mean pooling and a plain hierarchical encoder matched or beat vision-based compression at every ratio tested. For factual recall specifically, the paper found vision compression never surpassed the best direct text baseline, and for general language-modeling quality, it performed comparably to just truncating the context outright. pxpipe's win isn't evidence against that finding, it's a different mechanism entirely: it isn't exploiting a smarter way to represent language, it's exploiting the gap between how providers price a pixel and how they price a token, on a general-purpose model that was never trained to read compressed context and, per its own test suite, sometimes can't. Where this actually fits, if it fits at all. None of this makes the trick useless, it makes it narrow. pxpipe's own profitability gates already encode the right instinct: it applies the image transform only where the token math clearly wins, dense, static, non-exact bulk content like system prompts and stale tool documentation, and leaves recent turns and short prompts as plain text because imaging them would lose money anyway. The failure mode above says where the second, harder line has to sit: not "does this content compress well" but "does anything in it need to survive character-for-character." A 40-page API reference compresses beautifully and rarely needs an exact quote back. An order ID, an API key fragment, a hash, a timestamp with legal significance, none of those can afford a 0/15 model rolling a confident wrong answer with zero indication it happened. A conservative gate: only image content that is (1) bulk and static, and (2) contains no fields that need byte-exact recall. EXACT_VALUE_PATTERN = r"\b[0-9a-fA-F]{8,}\b|order[_-]?id|api[_-]?key|hash|secret" def should_image(content: str, min_chars: int = 4000) -> bool: if len(content) < min_chars: return False # too small to be worth the token-math gap if re.search(EXACT_VALUE_PATTERN, content, re.IGNORECASE): return False # exact-value content: keep as text, no exceptions return True That's also, not coincidentally, the same discipline routing already has to apply, just at a different layer. A cascade router decides per request whether the cheap path is safe enough; a compression gate has to decide per field whether the lossy path is safe enough. Neither decision is free, and neither should default to "compress everything because the average case looks good." The pxpipe README gets this exactly right for its own tool. The risk is everyone downstream who reads "up to 70% cheaper" and skips the part where the tool tells you, in its own test results, exactly which 2 to 15 out of 15 answers you can't trust. What to ship this week. If you try pxpipe or anything like it, read the failure-mode section of the README before the savings section. The 0/15 and 2/15 rows are the actual spec of the tool, not an edge case. Draw the line by field, not by document. Bulk documentation and stale history are fair game. IDs, hashes, secrets, and anything else that needs exact recall should never enter the image path, regardless of how much it would save. Don't let a viral savings number substitute for your own paired test. The same lesson applies here as it did to token-reduction claims generally: measure the specific failure mode against your own exact-value fields before shipping any lossy transform broadly. Prefer savings mechanisms that fail loud over ones that fail silent. Prompt caching misses cost the standard rate. Model routing that under-escalates produces a visibly wrong answer you can catch downstream. Nadir routes each request to the cheapest model that can handle it and escalates only when a calibrated verifier flags the cheap model's answer as likely wrong, a decision with a visible, checkable outcome, not an invisible one baked into how a document was rendered before the model ever saw it. Conclusion. pxpipe's numbers are real, and so is the pricing gap it's exploiting: a formula that bills a pixel by area and a formula that bills text by character were never going to agree on the price of the same information, and someone was always going to notice. What makes this one worth pausing on isn't the size of the saving, plenty of legitimate techniques save more. It's that the failure mode doesn't cost you money or time, the two things every other compression tradeoff on this blog has cost someone. It costs you a wrong answer that looks exactly like a right one, with the model's own confidence offering no way to tell the difference. A technique that saves 70% and fails loud is a tuning problem. A technique that saves 70% and fails silent is a policy about which fields are allowed anywhere near it. Related reading. Every compression pitch assumes fewer tokens means a smaller bill. A 2,848-run study found the correlation is nearly zero. Prompt caching is the closest thing to free money in LLM cost optimization, until the cache boundary is drawn wrong. Anthropic and OpenAI both now charge a premium the first time you try to save money with a cache write. A vision model's image tokens follow completely different math than its text tokens. Here's what that costs in practice. LLMLingua and the rest of the prompt-compression toolkit, and where each one actually saves money. Sources: teamchong/pxpipe, GitHub README, July 2026. the-decoder.com, "Open-source tool pxpipe hides text in PNGs to cut Claude Code and Fable 5 token costs up to 70%," July 2026. Anthropic, "Vision," Claude Platform Docs. DeepSeek-AI, "DeepSeek-OCR: Contexts Optical Compression," arXiv:2510.18234, October 2025. "Vision-centric Token Compression in Large Language Model," NeurIPS 2025, arXiv:2502.00791. "Optical Context Compression Is Just (Bad) Autoencoding," arXiv:2512.03643, December 2025.