Skip to main content

One API for every model provider

The model you choose today is unlikely to be the model you want in a year, and the code you write against one provider's SDK does not move to another's. This page explains why a single, stable API across providers matters, how DIAL delivers it, and what you give up and gain. It is for architects and evaluators weighing provider strategy, and for developers who will write against the result.

Why this matters​

Every model provider has its own SDK, authentication, request shape, and quirks. Write directly against one, and you have coupled your application to that provider: switching means rewriting integration code, retesting, and redeploying every app that touched it. Multiply that across a dozen applications and the cost of changing your mind becomes the reason you never do.

The field moves too fast for that to be acceptable. A better model ships, a provider changes pricing, a region requirement forces a different vendor — and an organization that coded against a single provider's SDK cannot react without a migration project. The value of one API across providers is the freedom to change models without changing applications.

What you can do with DIAL​

DIAL Core gives every application one stable entry point to every model, in the API the application already speaks: the Unified API, DIAL's extension of OpenAI Chat Completions, or the OpenAI Responses or Anthropic Messages API. Your application calls a deployment by name; Core reaches the provider through an adapter, which converts the request to the provider's native format or passes a compatible request through.

Your apps ──▶ DIAL Core ──▶ adapter ──▶ provider
                            adapter ──▶ provider
                            adapter ──▶ provider

Because the deployment name is stable, swapping a model is a configuration change, not a code change. A router picks the model per request — by cost, by availability, or by rule — so applications keep calling one name, whichever model serves a given request. New providers join the catalog by adding an adapter, and applications written months earlier reach them unchanged.

How you'd build it​

  • Understand the APIs. AI API overview explains the APIs DIAL Core serves and how each request reaches a provider.
  • Know your options. Supported providers lists the models reachable today.
  • Connect a provider. Adapters covers how a provider is attached, and build a custom adapter handles anything not in the catalog.
  • Route between models. Aliases and routers put a stable name or a per-request model choice in front of your deployments.

Why DIAL over the alternatives​

A thin client library that abstracts a few providers solves part of this, but it lives in your application and still leaves each app to manage keys, limits, and observability. DIAL puts the abstraction in a gateway, so provider independence comes with central access control, cost limits, and audit for free — at the cost of running that gateway. See Trade-offs and limitations for the gateway's operating cost and API compatibility boundaries.

Provider independence is never total: a feature unique to one provider is still unique, and DIAL's APIs expose common ground plus documented extensions. The win is that the common case — send a prompt, get a completion — is identical everywhere.

Further reading​