1,500 tokens per second: Qwen 3.8 on Cerebras and the question of agent speed

Cerebras lists Qwen 3.8 27B in its own model catalog at roughly 1,500 tokens per second of output speed. The Hacker News discussion from 03.09.2026 stood at 493 points when I queried it through the API on 05.09.2026. Both facts are remarkable. The more interesting question starts after that, though: what does this speed do to an agent that does not run in a data center, but on a used Google Pixel 6a?

My answer from live operation is: the rate buys fast thinking steps, but it does not buy operations. An agent first needs a host that survives cron ticks, memory pressure and restarts before any token rate is worth anything. That is exactly what this post is about. I keep a clean separation between what the Cerebras catalog states, what I measured myself, and what remains a reasoned hypothesis.

I organize my agent operation into three layers, and this distinction carries the whole post. It is a working model, not a measured decomposition. The first layer is model thinking: planning, judgment, draft text. The 1,500-token rate helps here directly, because a plan stands in seconds where it used to take minutes. The second layer is the mechanics: scripts fetch transcripts, check 58 YouTube feeds, and write heartbeats. This work runs without model requests and therefore without any dependency on tokens per second.

The third layer is operations: watchdogs, cron ticks, and the restart when Android takes memory away from the process. Here endurance decides, not speed. The three layers do not add up, they dominate one after another. As long as the operations layer wobbles, the thinking layer is a matter of taste. And as long as the mechanics are built on requests, they eat the quota the thinking would need.

Why Android kills background processes at all, and how my stack survives those kills, I documented in detail in the Android post, from the OOM storm on 28 August to the semantic watchdog. Only the consequence matters here: the operations layer knows no tokens per second. It knows ticks, logs, and restarts. Whoever buys only the thinking layer ends up with the fastest weak point of the system.

The mechanics layer is the reason my quota lasts at all. Fetching the complete transcript of a 54-minute video and turning it into a blog draft barely touches the model quota, because a script fetches the transcript and only the judgments cost requests. What this stack looks like as a whole, namely Termux, PRoot, no root, cloud models, is described in the stack post.

I measured three things, all in normal operation, none of them in a lab. First, the quota side: the complete processing of a 54-minute video cost 0.5 percent of the five-hour window on 04.09.2026 according to a dashboard comparison. That is a single measurement from a single workflow type, and it says something about quota load, not about energy or general cost.

Second, stability: per stability-snapshots.log and the hourly heartbeat chain, the system ran from 28 August, 19:40 to 1 September, 12:18, 88 hours in a row, with no observed OOM kill since the hardening on 28 August. The measurement ticks hourly, it sees nothing between checks, and zero observed kills are no guarantee for the future. Third, the projects: the Network Obfuscation Layer and the Preiskompass passed 36 of 36 tests together on 30.08.2026.

What none of these numbers contain is a per-layer time measurement. I did not run a stopwatch that times planning, mechanics and operations separately. The claim that the bottleneck sits in operations and not in the model is therefore a reasoned hypothesis for my operation: supported by the observation that the agent waits on test runs and cron ticks, not on model responses, and that the mechanics work without requests. It would be refuted if a real measurement showed that network and model make up the largest share of my turn times. Exactly that measurement is missing. It is the next binding verification step, and this post does not claim it.

All the same, the observation is more concrete than the word hypothesis sounds. While building the two verified projects, the waiting time sat in building and checking, so in test runs, lookups and verification. The model was never the obstacle I actually felt. And the 0.5 percent measurement points in the opposite direction of the usual worry: the thinking is not what is expensive, everything around it that runs often is. Together, both make the hypothesis plausible, but neither replaces a stopped measurement series.

The 1,500-token figure is not a one-off but the current rung of a ladder Cerebras has been climbing for more than a year. In July 2025 the company brought Qwen3-235B out as the fastest frontier model at 1,500 tokens per second and put a number on the practical gain: response times drop from one to two minutes to around 0.6 seconds, per the press release. Qwen3-32B runs at 2,400 tokens per second according to the Cerebras blog, the first response token arrives after 1.2 seconds by their own account, measured by Artificial Analysis. For comparison, the same blog states: GPU-based inference sits at roughly 150 tokens per second for models of this class.

For a clean assessment it helps to keep five quantities apart that often get squeezed into one number: output token rate, time to first token, total duration of a job, output quality, and price. The catalog names for Qwen 3.8 27B the rate of roughly 1,500 tokens per second and a context window of 64k on the free tier and 128k on the paid tier, retrieved on 05.09.2026. A first-token latency figure for this model is not listed there; the 1.2 seconds above belong to Qwen3-32B. The catalog says nothing about quality, and prices sit separately behind rate limits and the pricing page. I did not evaluate them for this post, so I make no claim about cost.

The real message of the ladder is therefore a shift in the debate. A year ago the question was whether such a speed is possible at all. A 27B model now sits in the regular catalog at this rate, and the question is no longer how but what for. The rest of this post works on that second question.

The thread is worth reading as a mood check, and I read it exactly as that: a state of opinion, not technical evidence. Part of the comments celebrates the speed and works out how coding workflows feel when the answer arrives in fractions of a second. Another part runs the numbers on pricing and reports that prompt caching is supported but costs the same per sentence as fresh tokens, and that the subscription model is sold out. Others ask about the context window, find the 128k, with the caveat that it barely suffices for agentic work. And one comment calls the announcement by its name: pure marketing.

I do not read that as contempt but as a shift in what the market offers. Speed is the advertised advantage, but what an agent operator additionally has to buy is reliability: a host that delivers ticks while no model request is open. Cerebras sells the fastest thinking layer. Whoever owns only that layer notices, at the latest at the first Android kill, that a missing operations layer is not worth a single token per second.

The rate matters because it changes the calculation: faster model outputs could shift the bottleneck toward the operations layer. For my workflow that is a hypothesis, since per-step timing is missing; it is the working hypothesis of this post, not its measured conclusion. An agent that plans in 30 seconds still waits for the next cron tick, because the host sets the tempo. My setup has the hourly heartbeat, an external tick arrives every 60 seconds, and watchdogs bring the system back after an Android kill. For that restart I read roughly two minutes out of the snapshots, without a cleanly stopped measurement stretch; the precise figure is missing, and the Android post shows the mechanism in detail.

My conclusion deliberately names no winner. The 1,500 tokens per second for Qwen 3.8 27B are real, documented, and a genuine upgrade for the thinking layer. For agent operation on weak hardware, the benefit is decided in places the catalog does not list: clocks, memory pressure, agent memory, test runs. Anyone thinking about this should build the operations layer in parallel with the thinking layer, so watchdogs, ticks and memory, and not let speed be sold to them as a substitute. As the next verification step I have set myself a stopped turn time series, with network, model and orchestration separated. Once it runs, it replaces the hypothesis of this post with numbers.

About the author: I run the HUNTER cyberdeck on a used Google Pixel 6a, without root, with cloud models and terminal orchestration. I am Marcel, a graphic designer and operator of the d4sn3st sites. This post is based on my own measurements from stability-snapshots.log and the Ollama dashboard in the window 28.08. to 05.09.2026, plus the test reports of the two verified projects dated 30.08.2026. External figures come from the Cerebras model catalog and the Hacker News discussion, both retrieved on 05.09.2026. Last fact-checked: 05.09.2026.