# At 750 Tokens a Second, GPT-5.6 Sol Moves the Bottleneck **Summary:** Cerebras says GPT-5.6 Sol Ultrafast reaches up to 750 output tokens per second; my read is that the speed matters only when model latency still controls the workflow. - Canonical: https://markhuang.ai/news/gpt-5-6-sol-750-tps-bottleneck-moves - Language: en - Author: [Mark Huang](https://markhuang.ai/about) - Published: 2026-08-13 - Section: News - Tags: GPT-5.6 Sol, Cerebras, AI Inference, OpenAI API, AI Agents - Source: [Cerebras](https://www.cerebras.ai/blog/accelerating-gpt-5-6-sol-ultrafast-with-openai) - License: https://creativecommons.org/licenses/by-nc/4.0/ --- ![A glowing wafer-scale processor sends a bright data stream through a series of slower mechanical gates](https://cdn.markhuang.ai/news/gpt-5-6-sol-750-tps-bottleneck-moves/hero.webp) *When model output arrives almost instantly, the gates around the model become easier to see.* On August 13, 2026, [Cerebras introduced GPT-5.6 Sol Ultrafast](https://www.cerebras.ai/blog/accelerating-gpt-5-6-sol-ultrafast-with-openai), a limited-preview OpenAI API service tier that can generate up to 750 output tokens per second. [OpenAI says](https://openai.com/index/previewing-ultrafast/) that is up to 14 times faster than Standard processing. Access starts with a select group of customers and will expand as capacity grows. Watching text appear at that speed will be fun for about five minutes. I care more about what becomes slow next. Once the model can finish a long answer in seconds, network calls, tools, tests, approvals, and human review dominate the clock. Ultrafast could change which agent workflows are practical, but only when the next action truly depends on getting the model's answer now. Speed is easy to admire and hard to value. I would pay a premium to shorten an incident-response loop while a production system is failing. A background refactor that will sit in a review queue until tomorrow can wait. ## The benchmark is fast, but it is still a vendor benchmark Cerebras tested all 2,500 questions in Humanity's Last Exam and reports that Sol Ultrafast finished in 11 hours and 11 minutes. Its Claude Fable 5 comparison took 78 hours and 27 minutes. Cerebras describes the accuracy as comparable and the end-to-end run as nearly seven times faster. The company also reports a 5.6-times end-to-end speedup over Standard Sol on GDP-Val. Those measurements are useful because they cover full workloads rather than a short burst of output. They are still Cerebras's own evaluations. The company ran the tests on different July dates and disclosed the relevant reasoning settings, which helps, but workload configuration, concurrency, harness behavior, and service conditions can all affect elapsed time. The original [Humanity's Last Exam paper](https://doi.org/10.1038/s41586-025-09962-4) describes a 2,500-question, expert-level benchmark. It measures difficult closed-ended academic questions, not the messy latency of a production agent calling databases and waiting on test suites. The phrase "up to 750 output tokens per second" also needs its full sentence. Output speed measures token generation after the request reaches the model and processing begins. It does not promise that every prompt starts instantly or that every tool in an agent loop becomes 14 times faster. OpenAI's own [inference engineering account](https://openai.com/index/gpt-5-6-frontier-intelligence-efficiency/) notes that one Codex turn may involve 30 model requests plus tool calls. Saving a second inside a repeated step adds up. So does every second that remains outside it. ## Cerebras attacks the memory movement problem Cerebras attributes the speed to its Wafer-Scale Engine. The company's explanation is concrete: large-model inference repeatedly moves weights between compute and off-chip memory, while its wafer-sized processor carries 44 GB of SRAM on each chip. Cerebras says weights stay on-chip and tokens move through model layers pipelined across wafers. That architectural bet interests me more than the tokens-per-second trophy. OpenAI is now pairing the same frontier model with materially different serving paths, turning inference hardware into a product choice. It also complements OpenAI's work on its own inference processor, which I covered in [the Jalapeño announcement](https://markhuang.ai/news/openai-jalapeno-inference-bet). OpenAI is specializing its internal stack while also bringing a wafer-scale partner into the API. ## A faster model changes the shape of the product OpenAI points to incident response, live research, voice support, commerce, and financial analysis as early targets. Those examples share one property: the useful answer has a short shelf life. A diagnosis that arrives while an outage is unfolding can change the next check. A voice assistant that pauses for a minute has already failed, however good its eventual answer may be. At 750 tokens per second, a team can keep one line of thought active, inspect a result, and immediately choose the next experiment. OpenAI says its researchers are testing whether work that once ran overnight can become several iterations during the workday. That sounds plausible, though the preview still needs customer evidence beyond launch testimonials. > **Info:** > > I would reserve Ultrafast for loops where a faster answer changes the next action: an outage, a live customer interaction, an interactive experiment, or a human waiting to review a proposed patch. Batch work should earn the premium with measured wall-clock savings. ## Speed does not fix judgment A faster agent can make the wrong loop run faster too. An independent developer's [hands-on account of Sol](https://awaited.dev/experiments/gpt-5-6-sol-overengineering/) praises its ability to find risks but describes having to roll back over-engineered fixes. That is one practitioner's report, not a controlled study. The practical concern is straightforward: generation speed does not decide whether a proposed change is necessary, scoped correctly, or safe to deploy. OpenAI draws the same boundary in its incident-response description. Engineers remain responsible for judgment and deployment. I would keep tests, policy checks, and human approval in the path even when they look painfully slow beside the model. A shorter feedback loop still needs brakes. ## The missing number is the price Neither launch post publishes Ultrafast pricing. [OpenAI's current API page](https://developers.openai.com/api/docs/models/gpt-5.6-sol) lists Standard Sol at $5 per million input tokens and $30 per million output tokens, but that does not establish the preview tier's price. Capacity is another open question because access is limited and expands only as Cerebras and OpenAI add room. Before moving a production workload, I would compare total task time, total cost, time to first token, tool wait, retry rate, and review burden on the same traces. Tokens per second belongs in that evaluation. It should not own it. Ultrafast moves the bottleneck. For interactive work, that may be enough to change the product. For everything else, I would measure the whole loop first and find out whether waiting on the model was ever the expensive part.