Sending Text as Images to Claude Cuts Your Bill by 60%. Here Is Why That Should Not Work, and Why It Does

A proxy called pxpipe hit Hacker News front page this week with a claim that sounds like it was generated by a hallucinating model: you can cut your Claude Code bills by around 60 percent by rendering your text context as images and letting the model OCR it back. Two hundred points later, the claim is holding up. The savings are real, the benchmarks are reproducible, and the mechanism is not a bug in pxpipe — it is a structural feature of how Anthropic charges for images versus text.

This is worth understanding in detail because it reveals something important about where AI API pricing models are right now: early, internally inconsistent, and exploitable in ways that will eventually get patched, but probably not before a lot of engineers have extracted significant money from the gap.

What pxpipe Actually Does

The mechanic is almost comically simple. pxpipe runs as a local proxy on port 47821. You point Claude Code at it by setting ANTHROPIC_BASE_URL=http://localhost:47821. Every /v1/messages call that would normally go to Anthropic’s API passes through pxpipe first. For most calls, the proxy does nothing and forwards the request unchanged. For calls that contain large blocks of token-dense content — system prompts, tool docs, older conversation history, tool results from file reads or command output — the proxy rewrites those blocks as compact PNG images before forwarding.

The model on the other end receives an image instead of text. It OCRs the image and proceeds as if it had received text. The response comes back normally. Nothing about the output changes. pxpipe only compresses the request, never the model’s reply.

npx pxpipe-proxy                                  # proxy on 127.0.0.1:47821
ANTHROPIC_BASE_URL=http://localhost:47821 claude  # point Claude Code at it

The images are constructed with a specific pixel layout: text is rendered at a monospace font into full-width rows 1928 pixels wide, with a co-rendered OCR instruction banner at the top telling the model what it is looking at. Original newlines are marked with a ↵ character. The proxy only images content where the math works out in its favor — it includes a per-request profitability gate calibrated against 391 production rows of observed Claude Code traffic. If the content is too sparse or too short, it passes through as text.

The Pricing Arbitrage: Why Images Are Cheaper Than Text Here

Anthropic prices image tokens by pixel dimensions, not by content density. A 1928×1928 image costs approximately 4,761 vision tokens. That same image can hold around 92,000 characters of text — which, at standard text token pricing where code and JSON average roughly 1.91 characters per token based on pxpipe’s observed production traffic, would cost around 48,000 text tokens.

Run the math: 4,761 image tokens versus 48,000 text tokens for the same content. That is a 10x reduction in token count for dense code content. The effective ratio pxpipe measures across real Claude Code traffic is approximately 3.1 characters per image-token versus 1 character per text-token — a 3x ratio that, combined with Anthropic’s pricing structure, translates to 59 to 70 percent lower end-to-end bills on a 13,709-request production snapshot.

The key phrase is pixel dimensions. Anthropic’s image pricing is computed from the image’s width and height, not from any assessment of how much textual content is inside that image. This is how vision models have traditionally been priced — images are treated as fixed-cost inputs because the visual processing overhead is roughly proportional to pixel count, not content. The assumption that held for photographs and charts breaks down entirely for rendered text, where you can pack extraordinary amounts of information into a fixed pixel budget by simply reducing the font size or tightening the line spacing.

pxpipe exploits this by rendering at a font size small enough that a single image page holds 92,000 characters but large enough that Fable 5 (Claude’s current frontier model) can read it with 100/100 accuracy on the evaluation suite.

The Information Theory Objection, and Why It Does Not Hold

The most common reaction from engineers encountering this for the first time is some version of “this can’t work without violating information theory.” The argument goes: if you’re compressing 48,000 text tokens into 4,761 image tokens, the model must be doing extra work somewhere to decompress it. That extra work should show up as increased output tokens — internal OCR processing, extended thinking, something. Where is the conservation law?

Several HN commenters raised exactly this. User __hugues put it directly: “seems really dumb and like it would need to violate basic information theory to work? input tokens are cheaper than output tokens. seems like it would maybe reduce input tokens at the expense of many more output tokens if you’re actually triggering OCR via thinking?”

The answer requires distinguishing between the model’s internal processing and what gets billed. pxpipe compresses the input. The output — the model’s response — is never touched by the proxy. The question is whether processing an image of text costs more in terms of internal compute than processing the equivalent text tokens, and whether that difference is reflected in the billing.

Right now, it is not. Anthropic bills output tokens at standard rates and image input tokens at pixel rates. Any additional inference compute required to OCR the image is absorbed by Anthropic as an operational cost that is not passed through to the customer. This is the actual arbitrage: pxpipe is externalizing the OCR overhead onto Anthropic’s infrastructure while the customer only pays the pixel-dimension image price.

Whether this constitutes a feature or a pricing bug depends on your perspective. From Anthropic’s engineering standpoint, the vision models were not designed to OCR screenshotted code at production scale, and the pricing was not calibrated to account for that use case. From the customer’s standpoint, the API does exactly what it promises: it processes the image and produces a response, at the advertised image token rate.

There is also a deeper reason this works that has nothing to do with pricing. Sean Goedecke and others have pointed to a DeepSeek OCR paper that found models can extract approximately 10 text tokens from a single image token with near-100% accuracy. The theoretical explanation is that text tokens are discrete — a finite vocabulary of 50,000 or so items, each mapping to a specific point in embedding space. Image tokens are continuous — any embedding value is valid, so a single image token can in principle occupy any position in that continuous space and carry arbitrarily more semantic content than a text token constrained to a discrete vocabulary position. The image token’s embedding can encode not just which characters are present but their spatial relationships, formatting, and context in ways that text tokens structurally cannot.

Whether this matters for practical OCR fidelity is a separate question from whether it matters for billing. What we can say is that models trained on massive amounts of text rendered as images (OCR training data) have effectively learned a more efficient internal representation of textual content than their text-token pathway provides. pxpipe routes around the inefficient pathway.

The Benchmark Numbers

The pxpipe README presents benchmarks with methodological transparency that is unusual for a project at this stage. The key numbers:

The SWE-bench results are the most credible signal for real-world coding work:

The SWE-bench Pro result — 14/19 versus 15/19 — requires careful reading. The single split case (navidrome, ON fail) was replicated three times on the ON arm and all three resolved, producing identical patches. The original failure was run-to-run agentic variance, not compression. The authors are explicit about this and about the small n.

The methodology for cost measurement is also worth understanding. For every /v1/messages POST, pxpipe fires a free count_tokens probe on the original uncompressed body in parallel with the real forwarded request. It reads Anthropic’s actually-billed usage block off the response. Both land in the same row of ~/.pxpipe/events.jsonl. This eliminates turn-count confounds and run-to-run variance from the token comparison — you’re comparing the same request, at the same moment, compressed versus uncompressed. The dollar conversion uses current Fable 5 list ratios: input ×1.0, cache write ×1.25, cache read ×0.1, output ×5. Cache pricing is applied identically to both sides, so the caching discount cancels.

The headline demo numbers — $42.21 versus $6.06 for the same task, with context at 96% full on plain versus 7.35% on pxpipe — are striking but reflect a workload specifically chosen to stress test context compression. They are not claimed as typical; they illustrate the upper end of what’s achievable when you’re working with large, token-dense codebases where context pressure is the bottleneck.

Where It Fails: The Lossy Problem

pxpipe is lossy in a specific and dangerous way. The README does not hide this; it leads with it under a section titled “the honest part, read before relying on it.” Understanding the failure mode is essential to understanding what this tool is actually safe to use for.

Verbatim byte-exact recall from imaged content is unreliable. The 12-character hex recall benchmark says it all: 0/15 on Opus 4.8, 13/15 on Fable 5. The failure mode is not “the model says it doesn’t know.” It is silent confabulation — the model produces a plausible-looking wrong value without any uncertainty signal. For Opus, this is total. For Fable 5, it happens 13% of the time on a synthetic benchmark designed to stress this exact failure mode.

The practical implications are more nuanced than “don’t use it.” Coding sessions have a natural escape hatch: agents re-read files before editing them, so even if the agent misremembers a value from imaged history, it will re-fetch the ground truth before making any change. The README makes this explicit and routes work that requires byte-exact recall to non-Fable subagents by default, which pass through as text. CLAUDE_CODE_SUBAGENT_MODEL=claude-sonnet-4-6 forces exact-recall subagents to use the text path.

One real-world failure is documented: the model recalled a person’s name from imaged chat history and got it confidently wrong. No error, no uncertainty, just a plausible wrong name. For a coding session this matters less than for a conversation with personal context. For a pure chat use case the escape hatch does not exist.

The boundary of what is safe is: decisions, values, paths, variable names, function signatures, and logical flow — gist-level content — are reliably preserved. Exact byte strings, hashes, IDs, hex values, and secrets are not. If your workflow involves pasting API keys, commit hashes, or database connection strings into your conversation and then relying on the agent to recall them from history, pxpipe is not for that workflow. Recent turns always stay text; it is only older history that gets imaged.

The Workload Gate

pxpipe does not unconditionally compress everything. The built-in gate only images content where the economics win. The key variable is the observed characters-per-token ratio of the content. Code, JSON, tool output, and log files average around 1.91 characters per text token on real Claude Code traffic. The imaging path packages this at approximately 3.1 characters per image-token based on the observed production density. The gate breaks even when text content runs denser than roughly 19 characters per token — sparse English prose runs at approximately 3.5 characters per token, which means imaging it would increase costs rather than reduce them.

This is the crucial nuance that separates pxpipe from a blind compression proxy. A developer using Claude Code primarily for code, file analysis, and tool execution will see large savings. A developer using Claude Code as a conversational assistant with mostly prose messages and responses will see little or no benefit. The gate tries to detect this per-request and default to text for content that does not win.

Three kinds of content get imaged:

1. Large tool_result bodies (file reads, command output, logs) above roughly 6,000 characters of token-dense content
2. Older collapsed history: turns behind the live tail get re-rendered as image pages; recent turns always stay text
3. The static system prompt and tool documentation slab

The proxy also preserves prompt caching by keeping the static prefix intact. Anthropic’s caching discount (cache read at 0.1× the input price) continues to apply to the imaged static prefix, because the same image bytes are sent on repeat requests. This is not a trivial detail: on long sessions where the system prompt and tool docs are cached, the effective savings from pxpipe stack on top of the caching discount rather than replacing it.

The Hacker News Reaction: Three Competing Interpretations

The HN comments on the pxpipe submission reveal three distinct framings of what this tool is, and the tension between them is more interesting than any of them individually.

Framing one: it’s a loophole that will get closed. User aabhay pointed out that Gemini, when processing PDFs, does an OCR pass internally and does not charge text tokens for the extracted text — the image billing covers it. If Claude’s backend is doing similar internal processing and the image price already accounts for that compute, then pxpipe is not really exploiting a gap; it’s exploiting a difference in how Anthropic chose to surface the billing, and that choice could be reversed. Several commenters assumed Anthropic would patch this once it became widely known.

Framing two: it’s an information-theoretic impossibility that works anyway. The __hugues thread reflects genuine confusion about how this could work without the savings appearing somewhere else in the bill. The answer — that the OCR overhead is externalized to Anthropic rather than billed to the customer — is satisfying from an accounting standpoint but raises the question of whether Anthropic is aware of and comfortable with this use of their infrastructure. A system prompt full of rendered code is not what Anthropic’s vision model compute was sized and priced for.

Framing three: the blame falls on Anthropic for bad pricing design. User anigbrowl, characteristically blunt on HN, put it this way: “I’m also disgusted by the incentive structure pxpipe promotes. I think ultimately blame falls on Anthropic for the poor pricing system that enables such arbitrage.” This is a reasonable position if you believe API providers have an obligation to price in ways that don’t create perverse incentives. The “speed up audio to cut Whisper costs” analogy the Sean Goedecke article raises is useful here: ffmpeg tricks to halve your audio processing costs are clever, but they represent a waste of engineer time solving a pricing problem rather than a real problem.

A fourth, quieter framing from user chickensong — “binary compression unpacked by OCR? This is the stuff of nightmares. So cursed, and yet…” — is probably the most accurate emotional register. This is a hack in the original sense: a clever, unexpected solution to a real problem that uses the system in a way it was not designed for. It works. It will probably keep working until Anthropic changes something. Whether you think it’s elegant or disturbing depends mostly on your priors about what API providers owe their customers in terms of pricing predictability.

What This Reveals About Anthropic’s Pricing Architecture

The pxpipe finding illuminates something that should have been obvious but is easy to miss: Anthropic’s pricing model treats text and image content as two separate, independently developed billing systems that were never reconciled for the case where images contain text.

Text pricing evolved from the language model training paradigm, where a “token” is a natural unit of computation because language models process tokens sequentially and the computation scales with token count. Text pricing at $X per million tokens is a reasonable proxy for inference compute if your users are sending natural language.

Image pricing evolved from the vision model paradigm, where the natural unit of computation is the image patch (usually a 32×32 pixel tile or similar), and processing cost scales with patch count which scales with pixel area. Pricing by pixel dimensions is a reasonable proxy for vision model compute if your users are sending photographs and diagrams.

Neither pricing model was designed with the case where users send images of text at the highest information density the model can reliably parse. The overlap region — vision models reading dense text — is the gap. It is not a gap either team left intentionally; it is the gap that appears between two systems built independently and joined at their edges.

This kind of pricing gap is structurally common at the intersection of two product lines. The historical analogy that comes to mind is the early days of cloud provider egress pricing, where data transfer between different availability zones in the same region was priced at a rate that made it cheaper to move data to a completely different region and back than to move it between AZs. No one designed this as an incentive; it was an artifact of how egress pricing was built before anyone thought carefully about intra-region transfers. It got fixed when the gap became large enough to matter.

The same thing will happen here. The question is how long the gap stays open and whether Anthropic patches it by raising image pricing (which would hurt vision users who are using images legitimately), by building a text-in-image detection system and pricing it differently, or by restructuring how they think about input pricing altogether to be compute-based rather than modality-based.

The Comparison Class: Other Pricing Arbitrages in AI APIs

pxpipe is not the first of its kind, and understanding the comparison class helps calibrate expectations for how long the gap stays open and how Anthropic is likely to respond.

The audio speedup trick predates the current LLM era: before sending audio to Whisper or similar transcription APIs, run it through ffmpeg to speed it up 2x. The model is robust enough to transcribe sped-up speech at roughly the same accuracy, and you’ve halved your audio minutes. This is still possible with most transcription APIs as of mid-2026 because fixing it would require transcription APIs to measure semantic content density rather than audio duration, which is non-trivial and potentially breaks legitimate use cases.

SnapCompact, referenced in the HN comments and published in June 2026 by Can Bölük at blog.can.ac, describes essentially the same idea as pxpipe applied to context compression: a 1568×1568 PNG holds approximately 40,000 characters in a 6×10 pixel font, billed as roughly one image price equivalent. SnapCompact arrived roughly three weeks before pxpipe hit HN; pxpipe is a more polished, production-tested implementation with a proxy wrapper, a dashboard, and benchmarks rather than a conceptual blog post.

lpellis tried the text-as-image technique with OpenAI models roughly a year ago and found the opposite result: input tokens decreased but output tokens increased enough to make it more expensive overall. This suggests the technique is model-specific — it requires a model that can parse rendered text efficiently without incurring significant output token overhead for the processing. Fable 5 (Claude’s current frontier) apparently meets this bar in a way that OpenAI’s models circa mid-2025 did not. Whether this is because Fable was specifically trained on more OCR data, or because Anthropic’s internal OCR is more efficient, or because the billing structure differs in a relevant way, is not documented.

The DeepSeek OCR paper is the academic underpinning of the entire category. DeepSeek’s finding that one image token can carry approximately ten text tokens of content with near-100% accuracy establishes that there is a real information-theoretic argument for why this should work, not just an empirical observation that it does. If DeepSeek’s result generalizes, then any sufficiently capable vision-language model should support similar compression ratios, and the pxpipe gap is not Anthropic-specific but a general property of how multimodal models process text.

Who Should Actually Use This

The use case profile is specific. pxpipe is genuinely useful for:

Long-running coding agent sessions with large codebases. This is the core use case. Claude Code sessions working against a large repository accumulate enormous amounts of tool output, file contents, and conversation history. The history tail that gets imaged is exactly the content where exact-recall requirements are lowest — the agent has already acted on those turns and will re-read files before acting again. Savings in this context are real and the fidelity loss is manageable.

Workloads where context pressure is the limiting factor. The demo showing 96% versus 7.35% context utilization for the same task illustrates a second benefit beyond cost: pxpipe effectively extends the practical context window. If you have tasks that are regularly hitting the context limit and forcing compaction, pxpipe lets you run them to completion without compaction by reducing the token footprint of accumulated history.

Teams with reproducible Claude Code workflows and high volume. The 59-70% end-to-end saving scales linearly with volume. A team spending $5,000/month on Claude Code bills could realistically save $2,500-3,500/month at the observed ratios, with the proviso that the actual savings depend heavily on workload composition.

It is not appropriate for:

Workflows where exact string values in conversation history matter. If you’re passing secrets, connection strings, commit hashes, or any byte-exact values through the conversation and expecting the agent to recall them from older turns, the 13% verbatim recall failure rate on Fable 5 is a serious risk. The mitigations (routing specific subagents to text models, keeping recent turns as text) help but do not eliminate the risk entirely.

Pure chat or natural language workflows. The economics don’t work for prose at 3.5 chars/token; the gate should prevent savings-negative compression but the overhead and latency are real even on pass-through requests. There is no reason to add a proxy layer if your Claude Code usage is primarily natural language discussion rather than code and tool execution.

Security-sensitive environments. The proxy routes all your Claude Code traffic through a local Node.js process. The README is clear that this is a local proxy and does not exfiltrate anything, but the security posture of running your Anthropic API traffic through an open-source Node process on your machine is a decision that should be made consciously rather than by default.

What Happens When Anthropic Patches This

Assuming Anthropic does close the gap — which seems likely given the attention pxpipe is getting — the options available to them reveal how constrained the problem space is.

Option one: raise image pricing. Simply increasing the per-pixel cost of images to account for the OCR compute overhead would close the arbitrage but would also raise prices for all vision users, including those sending actual photographs and charts. This is the bluntest instrument and the least likely choice because it punishes legitimate vision use cases.

Option two: detect text-heavy images and price them differently. Anthropic could build a classifier that estimates the text density of an uploaded image and charges text token rates for detected text content. This is technically feasible — the same vision model being used to read the text could estimate its density. But this creates a cat-and-mouse problem: pxpipe (or its successors) could respond by rendering at slightly lower density to stay below the detection threshold, or by adding visual noise that confuses the classifier while remaining readable to the model.

Option three: restructure to compute-based pricing. This is the most elegant but least near-term solution. If input pricing were based on actual inference compute consumed rather than on input modality and token count, the OCR overhead would automatically be reflected in the price. Anthropic would need significant telemetry infrastructure to bill at this level of granularity, and it would introduce pricing uncertainty that customers generally dislike.

Option four: do nothing for now. Anthropic may decide the user base for pxpipe-style workloads is small enough that the revenue impact of the arbitrage is acceptable, particularly if those users represent high-value customers they would rather retain at a discount than lose to a competitor. This is consistent with how cloud providers have historically treated many pricing edge cases — leave them alone until they become operationally significant.

The most likely near-term outcome is some version of option two, implemented imprecisely enough to close the obvious pxpipe use case while not materially affecting legitimate vision workflows. The pxpipe maintainer has already acknowledged this: the README notes that “list prices can change tomorrow and the token count won’t, so tokens — not dollars — are the number to watch.” They are explicitly flagging that the dollar savings are contingent on current pricing while the token compression is a physical property of the technique that will persist regardless.

The Longer Thesis: What AI API Pricing Has to Figure Out

The pxpipe finding is a data point in a larger pattern. AI API pricing in 2026 is fundamentally similar to cloud pricing in 2008: it works for the core use cases the providers designed for, and it breaks in interesting ways at the intersections between modalities, between products, and between provider intentions and customer incentives.

The text-token pricing assumption — that a text token is a unit of approximately equal compute cost — was reasonable when all the models being deployed were language models. It held up reasonably well through the GPT-3 and GPT-4 era when vision was a minor feature. It breaks when multimodal models become the default and when customers discover that routing content through the vision pathway is cheaper than the text pathway for the same content. This is not a bug in pxpipe’s design; it is a feature of a pricing model that was not designed for this use case.

Similarly, the image pricing assumption — that pixels are a reasonable proxy for inference compute — was reasonable when images were used to transmit visual information. It breaks when images are used to transmit textual information at maximum density, because the OCR compute per unit of information conveyed is far higher for dense text images than for typical photographs.

The deeper question the pxpipe finding raises is whether per-token / per-pixel pricing can survive as models become more capable. A sufficiently capable model can extract ten text tokens from one image token. If that ratio keeps improving — and there is no reason to believe it has plateaued — then the token as a unit of pricing becomes increasingly fictional. The token measures something about the model’s representation of the content, not something about the content itself or the compute required to process it.

Some providers are already moving toward time-based or compute-unit-based pricing for certain workloads. Anthropic’s own extended thinking feature, which bills separately for internal reasoning tokens, is a step toward pricing based on compute consumed rather than input/output volume. The pxpipe gap is a preview of the pricing architecture problems that will become endemic as models get better at processing information in non-standard formats.

For now, the practical upshot is straightforward: if you are running Claude Code against large codebases at scale, pxpipe is worth benchmarking against your own workload. The 60% figure is a measured result on production traffic, not a theoretical maximum. Your actual savings will depend on your workload composition, but the mechanism is sound and the tooling is mature enough to test in one afternoon. The loophole may close, but it is open today, the code works, and the benchmarks are reproducible.

Anthropic’s pricing team has a more complicated problem than closing a proxy. They need to figure out what they are actually charging for when the thing you are charging for can be arbitraged across modalities. Until they do, the pxpipe situation will recur in different forms every time someone finds a cheaper path through the modality boundary.

---

pxpipe is available on npm. Install via npx pxpipe-proxy or as a library from npm install pxpipe. The events log at ~/.pxpipe/events.jsonl lets you reproduce all claimed savings on your own workload. Source and benchmarks at github.com/teamchong/pxpipe.