Lesson 09. Pick the Venue, Then Plan for Its Death

A cloud-hosted background-agent service ran a small team's entire fan-out workflow: task definitions, session history, the review queue where finished branches waited for a human, all of it lived inside the product's own dashboard, not in the team's repository. The service shut down in January, the way a young, single-company product sometimes does, and the team had weeks, not months, to move everything that had only ever existed inside it. Nothing about the shutdown was unusual; it was a company deciding to stop. What made it expensive was that the team had never asked, while things were working, what they would keep if the vendor disappeared tomorrow. Decide now: for whichever venue is currently running your own fleet, what survives if it vanished with the same amount of notice?

Illustrative composite. The migration itself, reconstructing task definitions from memory and old pull request descriptions, cost the team more engineering time than a full year of the subscription they had been paying. The shutdown is real and dated; the exact cost figure is a teaching device, not a reported number.

This lesson gives you fleet/venues.md, the same task run in two venues, priced and timed, with an exit plan for each. It is the second half of the Isolate stage's question about where an agent lives: Lesson 08 chose whether your own remote host survives a dropped connection; this lesson chooses which venue you trust with the work at all, and what you keep of it if that trust turns out to be misplaced.

What is actually going on

A venue is anywhere an agent's shell actually runs, and four classes cover nearly everything available in 2026. Your own machine, the default and the one with no separate bill. Your own remote host, Lesson 08's subject: a box you provision and are responsible for keeping alive. A self-served sandbox: a purpose-built, ephemeral compute primitive (E2B, Daytona, Modal, GitHub Codespaces) that you provision, script, and tear down yourself, paying for wall-clock existence. And a vendor's managed cloud agent: a product that owns the whole loop end to end (GitHub Copilot's coding agent, Jules, Codex Cloud, Cursor's background agents), where you assign work and a result comes back, and everything in between is the vendor's to run.

The classes differ most sharply on two things the picture below makes legible: how much of the environment you control, and how much operational burden you carry for that control. A managed cloud agent gives you almost none of the first and almost none of the second, by design: you assign a task and the vendor owns the sandbox, the retries, and the environment. A self-served sandbox or your own remote host gives you nearly all of both: you choose the image, you write the gate, and you carry the cost of keeping it working. What to look for: nothing sits in the low-control, high-burden corner, because there is no reason a tool would ask you to carry the operational cost of an environment you don't get to shape.

diagramsource

drawing

Two more properties separate the classes once the control-versus-burden picture is granted. How a secret reaches the run differs by venue: a self-served sandbox gets whatever you inject into it at launch, so nothing has to live inside the image between runs, while a managed cloud agent decides for you, and the decision differs sharply by vendor. Cursor's background agents scope secrets per environment, so a credential configured for one run cannot be read from another; Codex Cloud, Copilot's coding agent, and Jules are all documented as repo-scoped by default, with no route to a private network or a secret store beyond what the public repository itself already contains [Source: WebSearch aggregating agent37.com and eesel.ai on Codex Cloud's scope, morphllm.com on Cursor's per-environment secrets | observed 2026-09-11, confidence medium]. And not every sandbox treats a paused run the same way: E2B's pause-resume keeps a sandbox's live process state intact across the gap, where several other vendors default to a plain tear-down-and-recreate model that makes "pause" functionally identical to "stop and start over" [Source: E2B pricing | observed 2026-09-11].

The rule and its condition

Choose a venue on four measurements, not on preference: start-up latency, what it costs per hour while idle, how the result comes back to you, and what you keep if the venue disappears. Keep the portable layer yours regardless of the answer: task definitions, repository conventions, and gates live in plain files in your own repository, never only inside a vendor's dashboard, session history, or task-configuration UI, so that the venue underneath them stays a replaceable detail rather than a dependency.

Measurement	Your machine or remote host	Self-served sandbox	Vendor managed cloud agent
Start-up latency	None once it's running	Sub-second to a few seconds, varies by vendor	Not published as latency; turnaround is minutes
Idle cost per hour	Whatever the box costs, running or not	Billed wall-clock; idle costs the same as busy	Not hourly; billed per task, seat, or credit
How the result comes back	Already there, on disk	Whatever you script: a branch, a diff, a running process	A diff or a pull request, by design
What you keep if it disappears	Everything; it was always yours	Nothing in the sandbox, but nothing lived only there either	Whatever already merged; task state and config inside the product do not survive

The self-served sandboxes checked in this research bill on the same shape: Daytona charges per vCPU-hour and per-memory rate, with storage and GPU tiers starting at $0.57/hour, pulled directly from its own pricing page, and Modal charges roughly $0.0000394 per core-second for its sandbox tier, about three times its base serverless rate, specifically because a sandbox is held non-preemptible, both confirmed against the vendor's own page [Sources: Daytona pricing, Modal Sandboxes guide | observed 2026-09-11]. E2B publishes a comparable per-vCPU and per-memory rate on its own pricing page, but this research pass triangulated the figure from secondary sources instead of confirming it directly against e2b.dev/pricing — check the page yourself before budgeting against a number this lesson did not verify first-hand. GitHub Codespaces bills a flat $0.18 per core-hour regardless of machine size, so a 4-core environment runs $0.72/hour, billed only while active [Source: GitHub Codespaces billing | observed 2026-09-11]. None of the four vendor-managed products in the table publish an hourly rate at all; GitHub's Copilot coding agent is billed through the existing Copilot plan and its own AI-credit usage, capped at a hard 59 minutes of execution per task regardless of cost [Source: GitHub Copilot coding agent docs | observed 2026-09-11]. That gap, hourly versus per-task, is itself a design input: a sandbox rewards you for tearing it down between runs, and a managed agent rewards you for not having to think about the meter at all.

Worked case

A two-person team maintains an open-source SDK (public repository, no secrets involved) and a private product repository that needs a live Postgres instance and internal network access to test against. Both repositories need the same kind of task on a regular basis: bump a batch of dependencies, run the test suite, open a pull request. The team wants one answer, "which venue do we standardize on," and the honest answer turns out to be two.

For the open-source SDK, they route the task through GitHub's Copilot coding agent: assign the issue, the agent runs inside GitHub's own sandboxed Actions VM, pushes to a branch prefixed copilot/, and opens a draft pull request that only runs further CI once a human approves it [Source: docs.github.com coding-agent docs | observed 2026-09-11].

diagramsource

drawing

For the private product repository, Copilot's coding agent is the wrong shape before it is even the wrong price: it is documented as repo-scoped with no route to a private database or internal network by default, and the same limit applies to Codex Cloud and Jules, both of which run against the repository alone with no local or private network reachable from inside the task [Sources: WebSearch aggregating agent37.com and eesel.ai on Codex Cloud's repo-only scope; jules.google product description | observed 2026-09-11, confidence medium]. The team instead runs a self-served Daytona sandbox with a custom image carrying a Tailscale sidecar that reaches their private Postgres instance, and writes their own gate to run the suite and push the branch.

Illustrative composite. On the public SDK, the dependency-bump task took about forty minutes inside Copilot's 59-minute cap, billed as part of the team's existing Pro+ Copilot seat with no separate line item. On the private repository's equivalent-sized task, the Daytona sandbox ran for about twenty-five minutes at a 2 vCPU/4 GiB profile (a few cents of compute), plus roughly two dollars of Sonnet-class API usage for the agent's own reasoning, for a total under three dollars, not counting the engineering time the team had already spent writing and maintaining the gate that Copilot's product supplies for free.

Decide now, and name the fact from the table that rejects each option before it is priced. Running the private repository's task through a managed cloud agent is rejected first on capability: none of the three checked provide a documented route to a private network, so the task would not have completed regardless of cost. Running the public SDK's task through the self-served sandbox is not rejected on capability, it would work, but it is rejected on the idle-cost-per-hour and operational-burden columns: the team would be paying, in both money and maintenance time, for a gate and an environment that a zero-infra product already gives them for the price of a seat they already hold. The venue choice tracks the measurement that actually binds for each task, not a preference for consistency across the two.

Faded case

Skip to the open case if this is familiar.

A solo developer runs fifteen to twenty small, independent chores a day against a single public repository: typo fixes, small refactors, dependency bumps flagged by a bot. Nothing touches a private network. The developer is weighing Google's Jules against a self-served sandbox they would have to script themselves. Jules clones the repository into its own ephemeral Cloud VM, requires an explicit diff review before anything merges, and its free tier allows fifteen tasks a day at three concurrent [Source: jules.google, cross-referenced against WebSearch aggregation | observed 2026-09-11, confidence medium on exact task caps]. The developer's daily volume sits right at that ceiling on a busy day.

Open case

A three-person team has a steady nightly batch of a dozen small maintenance tasks and, roughly once a week, an urgent fix that needs to touch a private staging database. One teammate proposes standardizing on a single venue "so we only have to learn one tool." Using the four measurements, decide whether that proposal holds, and if not, which task goes to which venue and why.

Where this breaks

Naming a vendor's product does not make it permanent. This research pass, done in a single sitting, found five fleet-orchestration and agent tools already dead or discontinued: a popular IDE-extension fork that shut down and archived its repository, stating plainly that its team no longer believed in the product category it had built (Roo Code, archived 2026-05-15); a desktop app for parallel agent sessions that was quietly renamed and abandoned under its old name (Crystal, dormant since 2026-02-26); a kanban board for heterogeneous agent fleets whose company shut down, open-sourcing the code with zero commits since (Vibe Kanban, dormant since 2026-04-24); a CLI for parallel worktree-isolated agents left with no commits in over a year (Uzi, last pushed 2025-06-04); and a fully cloud-hosted background-agent orchestrator that shut down outright, its own repository now only an archival snapshot (Terragon, shut down January 2026) [Sources: github.com/RooCodeInc/Roo-Code, github.com/stravu/crystal, github.com/BloopAI/vibe-kanban, github.com/devflowinc/uzi, github.com/terragon-labs/terragon-oss, GitHub API stats | observed 2026-09-11]. None of these were obscure; several had tens of thousands of stars and real installed bases. Star count and funding are not a mortality forecast.

The class that survives a single vendor's death is the one built on identity-scoped, credential-less access rather than a static secret handed to whichever box runs the work: a per-workload identity that grants a scoped set of cloud services with no embedded credential, so an agent's access can be revoked or rotated without touching a secrets file anywhere. This pattern is real and worth adopting regardless of which specific platform implements it; treat any single vendor's exact onboarding time or "instant" claim for it as marketing until you have measured it yourself.

A managed cloud agent's per-task billing hides a compute-time unit underneath it on at least one vendor: Devin's ACU, reported as roughly fifteen minutes of active work per unit. The concept is worth knowing; the exact price per unit is not verified against the vendor's own page in this research and does not belong in a budget until it is.

Key Takeaways

• Score a venue on start-up latency, idle cost, return path, and what survives its death.
• Wall-clock billing charges an idle sandbox the same as a busy one, on every vendor checked.
• Keep task definitions, conventions, and gates in your repository, never only inside a vendor's product.
• A managed cloud agent trades control for zero operational burden; a sandbox trades the burden back.
• Five tools this research relied on were already dead or discontinued within about a year.
• Write each venue's exit plan before you need it, the same discipline Lesson 08 asked for persistence.

What You Have Now

fleet/venues.md — the same task run in two venues, priced and timed, with an exit plan for each. It sits next to fleet/cost-model.md, whose crossover point this lesson's pricing feeds directly, and it closes the second half of the Isolate stage's question about where an agent lives: Lesson 08 settled whether your own host survives you leaving, this lesson settles which venue you trust at all, and what remains yours if that trust turns out to be misplaced.

Further Reading

• E2B pricing: per-second sandbox billing and pause-resume semantics from a purpose-built agent-sandbox vendor.
• Daytona pricing: the most detailed public, GPU-inclusive sandbox price table found in this research.
• Modal Sandboxes guide: readiness probes and the standard-versus-sandbox pricing split.
• GitHub Copilot coding agent docs: the documented 59-minute execution cap and the branch-and-approval gate for a fully managed venue.
• GitHub Codespaces billing: flat per-core pricing and the free-tier compute-hour allowance for the simplest on-ramp venue.

Exercises

1. List every venue your fleet currently touches, including ones nobody deliberately chose, and score each against the four measurements.
2. Run one real task in your current venue and in one alternative from a different class; fill fleet/venues.md with the measured latency, idle cost, and return path for both.
3. Write the exit plan for your primary venue as if it announced a shutdown with six weeks' notice tomorrow: what would you keep, and what would you have to rebuild from nothing.

Check your understanding