Limits and quotas

This page is the canonical source for every numeric limit in BattleTest. The how-to guides link here rather than restating these figures.

PR review is free. There are no tiers to compare; the only thing that changes a review limit is whether the repository is public or private.

PR review limits

BattleTest runs two review types. Advanced reviews run the full agentic pipeline (AI code analysis, CVE scanning, regression detection). Basic reviews are a fast single-pass scan (secrets and CVEs only) that runs automatically as a fallback when the advanced limit is reached. See How PR review works for the distinction.

Repository	Advanced reviews	Basic fallback
Public	20 per hour, per repository	20 per hour, per repository
Private	10 per month	5 per hour

Note

Public-repo limits are metered per repository, not per account. Twenty advanced reviews per hour applies to each public repo independently, so a busy merge train on one repo does not consume another’s quota. Private-repo limits are metered per user, because there the limit is the product boundary rather than an anti-runaway guard. Aggregate spend is bounded globally rather than per user.

On a public repo the accuracy-critical verifier agent runs on the higher-capability model even though the rest of the pipeline does not: a false positive on a public PR comment costs more than the model does.

Hourly limits use a rolling 60-minute window, not a clock-hour reset. Monthly caps reset on the first of each UTC month. When the monthly advanced cap is reached, reviews fall back to basic scans for the rest of the cycle so every PR still gets coverage.

Live testing limits

Live application testing is not self-serve. It runs as a dedicated per-client deployment, and run allowances, cadence, and depth are set as part of that engagement rather than by a limit on this page. A standard account cannot start a live run; the API refuses it.

Domain registration and DNS verification remain open to any account, capped at 50 active verified domains as an anti-abuse ceiling. That ceiling exists to bound pathological registration, not to price anything.

One battletest is one run regardless of scope. Depth is chosen per run (Discover, Probe, or Full Exploit) and multiple domains or assets covered inside one run are still one run.

Scan duration

A live security test runs until the agents have thoroughly covered the target; there is no time budget you need to plan around. Duration scales with how much there is to test, so a small hardened site finishes quickly while a large or issue-rich application takes longer (the agents chase every confirmed weakness deeper). Total AI work per run is bounded by your fair-use compute limit, not a clock.

A 90-minute wall-clock backstop exists as a safety net against a hung run, not as a coverage limit; runs are not designed to approach it, and one that does indicates a fault worth reporting rather than a target too large to finish.

Operation	Typical duration
PR review (all four passes)	2–4 minutes
Discovery scan	5–15 minutes (depends on application size)
Live test (probe)	~15–40 minutes for a typical application
Live test (with exploit validation)	longer for large or exploit-rich targets

Fair-use compute limit

Underneath the countable limits above sits a second limit, measured in compute rather than in events: a monthly fair-use compute limit on the total AI work an organisation runs, across PR reviews and battletests combined. It exists because the countable limits alone do not bound cost. Reviews vary enormously in how much work they take, so a month that looks identical by count can differ by an order of magnitude in compute. It is sized well above normal usage, so most teams never see it.

• It is measured across all AI usage for your organisation: PR reviews and battletests together.
• It is a soft limit. Work already in progress always finishes. It only affects new work.
• It resets each month.

The limit you will meet day to day is the countable one above, not the fair-use limit.

What makes a run use more compute

Cost scales with how much there is to examine, not with a clock. A pull request uses more compute when the diff is large, when it touches security-relevant code paths that pull more of the surrounding codebase into context, or when confirmed findings send the analysis agent deeper. A battletest uses more when:

• The target is exploit-rich. Every confirmed weakness opens new avenues: a recovered credential unlocks authenticated areas, an exposed endpoint reveals more endpoints. The agents follow each thread, so a target with many real issues is tested far more deeply than a hardened one.
• The site is large or dense. More pages, forms, and API endpoints mean more surface to map and probe.

Additional testing consumes more of the monthly compute allowance.

What happens when you reach it

When your organisation reaches its monthly fair-use compute limit:

1. Work already in progress finishes normally. Nothing is interrupted mid-run.
2. PR reviews keep running in a lighter-weight mode. The pipeline drops to the faster model rather than stopping, so no pull request is left unreviewed.
3. New battletests soft-stop until the month resets. You will see a Soft limit reached this month note on Settings → Usage, and you will get a notification.

The limit resets at the start of each month with no action needed. Reaching it regularly means BattleTest is doing more work than the free product is sized to absorb. If that is where you are, get in touch about a dedicated deployment.