If you use Claude Code seriously, you have probably noticed the bill creeping up in a way that does not quite track with how much actual work you are doing. Every turn ships the full conversation history back to the model. The longer a session runs, the more tokens you burn just on repetition. Context bloat is quietly the biggest drain on your token budget, and it compounds fast.
That frustration is what led me to build Decompute.
The core problem
Most of what ends up in a Claude Code context window is filler. Build logs with hundreds of identical lines. Tool output you read once and moved on from. Error traces that repeat the same stack three times. The model does not need any of that at full fidelity to give you a good response. You are paying to send noise upstream, and it is eroding your context headroom at the same time.
That second part matters as much as the cost. Context headroom is how much room you have left in the window before Claude starts losing track of earlier parts of the session. If your context fills up with bloated tool output from an hour ago, you lose headroom for the stuff that actually matters: your current file, your current question, the decisions you made ten minutes ago. Compression is not just about saving money. It is about keeping your session coherent for longer.
How the compression works
The compression engine I built is called YSCompress. It sits in the gateway layer and runs on each request before it goes to Anthropic. The idea is simple: strip the context down to its information-dense parts without losing meaning.
In practice that means a few things. Repeated log lines get collapsed into a representative sample with a count. Tool output that is structurally redundant gets summarized. Long file contents that have not changed between turns get referenced rather than resent in full. The goal is to preserve what the model actually needs to answer your next message, and drop what it does not.
The key constraint I designed around is that compression has to be lossless in terms of semantics. The model should not behave differently on the output side. The response quality cannot degrade. If the compressed context would cause the model to lose something meaningful, it does not compress that part. Headroom savings come from cutting the genuinely redundant stuff, not from cutting corners.
The architecture
Decompute is a local gateway that intercepts the requests Claude Code makes to Anthropic. Claude Code sends to localhost instead of directly to the API, the gateway compresses and routes, and the response comes back the same way. From Claude Code's perspective, nothing changed. Same model, same API shape, same output.
The routing layer is called Yellowstone. It handles the proxy logic and makes sure compressed requests land at the right endpoint cleanly. The extension and the CLI both talk to it the same way.
It is BYOK by design. Your Anthropic key lives on your machine in a local file with owner-only permissions. It is never committed, never synced through VS Code, never touches any server I run. The gateway only ever sees the request in transit, compresses it, and forwards it. I wanted to build something I would actually trust to run on my own machine, and that meant not creating any reason to hand over credentials.
The VS Code extension
I built a VS Code extension to make routing opt-in without requiring terminal setup. Install it, run "Enable Routing," and it points both the Claude Code terminal CLI and the panel at the local gateway. The status bar shows you whether routing is active and how your usage looks.
A few things I was deliberate about: it does not turn on silently, it does not break anything if the gateway is not running, and it does not touch your key storage. The extension is intentionally a thin client. The compression logic lives server side. The extension just wires things up and stays out of the way.
What it actually changes
The practical effect in a long session is that your context window stays cleaner. You can go deeper into a problem before hitting limits. The model retains more of the session that matters. And your token spend scales with how much you are actually doing, not with how much log output accumulated in the first twenty minutes.
The savings are heaviest on the kind of context Claude Code generates naturally: verbose build output, repeated file reads, long tool responses. On already-tight short prompts there is not much to compress and it mostly passes through. But those are not the sessions where cost or headroom is ever really the problem anyway.
If you have been watching your usage climb without a clear reason, this is probably where it is going.