Cursor Updates & Release Notes

This release makes it easier to stay in flow with side chats that run alongside your main chat, the ability to search agent transcripts, and simplified project and repo pickers.

Side chats

Open a side chat to ask questions, explore ideas, and investigate tangents without interrupting your main agent conversation. Use /side, /btw, or the plus button at the top of the chat panel to create a new side chat that has context from the main chat.

Each side chat is a durable, full agent conversation that you can follow up on, revisit later, and at-mention to pull context back into the main thread.

By default, side chats focus on reading, searching, and answering. Use them to ask clarification questions, research alternatives without committing to a pivot, and sanity-check a decision while the main agent continues running.

Conversation search

Find past agent chats faster with search results that go beyond names and PR numbers. In the Agents Window, you can search agent transcripts from the command palette (Cmd+K). Cursor builds a local search index that scales search to thousands of conversations with snappy performance.

You can also search within an existing conversation using Cmd+F. Jump between matches, see a match counter, and keep searching as you scroll through long transcripts.

Redesigned project and repo pickers

We've simplified the project and repo pickers and made them more powerful. You can now stay in the picker for workflows that used to send you elsewhere. For example, you can create a project and connect GitHub, GitLab, or Azure DevOps without leaving the picker.

Search is now scoped to where you're working—This Computer, Cloud, or a specific remote machine—instead of one global search box. You can also remove projects from Recents with one click.

New cloud agent hooks

Cloud agents already support team hooks around tool execution and file/shell work. We've added new hooks that let you observe and control the agent conversation itself: prompts, responses, thinking, subagents, compaction, and turn completion. See all the supported hooks in our docs.

New hooks like beforeSubmitPrompt, afterAgentResponse, afterAgentThought, stop, subagentStart, and more allow you to better observe output and reasoning, control subagents, and build self-correcting loops with cloud agents.

Today we are releasing Grok 4.5 together with SpaceXAI, our most intelligent model and the first we've built for more than software engineering.

Grok 4.5 can handle difficult, long-running tasks that require creatively using tools to solve problems, whether in software engineering, data science, finance, legal work, or anything else you do on a computer.

Cursor subscription plans for individuals and teams include significant usage of the model with double usage for the first week. We've also added new safeguards reflecting the model's cybersecurity capabilities.

A strong foundation

Grok 4.5 is a mixture-of-experts model that we trained jointly with SpaceXAI.

Training included trillions of tokens of Cursor data which capture a wide-range of user interactions with codebases and software tools. This dataset lets the model learn both from existing software as well as developer-agent interactions, capturing how developers work and how agents interact with their environments.

While we trained our previous model, Composer 2.5, to be a coding specialist, for Grok 4.5 we kept the training data mix deliberately broader. This involved drawing on high-quality STEM tasks, research papers, and other knowledge work, so that the model gained proficiency across a wide range of domains.

Reinforcement learning on difficult problems

We used reinforcement learning on difficult problems in realistic environments spanning both software engineering and broader knowledge work. These environments teach the model to investigate problems, use tools, recover from mistakes, and verify results.

Many of these problems had to be designed to be difficult enough that even frontier models fail at them. As models improve, existing tasks stop teaching them anything new, and problems that once required extensive reasoning become routine.

We developed a distributed agent system to construct these environments at scale. Engineers specify a problem and how a solution is verified, and large groups of agents construct, test, and refine each environment. Some would have taken teams of hundreds of engineers months to build. This is one of the ways in which we used the previous model to accelerate progress on the next model.

Get started with Grok 4.5

Grok 4.5 is available today in Cursor across desktop, web, iOS, CLI, and our SDK.

Individual and team plans include significant usage of the model as part of our first-party model pool, and we are doubling usage for the first week. The base model is priced at $2/M input tokens and $6/M output tokens. There is also a fast variant at $4/M input tokens and $18/M output tokens.

Grok 4.5 and Composer 2.5 are two different model weight classes, and we're excited to support both sizes and weights. Composer 2.5 will remain offered, and we will release new models of this size going forward.

SWE-Bench Pro and Terminal-Bench show self-reported scores for third-party models. For SWE-Bench multilingual, the GPT 5.5 score comes from our internal run.

Grok 4.5 has an advantage on CursorBench because an earlier snapshot of the Cursor codebase was accidentally included in training. The exact impact is unclear. That data has been removed for future models, and in parallel we are working on a larger update to CursorBench, hence the exclusion here.

As agentic coding spreads, the working life of a software engineer has become dazzlingly complex. A single engineer might oversee dozens of coding agents at once, launching and guiding different processes as necessary.

It’s a lot to keep track of, and human engineers’ attention has quickly become the limiting resource.

Cursor launched a new tool Thursday aimed at keeping that chaos in check. Called Automations, the new system gives users a way to automatically launch agents within their coding environment, triggered by a new addition to the codebase, a Slack message, or a simple timer. As Cursor describes it, it’s a way to review and maintain all the new code created by agentic tools — without tracking dozens of agents at once.

At the most basic level, Automations are a way for engineers to break out of the “prompt-and-monitor” dynamic that defines most agent-based engineering. Instead of launching agents with a human prompt, Cursor’s Automation framework lets you launch agents automatically — and loop humans in whenever they’re needed.

“It’s not that humans are completely out of the picture,” Jonas Nelle, Cursor’s engineering chief for asynchronous agents, told TechCrunch in an interview. ”It’s that they aren’t always initiating. They’re called in at the right points in this conveyor belt.”

One early example is Bugbot, a long-standing Cursor feature that the team sees as a predecessor to the broader Automation system. The Bugbot system is triggered every time an engineer makes an addition to the codebase and reviews the new code for bugs and other issues. Using Automations, Cursor has been able to expand that system to more involved security audits and more thorough reviews.

“This idea of thinking harder, spending more tokens to find harder issues, has been really valuable,” said engineering lead Josh Ma.

Cursor estimates that it runs hundreds of automations per hour, reaching far beyond simple code review. The system is also used for incident response, with PagerDuty incidents initiating an agent that can immediately query server logs through an MCP connection. A separate automation offers weekly summaries of changes to the codebase on Cursor’s company Slack.

“In the abstract, anything that an automation kicks off, a human could have also kicked off,” said Nelle. “But by making it automatic, you change the types of tasks that models can usefully do in a codebase.”

The new system comes amid intense competition in the agentic coding space, with both OpenAI and Anthropic having made significant updates to their agentic coding tools in the past month.

Ramp data shows Cursor’s market share holding steady since May, with roughly 25% of generative AI clients subscribing to Cursor in some capacity.

Still, the overall growth of the agentic coding space has kept the company’s revenue increasing at a stunning pace. Earlier this week, Bloomberg reported that Cursor’s annual revenue had grown to more than $2 billion, doubling over the past three months.

We've expanded team marketplaces to support Team MCPs and organization groups.

Admins can now configure Team MCP servers once and distribute them across cloud agents, the agents window, IDE, and CLI.

When an admin sets up Team MCP servers for cloud agents, they can make those same servers available in a team marketplace from Dashboard -> Integrations & MCP. This allows members of the team to install approved integrations locally without configuring servers themselves.

Learn more in the docs on migrating existing Team MCPs.

Team marketplaces now support organization groups, in addition to team-level SCIM directory groups.

Under Dashboard -> Plugins -> Team Marketplaces, restrict marketplace access to specific organization groups. Marketplaces that already use SCIM directory groups keep that configuration.

Get started in the Cursor dashboard.

Cursor is now available as a native iOS app in public beta, so you can build from anywhere.

Until now, developers have worked around the limits of their local machines, keeping laptops half-open and caffeinated everywhere they go.

With Cursor for iOS, you can launch always-on agents in the cloud, or control agents running on your computer from your phone. Kick them off when ideas strike, get notified when work is ready for review, and merge PRs on the go.

Whether your agents are running on your machine or in the cloud, you can move work forward from wherever you are.

Get Cursor for iOS

Launch and track agents from anywhere

Whether you're catching a flight, cooking a meal, or in between sets at the gym, you can now act on moments of inspiration or curiosity.

Open the Cursor mobile app, choose a repo, and launch an agent the same way you would on the desktop app. You can pick any frontier model, describe ideas out loud with voice input, and use slash commands to guide Cursor in the right direction.

For agents running on your computer, use Remote Control to continue directing them from your phone. To ensure your machine remains reachable while you're away from your desk, you can enable a setting that keeps your computer awake.

New ways of working from your phone

At Cursor, we use the mobile app for everything from small, well-scoped tasks to long-running projects. It has enabled new workflows for our team and early testers:

• Handling incidents while on call: When you get paged at lunch, you can kick off an agent to investigate and propose a fix. By the time you get back to your computer, you'll have a PR ready for review.
• Resolving customer issues: If a customer reports a time-sensitive bug while you're away from your desk, you can start an agent from your phone to reproduce the issue, inspect the relevant code, and work toward a fix.
• Acting on feedback from other mobile apps: When you see user feedback on X or other platforms, take a screenshot, annotate it, and send it to an agent as visual context. This is often the fastest way to start design or UI changes.

Stay in the loop

Once an agent starts, you can leave the app. Cursor keeps you updated with Live Activities on your lock screen and push notifications when an agent finishes, needs input, or is ready for review.

Beyond code, cloud agents produce demos, screenshots, and logs that make it easy to validate their work. When an agent is done, you can review these generated artifacts, inspect diffs, leave follow-up instructions, or merge the PR directly from the app.

Handoff between local and cloud

Cloud agents run in isolated virtual machines with full development environments to test, verify, and demo work. Since they operate asynchronously with their own tools and resources, cloud agents can run for longer and iterate toward merge-ready PRs without intervention.

To take advantage of these capabilities, send a local plan to a cloud agent or move active agents to the cloud to keep running. You can move the cloud session back to your computer to test changes locally before merging.

What's next

Over time, the experience of running agents in the cloud will become indistinguishable from running them on your local machine. Until then, we want to make it easy to work with agents across both environments with Remote Control and fluid handoffs between local and cloud.

We are also working on adding the ability to create repo-less chats to make it easier to kick off tasks that don't require codebase context. Teams are already using Cursor today with MCPs to query Datadog logs, summarize activity across Slack channels, and more.

Cursor for iOS is available now in public beta on all paid plans. Get 75% off on Composer 2.5 runs in the mobile app now through July 5, 2026.

Download for iOS to start building from your phone, or read the docs to learn more.

Cursor for iOS is now available in public beta on all paid plans. Launch and manage always-on agents from anywhere.

Cloud agents on mobile

Open the Cursor mobile app, choose a repo, and launch an agent the same way you would on the desktop app. Pick any frontier model, describe ideas out loud with voice input, and use slash commands to guide Cursor in the right direction.

Cloud agents run in isolated virtual machines with full development environments to test, verify, and demo work. Move sessions from local to cloud to keep them running with your laptop closed.

Remote Control

Use Remote Control to take an agent you're running on your computer and keep directing it from your phone.

You can also turn on a setting to keep your computer awake, so your machine stays reachable while you're away from your desk.

On Teams and Enterprise plans, admins must enable Remote Control from the Cursor Dashboard.

Live Activities and push notifications

Track the status of your agents with Live Activities on your lock screen. Get push notifications when an agent finishes, needs input, or is ready for review.

Artifacts and SCM

Review demos, screenshots, logs, and diffs from your phone. Leave follow-up instructions, or merge the PR directly from the app.

Download Cursor for iOS to start building from your phone. Read our announcement or the docs to learn more.

Plugins, skills, and MCPs

Plugins, skills, and MCPs let you customize Cursor for your workflows. The new Customize page brings them into one place.

You can now add and manage plugins, skills, MCPs, subagents, rules, commands, and hooks at the user, team, or workspace level, and even bring your own custom MCPs.

Marketplace leaderboard

Cursor now shows you a leaderboard of the most popular plugins, skills, and MCPs across your team.

Add any to your setup with one click from the new Customize page and extend Cursor for your workflow.

Plugin canvases

Plugins now support prebuilt canvases: shared setup templates your team can open and reuse.

Use the Hex Canvas to build data visualizations.

Use the Atlassian Canvas to see a realtime view of all our issues, projects, and documents.

New Team Marketplaces

Team marketplaces now support imports of plugin repositories from GitLab, BitBucket, or Azure DevOps so you easily add plugins and distribute them to your team.

Learn more in our docs.

Take a first pass at addressing inline review comments on PR diffs

You address inline PR review comments with a first-pass fix.

Goal

When a reviewer leaves an inline comment on the diff, attempt a minimal fix and respond on the thread.

Process

1. Read the triggering inline comment from the payload (author, comment body, comment URL, PR number).
2. Use the comment URL or gh to fetch the file path and line if needed.
3. Understand the requested change — bug, style, missing case, naming, etc.
4. Inspect the surrounding code and make the smallest correct fix.
5. Commit and push to the existing PR branch. Do not open a new PR.
6. Reply on the review thread with what you changed. Resolve the thread if the comment is fully addressed.

Rules

• Only change code required by the comment. Match existing patterns.
• If the comment is unclear, a design question, or needs human judgment, reply explaining what is ambiguous — do not guess.
• If you cannot fix confidently, say why and what you'd need to proceed.
• Do not approve the PR. Do not address unrelated comments.

Cursor Automations save you time by automating repetitive tasks with always-on agents. This release introduces the /automate skill, new triggers for GitHub and Slack, and support for computer use.

/use /automate to create an automation directly in your local agent session.
Describe the task you want to automate in plain language and Cursor will configure the triggers, instructions, and tools for you.

An emoji trigger for Slack

React to any Slack message with a designated emoji to kick off an automation. At Cursor, we use this to trigger specific automations right from Slack.

New GitHub triggers

Automations now support five additional GitHub triggers:

• Issue comment: when a comment is made on a non-PR issue
• PR review comment: when an inline comment is left on a pull request diff
• PR review submitted: when a PR review is submitted
• Review thread updated: when a review thread on a pull request is marked resolved or unresolved
• Workflow run completed: when a GitHub Actions workflow run finishes on a pull request or branch

We've added new templates for triaging failed GitHub actions and auto-fixing PR review comments to the Cursor Marketplace to help you get started.

Computer use tool for automations

Cloud agents kicked off by automations can now use their own computers to produce demos or artifacts of their work.
The computer use tool is enabled by default for every automation, just tell the agent to include a demo of its work in your instructions.

To get started, update to the latest version of Cursor. Learn more in our docs.

Cursor Automations save you time by automating repetitive tasks with always-on agents. This release introduces the /automate skill, new triggers for GitHub and Slack, and support for computer use.

/automate skill

Use /automate to create an automation directly in your local agent session.
Describe the task you want to automate in plain language and Cursor will configure the triggers, instructions, and tools for you.

An emoji trigger for Slack

React to any Slack message with a designated emoji to kick off an automation. At Cursor, we use this to trigger specific automations right from Slack.

New GitHub triggers

Automations now support five additional GitHub triggers:

• Issue comment: when a comment is made on a non-PR issue
• PR review comment: when an inline comment is left on a pull request diff
• PR review submitted: when a PR review is submitted
• Review thread updated: when a review thread on a pull request is marked resolved or unresolved
• Workflow run completed: when a GitHub Actions workflow run finishes on a pull request or branch

We've added new templates for triaging failed GitHub actions and auto-fixing PR review comments to the Cursor Marketplace to help you get started.

Computer use tool for automations

Cloud agents kicked off by automations can now use their own computers to produce demos or artifacts of their work.
The computer use tool is enabled by default for every automation, just tell the agent to include a demo of its work in your instructions.
To get started, update to the latest version of Cursor. Learn more in our docs.

Cloud environment setup

Cursor can now help you set up your dev environment in the cloud in less than 10 minutes. You can watch the agent's progress in a shared terminal session as it handles setup tasks like installing dependencies.

Your environment is captured in a reusable snapshot, so future cloud agents start up faster with the ability to test changes by running your software. It can iterate over long time horizons until outputs are verified. This benefits your entire team when committed to .cursor/environment.json.

Cloud subagents with /in-cloud

Use /in-cloud to spin up a cloud subagent in its own VM to work on the next task you submit. It runs on its own VM and branch, so your local workspace stays clean and responsive.

This is especially useful for isolating long-running or parallel work like fixing CI, investigating an issue, or exploring a codebase while you keep working locally.

You can also ask a cloud subagent to babysit a PR by clicking on the quick-action pill or using /babysit. The cloud agent will iterate remotely to prepare your PR for merge without tying up the local session.

The cloud subagent can run in the background without interrupting the parent agent, which can continue to run locally or in the cloud.

Handoff between local and cloud

Move agent sessions more reliably between your local computer and the cloud. You can offload long-running work from your machine and run as many cloud agents in parallel as you want. Pull a cloud agent back down to local to test changes yourself.

This release introduces updates to cloud agents in the Agents Window of the Cursor desktop app.

Cloud environment setup

Cursor can now help you set up your dev environment in the cloud in less than 10 minutes. You can watch the agent's progress in a shared terminal session as it handles setup tasks like installing dependencies.

Your environment is captured in a reusable snapshot, so future cloud agents start up faster with the ability to test changes by running your software. It can iterate over long time horizons until outputs are verified. This benefits your entire team when committed to .cursor/environment.json.

Cloud subagents with /in-cloud

Use /in-cloud to spin up a cloud subagent in its own VM to work on the next task you submit. It runs on its own VM and branch, so your local workspace stays clean and responsive.

This is especially useful for isolating long-running or parallel work like fixing CI, investigating an issue, or exploring a codebase while you keep working locally.

You can also ask a cloud subagent to babysit a PR by clicking on the quick-action pill or using /babysit. The cloud agent will iterate remotely to prepare your PR for merge without tying up the local session.

The cloud subagent can run in the background without interrupting the parent agent, which can continue to run locally or in the cloud.

Handoff between local and cloud

Move agent sessions more reliably between your local computer and the cloud. You can offload long-running work from your machine and run as many cloud agents in parallel as you want. Pull a cloud agent back down to local to test changes yourself.

To be their most productive for coding and other tasks, agents need a healthy level of autonomy.

That means they should be able to operate independently, be creative, and accomplish work without stopping too often to ask for permission.

However, greater autonomy introduces security risks if agents take unintended actions. This is especially true for local agents, which often run near files, credentials, environment variables, MCP tools, and have access to production systems.

The easy answer is to ask the user before any action happens, but asking for permission too often creates its own safety problem. After enough repeated prompts, people stop reading carefully, and the approval flow becomes less meaningful.

This week we launched Auto-review, which makes decisions around agent autonomy behave more like a dial than a switch. The core idea is that an agent should be able to move freely when the stakes are low, but slow down when its next action crosses a meaningful boundary.

We determine where an action sits along that continuum with a specialized classifier agent that reviews actions in context before they run. Building it meant turning our intuition for how agent autonomy should be governed into a working model of consequence, intent, and feedback that we could test against real agent behavior.

Whether an agent action poses risk depends on the situation. The same command can be harmless in one workflow and unacceptable in another. What matters is the relationship between the action, the user's request, and the consequence of being wrong.

That recognition pushed us toward developing a "classifier" agent that would govern overall agent autonomy. We wanted it to be a small model, so that it stayed fast and inexpensive to run, while still making a nuanced judgment about whether the next action was consistent with the user's intent.

The central rule we gave the classifier was that it should be more lenient when the security stakes are lower, and more cautious when they're higher. With that broad understanding in place, we began building the classifier as a fast, contextual reviewer that could sit directly in the agent's execution path.

The first technical decision was model choice. The classifier runs before a tool call executes, so it sits directly in the agent loop and needs to be fast as well as accurate. Being a multi-model company helped here because we could try a wide range of models and reasoning modes, then choose the one that sat at the right point between speed and judgment.

One early surprise was that lower-reasoning models were not always faster. When a model struggled to understand the policy or the tool call, it could spend more time and tokens searching for what ultimately became a worse answer. The better trade-off was a small model with enough reasoning to make the decision cleanly.

We also made the classifier agentic, because some actions cannot be judged from the command alone. A command like

python script.py

might be safe or unsafe depending on what is inside the file, so the classifier can inspect the workspace with tools like ReadFile, Grep, Glob, and ListDir before deciding.

We avoided a separate classification endpoint, because an extra round trip would add latency directly before every reviewed tool call. Instead, the classifier runs in the same RPC stream as the parent agent, using an architecture similar to subagents.

The next decision was what a block should do. We did not want the classifier to become another approval prompt generator. When it blocks an action, it returns an explanation to the parent agent, and the parent agent can often use that feedback to choose a safer path without interrupting the user.

User intent is what makes that feedback useful. The question is not whether an action looks risky in isolation. The question is whether the action is justified by what the user asked the agent to do. That is what lets normal development work keep moving while higher-consequence actions require a clearer signal from the user.

That design only works if the classifier is tuned against the actions it should let through and the ones it should stop, so we needed evals that covered both.

Our first set of evals came from internal usage data to understand the normal shape of agent work. The classifier had to catch risky actions without blocking routine development work, and internal sessions were the best way to see that baseline. We started with roughly 12 hours of internal developer sessions, then cut that down and deduplicated common actions into 6,122 labeled rows.

We also needed synthetic data, because the worst cases do not appear often enough in normal usage. We generated cases where the agent might read secrets, touch production data, follow untrusted instructions, or take actions with large side effects. Those examples gave us coverage for the failures we most wanted the classifier to catch.

The policy changed as we learned, which made the data work more complicated. When we changed the categories of behavior the classifier should recognize, we had to relabel or rematerialize the eval set. Otherwise, we would be testing the current classifier against an outdated understanding of the problem.

We ran the evals through the same backend classifier loop used in production. That let us test the full path, including tool use, final classification, model overrides, and parse failures. The evals checked the final allow or block decision, along with the context the classifier used when it needed to inspect the workspace before deciding.

We also looked for flapping. If the same case allowed six times and blocked four times, that usually meant the policy or prompt was underspecified. Repeated runs gave us a way to find those unstable cases and tighten the classifier until its behavior was more consistent.

In practice, only a small share of agent actions need to be reviewed by the classifier. Many commands are already covered by allowlists or sandboxing, so the classifier mostly runs when the action needs contextual judgment.

When the classifier does run, it currently blocks around 4% of actions, though a block does not immediately become a user prompt. The classifier sends an explanation back to the parent agent, which can often narrow the action, choose a different tool, or avoid the risky step entirely.

Some blocks from the classifier become user interruptions, but globally we're seeing that only about 7% of total chats in Auto-review mode lead to at least one interruption. To put that in perspective, some enterprise customers we're working with previously saw roughly 40% of actions blocked within their organization.

This early data is consistent with the main product behavior we wanted. The classifier rarely interrupts the user directly, and in most blocked cases the parent agent can use the feedback to continue in a safer, narrower way.

Auto-review is still early, and our understanding of the autonomy continuum will keep changing as agents become more capable. Today, it is focused on local agents in the desktop app, and we expect the same ideas to shape how we govern agent autonomy in more places over time.

We want agents to have real autonomy, while making the decision to slow them down depend on context rather than a single global permission setting. The classifier lets us improve safety without turning autonomy back into a stream of approval prompts. It catches actions that need more scrutiny, gives the parent agent feedback, and lets the agent keep working when there is a safer way to proceed.

Auto-review is now the default for new users. For existing users, you can enable it in Settings > Agents.

The average review time for Bugbot is now ~90 seconds, down from ~5 minutes. Bugbot also finds 10% more bugs per review on average 1.62, up from 0.56 and costs ~22% less per run.

These performance gains are made possible by progress we've made training Composer 2.5, which now powers Bugbot. Bugbot respects model block lists, and speed and performance can vary depending on your configuration.

Run Bugbot before you push

You can now run Bugbot and Security Review with /review before pushing code. /review prompts you to choose which agents to run, or use /review-bugbot and /review-security directly.

/review also syncs with Bugbot on GitHub and GitLab. If you run /review and then open a PR with the same diff, Bugbot recognizes it, skips the review, and leaves a comment noting it has already reviewed that diff.

Available in Cursor 3.7+ and on cursor.com/agents, with support in CLI coming soon.

Only review what's new in your PR

You can now configure Bugbot to only review what's new since the last review, keeping feedback focused on your latest updates.

Learn more in our docs.

Today we're shipping our biggest set of improvements yet to Bugbot.

Bugbot is now over 3x faster to run, 22% cheaper, and finds 10% more bugs per review. In practice, 90% of Bugbot runs now finish in under three minutes.

A faster, less expensive, more thorough Bugbot allows you to find issues sooner and merge code faster.

Run Bugbot before you push

You can now run Bugbot and Security Review with /review before pushing code. /review prompts you to choose which agents to run, or use /review-bugbot and /review-security directly.

This is a great way to catch and fix issues before pushing the code. /review also syncs with Bugbot on GitHub and GitLab. If you run /review and then open a PR with the same diff, Bugbot recognizes it, skips the review, and leaves a comment noting it has already reviewed that diff.

Available in Cursor 3.7+ and on cursor.com/agents, with support in CLI coming soon.

Only review what's new in your PR

Bugbot by default re-reviews the entire PR every time a change is pushed. This can result in new flags on code it had already reviewed and approved. You can now configure Bugbot to only review what's new since the last review, keeping feedback focused on your latest updates.

How we got here

These performance gains are made possible by harness improvements and progress we've made training Composer 2.5, which now powers Bugbot. Our model training work is one part of how we will continue to improve Bugbot over time.

Bugbot respects model block lists. If your organization has opted out of Composer 2.5, Bugbot will automatically fall back to the next best available model. Speed and performance can vary depending on your configuration.

Learn more

Try Bugbot here and read the Bugbot docs to learn more.