3.8x Faster Browser Use: Gemma-4-31b on Wafer-Scale Silicon and a One-Page Playbook

Abstract. Fast inference just reached models that can see. On Cerebras hardware, gemma-4-31b, a 31-billion-parameter open model from the Gemma family, reads a full screenshot and picks its next browser action in about a second (it is multimodal: it takes images as well as text). In browser-navigation tests it matched Claude Sonnet 5 on accuracy while generating tokens 17 to 39 times faster, and with a one-page playbook it cleared five multi-hop lookups in 10.4 seconds, reading a screenshot at every step. It is less careful: on one hard lookup it read the wrong number off the page with full confidence. The fix is a division of labor. Distill a playbook once with a careful model, run it with the fast one, and spend the speed surplus on self-checks. On tasks like these, that is faster than a person clicking the same pages.

One task, three ways: the tungsten lookup Bar length is total time · notches divide it into steps · same correct answer all three ways

Figure 1. The tungsten lookup, one of the five tasks. Without a playbook the fast model wanders through 10 steps and still finishes ahead of Sonnet. With the playbook it takes the same 2 steps Sonnet does and finishes in 2.2 s against Sonnet's 7.0 s on the matching run. Both playbook runs also fed each model a screenshot per step; Sonnet without the playbook took 11.6 s. Sonnet is shown at its best. Notches split bars into equal step counts (per-step times within a task are approximated as equal).

Contents. Key results · The test · Speed, with vision · Failure modes · The playbook method · Implications · Limitations · Open questions · Methods

Key results

A capable model that can see is now fast enough to watch the screen on every step. In the screenshot-enabled runs, gemma-4-31b read the rendered page as an image at every step and still averaged about a second per action. With the playbook it cleared the five-task suite in 10.4 s (Figure 1 shows one task). Real-time vision used to be too slow to run each step. It is not anymore.
Raw speed shrinks as planning waste compounds. On the text-only baseline the small model was about 24x faster per token and 5.6x faster per step, but only 1.9x faster per task, because it wandered through three times as many steps.
The failure modes are opposite. On four lookups no model has memorized, both scored 3 of 4. The fast model read 115 m as 120 m, confidently. The careful model circled a hard search for 103 seconds and never answered.
A one-page playbook, plus per-step screenshots, cut its steps from 30 to 10 and left it about 3.8x faster per step than Sonnet on the same tasks (Figure 2). Both models converged on nearly the same rules, and the same page ran on both unmodified.

Per-step speedup with the playbook Relative to Sonnet 5's average step time · each dot is one task · the large dot is the mean

Figure 2. Playbook rerun: the same five tasks, both models given the same playbook and a screenshot per step, every task solved in 2 steps by both. Step times are normalized to Sonnet's average, so Sonnet's own spread sits around 1x (0.8 to 1.1x). gemma-4-31b lands between 2.7x and 4.7x, mean 3.8x, the number in the title; suite totals 10.4 s vs 39.7 s. The 30-to-10 step cut is the combined effect of playbook plus screenshots (see Open questions).

The test

The agent is a loop. The model writes one action, a browser runs it, the model sees the result and writes the next action. The loop has a name in the literature, the ReAct pattern (reason, then act), and its key property is that every step needs a fresh read of the page.

Each turn, the model receives the current page as the URL, a slice of the visible text, and a numbered list of every clickable element, plus, in the screenshot-enabled runs, an image of the rendered page. It replies with one action as structured data: click element 14, type into the search box, or finish with an answer. A headless browser (Chromium with no visible window) runs the action and the loop repeats until the model finishes or hits the 14-step limit.

The whole thing is about 150 lines, deliberately simple so the model does the reasoning. The only thing that changes between runs is which model answers, so the comparison is on identical work.

Two terms carry the rest. Wall-clock is real time, start to finish. Throughput is tokens generated per second, a token being roughly four characters. High throughput can still lose on wall-clock if the model takes more steps, so watch both.

Speed, with vision

The baseline was five multi-hop Wikipedia lookups, text-only. Find the atomic number of tungsten. From the Apollo 11 article, find the command module pilot, then his birth year. Each takes several reads and clicks to do honestly, though a model that already knows Wikipedia can shortcut some of it, which is why the harder suite below exists. Both models solved all five. The small one finished the suite in half the time, 24x faster per token, and Figure 1 shows the shape of it on one task. The speed has a one-sentence explanation: Cerebras keeps the whole model in memory on one large chip instead of streaming weights across a narrow connection for every token, the bottleneck on a normal GPU. Details in the 10,000-tokens-a-second piece.

Speed is half of it. The other half is that this fast model can see. Most computer-use agents read the DOM, the page’s underlying HTML structure, rather than the picture on screen, because processing an image used to be too slow to do every step. The reason a screenshot is affordable now is prefill: models read input much faster than they write output, so a large image goes in quickly even when writing speed is modest.

A full screenshot is on the order of a thousand image tokens, which gemma-4-31b absorbs in about a second. In the screenshot-enabled runs (the playbook rerun and the hard suite) both models got the rendered page as an image on every step, and it barely moved the clock: per-step time went from 0.76 s text-only to roughly a second with images. When looking at the screen costs a second instead of ten, the agent can watch the pixels a person sees instead of reading the HTML and hoping the HTML is complete.

The HTML is often not complete. A drawing canvas, a chart, a PDF, a legacy desktop program, a login field built so its text is not in the markup: the screen has the answer and the DOM does not. Where this lands first:

Browser automation on sites where reading the HTML fails. If a field only exists as pixels, a seeing agent still finds it.
Visual quality checks. Have the agent look for the layout that broke or the chart that rendered empty, cheaply enough to run on every code change.
Legacy desktop software, where there is no clean structure to read, only a screen. A lot of slow, repetitive office work lives here.

Failure modes

To test reading rather than memory, I swapped in lookups whose answers no model has memorized: maximum elevations of tiny French communes, pulled from their infoboxes. Both models scored 3 of 4, and the misses point in opposite directions.

gemma-4-31b: reads fast, reads wrong

On one commune it reported 120 m. The infobox says 115 m.

It took a nearby number off the page and returned it in about seven seconds. The error was in the reading, not the search, so speed did not help.

Sonnet 5: reads carefully, gets stuck

On the commune named "Y," it hit the 14-step limit after 103 seconds without answering.

It reads carefully, but on a hard search it goes in circles, and at frontier writing speeds that compounds into minutes.

Figure 3. Same 3-of-4 accuracy on the hard suite, opposite failure modes.

The fast model is confident and, once here, wrong. The careful model is right and sometimes stuck. On the hard suite the wall-clock gap widened past six times, because hard tasks take more steps and the slow model pays its rate on each one. Which failure you can tolerate depends on the job, and neither shows up on an easy benchmark where both models look perfect.

The playbook method

Both weaknesses have a cheap fix with the same shape.

After the baseline, I asked each model to look back at its own runs and write the shortest path for this kind of task. Both produced nearly the same rules without seeing each other: go straight to the article, read the summary box at the top, stop as soon as the fact is on screen, skip index pages. I distilled them into one page and put it in the prompt. Steps fell from thirty to ten at the same accuracy, about 3.8x Sonnet’s per-step pace (Figures 1 and 2). Two honest qualifiers: that rerun also added per-step screenshots, so the cut is their combined effect, and on tasks this easy the fast model could have authored its own rules. The division of labor, careful model distills, fast model runs, is the version that scales to work where it cannot.

The idea has a name, Reflexion (Shinn et al., 2023): an agent reflects on its own mistakes in plain language and keeps the lessons as text instead of retraining. The lesson here is a page you can read, edit, and version, and the same page ran on both models unmodified.

Reading errors get a different fix, and speed is what pays for it: at over a thousand tokens a second, the agent can read a value two or three times and take the majority, and still return before one Sonnet call. That fix is proposed, not yet tested. Until it is, the honest claim is this: the pairing does screen work of this shape faster than the person doing it now, and the reliability step is designed but unproven.

Implications

If you build with AI. Composition beats selection. Do not ask which model your agent should use; assign roles. Three things follow from the numbers.

Skills become artifacts. The playbook is a text file in version control: readable, diffable, shareable. It ran on both models unmodified here, so carrying a skill library across models, or to next year’s models, is cheap.
Careful agents become affordable. Re-reads, second opinions, verify-before-submit were always good engineering, but too slow and costly at frontier prices. At a thousand-plus tokens a second they cost almost nothing. One caution from this data: the playbook measurably fixed planning, while the reading fix is still a proposal. Know which of your mitigations are measured.
About a second per action changes the product. That is an agent you watch and interrupt, like a colleague sharing a screen, not a batch job you wait on.

If you have screen work. Most business software has no API: the insurance portal, the county records site, the fifteen-year-old ERP. An agent that operates software by looking at it skips the integration project, because it uses the same interface you do. The playbook is something operators already know, a standard operating procedure: an experienced hand writes the steps once, a fast worker follows them all day. Here the SOP is a page of plain text your bookkeeper can audit, and the fast worker, reading a screenshot at every step, cleared five multi-step lookups in about ten seconds. The same clicking by hand is minutes, every day. One line belongs in the SOP itself: the model can read a number wrong with full confidence, so end the procedure with a verification step or a human spot-check until self-checking is proven.

Limitations

Small samples. Four to five tasks per configuration, one pass each. Read 3 of 4 as a direction, not a measurement.
Confounded variables. The playbook rerun added the playbook and screenshots together; the hard suite added a persistent session on top. Isolation runs are next.
The read-and-vote fix is untested. I have a reason to think it catches the misreads, not evidence.
“Faster than a person” is narrow. It holds for simple lookups, and says nothing about judgment work.
Wikipedia is friendly terrain. No anti-bot walls, clean pages. These numbers are a floor on difficulty.

Open questions

Does read-and-vote actually catch the misreads, and how many reads does it take?
With the variables separated, how much does per-step vision help versus the playbook versus the persistent session (the run where lessons carried between tasks)?
How far does one distilled playbook carry across tasks, and across models, before someone has to write a new one?
On software with no clean DOM, how much does watching the screen beat reading the markup, measured rather than argued?

Cheap eyes, fast hands, and a careful teacher whose lessons are a page of text. That is the combination these numbers point at, and the isolation runs will say how much each part carries.

Methods

Agent: one ReAct-style loop in Node driving headless Chromium via Playwright. Per turn: page URL, truncated text snippet, indexed interactive elements, and, in screenshot-enabled runs, a JPEG screenshot. One JSON action out (click, type, navigate, finish). Step limit 14. Identical code for both models.
Models: gemma-4-31b via the Cerebras API (the exact id its /v1/models endpoint returns). Claude Sonnet 5 (anthropic/claude-sonnet-5) via OpenRouter. Temperature 0.2. Cerebras rate-limit responses retried with backoff and excluded from latency.
Runs: warm-up (1 task); easy suite (5 tasks, text-only); playbook rerun (same 5 tasks, playbook plus per-step screenshots, both models); hard suite (4 un-memorizable tasks, persistent session plus playbook plus screenshots). One pass each.
Scoring: one ground-truth answer per task, matched by regex on the final response. The commune elevations were locked from raw Wikipedia infobox values before the runs.
Throughput: completion tokens over provider-reported generation time where given, else measured latency. Browser action time was under 10% of every run.

Rich Valente is the founder of Valente Labs. He works with operators who are done demoing AI and ready to run it. valentelabs.ai