A few weeks ago I wrote about why I built Apiarium after OpenRouter solved one problem for me and I still had four more.
The comments on that post ended up shaping a good chunk of what I actually built next, so this is the "here's what changed" follow-up.
The interesting part isn't really the features. It's where they came from.
Almost everything below started with someone telling me something was annoying, confusing, or missing. So instead of adding things because they looked good on a roadmap, I tried to fix the problems people were actually running into.
Multiple API keys, not one shared key for everything
The biggest ask came directly from someone using Apiarium in production. They wanted to know which app or feature was actually driving usage, without having to share one API key across everything and lose that signal.
So now you can create multiple keys per account:
- 2 on Free
- 5 on Starter
- 10 on Pro
You can name them, revoke them individually, and every request is tagged with the key that made it. Credits are still shared across the account, the keys are about visibility, not splitting your balance.
// key for your production app
fetch('https://api.apiarium.dev/llm', {
headers: { Authorization: 'Bearer sk-prod-...' },
...
})
// separate key for a side project
// same account, same credits
fetch('https://api.apiarium.dev/llm', {
headers: { Authorization: 'Bearer sk-sideproject-...' },
...
})
You can also see when each key was last used and filter usage by key in the dashboard. That last part was really the reason I built it.
A dashboard that answers "where did my credits go?"
The old dashboard was basically a number going down. That wasn't particularly useful.
The new dashboard is split into Overview, Usage, API Keys, and Billing. There's a proper date range filter with 7d/30d presets or a custom range, and that same range drives the usage chart, breakdowns, and request logs together.
You can break usage down by model and endpoint, so you can actually see what's consuming your credits. And you can export the entire selected range to CSV instead of being limited to the last few hundred requests.
None of this is particularly exciting. But "I have no idea what's using my credits" was a real problem. Now there's an answer.
Pricing that reflects what things actually cost
This one's less fun to admit.
Some of the original per-model pricing wasn't calibrated properly. Cheaper models and frontier models were sometimes costing users roughly the same number of credits, even though they obviously don't cost us the same to run.
So I changed the pricing model. Credit consumption now scales with the underlying cost of the model instead of using a flat number that was convenient when I launched. TTS pricing got the same treatment.
If you noticed some weird numbers before, that's why. It's better now.
No fixed monthly minimum
You can start with pay-as-you-go from €5, with no subscription required. If you outgrow that, Starter and Pro are there, but you don't need to commit to a monthly plan just to try Apiarium.
What's next?
This is probably the most useful part for me.
If you're using Apiarium, what's the one thing that still annoys you? I'd rather hear it now and build it than spend two weeks building something nobody asked for.
If you're curious, you can poke around here: apiarium.dev
Top comments (3)
Hello Lolo, I am Kane Lim from Hong Kong. I have over 10 years of development experience. I am writing this because your post was interesting.
I really like the direction you took with Apiarium because you are solving observability and cost attribution rather than simply adding another LLM gateway feature. Multiple API keys per account is especially useful when combined with request level telemetry, because it creates a clean attribution boundary between production workloads, experiments, and internal services without fragmenting the credit pool.
I would take this one step further with a unified usage metering pipeline. Every request could emit an immutable usage event containing key identity, model, endpoint, token counts, latency, cache status, provider cost, and response status. From there, you can build real time aggregation through a streaming layer and expose cost per application, model, endpoint, and time window.
For pricing, I would also consider a provider cost normalization layer rather than hardcoding model prices into application logic. That would make provider changes, routing optimization, margin analysis, and automatic model substitution much easier. Eventually, anomaly detection could identify sudden token spikes or unexpected model usage before credits disappear.
The feedback driven roadmap is probably your strongest advantage. Keep the feedback loop close to actual production telemetry.
I would like to get to know you better and discuss about your post. Would you please contact me? t_g_@kanelim1997
Thanks Kane, appreciate the detailed breakdown. The immutable usage event idea is close to what the dashboard is already doing under the hood (each request already logs key, model, endpoint, credits, status), a proper streaming layer on top is a fair next step once volume justifies it.
The cost normalization layer is a good callout too, right now pricing is per-model but not abstracted from the routing logic yet, that's on my list.
Happy to keep discussing here in the comments, that's usually where the best ideas end up getting refined for me anyway.
The reason I want to chat on Telegram is that I need your help. However, I feel uncomfortable discussing this in this community. I would be very grateful if you could contact me.