Optimizing Bugbot Costs in a Large Monorepo: ~$30 per run and $300 in 2 days. Any best practices?

Support Help
, ,
1

Hi everyone,

We are working in a large monorepo and recently enabled Bugbot at its highest settings to catch as many bugs as possible during our PR workflows.

While the results have been great in terms of quality, the costs have escalated extremely fast. In just two days, our Bugbot spending reached $300.

As you can see in the attached screenshot, a single Bugbot run consumes around 38.3M tokens/context and costs $29.74!

Bugbot Cost Screenshot

We suspect this is because our monorepo is quite large, causing Bugbot to load a massive amount of context for every single run, even if the PR only touches a small subset of the codebase.

We would love to get your advice on a few things:

Context Optimization: Is there a way to limit the context Bugbot loads? Can we exclude specific directories, use a .cursorignore equivalent specifically for Bugbot, or instruct it to only analyze modified files and their direct dependencies?
Multi-tiered Review Pipeline: We are considering introducing a cheaper tool like CodeRabbit in the middle as a gatekeeper. The workflow would run CodeRabbit on every commit/PR, and only trigger the full, expensive Bugbot run once CodeRabbit approves the changes or under specific conditions. Has anyone implemented a similar tiered review pipeline?
Other Best Practices: Are there any other cost-saving strategies recommended by the Cursor team or the community for running Bugbot on large codebases?
Any insights or recommendations would be highly appreciated!

6

Cost scales with how deep each review is and how many times it re-runs, not repo size. Since you’re on usage-based Bugbot, the biggest levers are all in your Bugbot dashboard (cursor.com/dashboard):

  1. Effort: High to Custom. Describe when to go deep, e.g. “high effort for auth/, billing/, infra/, migrations; default elsewhere.” Deep reviews only where risk is real.
  2. Turn on Incremental Review. Reviews only what changed since the last run instead of the full diff on every push.
  3. “Run only once per PR” (or manual @cursor review). Stops a single PR firing a run on every push. Usually the biggest win for iterative work.
  4. Smaller PRs. Fewer packages touched means less context pulled per run.
  5. Set a spend limit (Dashboard > Usage) as a hard cap. Note: it covers all on-demand usage (chat + Bugbot), not Bugbot alone.

Two quick answers:

  • No .cursorignore for Bugbot. That only affects IDE indexing. There’s no per-directory context exclusion today. .cursor/BUGBOT.md (root + nested) steers what it reviews for, not which files load.
  • No native gatekeeper pipeline. You can DIY it: set Bugbot to manual-only and trigger @cursor review from CI only after your own gate passes.