Our thesis is simple: pair one large cloud model that plans, delegates, and verifies with a set of small local models that do the grunt work. The large model thinks a few times per task. The small models act dozens of times per task, at zero marginal cost. Done right, this radically reduces the cost of browser automation while matching the accuracy of cloud-only agents, and your screen never leaves your machine.
Why browser use is the use case that matters
Most of the world's business software has no API. It has a login page. CRMs, supplier portals, admin consoles, government filings, internal tools built in 2011: the universal interface to all of them is a browser with a human in front of it.
That is why browser use and computer use are, in our view, the most important agent capabilities for businesses. An agent that can competently drive a browser is effectively a digital human. In the near term it augments your employees: it fills the forms, reconciles the records, gathers the data, and hands back the judgment calls. Over time, as reliability compounds, it starts to look less like a feature and more like an independent staff member: one that works nights, never forgets a step, and costs a fraction of a salary.
The technology already works. The economics, for most businesses, do not. That is the problem we set out to fix.
Why current solutions are expensive: a short detour into vision
Today's flagship browser agents (Claude's computer use, OpenAI's Operator, and similar) are vision-driven. The loop looks like this: take a screenshot, send it to a cloud API, get back the next action, execute, repeat.
The catch is what a screenshot costs. Models do not see images the way we do. A screenshot is chopped into a grid of patches, and each patch becomes tokens, the same billing unit as text. A typical 1280 pixel wide browser screenshot works out to roughly 1,000 to 1,600 tokens per image depending on the provider's tiling scheme. That is the equivalent of sending several pages of text, every single step, before the model has said a word.
Now multiply. A realistic business task ("find this order in the supplier portal and update the delivery date") takes 20 to 40 steps. Each step resends a fresh screenshot plus the accumulated conversation history, so input grows as the task runs. A 30 step task easily consumes 150,000 to 300,000 input tokens. At frontier model pricing (on the order of $3 per million input tokens and $15 per million output), that is roughly $0.50 to $1.50 per task. Run 200 tasks a day and you are staring at a five figure monthly bill for what is, mostly, clicking buttons.
The expensive part is not the thinking. It is paying frontier prices for pixels, over and over, to make decisions like "click the Submit button."
Our architecture: local hands, cloud brain
We built Local Browser Use, a Chrome side panel agent, around a different division of labor.
Small local models do the acting. All browser actions are planned and executed by models running on the user's own machine via Ollama (our reference hardware is an ordinary MacBook):
- qwen3.5 4B is the step planner. It reads a compact text observation of the page and picks the next action: click, type, scroll, navigate, extract, done.
- Holo1.5 3B, a web-specialized vision model, is the grounder. When an element is not reachable through the DOM (canvas UIs, icon-only buttons), it locates the target on a screenshot and returns coordinates.
These models cost nothing per call. Once the hardware is on your desk, the marginal cost of an action is zero.
One strong cloud model does the thinking. We use GLM-5.2 through OpenRouter as the orchestrator. It never touches the browser. It triages each request, decomposes multi-part tasks, judges outcomes, and writes the final answer. We chose GLM-5.2 because it is the current state of the art among open-weight models (top open score on the Artificial Analysis Intelligence Index and on SWE-bench Pro as of mid 2026) while costing roughly $0.56 per million input tokens and $1.76 per million output. That is around a fifth to a tenth of the latest Claude and OpenAI flagship pricing, for planning quality that is entirely sufficient when the job is decomposition and verification rather than pixel-level control.
Perception is text-first, vision-second. Instead of feeding screenshots to the decision maker, we extract two things from every page: a numbered list of interactive elements (a "set of marks") and the readable page text, viewport first. The planner reasons over a few thousand text tokens instead of an image. Screenshots are still captured every step, but they stay on the machine, used only by the local grounder and saved as training data.
How a request flows
A user request moves through the system like this:
USER REQUEST
│
▼
┌─────────────────────────────┐
│ TRIAGE ☁ GLM-5.2 │
│ chat / execute / plan │
└──────────────┬──────────────┘
│ 2 to 8 subtasks, each with
│ a verifiable success criterion
▼
┌───────────────────────────────────────────┐
│ SUBTASK LOOP (up to 10 steps) ⌂ LOCAL │
│ │
│ perceive: element list + page text │
│ (+ screenshot, kept local) │
│ plan: ⌂ qwen3.5 4B picks an action │
│ ground: ⌂ Holo1.5 3B vision fallback │
│ act: click / type / extract / ... │
│ detect: loops and no-effect streaks │
└──────────────────┬─────────────────────────┘
stuck? │ outcome digest
│ ▼
│ ┌─────────────────────────────┐
│ │ CHECKPOINT ☁ GLM-5.2 │
│ │ continue / replan / │
│ │ done / fail │
│ └──────────────┬──────────────┘
▼ │
┌──────────────────┐ ▼
│ RESCUE ☁ strong │ FINAL ANSWER
│ model diagnoses; │ (or salvage: best
│ retry escalates │ partial answer when
│ the executor: │ budget runs out)
│ local → tier 1 ☁ │
│ → tier 2 ☁ │
└──────────────────┘
│
▼
┌────────────────────────────────────┐
│ TRAJECTORY STORE (all of it) │
│ every observation, decision, │
│ action, correction, tier label │
└────────────────────────────────────┘
Three properties of this flow matter:
Tasks are split into small, verifiable units. The orchestrator never says "go do the thing." It produces subtasks that a small model can reliably finish in under ten concrete actions, each with an explicit success criterion ("the price of X is known"). Small models are unreliable on vague goals and surprisingly solid on crisp ones. The decomposition is what makes 4B-scale execution viable.
Verification is separated from execution. After every subtask, the orchestrator checks the outcome against the plan before moving on. The model doing the work never gets to grade its own homework.
Failure escalates capability, not just wording. The local loop detects when it is stuck (repeating an action, page not changing). A strong cloud model then diagnoses the blocker and the retry runs with a more capable executor: first GLM-5.2 driving the actions directly, then an agentic specialist (Kimi K2.6) if it is still stuck. Escalation is per subtask and temporary; the next subtask starts local again. The expensive models are the exception path, reached only when the free one has demonstrably failed.
The data flywheel
Every step, at every tier, is logged in a typed schema: the observation (element list, page text, and the screenshot that never left the machine), the planner's decision and reasoning, the executed action, the result, and human corrections when the user intervenes.
This gives us three kinds of training signal for free:
- Supervised examples for the local planner and grounder, aligned to standard formats so they are trainable without reprocessing.
- Preference pairs from rejected decisions and human corrections.
- Priority examples from escalations. When a cloud model takes over, we record its actions against the exact observations where the local model failed. That is the highest-value data you can collect: a strong teacher demonstrating precisely the cases the student gets wrong.
Over time this loop should make the local models need escalation less, which makes the system cheaper, which generates more usage and more data. The harness improves the models; the models cheapen the harness.
Privacy comes with the architecture
Because decisions are local by default, privacy is not a policy, it is a data path. Screenshots never leave the machine, at any tier, ever. The orchestrator sees task text and outcome digests. Only when the cloud executor fallback is enabled (a user toggle) do element labels and page text cross the boundary, and even then it is text only. Your logged-in sessions, your customers' data on screen, your internal tools: none of it is uploaded as pixels to anyone's API.
The costing
Illustrative arithmetic for a typical 30 step business task:
| Cloud vision agent (frontier model) | Local Browser Use | |
|---|---|---|
| Who acts | Frontier model, every step | Local models, $0 |
| Vision tokens sent | ~1,000 to 1,600 per step, 30 steps | Zero |
| Cloud tokens per task | ~150k to 300k input, ~5k output | ~10k to 20k (triage, checkpoints, final answer) |
| Cloud model price | ~$3 / $15 per M tokens | ~$0.56 / $1.76 per M (GLM-5.2) |
| Cost per task | ~$0.50 to $1.50 | ~$0.01 to $0.02 |
| Hard task with escalation | same | ~$0.05 to $0.10 |
| 200 tasks/day, monthly | ~$3,000 to $9,000 | ~$60 to $120 |
Call it a 50x to 100x reduction on typical workloads, with the gap widening as the local models improve and escalate less. Accuracy on everyday tasks is comparable, because the hard reasoning still goes to a state of the art model; we simply stopped paying frontier prices to click buttons.
The pattern generalizes beyond browsers: a big brain for orchestration and judgment, many small hands for execution, and a data flywheel that shifts work from the paid tier to the free tier over time. We think this is what the economics of digital labor will actually look like.