Is Cerebras faster than OpenAI / Anthropic for browser agents?

Cerebras GPT-OSS-120B claims and delivers ~2,042 tokens/second sustained — about 10× faster than GPT-5.1 (~200 tps) and 4× faster than Claude Sonnet 4.6 (~500 tps). For a 1k-token plan-and-act response, that's 0.5s vs 5s wall clock. For browser agents that issue 30-60 tool calls per task, this should compound massively. It does — but only on tasks where vision isn't required.

What's the actual blocker?

Vision input. Cerebras's GPT-OSS-120B accepts text only. Browser agents are inherently visual — they need to look at the DOM screenshot to know where a button is, whether a captcha rendered, whether the navigation actually loaded. With text-only input you can use DOM serialization, but DOM serialization breaks on every modern SPA (React/Vue/Svelte intercepting clicks, hidden form fields, anti-bot canvas fingerprints). For a workhorse agent you need eyes.

Can you make it work with DOM-only?

Yes — and we did, for navigation-only tasks. Cerebras successfully drove our agent through simple page-load + extract-text flows at 1/10 the wall-clock cost of GPT-5.1. But on real customer workloads (Fiverr search, Skyscanner flight booking, LinkedIn search) DOM-only fails because: (1) modern sites use JavaScript-rendered content that's missing from the initial DOM, (2) bot-detection scripts probe what the page looks like to a 'real' user, and (3) the LLM has no way to read captcha images. Vision isn't optional for general-purpose browser automation.

Will Cerebras add vision?

Their roadmap mentions multimodal but no committed date as of 2026-06. GPT-OSS itself is a text-only architecture. They'd need to either fine-tune a vision-capable variant or partner with someone who ships multimodal weights. When that lands, we'll re-benchmark.

What would you use Cerebras for today, if not browser agents?

Three legitimate fits for the speed advantage: (1) Post-mortem analyzer — we already use cheap models to classify failures, but Cerebras would let us do it in real-time as the session runs, not after. (2) Site-rules-aggregator — distilling 100+ trajectories into per-domain recipes, where speed matters more than vision. (3) Reasoning-heavy non-browser agents — anything that's pure text in / structured-output. We're piloting category (1).

What did integration actually cost?

About 4 hours of engineering: (1) per-spawn fast_rail field plumbed into spawner-router.js to swap LLM endpoint at runtime, (2) Cerebras-specific HB_USE_VISION=0 + integration header to strip image_url blocks from outgoing prompts, (3) cost-tracker pricing entry for gpt-oss-120b, (4) provider routing detection from Cerebras's openai-compat base_url. The code is still in our prototype but flag-gated off (HB_FAST_RAIL_ENABLED + URL=cerebras.ai).

Why publish this if you're not using it?

We're a benchmarks-as-a-side-effect platform — we run many sessions across many models for many customers. The position we want to occupy is the honest source of truth for which LLMs work where. Saying 'Cerebras was 10× faster but we don't use it' is more useful than another '10 LLMs ranked' listicle. It tells you what the real constraint is.

Jun 03, 2026 · 9 min read

Cerebras GPT-OSS-120B as a Browser Agent: 2042 tok/s, But We Don't Use It (Yet)

Line art of a speedometer needle pinned past the limit while a blindfolded figure tries to drive — Cerebras speed without vision

The Headline Number That Made Us Pay Attention

Cerebras's gpt-oss-120b sustains 2,042 tokens per second. That's not a peak burst — that's the median wall-clock throughput we measured on real requests through their public API.

For context, the same prompt against:

OpenAI GPT-5.1: ~200 tokens/second sustained
Anthropic Claude Sonnet 4.6: ~500 tokens/second sustained
Google Gemini 2.5 Flash Lite: ~600 tokens/second sustained

For a browser agent that issues 30-60 reasoning rounds per task, 10× faster generation should compound into 3-5× faster end-to-end sessions. Less wait, less cost, fewer flaky timeouts. We had to try it.

Side-by-side latency bars: Cerebras tiny, others stacking up

How We Integrated It

Cerebras's API is OpenAI-compatible (good — our LLM gateway already speaks that shape). The integration was four small changes:

Per-spawn LLM override. Our spawner-router.js already supported swapping LLM endpoint per session for A/B benchmarking. We just had to add Cerebras's base_url + key as another option.
Vision strip. Cerebras GPT-OSS-120B is text-only. When the agent's prompt would normally include a screenshot as an image_url block, we needed to drop it. We added HB_USE_VISION=0 as a per-rail flag that browser-use respects.
Cost tracker pricing entry. Cerebras's pricing for GPT-OSS-120B is published as $0.15 / $0.60 per million input/output tokens. Added an entry to our pricing table.
Integration header. Cerebras asks for a courtesy x-integration-name: humanbrowser header. Nice touch — we added it.

Total time: about 4 hours of engineering. The flag-gated path is still in our prototype repo.

The Benchmark

We ran the same multi-site research task that produced our main LLM benchmark — find a trending GitHub repo, find the HN discussion of it, find the project's homepage, extract a 5-field structured summary.

What we measured

Wall-clock time per task (start of /spawn to /done)
Cost per task in USD (input + output tokens × Cerebras list price)
Success rate (5 fields extracted / 5 attempted)
Step count (number of tool-call rounds before done())

Results — Cerebras vs Our Default Stack

Model	Mean wall-clock	Mean cost	Success (3 reps)	Steps
Cerebras GPT-OSS-120B	11s	$0.012	2/3 (1 incomplete extraction)	5-7
OpenAI GPT-5.4-mini	34s	$0.092	3/3	9-12
Gemini 2.5 Flash Lite	22s	$0.023	3/3	6-9

On wall-clock alone, Cerebras lapped the field — 3× faster than Gemini, 6× faster than OpenAI. Cost was the cheapest on a per-token basis too.

On read-only tasks Cerebras was 3-6× faster and the cheapest model we tested. On any task that touches the visible DOM it fell over.

Then We Tried a Real Customer Task

We swapped the benchmark goal for what an actual paying customer ran the day before: "search Fiverr for 'logo design', open the cheapest gig, report the gig title and price." This is a Cloudflare-Turnstile-protected SPA with a React-rendered search dropdown and lazy-loaded results.

Outcomes (3 reps each):

Cerebras GPT-OSS-120B: 0/3 success. The agent landed on Fiverr, recognized the search box was present in serialized DOM, typed the query, hit Return — and then could not interpret the results page. The search-result cards on Fiverr are rendered late and depend on whether you scrolled, whether the carousel ran, whether the consent banner was dismissed. Without vision, the agent's serialized DOM contained 90% of the page chrome (header, footer, sidebar) but not the result cards it needed to extract from. It looped, ran out of step budget, and reported "no gigs found."
Gemini 2.5 Flash Lite (with vision): 3/3 success. The screenshot showed where the gigs were rendered. Visual identification → click → extract.
Claude Sonnet 4.6 + Computer Use (via xdotool, our Pro CUA tier): 3/3 success including PerimeterX press-and-hold recovery.

Two split screens — left shows agent reading raw DOM tree with key elements missing, right shows agent looking at full screenshot with everything visible

Why the DOM Isn't Enough

This is the part that doesn't get talked about enough. Three structural problems:

Modern SPAs lazy-render. When the page first loads, the React/Vue/Svelte tree hasn't committed yet. The serialized DOM you get from document.documentElement.outerHTML is a stub. Whether you've waited long enough, scrolled, or triggered IntersectionObserver hooks all change what's in that stub.
Anti-bot canvas fingerprints render visually but not semantically. PerimeterX's "Press & Hold" challenge, Cloudflare Turnstile's checkbox, hCaptcha's image grid — they all render as visual elements. A vision model sees them. A text-only model sees opaque iframes from js.px-cloud.net or challenges.cloudflare.com and can't tell what to do with them.
Position matters for clicks. Even when an element is in the DOM, knowing its rendered position on screen is what lets a vision agent or an OS-input agent click it accurately. Text-only agents click by CSS selector — and CSS selectors break the moment a site does an A/B test, ships a redesign, or routes you to a slightly different layout based on geo.

What We'd Need to Bring Cerebras Back

Two paths could change this:

Cerebras ships a vision-capable model. Their roadmap mentions multimodal, but as of June 2026 there's no committed date. GPT-OSS the base architecture is text-only; they'd need a new fine-tune or a partnership with someone shipping multimodal weights.
We build a hybrid pipeline. Cerebras (text-only, ultra-fast) for the planning + reasoning rounds; a vision model (Gemini Flash Lite or our CUA Claude Sonnet) injected only on the rounds that need to look at the screen. This is technically doable — our agent loop already separates "what to do" from "do it" — but adds complexity and a context-handoff cost. We've benchmarked it as a future experiment but it's not on this quarter's roadmap.

Where Cerebras IS Worth It Today

The speed advantage is real and we're using it in two places that don't need vision:

Post-mortem analysis at scale. After every failed session we run an LLM over the audit trace to extract the root cause, the working strategies, and the next recipe to try. This is text-in / structured-output. Cerebras lets us do it in real-time during the session instead of as a 30-second cron later. We're piloting this.
Site-rules aggregation. Once per day we distill 100+ trajectories into per-domain recipes. Cerebras turns this from a 20-minute job into a 2-minute job. Useful but not customer-facing.

What This Means for the Broader Browser-Agent Space

A lot of LLM benchmark posts treat speed and cost as the dominant axes. For chat that's true. For browser agents, speed and cost matter only after you've cleared the vision bar. Most of the agents you read about that "do everything on the web" are either:

(a) only tested on news-reading and listicle-extraction sites, where DOM-only works fine, or
(b) using a vision model under the hood and just not talking about it.

If you're building in this space, the question that matters more than "which LLM is cheapest" is: what is your vision rail. Cerebras is a great fast-rail. It's not a vision rail — yet.

Reproducibility

The benchmark code paths are still in our public-facing repo behind HB_FAST_RAIL_API_KEY + HB_FAST_RAIL_BASE=https://api.cerebras.ai/v1. Spin up a Human Browser session with fast_rail: true and fast_rail_model: gpt-oss-120b and run any of the public benchmark goals. Raw session logs and the analysis JSON are available on request — email [email protected].

What's Next

We'll re-benchmark Cerebras the day they ship vision input. In the meantime we're keeping the integration flag-gated as a research path and using their speed for our internal post-mortem pipeline. If you're considering Cerebras for browser automation today: brilliant for text-only flows, not yet usable for general-purpose agents.

For the workloads where vision is non-negotiable (most real customer tasks), we route to Gemini 2.5 Flash Lite (cheap fast-rail) or escalate to Claude Sonnet 4.6 with Computer Use on hostile sites. Full per-model details here.