Team Budgets for AI Code Review in a Monorepo

The monorepo money pit

Monorepos solve a lot of problems. Shared tooling, atomic cross-package changes, one CI pipeline to rule them all. But they create a budgeting nightmare that nobody talks about: when fifty engineers across eight teams all commit to the same repository, who pays for the AI reviews?

If you set one global budget, the biggest team burns through it first. The platform squad with twelve engineers shipping continuously will consume 80% of the monthly allocation before the mobile team — four people shipping once a week — even gets a look in. The mobile team's PRs start getting skipped. They complain. You raise the cap. The platform team consumes the new headroom. The cycle repeats.

This isn't malicious. It's arithmetic. In a monorepo with a shared AI review budget, the team that ships the most PRs gets the most reviews. The team that ships the riskiest PRs might get none.

Budget by contributing team, not by repo

PURA's contributing-team budget restrictions solve this by tracking spend against the PR author's team membership — not the repository the PR targets. When a platform engineer opens a PR, the cost is attributed to the platform team's budget. When a mobile engineer opens one, it hits the mobile team's pool. Same repo, different budgets, zero overlap.

The setup is straightforward. In a review agent's budget restrictions, you add blocks of type Team (Contributor). Each block carries a glob pattern matching one or more GitHub team slugs — and each block gets its own entity budget caps:

• Platform team — platform-*, $30/month entity budget. Twelve engineers, high throughput. They'll use it.
• Frontend team — frontend-*, $20/month entity budget. Eight engineers, moderate throughput, but UI diffs tend to be larger and consume more tokens per review.
• Mobile team — mobile, mobile-*, $15/month entity budget. Four engineers, lower volume. They should never get starved by the other teams.

Each team's spend is tracked independently. When the platform team burns through their $30 on the 22nd, their PRs stop getting reviewed — but frontend and mobile continue uninterrupted. The agent-level overall cap still applies as a global backstop, but it's intentionally set above the sum of all team budgets so it only triggers in genuinely exceptional months.

The contributing team is resolved from the PR author's first team membership in the GitHub organization. If an engineer belongs to multiple teams, PURA uses the first one returned by the GitHub API. Plan your team memberships accordingly.

The governance conversation

Per-team budgets force a conversation that most engineering organizations have been avoiding: who decides how much AI review budget each team gets?

There's no single right answer. In some orgs, the CTO allocates budgets top-down based on team size and risk profile. In others, engineering managers negotiate quarterly and adjust monthly based on actual usage. A few teams we work with tie budgets to on-call rotations — the team currently carrying the pager gets a higher monthly cap because their changes need more scrutiny.

PURA doesn't dictate the governance model. It provides the plumbing. The analytics dashboard shows each team's burn rate, average tokens per review, and which models they're hitting. Armed with that data, the conversation shifts from "someone used all the budget" to "here's who used what, and here's whether that's right."

What the analytics show

Filter the PURA analytics dashboard by contributing team and you get a clean per-squad view: total reviews run, average cost per review, tokens consumed, findings surfaced, and which providers were used. Export it as CSV for quarterly planning. Share the dashboard link with EMs so they can see their own team's usage without asking you for a report.

The most useful pattern we see: at the start of each month, set team budgets conservatively. By the 15th, check the dashboard. If a team is burning 20% per week and their changes are high-risk, bump their cap. If a team is at 2% utilization because their PRs are all small and low-risk, leave it. Budgets shouldn't be set-and-forget — they should track reality.

Setup in five steps

1. Open the PURA dashboard and select (or create) a review agent.
2. In the Budget Restrictions section, add a block of type Team (Contributor).
3. Set the Name Matches field to a glob matching one team slug, e.g. platform or frontend-*.
4. Set restriction to Allow. Configure entity budgets (daily, weekly, monthly) for this team.
5. Repeat for each contributing team. Add a final Deny block with the *pattern if you want to explicitly exclude any team you haven't budgeted for — or an Allow block with a small default budget as a safety net.

Contributing-team budgets are the fastest way to make AI review spend fair in a multi-team org. They don't require repo splits, CODEOWNERS changes, or GitHub org restructuring. They just require a dashboard, five minutes, and a rough sense of which teams need how much review depth.