Cursor Updates & Release Notes

This release brings Cursor Automations to the Agents Window and introduces the ability to configure automations with multiple attached repos or no repos at all.

For the next 7 days, all agent runs for newly created automations are 50% off.

Automations in the Agents Window

Cursor Automations are now available in the Agents Window, in addition to cursor.com/automations. Create and manage your automations in the same workspace as your agents.

Multi-repo automations

A lot of engineering work spans more than one codebase. You can now attach multiple repos to an automation so agents reason across all required context and work across repos to deliver, test, and verify tasks.

No-repo automations

Many useful automations exist apart from code, where agents monitor your tools and act on key signals. You can now create automations without an attached repository.

We've added five new templates for no-repo automations to the Cursor Marketplace to help you get started:

• Slack digest agent: Summarizes unread DMs and key Slack channels every morning and prioritizes them by importance
• Product analytics agent: Delivers a weekly digest of key metrics from your data warehouse like Databricks
• Product FAQ agent: Watches a Slack channel for questions and writes a first response based on docs, codebase context, and past threads
• Product finance agent: Pulls financial data from a billing provider like Stripe for recurring revenue reports
• Customer health agent: Monitors key systems like Granola, Slack, and Databricks and flags accounts where health signals are shifting

Read our docs to learn more.

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.

This release introduces quality-of-life improvements to the Agents Window.

Full-screen tabs

Full screen maximizes the right panel so you can focus on a single tab.

Files, changes, canvases, PRs, browsers, and terminals can expand to fill the entire working area. This replaces the agent chat with a floating prompt bar.

Enter and exit full screen by clicking on the expand/contract button in the panel header, using the command palette, or pressing Cmd/Ctrl+Shift+M.

Compact chat responses

Compact chats give you a tighter view of your agent conversations so you can read threads more quickly without losing important context.

Customize tool call density to control how much of the agent's tool activity is shown in each response:

• Compact: shows concise results with minimal tool traces
• Balanced: includes important intermediate steps
• Detailed: provides near-complete step-by-step context

Improvements (8)

Bug Fixes (9)

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.