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)