Mozilla、新モデル追従から統一アクセスへ移行を提案するプラットフォーム戦略を発表

imageA new LLM is released. It is faster, cheaper, better at reasoning, or simply a stronger fit for one of your workloads.

The product team wants to test it. From the outside, that sounds like changing a model name and running a few evaluations.

From a platform or infrastructure perspective, it is rarely that simple.

A new model may arrive through a provider your application does not support. That means another SDK, authentication method, request format, error model, set of environment variables, and collection of provider-specific behaviours.

The real challenge is not accessing more models. It is preventing every new model from becoming another infrastructure project.

The Model Is Only Part of the Integration

When an application connects directly to an LLM provider, it depends on much more than the model itself.

It also depends on the provider’s SDK, credentials, request and response schemas, streaming implementation, tool-calling conventions, rate limits, retries, model identifiers, and usage data.

Provider-specific logic begins to spread across application code, secrets management, observability, testing, deployment pipelines, and incident response.

This may be manageable with two providers. It becomes harder when new vendors appear, models are deprecated, APIs evolve, and teams want different models for different workloads.

Eventually, the team is no longer maintaining an AI application. It is maintaining an internal provider compatibility layer.

We Have Seen This Problem Before

Software teams have dealt with a similar problem before.

Before reproducible package management and containerised environments became standard, applications frequently broke because libraries, runtimes, and operating systems expected incompatible versions. Updating one dependency could break an unrelated component. Deploying the same software in two environments could produce different results.

We called it dependency hell.

The issue was not that dependencies were inherently bad. Application code was too tightly coupled to systems that evolved independently.

Engineering practices improved by introducing stable boundaries: package managers, lock files, containers, and consistent interfaces.

LLM providers now resemble separate dependency ecosystems. Each evolves its own SDKs, APIs, credentials, models, tools, and billing mechanisms. Connecting applications directly to each provider recreates the coupling we spent years removing elsewhere.

Decouple the Application Lifecycle from the Model Lifecycle

A new model should be a configuration change, not an application rewrite.

Applications and models operate on different release cycles. Application changes may require code review, security checks, integration testing, staged deployments, and production approval. New models appear continuously and may need to be evaluated or rerouted much faster.

Otari provides a stable OpenAI/Anthropic-compatible endpoint between applications and providers. The application sends one request using one API key, while provider selection, upstream credentials, routing policies, and fallback behaviour remain behind the gateway. Otari currently supports more than 40 providers.

The application integration can remain stable:

imageThat separation lets the application own product behaviour while the platform owns model access and operational policy.

Instead of asking, “What code must change to support this provider?”, the team can ask, “Which model should serve this workload?”

Teams must still assess quality, latency, privacy, reliability, and price. Otari does not replace engineering judgement. It removes the repeated integration work surrounding each decision.

A Smaller Model Should Not Mean a Smaller Platform

Model capability and platform capability are not the same thing.

Lighter or open-weight models may be a better fit for a workload based on cost, latency, privacy, or deployment requirements. However, they often lack the managed capabilities bundled with some frontier model APIs.

Otari helps close that gap by providing model-agnostic tools such as web search and sandboxed code execution through the same gateway.

Once tools are decoupled from the provider, smaller models become much more interesting.

Fragmentation Goes Beyond Integration

Direct provider integrations do not only fragment code. They also spread credentials across systems and divide financial visibility across several accounts and billing dashboards.

Centralise Credentials and Reduce Exposure

Otari stores upstream provider credentials centrally, while applications use workspace-scoped API keys to call the gateway. The application never needs direct access to the provider secret.

This creates a cleaner security boundary. Provider credentials can be managed and rotated centrally, application access can be scoped separately, and the blast radius of a leaked application key is easier to contain.

Unify Usage and Control Spend

Multiple provider accounts make cost attribution difficult. A consolidated invoice total does not explain which application, team, user, model, or environment generated the spend.

Otari records requests and costs across providers in one place and supports budgets, usage visibility, and spending controls. Its hosted platform also organizes access and spend through organizations and workspaces.

This moves cost management closer to the request itself. Rather than discovering unexpected usage after several invoices arrive, teams can define limits and trace spend through the same control layer that authorizes model access.

Build the Product, Not Another Provider Abstraction

Model choice will keep changing. Teams will adopt new models, retire older ones, and route different workloads to different providers.

Trying to predict one permanent provider is not a realistic platform strategy. Neither is rebuilding provider-specific logic inside every application.

The sustainable approach is to give applications a stable contract and allow the model layer to evolve behind it.

Models still need testing. Costs still need measuring. Reliability and security still need designing. But those decisions should happen in a dedicated control plane, not through repeated rewrites across application codebases.

Stop chasing provider integrations. Build the product against one stable interface and let the model ecosystem change behind it.

Explore Otari

Explore Otari’s multi-provider routing guide to see how one integration can route requests across providers, centralize credentials, add fallback behavior, and bring usage and spend into one operational view.