Provider-String Routing

Problem

When the call site is written as a typed provider object such as `OpenAI(...)` or `Anthropic(...)`, the provider becomes part of the application's source code and switching between them requires conditional construction at every call site. Per-request, per-tenant, or per-experiment routing across providers turns into a tangle of imports and adapter classes, and adding a new provider means another typed branch wherever models are invoked. The application ends up coupled to provider SDK shapes that have no business in its core logic.

Solution

Define a unified language-model interface and a registry of providers keyed by short prefix (`openai/`, `anthropic/`, `google/`, `xai/`, `openrouter/...`). Each provider implementation knows how to read its credentials from environment variables. The call site takes a single string (`'anthropic/claude-sonnet-4-6'`) and the runtime resolves provider, credentials, and capability flags. Pair with provider-fallback (chain strings for resilience), multi-model-routing (pick a string by quality/cost), and vendor-lock-in (this is its mirror — the un-locked version).

When to use

• The application targets multiple providers and may change the mix over time.
• Per-call routing (experiments, A/B, cost lanes) shares a single call site.
• Credentials are managed by environment, not by application code.
• A central capability registry is acceptable to track which providers support which features.