Diffusion decoding in production: output-speed measurements for celeris-1

Today we're sharing output-speed measurements for celeris-1, our diffusion language model, on an Artificial-Analysis-style workload, run head-to-head against five widely used model APIs: mercury-2, gemini-3.5-flash, gemini-3.5-flash-lite, gpt-5, and gpt-5-mini. On this benchmark, celeris-1 generated a median of 1,664 tokens per second - 5.1 times the next-fastest API we measured - and returned complete responses to 1,000-token prompts in a median of 0.58 seconds.

Speed determines where a model can be used. A response that arrives in half a second fits inside the latency of an ordinary page load; a response that arrives in fifteen seconds does not. Below we present the full results, explain exactly how we measured them, and note the limitations of the comparison.

Results

Each model received an identical workload: ten long-form prompts of ~1,000 input tokens, five samples per prompt, non-streaming, with output capped at 1,024 tokens. Output speed is the number of tokens the provider reports generating - including hidden reasoning tokens - divided by the time the request took.

Read as a stopwatch rather than a rate, the same data shows the median time to a complete response: 0.58 seconds for celeris-1, 3.10 seconds for the next-fastest model, and 14.78 seconds for the slowest.

The result is consistent across the full run, not a favorable median. The slowest of celeris-1's 49 timed requests ran at 814 tokens per second, while the fastest single request from any other model reached 662. The two distributions do not overlap.

The runs above left reasoning at provider defaults. We also reran the workload with reasoning off: the picture does not significantly change - every model lands close to its default-mode speed, so the gap is decoding, not thinking budgets.

What this makes possible

The difference between these speeds compounds in any system that generates more than once. A ten-step agent pipeline that spends 0.58 seconds per generation finishes its generation work in about 6 seconds with celeris-1; the same pipeline spends roughly 31 seconds with mercury-2, 76 seconds with gemini-3.5-flash, and 148 seconds with gpt-5. At sub-second response times, techniques that are usually reserved for offline processing - sampling several candidate responses and keeping the best, regenerating a document instead of patching it - fit within interactive latency budgets: five full resamples of a 1,000-token response complete in about 3 seconds.

celeris-1 reaches these speeds because it is a diffusion language model: it produces many tokens per model invocation, rather than one token per forward pass as in autoregressive decoding. It is notable that the two fastest APIs in this comparison are the two diffusion models.

How we measured

Published speed figures depend heavily on methodology, so we want to be precise about ours. The prompts are original text written to match the published shape of the Artificial Analysis workload - Artificial Analysis does not release its prompts, and these are our measurements, not theirs. All requests were non-streaming, sent sequentially over a pre-warmed connection, with one discarded warm-up request per provider.

The denominator - response time - is the provider's own server-reported processing time where one is exposed, and end-to-end wall time measured from a virtual machine inside the provider's serving region where it is not:

• gpt-5 and gpt-5-mini: OpenAI's openai-processing-ms response header, which contains no network time.
• celeris-1: end-to-end from EC2 us-east-1, the model's serving region. Measured end-to-end exceeded the server's own Server-Timing header by a median of 3.9 ms - 0.7% of the 578 ms median response.
• mercury-2: Inception's x-process-time response header. We validated the header before relying on it: it scales with output length, its distribution is the same from different measurement locations, and end-to-end wall time from a GCE us-west1 instance exceeded it by 70 ms median - consistent with it measuring origin-side processing only. mercury-2 was re-measured on 23 July on this basis. An earlier end-to-end measurement (22 July) gave 294 tok/s at p50; it was lower for two reasons corrected here: ~70 ms of network overhead inside every request, and Inception reporting reasoning tokens in a separate usage field that the first run did not count.
• gemini-3.5-flash and -lite: end-to-end from GCE us-central1 against the global Vertex endpoint; Vertex exposes no server timing.

These two timing bases are not identical, but the asymmetry runs against celeris-1 and the gemini models: their figures include real network overhead that the server-reported figures exclude. For celeris-1 this is 3.9 ms median on a 578 ms response - under 1%.

Limitations

Reasoning budgets were left at provider defaults: at this output cap, gpt-5 and gpt-5-mini spent their entire 1,024-token budget on hidden reasoning and gemini-3.5-flash spent ~980 of 1,020 tokens thinking, and mercury-2 spent a mean of 208 of its ~997 tokens on reasoning, so their figures are decode rates over the tokens they chose to generate. Token counts are provider-self-reported. The 1,024-token cap truncated most responses. Five models were measured on 22 July and mercury-2 re-measured on 23 July, 50 requests per model, one region per provider; one celeris-1 request returned a rate-limit error and is excluded. Raw per-request data for all 300 timed calls, the dataset, and the harness are available on request.

celeris-1 is available today through the Celeris API.