For a media support chatbot, a unified LLM API must handle multi-provider fallback while keeping each tenant's cost explainable. That constraint changes the architecture.

TL;DR: put provider selection behind one OpenAI-compatible endpoint, let the gateway fail over when the selected provider is down or rate-limited, and keep the returned vendor, cost, latency, and request ID beside the tenant ID in your own usage record. The frontend should know about a conversation, not about three credential systems.

For a one-person SaaS, this is a revenue-per-hour decision. A working fallback is valuable. A new adapter to maintain every time a model changes is not. Ship the first useful path this week, then outsource the undifferentiated credential and invoice plumbing to a service that exposes it clearly.

What should fail over, and what should stay stable?

The stable boundary is the chat request. A ticket arrives with its tenant ID, conversation history, and routing policy.…