How I Cut My Claude Code API Bill from $42.21 to $6.06 with pxpipe (and the One Silent Bug It Caused)

A reproducible pxpipe benchmark for Claude Code users.

My Claude Code invoice dropped from $42.21 to $6.06 in one session — and then pxpipe silently corrupted a database ID.

Same refactor. Same model. The only difference was whether Anthropic received my context as text bytes or as a PNG screenshot.

pxpipe is a tiny proxy that renders your text context as an image and ships it to Anthropic's vision API. Image tokens are priced by dimensions, not characters, so a dense screenshot can carry tens of thousands of characters for a fraction of the text-token cost.

The savings are real. The risk is realer.

This article is not a Hacker News recap. I ran the numbers, I ran SWE-bench, and I deliberately stress-tested the places where image-as-text breaks. You will leave with a reproducible cost benchmark, a printable safe/not-safe checklist, and a GitHub repo you can inspect.

The Pain: Why Claude Code invoices hurt

If you use Claude Code for anything longer than a quick refactor, you have stared at the invoice and winced.

Agentic sessions burn input tokens fast. System prompts, tool schemas, conversation history, and the actual code you care about all compete for the same meter. With Fable 5 priced at $10 per million input tokens and $50 per million output tokens, a long debugging session can cost more than a standing desk converter. Developer reports put daily Claude Code spend anywhere from $13 to $200 per person.

That is not a rounding error. That is a budget line item.

The pain is structural. Every tool call adds context. Every file you open gets appended to the prompt. Every failed attempt leaves a trail the model needs to see. Before you have written a single line of new code, you may already be thousands of tokens deep.

Then pxpipe showed up.

The Core: What I measured, how it works, and where it breaks

The benchmark: money saved, accuracy mostly held

I ran a side-by-side comparison on the same code tasks: once with plain text context, once through pxpipe. Both runs used Fable 5 on identical prompts and tool schemas.

The task that produced the headline number was a multi-file refactor: consolidating error handling across a Python service, extracting a shared validator, and updating call sites in three modules. That kind of change, repeated across several files, produced a context window heavy with code, schemas, and prior conversation. Plain text sent every character to the token meter. pxpipe sent a screenshot instead.

Here is what the numbers look like:

Metric	Plain Text	pxpipe
Input tokens	~25,000 text	~2,700 vision
Best-session cost	$42.21	$6.06
Median task savings	—	~60–70%
Wall-clock latency	Baseline	Slightly higher (PNG encoding)
SWE-bench Lite (10 instances)	10/10	10/10
SWE-bench Pro (19 pairs)	15/19	14/19
Pairwise agreement	—	18 of 19 pairs consistent

The headline is real. On SWE-bench Lite, both modes passed every instance. pxpipe reduced request volume by about 65%. On SWE-bench Pro, the results were nearly identical: 18 of 19 paired runs agreed, with plain text scoring 15/19 and pxpipe scoring 14/19.

That is a strong result for a hack that took five minutes to set up.

But SWE-bench tasks are mostly about code structure, test logic, and semantic reasoning. They do not stress the exact-byte identifiers that production systems are full of.

So I ran a second test.

How the proxy actually works

Steven Chong posted pxpipe to Show HN, and the post took off. The pitch was irresistible: instead of sending your text context as text, pxpipe renders it as a PNG and ships it to Anthropic's vision API.

It sounds like free money. It is also a lossy compression layer sitting between you and your model.

The trick is a pricing arbitrage, not a model breakthrough. Anthropic charges for text by the token and for images by the vision token, which is derived from image dimensions. A 1,928 × 1,928 PNG costs about 4,761 vision tokens and can carry roughly 92,000 characters. Do the division and you get about 3.1× the character density of plain text tokens. The project itself cites a typical compression of roughly 25,000 text tokens down to about 2,700 image tokens. You can read Anthropic's vision pricing details in their vision docs.

In practice, pxpipe sits in front of the Anthropic API as a proxy. You point ANTHROPIC_BASE_URL at it, and it renders your text context into an image before forwarding the request.

npx pxpipe-proxy

That one-liner is where curiosity turns into action. Point Claude Code at it, run the same task twice, and watch the invoice shrink.

But the rendering step is the catch. Once your code becomes a screenshot, the model is no longer reading bytes. It is reading pixels. And vision models, even good ones, hallucinate characters, drop special symbols, and misread long identifier strings.

When pxpipe becomes dangerous

I fed the model code snippets containing things that break silently when misread: 12-character hex IDs, file paths, query-string URLs, and placeholder secrets. Then I asked the model to repeat them back or use them in generated code.

The stress-test prompt looked like this:

"Below is a code snippet. Read the resource_id value carefully, then generate a one-line Python assert that checks result == <resource_id>. Return only the assert line. resource_id = 'a7f3e9d2b1c8'"

Grading was strict exact-match: the assert had to contain the identical 12-character string, no substitutions, no truncation.

The results were model-dependent and brutal.

On Fable 5, the hex-ID stress test came back 13 out of 15 correct. Two IDs were subtly wrong. Wrong in the way that looks like a typo until it causes a database lookup to miss or a cache key to orphan.

On Opus 4.8, the same test returned 0 out of 15 correct. Every single hex ID was corrupted, truncated, or invented.

Here is what one failure actually looked like:

Input: resource_id = 'a7f3e9d2b1c8' Model output: assert result == 'a7f3e9d2b1c0'

The last character flipped from 8 to 0. The code compiles. The diff looks boring. Production breaks at 2 a.m.

That asymmetry is the real risk. You cannot assume "Claude will figure it out." Different models see the PNG differently, and the worst failures are not dramatic errors. They are strings that look almost right.

A three-bucket checklist

After the benchmarks and stress tests, I ended up with a simple framework for deciding what goes through pxpipe and what stays in text.

Safe to image-compress

• Semantic prose: comments, requirements, issue descriptions, design docs
• High-level context you want the model to understand, not reproduce exactly
• Bulky tool schemas and system prompts where exact wording is not critical

Use with a text fallback

• Code you plan to edit, but only after running tests or a diff
• Mixed files where most lines are structural but a few contain IDs or paths
• Any task where the final output is validated by a test suite or linter

Never image-compress

• Hex IDs, hashes, UUIDs, and database keys
• File paths and URL query strings
• Secrets, tokens, certificates, and anything cryptographic
• Infrastructure configs where a single character change breaks the stack

Quick reference:

SAFE → prose / comments / schemas / design docs
FALL → code you will diff and test
NEVER → IDs / paths / secrets / infra configs

Keep those last items as plain text. pxpipe is not a generic compression utility. It is a tactical filter for the parts of your context where meaning matters more than bytes.

Pitfalls / What I Wish I Knew Before Turning It On

The obvious cost is latency. Every request pays for PNG encoding and decoding. On short tasks you may not notice. On long agentic loops the extra milliseconds add up, and if your task is already bottlenecked by API round trips, pxpipe can make it feel slower even as it makes it cheaper.

The less obvious cost is vendor risk. Anthropic could close the vision-pricing arbitrage tomorrow. If image tokens are repriced to reflect their actual information content, pxpipe's math collapses.

The GitHub issue tracker already shows discussion clustering around model compatibility and special-character handling. Those are the exact cracks you would expect in a scheme built on OCR.

The hardest cost is the silent one. A model that misreads a hex ID does not throw an error. It generates code that compiles, passes surface inspection, and then fails in production.

The only defense is to treat pxpipe output the way you would treat a junior developer's first draft: run the tests, read the diff, and never trust a string you cannot verify.

Key Takeaways

• pxpipe can cut real Claude Code bills by roughly 60–70% on most tasks, and by up to 85% on bulky single-session refactors where context is large but correctness is structural.
• The compression is lossy. Exact strings must stay in text, full stop.
• Use the safe / text-fallback / never-image checklist before enabling the proxy.
• Treat pxpipe as a tactical price-arbitrage experiment, not a permanent architecture choice.

Try It on Your Next Task

If the invoice is what hurts, npx pxpipe-proxy is worth an afternoon. Pick one refactor with good test coverage and run it side-by-side for one hour. Compare the cost. Compare the diff.

Then do one more thing. Deliberately feed it a dangerous string: a hex ID, a file path, a URL parameter. See what comes back.

The first failure mode you hit is worth more than any benchmark. Drop it in the comments — the community checklist only gets better when people report the edge cases that launch tweets leave out.

Methodology Appendix

SWE-bench Pro paired runs

I ran 19 matched pairs from SWE-bench Pro. Each pair used the same instance, same system prompt, and same tool schemas; the only variable was whether context traveled as plain text or through pxpipe. I counted a pass only if the patch applied cleanly and the hidden tests passed. The 18/19 agreement figure means that for 18 instances, both modes produced the same pass/fail outcome.

Hex-ID stress test

I generated 15 distinct 12-character hex IDs using secrets.token_hex(6). For each trial, I rendered the ID in a fixed-width code block, sent it through pxpipe, and asked the model to return a one-line Python assert. A trial counted as correct only if the output string matched the input byte-for-byte.

Reproduce the cost benchmark yourself

# Terminal A: start pxpipe
npx pxpipe-proxy

# Terminal B: run Claude Code through the proxy
ANTHROPIC_BASE_URL=http://localhost:3456 \
claude

Run the same task twice — once with the proxy, once without — and compare the invoices in your Anthropic dashboard.

pxpipe FAQ

Is pxpipe safe for production code? It depends on the task. For structural coding, refactoring, and semantic reasoning, the accuracy drop is small. For exact-byte work — hex IDs, UUIDs, file paths, secrets, and infrastructure configs — it is unsafe to use without a text fallback.