I keep seeing “local-first” used as if it is a personality trait. A product says it, people nod approvingly, and everybody quietly imagines that every byte stays in the room next to the coffee mug.
That is not what the phrase means. At least, it should not be.
I was looking into OpenMausBot, an open-source multi-agent desktop app, and the useful part was the boundary it forced me to name properly: where does a bot’s computer-use work actually happen?
It sounds fussy, but it is also the question that prevents a lot of accidental architecture.
“Local-first” is a starting point, not a force field
OpenMausBot describes itself as local-first. Its README says the harness listens on 127.0.0.1, and that transcripts, keys, and events live under ~/.openmausbot. That is a meaningful default. The control surface and the local records are on the machine running it.
But a local control plane does not magically make every part of an agent’s turn local. The model request still goes to whichever model provider has been selected. Optional Box and Composio integrations are remote too. Pretending otherwise is how “local-first” turns into a marketing fog machine.
The cleaner way to think about it is narrower: for computer-use work, the selected destination determines where the desktop, browser, and files involved in that work run.
That distinction is enough. It is also the one that matters when a bot is about to open a browser, download something, or shuffle files around. I do not need a philosophical debate about locality. I need to know which computer is doing the clicking.
There are two decisions hiding in one sentence
The project can give a bot a cloud Linux desktop, an isolated Local VM, or an explicitly enabled host computer. Those are computer destinations.
Then there is a separate Local VM policy. If I choose that route, the local target can be shared or configured per bot. Shared mode means one local target is shared. Per-bot mode derives a separate target or container identity for each bot, within the configured limits.
Those are not interchangeable ideas, even though they are easy to mush together in casual conversation.
“Every bot gets its own VM” is not the same claim as “the app supports local VMs.” The first describes a particular policy and configuration. The second describes an available destination. The difference sounds pedantic until the second bot opens the same environment as the first one and somebody wonders why the state looks weird.
I like that this forces a concrete question before anything runs: should these bots share a working desk, or should each one get a separate little room?
Neither answer is universally correct. A shared environment can be simpler when the task really is shared. Separate environments make more sense when isolation is the point. The important thing is choosing deliberately instead of treating the default as an invisible product decision.
Cloud is not a betrayal of local-first
This is the bit I think gets needlessly tribal.
Using a cloud computer does not cancel a local-first design. It changes the destination for a specific kind of work. That can be a sensible choice if the task needs a Linux desktop away from the host machine, or if I want the computer-use environment to live somewhere other than the machine in front of me.
The project’s release history makes the boundary unusually visible. Version v0.1.51, published on September 4, 2026, listed the ability to show and manage per-bot desktops. Later, version v0.1.79, published on September 15, listed “Run cloud turns on the Box itself, drop the local computer relay.” Its linked pull request says a bot set to Cloud runs its whole turn on the Box.
That is not a small implementation detail dressed up as a feature. It is the architecture saying, plainly, “this turn happens there.”
And honestly, good. I would rather see that boundary named than have a supposedly local tool quietly relay a cloud task through my machine because it was convenient for the implementation.
The question I would ask before enabling anything
Before I try a tool like this, I want a boring little checklist. Boring checklists save weekends.
- What is the computer destination for this bot? Host, Local VM, or cloud Linux desktop are different choices with different consequences.
- If it is a Local VM, is the policy shared or per-bot? “Local” alone does not answer that.
- What work remains remote? Model-provider traffic and optional connected services do not become local merely because the harness is.
- Which bots should share an environment? A shared target can make handoffs convenient, but it also makes that shared state part of the task whether I intended it or not.
None of this requires pretending to have a giant fleet of agents. It applies just as well to a personal experiment with two bots and a browser. The scale changes; the boundary does not.
Deployment choices are product choices
“Local-first” is useful when it describes defaults I can inspect and change. It is useless when it becomes a halo around a product.
What I took away from this investigation is simple: locality is not binary. A system can keep its harness and local records on my machine, send model calls to a provider, and run computer-use turns in either a local environment or a cloud one. That is not hypocrisy. It is a map.
The only bad version is the one where I cannot tell which road a task took.
So before I get excited about an agent desktop calling itself local-first, I am going to ask a much less glamorous question: where will this bot’s next click happen?
