This Small Tool Cut My Claude Code Token Bill by 53 Percent, Here’s How It Works
A developer named teamchong built a small open-source tool called pxpipe that cuts your Claude Code input-token bill by taking the bulky, repetitive parts of every request and rendering them as PNG images instead of sending them as text. It sounds like it shouldn’t work, and the fact that it does…
A developer named teamchong built a small open-source tool called pxpipe that cuts your Claude Code input-token bill by taking the bulky, repetitive parts of every request and rendering them as PNG images instead of sending them as text. It sounds like it shouldn’t work, and the fact that it does reveals something real about how these models are priced.I will explain what it is, why the trick works, how to set it up in about 30 seconds, and the honest catch, and then I will show you what happened when I actually ran it on my own workload, where it cut my token usage by 53 percent.Every request Claude Code sends carries a lot of dead weight. The same system prompt, the same tool documentation, the same older conversation history, the same big file dumps and command outputs, over and over, and you pay input tokens for all of it every single time. Anyone who has run an AI coding agent on a real project has watched the token meter climb and known, intuitively, that most of what they’re paying for is the same bulky context being re-sent on every turn.A developer going by teamchong looked at that waste and had an unusual idea, what if you didn’t send that bulk as text at all, what if you sent it as a picture. The result is pxpipe, an open-source tool sitting at around 2,400 stars, and it’s one of those hacks that makes you laugh and then makes you think. I came across it, could not quite believe the premise, and installed it to see for myself. It is running on my setup as I write this. The core trick is so counterintuitive that it’s worth understanding even if you never install the thing, because it reveals something real about how AI pricing actually works.The trick, and why it is not as crazy as it soundsHere’s the insight the whole thing rests on. When you send text to a model, you pay per token, and dense text like code, JSON, or logs costs roughly one token per character. When you send an image to a model, though, the token cost is fixed by the image’s pixel dimensions, not by how much text is printed inside it. A given image costs the same number of tokens whether it shows a blank square or a wall of dense text.That gap is the entire opportunity. If you take a big slab of text, say a 48,000 character system prompt that would cost around 25,000 tokens as text, and you render it as a densely packed image instead, that image might cost only around 2,700 tokens. Same information, roughly a tenth of the token cost. According to the project’s measurements, dense content packs about 3.1 characters per image-token versus about 1 character per text-token on real Claude Code traffic. You’re exploiting the fact that a picture of text is priced by its size, while the text itself is priced by its length.pxpipe is the machinery that does this automatically. It runs as a small local proxy on your own machine, sits between Claude Code and the model, intercepts each outgoing request, finds the bulky parts that are worth converting, renders them into compact PNG pages, and forwards the request along. The model reads the images, does the work, and responds normally. You don’t change how you use Claude Code at all, the proxy just quietly makes the requests cheaper on the way out.The part that makes it clever rather than recklessThe obvious worry is that this sounds lossy, and it is, which is exactly why the interesting engineering is in knowing when not to do it. pxpipe doesn’t blindly image everything, because for some content, imaging would actually cost more or break things.The tool does the math on every request. There’s a break-even point, based on how dense the text is, above which imaging saves money and below which it costs money. Dense content like code and logs is cheap to image and expensive as text, so it wins. Sparse content like ordinary prose is the opposite, so imaging it would lose money, and pxpipe leaves it as text. The project describes a profitability gate calibrated on hundreds of real production requests that decides, per request, whether converting actually pays. It only images where the numbers work.It’s also careful about what it converts structurally. Your recent conversation turns stay as text, because those are what the model is actively working with. It’s the older, collapsed history, the static system prompt and tool docs, and the large file-and-command dumps that get imaged, the stuff that is bulky and repetitive but not part of the immediate back-and-forth. And crucially, it only ever compresses the request going out, never the model’s response coming back. The output you read streams normally as text.How to actually try it, and how my setup wentThe setup is genuinely a 30-second thing, which is part of the appeal, and I can confirm it just worked for me with no fuss. It runs through npx with no real installation, and you point Claude Code at it with an environment variable.You start the proxy in one command.npx pxpipe-proxyThat launches the proxy locally on port 47821. Then you tell Claude Code to route through it by setting its base URL to the local proxy when you launch.ANTHROPIC_BASE_URL=http://127.0.0.1:47821 claudeThat’s the whole setup. Claude Code now sends its requests through pxpipe, which images the bulky parts before they leave your machine. There’s nothing else to configure to get started, and in my case it came up cleanly on the first try and Claude Code behaved exactly as normal, which is the point, you are not supposed to feel it working.The tool also gives you a live dashboard in your browser at the same local address, and this is worth opening, because it shows you the trick working in real time. You see how many tokens you are saving, every text-to-image conversion laid out side by side so you can see exactly what got turned into a picture, live indicators of which models are active, and a kill switch to turn the imaging off instantly if you want to compare. It turns an invisible backend optimization into something you can actually watch, which makes it much easier to trust, and it is where you will see your own savings number add up.Turning it on for each model, step by stepThe important thing to understand is that pxpipe does not image for every model, and it should not, because the whole trick depends on the model reading pictures of text accurately, and they differ a lot at that. The tool controls this through a single setting, an environment variable called PXPIPE_MODELS, plus matching toggles on the dashboard. Here is how each model is handled and how to change it.Fable 5 is on by default, and it is the model the whole thing is tuned for, because it reads these dense renders essentially perfectly. If you run Claude Code with Fable 5, imaging is already active with no extra steps, the default setting covers it. This is the configuration you want for the biggest, safest savings, so most people do not need to change anything at all.Opus 4.8 is off by default, and turning it on is a deliberate opt-in. Because Opus misreads roughly 7 percent of imaged renders, pxpipe refuses to image for it unless you explicitly say so, which is the responsible default. If you want to enable it anyway, you add it to the model list when you start the proxy, or you flip its chip on in the dashboard. On the command line that looks like setting the variable to include both models.PXPIPE_MODELS=claude-fable-5,claude-opus-4-8 npx pxpipe-proxyOther models follow the same rule. The default allowlist covers Fable 5 and a current GPT model, and anything not on the list simply passes through as normal text, untouched, byte for byte. Older GPT models read imaged context worse, so they are also left off by default and can be opted in the same way through the model list or the dashboard. The principle is consistent, image only where the model reads it reliably, pass everything else through unchanged.To turn imaging off entirely, you set the same variable to off, which makes pxpipe a transparent passthrough that changes nothing.PXPIPE_MODELS=off npx pxpipe-proxyAnd for the exact-string safety valve, there is a separate setting worth knowing. If part of your work involves byte-exact values that must never be imaged, you can route that work to a subagent on a model outside the allowlist, which forces it through as plain text. You do that by pointing the subagent at a passthrough model, either with an environment variable or in the agent’s frontmatter.CLAUDE_CODE_SUBAGENT_MODEL=claude-sonnet-4-6The short version of all this is that the defaults are already the safe, sensible setup, Fable 5 imaged, everything uncertain left alone. You only touch these settings if you want to opt a riskier model in, turn the whole thing off, or deliberately push exact-string work down a text-only path.The honest catch, which the project is refreshingly upfront aboutHere’s where I appreciate this project, because instead of overselling, its own documentation is blunt about the failure mode, and you should understand it before using it.The core catch is that imaging text is lossy for exact strings. The model reads the gist of an imaged page well, but it can misread individual precise characters, and when it does, it does not throw an error, it just confidently reads the wrong thing. The project measured this directly, on a test of recalling exact 12-character hex strings from dense imaged content, the results were imperfect even on the best-performing model and much worse on others. The practical rule that follows is important, byte-exact values like IDs, hashes, secrets, and precise tokens must stay as text, never imaged, because a silently wrong hash is worse than an expensive one. The tool keeps recent turns as text partly for this reason, and it lets you route exact-string work to a passthrough path.There’s also a model-specific wrinkle worth knowing, and this is the part to be careful about. Different models read imaged text with very different fidelity. According to the project’s own benchmarks, Fable 5 reads these dense renders extremely well, scoring essentially perfectly on the gist-and-reasoning tests, which is why it’s the default target. Other models read imaged content measurably worse, the project found Opus 4.8 misreads roughly 7 percent of renders and an older GPT model degraded on imaged context, so pxpipe deliberately leaves those models switched off by default and makes you opt them in. That’s the responsible design choice, image only where the model reads it reliably, and pass everything else through untouched. It’s worth internalizing that this technique isn’t uniformly safe across models, it depends on the specific model reading pictures of text accurately, and not all of them do.The other honest caveats are smaller. Encoding pages into PNGs adds a little latency to large requests before they go out. The savings depend entirely on your workload, token-dense coding work benefits a lot, while sparse prose does not benefit at all. The project reports headline savings of around 59 percent on one large real-world trace and around 70 percent on another, measured on its own traffic and reproducible from the logged data. The exact figure is workload-dependent, so the honest move is to watch your own dashboard rather than assume any specific number.What happened when I ran itEnough theory, here is my own experience with it. Setup was exactly as painless as advertised, the npx command brought the proxy up cleanly on the first try, I pointed Claude Code at the local address, and from there everything felt completely normal. That is the part that matters, I did not have to change how I work at all, the proxy just sat quietly in between and did its thing.Then I opened the dashboard and watched. Over my usage, on the kind of token-dense coding work I actually do, the overall saving settled at 53 percent. That is my real number, straight off the dashboard, on my own traffic, not a benchmark from a README. A little more than half of my input-token cost simply went away, for content that was being re-sent on every turn anyway, and the model on the other end kept doing the work as if nothing had changed.Fifty-three percent sits a bit below the 59 to 70 percent the project reports on its own traces, which makes sense, my mix of work is my own, and the savings scale with how dense and repetitive your context is. But that is the point worth emphasizing, the exact figure will differ for everyone, and the honest thing is that I watched mine accumulate live rather than trusting a number someone else published. On my workload, the trick paid off clearly, and I could see exactly where every saved token came from.There’s one more thing about pxpipe that elevates it from a clever hack to something genuinely fun, and it’s buried near the bottom of the documentation. Someone asks, in the project’s own FAQ, why the documentation reads like an AI wrote it. The answer is that one did. Most of the repository’s code and documentation were written by AI coding agents running behind pxpipe itself, reading their own collapsed history as image pages while they worked.Sit with that for a second. The tool that turns context into images was largely built by AI agents who were themselves reading their context as images, compressed by the very tool they were building. It’s a small ouroboros of a project, an AI-cost-reduction tool bootstrapped by AI agents running under the cost reduction. Whatever you think of the technique, that’s a genuinely clever demonstration that it works well enough to build a real, working, benchmarked tool on top of.What to take from itpxpipe is worth knowing about on two levels. On the practical level, if you run Claude Code heavily on token-dense work and your bill has been climbing, it’s a free, MIT-licensed, 30-second thing to try, with a dashboard that shows you exactly what it’s doing and a kill switch if you don’t like it. It installed and ran cleanly for me, so the barrier to just trying it is genuinely low. Just respect the catch, keep exact strings as text, and understand it only images reliably on models that read pictures of text well.On the more interesting level, it is a reminder that the way these models are priced has exploitable seams, and that a sharp developer paying attention can find real savings in the gap between how something is billed and how it actually works. The specific trick may or may not fit your workflow. The mindset behind it, looking at what you are being charged for and asking whether there is a cheaper representation of the same information, is worth carrying into everything you build on top of these models. Someone looked at a wall of repeated text and thought, that could be a picture. That’s the kind of thinking that finds the savings everyone else walks past.pxpipe is an open-source project by its independent author. The 53 percent figure is what my own dashboard showed on my workload, and the higher numbers cited are the project’s own measurements, all reproducible from logs but dependent on your specific usage. Treat exact-string handling with care, and watch the savings on your own dashboard before relying on any particular number.This story is published on Generative AI. Connect with us on LinkedIn and follow Zeniteq to stay in the loop with the latest AI stories.Subscribe to our newsletter and YouTube channel to stay updated with the latest news and updates on generative AI. Let’s shape the future of AI together!This Small Tool Cut My Claude Code Token Bill by 53 Percent, Here’s How It Works was originally published in Generative AI on Medium, where people are continuing the conversation by highlighting and responding to this story.Source: Generative AI Pub — Published — Category: Image AI