Do AI agents need their own computer? The managed-VM pattern, examined

What "its own computer" is actually claiming

When a vendor says the agent has its own computer, it is making two claims at once and they are worth separating, because products satisfy them independently.

• An execution environment that is not your chat window. A filesystem it can write to, a shell it can run, a browser it can drive. Without this the agent can only produce text.
• An execution environment that is not your machine. Which means it survives your laptop closing, and it means a mistake happens over there rather than in your home directory.

The first claim is uncontroversial and universal. Every agent that does more than write text has one, including agents running on your own hardware. The second is the actual product decision, and it is where all the interesting trade-offs live.

It is also the claim that gets garbled. On the Grok Bot launch thread, wiradikusuma quoted the product FAQ back at it: "Bots have their own computer, so they can work inside your apps and tools. They also run in parallel, 24/7, even when your laptop is closed", and then asked the right question: "what does 'own computer' mean? X provisions a 'private cloud' a'la Apple for your Bot?" The answer, from xAI’s own documentation, is no: "All of your Bots use the same persistent cloud computer." One machine per account, one screen per Bot. Several ranking comparison pages still print "a dedicated cloud computer per bot" as a feature.

The case for the vendor VM, made properly

It would be easy to treat the managed VM as a rent-extraction device. It is not, or not only. There are three engineering reasons and they are all sound.

Reason one: a blast radius you can reason about

An agent that can run shell commands on your laptop can also delete things on your laptop. Putting it on a machine that contains only what you deliberately placed there converts an unbounded risk into a bounded one. This is the same argument that made containers standard in CI, and it is correct.

The catch is that the argument only holds while the machine stays small. A per-task VM that is destroyed afterwards keeps the promise. A persistent machine accumulates your logins, your downloads, your browser sessions, and your API keys until it is no longer a sandbox but a second computer holding a copy of your professional life, at which point "bounded" is doing very little work.

Reason two: uptime that does not depend on you

The one thing a laptop cannot do is be reliably awake. Scheduled work, inbound triggers, and long-running jobs all need something that stays up, and for most buyers a vendor VM is the only such machine they have access to. This is the honest core of the always-on pitch, and it is why Manus put "The Future of Work is Always On" on its Cloud Computer launch page and told buyers to "let your digital employee take the night shift".

Reason three: zero setup, which is worth real money

Provisioning a Linux box, hardening it, installing a browser stack, keeping it patched, and debugging it when it breaks is a job. A managed VM makes that job disappear. For a buyer whose time is worth more than the subscription, this alone justifies the price, and any comparison that ignores it is not being honest.

Per-task versus persistent: the distinction that decides everything

Two products can both say "the agent gets a cloud computer" and mean opposite things. Manus is the clearest illustration because it ships both models and documents the difference itself.

Its default is per-task: "Manus Sandbox is a fully isolated cloud virtual machine that Manus allocates for each task", which sleeps when idle and is eventually recycled (after 7 days for free users, 21 for paid, with artefacts and uploads restored). Its Cloud Computer, announced on 30 April 2026, is the other model: "a dedicated, persistent virtual machine in the cloud that allows Manus to run your applications, bots, and scripts 24/7", running Ubuntu, reachable over SSH or a web terminal, with no graphical interface.

The persistent column is not a better version of the per-task column. It is a memory system wearing infrastructure’s clothes. The reason to want one is that the agent remembers your CRM login and the file it wrote last Tuesday; the reason to fear one is exactly the same sentence.

Grok Bot pushes this further than anyone by sharing the persistent machine across every Bot on the account. Its documentation is unusually direct about the consequence: each Bot gets its own screen "without getting separate security boundaries", and you should "treat a login or file placed on the computer as available to all of your Bots". That is a deliberate design choice in service of a real feature (one Bot can hand work to another without re-authenticating), and it forecloses the obvious safety pattern of keeping a risky Bot and a trusted Bot apart.

What the rented computer costs beyond the price

Three costs do not appear on any pricing page, and each one has bitten someone this month.

The trust boundary moves, permanently

The moment an agent needs to log into something on your behalf, the vendor’s machine holds a live session for that service. With Grok Bot, you do not send the password through chat; xAI says Bot hands control to you so you can type it into the shared computer. What follows is the part to think about: the session persists on the vendor’s machine afterwards, and on Grok Bot it is inherited by every other Bot on the account.

From then on, every action taken with that session is recorded by the target service as you. SilverBirch asked the awkward version on the launch thread: if the agent uses your account to post on X, is that adhering to X’s terms of service? Nobody has answered. The general form of the problem is that you have created an actor with your identity and no independent accountability, and the log files cannot tell the difference.

The meter runs when nothing is happening

A persistent machine is billed persistently. Manus is transparent about it: Basic at $10 a month for 2 vCPU, 1GB of RAM and 35GB of storage; Standard at $30 for 4GB and 70GB; Advanced at $50 for 8GB and 120GB, on top of a membership starting at $20 a month for 4,000 credits, with 300 credits a day on the free tier and a 17% annual discount.

Grok Bot inverts it. The machine comes with the seat ($40 a month for a Cursor Teams Standard seat up to a reported $300 for SuperGrok Heavy), and the meter is on tokens against a weekly allowance xAI does not publish, with overage at raw model rates and no spend cap. Reviewers found the metering display itself broken during launch week, showing 48% usage as 0%.

The exit leaves things behind

Ask what happens when you stop paying. Manus answers plainly: the persistent VM "will be shut down" and "your working files, installed tools, and databases stored on that specific Cloud Computer will be deleted", although final outputs already delivered into the chat remain in your history. That is clear and fair, and it is also the definition of state you do not own.

The Grok Bot version of this is the account link rather than the machine. Every access path requires a Cursor account, and Cursor’s documentation states that a SuperGrok link is permanent once created: you cannot unlink a Grok account from a Cursor account, and you cannot move a link to a different Cursor account. An irreversible identity decision made during a free trial is a strange thing to find inside a compute purchase, but that is where it lives.

The arithmetic, done honestly

Compare like with like. The question is not "cloud versus local", it is "rent a machine monthly, or use one you already have, or buy one".

Three observations, none of which favour a single answer.

First, the cheapest rented option is genuinely cheap. $360 for a year of a machine you never administer is not a rip-off, and if your alternative is a $599 machine you would not otherwise want, renting wins for roughly the first 20 months before electricity.

Second, the expensive rented options stop making sense quickly. A $300 a month seat costs six Mac minis over a year, and the meter on top of it is uncapped.

Third, and most often missed: if you already own a desktop that stays on, the marginal cost of using it is a rounding error, and you have already paid for it. The row that decides this for most developers is not price at all, it is whether a machine in their life stays awake.

A note on the inference bill, since it is the larger number for anyone doing real work: it is separable from the machine. Own-hardware setups run against subscriptions you already hold (Claude, Codex, Cursor, Gemini) or your own API keys, which means the cost is the same work you were already paying for rather than a second bill on top. Managed products bundle inference into the seat and the meter, which is convenient right up until you want to see what a given repository or project actually cost you.

The objection, and the third option

The best argument against running agents on your own hardware was made on Hacker News by phoghed, and it deserves to be quoted rather than paraphrased:

This is right about the requirement and wrong about the conclusion, and the gap between the two is where the third option lives.

The requirement is: one agent, running somewhere that is not the device in my hand, reachable from every device I own. Nothing in that sentence says the machine must belong to a vendor. A desktop at home with remote access satisfies it exactly. The word "locally" smuggles in an assumption that running on your hardware means sitting in front of your hardware, and once you notice the assumption the argument stops being an argument against owning the box and becomes an argument for good remote access.

That is a design brief rather than a slogan, and it has three parts.

• The session must survive the client disconnecting. Closing your phone cannot stop the work; the agent runs on the machine, not in the app you are looking at.
• Every surface must be a real client. A phone that can only read status is a monitoring tool. It needs to send prompts, approve steps, read diffs, and stop a run.
• Reaching it must not require you to be a network engineer. This is where self-hosting usually loses people, and it is a solvable product problem rather than a fact of nature.

Continuum is built to that brief: agent sessions run on your Mac or Linux machine, in isolated git worktrees, and the iPhone and web clients drive a session that is executing on your hardware, over a private network rather than a port opened to the internet. The user experience is close to a hosted agent. The differences are that the box is yours, the model is your choice across labs, the repository and credentials remain on your host, selected context is sent to the configured provider for inference, and there is no meter on idle time.

It is also worth saying which half of phoghed’s comment stands. "Most people and businesses don’t self host" is true, and it will stay true, because self-hosting a framework is a job. The third option is only interesting if it removes that job rather than renaming it. A workbench you install like any other desktop app is a different proposition from a VPS you maintain, and the distinction between those two is the whole reason this option exists as a category at all.

A checklist before you hand an agent a computer

Whichever shape you pick, run through these before you connect anything real. Each one corresponds to a failure somebody had this month.

• How long does the machine live, and who else is on it? If persistent and shared, assume any credential on it is available to every agent on the account, because on Grok Bot that is documented behaviour rather than a worst case.
• Can you reconstruct what it did last Tuesday? Grok Bot’s audit view is described in its documentation as coming. Its 20-record retention limit was reported by Daily Dose of Data Science and remains unconfirmed by xAI. No queryable organisation-wide audit view means no organisation-wide post-incident answer.
• Is there a dry run? In mainstream products there is not. A test run performs real work: it navigates real websites, changes real files, and calls real tools. Rehearsing an email send sends the email.
• What is the spend ceiling? If the answer is "the allowance is not published and there is no cap", you do not have a budget, you have a hope.
• Which accounts is it getting? Create separate, revocable accounts for the agent wherever the service allows it. Never your primary bank, payroll, or domain registrar.
• What happens on cancellation? Ask specifically about state on the machine, not just about access. Manus deletes it; other vendors have not said.
• Can you leave with your work? Outputs delivered into a chat are exportable. A browser profile, a database, and an installed toolchain generally are not.

None of this says do not use agents with computers. Every one of them can be answered acceptably for a scoped, low-stakes use, and the products are getting better monthly. The mistake is treating a machine that holds live sessions until site or session expiry, sign-out, or revocation as though it were a chat window, because that is the framing the marketing invites and it is off by a whole category of risk.

For the same analysis applied to specific products, see Grok Bot versus Manus for two managed clouds side by side, Grok Bot versus Hermes Agent for managed against self-hosted, and the always-on category explainer for how the three delivery shapes compare.

Questions people ask

Keep reading

Continue through Agentic coding with AI coding agents in 2026: the landscape, priced.