Cursor's Cloud Agents Now Manage 500 Repos and Start 5x Faster

Cursor’s latest cloud-agent release adds three capabilities for teams running agents outside the editor: shareable interactive canvases, a public-beta Environments API, and multi-repository environments that support up to 500 repositories while starting roughly five times faster.

• Shareable output: Cloud agents can publish dashboards and reports as interactive links.
• Scriptable setup: Developers can create, inspect, update, and delete agent environments through an API.
• Larger environments: Agents can work across hundreds of repositories, although the current API documentation still lists a lower request limit.

Canvases become handoff artifacts

Canvas, introduced earlier this year, lets agents render persistent React interfaces inside the Agents Window. Those interfaces can contain charts, tables, code diffs, custom logic, and controls that update as the agent works.

The release adds distribution to that workflow. A cloud agent can build a dashboard or report during a run, then expose the completed canvas through a shareable URL. Teams can use the result for incident summaries, migration reports, test analysis, or any task that benefits from a structured visual output.

Shared canvases can open full-screen in a browser and include buttons tied to specific prompts. That makes them useful as lightweight internal tools, since a teammate can inspect an agent’s findings and trigger a predefined follow-up action from the same interface.

Environment setup gets a control plane

The public-beta Environments API extends Cursor’s Cloud Agents API v1 with programmatic control over agent runtime configurations. Developers can now manage both the agents performing work and the environments in which those agents start.

A Cursor environment defines the repositories and environment.json configuration available to an agent. These configurations were previously managed through the Cloud Agents dashboard. The new endpoints expose environments as resources that applications can create, list, retrieve, update, and delete.

The API enables several practical workflows:

• Create an isolated environment for each ticket or incident, then remove it when the work is complete.
• Store environment definitions in an infrastructure repository and synchronize them through CI.
• Launch agents from webhooks or pipelines with a controlled repository set and runtime configuration.
• Record environment changes in existing audit, approval, and rollback systems.
• Standardize agent setup across teams without requiring manual dashboard configuration.

A two-call TypeScript flow

import { Cursor } from "@cursor/sdk";

const apiKey = process.env.CURSOR_API_KEY;

if (!apiKey) {
  throw new Error("Missing CURSOR_API_KEY");
}

const cursor = new Cursor({ apiKey });

const environment = await cursor.environments.create({
  name: "payments-hotfix",
  repositories: [
    { url: "https://github.com/acme/api" },
    { url: "https://github.com/acme/web" },
    { url: "https://github.com/acme/infra" },
  ],
});

await cursor.agents.create({
  env: { id: environment.id },
  prompt:
    "Reproduce the 500 response on /checkout and open a pull request with a fix and regression test.",
});

This example follows the TypeScript SDK shape: it creates a reusable environment, then starts an agent inside it. Production integrations should keep API keys on the server, persist returned resource IDs, and handle failures during both environment creation and agent launch.

The beta label also matters for automation. Teams should pin SDK versions, validate API responses, and isolate Cursor-specific calls behind a small integration layer so schema changes do not spread through CI or internal tooling.

Five hundred repos, one docs gap

Cursor now supports up to 500 repositories in an environment. Multi-repository agents can inspect dependencies and coordinate changes across services, libraries, infrastructure code, and client applications during one run.

Cursor also reports that large multi-repository environments start roughly five times faster. The release does not publish the benchmark configuration, so teams with large polyrepo estates should measure startup time against their own repository sizes, dependency installation, and initialization scripts.

The current API reference still caps repository arrays at 300 for agent-creation and environment-creation request bodies. The announced 500-repository limit may therefore be unavailable through some API paths until the schema and request validation are updated. Integrations should treat 300 as the documented maximum and test for the higher limit before depending on it.

Agent performance at this scale will depend on more than repository count. Repository selection, indexing, dependency boundaries, setup scripts, and prompt scope will determine whether the agent receives useful context or spends its run searching unrelated code.

The workflows that gain most

Together, these changes give cloud agents a shareable output surface, a scriptable runtime control plane, and enough repository capacity for large service estates. Cursor says autonomous cloud agents now create more than 35% of pull requests merged by its engineering team, up from 30% when the feature launched in February. That figure reflects Cursor’s internal workflow and workload mix.

The release is particularly relevant to workflows that span people, systems, or repositories:

• Nightly triage agents that publish an interactive dashboard for the engineering team.
• Incident-response agents that inspect and patch several dependent services.
• Migration agents that coordinate API, client, infrastructure, and documentation changes.
• SDK-driven pipelines that launch many isolated refactors in parallel.
• Compliance jobs that collect findings in a reviewable canvas and preserve run metadata.

Single-repository tasks launched by one developer will see fewer operational gains. The larger benefit goes to teams treating agents as shared infrastructure that must be provisioned, audited, integrated with CI, and handed off through durable outputs.

Guardrails for production runs

Automating environment creation increases the number of systems an agent can reach and the speed at which configurations can spread. A production rollout should include controls for credentials, repository access, generated changes, and interactive canvas actions.

• Grant each environment the minimum repository and service permissions required for its task.
• Keep production credentials separate from development and incident-response environments.
• Version environment.json files and require review for changes to setup scripts or secrets.
• Record environment IDs, agent run IDs, commits, pull requests, and initiating users in audit logs.
• Review shared canvases for sensitive data and restrict prompt-backed buttons to approved actions.
• Enforce repository-count limits in client code until Cursor resolves the 300-versus-500 documentation gap.