Choosing a home for your agent

How plori compares.

There are several honest ways to run an AI agent, and they solve different problems. Here is the landscape as we see it, including where plori is not the right choice.

Opens your agent straight away, no signup needed.

The landscape.

§01
OptionWhat it isState between sessionsCost while idleWho operates it
ploriA managed computer per agent, with the agent includedPersistent by default: disk and memory survive between sessionsZero. Idle agents scale to zero; plan disk is freeplori runs it; you talk to it or drive it over MCP
Sandbox APIs (E2B, Daytona, Modal)Infrastructure primitives for executing code from your own appEphemeral sessions; persistence is snapshots or storage you wire upDepends on what you keep warm and storedYou build and operate the agent around the sandbox
A VPS you manageA general server you rent and administerPersistent, and entirely yours to maintainThe full server price, 24/7, working or notYou: install, isolate, update, monitor, secure
Your own laptopThe agent as a local processPersistent while that machine lives and stays yoursFree, but the agent stops when the lid closesYou, and only while you are online
Agent inside an IDE or SaaSAn assistant feature of another productScoped to that product's sessions and workspaceBundled in that product's subscriptionThe vendor, inside their workflow only

The structural difference: sandbox APIs and servers are places where your software runs; plori is a place where your agent lives. If you are building a product, you likely want the former. If you want a working agent today, with persistent files, memory, and unattended work built in, that is what plori is for.

Questions, answered.

§02

What is the best way to host an AI agent?

It depends on who builds and who operates. If you are shipping code execution inside your own product, a sandbox API like E2B or Modal is the right primitive. If you want an agent working for you without building or operating anything, a managed platform like plori is the shortest path: the agent, its computer, persistence, and billing come as one thing you talk to.

When is plori NOT the right choice?

When you are embedding code execution into your own application at scale (use a sandbox API), when policy requires everything on-premises or fully local, or when all you want is autocomplete-style help inside an editor. plori is for agents that work as durable colleagues, not for infrastructure you resell.

How is plori different from an ephemeral sandbox?

A sandbox gives your code a place to run for a session. plori gives an agent a computer to live on: the disk, installed tools, and memory persist between conversations, the agent sleeps in place at zero compute cost, and scheduling plus background work come built in.

Why not just run my agent on a $5 VPS?

You can, and you will own isolation, updates, secrets handling, and monitoring, and pay for every idle hour. A VPS bills around the clock; a plori agent bills only while it works. The trade is control for operations: a VPS is fully yours, plori is fully managed.

Can I migrate between plori and other setups?

Your agent's files are plain files: browse and download them from the files panel anytime, or ask the agent to push work to your own git remotes and storage as it goes. There is no proprietary workspace format holding the work.

Does plori replace my IDE's agent?

No, it complements it. IDE assistants excel at the tight loop with you present; a plori agent covers unattended work: long jobs, scheduled runs, background builds. Over MCP your IDE agent can even delegate to a plori agent directly.