Dora NodaYour laptop has become the bottleneck in your own workflow. The agent run you started before lunch is still going, the fan is audible from the next room, and closing the lid means deciding whether the last two hours of work survive the sleep. On August 3, 2026, a YC S26 startup called Hoplite launched on Hacker News with a pitch aimed squarely at that moment: take your whole local coding-agent setup — sessions, memories, MCP servers — and run it on their cloud instead, with a live preview URL and a pull request at the end.
Hoplite is the example, not the whole story. GitHub, OpenAI, Cursor, and a fleet of startups are all converging on the same product category: agent execution as a rented service. This post inventories exactly what you're renting when you move agent work off your machine — Hoplite's bundle line by line, the lock-in shape underneath it, and the worked rent-vs-own math — so a team can decide whether cloud-grade agent execution belongs on someone else's substrate or on machines they own.
What Hoplite actually is
The product loop is simple: connect a GitHub repository, describe a task in a thread, and an agent works it inside an isolated cloud sandbox — reading and editing the repo, running tests, driving a browser against a live preview of your app — then opens a pull request you review. Setup per repo is a base branch, a setup script, and encrypted environment variables; sensitive actions pause for your approval; every run ships verification evidence (test output, preview recordings) alongside the diff. A CLI imports your existing local history from Claude Code, Codex, or OpenCode, and the platform exposes itself back out over an OAuth-protected MCP endpoint, so other agents can drive Hoplite as a tool.
The launch resonated because the category is unmistakably forming. Hoplite pitches itself against GitHub's Copilot Cloud agents, OpenAI's Codex Cloud, and Cursor's cloud agents — the three vendors racing to move your editor's agent off your machine and into their datacenters — while Devin holds the high end of delegated work at $500/month for its Core tier. The Hacker News thread split exactly the way a new infrastructure category always splits: half the comments debating managed hosting versus self-hosted runners, the other half asking whether this layer survives as independent companies or gets absorbed into the model providers. That debate is the reason this post exists — but the interesting part isn't the opinions, it's the architecture underneath them.
Hoplite's founders disclosed their stack in the launch thread: Temporal for durable orchestration of agent runs (workflows that survive retries, sleeps, and failures without hand-rolled state machines), Modal as the serverless compute substrate that actually boots the sandboxes, and PlanetScale as the state store holding threads, memories, and skills. Three rented layers under one $99 seat. Remember that composition, because the lock-in analysis later is really just asking what happens to each layer when you want to leave.
The bundle inventory: what you're renting
Here is the full bundle, each item with what it would cost you to replicate. This is the "really renting" the title promises:
- Isolated sandboxes on someone else's capacity. Every thread gets a fresh dev environment on Modal/AWS-backed compute. Self-host equivalent: a Firecracker/container pool you operate (see the options table below).
- Repo setup automation. Setup scripts plus encrypted env vars that turn "fresh box" into "my app runs here" without human intervention. Replicating it means writing the same scripts — the value is that Hoplite runs and debugs them for you.
- Local config transfer, MCP servers included. The CLI imports Claude Code/Codex/OpenCode sessions, memories, and skills, and agents get your MCP tool integrations inside the sandbox. This is the headline feature and the stickiest: your agent's accumulated context now lives in their database.
- Approval gates for sensitive actions. The agent pauses and asks before doing anything risky. Replicating it means building the policy layer plus a UI someone actually watches.
- Verification evidence. Test runs, live preview URLs, and recordings attached to the thread so review starts from proof, not vibes. The preview-serving alone — per-thread URLs with correct routing and auth — is a small platform project.
- PR workflow and iteration. Open the pull request, then keep iterating in the same thread as review feedback arrives. GitHub App-scoped repo access keeps permissions tight.
- Drive-it-yourself interfaces. An MCP server, a CLI, and agent-readable docs (
llms.txt,agents.txt) so the platform composes with the rest of your agent stack instead of being a walled garden with one door.
TL;DR verdict: rent this bundle when your team is small and agent usage is bursty — the per-seat price buys you out of a platform project you don't have headcount to staff. Own the equivalent when your agent fleet runs hot all day, when code and credentials can't leave your machines, or when per-seat math breaks at your team size. The rest of this post shows the numbers behind that sentence and names exactly what "own the equivalent" requires.
The lock-in shape, named
"Your agents, their substrate, their state store" sounds like a slogan until you price the exit. Three surfaces, each with its concrete migration cost:
1. The substrate. Your agents execute on Hoplite-operated compute (Modal/AWS under the hood). Leaving means standing up your own sandbox fleet — picking a runtime from the table below, wiring autoscaling, and absorbing the cold-start and snapshot engineering Hoplite did once for all customers. This is the most visible lock-in and the least dangerous: compute is fungible, and the migration is a known project with known tools.
2. The state store. Threads, memories, skills, and imported local history live in Hoplite's PlanetScale database. This is the dangerous one. Agent memories compound — every corrected mistake, every learned repo convention, every tuned skill makes the next run better, and all of that compounding happens inside someone else's tables. Migrating it off means exporting whatever the API exposes (today: effectively a fresh start with your repo and dotfiles) and re-earning months of learned context. Data gravity applies to agent memory exactly the way it applies to databases: the longer you stay, the heavier the exit.
3. The workflow. Approvals, verification evidence, cost cards, and the thread↔PR linkage live in Hoplite's UI and CLI. Leaving means rebuilding the human side of the loop — where reviewers click approve, where evidence renders, where spend limits live — and retraining the team muscle memory that formed around it. This is the lock-in nobody prices on day one and everybody pays on exit day: not a technical migration, an organizational one.
None of this is an accusation — every managed platform has this shape, and Hoplite's agent-readable interfaces arguably make exit easier than average. It is a bill of materials for the exit you hope you never need. Price it before you need it.
Cost math: $99/seat versus a sandbox fleet you own
Hoplite's public pricing is simple: Free ($0, run agents yourself with tighter limits), Pro at $99/seat/month ($82.50 on yearly) including $100 of usage credits per seat each month, team seats, shared workspaces, and bigger sandboxes, then Enterprise on custom terms. Past the included credits, usage keeps metering against credits, and teams can route inference through connected subscriptions or their own provider API keys — in which case the model bill lands on your Anthropic/OpenAI account, not Hoplite's. One honest gap: the public pricing page doesn't list per-unit overage rates, so heavy teams can't compute their ceiling from the website. Assume the meter runs past $100 and budget accordingly.
The own-side total has three lines, and the labor lines are non-negotiable — compute-only comparisons are how self-hosting math lies to you:
- Sandbox compute. Managed E2B at volume runs on the order of ~$545/month for a busy fleet; the same workload self-hosted lands on roughly a $6/month VPS at the small end, scaling to $25–60/month in owned boxes (a Hetzner-class machine or two) for a team-sized fleet. Unit economics favor owning by roughly two orders of magnitude at steady utilization.
- Build labor (one-time). Standing up the equivalent — sandbox runtime, GitHub App, MCP tool gateway, approvals surface, preview serving — is realistically 1–2 engineering weeks for a team that already runs infrastructure. At a $75/hour planning rate, call it ~$3,000 one-time, amortized over the comparison period.
- Ongoing ops labor. Patching, capacity watching, debugging the 2 AM sandbox failure: budget ~4 hours/month for a small fleet (~$300/month), more as the fleet grows. This line is where most "we'll just self-host" plans quietly die.
Now the sensitivity across team sizes, steady-state monthly cost, tokens excluded (they're metered either way — see the caveat below):
| Team | Rent (Pro seats) | Own (compute + ops + amortized build, yr 1) |
|---|---|---|
| 1 dev | $99 (or $0 on Free) | ~$6 + $300 + $250 = ~$556 |
| 5 devs | $495 + overage | ~$25 + $300 + $250 = ~$575 |
| 20 devs | $1,980 + overage | ~$60 + $600 + $125 = ~$785 |
Three readings. At one developer, renting wins by a mile — the Free tier makes it not even close. At five developers, year one is roughly break-even on cash, but renting buys zero build risk and zero pager duty, which is worth more than the spreadsheet gap. At twenty developers, owning wins clearly on cash (roughly 2.5x cheaper before overage), provided the team actually staffs the ops line instead of letting it rot. The crossover sits around 5–10 seats in year one, moving earlier the heavier your per-seat credit overage runs.
Two caveats keep this honest. First, model tokens dominate both sides and mostly cancel out — the seat-vs-server debate is about the execution substrate, not inference, and anyone quoting you agent costs without a token line is selling something. Second, measure in Hoplite's own unit: cost per accepted change — total batch spend (including abandoned attempts and failed runs) divided by merged PRs, plus review minutes at your planning rate. Their September 19 cost-accounting post makes the methodology explicit, including the warning that a zero credit balance doesn't mean zero economic cost when inference rode a connected subscription. Apply that frame to both columns and the comparison survives contact with reality.
The self-hosted equivalent: build list
Five components, each rated build-vs-adopt with the hard part named. This is the shopping list for "cloud-grade agent execution on machines you own":
1. Sandboxed runners — ADOPT a runtime, BUILD the fleet layer. The 2026 options table:
| Runtime | Isolation | Cold start | Self-host story |
|---|---|---|---|
| E2B | Firecracker microVMs | ~150 ms | Apache-2.0 SDK, self-hostable — but a real infra project (Nomad/Consul scale) |
| Daytona | Containers (+Kata) | sub-90 ms | Core went closed-source June 2026; OSS repo archived — adopt with eyes open |
| Temps | Firecracker microVMs | fast | Self-hosted option still open |
| AgentENV (Kimi K3) | Firecracker microVMs | sub-second | Self-hosted, E2B-API-compatible — drop-in for E2B SDK code |
| Mitos | Firecracker + CoW snapshots | fast | Native sandbox CRDs plus a Daytona-compat shim for refugees |
| Modal / Vercel Sandbox | Managed serverless | fast | Managed-only; use as the substrate, not the owned layer |
The hard part isn't picking a runtime — it's snapshots, image caching, and per-tenant network policy at fleet scale. Budget the engineering there, not in the bake-off.
2. Per-agent scoped credentials — BUILD. Short-lived tokens minted per thread, scoped to exactly the repos and tools that run needs, revoked when the thread closes. The managed platforms do this invisibly (GitHub App installations, encrypted env injection); self-hosted, it's a small secrets broker plus ruthless default-deny. This is the component most DIY agent setups skip and most agent-incident postmortems wish they hadn't.
3. Machine-readable deploy state — BUILD on your existing APIs. The agent needs to read "what's deployed where, at what version, with what health" without parsing your Slack. If your platform already exposes that (and a Render-compatible API on your own fleet does), this is an afternoon of MCP tool wrapping. If it doesn't, fix that before giving agents deploy buttons.
4. Approval and evidence trail — BUILD, keep it boring. A queue where sensitive actions wait, a page where verification evidence renders, spend limits per thread. Hoplite's version is polished; yours needs to be present and auditable, not beautiful. Append-only logs, signed approvals, done.
5. MCP tool gateway — ADOPT the protocol, BUILD the policy. Expose deploy/rollback/log tools over MCP so any agent client can drive them — but every mutating tool gets an approval gate and an audit entry. Read-mostly tools are the easy case; the moment a tool can change production, it inherits component 4's requirements. (Two recent posts on this blog covered the deploy-MCP production gaps and the production numbers in depth — this checklist assumes you've read them and starts where they end.)
When to rent versus own
The full rule, compressed from everything above:
- Rent when the team is small (the 1–5 seat math isn't close), when agent usage is bursty (nights-and-weekends automation doesn't justify an always-on fleet team), or when you'd be building the platform and the product simultaneously — one of them will lose, and it'll be the platform.
- Own when the agent fleet runs hot all day (steady utilization is where the 100x compute gap compounds), when code, credentials, or model inputs can't leave your machines, or when per-seat pricing breaks at your headcount — $1,980/month at 20 seats buys a lot of owned sandbox capacity and ops hours.
- Hybrid is legitimate. Run managed for bursty overflow and self-hosted for the steady base, the same way teams split CI minutes. The MCP interface both sides speak makes this less painful than it sounds.
One line to carry out of this post: agent execution just became a product category, which means it just became a build-vs-buy decision. Run the numbers for your team size, price the exit before you sign, and whichever side you pick, keep the memories portable — that's the asset that compounds, and it's the one you'll miss if it lives in someone else's database.
Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own, with the machine-readable deploy state your agents need to operate it. Star the repo on GitHub or run your first agent-operated deploy today.
