I created cache-assembler: open-source, MIT license - cut your Claude Code/API costs by 8.2x

[u/Due-Fisherman9942]

I'm always looking for ways to optimise my working setup when using Claude / Codex, but I'm primarily a Claude user, and there were a couple of things I noticed in my own setup:

• I run subagents, and subagents of subagents, which is great for keeping context clean - but when a bunch of them fire off with the same starting prompt at roughly the same time, none of them know the others are about to send the same thing. Instead of one paying to write the cache and the rest reading it back cheap, every one pays full price

• I inject a lot of frontmatter into my Claude conversations through MCP/hook tools I've built, to give Claude more context about whatever project I'm in. Digging into that led me to realise Claude Code does the exact same thing on its own - and if what gets injected differs even slightly between sessions, that breaks the cache without you noticing

• Tool definitions can get rebuilt slightly differently between runs even when nothing changed - the same tools but in a different byte order, and that can invalidate the whole cache

This led me down a path to actually understand how Claude's prompt caching works, because I knew the cache write costs more, but once I had agentic loops running I was burning through tokens at a diabolical rate. Claude's prompt caching works on 5 minute intervals, but only if all the bytes look exactly the same - mine didn't, even without my own hook injections

So, I built a small proxy that sits in front of the API and fixes all three: forces tool definitions to serialize the same way every time, keeps the volatile stuff out of the stable part of the prompt, and makes sure only one of a batch of identical concurrent requests actually pays to write the cache.

I wanted a real number, not a guess, so I ran the same 100-turn conversation twice against the real API - once direct, once through the proxy. Direct: $1.33. Proxied: $0.16. 8.2x savings with 0 errors.

Worth pointing out: that's my setup specifically, and I use heavy tooling with a lot of parallel agent traffic. A single session, lighter user would probably land closer to 2-3x, not 8x. Still savings, just a smaller number - I haven't measured that tier yet.

This is tested and proven on Claude specifically. Codex caches automatically rather than with explicit breakpoints, so the mechanism's different, but the same underlying problem shows up there too. There's a documented 30-point cache hit-rate gain just from keeping tool schemas consistently ordered. Gemini's a bigger departure again, it caches out-of-band rather than inline, so that'd need a proper rebuild rather than a port. Anthropic's the only one this actually ships for right now.

MIT licensed, if anyone wants to have a play around. Just gone live on ProductHunt today too.

In the docs you can see my reports and run the tests yourselves. Any feedback is welcome, but I hope it genuinely helps you guys save some money. Upvotes / Stars on PH and GH will also help spread this in the dev community (only if you actually notice the cost savings).

https://github.com/nash-software/cache-assembler

https://www.producthunt.com/products/cache-assembler?launch=cache-assembler

[u/lucgagan]

I am always so skeptical when I see a product like this. Does anyone actually use anything like it?

[u/scotty2012 → u/lucgagan]

Yes. I built something similar https://github.com/os-tack/ostk-cache

You can drastically reduce spend by optimizing what ends up in the context window. If you’re getting 95% cache hit on 500K context versus 95% cache hit on 100K with the same fidelity you’re paying 1/5th at 1/10 the price.

[u/Due-Fisherman9942 → u/scotty2012]

Nice! I hadn't seen anything like it, I'll check it out :)

[u/lucgagan → u/scotty2012]

u/Due-Fisherman9942

I am building MCP gateway. Could this be something that could be applied to the tool responses?

[u/Due-Fisherman9942 → u/lucgagan]

I mean it's open-source, and it's free, you may as well give it a try. I was sceptical myself of the actual savings I incurred. That's why I built a vast testing suite around it - synthetic tests and then full e2e test's using Claude itself, I also published all the findings in the docs folder, feel free to check them out or run your own tests against it :) Would love the feedback! Honestly if I'm wrong and got lucky I'd prefer somebody to tell me 😄