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.
The 40% drop from routing simpler tasks to Haiku is the number that would make me look twice, more than the 30% off through the relay. That matches what I see running several agents on the same project: most of the spend is one workflow resending context it does not need, and caching plus clearing between tasks usually buys more than any discount would. My hesitation is not the money: it is routing a client project through a third party I do not control, and not knowing what gets logged on your end. For a personal side project that tradeoff is easy. For anything touching client code I would want that answered first.
The 'measure before optimizing' section is the real post: one workflow eating 70% of tokens matches what we see at SocialPost.ai, where a single retry loop once outspent every model choice we made. On the relay itself, the question I would want answered as a buyer is how the 30% discount holds up: if it comes from pooled volume discounts it is a real business, if it comes from subsidized pricing it disappears exactly when I depend on it. Worth publishing that answer, because routing production traffic through a middleman is a trust decision, not a price decision.
Two biggest levers. One thing I learned building a workflow tool is that a lot of token spend isn't from choosing the wrong model — it's from rebuilding the same context every time you switch tools or resume a task.
If your project state lives in a single file that every AI tool reads and writes, you stop paying to re-send goals, constraints, and history on every handoff. It's a different axis from cheaper API access, but the savings add up for long-running projects.
Hey i like that you shared the optimizations that worked before introducing your own product and the understanding where tokens are actually being spent is probably the most valuable things takeaway here.
That’s a great breakdown — I hadn’t considered how setup friction differs between technical and non‑technical users. The middle group you mentioned is interesting; I’ve seen similar behavior with SMBs using AI tools. They assume APIs are pricier when they’re actually more efficient. Thanks for clarifying that!
— Francisca, building Finsight AI
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?
depends how they're set up technically. if a small business is already calling the API directly (or has a dev on the team doing it), the setup is the same -- base URL swap, done. the friction is mainly for non-technical users who only use claude through subscriptions like Claude.ai, those don't route through the API at all.
that said, there's a middle group worth calling out -- devs who ARE technical but stuck on subscriptions because they assume API costs more. they hit quota in hours, end up juggling multiple accounts just to keep working. for that group the API is actually the better deal, especially at 30% off.
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.
Thanks! I’ve just sent it over.
Looking forward to hearing your thoughts whenever you have a chance.