Why a Cloud Browser With UI Mode Beats Blind Scripts

What “UI Mode” Means in a Cloud Browser

A cloud browser with UI mode gives you a live, interactive view of a session running on a remote server, opened in a tab on your own machine. Instead of a headless script running blind, you watch the real page render, then click and type to take over when it stalls. The session keeps its cookies, open tabs and exit IP, so work resumes where the human stopped.

“UI mode” is vendor naming, not a standard. Floppydata sells UI Mode, Browserbase calls it a session live view, Gologin calls it a Live View link, and Browser.lol streams a remote desktop through Selkies over WebRTC with a WebSocket fallback. Under all four labels sits the same object: a URL, opened in your browser, that renders the page the remote browser is showing and passes your keystrokes back to it.

That URL points at the session your script was using a moment ago — same cookies, same signed-in state, same open tabs, same proxy exit IP. Restarting in a fresh session throws all of it away and hands you a different network path to debug on, which is usually why the failure was hard to reproduce.

Headless, headed and live view are three different things

Much of the confusion comes from headless: false in Playwright. That flag opens a window on your own laptop; the browser still runs locally, on your connection, with your machine’s clock and timezone. It does nothing for a session sitting in a data centre on a residential IP you rented for a reason.

Only the third row survives a handoff, because nothing about your local machine is part of the session. For the wider architecture — what stays on the host and what travels to your screen — our browser isolation guide covers how remote sessions stay separated from the local desktop.

How a Live View Works Under the Hood

A cloud browser with ui mode is the same browser process your script drives, plus a second door into it. The session runs in a container on the provider’s host; the provider attaches a viewer to that process and forwards input into it, which is the mechanism behind every “the session stayed logged in” claim you read.

Two delivery models with different trade-offs

Pixel streaming. The provider encodes frames from the remote browser and sends them over WebRTC, falling back to WebSocket when a network blocks it — the model Browser.lol documents for its Selkies-based viewer. You see everything drawn on screen, including native dialogs. The cost is bandwidth, and the viewer receives pixels only, so you cannot inspect the DOM from it.

Devtools-level view. The provider exposes a URL that proxies the browser’s rendering and input layer. Browserbase publishes a per-tab live view URL in the session’s pages property, so you listen for the new-tab event and collect URLs as tabs open; the views embed in an iframe beside console output, network requests and performance data. Lighter than streaming, but it is the vendor’s own plumbing, so behaviour differs — read the session live view documentation before you build against it.

The concurrency rule decides your architecture

Some providers allow one client at a time. Floppydata’s UI Mode is explicit: a session cannot run an automation connection and a live view simultaneously, and closing one opens the other. Others let both coexist while a person types into a page the script has paused on. Build a handoff that assumes the second model on a provider that implements the first, and your script loses its connection at the exact moment you need it.

Wherever you land, assume one driver. Two people clicking in the same view produce half-submitted forms and state nobody can reproduce later. Browserbase’s mobile views add a wrinkle: keyboards are not officially supported, so you catch key events and forward them to the script, which calls page.keyboard.press(). For the host side, start with what a cloud browser server is and how sessions get provisioned.

Why UI Mode Matters: Where Blind Runs Break

Unattended runs fail in ways log lines cannot describe. A one-time code goes to a phone the script cannot read. A consent screen arrives with wording that changed last quarter. A file upload control ignores synthetic events. A bug reproduces only from one country. Without a view, each of those ends the run, and the restart hands you a new session without the cookie state that made the flow work.

Who ends up using it

• QA teams reproducing a report from a specific region, where the bug is a rendered layout rather than a response code.
• Support teams looking at the exact screen a customer describes, instead of asking for another screenshot.
• Agencies where the client must enter their own credentials — the documented human-in-the-loop case where a view goes to the end user rather than staying in-house.
• Ops teams running checkout flows where a human decision appears mid-flow and a wrong click costs real money.

If your runs are fully deterministic and unattended, you probably don’t need UI mode; you need better screenshots and error capture. It earns its keep where a human decision interrupts the script.

One boundary worth stating plainly: a live view is a window into a session, not a permission slip. Whatever the account’s terms say about who may act still applies once a person is driving, and any verification step belongs to the account owner and goes through the platform’s own process — not a workaround in your runbook.

The Handoff, Step by Step

On an exclusive-attach provider the sequence is fixed. The script disconnects, the live view is requested for the same session ID, the human acts, the script reconnects. Opening the view while the automation client still holds the connection fails, and retrying in a loop just burns billable minutes.

On a simultaneous-attach provider you can leave automation attached, open the tab URL, and let a person type into the page the script has paused on. Simpler in practice, but two clients can write to the same DOM, so have the script wait on an explicit signal — a flag you set, a value it polls — rather than a fixed sleep.

Either way, the human’s work lands in the session profile, not in your code. That is the whole value: the sign-in, the consent record and the cookie jar update in the remote browser, and the next run inherits them without a re-login.

A Checklist Before You Open a Live View

Run through this list before you open a viewer in any cloud browser with ui mode; every item maps to either a bill or a broken handoff.

1. Confirm the concurrency rule from the docs, not from a sales call. Exclusive attach and simultaneous attach lead to different code.
2. Read the session lifetime policy. Know how long a browser survives with no client attached, and whether keep-alive has to be enabled on creation.
3. Budget in money, not minutes. Browser-hours plus proxy gigabytes is the real number; a 20-minute handoff on a metered residential proxy can cost more than the compute.
4. Store the session ID and the view URL together, keyed to the task, so a colleague picking up a ticket doesn’t recreate the session from scratch.
5. Issue the URL per task. One link per handoff, revoked when the session stops, beats a link that lives in a pinned message.
6. Brief the human. Which page they should land on, what to complete, and what not to touch while the script is paused.
7. Decide on recording. Browserbase records session video by default and Browser Use does not; recording helps with audit and gets awkward when credentials are on screen.
8. Re-query page state after the handoff. The DOM is not where the script left it, so look the element up again instead of trusting your last selector.

Common Mistakes That Cost You Sessions and Money

• Treating the viewer tab as the session. Closing your tab does not stop the remote browser. Billing continues until you stop it through the API, and a client-side timeout in your script neither cancels the run nor closes the server browser.
• Posting the live view URL in a shared channel. The link is a bearer credential: in Gologin’s implementation it works only while the session runs, but anyone holding it can open it and act.
• Reading a blank window as a broken session. With several tabs open, the URL you grabbed may point at an empty one. Check the pages list before filing a bug.
• Assuming mobile typing works. Mobile live views follow the viewport, but keyboards are not officially supported; input has to be forwarded to the script.
• Confusing replay with live view. Replay is post-mortem; a live view is the only thing that changes what is happening right now.
• Leaving stale saved profiles behind. On providers that persist profile state, a broken login persists too. Clean up when a profile outlives its task.

What UI Mode Costs and What Drives the Bill

Rates below come from vendor pages and a recent provider comparison, and they move. Treat them as a starting point for a quote, not a contract.

Live view availability is taken from each vendor’s own pages and that comparison, so confirm it on the plan you actually buy before committing.

The per-hour rate is rarely the whole bill for a cloud browser with ui mode. Two multipliers do the damage. The first is parallelism: the same workload at 100 concurrent browsers lands around $352 per month on one provider and $3,168 on another in the published comparison, a gap that comes almost entirely from the hourly rate. The second is proxy traffic, where residential bandwidth runs from $1 to $12 per gigabyte across the vendors above.

Then there is the meter nobody watches: idle time. A session left open after the human closed the tab bills exactly like a working one. If you hand off sessions regularly, the choice between rotating and sticky exit IPs also changes what you pay and what the page sees — we break that down in rotating versus sticky proxy sessions.

Where Send.win Fits

Be clear about the boundary. Send.win is built for people working by hand inside isolated browser profiles, not for machine-driven sessions with a viewer attached. If your workflow is “automation with a live view attached”, pick from the table above and build the handoff around that provider’s concurrency rule.

Send.win covers the other half of the problem — people, not scripts, working inside many isolated browser profiles. You run it two ways. The Sendwin Browser desktop app installs on Windows 10/11, macOS 12+ and Linux and is built on Chromium. The cloud browser runs profiles on Send.win’s server in Helsinki, Finland, from any device with nothing to install. Each profile keeps its own cookies, storage, sessions, fingerprint settings and proxy, so one client’s signed-in state never bleeds into another’s.

The handoff story here is human to human. Share a profile with a paid teammate and it opens already signed in, with no password changing hands. Share a live cloud session when the person who owns the account needs to drive it themselves, and the work happens in the session you prepared rather than in a screen-share of your desktop. Timezone, locale, WebRTC and geolocation follow the proxy’s exit IP automatically, which matters when the account is registered somewhere other than where you sit.

Capacity scales by plan — 150 saved profiles and 6 seats on Pro, 500 profiles and 16 seats on Team, with up to 50 profiles open at once on either and residential proxy bandwidth included on both. Our Sendwin cloud features guide covers the session-sharing side in more detail.

Frequently Asked Questions

What is UI mode in a cloud browser?

It is a live, interactive view of a session running on the provider’s server, opened in your own browser tab. You see the real rendered page and your clicks and keystrokes reach the same browser process your automation uses. Floppydata brands it UI Mode, Browserbase calls it a session live view, and Gologin calls it a Live View link.

Can I take over a running headless browser session?

With providers that support live view, yes — the viewer attaches to the existing session rather than creating a new one. On exclusive-attach providers you disconnect the automation client first, take over, then reconnect. On providers that allow both at once, the script can stay attached while a person acts.

Is live view the same as headful mode?

No. Headful mode in Playwright opens a browser window on your own machine, on your own network and timezone. Live view renders a browser that is still running remotely, so the session keeps its rented exit IP, its remote profile and its fingerprint settings.

Does the session stay logged in after a human handoff?

Yes, because the human acted inside the same remote browser process. Cookies, storage and the signed-in state live in that session, so the script’s next action — or the next run on a saved profile — inherits them. That is why a one-time code completed in the view does not have to be requested again.

Why does my cloud browser keep billing after I disconnect?

Because you disconnected a client, not the server. The remote browser keeps running until it is stopped through the provider’s API or times out under its own policy, and a timeout in your script neither cancels the run nor closes the browser. Set an explicit stop call at the end of every task and check the running-session list afterwards.

Which cloud browser has the cheapest residential proxy?

Among the vendors compared here, Gologin lists $1/GB, Browser Use $5/GB, Steel $6–$10/GB, Anchor $8/GB and Browserbase $10–$12/GB, while Floppydata bills proxy traffic on its own tiers and Kernel does not meter proxies at all. Rates change often, and a low per-gigabyte price can still lose if the session is short and the hourly rate is high.

How do I embed a live view in my own dashboard?

Provider-dependent, but the pattern is an iframe pointed at the session’s view URL, with a listener for the provider’s disconnect event so the UI can show a reconnecting state — Browserbase posts a browserbase-disconnected message for exactly this. Keep the URL server-side and mint it per session, because whoever holds it can act inside the browser.

Does Send.win offer a cloud browser with ui mode?

Yes, for human work. The cloud browser runs each profile on Send.win’s server in Helsinki and you open it in a tab from any device, nothing to install; Pro includes 20 saved cloud sessions with 3 open at once, Team 100 with 9 at once. You can share a live cloud session with a paid teammate so they drive the same remote profile you prepared. It is built for people working inside the session themselves, not for attaching a viewer to a machine-driven run.

Run Cloud Browser With Ui Mode in the Cloud With Send.win

Send.win’s cloud browser runs isolated browser profiles on a server in the EU — open a clean session from any device without installing anything:

• Instant cloud sessions – launch an isolated browser in seconds, no local install
• Isolated profiles – separate cookies, storage and fingerprint settings per session
• Cloud sync & profile sharing – pick up the same profiles on the desktop app (Windows, macOS, Linux) or share them with your team
• Residential proxies included – on Pro and Team, with timezone and locale matched to the proxy

You can try it right now: the Send.win demo browser opens an isolated cloud session directly in this browser tab. Paid plans start at $19/month, with a 7-day money-back guarantee on your first card purchase — see pricing.

Related Products & Resources

• Download
• Demo Browser
• Pricing
• Fingerprint Checker
• Canvas Fingerprint Test