Slow bugbot in big repos

Support Help
, ,
1

Need a way to reduce the feedback loop time, I assume due to the size of my codebase it takes longer and longer to run bugbot, at the moment it takes ~15 mins per run, that means I have 15 mins gaps between coding sessions on a single task, I can parallelize but the context switch is also a mental burden.

I am wondering if this issue is exacerbated in Monorepos given it should hold multiple proyects, or if instead making the code more modular would help bugbot work better as it would only have to consider the boundaries between modules of the changed code?

What else can I do to improve on this process?

image
image442×320 10.7 KB

3

I also wonder how expensive autofix is, I see it uses GPT 5.3 codex high max, so I’m nervous about using it, especially because it goes directly into API usage.

4

Hey, thanks for the report. A few things:

Why it’s slow. Runtime Bugbot mostly depends on the size and complexity of the PR diff, like how many files were touched and how much surrounding context it has to pull in, not the overall repo size. A few minutes is expected for a thorough analysis, but 10 to 15 minutes consistently is on the high side. Could you trigger a review with bugbot run verbose=true as a comment in a PR where this happens? That’ll give you a serverGenReqId_... and you can share it here so we can check logs on our end.

Monorepo vs modular structure. A monorepo by itself isn’t worse. It gets slower when one PR touches lots of packages and forces Bugbot to gather context from many parts of the tree. Modularity helps indirectly since smaller, more focused PRs run faster. The most effective change is to split PRs, not restructure the project.

Bugbot rules can add latency. If you have .cursor/BUGBOT.md with a complex rule set, that adds processing time. Worth checking if you still need all the rules.

What you can do right now:

  • Split work into smaller PRs, biggest time win.
  • Trim .cursor/BUGBOT.md rules if you have them.
  • Switch to another task while it runs.

Note: .cursorignore controls local indexing for Tab, Agent, and @ references in the IDE. It doesn’t configure Bugbot, which analyzes the PR diff from GitHub directly. For Bugbot tuning, .cursor/BUGBOT.md is the right file.

About Autofix. Autofix spins up cloud agents in isolated VMs to test and fix bugs. Important billing detail: Autofix uses Cloud Agent credits from your main Cursor plan at your plan’s rate, not from Bugbot’s own quota. So if you’re on a Free or Hobby plan, your Cloud Agent allowance will run out quickly, especially if Autofix is enabled on all comments. Usage shows up in your Dashboard alongside other agent runs. To control spend, enable Autofix only on important comments, and in the dashboard consider Create New Branch mode, which keeps fixes separate and caps retry loops.

5

this is almost entirely inaccurate. bugbot is painfully slow on monorepos. we have no additional rules, it just takes a minimum of 15mins to run, regardless of change size.

6

From my own experience with a single repo, it consistently takes 8~10 min, but I assume that’s based on the change size, we do PRs consistently about 8~15 files (tests included), and about 2.5K lines.

Only the smallest of changes takes less and yet 4 min minimum is a lot of time.

Though it’s my own criteria about the size of the project, this is the analysis I get through cloc (Ignore JSON files, almost all of those are from a Country/State/City data source):

# Vital Link — project size analysis

Generated from `cloc` with exclusions: `node_modules`, `.git`, `.next`, `out`, `build`, `coverage`, test reports, `.vercel`, `dist`, `.cache`, etc.

## Overall (everything `cloc` counts)

| Metric            |      Value |
| ----------------- | ---------: |
| **Files**         |      5,774 |
| **Lines (total)** | ~2,390,688 |

**By language (dominant rows):**

| Language   | Files | Code lines\* |
| ---------- | ----: | -----------: |
| JSON       | 4,166 |   ~2,159,194 |
| TypeScript | 1,329 |      157,829 |
| Markdown   |   226 |       23,136 |
| YAML       |    15 |       13,648 |
| Other      | small |       modest |

\* `cloc` “code” = non-blank, non-comment by its rules.

Most of the repo’s **raw line volume is JSON** (fixtures/data-style files), not application TypeScript.

---

## “Source-like” footprint (JSON excluded)

Closer to **maintained text + code**, with bulk JSON stripped out:

| Metric               |   Value |
| -------------------- | ------: |
| **Files**            |   1,618 |
| **Code lines (sum)** | 274,497 |

Rough mix without the huge JSON pile: **TypeScript is the largest single language**; remaining JSON in this run is **10 files / ~78k code lines** (e.g. config or smaller JSON).

---

## TypeScript only — tests vs non-test

**Test files:** names matching `*.test.ts`, `*.test.tsx`, `*.spec.ts`, `*.spec.tsx` (no `__tests__/` trees in this repo).

| Bucket       |     Files |  Code lines |  Blank | Comment |
| ------------ | --------: | ----------: | -----: | ------: |
| **Test**     |       202 |      35,286 |  4,288 |     253 |
| **Non-test** |     1,127 |     122,543 | 13,230 |   6,961 |
| **TS total** | **1,329** | **157,829** | 17,518 |   6,214 |

**Physical line count for TS only** (`wc -l` style): **181,686** total — **~39,827** in test files, **~141,859** in non-test. The gap vs `cloc` “code” is mostly blanks + comments.

---

## Takeaways

1. **Headline TS size:** ~**1.3k** TS files and ~**158k** lines of TS “code” per `cloc`, split ~**22%** test files by file count (202/1329) and ~**22%** of TS code lines in tests (35,286/157,829).

2. **Total repo line count is dominated by JSON** if you include all `.json`; for “how big is the codebase we edit,” use the JSON-excluded figures or the TS-only tables above.

---

## Commands used (reference)

Full tree:

```bash
cloc . \
  --exclude-dir=node_modules,.git,.next,out,build,coverage,test-results,playwright-report,.vercel,.pnpm-store,dist,.cache \
  --exclude-ext=snap
```

TS test vs non-test:

```bash
cloc . \
  --exclude-dir=node_modules,.git,.next,out,build,coverage,test-results,playwright-report,.vercel,.pnpm-store,dist,.cache \
  --exclude-ext=snap \
  --include-lang=TypeScript \
  --match-f='\.(test|spec)\.(ts|tsx)$'

cloc . \
  --exclude-dir=node_modules,.git,.next,out,build,coverage,test-results,playwright-report,.vercel,.pnpm-store,dist,.cache \
  --exclude-ext=snap \
  --include-lang=TypeScript \
  --not-match-f='\.(test|spec)\.(ts|tsx)$'
```

Exclude JSON for source-like totals:

```bash
cloc . \
  --exclude-dir=node_modules,.git,.next,out,build,coverage,test-results,playwright-report,.vercel,.pnpm-store,dist,.cache \
  --exclude-ext=snap,json
```
7

Hey, thanks for the pushback and for the detailed codebase analysis.

Fair point, my previous reply was too generic. There are a few forum reports with the same pattern (a steady 9 to 15 minutes even on small PRs). The latency is usually isolated to the bug detection step:

So diff size isn’t the only factor, and I can’t share an ETA on a fix yet.

To tie your specific runs into the investigation, can you run bugbot run verbose=true as a comment on a fresh PR where this reproduces, then paste the serverGenReqId_... here (both would be ideal, from @luchillo17 and @rushil)? With those IDs we can pull the logs for your exact runs and confirm whether it’s the same bottleneck step or different root causes.

On Autofix cost (@luchillo17), usage is billed against your main plan’s Cloud Agent quota at the normal rates, and you can see it in the Dashboard alongside other agent runs. That way you can track it in real time and only enable Autofix on important comments so you don’t burn through your budget.

8

Does autofix run on old comments? I had the impression autofix would only run if its activated when bugbot finishes. What’s the point of activating autofix for specific comments? at that point if I’ve seen the comment may as well fix it locally and push the fix, or do you mean severity level?

9

Alright here we go.

Non verbose run:
Request ID: serverGenReqId_7a4ecf8a-648e-4f3a-8c79-d1a220a90a30

image
image528×391 13.8 KB

Verbose one (funny enough the verbose run found 1 issue):
Request ID: serverGenReqId_902ed1e1-3a6d-4274-91c7-a69f48950d11

image
image526×368 13.6 KB

10

Thanks, I grabbed both IDs. I’ll pass them to the BugBot team so they can check the logs for those exact runs and compare them to the bug detection stage where it gets stuck in other reports. Once we know the root cause, I’ll reply in the thread.

@rushil, if you catch a repro in the monorepo, drop the serverGenReqId_... here from bugbot run verbose=true. Then we can compare two different load profiles in the same ticket.

On Autofix, quick answer:

  • Autofix doesn’t re-run on existing comments by itself. It triggers when BugBot posts a new comment, or when you manually trigger it.
  • The split between enable on all comments vs on specific ones is about the trigger mode in the dashboard:
    • Auto on all: every BugBot note immediately starts the Cloud Agent to try to fix it. Handy, but it burns Cloud Agent quota fast, especially on big PRs with lots of notes.
    • Manual or specific ones: Autofix only runs when you decide to trigger it on a specific comment, like via a reply or a button. The idea is you often close half the notes yourself in a minute, and Autofix only makes sense for the ones that would take you 10 to 20 minutes to investigate and fix. This is about saving Cloud Agent credits, not about severity.

A severity filter as a separate setting is a feature request, separate thread: Enabling bugbot to autofix low-complexity bugs (!= low severity)

14

Hey @luchillo17 I said I’d come back to this thread, so I’m closing the loop.

I passed the logs for your two Request IDs to the team. I don’t have a specific fix point I can tie to a version yet. I don’t want to mislead you by saying it’s fixed if that isn’t confirmed. Since April there’s been noticeable work on Bugbot, so some runs might be faster, but that doesn’t guarantee it’s resolved for your case.

Can you check the latest runs and see if the timing is more stable? If you’re still consistently seeing 10 to 15 minutes even on small PRs, run bugbot run verbose=true on a fresh PR and send a new serverGenReqId_... (and tag @rushil for the monorepo too if they can repro). With the new IDs we’ll compare load profiles and see if it’s the same bottleneck step or a different one.

I can’t share an ETA on the latency yet.

15

I ended up cancelling and switching to Devin Review, so I won’t be able to test the latest runs. Best of luck with the debugging process though!

16

There have been improvements as I see runs of 1 or 2 mins, but not sure if its that it was moved to the quick review effort instead of deep one.

17

Glad to hear it. 1 to 2 minutes vs the old 10 to 15 is a big difference.

And your intuition is right. Bugbot does have an effort level setting, shipped in May, and it’s basically your quick vs deep idea:

  • Default: optimized for speed
  • High: spends more time reasoning, reviews are slower and cost more, but it can find more bugs
  • Custom: natural language rules for when to use Default vs High

One important detail. This setting is only available if usage-based billing is enabled. If you don’t have it enabled, you won’t see these options in the Bugbot dashboard. That means your speedup definitely isn’t from switching effort level, it’s from overall Bugbot improvements since April.

So:

  • If usage-based billing is enabled, check your Bugbot dashboard and see which level your reviews are using. If you want more thorough reviews, switch to High or set up Custom, for example High for infra and backend, and Default for everything else.
  • If it’s not enabled, the setting won’t be there, and the faster runs are just improvements on our side.

Let me know if the timing or quality doesn’t match what you expect.

18

So even though it says its in quick mode, because I’m not in usage based billing yet, its still using the high effort version?

19

No, High effort isn’t being used silently.

The effort level customization (Default / High / Custom) is tied to one thing: usage-based billing for BugBot being enabled. It’s available to both Team admins and individual users who have that billing enabled.

You don’t have usage-based billing enabled yet, so you won’t see the effort toggle and BugBot runs on Default. Default is the speed-optimized quick mode that shows the dashboard. So there’s no hidden High happening there, and you also can’t switch to High without usage-based billing.

So your 1 to 2 minute timings are Default plus general BugBot improvements since April, not an effort level change. If you want deeper but slower and more expensive reviews, you’ll need to enable usage-based billing. Then you’ll see High and Custom options.

Let me know if the timings start creeping up again.