I built a Claude / ChatGPT API relay because my API bill was eating my side-project budget
I built a Claude / ChatGPT API relay because my API bill was eating my side-project budget
Three months ago, I was building a small SaaS project on the side.Nothing too crazy. No big team, no massive traffic, not even real users yet.
Then I checked my Anthropic bill for that week: $85.For a side project that basically nobody was using yet, that felt painful.
I wasn’t doing anything unusual either. I was just using Claude Code to iterate on features, debug things, and go through normal back-and-forth development. But when you’re in flow and not paying close attention, token usage adds up fast.
Before talking about what I built, here are the changes I made first, and what actually moved the needle for me:
Model routing
I used to send almost everything to Opus 4.8 by default.Later, I started routing simpler tasks to Haiku instead: boilerplate generation, log summaries, simple one-off code snippets, and other things that didn’t need deep reasoning.
That alone cut my costs by around 40%.For hard problems, I still use Opus 4.8.
Cutting context waste
Claude Code keeps a lot in context by default. If you’re not careful, long sessions can quietly grow past 50k tokens.So I started using /clear when switching tasks, and opening a fresh window for unrelated work.
Obvious in hindsight, but it made a real difference.
Prompt caching
If you have a large system prompt or repeated context blocks, caching can meaningfully reduce input costs.
Not everyone needs it, but it’s worth knowing it exists.
Measure before optimizing
I wasted about two weeks guessing where the problem was.Once I actually looked at the usage breakdown, I realized one specific workflow was responsible for around 70% of my token usage.
Fixing the biggest leak mattered way more than making tiny optimizations everywhere.
Those four changes cut my bill by roughly half.But I still wanted to push it further, so I built Kaatta.
The honest description: Kaatta is an API relay that sits in front of the official Claude and GPT APIs.
You point your base URL to Kaatta, and you can use the same models at about 70% of the official price. Everything else stays the same: same models, same outputs, just a one-line config change.
For Claude Code, the setup looks like this:
ANTHROPIC_BASE_URL="https://kaatta.com" ANTHROPIC_AUTH_TOKEN="your-key" claude
That’s it. Claude Code handles the rest.
If you’re using "cc-switch", point it to:
Just don’t include the "/v1" suffix there.
For OpenAI-compatible clients, the base URL should be:
The obvious question is: doesn’t reselling API access sound a bit sketchy?
Fair question.
The tradeoff is that your requests go through one extra third party, instead of going directly to the official provider. Your requests pass through Kaatta, but we don’t store or read your conversations.
For side projects, prototypes, and personal tools, I think that tradeoff can make sense. For production systems with sensitive data, you should absolutely think it through yourself.I’m not going to oversell it.
Kaatta is still early, and I’m still figuring out what people actually care about most.
If your API bill is starting to hurt while building side projects, feel free to try it at kaatta.com. Or just leave a comment and I’ll send over some test credits.
Great solution to a real pain point. As someone building Finsight AI, I know how important cost control is early on. Do you see this relay being useful for small businesses too, or mainly for developers?
How you identified and fixed the biggest leak (70% of usage from one workflow) is really valuable. So many devs spend time micro-optimizing everything when addressing one bottleneck would have cut costs in half. The four-step approach (model routing, context waste, caching, then measuring) feels like it'd apply to a lot of side-project technical debt.
yeah the bottleneck thing is the move nobody talks about. prompts get tweaked endlessly while one workflow quietly burns 70% of the bill.
worth stacking on top of this: apply these same steps from a lower baseline cost. same 40% cut through optimization looks very different at full pricing vs 30% off. that's the combination I was going for with Kaatta -- cheaper starting point, then optimize from there.
The interesting opportunity isn't cheaper API calls—it's helping developers control AI costs without changing how they already work. I'd keep validating whether the long-term value comes from lower pricing or from giving builders better visibility into where their token spend actually goes. That insight may end up being harder to replace than the relay itself.
This is actually something I spent a lot of time on while building Kaatta. beyond cheaper API access, what do developers actually need to manage costs? kept asking myself that, kept adding things.
turns out more of that visibility is already there than you might expect. per-request cost breakdown, model distribution charts, cache hit rate, and the usage page shows official pricing crossed out next to what you actually paid. the insight layer is there. what's missing is probably higher-level "here's what's eating your budget this week" summaries, but the raw visibility is already pretty solid.
That's exactly the distinction I was getting at.
Reading your reply gave me one thought about the gap between showing developers data and helping them confidently decide what to do with it. I don't think I could explain it properly in a thread without reducing it to a generic analytics point.
If you're interested, what's the best email to reach you on?
yeah you're describing something harder than what I'm building. the data layer is there, but "look at this and tell me what to change" is a different product entirely, probably its own thing. Kaatta is the relay, not the advisor.
still curious what you're thinking though, if you want to get into it properly, contact's on kaatta.com.