Agentic Browser: Which Kind You Need and When an Agent Skips It

Give your agent a way to read a web page, and learn whether it needs a real browser session. Paste this into your agent:

Set up https://monid.ai/SKILL.md, and then use Monid to read https://example.com as markdown, tell me what came back and what it cost, and say whether that page needed a browser session or a plain fetch.

One prompt reads a page without a browser. 1 min setup · 6-16 hrs saved.

You keep seeing "agentic browser" and the results disagree about what it is. Some pages sell an app you install and sit in front of. Others describe a remote browser your code opens, drives and closes. This guide separates the two, explains how the loop inside either one works, shows how to rent a session from your own code, and tests the question that decides whether you need one: does your task carry state? Two live runs on 2026-10-16 show what a plain page read looks like. It runs through Monid, the OpenRouter for agent tools: one key, one balance, every tool priced for what you run.

What is the easiest way to give an agent a browser?

Monid. Install it once, add a key, and your agent can discover browser-session endpoints, read their schema and price for free, and call them when a task needs one. There is no browser fleet to build and no separate vendor account to open first.

• Pay for what you run. Each call is billed on its own, and discovery and inspection are free. Buy calls as you need them: no monthly plan and no minimum top-up. A page read through the Context.dev markdown endpoint is $0.002533 a call (Verified 2026-10-16 on the agents tools page). Browser-session endpoints bill by session time, covered below.
• One install, many browsers and fetchers. The same key and balance reach a session endpoint, a fetch endpoint and a scraper. Your agent picks the lightest one that does the job.
• Lives inside your agent. Your agent reads SKILL.md, learns the discover, inspect, run loop, and calls the endpoint when it needs it. Setup is about a minute.

The rest of this guide is how to choose between a session and a fetch.

What is an agentic browser, and why does the term mean two things?

An agentic browser is a browser where a model takes actions instead of only rendering pages. That one definition covers two products with almost nothing in common, which is why the results for the term read as if they were about different subjects.

The consumer agentic browser

This one is an application. You install it, browse as usual, and ask an assistant to act on the tab in front of you: summarise it, fill it in, compare these and add one to the cart. Perplexity's Comet and OpenAI's Atlas are the names people usually mean. The agent shares your session, which is the point and also the risk, because it is already signed in to whatever you are.

The buyer is a person, and the product is convenience. Most of the autosuggest for the term sits here: for Windows, for Android, free.

The programmable agentic browser

This one is infrastructure. It is a headless Chrome running somewhere else that your program connects to over the Chrome DevTools Protocol, drives with Playwright or Puppeteer, and shuts down. There is no user, no personal session and no interface. The rest of the autosuggest sits here: automation, GitHub, open source.

The buyer is a developer, and the product is a browser they do not have to operate.

Why the split matters

Every follow-up question resolves differently depending on which one you meant. "Is it safe" is a serious question about the first and a smaller one about the second, since a throwaway session holding no credentials has little to leak. "What does it cost" is a subscription question for one and a session-time question for the other.

The consumer version borrows your identity and the programmable one deliberately has none. The rest of this guide is about the second.

How does an agentic browser work?

Both kinds give a model a loop: look at the page, decide on an action, perform it, look again. What differs is where the page comes from and what the model may touch.

The loop, concretely

The model receives a representation of the current page: the accessibility tree, a simplified DOM, a screenshot, or a mix. It emits an action such as click this element, type this text, scroll or navigate. A runtime performs the action against the real browser and returns the new state. This repeats until the goal is met or a step budget runs out.

Most of the engineering is in the representation. A full DOM is too large for a context window and a screenshot alone loses element identity, so every product has its own way of compressing a page into something a model can reason over.

The weak point of the loop

The loop treats page content as information, and a model reading a page cannot reliably tell that content from its own instructions. That is indirect prompt injection. Brave's security team published two posts on it: Agentic Browser Security: Indirect Prompt Injection in Perplexity Comet and Unseeable prompt injections in screenshots, the second covering Comet and other AI browsers.

The lesson holds for any browser you give a model. Keep credentials out of the session by default, add them per task, and treat anything that arrives through page content as data rather than a command. A fresh programmable session starts that way.

What a browser buys you

Strip the loop back and a browser gives you two things a fetch does not: it executes JavaScript, and it holds state across requests. Everything else is overhead. The section after next puts that to a test.

How do you use an agentic browser from your own code?

Open a remote session, attach your automation library to it, and treat it as a resource with a lifetime. Renting the browser means no driver to keep in step, no memory per tab on your machine and no pool to build when you need five at once. Running the browser yourself is the other route, and Python web scraping without a scraper covers where that stops being worth it.

For agents

Grab an API key at app.monid.ai, then paste this to your agent and hand it the key:

set up https://monid.ai/SKILL.md

It learns the whole discover, inspect, run workflow itself. More in the agent quickstart.

For humans

npm install -g @monid-ai/cli
monid keys add -k <your-api-key> -l main

Step 1. Open a session

What it does. Creates a remote browser on Browserbase and hands you the address to connect to.

The endpoint. x402.browserbase.com/browser/session/create.

The call.

monid inspect -p x402.browserbase.com -e /browser/session/create

monid run -p x402.browserbase.com -e /browser/session/create -w -i '{"estimatedMinutes":5}'

What the schema says. The live schema takes one body field, estimatedMinutes, a number you must supply: how long you plan to use the session. The listed price is $0.011 per call (Verified 2026-10-16). The endpoint bills by session time, so we ran inspect and did not run it for this guide.

Step 2. Drive it with Playwright

What it does. Connects your existing automation code to the remote browser instead of a local one.

The endpoint. None. This is your code connecting over CDP to the address Step 1 returns.

The call.

import json
import subprocess
from playwright.sync_api import sync_playwright

session = json.loads(subprocess.run(
    ["monid", "run", "-p", "x402.browserbase.com",
     "-e", "/browser/session/create", "-w", "-j",
     "-i", '{"estimatedMinutes":5}'],
    capture_output=True, text=True, check=True,
    env={"NO_COLOR": "1"},
).stdout)

with sync_playwright() as p:
    browser = p.chromium.connect_over_cdp(session["connectUrl"])
    page = browser.contexts[0].pages[0]
    page.goto("https://example.com")
    print(page.title())
    browser.close()

The session response carries the connection address under connectUrl. Once connected, every selector, wait and assertion you already wrote works unchanged, which is the reason to use CDP rather than a bespoke API.

Step 3. Close it

What it does. Ends the session so the meter stops.

The call. browser.close() in a finally block, or a context manager. For a TinyFish session the matching call is /browser-sessions/release, which the endpoint text calls the only way to stop paying for an idle-open session before its timeout.

Sessions that leak are the main way browser work gets expensive, and they leak when an exception skips the cleanup.

Does your agent need a browser at all?

Often not, and the test is one question: does the task carry state across requests? Logins, carts, multi-step forms and wizards do. Reading a page does not, and reading a page is most of what agents do on the web.

We ran the stateless case twice on 2026-10-16, on https://example.com.

monid run -p tinyfish -e /fetch -i '{"urls":["https://example.com"],"format":"markdown","ttl":0}'

monid run -p context.dev -e /web/scrape/markdown \
  --query '{"url":"https://example.com","useMainContentOnly":true,"waitForMs":1000}'

The TinyFish fetch came back in about two seconds with the listed price at zero. Each result carried url, final_url, title, description, language, text, author, published_date, latency_ms and format; here title was "Example Domain" and description, author and published_date were null. The Context.dev scrape took about a second, billed $0.002533 (Verified 2026-10-16), and returned markdown, contentLength, a metadata object, cache_metadata and finalDOMState. That cache metadata showed a cached copy about 34 minutes old, so set maxAgeMs to 0 when you need a fresh read.

Neither run opened a session, and neither needed one: the page text was in the response. Compare that with a session, where you pay for time, write driving code and clean up afterwards, and the question becomes whether the task needs what only a session provides. When a page is behind a login or a wizard, it does. When it is a page to read, a fetch endpoint is the lighter tool, and searching first, then reading the pages uses that same free fetch.

If the site publishes an API, use that instead of either, and if it does not, check the catalog for an existing endpoint before you write browser code. Driving a browser against a service with structured data is the slowest way to get information that was available directly.

What goes wrong when you rent a browser by the minute?

The costs are time-shaped, so the failures are too. The TinyFish provision endpoint states them in its own inspect text, and Browserbase's takes a time estimate as a required input.

Idle time costs the same as active time

The TinyFish text says billing is per minute of wall-clock session lifetime, idle time included. An agent that opens a session, thinks for ten minutes and then clicks twice has paid for ten minutes. Plan the work first, then open the session.

Sessions you forget keep running

TinyFish sessions end on an inactivity timeout set by timeoutSeconds, between 5 and 86,400 seconds, which the endpoint tells you to keep as short as the workflow allows. Release explicitly when you finish. The release call is one-shot per session: a second call with the same id returns a 404.

Estimates are inputs, not guesses

Browserbase's create endpoint requires estimatedMinutes. Treat it as the budget you hand over, not a number to round up for comfort.

Creation is slow

TinyFish notes that creating a session can take 10 to 30 seconds. A task that opens a fresh session per page spends most of its time waiting, so reuse one session for a sequence of steps.

Which endpoint should I use for which job?

The rows were read with monid inspect on 2026-10-16; the fetch and markdown rows were also run, and the session rows were not. The table gives the billing shape rather than a figure, because the shape changes your design and a number goes stale. Current figures are on monid.ai/tools.

When is another route a better fit?

You are the person browsing. A consumer agentic browser suits a person who wants help with the tabs they have open, and nothing here argues otherwise. Choose it for yourself, and decide deliberately which tabs it can see.

You run browsers all day. Rented time adds up with steady load. If sessions run all day, a browser pool you operate yourself, or a flat plan from a browser vendor, may fit your volume better. Work out your minutes before you pick.

You need a site's data and nothing else. If the data you want is on an API or a listing endpoint, skip both session and fetch.

You want full control of the browser. A session you rent gives you less to tune than a browser you configure. If you need custom extensions or a fixed fingerprint, run your own.

And the disclosure: we resell these endpoints.

Conclusion

An agentic browser is either an app you sit in front of or a remote browser your agent drives, and the second is the one to rent through Monid: one key for session endpoints, fetch endpoints and scrapers, calls bought as you need them with no minimum top-up, and usable from inside your agent. For a page read, $0.002533 a call (Verified 2026-10-16) or a zero-listed fetch is the lighter tool.

Two things matter more than the vendor. State decides it: if the task needs a login, a cart or a form, open a session, and otherwise fetch. And time is the bill: open a session late, close it early, and keep credentials out of it by default.

How we estimated the time saved: standing up your own remote browser handling, with the driver, the session lifecycle, cleanup on failure and a pool for parallel work, is roughly 6 to 16 hours for a first working version. The 1 minute is the install, key and first call once you already have a Monid key.

Free next step: run monid discover -q "headless browser session", monid inspect the top rows next to the markdown scrape endpoint, and compare the schemas. Start at monid.ai.

FAQ

Published August 2026.