Every side project starts the same way.
-Generate an OpenAI key.
-Add it to .env
.
-Write a wrapper.
-Realize I also need Claude.
-Create another account.
-Another API key.
-Another billing dashboard.
Before the project even starts, I've already configured three different services.
At some point I thought why not just make this a proper API and host it publicly?
That's how Apiarium started.
They're great projects. But I wanted something more opinionated:
My target isn't teams running production AI infrastructure. It's developers building side projects who want one API key and a predictable bill.
Client
│
▼
Apiarium
├── /llm → OpenAI, Anthropic (more coming)
├── /image → gpt-image-1 (more coming)
├── /tts → OpenAI TTS, ElevenLabs (soon)
└── /transcribe → Whisper (more coming)
*More providers coming.
Adding a new provider doesn't change the API contract.
Same endpoints, same auth, more options.
From the client's perspective, every provider looks exactly the same:
curl -X POST https://api.apiarium.dev/llm \
-H "Authorization: Bearer YOUR_KEY" \
-H "Content-Type: application/json" \
-d '{"model":"gpt-4o-mini","messages":[{"role":"user","content":"Hello"}]}'
curl -X POST https://api.apiarium.dev/llm \
-H "Authorization: Bearer YOUR_KEY" \
-H "Content-Type: application/json" \
-d '{"model":"claude-haiku","messages":[{"role":"user","content":"Hello"}]}'
Credits instead of per-model pricing. Pricing by token across four providers is confusing. I landed on credits text generation costs 1–20 credits depending on the model, images cost 100, TTS costs 10 per 1,000 characters. One number, always visible.
Normalized error format. OpenAI and Anthropic return completely different error structures. Every error from Apiarium looks the same regardless of which provider caused it:
{
"error": "Rate limit exceeded. Try again in 30 seconds.",
"code": "rate_limit_exceeded",
"retry_after": 30
}
Provider abstraction. Every provider adapter returns the same internal response format before it's sent back to the client. That means adding a new provider is mostly implementing one adapter instead of changing the whole API.
If I started again, I'd build the provider abstraction first instead of adding providers one by one. Every new model taught me another edge case around streaming, token accounting, or error handling. Designing for those differences upfront would've saved me time.
Launched a few days ago. Still early, but the infrastructure is solid and every endpoint works.
I'm mostly interested in whether this solves a real problem for other developers. If you've hit the same setup tax or think I'm solving the wrong problem entirely, I'd genuinely like to hear it.
If even one developer stops copy-pasting another ai-utils.js
file because of this, I'll call it a success.