A hosted agent runs in a provider’s cloud. You give it a copy of your repositories and a set of credentials, and it works from there. A local-first agent runs on your own machine, with the runtime, subscription, files and keys already on it, and only the conversation leaves.
Both are legitimate designs. They put your code, your identity and your bill in different places, and the differences matter more once you start sharing the agent with other people.
What hosted gets right, and what it costs
The concrete examples in 2026 are Claude Code on the web and OpenAI’s Codex cloud tasks. Both run the agent in the provider’s sandbox against a clone of your repository and authenticate to git with tokens issued to the provider through GitHub’s OAuth integration, so the agent never has access to your local credentials, SSH keys or environment variables. That is a real security property: a compromised developer laptop cannot leak into the agent’s environment, and a poorly scoped task cannot touch files outside the sandbox.
A hosted agent is always on. There is no laptop to keep awake and nothing to install. For unattended, around-the-clock fleets, that is decisive.
The costs are structural rather than fixable.
- A second copy of everything. The provider holds your repositories, and often your environment, so the agent can work. That copy has its own access controls, retention and breach surface.
- A second set of credentials. Tokens for GitHub, cloud accounts and internal APIs are issued to the provider. Rotating them means rotating them there too.
- A second bill. You pay for the hosted runtime on top of, or instead of, the subscription you already have.
- Someone else’s model choice. The host decides which models are available and when they change.
What local-first gets right, and what it costs
A local-first agent uses what is already on your machine: the Claude Code or Codex subscription you pay for, the repositories you already have checked out, the keys already in your keychain. Nothing is copied anywhere. When you share the agent, the other person gets to ask; your machine still does the work.
The cost is availability. If the machine is asleep, the agent is asleep.
The mitigations are practical rather than architectural: register the daemon as a service so it starts at login and restarts after a crash, keep the machine awake during working hours, and queue requests in an inbox so nothing is lost while it is offline. Requests run in order when it returns.
Two places to put the trust boundary: around the provider’s sandbox, or around your own machine with a room outside it.
How thin the cloud layer can be
muti is local-first, and the interesting design question was what the cloud is allowed to hold. The answer is: the room, and nothing that would let the room impersonate the machine.
Three mechanics make this hold.
Outbound only. The daemon on your machine polls for work over an outgoing connection. There is no open port, no tunnel and no inbound path. If muti’s cloud were compromised, the attacker could queue requests that your permission rules and approvals would still govern; they could not reach your files.
Events, not files. The daemon emits timeline events describing what happened. It does not upload the working tree, and it never reads environment variables or key files to send them anywhere.
Approvals in the middle. Because the machine is yours, the four dangerous action types pause for you on every request from someone else. A hosted agent with your credentials has nobody to ask.
The shape in between
Two products have since taken a middle path worth naming. Kylon hosts the workspace but lets an AI member be either its own hosted agent or one connected to a Codex or Claude Code already configured on someone's computer. Buzz inverts it: you host the workspace yourself, and a bridge brings a locally running Goose, Codex or Claude Code in as a member with its own keys.
Both dissolve the neat line between hosted and local-first, and both leave open the question this post is really about: when a request from someone else reaches an irreversible action, whose approval is required? Where the process runs is a hosting decision. Who is accountable is not. See Block's Buzz and muti and Kylon and muti.
A decision table
Why muti doesn’t host runtimes
It would be easy to add a “run this in our cloud” button. We haven’t, and it is a deliberate non-goal. The moment the runtime moves, the credentials and the repositories follow, and the owner stops being the one who approves. Every guarantee in the four actions that always ask depends on the machine being the owner’s.
muti hosts rooms. Your agent stays where it is.
Frequently asked questions
Is “local-first” the same as “offline”? No. The agent needs the network to reach its model provider, and muti needs it to deliver messages. Local-first describes where the work and the secrets live, not whether the machine is connected.
Can I run muti’s cloud myself? Self-hosting the room layer is on the roadmap as a single-person, offline-capable mode. The daemon and the cloud already talk over a plain API.
What if I have several machines? Connect each one. Agents are tied to a machine and a working directory, and you can tell your machines apart by the addresses the daemon reports.
If you already pay for a good agent and want to keep it where it is, give it a room.
Published · Updated