1
1 Comment

One app, 3 AI providers, 3 SDKs, 3 sets of keys — how are you keeping this sane?

One app, 3 AI providers, 3 SDKs, 3 sets of keys — how are you keeping this sane?

Hey IH — a build-in-public confession about the part of our stack that quietly turned into a mess.

When we started, using one model was simple. Then reality happened:

  • one workflow ran best on Claude
  • another on GPT
  • a few experiments on Gemini
  • and some cheap/fast tasks on smaller models

None of that was a "decision." It just accumulated.

Six months in, here's what our codebase actually looked like:

  • 3 different SDKs, each with its own request/response shape
  • 3 sets of API keys in 3 dashboards
  • per-provider retry and error handling, written 3 slightly different ways
  • and every time we wanted to try a new model, another integration

The annoying part wasn't any single provider. Each one is fine on its own. The annoying part was that adding the 4th model meant touching code in four places, and nobody on the team could answer "what would it take to swap this workflow to a different model?" without opening the editor.

At some point we stopped adding models we wanted to try, just because the integration tax wasn't worth it. That's the part that actually bothered me — the friction was quietly shaping our product decisions.

So I'm genuinely curious how others are handling this, because I don't think we're special here:

  • Do you wrap everything behind your own internal abstraction layer?
  • Use an aggregator / gateway?
  • Or just standardize on one provider and accept the lock-in to keep things simple?

What does your multi-provider setup actually look like right now — and at what point did it start to hurt?

(For context on where I'm coming from: we ended up routing everything through one OpenAI-compatible API so the rest of the app only talks to a single endpoint — that's what we're building at EvoLink. But I'm more interested in how you're solving it, especially if you went the build-it-yourself route.)

on June 10, 2026
  1. 1

    We hit the same pain once GPT/Claude/Gemini started being used for different jobs. The biggest win for us was not just a provider wrapper, but making the route decision, request log, spend bucket, and fallback reason visible in one place. Otherwise the abstraction hides too much and debugging gets worse.

    For Tokens Forge we kept the app side OpenAI-compatible, then moved provider keys, model mapping, usage accounting, and backup routing into the gateway/admin layer. That made it easier to change a workflow from one model to another without touching the product code.

    Curious how you are thinking about observability: do you want your users/team to see only the final model, or the full provider route/fallback trace?