Docs

Configuration

Set up review agents in the dashboard: connect your API keys, pick models, and decide which pull requests each agent reviews.

1. Review agents

A review agent is a reviewer you configure in the dashboard. Each agent has:

  • Title: the label your team sees, such as Security Agent.
  • Name: letters and numbers joined by hyphens, such as security-agent, set once at creation. It names the folder of the agent's review-agent skill.
  • Type: Code Review reviews the diff and the code around it, and PR Quality Review reviews the title, description, labels and commit messages.
  • Status: Active agents review, Inactive agents are paused.
  • Budgets and providers: daily, weekly and monthly budgets, and one or more providers.

Add as many agents as you need: one per team, one per concern, or a single agent for everything. Every agent that applies to a pull request reviews it, and PURA merges their findings into one review with one verdict.

The PURA review agent editor — name, status, agent daily/weekly/monthly budgets, and provider blocks for OpenAI, Claude, and Gemini with keys, models, and per-provider budgets
A review agent: title and name, status, budgets, and providers with your own keys and models.

Start simple. One active agent with a key is enough. Split into more agents as your teams grow.

2. Providers and your keys

Each agent uses one or more providers: Anthropic (Claude), OpenAI, Google (Gemini) or an OpenAI-compatible provider. Paste your API key once in the dashboard. PURA encrypts it and shows it masked from then on.

For Anthropic, OpenAI and Google, you pick models from a list and PURA already knows their prices. For OpenAI-compatible providers, type the model name and its input and output price per million tokens, so PURA can track spend against your budgets.

Every review runs on your key, so your provider bills inference directly at its published rates. PURA's plan is a separate, flat fee with no markup on inference.

3. Choose models

For each provider, pick a model for three tiers:

  • Default: used for most reviews, and to merge findings when several agents review.
  • High: a stronger model for risky or complex changes, such as payments, auth or core infrastructure.
  • Low: a cheaper model for routine changes, such as docs, dependency bumps or small refactors.

The agent's routing instructions pick the tier for each pull request, so each change gets the depth of review it needs without paying top-tier prices for every one.

4. Provider fallback

Add more than one provider and they form a fallback chain. PURA uses the first provider that still has budget, so reviews keep running when one provider's budget is spent.

For example: Anthropic first, then OpenAI and Google as backups. When the Anthropic budget for the day is used, the next pull request is reviewed on OpenAI.

5. Scope an agent

An agent applies to every pull request in your installed repositories until you scope it. Scoping rules use glob patterns such as * or acme/payments-*, and can match on:

  • Contributing team: the team the pull request author belongs to.
  • Reviewing team: the team requested to review the pull request.
  • Author: the person who opened the pull request.
  • Repository: by name or pattern.
  • Pull request: a repository plus one or more labels.

Each rule is Allow or Deny. Deny rules are checked first, then PURA uses the first Allow rule that matches. An Allow rule can carry its own daily, weekly and monthly budget, which each matching team, author, repository or pull request gets separately. See where budgets apply.

An agent's budget restrictions — repository, user, and team blocks, each with allow/deny and per-entity daily, weekly, and monthly budgets
Scoping rules by repository, author and team, each with Allow or Deny and its own budgets.

For multi-team orgs: give each team an agent scoped to its repositories, with a budget that matches its usage. One team's busy month then leaves every other team's budget untouched.

6. Cross-repo access

Agents read files from the pull request's own repository. To give an agent context from other repositories, such as shared libraries or API contracts, add cross-repo access rules to it in the dashboard.

Available on Scale and above. See pricing.

Each rule uses four glob patterns, and all four must match:

  • Organizations, e.g. acme or acme-*
  • Repositories, e.g. acme/shared-lib or acme/*
  • Branches, e.g. main or release/*
  • File paths, e.g. **/*.ts or src/**

Rules are Allow or Deny, and Deny wins. The agent reads exactly what your Allow rules grant and nothing more.

Next