Cursor Release Notes

Cursor is now available in Jira.

Assign work items to Cursor, or mention @Cursor in a comment to kick off a cloud agent. Cursor uses the work item title, description, comments, and your team's repository settings to scope the task.

You can ask Cursor to fix bugs, add features, update tests, or investigate something described in the ticket. When the agent finishes, Jira shows completion updates and includes a link to the pull request.

Install the integration from Cursor integrations. You need Cursor admin access and Jira Commercial Cloud with Rovo enabled. Learn more in our docs.

Composer 2.5 is now available in Cursor.

It's a substantial improvement in intelligence and behavior over Composer 2. It is better at sustained work on long-running tasks, follows complex instructions more reliably, and is more pleasant to collaborate with.

We improved Composer by scaling training, generating more complex RL environments, and introducing new learning methods.

In addition to training Composer 2.5 on more difficult tasks, we improved behavioral aspects of the model like communication style and effort calibration. These dimensions are not well captured by existing benchmarks, but we find that they matter for real-world usefulness.

Composer 2.5 is built on the same open-source checkpoint as Composer 2, Moonshot's Kimi K2.5.

Together with SpaceXAI, we're training a significantly larger model from scratch, using 10x more total compute. With Colossus 2's million H100-equivalents and our combined data and training techniques, we expect this to be a major leap in model capability.

Training Composer 2.5

Composer 2.5 contains several new improvements to our training stack. These changes target both model intelligence and usability.

Targeted RL with textual feedback

Credit assignment during RL is becoming an increasingly difficult challenge as rollouts can span hundreds of thousands of tokens. When a reward is computed over an entire rollout, it may be hard for the model to tell which specific decision helped or hurt the outcome. This is especially limiting when we want to discourage a localized behavior, such as a bad tool call, a confusing explanation, or a style violation. The final reward can tell us that something went wrong, but it is a noisy signal for where it went wrong.

To address this, we trained Composer 2.5 with targeted textual feedback. The idea is to provide feedback directly at the point in the trajectory where the model could have behaved better. For a target model message, we construct a short hint describing the desired improvement, insert that hint into the local context, and use the resulting model distribution as a teacher. We use the policy with the original context as the student and add an on-policy distillation KL loss that moves the student's token probabilities toward the teacher's. This gives us a localized training signal for the behavior we want to change, while still retaining the broader RL objective over the full trajectory.

As an illustration of the text feedback process, consider a long rollout that includes a tool call error where the model attempts to call a tool that is not available. During the rollout, the model will receive a “Tool not found” error and continue making additional valid tool calls. The fact that it hit one error in the process of hundreds of tool calls will have a minimal impact on its final reward.

With text feedback, we can target this specific mistake by inserting a hint in the context of the problematic turn, such as “Reminder: Available tools…” with a list of available tools. This hint changes the probabilities for the teacher, lowering those for the wrong tool and increasing those for a valid replacement. For that turn only, we then update the student weights towards to the new probabilities.

During the Composer 2.5 run, we applied this method to a variety of model behaviors, from coding style to model communication.

Synthetic data

During RL training, Composer's coding ability improves substantially to the point where it begins to get most training problems correct. To continue increasing intelligence, we both select for and create harder tasks dynamically throughout the run. Composer 2.5 is trained with 25x more synthetic tasks than Composer 2.

We use a range of approaches for creating synthetic tasks that are grounded in real codebases. For example, one synthetic approach is feature deletion. For these tasks the agent is given a codebase with a large set of tests, and asked to delete code and files in such a way that the codebase remains functional while specific testable features are removed. The synthetic task is to reimplement the feature, and the tests are used as a verifiable reward.

One downstream consequence of large scale synthetic task creation is that it can cause unexpected reward hacking. As the model became more adept, Composer 2.5 was able to find increasingly sophisticated workarounds to solve the task at hand. In one example, the model found a leftover Python type-checking cache and reverse-engineered the format to find a deleted function signature. In another, it was able to find and decompile Java bytecode to reconstruct a third-party API. We were able to find and diagnose these problems using agentic monitoring tools, but they demonstrate the increasing care necessary for large scale RL.

Sharded Muon and dual mesh HSDP

For continued pretraining, we use Muon with distributed orthogonalization. After forming the momentum update, we run Newton-Schulz at the model's natural granularity: per attention head for attention projections, and per expert for stacked MoE weights.

The main cost is orthogonalizing expert weights. For sharded parameters, we batch same-shaped tensors, all-to-all shards into complete matrices, run Newton-Schulz, then all-to-all the result back to the original sharded layout. These transfers are asynchronous: while one task is waiting on communication, the optimizer runtime advances other Muon tasks, overlapping network and compute. This is equivalent to full-matrix Muon, but keeps the shard group busy; on the 1T model, optimizer step time is 0.2s.

This interacts closely with how we use HSDP for MoE models. HSDP forms multiple FSDP replicas and all-reduces gradients across corresponding shards. We use separate HSDP layouts for non-expert and expert weights: non-expert weights are comparatively small, so their FSDP groups can stay narrow, often within a node or rack, while expert weights hold most of the parameters and most of the Muon compute, so they use a wider expert sharding mesh.

Keeping these layouts separate also lets independent parallelism dimensions overlap: CP=2 and EP=8 can run on 8 GPUs instead of requiring 16 in a single shared mesh. This avoids wide communication for small non-expert state while spreading expert optimizer work over many GPUs.

Try Composer 2.5

Composer 2.5 is priced at $0.50/M input and $2.50/M output tokens.

There's also a stronger faster variant with the same intelligence at $3.00/M input and $15.00/M output tokens, a lower cost than the fast tiers of other frontier models. Similar to Composer 2, fast is the default option. See our model docs for full details.

Composer 2.5 includes double usage for the first week.

Multi-repo environments

Most engineering work in the enterprise spans multiple codebases and repositories. Larger organizations running microservices often have many repos that need to move in tandem. An agent confined to a single repo has limited usefulness because it can't reason across all the required context.

Cloud agents and automations now support multi-repo environments, building off our work on multi-root workspaces. You can configure a single environment with all the repositories an agent needs for its work, with re-use across sessions. With multiple repos in scope, agents can reason about how a change in one part of the codebase affects others and work across repos to deliver, test, and verify changes.

Hear directly from some of our customers using multi-repo environments:

We run Cursor Automations across public Slack channels at Amplitude. Multi-repo support is what makes them actually useful. An agent can investigate a reported issue, figure out which repos it touches, and open a PR with the fix in the right places with full context.

Steven Cheng
Senior Engineering Manager, Amplitude

Environment configuration as code

To make it easier to change, debug, and review environment definitions, we have improved Dockerfile-based configuration. This includes support for build secrets, making it easy to securely access private package registries directly from Dockerfiles. Build secrets are scoped to the build step and aren't passed to the running agent's environment.

We've also upgraded layer caching, so that only the updated layers of your image rebuild when you change the Dockerfile. Builds that hit the cache run 70% faster.

For teams that don't want to write Dockerfiles from scratch, Cursor can configure the Dockerfile for you. Cursor will inspect your repos, figure out the tools and dependencies required, and produce a configuration you can edit and version. This feature is in private beta and will be rolling out to Enterprise teams over the coming weeks.

Improved agent-led environment setup

As Cursor configures your environment, it will ask you questions, flag missing credentials, and validate that your environment is set up properly.

Cursor is also more aware of development environments. It will show you the version of the environment your agent is running in. If your environment configuration fails, Cursor will default to a base image with clear warning signs so that your cloud agents can keep running instead of immediately failing.

Environment governance and security controls

Every development environment now has its own version history that users can review and roll back. Admins can also restrict rollback permissions to admins only. An audit log captures every action team members take on environments, giving security teams full visibility into who changed what.

Egress and secrets can now be scoped at the development environment level. Teams can restrict outbound network access to a specific allowlist for one environment while leaving a different environment more permissive. Additionally, secrets configured for one environment aren't accessible from any other.

What's next

Today, environments are configured at a point in time and rebuilt when they fall out of sync with the codebase. We are building towards environment setups that evolve autonomously as your codebase evolves.

To get started with cloud agent development environments, read the docs or visit your cloud agents dashboard.

To take engineering tasks from start to finish, agents need a development environment similar to the setup on your laptop: cloned repositories, installed dependencies, credentials for internal toolchains, and access to build systems.

This release introduces new tools for teams to configure development environments for their agents. Cursor also can use these tools to set up and maintain environments for you. Together, this makes it easier for teams to run fleets of parallelized agents that handle tasks from end-to-end, inside development environments you fully control.

Multi-repo environments

Cloud agents and automations now support multi-repo environments, building off our work on multi-root workspaces. You can configure a single environment with all the repositories an agent needs for its work, with re-use across sessions.

Environment configuration as code

To make it easier to change, debug, and review environment definitions, we have improved Dockerfile-based configuration.

This includes support for build secrets, making it easy to securely access private package registries directly from your Dockerfiles. Build secrets are scoped to the build step and aren't passed to the running agent's environment.

We've also upgraded layer caching, so that only the updated layers of your image rebuild when you change the Dockerfile. Builds that hit the cache run 70% faster.

Improved agent-led environment setup

As Cursor configures your environment, it will ask you questions, flag missing credentials, and validate that your environment is set up properly.

Cursor will always show you the version of the environment your agent is running in. If your environment configuration fails, it will default to a base image with clear warning signs so that your cloud agents can keep running instead of immediately failing.

Environment governance and security controls

Every development environment now has its own version history that users can review and roll back. Admins can also restrict rollback permissions to admins only. An audit log captures every action team members take on environments, giving security teams full visibility into who changed what.

Egress and secrets can now be scoped at the development environment level. Secrets configured for one environment aren't accessible from any other.

Learn more about agent development environments in our announcement and docs.

Bugbot is switching from a $40 per seat per month subscription to usage-based billing for Teams and Individual plans.

For existing customers, this change will start at your next billing renewal after June 8th, 2026. For example, if you bought an annual subscription in May 2026, these changes will only take effect in May 2027.

Usage-based pricing

We are removing seat fees for Bugbot and transitioning to purely usage-based billing. For Teams, Bugbot will bill from on-demand spend; for Individuals, it will bill from included usage.

The average Bugbot run costs $1.00-$1.50, depending on PR size and complexity. Existing customers can switch to usage-based billing early in the Cursor dashboard.

Bugbot effort levels

With usage billing, you can now choose the effort level Bugbot uses when reviewing PRs. Users can configure Bugbot to think for longer and run deeper reviews, or set up custom logic that Cursor uses to dynamically determine review effort.

Default effort preserves how Bugbot works today: 80% of bugs identified are resolved by merge time. From our internal runs, Bugbot with high effort finds 35% more bugs while resolution rate stays constant at 80%.

Please let us know if you have any questions! You can check out this help article or email us at [email protected].

Teams admins and Individual plan users can now customize the effort level Bugbot uses for its PR reviews, with three different configurations:

• Default: Bugbot continues to use the same effort level as it does today. Optimized for efficiency and speed.
• High: Bugbot spends more time reasoning. Reviews are more expensive and take longer, but Bugbot may find more bugs.
• Custom: Describe in natural language when Bugbot should use default or high effort. Cursor will dynamically set effort levels based on your instructions.

Customers must be on usage-based billing for Bugbot to customize effort levels. Learn more in our docs and go to your Bugbot dashboard to get started.

This release introduces a new PR review experience, faster execution on plans through parallel agents, and new quick-action pills for common workflows.

PR review

A new PR review experience is now available in Cursor 3. Take PRs from creation to merge all in one place.

• The Reviews tab now shows inline review threads and top-level PR comments.
• The Commits tab gives you a focused view of commit history for the PR.
• The Changes tab makes it easier to navigate larger PRs with a file tree and changes picker.

You can see useful context like reviewer status and pending review banners, and quick action pills allow you to take next steps faster.

Build in parallel from plans

Cursor can now execute on plans faster by multitasking across tasks instead of tackling them one at a time.

Click "Build in Parallel" to have it identify independent parts of your plan and run them simultaneously using async subagents. Cursor will keep dependent steps in order when needed.

Split changes into PRs

When multitasking in Cursor, you can now use a built-in quick action to split changes into PRs.

It will use chat context to identify logical slices, default to independent PRs unless dependencies are required, create a backup snapshot, and propose a split plan for your approval.

Pin skills as quick actions

You can now pin your most commonly used skills as quick-action pills for faster access.

This release introduces updates for Enterprise admins: a new system for model controls, updated spend management, and more detail for usage analytics.

Model access controls

Admins can now set more granular allow or blocklists at the model and provider level. You can block entire providers or specific model configurations for speed and context window size.

Enterprises also have the option to block new providers or model versions by default.

Customers with existing blocklists will need to migrate to the new system by June 1st. Admins should go to their

team model settings

in the Cursor dashboard to get started.

Soft spend limits and intelligent alerts

Admins can now set soft limits instead of hard limits to avoid blocking users. Cursor can also monitor usage and sends automatic alerts to users reaching 50%, 80%, and 100% of their soft or hard limits.

This keeps users productive while giving admins and users visibility into consumption patterns.

Go to the

spend management settings

in the Cursor dashboard to get started.

Updated usage analytics tab

Admins can now filter usage by specific users, or break it down by product surface: clients, Cloud Agents, automations, Bugbot, and Security Review.

Go to the

usage analytics tab

in the Cursor dashboard to get started.

Admins can now create a team marketplace without connecting a repository first. Add, remove, and configure install behavior for first-party plugins directly in team marketplace settings.

Plugins bundle capabilities like MCP servers, skills, subagents, rules, and hooks that extend agents with custom functionality. Each plugin can be distributed in one of three ways:

1. Default Off: users can discover and opt in
2. Default On: users get the plugin installed by default, but can opt out
3. Required: users always have the plugin and cannot uninstall it

Get started in the Cursor dashboard.

Cursor Security Review is now in beta on Teams and Enterprise plans. You can run two types of always-on security agents: Security Reviewer and Vulnerability Scanner.

Security Reviewer checks every PR for security vulnerabilities, auth regressions, privacy and data-handling risks, agent tool auto-approvals, and prompt injection attacks. It will leave inline comments at the exact diff location with severity and remediation.

Vulnerability Scanner runs scheduled scans of your codebase to check for known vulnerabilities, outdated dependencies, and configuration issues. You can configure it to send updates of its findings in Slack.

Customize Cursor-managed security agents by adjusting triggers, adding your own instructions, giving them custom tooling, and choosing how outputs are shared. For example, you can plug in MCP servers for your existing SAST, SCA, and secrets scanners for Cursor to use as part of the review.

We're also continuously improving the runtime, harness, and models powering Cursor Security Review for a strong out-of-the-box experience.

Security agents draw from your existing usage pool. Admins can enable Security Review in the Cursor dashboard to get started.

Deploy agents to production quickly

We're introducing the Cursor SDK so you can build agents with the same runtime, harness, and models that power Cursor.

The agents that run in the Cursor desktop app, CLI, and web app are now accessible with a few lines of TypeScript. Run it on your machine or on Cursor's cloud against a dedicated VM, with any frontier model.

Coding agents are evolving from interactive tools for individual developers to programmatic infrastructure for organizations. The Cursor SDK lets you deploy agents without the overhead of building and maintaining the entire agent stack. Many teams are invoking agents directly from CI/CD pipelines, creating automations for end-to-end workflows, and embedding agents into their core products.

The Cursor SDK is now available in public beta for all users. Just run

npm install @cursor/sdk

to get started.

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

const agent = await Agent.create({
  apiKey: process.env.CURSOR_API_KEY!,
  model: { id: "composer-2" },
  local: { cwd: process.cwd() },
});

const run = await agent.send("Summarize what this repository does");

for await (const event of run.stream()) {
  console.log(event);
}

The Cursor SDK eliminates this complexity so you can focus on building useful agents.

Use production-ready cloud infrastructure

Cloud sessions initiated from the SDK run on the same optimized runtime we use for Cloud Agents. Each agent gets its own dedicated VM with strong sandboxing, a clone of the repo, and a fully configured development environment.

Agents keep going when your laptop sleeps or network drops. You can stream the conversation and reconnect later. When the agent finishes, it can open a PR, push a branch, or attach demos and screenshots.

// Initiate cloud agent to start a task...:
const agent = await Agent.create({
  apiKey: process.env.CURSOR_API_KEY!,
  model: { id: "gpt-5.5" },
  cloud: {
    repos: [{ url: "https://github.com/cursor/cookbook", startingRef: "main" }],
    autoCreatePR: true,
  },
});

const run = await agent.send("Fix the auth token expiry bug");
console.log(`Started ${run.id}`);

// ...check back in later, from anywhere:
const result = await (await Agent.getRun(run.id, { runtime: "cloud", agentId: run.agentId })).wait();
console.log(result.git?.branches[0]?.prUrl);

The SDK uses our updated Cloud Agents API, which allows cloud agent runs to show up in Cursor's Agents Window and web app. You can start a task programmatically and then jump into Cursor to inspect progress or take over the work.

When you need a different runtime, the same SDK can run agents on self-hosted workers, keeping code and tool execution inside your network, or locally on your machine for fast iteration.

Use the full Cursor harness

Agents launched through the SDK benefit from the same harness that powers Cursor across our desktop app, CLI, and web app:

• Intelligent context management: Codebase indexing, semantic search, and instant grep help agents get to the right outcome faster and more efficiently.
• MCP servers: Agents can connect to external tools and data sources over stdio or HTTP, either through a .cursor/mcp.json config file or passed inline on the call.
• Skills: Agents pick up skills automatically from your repo's .cursor/skills/ directory.
• Hooks: Observe, control, and extend the agent loop across cloud, self-hosted, and local with a .cursor/hooks.json file.
• Subagents: Delegate subtasks to named subagents with their own prompts and models, which the main agent spawns via the Agent tool.

Build on any model

The Cursor SDK gives you access to every model supported in Cursor. Route agents to the best model for the task at hand, with your desired balance of cost and capability, with a single field change.

And with Composer 2, a specialized coding model that achieves frontier-level performance at a fraction of the cost of general-purpose models, you get the best combination of intelligence and efficiency for most coding agent tasks.

What developers are building

Teams are using the Cursor SDK to ship custom agents faster. For example, programmatic agents that are kicked off directly from CI/CD to summarize changes, identify root causes for CI failures, and update PRs with fixes. Others are building custom agent platforms like internal applications that let GTM teams query product data without writing code.

Some customers are even embedding Cursor directly into customer-facing products, where end users now get an agent experience without leaving the host application.

Hear directly from some of our customers building on the Cursor SDK:

"Cursor offers a great cloud experience for running many agents in parallel from the editor and CLI. We're excited about the SDK as a path to running our own programmatic agents on that same cloud runtime, without managing VMs or working around memory limits, to keep our codebase healthy without constant developer intervention." — George Jacob, Senior Engineering Manager, Faire

Start from a sample project

We've added a few starter projects to a public GitHub repo that you can fork and extend for your own use cases:

• Quickstart: A minimal Node.js example that creates a local agent, sends one prompt, and streams the response.
• Prototyping tool: A web app for spinning up agents to scaffold new projects and iterate on ideas in a sandboxed cloud environment.
• Kanban board: An agent-powered kanban tool where engineers can drag a card and have agents programmatically pick up the work, open a PR, and post the result back as an attachment.
• Coding agent CLI: A lightweight command-line interface that lets you spawn Cursor agents from your terminal.

What's next

The Cursor SDK is available to all users and is billed based on standard, token-based consumption pricing.

We are continuing to invest in the Cursor SDK, with a focus on making it even easier for teams to build programmatic agents across more languages, workflows, and deployment patterns.

Learn more by reading our docs. You can also use Cursor with our Cursor SDK plugin to help you start building.

We're introducing the Cursor SDK so you can build agents with the same runtime, harness, and models that power Cursor.

The agents that run in the Cursor desktop app, CLI, and web app are now accessible with a few lines of TypeScript. Run it on your machine or on Cursor's cloud against a dedicated VM, with any frontier model.

Run npm install @cursor/sdk to get started and use the Cursor SDK plugin so Cursor can help you build.

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

const agent = await Agent.create({
  apiKey: process.env.CURSOR_API_KEY!,
  model: { id: "composer-2" },
  local: { cwd: process.cwd() },
});

const run = await agent.send("Summarize what this repository does");

for await (const event of run.stream()) {
  console.log(event);
}

We built a few sample projects that you can access from a public repo. Fork and extend them for your own use case.

The Cursor SDK is now available for all users in public beta and is billed based on standard, token-based consumption pricing. Learn more in our announcement and docs.