AllModels has opened a beta router for abliterated DeepSeek V4.1 Flash and GLM 5.3 deployments. Developers get a single API connection that can select among compatible inference providers, fall back when capacity is unavailable and handle web search independently of the provider generating the answer.
The practical change is in the access layer. An application can keep its integration and public model ID while AllModels manages the provider routes behind them. Its product page advertises OpenAI-compatible Chat Completions and Responses APIs, modality-aware routing and the ability to select a low-cost eligible provider.
That could simplify deployments that would otherwise need several provider integrations. But the useful question is what makes a route eligible: an inexpensive text-only provider cannot necessarily handle an image request, and a shared model name does not guarantee identical deployment limits.
The product page is undated, so it does not establish an exact launch time. Its available version also shows placeholders for median latency and tokens per second, with live provider listings still loading. There is no independently verified provider count, performance comparison or safety evaluation in the supplied evidence.
One API Connection, Two OpenAI-Compatible Interfaces
AllModels describes the service as “One endpoint for every abliterated model.” In implementation terms, that means one API base URL with two documented request paths:
- Chat Completions:
POST /oai/chat/completions, supporting messages, streaming, function tools and the familiar OpenAI chat schema. - Responses:
POST /oai/responses, supporting input items, streaming events, reasoning controls, structured output, custom tools and hosted web search.
Both sit under the base URL https://api.allmodels.io/oai. Applications using the OpenAI SDK can configure that address and supply an AllModels API key. The SDK is acting as the client library; requests go to AllModels, not OpenAI. These interfaces and the configuration example are documented on the AllModels page.
For Python, the documented pattern looks like this:
import os
from openai import OpenAI
client = OpenAI(
api_key=os.environ["ALLMODELS_API_KEY"],
base_url="https://api.allmodels.io/oai",
)
response = client.responses.create(
model="deepseek/deepseek-v4.1-flash-abliterated",
input="Explain the difference between latency and throughput.",
)
print(response.output_text)
This example assumes the OpenAI Python package is available and ALLMODELS_API_KEY contains a key issued by AllModels. It creates a client, sends a Responses request to the router’s published DeepSeek model ID and prints the returned text. It is an integration example, not a reported test.
The model ID matters. AllModels lists abliterated deployments in the DeepSeek V4.1 Flash 1017 and GLM 5.3 families, but an application must use the identifiers accepted by the router. A name accepted by DeepSeek’s own API is not automatically interchangeable with an AllModels identifier.
OpenAI compatibility should make an existing SDK integration easier to adapt. I would still treat that as a starting point for migration, especially for applications using structured output, streaming or tool calls. Matching the request format is one part of compatibility; the selected deployment must also handle the features the application depends on.
Failover Depends on What Each Provider Can Handle
AllModels says it routes requests across compatible providers and automatically tries another eligible route when a provider is unavailable or capacity-constrained. For GLM 5.3, it describes multiple deployments sharing one public model ID, with a default provider sequence or an explicit provider choice when a particular price or limit matters.
The published routing claims break down into four distinct functions:
| Function | AllModels’ documented claim | Practical consequence |
|---|---|---|
| Provider fallback | Try another eligible provider when one is unavailable or capacity-constrained | Applications can avoid implementing some provider-switching logic themselves |
| Modality routing | Send image and multimodal requests only to providers that support them | An image request may have fewer fallback options than a text request |
| Price-aware routing | Keep provider pricing current and support choosing the lowest-cost eligible option | Price selection happens within the set of providers capable of serving the request |
| Explicit provider selection | Allow a provider choice when price or limits matter | Developers can favor a known deployment over automatic selection |
These are vendor descriptions of the beta, not measured availability results.
The modality rule is particularly consequential. AllModels says text requests can use every eligible text route, while image requests go only to providers that can read them. That means the fallback pool is determined partly by the request itself.
Consider an application that usually sends plain text but occasionally attaches a screenshot. The text request might qualify for several providers. Adding the screenshot can narrow the eligible set. If one vision-capable provider becomes unavailable, the router needs another compatible vision route to preserve the request’s functionality.
That is why I would evaluate text and image workloads separately. A successful text-only integration would say little about the number of usable image routes or their limits.
Native Model Vision Does Not Guarantee Every Route Supports It
DeepSeek’s September 10, 2026 announcement introduced V4.1 Flash with native visual understanding and said native multimodal support was available through DeepSeek’s own API.
AllModels’ routing description adds a deployment-level distinction: the underlying model family may support vision, while only some provider routes expose that capability.
Those statements concern different layers. DeepSeek describes the model and its own service. AllModels describes which third-party routes can accept a particular request. A developer choosing a model family still needs to check the capabilities of the deployment serving it.
The same reasoning makes automatic failover useful without treating it as an uptime guarantee. Multiple eligible routes create additional recovery options, but the published page does not specify retry timing, the errors that trigger fallback or behavior after a streamed response has already begun. Those details matter for timeout budgets and user-visible recovery.
Hosted Web Search Moves a Tool Into the Router
AllModels says web search is processed at its routing layer instead of being delegated to whichever inference provider serves the request. It advertises OpenAI-compatible search calls and URL citations even when the selected model provider does not offer search.
The documented request options are:
- For Responses, include
tools: [{ type: "web_search" }]. - For Chat Completions, use
web_search_options: { search_context_size: "medium" }.
These are two interface-specific ways to request the router-hosted search function. They are not interchangeable fields.
This design can reduce a particular kind of integration friction. If search depends entirely on the inference provider, switching providers can mean losing that tool or adapting to another search interface. Hosting it at the router gives AllModels a way to keep the search entry point consistent while changing the provider responsible for generating the answer.
That consistency could be valuable for research assistants or document workflows that need both generated text and links to current web material. It also gives developers another service boundary to examine: inference routing and search processing are separate functions, even when exposed through one API.
URL citations should be treated as material to inspect. A returned link does not, on its own, verify that the linked page supports the generated claim. For an application publishing factual answers, I would check whether citations resolve, whether the relevant passage supports the answer and whether the application preserves the citation information when rendering the response.
Price-Aware Routing Is Constrained by Eligibility
AllModels says it keeps provider pricing current and can route to the lowest-cost eligible option as providers become available. The important word is eligible.
A route has to satisfy the request’s requirements before its price is useful. For a text-only workload, that might leave a broader selection. For an image request or a workload tied to a particular provider limit, the usable set can be smaller.
The practical implication follows directly from combining AllModels’ modality and price claims: the cheapest advertised route for a model is not necessarily the cheapest route available to a specific request. A lower-priced provider outside that request’s capability set cannot solve the pricing problem.
Frequently Asked Questions
4 questions
1Does AllModels Send These Requests to OpenAI?
The documented setup uses the OpenAI SDK with AllModels’ base URL and an AllModels API key. The SDK provides the client interface; the requests go to AllModels.
