Model Provider Abstraction

A classic production problem: you build directly against one provider’s SDK (say OpenAI’s), and one day you need to switch models — every call site is now vendor-shaped. The cost is not the model, it’s the integration surface: message formats, streaming, tool-call shapes, and error handling all differ per vendor.

The Pattern

Define a narrow interface — e.g. a LanguageModel type (the AI SDK, by vercel, is the reference implementation) that any ask(prompt, model) function accepts — and route all generation through it:

• Swapping models becomes a one-line change; the same prompt path runs against Anthropic, OpenAI, or a local model.
• createOpenAICompatible-style adapters extend this to any OpenAI-compatible endpoint, including locally-hosted models.
• Generation, streaming, embeddings, and image/file input all sit behind the same abstraction.

This is dependency inversion principle applied to LLM infrastructure: the application depends on an abstraction it owns, not on a vendor SDK. It also de-risks context rot economics — provider-agnostic apps can chase the cheapest adequate model without a rewrite.

Caveat

Abstractions leak: provider-specific features (caching behavior, reasoning-token billing, tool-call quirks) do not always map cleanly. The interface should expose the common denominator and allow escape hatches.

Related

llm message protocol, structured outputs, dependency inversion principle, clean architecture, agent native infrastructure.