Cursor 3.5's /loop: Async Agents That Keep Running After You Close the Tab

Cursor 3.5 dropped on May 20 with two features that change how you work with long-running agents. /loop lets a local agent run on a schedule — fixed interval, dynamic pacing, or until a goal condition is hit. And shared canvases turn the interactive dashboards that agents build into URLs your team can open in a browser. Together they push Cursor closer to an agent runtime than an editor.

The difference from existing cloud-based Cursor Automations is that /loop runs on your machine. That means it can touch local files, hit a localhost dev server, and use the same context (rules, MCPs, skills) as your interactive session. No special configuration to give a cloud agent permissions — your local agent already has them.

Three Modes of /loop

The command takes either an interval, a goal condition, or nothing at all. Each picks a different scheduling mode:

# Fixed interval — runs every 5 minutes
/loop 5m check deploy status and ping me on Slack if it fails

# Goal-driven — runs until condition is met
/loop until tests pass: keep iterating on the failing test in user-service

# Dynamic pacing — agent decides when to wake itself
/loop watch the staging API for 5xx errors and analyze patterns

Fixed interval is the most predictable — you know the cadence and the cost. Goal-driven is the most useful for iteration loops like 'fix this failing test' where you don't know how many turns it will take. Dynamic pacing is the riskiest — the agent picks its own wake schedule and can spike costs if it decides 30-second polling is appropriate.

Where /loop Beats Cloud Automations

Cursor's cloud Automations (shipped earlier this spring) run a scheduled agent on Cursor's infrastructure. They're great for tasks that don't need your local environment — Slack digests, scraping a public API, sending an email. But they can't see your project files, can't run your test suite against your local database, and can't interact with services you've port-forwarded for development. /loop fills that gap. Anything that needs your laptop's state — your repo, your local stack, your secrets in .env — runs better as a /loop.

The trade-off is uptime. Cloud Automations keep running when your laptop is closed. /loop stops the moment you suspend or quit Cursor. So the rule is simple: ephemeral local work goes in /loop, persistent observability goes in Automations.

Shared Canvases — The Output Side

The other big 3.5 feature is canvas sharing. When a Cursor agent builds an interactive canvas — a dashboard, a chart, a custom interface — you can now click Share to publish a live snapshot to your team. Teammates open the link in a browser with read-only access. The Cursor Dashboard shows every shared canvas across your team.

Canvases pair well with /loop. Set up a /loop that polls something and writes results to a canvas, share the canvas link, and your team gets a live view without anyone needing to install Cursor. It's a low-effort way to ship internal dashboards from inside the editor.

The Cost Trap

A /loop agent costs the same per turn as an interactive agent. So a goal-driven loop that takes 40 iterations to fix a flaky test costs about 40x a normal turn. Most teams hit a cost surprise within a week of adopting /loop because they set goals that turn out to be harder than expected. Two guardrails help.

# Cap maximum turns regardless of goal completion
/loop --max-turns 20 until tests pass: fix failing test

# Cap maximum wall time
/loop --max-runtime 30m monitor staging logs for errors

# Both together — whichever fires first stops the loop
/loop --max-turns 50 --max-runtime 1h fix all flaky tests in CI

Set these on every /loop you start. The defaults are unbounded, which is the right choice for an experienced user but a bad one for the first week. Treat unbounded /loop the way you'd treat a runaway recursive script — useful when it terminates, expensive when it doesn't.

Use Cases That Actually Pay Off

Three patterns hold up well in practice. Test iteration loops — set a goal of 'this test passes,' cap at 20 turns, walk away. Deploy monitoring — short interval poll, ping a notification channel on regression, run for 1 hour after a deploy. Documentation refresh — read recent commits every hour, update a docs canvas, share the canvas with the team. Each gives a clear stop condition and a tight cost ceiling. Open-ended 'watch and learn' loops sound clever but rack up bills without producing much.