unbrowseYour agent's cloud browser wakes up a stranger.
New machine. Datacenter IP. No cookies, no history, no saved logins. It lands on a site, and the site does what sites do with strangers from datacenters: a CAPTCHA, a "verify it's you" email, or a polite 403.
Meanwhile, on your desk, there's a browser that has been signed in to your email for years. It sits on your home connection. It passed every 2FA prompt months ago.
You're reading this in it.
I'm Lewis Tham, founder of Unbrowse and first author of "Internal APIs Are All You Need". We pay for cloud browsers every month, and I've come round to a position that's bad for that line item: the best browser for your agent is the one already open on your machine. Ours should be the fallback.
Sites trust your browser because they've met it
Here's the same site from two machines:
cloud browser your browser
------------------------------------------------------
network datacenter IP home IP
history none years
signed in no yes
2FA texts your phone passed long ago
session copied in issued to this device
------------------------------------------------------
first impression a bot you
Datacenter addresses are easy to spot and cheap to block, and plenty of sites challenge them. Since July 2025 Cloudflare blocks AI crawlers by default on new domains. A cloud browser doing a task for you looks a lot like that crawler from the outside.
Logins are worse. A cloud browser signing in as you triggers the same alarms as a stranger signing in as you, because from the site's side it is one. New device, new location, new prompt on your phone, mid-task, while you're in a meeting.
And sessions are moving onto the device. Chrome on Windows now ships Device Bound Session Credentials for Google accounts: the sign-in is tied to a key on the machine that created it, so a cookie copied to a server stops working.
Your browser has none of these problems. The site already knows it. It's the most trusted client your agent will ever get, and it's sitting idle in a tab.
Your browser would cost us nothing
The First Call Is the Expensive One did the money: learning a route costs about what a browser agent costs, so whoever runs the browser pays for the first call. When that browser is yours, the bill to us is $0.
So the split we want to move to is simple.
Free is your browser. Paid is our browsers, when yours is off.
That is a plan, not our pricing. Today Unbrowse is free during the beta, up to 500 verified calls a month, and after the beta it's $10 per 10,000 verified calls, whichever browser did the work. Moving the free line to "your browser" is where we want to go, and the rest of this piece is how it would work.
One program, two browsers
The design is a single program on your machine. We call it a node. It would do four things.
It runs real Chrome, in its own profile, with two contexts. Its own profile, because current Chrome refuses remote automation of your default one. One context is persistent and signed in: that's "you", used for your tasks on your accounts. The other is clean and cookieless: that's "index", used to learn public routes. Learning a public search in a context that has never seen your cookies means there's nothing of yours to scrub before the route goes to the shared registry.
It keeps your passwords in your OS keychain. Today Unbrowse's vault is server-side, sealed per workspace. The node would move sign-in to your machine, so your password never has to leave it.
It speaks local MCP and a CLI, so an agent on the same machine calls it directly.
It dials out. The node opens an outbound connection to Unbrowse, so a cloud agent can reach your browser without you opening a port, forwarding anything, or owning a static IP.
cloud agent ── MCP ──> unbrowse.ai
^
| outbound connection
| (no open ports)
local agent ── MCP/CLI ──> your machine: unbrowse node
├─ "you" signed in, persistent
├─ "index" clean, no cookies
└─ keychain passwords stay here
Where the cloud still wins
Your browser has one big weakness: it's yours, so it goes where you go.
laptop closed your browser can't help
agent runs on a server nowhere near your machine
job runs at 3am you're asleep, so is Chrome
first try, nothing installed no node yet
That's what the paid tier would be for: our browsers are always on, headless, and need no install. You'd be paying for the hours your browser isn't around, which is a much easier thing to charge for than the hours it is.
It also keeps the economics honest. Our cloud browsers stop being a subsidy for every first call on the internet and become a product people choose when they need it.
Where this actually is
Be exact, because this piece describes more than we've shipped. Status as of 12 October 2026:
live replay over HTTP, the public registry, the
remote MCP server, and our cloud browser for
sites nobody has learned yet
live vault is server-side; pricing is free in the
beta (500 verified calls a month), then $10
per 10,000 verified calls
testing local browse: a cloud agent drives a fresh
browser on your machine through the CLI, from
your connection. The service side exists; the
released CLI doesn't include it yet
built browser extension relay: agent calls run
through your own Chrome. Not yet on in production
merged the node's outbound link to Unbrowse (merged
12 Oct 2026). Not in production
plan the node itself: two contexts, keychain
passwords, local MCP
plan "free is your browser, paid is ours" pricing
The node is a plan, and I'd rather build the version people will actually install. If you have a view on what it would have to do, or never do, before you'd put it on your machine, that's the input we need now.
It's one MCP server today: unbrowse.ai/mcp. Setup is in the docs.
The plan is simple to say: free is your browser, paid is ours, for the hours yours is asleep.