Over the weekend a tweet made the rounds claiming a developer had found a way to cut Claude API bills by up to 70% by exploiting image-vs-text token pricing. The tool is pxpipe, an open-source proxy that intercepts your API requests and re-renders the bulky text parts — system prompts, tool docs, old conversation history — as densely packed PNGs. The arbitrage is real in principle: text is billed per token of content, while an image is billed by pixel area regardless of how much text you cram into it. Pack the pixels densely enough and the same information rides in fewer tokens.
I wanted to test it. Not the headline number — the counterfactual. The pxpipe pitch compares Fable 5 reading images against Fable 5 reading text. But if you're willing to accept degraded fidelity to save money, the honest alternative isn't degrading your frontier model's inputs. It's using a cheaper model with clean text. At current prices (Fable 5 at $10/$50 per million tokens in/out, Opus 4.8 at $5/$25, Sonnet 5 at $2/$10 introductory), even pxpipe's claimed 3.1× compression puts Fable-reading-images at an effective input cost above Sonnet reading lossless plain text. My hypothesis going in: the trick loses to a model downgrade on cost before accuracy even enters the conversation.
I never got to finish testing that hypothesis. What I found instead was more interesting.
The harness
The setup was simple: generate synthetic documents dense with exact values (the kind of content where image compression's known weakness — silently misreading precise strings — would show up), render each document both as plain text and as packed PNGs, and run six conditions across Fable 5, Opus 4.8, and Sonnet 5. Two tasks per trial: exact recall (retrieve a specific 12-character value) and gist (answer a semantic question about the document). Track accuracy, silent confabulations, tokens, and cost.
First run, Fable 5 failed everything. Not just image trials — plain text too. Exact recall, gist questions, all of it. Meanwhile Opus and Sonnet sailed through, and Sonnet even read the image-rendered context fine, which already complicated the "you need a Fable-class model for this" premise.
A model that can't copy a string out of a 3,000-token text document isn't a model failing. It's a harness bug or something weirder. I added diagnostics:
stop_reason='refusal'
stop_details={'type': 'refusal', 'category': 'cyber', 'explanation':
"This request triggered restrictions on violative cyber content..."}
Fable 5 wasn't misreading the documents. It was refusing to read them — returning HTTP 200 with an empty content array and a cyber classification. And billing the full input tokens for each refusal.
The sanitization spiral
My first document was a synthetic ops config: service names, deploy hashes, regions. Fair enough — hex strings labeled deploy_hash in a config dump could plausibly pattern-match to credential harvesting. So I defanged it.
Round one: a retail shop inventory. Ceramic mugs, wool blankets, suppliers named Hartley & Co. The 12-character hex values became archive_code fields on catalog items. Refused.
Round two: I removed hex entirely. Values became 12-digit numbers formatted like order references (4829-3017-5566) — "what's the order ref for this item" is about as innocent as retrieval gets. Refused.
At that point I ran a bisection probe: a ladder of prompt variants from trivially benign to the full test prompt, checking stop_reason at each rung. The trigger turned out to be the instruction, not the content. "What is the order_ref for item-wool-53-004?" passed. The identical question followed by "Reply with ONLY the number, nothing else" was refused — category cyber. The machine-parseable output constraint — the way every automated pipeline on earth phrases extraction requests — is apparently what the classifier keys on.
So I stripped the instruction. Refused again on the next run, on the same phrasing that had just passed the probe. The classifier is nondeterministic, or sensitive to per-trial content variation in ways I couldn't isolate.
Round three, I rebuilt the whole experiment around a friendlier scenario: an appliance fault guide with not one alphanumeric identifier in it. Faults with names like "cold-start shudder," remedies like "fit a replacement cedar valve kit." A technician asks which parts to bring. This is a children's-book version of a reference lookup. Refused — text and image conditions alike.
Notice the direction of travel. Every round of sanitization made the test less like the real workload. Actual error-code catalogs, SOP appendices, and ops runbooks — the dense reference content that image compression is pitched for — are full of hex, part numbers, and machine formatting. I couldn't get Fable to accept even the sanitized versions. The gap between what Fable will read and what users actually have is the finding.
What we measured anyway
The runs that completed produced three data points worth keeping.
Compression came in at about 1.7×, not 3.1× — a 3,105-token text document rendered to 1,842 image tokens. Packing density depends heavily on font size, layout, and content; pxpipe's number may be achievable with more aggressive packing, but it isn't what a straightforward implementation gets. At 1.7×, Fable-plus-images has an effective input cost around $5.90 per million text-equivalent tokens — roughly triple Sonnet 5 reading plain text.
Sonnet 5 read the image-rendered context accurately in every trial it saw (small sample, n=4, so treat it as a hint rather than a result). The public reports that motivated the "frontier-only" framing tested byte-exact hex recall, a harder visual task than most real retrieval. The premise that this trick is gated to the expensive tier deserves more scrutiny than it's gotten.
And the refusal tax is real: each refused call billed its full input — about $0.03 per attempt on my 3,100-token documents at Fable prices. Refusals being nondeterministic means retries, which means paying the tax repeatedly. On the API, unlike the consumer apps, fallback routing to another model is not automatic — you configure it yourself. And if your fallback is Opus or Sonnet anyway, it's fair to ask why the pipeline doesn't just start there.
Is it just us?
No — and yes. The broader false-positive problem is well documented. Anthropic has said openly that Fable 5's safety margin is "much larger than in any prior launch", accepting benign blocks as the cost of shipping the capability at all. The Register covered refusals of innocuous prompts; byteiota catalogued false positives on SSH configs, POSIX syscall names, and AWS reliability vocabulary; a June redeployment made the classifier stricter, and debugging benchmark scores dropped 70% as tasks silently rerouted to a weaker fallback.
But I can't find anyone reporting this specific experience: the cyber classifier refusing dense reference-lookup workloads as a category. pxpipe's own README warns about silent confabulation on exact strings and says nothing about refusals — plausibly because its demo workload is code generation over organic source files, not retrieval over identifier tables. As far as I can tell, this post is the first published account of that particular collision. Which is exactly why everything I ran is linked below: one experience isn't a refusal rate, and I'd like to see replications — especially failed ones.
Where this leaves the 70% trick
Two caveats before the conclusion. The test corpora were synthetic and highly repetitive, and it's possible a "machine-generated bulk content" heuristic fired harder here than it would on organic documents — though the public false-positive reports cover organic content too, and real ops material is more identifier-dense than anything I managed to get accepted, not less. And Anthropic tunes this classifier actively; everything above describes early July 2026 and could improve. It could also get stricter. It already did once.
With those on the table: the pxpipe debate has been framed as accuracy versus cost, and I think that's the wrong axis entirely. The measured compression already loses to "use a cheaper model with plain text" on price. What actually sinks the approach is deployability. The trick requires the one model tier whose safety layer treats dense, machine-shaped context — the precise workload the trick exists to serve — as hostile, refuses it unpredictably, and charges you for every refused attempt. Token arbitrage built on a frontier model inherits that model's safety posture. And the safety posture is a moving target you don't control.
Good luck.
Reproduce it
All three harnesses are small, dependency-light Python scripts (pip install anthropic pillow, bring your own API key):
image_vs_text_cost_test.py— the six-condition accuracy/cost harness (3 models × image/text, exact-recall + gist tasks, per-query cost from current pricing, incremental CSV output, refusal tracking)refusal_probe.py— the bisection ladder that isolated the instruction-phrasing triggercatalog_lookup_test.py— the context-stuffing vs retrieval-pipeline comparison (Fable+image vs Fable+text vs Sonnet-extract→Fable vs Sonnet end-to-end), including the fully identifier-free fault-guide variant that was still refused
A full run of the main harness costs about $2–5 in API spend. If you replicate — successfully or not — I'd love to hear about it.