I spent an hour last week on the Yamak thread on Hacker News, where half the comments were people pasting screenshots of their autoscaling agent doing twelve browser tasks in parallel. Beautiful demos. Then someone two replies down asked the question nobody in the launch post wanted to answer: “Does this work with my actual logged-in Chrome, or do I get a fresh sandbox every time?” Silence, mostly. Because the moment you point one of these things at your real browser through a relay, it falls over the first time you click a link.

This is the part the leaderboard posts skip.

The relay is a phone line, and you keep hanging up

Most of these open-source agents control a browser over the Chrome DevTools Protocol. CDP is a websocket. The agent on your VPS opens a connection to a specific debugging target inside Chrome, and that target is a single tab. Not “your browser.” One tab. The relay is just a tunnel that carries those CDP messages back and forth between the cloud agent and the Chrome running on your laptop.

So picture what happens when the agent clicks a link that opens in a new tab, or the site does a full-page redirect through an auth gateway. Chrome tears down the old target and spins up a new one with a new target ID. The websocket the agent was holding now points at a page that no longer exists. The agent didn’t lose its login. It lost its handle. It’s still shouting into a phone line where the person on the other end already walked away.

You see this as a frozen run, a timeout, or the agent confidently narrating actions on a page that closed thirty seconds ago.

Restart Chrome and the whole thing evaporates

Navigation is the gentle failure. Restarting Chrome is the brutal one.

The remote debugging port that the relay attaches to only exists because you launched Chrome with --remote-debugging-port and usually a separate --user-data-dir. Quit Chrome, and that port is gone. Reopen Chrome the normal way, from the dock, and it comes back without the debugging flag at all, so there’s nothing for the relay to reconnect to. Even if your tooling auto-relaunches with the right flags, the target IDs are freshly minted, so any session the agent cached is stale. The agent reconnects to a port that’s either closed or pointing at a browser that doesn’t remember a thing.

And here’s the profile trap that eats a whole evening of debugging. A lot of these setups, to avoid stepping on your daily browsing, launch Chrome against a throwaway --user-data-dir. That directory is a brand new profile. No cookies, no saved sessions, no extensions, none of the logins you assumed the agent would inherit. So you wire everything up perfectly, the relay connects, and the agent still hits a login wall on Gmail because it’s driving a profile that has literally never seen your Google account. People burn hours assuming it’s a relay bug when the relay is working fine and the profile is just empty.

So why does a side-panel agent not care?

Because it was never on the other end of a phone line to begin with.

A Chrome extension running in your browser’s side panel doesn’t attach to a debugging target over a socket. It lives inside the same browser session you’re already using. When you navigate, the extension’s content script gets re-injected into the new page by Chrome itself. When a new tab opens, the extension already has permission to operate in that tab. There’s no target ID to lose, because the extension isn’t holding a reference to a target. It’s part of the browser.

That’s the whole architectural difference, and it sounds almost too simple. The relay model puts the agent outside Chrome and makes it reach in through a fragile pipe. The extension model puts the agent inside Chrome and lets Chrome manage the lifecycle, which Chrome is extremely good at, because managing tabs and navigation and profiles is the one job a browser has.

Dassi works this way. It runs in the side panel, sees the page you see, and uses the session you’re already logged into. Restart Chrome and reopen the panel and you’re exactly where you left off, because there was never an external connection to drop. No --remote-debugging-port, no throwaway profile, no relay to babysit.

The thing the demos don’t measure

I’m not knocking the autoscaling agents. Running forty browsers in parallel against fresh cloud sandboxes is genuinely useful for scraping and batch jobs where you want a clean room and don’t care about login state. That’s a real use case and those projects are good at it.

But that’s a different problem than “do my work in my browser.” The instant you need the agent to act as you, inside your authenticated session, on the sites you’re actually logged into, the relay becomes the weakest link in the system. It drops on the most ordinary thing a browser does, which is go somewhere else. If you want to feel it firsthand, Dassi is on the Chrome Web Store and there’s nothing to wire up. We wrote more about why cloud browser agents can’t see your tabs if you want the longer version.

The demos measure parallelism. They don’t measure what happens on click two. That’s the number I’d want on the leaderboard.