I scrolled HN this morning and saw two browser agent launches sitting on the front page within hours of each other. Yamak, pitched as an open-source AI browser agent, and right next to it, a “Show HN” for an open-source autoscaling browser agent. Different teams, same week, same playbook.

People are excited about Yamak being open source. I get it. Auditing the code is good. Being able to fork it is good. And not paying a SaaS subscription for a wrapper around an LLM has obvious appeal.

But open source is not the same as local. And almost nobody catches the difference.

Hosting it somewhere isn’t running it where you are

When you clone Yamak’s repo, you still have to run it. That means a Docker container, a VM, a fly.io instance, something. The “browser” the agent controls is a headless Chromium spun up inside whatever box you stood up. So your agent is logged into nothing. It has no cookies. No saved sessions. It’s a stranger to every site you actually use.

If you want it to act on your Gmail, your Linear, your bank, you have to start re-authenticating inside that headless browser, and that means either piping credentials in or wrestling with some persistent-profile workaround that breaks the next time Chromium updates. People do it. Sort of.

But once you’ve done all that, the thing you have is a remote bot operating its own browser somewhere in a data center. You haven’t connected the agent to your work. You’ve stood up a parallel browser that has to redo its own login dance every time the container restarts.

What “local” actually has to mean

Local has to mean: the same Chrome window where I just replied to a Slack message. Same tab. Same logged-in state. Same 2FA cookie that was set this morning. If the agent is in a different process on a different machine pretending to be a different user, it’s not local in any way that matters to a working person.

This is the gap dassi sits in. It’s a Chrome extension. The side panel runs next to your real tabs, looks at your real DOM, uses your real session. Nothing gets posted to a server you have to maintain. Nothing has to re-log-in to Gmail because Gmail already logged you in this morning. The browser context is already there, and dassi plugs into it.

That’s not a small distinction. It’s the entire distinction. We wrote about this in Cloud Browser Agents Can’t See Your Tabs, and the same logic holds whether the cloud agent is closed-source SaaS or an open-source repo you stood up yourself. The architecture is what matters. Not the license.

The infrastructure tax nobody priced in

Every open-source browser agent ships with a hidden invoice. You pay it in DigitalOcean droplets, in time spent fixing the Playwright install on Ubuntu 24, in Cloudflare bot blocks, in re-logging into things, in re-running migrations after the schema changed in v0.4. None of that work makes you faster at the task you wanted automated in the first place. It just makes you a part-time devops engineer for a tool you don’t own.

We dug into this pattern in Every New Browser Agent Needs a Server. Why? and it hasn’t changed because a new repo trended on HN today.

Open source is a feature. Not a place.

The point isn’t proprietary vs. open. The point is where the code runs.

So what do you actually want

If you want full code access for its own sake, run Yamak. Audit it. Fork it. That’s a legitimate path for a developer who wants to bolt a programmable robot onto their own infrastructure.

But if what you wanted was an agent that helps you in the browser you’re already using — the one with all your tabs and logins and half-finished Google Docs — installing yet another self-hosted server isn’t the answer. Install dassi from the Chrome Web Store and let it see what you see. Bring your own LLM key, or log in with ChatGPT. No deploy step. No port forwarding. No fresh Gmail OAuth flow because the headless Chromium booted up clean again.

The headless Chromium in someone’s data center will never know what tab you’re on. Yours does.