How agents reach the web, lane by lane.

Lane one: agent libraries drive the browser for you

browser-use, Stagehand, and Skyvern own the whole job. You hand them a goal in plain language, and the model loops: observe the page through a DOM serialization or screenshot, plan the next step, act through CDP or Playwright, and repeat until the goal is done. This is the right shape for open-ended multi-step work, and it is why these tools dominate the space. The cost profile is the loop itself: every step re-reads the page, so context grows with task length, and the model decides each click inside a surface you cannot enumerate in advance.

Ghostget vs browser-use covers the detailed boundary difference.

Lane two: tool servers give your agent browser controls

Playwright MCP and chrome-devtools-mcp keep the agent you already run in charge and expose browser actions as MCP tools. Your agent calls browser_click or browser_snapshot; the page's accessibility tree streams back into its context after each call. Microsoft's own reported benchmark puts a typical Playwright MCP task near 114,000 tokens against about 27,000 for its disk-first CLI sibling, so this lane pays for flexibility in context size. Your harness's permission prompts are the guardrail; the page decides what the agent sees next.

Ghostget vs Playwright MCP covers the token and authority trade in detail.

Lane three: browser CLIs put steering in the shell

agent-browser and the Playwright CLI turn browser control into commands an agent composes: open, click, type, snapshot, eval. The token cost is lower than streamed page state because snapshots land on disk or stdout when asked. The authority question stays open: the agent chooses selectors, coordinates, and JavaScript, so every page it reaches is a place it can act.

Ghostget itself pins agent-browser 0.32.3 as an internal dependency for page captures that need rendering. The agent never reaches it: captures pass through a bounded admission gate, and no Ghostget interface accepts a selector, coordinate, or script. Ghostget vs agent-browser explains how the same engine sits inside the boundary instead of outside it.

Lane four: hosted browsers rent you the machine

Browserbase, Steel, and Hyperbrowser sell managed cloud sessions: parallel Chromium with proxies, stealth, replay, and compliance tiers that lanes one through three run on top of. They answer where the browser runs and at what scale, not what the agent is allowed to do once it is inside one.

Ghostget vs Browserbase covers when hosted sessions are the right tool and when local named operations replace the session entirely.

Ghostget: the agent names the outcome, never the path

Ghostget does not give the agent a browser at any layer. The agent requests a reviewed outcome such as messaging.list or a page read; the kernel binds the exact account, transport, contract version, and risk level; one exchange runs; the result comes back typed and bounded. There is no navigation surface to wander, no selector to guess, and no cookie the caller can exfiltrate. When a service changes shape, the operation fails closed until its contract is reviewed again rather than improvising a new path.

This trades reach for certainty: anything not in the supported action set is unavailable, by design. Public-page reads need no account; a measured article read returns about a tenth of the raw page's bytes, and the homepage shows the numbers.

The same task in each lane

Choose the lane before the tool

If the job is genuinely open-ended, a browser-driving agent earns its context cost. If the job recurs, the fixed contract wins: a named operation is cheaper in tokens, safer in blast radius, and reviewable in a way a thousand improvised clicks are not. Most production agent stacks end up with both: a driver for the long tail, and a capability layer for the paths that must be right every time.

Ghostget is that layer. It publishes no hosted browser, no MCP server, and no agent loop; it supplies the local operations your agent calls from whatever harness you already use.