Cursor Background Agents: What Changes When AI Code Is Async

Here’s a number that should make you pause: a single cloud agent task can spin up a fresh Ubuntu VM, clone your entire repository, run a multi-file refactor, execute tests, and open a pull request — all while you’re in a meeting or working on something else entirely. That’s not a hypothetical. It’s the core pitch behind Cursor’s Background Agents (officially renamed Cloud Agents), and it represents a fundamental shift in how AI-assisted development actually feels in practice.

The feature launched in Cursor 0.50 in May 2025 as an early preview and rolled out to all Pro users in v1.0. Since then, Cursor has built an entire async agent platform around it — complete with a unified Agents Window, multi-platform triggers, and a pricing structure that’s more nuanced than most teams realize. If you’re evaluating whether cloud-based async agents belong in your workflow, the answer depends on three things: your tolerance for context-switching, your team’s spending predictability needs, and how much you trust Cursor’s vertical integration trajectory.

How Cloud Agents Actually Work Under the Hood

Background Agents run asynchronously in isolated cloud Ubuntu VMs, cloning repositories, working on dedicated agent/ branches, and opening pull requests upon completion. Each agent gets its own isolated environment — a separate VM with full terminal access, package installation capabilities, and web browsing. Your local machine never needs to be running while the agent works.

The isolation mechanism matters. Every agent task creates its own agent/ branch from your main branch, so your working branch stays untouched. When the task finishes, the agent opens a pull request with a summary of every change it made. You get an email, a Cursor desktop notification, and a Slack message (if configured) when the PR is ready.

The Agents Window, introduced in Cursor 3 in April 2026, serves as the unified workspace for managing agents running locally, in the cloud, in worktrees, or on remote SSH. Cloud agents produce demos and screenshots of their work for verification. You can shift a session from cloud to local when you want to make edits on your own machine, or from local to cloud to keep it running while you’re offline.

Trigger options have expanded beyond the IDE. Background Agents can be triggered from Slack (@cursor in any thread), GitHub (@cursor on issues/PRs), and Linear. The multi-platform trigger system means a product manager can kick off an agent task from a Slack message without ever opening a code editor.

The Pricing Contradiction Most Teams Miss

Here’s where it gets complicated. Cloud Agents are not included in standard usage plans (Pro, Ultimate) and are billed at API-pricing — on-demand usage must be enabled and a spending limit set before launching the first cloud agent, per Cursor’s community forum. This is a direct contradiction to Cursor’s official Teams pricing blog, which states that all Teams seats include a Composer/Auto usage pool reserved for first-party Cursor models, and Cloud Agents are a native Cursor feature.

The practical implication: if you’re on a Pro plan and want to use cloud agents, you need usage-based spending enabled with a minimum limit, and you’re paying API rates for every agent run. For teams on the Teams plan, the June 2026 pricing update introduced two separate usage pools per seat — Composer/Auto for first-party Cursor models, and Third-Party API for third-party models — but the question of whether cloud agent usage draws from these pools or requires separate on-demand billing remains ambiguous.

Requirements to use Background Agents include: Cursor Pro plan or higher, usage-based spending enabled, Privacy Mode disabled (the agent needs to send your code to Cursor’s cloud), and a connected GitHub or GitLab account with read-write permissions.

The June 2026 Teams Pricing Update: Two Tiers, Two Pools

Cursor’s June 2026 Teams pricing update restructured the team plans around a two-pool model designed to steer teams toward Cursor’s first-party models.

Standard Teams seats cost $32 per seat per month on annual plans and $40 per seat per month on monthly plans. Premium Teams seats cost $96 per seat per month on annual plans and $120 per seat per month on monthly plans, providing 5x the usage of Standard seats. Every Teams seat includes two separate usage pools: Composer/Auto for first-party Cursor models and Auto, and Third-Party API for third-party models.

The Composer pool on a Premium seat is expected to cover a full month of heavy agent usage for 99% of users, per Cursor’s blog. The strategic logic is clear: by making Composer 2.5 (frontier performance at a fraction of third-party cost) the default, economically rational choice for heavy agent users, Cursor reduces its reliance on external model providers and locks teams into its stack.

For a 50-developer Cursor Teams deployment with 2 Premium seats and 48 Standard seats on annual billing, the math works out to $1,728 per month ($20,736 per year). That’s a meaningful number for budget planning, but it doesn’t include cloud agent overage costs, which depend entirely on usage patterns and model selection.

	Standard	Premium	Windsurf Teams
Best for	Regular coders, light-to-moderate agent use	Daily Claude Opus, overnight agent runs	Teams wanting flat-rate simplicity
Monthly price	$40/seat	$120/seat	$40/seat
Annual price	$32/seat	$96/seat	—
Usage vs. Standard	1× baseline	5×	Quota-based, not pooled
The catch	Third-party pool runs dry faster than Composer pool	$96/seat stings if usage is only moderate	No per-user seat type mixing

The Context Reset Problem Nobody Talks About

Cloud agent context cannot be reset on an existing VM — spinning up a new VM is required for a fresh context, per the community forum. This is a genuine workflow limitation that carries cost implications. If you’re running a ralph-inspired workflow that regularly resets context, you’re spinning up dozens of VMs, and each one incurs additional cost.

The workaround is to start small, set spending limits, and monitor usage closely. But the structural issue remains: cloud agents optimize for long-horizon, uninterrupted tasks. If your workflow requires frequent context resets, local agents in worktrees may be more cost-effective, even if they block your local machine.

This tradeoff is worth internalizing. Cloud agents deliver asynchronous, unblocked productivity for developers running long-horizon agent tasks — but they sacrifice the context control and cost efficiency that local agents provide. The two aren’t interchangeable; they serve different workflow patterns.

Automations and the Vertical Integration Endgame

Cursor 3.8 (June 18, 2026) introduced the /automate skill for plain-language automation setup, Slack emoji triggers, five new GitHub triggers, and enabled computer use by default for cloud agents in Automations, per the changelog. The automation ecosystem now supports multi-repo and no-repo modes, with templates for Slack digests, product analytics, and customer health monitoring.

Bugbot, Cursor’s automated code review tool, was updated in June 2026 to be 3x faster, 22% cheaper per review, finding 10% more bugs, and completing 90% of runs in under 3 minutes. These gains are powered by harness improvements and the Composer 2.5 model that now underpins Bugbot, per Cursor’s blog.

The pattern across all these updates is consistent: Cursor is aligning its pricing structure, product features, and infrastructure investments to monetize the shift from synchronous, local AI coding assistance to persistent, cloud-based agentic workflows. The two-pool usage structure and Premium tier are primarily designed to substitute Cursor’s first-party Composer model for third-party frontier models in most team workflows. By making Composer 2.5 the default, economically rational choice for 99% of heavy agent users, Cursor reduces its reliance on external model providers and locks teams into its stack ahead of its proprietary SpaceX-trained model launch.

The June 2026 Compile conference made the vertical integration strategy explicit. Cursor announced Origin, a Git hosting platform built for parallel AI agents rather than human developers, and a proprietary 1.5-trillion-parameter model being trained from scratch on SpaceX’s Colossus supercomputer. Origin is waitlist-only ahead of a fall 2026 launch, with no public pricing yet.

Teams that adopt Cursor for agentic workflows today will face significant switching costs within 12-18 months as its proprietary model, Origin Git forge, and automation ecosystem become more deeply integrated. Migration to alternative tools becomes increasingly costly with each quarter.

When Cloud Agents Make Sense (And When They Don’t)

Cloud agents are worth the cost when you have long-horizon, well-scoped tasks that don’t require frequent context resets: multi-file refactors, test generation, documentation updates, dependency upgrades, and bug triage across large codebases. They’re also valuable when you want to dispatch a task from Slack or GitHub and come back to a PR hours later.

They’re not worth the cost when you need tight context control, when your tasks require frequent back-and-forth clarification, or when you’re already hitting your usage limits on third-party models. Local agents in worktrees remain the better choice for interactive, iterative development where you need to redirect the agent mid-task.

The honest recommendation: start with a small, well-defined task. Set a spending limit. See how the VM cost and context behavior actually play out for your codebase before committing to a cloud-first agent workflow. The feature is genuinely useful — but the pricing ambiguity and context reset limitation mean it’s not the universal upgrade it might appear to be.