July 24, 2026

9 min read

AI Models

Celeris-1: The Diffusion LLM Betting That 158ms Matters More Than Another Benchmark Point

> Celeris-1 is a diffusion-based, OpenAI-compatible LLM claiming 75.9% MMLU-Pro at 158ms p50 latency. Here is what its speed changes for voice, agents, and developer workflows.

ShareX LinkedIn

🎧 Listen — ~9 min

Audio summary not available yet

~9 min

Verified by Essa Mamdani

Published: July 24, 2026
Category: AI Models
Tags: Celeris-1, diffusion models, LLM inference, AI agents, latency, OpenAI-compatible API

The usual frontier-model conversation starts with one question: Which model scores highest? Celeris-1 starts somewhere more operational: How long can an application wait before intelligence stops feeling useful?

Celeris Labs has launched Celeris-1, a general-purpose language model built around a diffusion-based inference architecture rather than conventional autoregressive decoding. The company’s claim is clear: near-frontier quality with radically lower response latency. In its published test, Celeris-1 scores 75.9% on MMLU-Pro at a 158ms p50 server-reported response time, with output throughput of 1,664 tokens per second. Celeris prices the API at $2 per million input tokens and $6 per million output tokens.

Those are vendor-reported figures, not an independent leaderboard result, so they need to be read as a starting point for testing—not as a reason to migrate a production stack blindly. But the premise is important. A model that answers in a fraction of a second can change what belongs in the hot path: live voice, autocomplete, agent substeps, query rewriting, extraction, and real-time product interactions.

This is the practical developer guide to what Celeris-1 is, what the published numbers do and do not establish, and where it is worth trying first.

Celeris-1 at a glance

Item	Celeris-1
Model family	General-purpose language model
Inference approach	Diffusion-based, according to Celeris
API	OpenAI-compatible chat completions
Published MMLU-Pro result	75.9% (5-shot chain-of-thought)
Published p50 response time	158ms, server-reported
Published p50 output rate	1,664 tokens/sec
API pricing	$2/MTok input, $6/MTok output
Primary stated fit	Voice, agents, real-time apps, high-throughput generation

The immediate attraction is not that Celeris-1 claims to replace every strongest reasoning model. It is that it targets the large class of tasks that are currently “good enough technically, frustratingly slow experientially.”

For a chat reply, two seconds may be tolerable. For every turn in a voice conversation, every tool-selection pass in an agent loop, or every keystroke in an IDE, it compounds fast. Ten sequential model calls at two seconds each create a twenty-second workflow before network and tool time. At a much lower model latency, the bottleneck moves back to the real work: database queries, browser actions, tests, and human approvals.

Why diffusion changes the latency story

Most large language models are autoregressive: they generate token one, then use it to produce token two, and so on. That sequential dependency is extraordinarily capable, but it makes generation latency fundamentally cumulative.

Celeris says its inference stack uses diffusion, allowing it to generate language through a different process designed for parallelism. The engineering promise is not merely “more tokens per second.” It is lower time-to-first-useful-answer and lower completion time for short-to-medium outputs.

That distinction matters. A long-form report can hide a slow start because the user will read for minutes. A voice assistant cannot. A tool-using agent deciding whether to retrieve, classify, route, retry, or ask a clarifying question should not spend multiple seconds on each tiny decision. These intermediate tasks are where a fast model can make a system feel coherent instead of stitched together.

The same broad opportunity is why browser-native and local inference are becoming relevant. LiteRT.js: Google’s WebGPU Browser AI Runtime and PrismML Bonsai 27B approach the latency problem from a deployment angle; Celeris approaches it from model inference architecture.

Reading the benchmark claim correctly

Celeris publishes a useful amount of methodology alongside its headline. It says it evaluated the full MMLU-Pro test set across fourteen categories with five-shot chain-of-thought and strict answer-format scoring. The comparison includes GPT-5, GPT-5 mini, Gemini 3.5 Flash Lite, Gemini 2.5 Flash, and Inception Mercury 2.

In that run, all compared models were configured for their fastest setting: reasoning budget zero for Celeris, GPT-5, GPT-5 mini, and Gemini models; “instant mode” for Mercury 2. Celeris reports 75.9% at 158ms p50, versus GPT-5 at 81.9% and 2,046ms, and Gemini 3.5 Flash Lite at 83.0% and 1,232ms. The company says its latency is server-reported where supported; Gemini’s figures are end-to-end measurements from a colocated client.

This makes the chart informative but not final.

It is a reasonable demonstration that the company is measuring quality and speed within one harness. It does not tell you which model will write the best production patch, follow your tool schema most reliably, handle a 200-page document, or stay coherent across a long autonomous task. MMLU-Pro is a reasoning benchmark; it is not a substitute for testing your own workload.

The right takeaway is: Celeris-1 has made a credible speed-quality claim worth reproducing on your tasks. Treat its “15× faster” positioning as workload-dependent, because latency changes with prompt size, output length, streaming, network location, concurrency, and reasoning configuration.

For a wider market map before choosing a model route, use July 2026 Frontier Model Comparison.

The best first workloads

Celeris’s own documentation points to short intermediate tasks: classification, extraction, scoring, and query rewriting. That is exactly where I would begin.

1. Agent routing and substeps

An agent should not need a premium, slow reasoning pass to decide which queue owns a ticket, whether a document contains a required field, or whether retrieval results are relevant. Put Celeris-1 behind a strict JSON schema and measure accuracy, retry rate, and time-to-action.

This fits well with the architecture in AI Agent Stacks: Skills, Plugins, MCP, ACP, Memory and Workflows: use a fast model for routing and constrained subagents, then escalate genuinely difficult work to a deeper model.

2. Real-time voice and chat

Conversation quality is partly a turn-taking problem. If a model starts answering quickly and streams smoothly, voice applications can feel less like a form submission and more like a dialogue. Celeris advertises streaming by default and says responses can begin as low as 24ms; verify that claim from the user’s region and with your own speech-to-text and text-to-speech pipeline in place.

3. Retrieval quality gates

RAG systems often need several lightweight checks: intent classification, query rewriting, relevance scoring, citation completeness, and unsafe-answer detection. Making those gates fast removes a common temptation: skipping evaluation because it adds too much latency. RAG Eval Gates for TypeScript Support Agents describes the sort of measurable gate Celeris-1 could power.

4. High-throughput transformations

Extraction, tagging, normalisation, and document transformation are usually constrained by volume rather than one spectacular answer. The $2/$6 per-million-token pricing and stated output rate are appealing here, but the test still needs to include malformed output, retries, and the cost of validation.

OpenAI-compatible API: a low-friction evaluation path

The integration story is pleasantly simple. Celeris documents a chat-completions endpoint and compatibility with clients that accept a custom OpenAI base URL. Its documented first call looks like this:

bash

1curl https://inference.celeris.ai/celeris-1/v1/chat/completions \
2  -H "Authorization: Bearer $CELERIS_API_KEY" \
3  -H "Content-Type: application/json" \
4  -d '{
5    "model": "celeris-1",
6    "messages": [{"role": "user", "content": "Classify this ticket."}],
7    "max_tokens": 256,
8    "temperature": 0,
9    "seed": 7
10  }'

That compatibility should make a controlled A/B test easy: keep your system prompt, schema, validator, and evaluation set fixed; change only the provider route. Do not assume compatibility means identical behaviour. Test tool-call formats, JSON reliability, stop conditions, streaming events, rate limits, and error handling before moving traffic.

Celeris also says successful responses include Server-Timing metrics. Capture those beside client wall-clock time. Server processing tells you about model performance; client time tells you what your customer actually felt. You need both.

Build a routing strategy, not a single-model religion

The interesting production pattern is not “replace every model with Celeris-1.” It is a tiered system:

Celeris-1: high-volume, low-latency steps with objective evaluation.
A strong general model: complex coding, nuanced analysis, or tasks needing broad capability.
A maximum-effort route: high-stakes planning, difficult debugging, and long-context work where human review is expensive.

For example, a coding assistant could use Celeris to classify the request, select repositories, rewrite search queries, and summarise small tool outputs. It could escalate implementation planning and code changes to Claude Opus 5, where context and deliberate reasoning matter more. Claude Opus 5: developer migration guide explains that other side of the trade-off.

For production agent systems, retain observability across every route. OpenTelemetry GenAI Observability is the useful baseline: trace the model selection, prompt version, timing, tool calls, validator results, fallback, and final outcome.

A practical test plan

Run Celeris-1 against your current route with a fixed test set. At minimum, measure:

acceptance accuracy or task completion rate;
structured-output validity on the first attempt;
p50, p95, and p99 end-to-end latency;
server-side versus client-observed latency;
cost per accepted task, including retries and fallback;
tool-selection and safety-policy failures;
user-visible quality for voice or interactive UX.

Then segment results. A classifier may be excellent while a tool planner is unreliable; a 100-token response may be blazing fast while a 2,000-token response changes the picture. This is how you avoid celebrating an average that masks the workload your users care about.

When a model becomes part of a write-capable agent, speed makes safety controls more—not less—important. Keep narrow tool permissions and explicit approval for external actions. MCP Security Threat Modeling Guide is a useful companion for that design work.

The verdict

Celeris-1 is worth watching because it attacks an underappreciated constraint: inference delay is product design. A model that is fast enough can move intelligence from a background feature into the interaction itself.

The vendor’s published data makes a persuasive case to test the model for short, measurable, latency-sensitive work. It does not yet prove that Celeris-1 is the universal best model, nor should it. The winning implementation will be the one that gives each task the cheapest, fastest model that can meet a clearly measured quality bar—and escalates only when necessary.

If you operate voice agents, high-frequency retrieval pipelines, interactive coding tools, or multi-step workflows with too much dead time between decisions, Celeris-1 deserves a small, disciplined trial now.