Show IH: I built a single API key layer for testing multiple AI models
Hey Indie Hackers,
I’m working on Crun — a lightweight AI model hub for builders who want to test multiple AI models without setting up a dozen different API keys.
The problem I kept running into:
When building AI features, one model is rarely enough.
OpenAI might be great for one workflow, Claude for another, Gemini for another, and once you add image, video, or audio models, the setup becomes messy pretty quickly.
You end up dealing with:
- multiple API keys
- different billing dashboards
- different model names
- different error formats
- unclear usage/cost tracking
- lots of integration work before you even know if the AI feature is worth building
So we started building Crun as a simpler layer for the prototyping stage.
What it does right now:
- one API key to access multiple AI model services
- credits-based usage
- built-in AI tools for quick testing
- easier model switching when validating prompts or workflows
- a more unified way to test text, image, video, and audio models
I don’t see this as a replacement for official APIs in every production use case.
The main use case is earlier:
Before you commit to one provider, before you build your own model gateway, before you spend days wiring up multiple APIs — quickly test what works.
Who I think it’s for:
- indie hackers building AI products
- solo founders validating AI SaaS ideas
- developers comparing model output before choosing a provider
- small teams that want a shared place to test AI tools and models
Here’s the product:
I’d love feedback from the IH community:
1. Would you use a gateway layer like this during the MVP stage?
2. What would make you trust this enough for production use?
3. Do credits-based usage make sense for this kind of product, or would you prefer simple pay-as-you-go?
4. What models or AI tools would you expect to be supported first?
Happy to answer questions and share more about how we’re thinking about model routing, credits, and usage tracking.
The prototype vs production split is exactly the right framing.
For MVP testing, one key + credits + fast model switching is enough to remove friction. For production trust, the missing layer is usually the usage ledger: which API key or project made the call, which upstream model actually ran, whether a fallback route fired, how many retries happened, what latency looked like, and which balance bucket paid for it.
That is the problem we are working on with Tokens Forge from the gateway/accounting side. Cheaper multi-model access is useful, but teams start trusting it when the route and the bill are explainable in the same place.
On pricing, credits can work if they map back to model cost clearly. If credits feel like a black box, builders will test with them but hesitate to route real user traffic through them.
This is useful, but I’d be careful not to position Crun as a general “AI model hub” too early.
That sounds broad and puts you near a lot of infrastructure/gateway tools.
The sharper entry point is probably the messy MVP stage:
“Test multiple AI models with one key before you commit to a provider.”
That makes the product feel less like another model platform and more like a speed layer for indie hackers and small AI teams.
For trust, I would not try to win production use first. I’d win prototype trust first:
clear usage tracking, predictable credits, transparent model/provider list, simple fallback behavior, and no confusing billing surprises.
Then production trust becomes a later expansion, not the first promise.
The pricing question is interesting too. Credits may work for testing, but builders will probably want a clear translation between credits and real model cost, otherwise it can feel abstract.
Happy to put a tighter version in writing if useful. The main thing I’d map is the positioning, trust path, pricing model, and first builder segment to target.