Remote browser on VM0
A real browser the agent drives and you can watch or take over, with a live link and a sign-in that outlasts the run.
Runtime · No setup · No per-call charge; included in the run
Plenty of important systems have no other way in. An internal admin panel, a supplier portal, a booking system, a regulator's filing site. The only interface is a browser, and until now that meant a person clicking through it.
The remote browser gives the agent a real one, and gives you a link to watch it work. You can take over with your own keyboard when it reaches something only a person should do, like typing a password. The window belongs to the conversation rather than to a single run, so it stays signed in and tomorrow's work picks up where today's stopped.
What Remote browser is
Scraping reads a public page. This is for everything else: pages that need a sign-in, a click, a form, or something that only happens in a real browser.
What makes it different from a browser hidden inside a sandbox is that you can see it. Ask for the browser and you get a private link to the live window, so you can watch what the agent is doing and put your hands on it when you need to.
The window outlives the run. VM0 takes it back after ten idle minutes, and a long task can keep it open. Even after it is taken back, the next run can pick it up still signed in, so a login is not lost the moment a run ends.
The market calls this a remote browser, a cloud browser or a browser automation service, and the usual versions are headless: fast, invisible and impossible to help when they get stuck. This one has a live link, so a person can watch it and take the keyboard.
What Remote browser can do
What an agent can do with it, and what comes back when it does.
Coverage and limits
What it does not do, said up front, so nobody plans a workflow around something that is out of scope.
One live window per conversation
Asking for the browser returns this conversation's window rather than opening a new one, which is what lets a later run carry on in the same place. A second one is something you ask for deliberately.
Ten idle minutes
An idle window is taken back. A long task that leaves it waiting can keep it open, and a window that was taken back can be resumed still signed in.
It remembers the login, not the tabs
Resuming brings back the signed-in state, not the exact tabs that were open. A workflow should navigate rather than assume.
Passwords stay out of the run
Browser credentials and connection links are never printed into the run. A person signs in through the live window, and the agent works with the session that results.
What Remote browser costs
Web services are billed in credits per call, not per token. There is no separate vendor bill to reconcile.
zero browserThere is no per-call charge for driving the browser. It comes with the run rather than being metered, so what it costs is the run itself, and the number to watch is how long a browser task keeps an agent working.
Setup and access
Nothing to set up
Nothing to connect. No browser infrastructure, no proxies, no separate provider account. Asking for the browser is the whole setup, and the first sign-in is done by a person in the live window.
Who can use it
The browser comes with the run, so the real control is what gets signed into it. Whatever a person signs in to through the live window is what the agent can then reach, which is exactly why the sign-in happens there and never through a password typed into a message.
What teams use Remote browser for
Systems with no other way in
Supplier portals, internal admin tools, government filing sites. The agent does the repetitive navigation and hands control back for the parts that need a person.
Watching a flow end to end
Walking your own signup, checkout or onboarding in a live window, with someone able to interrupt, tells you far more than a script reporting a green tick.
Work that spans days
Because the window belongs to the conversation, an agent can sign in today and tomorrow's run continues in the same place instead of starting from a signed-out browser.
When not to use Remote browser
Skip it when a public page is all you need, where reading the page is one step instead of a whole session. Skip it when the system has a connector, which is faster and far steadier than clicking through its interface. And do not use it to work through hundreds of pages: it is a browser, not a bulk reader.
What this is called elsewhere
The same thing goes by several names in the market. If you have shopped for one of these, this is how it maps to what you get here.
Remote or cloud browser
A browser running somewhere else that your agent drives. The difference here is that you get a link to watch it and can take over with your own keyboard.
Headless browser
The usual way agents browse: no window, nobody watching, nothing surviving the run. This is the opposite, which matters the moment a page asks for a code from your phone.
Browser automation
Clicking through a system that has no other way in. The agent reads the page it is actually on rather than replaying a recorded script that breaks when the layout moves.
A hosted browser session service
What you would otherwise buy separately and wire up. It is already here, needs no account of yours, and adds no per-call charge.
AI browser agent
An agent that uses a browser as a tool rather than a scripted bot. It decides what to click, and hands control back when something needs a person.
Remote browser compared
Remote browser vs reading a page
Reading is a single step that returns the text of a public page. The browser is a session with state that can sign in and click, and it is correspondingly heavier. Read first, and escalate only when the page demands it.
Remote browser vs a browser hidden inside the sandbox
An agent can drive a browser nobody can see, and nothing about it survives the run. This one has a live link a person can take over and a sign-in that outlasts the run.
Remote browser vs an automation tool that records clicks
Recorded scripts break the moment the interface moves. Here the agent reads the page it is actually on, and a person can step in part way through instead of re-recording everything.
The short version
The way in when a browser is the only way in. Read the page for public pages, use a connector where one exists, and use this when the work needs a sign-in, a click, or someone watching.
Frequently asked questions
Can I watch what the agent is doing?
Yes. You get a private live link, and you can take over with your own keyboard and mouse part way through.
How long does the window last?
It survives the run and is taken back after ten idle minutes. A long task can keep it open.
Does it stay signed in?
The sign-in is kept, so a window that was taken back can be resumed still signed in. Open tabs are not restored, so a workflow should navigate explicitly.
How do logins work?
A person signs in through the live window. Browser credentials and connection links are never printed into the run, and passwords should never be typed into a message to the agent.
When should I use this instead of reading the page?
When the page needs a sign-in, a click, a form, or something that only works in a real browser. For a public page, reading it is one step and much cheaper.
Can I have more than one browser?
Yes. A second window can be opened when a task needs two contexts at once, and it shares the same saved sign-ins.
How is this different from a hosted browser service I would buy?
You would otherwise create an account, hold a key and pay per session. This comes with the run, needs nothing set up, and adds a live link a person can take over, which most of those do not.
Do I need Playwright, Puppeteer or a script?
No. There is nothing to write. The agent works from what is on the page, which is why it survives the redesigns that break recorded scripts.
Is it a headless browser?
No. It is a real browser you can watch and take over, and the sign-in it holds outlasts the run. Headless is what you get when nobody needs to see it, and it is the wrong shape for anything that asks for a code.
Can it run on a schedule?
Yes. A scheduled agent can pick up the same window it used yesterday, still signed in, which is what makes a weekly download from a portal work without someone doing it by hand.
How you ask for Remote browser
You describe what you want in plain language. The agent works out which service it needs and makes the calls.
“Open a browser, go to our pricing page, and walk through signup to the first paid step so I can watch.”
“Sign in to the supplier portal, download this month's invoices, and hand control back if it asks for a code.”
“Carry on in the same browser as yesterday and finish the remaining submissions.”