How to Support Multiple AI Providers in TypeScript

When adding AI features to your application, it is tempting to install a single provider SDK (like OpenAI or Anthropic) and call it directly inside your route handlers or business logic.

However, as your application grows, you will likely want to switch models to lower costs, compare outputs, or add fallbacks during outages. If your app is coupled directly to a specific SDK, switching providers requires refactoring code across multiple files.

In this guide, you will learn how to design a simple Adapter Pattern in TypeScript so you can swap AI providers with a single configuration change.

1. The Problem: Direct SDK Coupling

When you hardcode provider SDKs across your codebase, you run into three main problems:

• Vendor Lock-in: Migrating to another model requires rewriting request parameters and response parsers everywhere.
• Inconsistent APIs: Different providers use different parameter names (for example, max_tokens vs max_completion_tokens, or passing a system prompt as a config property vs a message role).
• Hard to Test: Mocking third-party SDKs in unit tests is cumbersome when provider-specific methods are scattered across your app.

2. The Solution: The Adapter Pattern

The Adapter Pattern introduces a standard contract between your application and external AI APIs.

The architecture consists of three parts:

[ Your Application Logic ]
            │
            ▼
   [ LLMManager (Factory) ]
            │
    ┌───────┴───────┐
    ▼               ▼
[ Provider A ]   [ Provider B ]
 (Adapter)        (Adapter)

1. A Shared Interface (LLMProvider): Defines the standard input parameters and output format your application expects.
2. Provider Adapters: Classes that implement the shared interface, translating your standard format into provider-specific API calls.
3. A Central Manager (LLMManager): A factory that instantiates and selects the active provider based on runtime configuration.

3. Step-by-Step Code Walkthrough

Step 1: Define a Unified Interface

Start by standardizing the messages, input options, and response format in a shared types file:

// types.ts
 
export interface Message {
  role: 'system' | 'user' | 'assistant';
  content: string;
}
 
export interface CompletionOptions {
  messages: Message[];
  temperature?: number;
  maxTokens?:

Step 2: Implement Provider Adapters

Next, create adapter classes that implement LLMProvider. Each adapter encapsulates its provider's API calls and response translation.

Provider A (OpenAI-compatible)

// providers/openAIProvider.ts
import { LLMProvider, CompletionOptions, CompletionResponse } from '../types';
 
export class OpenAIProvider implements LLMProvider {
  readonly name = 'OpenAI';
  private apiKey: string

Provider B (Anthropic-compatible)

// providers/anthropicProvider.ts
import { LLMProvider, CompletionOptions, CompletionResponse } from '../types';
 
export class AnthropicProvider implements LLMProvider {
  readonly name =

Step 3: Create the Central Manager

The LLMManager acts as the single entry point for your application. It holds instances of your configured providers and selects which one to run.

// llmManager.ts
import { LLMProvider, CompletionOptions, CompletionResponse } from './types';
import { OpenAIProvider } from './providers/openAIProvider';
import { AnthropicProvider } from './providers/anthropicProvider';
 
export type SupportedProvider

Usage Example

// index.ts
import { LLMManager } from './llmManager';
 
const llm = new LLMManager({
  defaultProvider: 'openai',
  openAIApiKey: process.env.OPENAI_API_KEY,
  anthropicApiKey: process.env.ANTHROPIC_API_KEY,
});
 
async function main() {
  const response = await

4. Handling Provider Differences

While the interface standardizes common parameters, real-world providers have nuances that each adapter should normalize:

1. Message Roles & System Prompts

• OpenAI allows 'system' messages directly inside the messages array.
• Anthropic expects system prompts in a top-level system field rather than in the messages array.
• Solution: Keep your application format uniform ({ role: 'system', content: '...' }) and let the adapter extract or remap it before sending the payload.

2. Standardized Error Handling

Each provider returns different error structures (e.g., HTTP 429 rate limits, invalid auth, context length limits).

Create a unified error class:

export class LLMError extends Error {
  constructor(
    message: string,
    public readonly provider: string,
    public readonly statusCode?: number,
    public readonly isRateLimit: boolean = false
  ) {
    super(message);
    this.name 

When an adapter catches a provider-specific error, wrap it in LLMError. This allows your application code or fallback mechanisms to handle errors and retries consistently without knowing which SDK threw it.

5. Summary & Key Takeaways

• Modular: Adding a new provider (e.g., Google Gemini, Mistral, or a local Ollama instance) only requires creating one adapter class without touching existing application logic.
• Testable: You can mock LLMProvider in unit tests cleanly without dealing with third-party SDK mocks or live network requests.
• Future-Proof: Protects your app from vendor lock-in and breaking upstream API changes, allowing seamless provider switching and fallbacks.