Abliterated DeepSeek and GLM 5.3 Behind One Endpoint: Mapping the AllModels Routing Layer | AIdataNewsGlobal General
Developers tracking the fast-moving market for unrestricted model weights have a new aggregation point to watch. Rather than advertising a proprietary model, AllModels advertises plumbing: one connection, one base URL and one OpenAI-compatible schema as the entry to its abliterated route pool. The claim rests on routing behaviour — live provider routes, automated failover, router-hosted search and a status strip built around p50 latency and throughput readings for the sample model DeepSeek V4.1 Flash Abliterated.
What the published status panel actually shows
The displayed data is deliberately sparse, and it should be read as a template for future metrics rather than as a completed benchmark:
- Metric reported: p50, the median percentile of the measurement window.
- Latency display value: — ms, a placeholder with no live number published.
- Throughput display value: — tok/s, likewise a placeholder.
- Sample model named on the strip: DeepSeek V4.1 Flash Abliterated.
- Provider route state shown for DeepSeek and for GLM 5.3: loading.
In short, the page defines the shape of the figures it intends to publish; no independent performance comparison between providers can be drawn from what is visible today.
Integration pattern: two snippets, one prompt
Both published examples are written against the OpenAI SDK, which is the compatibility promise at the centre of the offering. Only the credential, the base URL and the model ID differ from a standard integration.
- JavaScript: an OpenAI client is constructed with process.env.ALLMODELS_API_KEY and baseURL "https://api.allmodels.io/oai"; client.responses.create is then called with model "deepseek/deepseek-v4.1-flash-abliterated" and input "Open the pod bay doors.", after which response.output_text is logged.
- Python: the same sequence, reading os.environ[ALLMODELS_API_KEY], setting base_url to "https://api.allmodels.io/oai", requesting "deepseek/deepseek-v4.1-flash-abliterated" with input "Open the pod bay doors.", and printing response.output_text.
The demo prompt is itself part of the messaging: it is the line a compliant assistant refuses, used here as shorthand for what an abliterated deployment is expected to answer.
Route coverage described in the catalogue
| Model family | How it is described | Selection guidance given | Route state displayed |
|---|---|---|---|
| DeepSeek | A fast reasoning model served by several independent providers; text routes remain in the fallback pool, while image requests go only to providers that can actually read them. | Use the default waterfall; modality separation is handled by the router. | Live provider routes shown as loading. |
| GLM 5.3 | Abliterated deployments from multiple providers consolidated behind one public model ID. | Route through the default waterfall, or explicitly choose a provider when a particular price or limit matters. | Live provider routes shown as loading. |
Neither family is presented as the whole product. The catalogue is described as a starting set that expands as additional abliterated models and competing inference providers become available.
Why a single connection instead of many
The positioning section frames the routing layer as one connection to the abliterated ecosystem. New abliterated models and price-competitive inference providers are pulled into the same layer, so the benefits claimed are the latest models, provider diversity and capacity failover behind a single security-hardened API — without rebuilding an integration each time the market moves.
Two OpenAI-compatible interfaces
- Chat Completions — POST /oai/chat/completions: supports messages, streaming, function tools and the familiar OpenAI chat schema.
- Responses — POST /oai/responses: supports input items, streaming events, reasoning controls, structured output, custom tools and hosted web search.
Search executed at the router, not the provider
Web search is processed at AllModels instead of being delegated to whichever inference provider happens to serve the request. The stated consequence is uniformity: every model gets the same OpenAI-compatible search calls and URL citations, even when its underlying provider offers no search. Concretely, a Responses API request can declare a web_search tool, while a Chat Completions request can set web_search_options with search_context_size "medium".
Automatic fallbacks and the three routing layers
Each request is dispatched across compatible providers. If one provider is unavailable or capacity constrained, traffic falls back automatically without changing the model ID or the application code. The published layering, and what it means for a caller, is summarised below:
| Layer | Handling described | Effect on the caller |
|---|---|---|
| Modality | Image and multimodal requests are sent only to providers that support them; text requests can use every eligible text route. | Vision traffic is never pushed onto text-only routes. |
| Capacity | When one provider is overloaded or unavailable, the next eligible route for the same model is tried automatically. | Availability is handled inside the router rather than by retry logic in the application. |
| Price | Provider pricing is kept current, with routing to the lowest-cost eligible option as new inference providers arrive. | Cost selection stays with the router unless a provider is pinned explicitly. |
FAQ: what readers are asking
What does p50 signify on the status strip?
It is the median (50th percentile) of the measured value. Here it is paired with — ms for latency and — tok/s for throughput, meaning placeholders rather than published measurements for DeepSeek V4.1 Flash Abliterated.
Does this require a new client library?
No. Both examples use the OpenAI SDK and OpenAI-compatible request formats; the differences are the API key environment variable, the base URL and the model string deepseek/deepseek-v4.1-flash-abliterated.
Are DeepSeek and GLM 5.3 routes live now?
The page shows live provider routes for both as loading, so the visible state is a pre-launch listing rather than a verified running service.
Can a caller choose the underlying provider?
For GLM 5.3 the guidance is to accept the default waterfall or explicitly select a provider when a particular price or limit is decisive.
Does web search depend on the provider behind a model?
According to the description, no: search runs at AllModels, so models whose providers lack search still return the same calls and URL citations.
Is the model list final?
No. DeepSeek and GLM are described only as the starting point, with the catalogue expected to grow alongside new abliterated releases and new competitive routes.
What to watch next
For readers tracking the global AI and data sector, the interest in this listing is procedural rather than technical. The aggregation point for abliterated DeepSeek and GLM 5.3 traffic is being sold on routing features — modality separation, capacity failover and price awareness — while the evidence that would let anyone verify performance or availability, namely populated p50 figures and running provider routes, is still shown as loading. The near-term signals to follow are the first real latency and throughput numbers, the model IDs that join the catalogue beyond DeepSeek and GLM 5.3, whether router-hosted search performs as described across providers, and how the default waterfall behaves once several routes are genuinely live. This report is published in the General desk of AIdataNewsGlobal by AI & Data News; correspondence: editorial@aidatanews.com.