OpenAI usage page, check spend. Anthropic console, check spend. Add it up in my head. Close both tabs, annoyed before writing a single line of code.
Every new project meant repeating it: new account, new key, new billing page, new error format. By the third project, I had four tabs pinned just for billing.
The breaking point was small. An email saying I'd hit 80% of a budget I didn't remember setting. Not because I'd overspent, but because I'd lost track of my own guardrails across two dashboards I only half-watched.
The problem was never the money. It was running two mental models for what should've been one workflow.
So I replaced both dashboards with one number: credits. One key, one balance, that drops no matter which provider handles the request. Didn't set out to build a product, just wanted to stop doing math every morning. Apiarium came after, once I noticed other people doing the same two-tab dance.
Top comments (14)
Honestly the money was never the problem, you nailed that. Holding two billing systems in your head, with two error formats and two budget thresholds you only half-remember, that's the actual tax, and it's the kind nobody measures. Collapsing it to one number you glance at is really about getting your attention back, not saving dollars. The 80 percent email being your breaking point rings true too, those small surprises are what finally tip you into building something.
Exactly, 'getting your attention back' is the better way to put it. The cost was never really the issue, it was the overhead of running two systems that should've been one. The 80% email was just the moment it became undeniable.
The two-dashboard math wasn't the real tax โ the per-provider error formats were. When OpenAI returns a 429 with a
type/codein one shape and Anthropic hands you a different envelope withoverloaded_error, your retry and fallback logic has to branch on provider, not on failure class. Unifying billing behind one credit balance doesn't fix that; if anything it hides it, because now a request can silently fall over to the other provider and you lose the signal about which backend is degraded.That's the thing I'd watch with a single-key abstraction: the moment it starts routing for you, you need it to surface the underlying provider, status, and normalized error class per request โ otherwise you've traded two dashboards you half-watched for one number that tells you even less when something's actually broken.
You're right, and this is exactly the gap in what I described. Apiarium doesn't currently do automatic cross-provider fallback, if a request to Claude fails, it fails with that provider's error surfaced, not silently retried against GPT. But your point stands regardless: even without fallback, I'm not yet normalizing error classes across providers in the response, only the credit accounting.
That's a real fix I need to make: return a consistent error_class (rate_limited / overloaded / invalid_request / etc.) alongside the raw provider error, so people building on top of this don't have to re-derive that mapping themselves. If I ever add fallback routing, the provider + status per request becomes non-negotiable, for exactly the reason you're describing, otherwise the abstraction actively makes debugging worse, not better.
Appreciate you pushing on this, it's the difference between "unified billing" and "unified failure handling," and I've only actually solved the first one.
Hello Lolo, How you become full stack developer, I mean where from you start learning about coding. And which programming language you learn first.
Haha, it feels like a lifetime ago. ๐ I actually started learning programming right after high school, and C# was the first language I learned. Now my favourite is python.
Pretty much everything I know came from studying first and then from working as a developer. Back then AI wasn't a thing like it is now. We couldn't just ask ChatGPT when we got stuck. ๐
Some of my exams were even on paper... yep, literally writing code with a pen. If you forgot a semicolon, you couldn't even blame your IDE. Those were tough times, but I guess it forced us to really understand what we were writing.
That makes sense, thanks for walking through it. Good to know the two approaches aren't mutually exclusive, if anything they're answering different questions about the same bill. Following what you're building.
This is exactly why I built Weckr. The dashboard fatigue is real. What made me stop checking was realizing the total number meant nothing without knowing which specific users were causing it.
Makes sense, and it's actually a nice complement to what I described here.
I solved the "which number do I even look at" problem with credits, but
you're right that the aggregate number doesn't tell you who is driving it.
Different failure mode of the same fatigue: I stopped worrying about the
total, but I still couldn't tell you today which user is costing me the
most relative to what they pay.
Curious how Weckr handles pricing models that aren't per-token passthrough, if someone's on a flat/credit-based plan like mine, does the per-user
margin math still work the same way?
Yes it works the same way. You just tell Weckr what each plan is worth in dollars when you initialize the SDK.
So if your credit plan costs $29/month you pass that in and Weckr calculates margin as $29 minus whatever that user actually cost in tokens that month. The revenue side is whatever you define, not what the user consumed.
The interesting case you're describing is actually where Weckr is most useful. With a credit system you know the aggregate is fine but you have no idea if user A burned 80% of their credits generating $0.50 in real cost or $15. Weckr shows you that breakdown per user so you can see who is getting a great deal at your expense even within a credit model.
Great work โค๏ธ๐๐ป
Thank u!
Simple but clever :-)
Yes, that's exactly what I wanted to convey :) Thank you so much