Render Code as Images and Send to Claude — Cut API Costs by 70%

A Counterintuitive Way to Save Money

Using AI to write code is getting increasingly expensive. Every time you ask Claude to fix a bug, the model doesn't just read your code — it re-reads the system prompt, tool documentation, and the entire conversation history. It's like having to recite your company handbook every time you ask your manager a question. The result: API bills that skyrocket.

Recently, an open-source project called PXPipe has sparked widespread discussion. According to a deep-dive breakdown by a Bilibili creator, the developer came up with a clever hack to cut costs: render qualifying long-context blocks — system prompts, tool documentation, old history, large tool outputs — as images, then send them to Claude as screenshots.

The results were surprising: input tokens dropped by roughly 68%, and end-to-end billing savings ranged from 59% to 70% (depending on workload). Is this a billing loophole in Anthropic's pricing, or a hidden superpower of multimodal models? Let's break it down from an engineering perspective.

Why Images Are Cheaper Than Text

To understand this arbitrage opportunity, you need to understand the core difference between the two billing models.

Text token billing in LLMs stems from their underlying tokenization design. Most mainstream models use BPE (Byte Pair Encoding) or similar subword tokenization algorithms to split text into subword units. In English, one token corresponds to roughly 3–4 characters. But high-density content like Chinese, code, and JSON tends to pack fewer characters per token due to complex character combinations — meaning the same amount of information costs more tokens. This is why code and logs benefit more from image compression than ordinary English prose.

Image token billing works entirely differently: Claude counts visual tokens based on 28×28 pixel patches.

A 1568×728 production page requires roughly 1,400–1,500 visual tokens. That same page packed with code, JSON, or logs could consume 15,000 to 30,000 text tokens. The difference is where the savings come from.

PXPipe exploits exactly this information density gap. The README shows an example with 48,000 characters: as text, that's roughly 25,000 tokens; as an image, just ~2,700 tokens. On real Claude Code traffic, PXPipe measured an average information density of 1.91 characters/token — so dense code, JSON, and logs have real arbitrage potential, while plain English prose has limited gains.

Engineering: Squeezing Every Pixel

Maximum Render Efficiency

Open src/core/render.ts and you'll find the author is extremely conservative at the pixel level. They use a compact 5×8 pixel bitmap font — the kind originally used in early embedded displays and LED dot-matrix screens, where each character occupies just 40 pixels. The engineering rationale: the visual encoder's receptive field is large enough to cover complete characters without high-resolution anti-aliased rendering. Fonts that are too large reduce per-page information density and destroy the compression ratio; fonts that are too small exceed the model's recognition threshold and cause hallucinations. 5×8 is the Pareto-optimal point between information density and recognition accuracy given current model capabilities. Pages are strictly capped at 1568×728 pixels, allowing a single image to hold up to 28,080 characters.

A Smart Layered Memory Strategy

Not everything is suitable for conversion to images. Inside transform.ts, the author implements a clever layered memory mechanism:

• Recent conversation turns (the latest question and the model's latest response) must stay as plain text to ensure 100% accuracy;
• Long-lived, stable system prompts and tool definitions are converted to images;
• History entries are folded and archived as images after tool calls complete.

This logic mirrors human memory: recent events are crystal clear, yesterday's events are remembered in outline only. PXPipe uses images as cheap "summary storage" and text as expensive "precise working memory." This philosophy also aligns with RAG (Retrieval-Augmented Generation) systems — replacing byte-perfect accuracy with semantically sufficient accuracy, finding a layered balance between precision and cost.

There's also a critical escape hatch called KeepSharp: callers can explicitly specify which content must remain as text.

In production, byte-exact content — hashes, IDs, secrets — must be explicitly kept as text, or serious issues can arise.

The Art of Cache Alignment

Savvy readers might ask: doesn't Anthropic have Prompt Caching? Won't converting text to images invalidate the cache?

It's worth understanding how Prompt Caching works first: it's a server-side optimization from Anthropic that allows frequently reused context prefixes (like system prompts and tool definitions) to be cached across requests, offering roughly a 90% token discount. The key requirement is that the prefix must be byte-exact and meet a minimum length threshold (around 1,024 tokens). Any change in prefix content invalidates the cache.

PXPipe handles this elegantly: instead of adding new cache control points, it moves the caller's existing cache_control markers to the end of the corresponding image blocks. This avoids consuming extra cache discounts and tries not to break Prompt Caching. Under the same cache state, the image prefix itself requires fewer tokens.

Real cost comparison: across a snapshot of 13,709 requests, cost with PXPipe enabled was $41 versus $100 without — 59% savings. This isn't a single-metric compression figure — it's a real end-to-end bill comparison.

Key Insight: VLMs Are Not OCR

At this point you might think this is just a money-saving plugin that relies on OCR. But here's the key: a large model's visual system is nothing like OCR.

Traditional OCR cuts an image into individual letters to recognize them — if it can't read clearly, it reports a low confidence score and fails. Multimodal large models (VLMs) work completely differently: images are first split into fixed-size patches (Claude uses 28×28 pixel patches), each patch is converted into a continuous high-dimensional vector by a visual encoder (typically based on ViT, the Vision Transformer architecture), then projected into the language model's token embedding space via a projection layer. The language model doesn't directly "see" pixels — it performs attention calculations over these visual vectors, using language priors to infer image content. This mechanism is inherently robust, but introduces a fundamental difference: inference rather than reading.

This explains two phenomena:

1. When code in an image is slightly blurry, the model can still understand the logic — because it infers from context;
2. When you ask it to read a random 12-character hexadecimal hash with no discernible pattern, it can't infer anything — so it will confidently fabricate one with no hesitation. It has no concept of "low confidence"; it simply hallucinates silently.

This is why early testing on the Opus model yielded a precise string recognition rate of 0 out of 15 — a complete failure.

Model Progress Changed Everything

The turning point came with newer model releases. According to the creator's analysis, when Fable 5 (the next-generation model referenced in the video) launched, the same precise string recognition test jumped to 13 out of 15. A single generation of model improvement pushed this once-controversial idea to the point where the author was comfortable enabling it by default.

Why is this class of model particularly well-suited? Because it sits at the intersection of three dimensions where ROI is optimal:

• Visual capability is strong enough to reliably read high-density text images;
• Visual token billing is more cost-effective for dense text scenarios;
• Input pricing is high (~$10/million tokens), so cutting 60% of input tokens is immediately visible on the bill.

This also explains the logic behind the default allowlist: older models like Opus achieve only ~10% precise read rates at 5×8 pixel density. To reach 95% accuracy, font size must be increased to 10×16, fitting only 7,000 characters per page instead of 28,080 — completely destroying the cost advantage, which is why they're opt-in only.

A Deeper Insight: Lossy Compression Is Acceptable

The most valuable takeaway from this project is: in AI engineering, lossy compression is perfectly acceptable — as long as you know exactly what's being lost.

Lossy compression is well-established in multimedia — JPEG, MP3, and H.264 all achieve extreme compression ratios by discarding information below human perceptual thresholds. Introducing lossy context compression into AI engineering represents a paradigm shift: from "data must be 100% faithful" to "semantically accurate is good enough." Software engineering demands 100% precision, but human memory is inherently lossy — we can't remember every word from yesterday's conversation, but we retain the core meaning. PXPipe uses images as cheap "summary storage" and provides a precision safety net through the KeepSharp mechanism, achieving a layered coexistence of lossy and lossless storage.

In GIST-level testing, the model achieved 98% accuracy in understanding historical decisions and path names.

This means we can maintain long-term contextual awareness at very low cost using images, only loading actual text files when precise operations are required. But the limits must be understood clearly: precise strings still carry a risk of misreading — this cannot be treated as zero-impact. The safer approach is to use the KeepSharp mechanism to explicitly keep byte-exact content — hashes, IDs, paths — as text, and only enable image compression for content where that's safe.

This Is Just a Transitional Phase

Text-to-image context compression is very likely only a transitional solution. Academia has already systematically explored visual context compression: beyond DeepSeek's specially trained optical encoder for long-context compression, several papers on "visual token compression" have appeared since 2023 — including token merging approaches from the LLaVA series and GPT-4V's high-resolution tiling strategy. The common starting point for all this work: visual encoding has a natural implicit aggregation advantage when handling structured, highly repetitive content. PXPipe pushes this through with off-the-shelf general-purpose models — demonstrating that visual context compression is being seriously explored by the industry, with research rapidly translating into engineering practice.

In the future, we'll likely see large models natively support tiered memory: precise short-term memory as text, approximate long-term memory as highly compressed visual or vector features. Until an official solution arrives, PXPipe is an effective but boundary-aware experimental tool.

Conclusion

PXPipe's true innovation isn't text compression — it's discovering a cost arbitrage window in multimodal models, making large models read pixels instead of transcripts.

But this window only opens when three conditions are simultaneously met: the model is capable enough to read small text in images, image token billing is cheap enough, and the task doesn't depend on character-perfect accuracy. So it's currently best suited for the newest generation of high-cost vision models — but that doesn't mean this technique belongs exclusively to any single model. As visual encoders continue to improve across the industry, visual context compression may well become a standard middleware layer in agent systems.

Key Takeaways