A payments service renames amount_total to amount_cents and updates its local callers, then passes its tests; the reporting parser in another repository writes null totals because Cursor Bugbot's documented review context stays with the pull request repository.
TL;DR
Cursor Bugbot reviews pull request diffs with repository-local comments and rules, plus configured Model Context Protocol tools. Cursor reports resolution rates rather than precision or recall, and usage billing applies after the 2026 transition. That documented review context stops at the boundary of the repository holding the pull request.
A reviewer working inside the payments repository sees a complete, internally consistent change and approves it. The reporting service never appears in the review, so its dependency on the old response field survives until the deploy.
Engineering leaders and platform owners at enterprise teams need to know whether Cursor Bugbot would catch that break during pull request review. The relevant evaluation covers how a review triggers and which context Cursor says the agent reads. It also covers Cursor's published figures, usage-based billing, and the fixed limits in its documentation. The boundary matters most for teams running dozens of services across many repositories, where a change in one repository routinely has consumers in another. Cosmos, Augment Code's unified cloud agents platform available on all paid plans, supplies the cross-repository review context that boundary requires.
What Cursor Bugbot Is and How a Review Runs
Cursor Bugbot is Cursor's artificial intelligence (AI) code review agent for pull request (PR) diffs. After a team installs it against a source control provider, Bugbot reads the PR diff, identifies likely defects, and posts inline comments that explain each finding and propose a fix, as described in the Bugbot documentation. Teams enable it per repository from the Automations area of the Cursor dashboard, and from there it runs automatically on every PR update by default.
A manual review runs when someone comments cursor review or bugbot run on the PR. Two documented repository controls narrow the default: one restricts Bugbot to manual triggers only, and one caps it at a single review per PR per installation. Draft PRs stay outside automatic review until the team turns on reviews for drafts.
Incremental review is the default behavior. Bugbot reviews only the commits pushed since its previous review on that PR, so each push gets a narrow pass over the new commits. Turning Incremental Review off in Bugbot Automations makes every push re-read the whole diff, at the cost of a full run each time. Bugbot comments on a PR that a developer or another agent opened, and its autofix mode can push fix commits to the branch under review. It therefore operates in the same pull request pipeline as other PR automation tools.
What Bugbot Reads: Documented Scope Within One Repository
Cursor documents Bugbot's context as the PR diff plus material drawn from the connected repository. Bugbot reads top-level and inline PR comments from the provider. It gathers .cursor/BUGBOT.md rule files by traversing upward from each changed file to the repository root and applies team and repository rules. On Team and Enterprise plans, team administrators can expose tools through Model Context Protocol support.
Cursor's code review page uses wider wording, describing the agent as weighing a change against the surrounding code it touches. Its Bugbot page describes evaluation of the changed lines together with the existing components and assumptions they touch. Cursor describes that reading as semantic, at the level of what the code means.
| Documented context source | Repository scope |
|---|---|
| PR diff | The repository holding the PR |
| Top-level and inline PR comments | The PR under review |
| .cursor/BUGBOT.md rule files | Each changed file's path up to the repository root |
| Team and repository rules | Rule text applies across repositories; code does not travel with it |
| MCP tools (Team and Enterprise plans) | Team administrators configure tools exposed to the review |
Read together, the documentation and the product pages describe contextual review that resolves inside one repository. Cursor describes that context as enough to check a renamed function against callers elsewhere in the same repository. Bugbot can also compare a change against constraints from rule files or earlier comment threads. This scope is materially wider than the diff alone: it can catch missed callers and violations of team conventions, then apply constraints from earlier reviewers.
Cursor's current Bugbot documentation names no native context source outside the repository that holds the PR. The May 13, 2026, entry in Cursor's changelog attributes multi-repository support to cloud agents. The May 20, 2026, entry attributes it to automations. Neither mentions Bugbot reviews. For teams whose services span repositories, this boundary determines which defects a Bugbot review can reach.
How Well Bugbot Catches Bugs: The Published Figures
Cursor publishes Bugbot resolution rates, not precision, recall, F-score, or a numeric false-positive rate. Resolution rate is straightforward: of the bugs Bugbot flagged on a PR, what share did developers act on before merge? In a May 11, 2026, changelog entry, Cursor reported that developers resolved 80% of bugs Bugbot identified by merge time at the default-effort setting, and that high effort found 35% more bugs while that resolution rate held steady at 80%.
That number answers a narrower question than it sounds like. Precision says what share of Bugbot's flags are real bugs; recall says what share of the real bugs in a PR Bugbot actually caught. Resolution rate is neither. A flag counts as resolved whether a developer fixed a genuine bug or just dismissed a suggestion that changed nothing, and an unresolved flag could be a false positive or a real bug the team chose to ship anyway. It also only counts what Bugbot flagged in the first place, so it says nothing about what Bugbot missed.
For a CTO citing this number in a board deck, the honest version is narrower: developers acted on 80% of Bugbot's own flags before merge, in Cursor's own measurement, at default effort. The 35% figure means high effort surfaces more bugs without moving that resolution rate; Cursor doesn't publish a separate resolution rate for those additional findings. And for the cross-repository break in the opening example, resolution rate isn't even the right lens: what matters there is whether Bugbot would have flagged the break at all, which is a recall question Cursor's published figure doesn't answer.
Pricing, Integrations, and Documented Limits
Bugbot moved from a flat seat subscription to usage-based billing in 2026. Cursor's legacy pricing documentation lists the previous Teams model at $40 per seat per month, with the Individual plan covering up to 200 PRs per month. Cursor announced the billing change for Teams and Individual plans on May 11, 2026, with existing subscribers transitioning at their first renewal after June 8, 2026. Customers who purchased annual subscriptions in May 2026 transition in May 2027. Cursor's billing help page puts an average Bugbot run at $1.00 to $1.50 depending on PR size and complexity.
Cursor's provider documentation covers GitHub and GitLab integrations, including their cloud and self-managed variants. Separate Bitbucket documentation and Azure DevOps documentation supply the beta labels and plan boundaries below.
| Platform | Documented status | Where it applies |
|---|---|---|
| GitHub | Supported, including GitHub Enterprise Server | Cloud and self-managed instances |
| GitLab | Supported; GitLab.com requires a paid Premium or Ultimate plan; self-managed requires Teams or Enterprise | Cloud and self-managed instances |
| Bitbucket Data Center | Supported on Teams and Enterprise | Self-managed Data Center instances |
| Bitbucket Cloud | Public beta | Bitbucket Cloud repositories |
| Azure DevOps | Public beta / limited availability | Azure DevOps Services repositories |
The fixed limits below come from the current Bugbot configuration documentation and set the operational boundaries a platform team inherits. Cursor documents separate application programming interface (API) limits for the review trigger endpoint and the administrative endpoints.
| Setting | Documented value | Effect when reached |
|---|---|---|
| Rule content per rule | 30,000 characters | Bugbot truncates longer rules when including them in a review |
| Combined rule content per review | 100,000 characters | Bugbot may omit rules beyond the cap and prioritizes required team rules |
| Autofix retries | 3 attempts per PR | Commit to Existing Branch autofix stops after 3 attempts on a PR, which prevents commit loops |
| Review-trigger API rate limit | 30 requests per minute per team | The API rejects requests above the limit on the review trigger endpoint |
| Admin API rate limit | 60 requests per minute per team | The API rejects requests above the limit on repository and user configuration endpoints |
The rule caps bite first for large organizations. A platform team that encodes service conventions in .cursor/BUGBOT.md files across a deep directory tree can exceed 100,000 combined characters. Bugbot may then omit rules beyond the cap and prioritize required team rules; a verbose review shows the omission list. The three-attempt cap means a fix Bugbot cannot land in three tries goes back to a human.
Where Same-Repository Review Stops: The Cross-Service Gap
The payments rename from the opening appears internally consistent under Bugbot's repository-local sources. The diff shows a consistent rename; the payments team updated callers inside the repository, and Bugbot can confirm those callers. The reporting service's parser remains outside that review path. A configured MCP tool or repository rule could expose an external contract, but the team must explicitly configure that context.
Platform engineers can use the documented sources to classify defects by scope. Bugbot can catch a missed caller inside the payments repository and a violated convention encoded in a .cursor/BUGBOT.md rule file. It can also apply a constraint that a reviewer raised earlier in the PR's comment thread. The consumer's parser remains a separate dependency, as do downstream artifacts such as a contract test or a client that another team generated from the old field name.
Any interface consumed across a repository boundary creates the same review requirement. Catching that dependency takes repo-aware code review spanning several repositories. For a repository whose consumers all live inside it, every documented Bugbot context source remains relevant, so the additional scope matters only when dependencies cross repository boundaries.
The Cosmos review workflow addresses that gap where it occurs. When using Cosmos Code Review, teams reviewing cross-service interfaces can examine repository relationships beyond the changed diff because the review workflow uses the Context Engine's cross-repository codebase context. That reading scope supports a different engineering decision: multi-repository exposure calls for a cross-repository reviewer, while self-contained changes remain suitable for repository-local review.
The Cosmos review workflow follows the interface relationship instead of stopping at the repository boundary. In the payments example, that means connecting the changed response field to the separate reporting parser before merge. This preserves Bugbot's value for local review without treating two repository-local passes as equivalent to one cross-repository analysis.
Fitting Cosmos Review to Multi-Repository Exposure
Services that consume interfaces defined in other repositories need review context that crosses those repository boundaries. The Context Engine indexes files and structural relationships across repositories, including relationships that connect service callers with the interfaces they consume. The code review workflow applies that context while reviewing changes, so the reviewer can examine the reporting service's dependency while reviewing the payments PR.
When using Cosmos Code Review, teams implementing cross-repository contract checks can connect a changed interface to affected consumers because the Context Engine retrieves relevant files through their structural relationships. In the payments example, the required review path starts with the amount_total rename and follows the relationship to the reporting parser. The reviewer can then check whether the consumer still expects the old field. That Cosmos workflow addresses the established boundary without changing the value Bugbot provides for repository-local review.
Treat Cosmos as the review layer for repositories with cross-service exposure. Stacking Cosmos beside Bugbot on every PR adds a second set of comments where repository-local review already covers the relevant consumers. The additional scope matters when a change crosses repository boundaries; self-contained repositories do not require that overhead.
What to Do Next
The tradeoff is between per-push, same-repository review across four provider integrations with per-run pricing and cross-service blast-radius visibility from a reviewer that indexes every repository involved. Bugbot fits a team whose repositories are self-contained; Cosmos fits a team whose changes in one repository regularly break code in another. Pull the list of repositories that call or import an interface defined outside themselves, then count how many of last quarter's incidents traced to a change merged in a repository other than the one that failed. If that count is above zero, review the incident records to determine which repositories the reviewer must read.
Frequently Asked Questions
Related Reading
Written by
Molisha Shah
Molisha is an early GTM and Customer Champion at Augment Code, where she focuses on helping developers understand and adopt modern AI coding practices. She writes about clean code principles, agentic development environments, and how teams are restructuring their workflows around AI agents. She holds a degree in Business and Cognitive Science from UC Berkeley.