Multi-Provider Strategy
Part of: Effective AI Utilization — Table of Contents
Depending on a single AI provider is a single point of failure. BrianBot is wired for three providers (Anthropic, OpenAI, Google) through the Vercel AI SDK — but in practice, everything runs on Anthropic. The multi-provider infrastructure is there; the strategy to use it isn't.
Why Multiple Providers
Three reasons: resilience (if Anthropic is down, fall to OpenAI — see Model Fallback and Resilience), capability matching (some models are better at certain tasks), and cost arbitrage (pricing varies and changes frequently).
BrianBot's Provider Map
The providerMap pattern — a simple object mapping provider names to SDK factory functions — is the right abstraction. It means adding a new provider is one line of code plus an API key. The Vercel AI SDK normalizes the interface so calling code doesn't care which provider serves the request.
Key Management Across Providers
BrianBot stores API keys AES-encrypted in the database with environment variable fallback. Each provider key is stored separately in SystemSettings. This is the right pattern — never store multiple provider keys in the same config entry, and always encrypt at rest.
The Capability Matrix
Not all models are interchangeable. Claude excels at long-form generation and instruction following. GPT-4o is strong at structured output and function calling. Gemini offers large context windows at competitive pricing. Map your task types to provider strengths, and your fallback chain should reflect this: fall from your primary to the next-best provider for that specific task, not just any available model.
Avoiding Lock-In
The Vercel AI SDK is the primary lock-in defense in BrianBot. Keep provider-specific features (Anthropic's prompt caching, OpenAI's structured outputs) behind feature flags or adapter patterns so you can use them when available without depending on them.
Related: Model Routing Strategies, Model Fallback and Resilience, Cost Tracking and Budget Controls