Copilot Projects Need Own Sandboxes

title: "Copilot Projects Need Own Sandboxes" slug: "2026-10-29-copilot-projects-hundreds-of-agents-where-they-run" meta_title: "Copilot Projects Need Own Sandboxes" meta_description: "GitHub Universe 2026 put copilot projects in every user's hands, demoing hundreds of agents per project. Here is the fleet infrastructure those sessions need." primary_keyword: copilot projects author: Krova Cloud Engineering date: 2026-10-29 schema: BlogPosting+FAQPage category: AI Code Sandboxing secondary_keywords: multi-agent fleets, agent sandbox infrastructure, per-minute billing, microVM snapshots, MCP provisioning excerpt: "GitHub's Universe demo coordinated hundreds of agents on one project. Each session needs a disposable, isolated computer. Here is the fleet shape."

Copilot Projects Need Own Sandboxes

GitHub used its Universe stage on 28 October to show copilot projects coordinating hundreds of agents on a single piece of work. Sessions continue in the cloud after the developer's laptop closes. That demo answers a workflow question and opens an infrastructure one. Every agent in that fleet needs a computer of its own, and somebody pays for the minutes.

The announcements stack up fast. Copilot Projects is available to all users, per the Moneycontrol Universe coverage. Copilot Fusion reached general availability as a multi-model orchestrator, and Copilot Automations adds scheduled agent workflows, as reported by Crypto Briefing.

What copilot projects changes for infrastructure

A single coding agent needs one sandbox. A coordinated fleet needs one sandbox per agent, created on demand, destroyed on completion, and isolated from every sibling session in the same project. Cross-agent leakage inside one fleet is exactly the failure mode OpenAI's red-team report described for shared hosts.

The cloud-session promise sharpens the requirement. When work continues while your machine is off, the sessions live on infrastructure that bills whether or not a human watches. Fleet cost becomes a function of session minutes, idle minutes and teardown discipline.

The fleet shape that survives contact with a demo

Give each agent a microVM with its own kernel, never a container slice of a shared box. One agent's escaped bug then stops at its own guest kernel. That is the boundary our agent isolation guide recommends for single agents, and fleets need it even more.

Bill per minute and power off between phases. A fleet that idles between agent turns pays for waiting. Per-minute metering with power-off turns waiting into zero, the same discipline we break down in safe agent sessions.

Clone snapshots instead of rebuilding environments. Identical starting images for a hundred agents mean one golden snapshot cloned per session. A hundred package installs racing the same registry disappear, and restore beats rebuild on speed and reproducibility.

Provision through the agent toolchain itself. A CLI or MCP server that creates and destroys sessions lets the orchestrator treat computers like variables. Our TypeScript SDK guide documents that pattern for per-user and per-agent provisioning.

Keep inbound closed by default. Fleet agents need outbound freedom for packages and APIs, while unsolicited inbound is pure attack surface. Private-by-default networking with per-port allowlists removes a whole class of cross-tenant probing.

What the benchmark numbers imply for fleets

According to Remio's Universe rundown, Fusion Max scored 60 on the Artificial Analysis Coding Agent Index, within two points of Claude Code on Opus 5.5 Max. It also ran at about half the average API cost and roughly 40% less time per task. Cheaper and faster tasks mean more tasks dispatched, which means more session minutes, not fewer.

We checked our product pages and provisioning docs on 29 October while working this arithmetic. The fleet pattern holds: cost per task falls on the model side and rises in session count on the compute side.

Verdict

We recommend treating multi-agent fleets as ephemeral infrastructure with four invariants. Own-kernel isolation per session, per-minute billing with power-off between phases, snapshot-cloned golden images, and closed inbound by default. The demo made hundreds of agents look easy; the infrastructure choices decide whether they stay cheap and contained.

Limitations

• GitHub's hundreds-of-agents figure is a stage demonstration; however, the infrastructure pattern follows from any multi-session orchestration.
• Benchmark scores compare model outputs, not fleet throughput, so task-count growth remains our inference rather than a measured rate.
• We have not run Copilot Projects against our own provisioning stack yet, and cannot publish latency figures for that pairing.
• Pricing comparisons reference vendor-published rates read in October 2026, but negotiated enterprise terms differ.

FAQ

Does each agent in a fleet need its own sandbox?

Yes for untrusted or parallel work. Shared sandboxes create cross-agent channels, while own-kernel microVMs keep a compromised session contained to itself.

How do fleets keep compute cost down between agent turns?

Power sessions off between phases so billing stops, and clone snapshots at start instead of rebuilding. Per-minute metering makes both choices pay off immediately.

Can provisioning be driven by the agent orchestrator itself?

Yes. A REST API, CLI or MCP server lets the orchestrator create, snapshot and destroy sessions programmatically, treating each computer as a scoped resource.