2 min lesson
The mechanic, the proof, and grind mode
Use "Reserve grind mode for big migrations or building from scratch" to say what you would do next.
Step 1 of 2
The mechanic, the proof, and grind modesay these precisely
Three facts make the Cloud Agent story credible instead of hand-wavy. First, the mechanic: a cloud agent spins up a Cursor-managed VM with its own desktop and terminal, checks out the repo from connected source control, implements the work and opens a PR - then the VM is torn down, so the codebase doesn't persist long-term. It uses the same models and harness as the desktop (same quality), and it doesn't touch your local RAM or disk, so you can run as many as you want.
The single biggest driver of async-work adoption (early 2026) was artifacts: the cloud agent navigates its own virtual desktop (it has its own mouse), makes a change, spins up a browser, tests it, records a video and screenshots and self-corrects on console errors - change, film, process, repeat. On completion it returns the walk-through video plus screenshots, type-checks and test results, and can upload the video straight to the PR. The decision rule falls right out of this: if output is reviewable via an artifact, push it async; if it's fuzzier, stay foreground.
Third, grind-until-done (a.k.a. grind mode, in beta) is a toggle on long-running tasks that lets a cloud agent grind for hours - or as long as needed - on the very hardest work. The guardrail matters as much as the feature: most tasks don't need it; just toggling cloud on and asking "implement this feature" already does a very good job. Reserve grind mode for big migrations or building from scratch - real war stories include migrating Poetry to uv and a SQL v4-to-v5 upgrade, and a researcher building a Chrome-level browser across thousands of commits. Async cloud agents can run minutes, hours, days, or in some cases weeks on a long-horizon harness.