Well.. here's a result that sounds wrong until you see the mechanism: Cerebras runs Qwen3.8-27B about eleven times faster than our H100, and still finishes fewer agent turns per minute than that H100. Both halves measured, same day, same harness, same model on both sides.

Let me be precise about what this is not saying. Cerebras is not slow. Single stream it decoded at 728-1142 tok/s in our tests against our box's ~87. The wafer-scale silicon delivers exactly what the marketing says, and if your workload is one stream of raw generation, it wins by a mile and this post does not apply to you. What follows is about a different question: what happens when you point a real agent harness at it.

The setup

Same model on both sides: Qwen3.8-27B, Cerebras' hosted qwen-3.8-27b versus RedHatAI's INT4 on the Trail Openers H100 in Helsinki. Both driven through the same OpenAI-compatible harness (pi-rukas, the agent framework we use daily): identical prompts, identical token budgets, reasoning_effort: "none" on both so neither burns thinking tokens, prefix caching warm on both, 429s retried with backoff rather than counted as failures. Six tests, about 22 minutes under load, 16.9.2026.

Agent work has a particular shape, and it decides everything here: the harness resends the whole conversation every turn. A coding agent sitting on a ~38k-token repo context sends those 38k tokens again and again, ~97% of them cache hits, to generate a few hundred new ones each time.

What the six tests said

Raw speed: Cerebras, decisively. 988 tok/s median decode vs 87. No contest, no dispute. (Funny detail: our time-to-first-token is better, 0.14s vs 0.33s, because the box is close and uncontended. They win the moment generation starts, not before it.)

Warm cached turns: us, actually. A 30k-token system prompt, four sequential turns, both sides caching. Their warm turns: 0.49-0.67s. Ours: 0.22-0.28s. For a short answer over a cached context - the single most common agent turn there is - our endpoint is already faster end-to-end.

Concurrency: we scale, they flatline. Simulated agent sessions over a ~38k context: Cerebras sits at 15-16 turns/min whether you run 1, 4, or 12 parallel sessions. Twelve sessions produced 60 rate-limit rejections and zero extra work. Our box went 9.2 → 27.5 → 45.6 → 62.7 turns/min at 1/4/12/24 sessions, zero rejections, still climbing when I stopped.

The obvious rebuttal, controlled for. Cerebras reserves input + max_completion_tokens up front, so surely the harness's 32,768-token default is self-inflicted? Re-ran the whole sweep at max_tokens: 1024, which is their own documented fix for spurious 429s. It changed nothing: 13.9-16.9 turns/min across the board.

The crossover: ~13k tokens of context. At ~10k context Cerebras wins clearly (62.8 vs 32.2 turns/min). At ~13k it's a dead heat. At ~38k we do 27.6 to their 12.4, and our box pushed 1.08M total tokens/min while theirs pinned at 460-670k no matter how the work was shaped.

What it feels like in practice: blocked. With the harness honouring their real Retry-After: 59, four sessions at 38.6k context spent 714 of 768 session-seconds waiting on backoff. 93% of wall-clock, blocked. The "it feels slow" instinct was correct: it was watching a full-minute stall, several times per session.

The mechanism, because it predicts every number above

Cerebras enforces two per-minute token buckets: an uncached one (150,000 tok/min on this account) and a total one at three times that, ~450k. Cache hits are exempt from the uncached bucket. They are not exempt from the total bucket. So a 38k-token agent context costs 38k against the quota every single turn, even when 97% of it is a cache hit and the model generates 300 new tokens. Our measured uncached burn was 19,248 tok/min, 13% of the allowance - we were nowhere near the advertised limit and throttled anyway.

Which gives you a rule simple enough to say out loud: turns per minute ≈ the total-token ceiling divided by your context size. Below ~13k of context the fast silicon wins. Above it, the ceiling does the deciding, and the world's fastest inference sits idle waiting for the next minute to start.

What I'd actually claim

So I'd put it this way: this is not a hardware story, it's a quota-design story. Their limiter prices a cached token like a computed one, and agents are the workload that maximises exactly that ratio. The unarguable version of the finding: dedicated capacity beats metered capacity for sustained agentic work. Our H100 has no rate limits because it's ours; that, not the silicon, is what won.

The caveats, before someone else states them: this is one account on one tier (450 RPM / 150k uncached TPM, measured 16.9.2026), not "Cerebras" - enterprise and dedicated endpoints get provisioned differently. Theirs is a shared multi-tenant service measured at one point in time. No cost claim here: a metered API against a box rented 24/7 is not a like-for-like bill. And no quality claim: they serve unquantised weights, we serve INT4; throughput compared, output quality not.

The part I find genuinely interesting: every provider racing to the top of the tok/s leaderboards is optimising the number that matters least for agents. An agent's real currency is completed turns per minute at its actual context size, and that's decided by quota shape, cache pricing, and backoff behaviour - the things no leaderboard shows. Speed-of-light decode with a context-priced meter in front of it is a sports car with a toll booth every 38,000 tokens...