What changed in Apiarium after developers started using it

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