Computer use vs. browser use: which does your agent actually need?

TL;DR: Computer use gives an agent a whole virtual desktop and lets it act by reading screenshots and moving a mouse to pixel coordinates. Browser use gives the agent a browser and lets it act through the page's own structure, its DOM and accessibility tree. Almost every agent task lives on the web, so for roughly 99% of real work you only need a browser. Reach for a full computer only when the task genuinely leaves the browser.

Most agent tasks are web tasks. Booking travel, pulling an invoice, filling a portal, checking a dashboard, reconciling two systems that both happen to be websites. When you sit down to build one of these, you hit an early fork: do you hand the agent a full computer and let it operate a screen the way a person does, or do you hand it a browser and let it drive the page directly? The answer shapes your cost, your speed, and how often the thing breaks.

The two approaches are often blurred together, and the names do not help. So start with what each one actually controls.

What is computer use?

Computer use is an agent operating a full virtual computer the way a human does: it looks at a screenshot of the screen, decides where to click or type, and moves a mouse to pixel coordinates or presses keys. The model perceives the machine visually and acts through raw input events. Nothing about the page's structure is given to it; it sees pixels and produces coordinates.

That generality is the point. A computer-use agent can open a desktop app, drag a file between windows, or operate a site inside a browser it happens to have on screen, all through the same screenshot-and-click loop. The cost of that generality is that every step is a vision inference over an image, and a click is only as accurate as the model's read of where the button is.

One way to wire this up is to hand a computer-use model the browser as a tool: the model runs its own loop over screenshots, and Stagehand carries out the clicks and keystrokes it asks for. Here that is Claude driving a browser through the Stagehand Claude toolset.

import Anthropic from "@anthropic-ai/sdk";
import { StagehandBrowser } from "stagehand-claude-sdk";

// Stagehand drives the browser; Claude runs the tool loop from screenshots.
const browser = await StagehandBrowser.launch({
  headless: true,
  allowedDomains: ["example.com"],
});

try {
  const runner = new Anthropic().messages.toolRunner({
    model: "claude-sonnet-5-5",
    max_tokens: 1024,
    tools: [browser],
    messages: [
      { role: "user", content: "Open example.com and fill out the contact form." },
    ],
  });

  for await (const message of runner) {
    console.log(JSON.stringify(message, null, 2));
  }
} finally {
  await browser.close();
}

What is browser use?

Browser use is an agent operating a browser through the page itself: it reads the DOM and the accessibility tree, finds the element it wants by structure rather than by pixels, and acts on that element directly. Instead of guessing where a button is on a screenshot, it asks the page where the button is and acts on the node. A model still decides what to do; it just acts through structured page handles rather than mouse coordinates.

Because the agent works from the page's own structure, each action is grounded in something real and repeatable. A selector resolves to the same element across runs. Steps that do not need judgement, navigating to a URL, clicking a stable button, reading a table, do not need a model call at all. You spend inference only where the page genuinely needs interpretation.

In Stagehand, this is the native model. You launch a browser, create the instance, and drive the page with natural-language steps like act() and extract(), which resolve against the page rather than a screenshot.

import { browserbase, Stagehand } from "@browserbasehq/stagehand";

const browser = await browserbase.launch({
  apiKey: process.env.BROWSERBASE_API_KEY,
});
const stagehand = await Stagehand.create({ browser });

try {
  const page = await browser.context.activePage();
  await page.goto("https://www.google.com");

  // act() resolves against the page structure, not a screenshot.
  await stagehand.act("type 'Stagehand automation' into the search box");
  await stagehand.act("press Enter in the search box");
  await stagehand.act("click the first result");
} finally {
  await stagehand.close();
  await browser.close();
}

Computer use vs. browser use: the differences that matter

The split comes down to what the agent perceives and how it acts. Computer use perceives pixels and acts by coordinates; browser use perceives page structure and acts on elements. Everything downstream, speed, cost, reliability, scope, follows from that one difference.

When should you use each one?

Pick the smallest surface that covers the task. If the whole job happens inside a browser, a browser is the surface, and handing the agent an entire operating system just adds screenshots, latency, and cost to every step. If the job genuinely needs the desktop, a browser cannot reach it and computer use is the right tool.

Use browser use when

• The task is a web task: forms, portals, dashboards, search, checkout, data pulled off pages.
• You care about cost and speed at scale and want to spend inference only where the page needs it.
• You want runs to be repeatable, so a step that worked yesterday resolves to the same element today.
• You want to drop to plain code for the deterministic steps and keep model calls for the judgement.

Use computer use when

• The task leaves the browser: a native desktop application, an installer, a file dialog, an OS-level setting.
• You are operating software that has no web surface and no API at all.
• You need to coordinate across several desktop windows that are not web pages.

A useful rule of thumb: if you can do the task with a browser open and nothing else, your agent can too. That covers the overwhelming majority of what people actually build agents to do.

Why the browser is enough for almost everything

The web is where the work is. The systems a business runs on, the vendor portals, the admin panels, the booking sites, the internal tools, are almost all websites. An agent that can drive a browser well can already reach them. Adding a full computer underneath does not unlock more of the web; it just makes each web step heavier.

It also changes the economics. A vision inference on every screenshot is the expensive path, and you pay it on every click whether or not the page needed interpreting. Driving the page through its structure lets you skip inference on the steps that are deterministic, which is most of them, and spend it only where a human would actually have to think. At one run that is a rounding error. Across thousands of runs it is the difference between a demo and production.

Running browser agents in production

Deciding you only need a browser is the easy part. Running thousands of real browsers reliably is the part that eats engineering time: keeping sessions alive, handling captchas, giving agents verified access to sites that gate automated traffic, recording what happened for debugging, and scaling concurrency without managing a fleet of machines.

Browserbase is the platform that runs those browsers for you. You get cloud browser sessions your agents connect to over CDP, with session recording, Verified access for sites that gate agents, and concurrency that scales without you provisioning infrastructure. Stagehand, our open-source SDK, drives those browsers through the page, so the act() and extract() calls above run the same locally and in the cloud.

Last updated: October 13, 2026. New to the concept? Start with What's the big deal about computer use? for the full history of how agents learned to operate a screen.