Cursor Cloud Agents Now Run on Your Own Infrastructure

Cursor shipped a genuinely infrastructural change on September 3, 2026: cloud agents can now run on machines you manage, including pools that auto-scale with demand, or through supported sandbox providers — while the agent loop itself stays inside Cursor. The framing from Cursor's own announcement: "this lets you give agents access to internal services or specialized hardware, while the agent loop stays in Cursor."

TL;DR

Why "the loop stays in Cursor" is the important detail

The headline capability — pointing a cloud agent at your own machines — is not new in isolated form; plenty of self-hosted CI/CD and remote-execution patterns already exist. What's specific to this release is the split: orchestration stays centralized in Cursor, while execution moves to wherever you point it. That means the agent's planning, tool-call sequencing, and session state remain managed by Cursor's product, while the actual code execution — the part that needs access to your VPN-gated internal API, your specific GPU hardware, or a compliance-scoped environment — happens on infrastructure your team controls.

This is the same shape of problem MCP solves for tool access — decoupling "where the agent's brain runs" from "what it's allowed to touch" — applied here to compute rather than tools specifically.

The supported providers, and what each is good for

Notably, several of these (E2B, Modal, Daytona) are already familiar names in the agent-sandboxing space — Cursor plugging directly into them rather than building a fully proprietary sandbox layer is a pragmatic choice that mirrors how agent harnesses increasingly compose existing infrastructure rather than reinventing it.

What teams asked, and what's still unclear

The announcement thread surfaced several practical questions that Cursor's public posts don't fully answer yet:

• Bring-your-own-key support — whether teams can use their own API keys/billing when running on self-managed infrastructure, rather than Cursor-metered usage, wasn't confirmed in the launch posts.
• GitLab / non-GitHub repo support — the announcement's examples lean on GitHub-centric workflows; teams on other Git hosting should verify support directly.
• GPU/hardware access specifics — whether "specialized hardware" access is a real guarantee (e.g. actual GPU passthrough for something like WebGPU-dependent projects) or limited to whatever the underlying sandbox provider exposes wasn't spelled out.

The honest takeaway: this is a real and useful infrastructural unlock, but teams evaluating it should test the specific provider and workload they care about rather than assuming blanket support based on the announcement alone.

Why "orchestration vs. execution" is the right way to think about this

It's easy to read "cloud agents on your own infrastructure" as Cursor simply adding another deployment target, but the more useful mental model is the split between where an agent thinks and where an agent acts. Cursor's product — the planning loop, the conversation history, the tool-call sequencing, the UI you interact with — is the "thinking" layer, and it stays centralized in Cursor regardless of where you point execution. What moves is purely the "acting" layer: the sandbox or machine where code actually runs, tests actually execute, and — critically — where network calls to internal systems actually originate from.

This split matters because it's the same shape of tradeoff every "bring your own compute" feature across the industry ends up making: centralize the parts that benefit from being centralized (product experience, session state, model access, billing) and let users control the parts where their specific constraints (network topology, hardware, compliance boundary) genuinely differ from what a generic hosted environment can offer. Cursor choosing to support this via well-known third-party sandbox providers rather than only self-managed machines is a pragmatic middle path — most teams don't want to operate their own sandbox infrastructure from scratch, so plugging into E2B, Modal, or Daytona gets them most of the "reach my own network and hardware" benefit without the operational burden of building a sandboxing layer themselves.

Practical scenarios this actually unlocks

A few concrete situations where this genuinely changes what's possible, versus purely hosted cloud agents:

• An agent that needs to query an internal, VPN-gated API — a staging database, an internal admin tool, a service with no public endpoint — can now do so if the agent's execution environment is on infrastructure with network access to that service, something a fully Cursor-hosted sandbox structurally couldn't do.
• An agent that needs GPU access for a task like running a local model, doing image/video processing, or validating a WebGPU-dependent change, can run on a provider like Modal that's built around exposing that kind of hardware, rather than being limited to whatever generic compute a hosted agent sandbox provides.
• A team with compliance requirements about where code execution happens (data residency, audit requirements, restricted environments) can point agent execution at infrastructure that already satisfies those requirements, rather than needing a separate compliance review for Cursor's hosted execution environment specifically.
• Cost-sensitive, high-volume agent workloads may be cheaper to run on infrastructure a team already pays for and has spare capacity on, versus metered hosted-agent compute — though this depends heavily on Cursor's own pricing model for this feature, which wasn't fully detailed in the launch announcement.

How this compares to what Anthropic and OpenAI shipped this same week

This announcement landed the same week as Anthropic's background computer use for Claude Cowork and Code, and OpenAI's earlier Codex computer use rollout for Windows and mobile control. Reading all three together is more useful than reading any one in isolation, because each is solving a genuinely different piece of the "where does an agent actually run" question rather than competing head-to-head on the same capability.

Anthropic's move is about attention — decoupling whether a task needs the user watching in real time from whether Claude can act on a real desktop at all. OpenAI's Codex move is about platform coverage — extending computer-use control to Windows and mobile, environments a Mac-first or browser-first agent tool wouldn't otherwise reach. Cursor's move here is about network and hardware reach — letting an agent's execution environment sit inside a team's own infrastructure boundary, something no amount of platform support or background operation on a vendor's own hosted compute could solve on its own, since the fundamental constraint (a private network, specific hardware) is about where the agent runs, not what it's capable of once it gets there.

None of these three capabilities substitute for each other. A team could reasonably want all three: an agent that operates in the background without requiring constant supervision, that works across whatever platform its developers use day to day, and that can execute against internal infrastructure when a task calls for it. That combination — not any single vendor's individual feature — is probably the more accurate description of where agentic coding tooling is actually heading through the rest of 2026.

Honest limitations

• Plan-level availability and bring-your-own-key support are not clearly specified in Cursor's public launch posts as of this writing.
• "Specialized hardware access" is described in general terms — actual GPU or hardware passthrough depends on what the chosen sandbox provider itself supports, not a Cursor-specific guarantee.
• Running agents against real internal services raises the same access-control questions as any remote-execution tooling — teams should scope credentials and network access deliberately rather than granting broad internal-network reach by default.

Closing

This is Cursor addressing a real gap: cloud-hosted coding agents are only as useful as what they can reach, and plenty of real engineering work depends on internal services or specific hardware a generic hosted sandbox was never going to have access to. Combined with the same week's background computer use from Anthropic, the pattern across agent tooling in September 2026 is consistent: labs are decoupling agent orchestration from a single fixed execution environment, letting teams choose where the actual work happens while keeping the agent's planning and control loop centralized.

Related on explainx.ai

• What Is MCP (Model Context Protocol)? Complete Guide
• What Is an Agent Harness? Complete Guide
• Claude Code vs Cursor vs GitHub Copilot
• Claude Can Now Use Your Computer in the Background
• Cursor Router: Auto Model Selection
• What Are Agent Skills? Complete Guide
• Claude Commerce Agents: Open-Source Blueprint

Sources

• @cursor_ai on X — cloud agents on your own infrastructure announcement
• cursor.com — cloud agent infrastructure documentation

This post reflects Cursor's official announcement as of September 3, 2026. Some details (plan gating, bring-your-own-key support) were unspecified in the public launch posts at time of writing — verify current specifics against Cursor's own documentation.