---
title: "Frazer Reviewer: code review with evidence · Frazer"
description: "A GitHub App that comments inline only on findings it can back: traced by a verifier from another model family, matched by a rule you approved, or found by a tool in the diff. Everything else is folded into one summary."
url: https://frazer.ai/reviewer
index: https://frazer.ai/llms.txt
tokens: 2865
---

> For agents: every page on frazer.ai is indexed at https://frazer.ai/llms.txt.

# Frazer Reviewer: code review with evidence · Frazer

**Frazer Reviewer**  frazer.ai

# Code review with evidence.  
Or it stays silent.

A GitHub App that reviews every pull request your policy covers, from people and from agents. It comments inline only on findings it can back with evidence, such as a trace by a verifier from another model family or a rule you approved. Everything else is folded into one summary, edited in place.

[Connect GitHub](https://frazer.ai/start?product=reviewer) [Read the docs](https://frazer.ai/docs)

*The Findings tab of a Frazer Reviewer review in the demo organization Acme, for checkout-api#1931 “Validate coupon codes on /v1/checkout”: 4 findings ordered by severity, then evidence. A high correctness finding is reproduced by a failing test and carries a three-line suggested fix; a medium finding renders the production memory limit against live use in a GitOps diff; one analyzer finding is already fixed and one is dismissed. 9 candidates without evidence were kept silent and folded into the summary on GitHub.*

One review: findings with their evidence, and what was kept silent product UI, demo organization

01 · How it works Fig. 1

## Evidence first, then a comment.  
Hunches stay folded in the summary.

**Fig. 1** One review per pull request head, and how feedback becomes a rule

02 · What lands on GitHub Fig. 2

## One review per head.  
Edited in place, never reposted.

A new push edits the same summary. A new inline comment appears only for a new finding on a changed line, and every inline comment carries one of six evidence badges with what backs it.

-   Verified A verifier from another model family traced the code 2 to 4 path:line citations, callers and guards included
-   Rule · name A rule your organization approved matched The rule's measured precision and a link to it
-   Analyzer · tool A tool found something new in this diff The tool and its rule id
-   GitOps diff The change rendered against live state The object, the live value and the cost change
-   Reproduced A test or command failed at the PR's head The command, the output tail and the artifact
-   Runtime Metrics or an incident on the code it touches The series, the window and a chart link

*The summary review Frazer Reviewer posted on checkout-api#1931 in the demo organization Acme, as shown in the console: one comment that lists 3 findings with their evidence (a reproduced test, a GitOps diff and an analyzer), folded sections for the walkthrough, checks, 7 findings that were not verified, 2 pre-existing issues and the run passport, and the first inline finding with a committable suggestion.*

**Fig. 2** The summary and the first inline finding product UI, demo organization

03 · Rules and checks

## Rules you test before you trust.  
Configured like code, from the base branch.

-   ### Trusted base, untrusted PR
    
    Policy, rules and `.frazer/review.yaml` come from the base branch and the Frazer API. Text in the pull request is data, never instructions.
    
-   ### Rules you backtest
    
    After three similar replies Frazer drafts a rule and shows what it would have silenced on the last 50 PRs. An admin approves it; it retires if its precision falls below 60 %.
    
-   ### Checks in plain language
    
    Write a pre-merge check, set it to Off, Warn or Block, and save it only after a backtest on the last 20 merged PRs.
    
-   ### Your guideline files
    
    `AGENTS.md`, `CLAUDE.md`, `REVIEW.md` and similar files are read automatically, each scoped to its folder and switchable.
    

```
# .frazer/review.yaml, read from the base branch
version: 1
trigger: { on_open: true, on_push: incremental, drafts: false, skip_authors: ["renovate[bot]"] }
depth:   { default: standard, deep_when: { risk: high, paths: ["services/billing/**"] }, quick_when: { lines_lt: 20 } }
execute: { tests: auto, preview: on_label("preview"), fork_prs: never }
post:    { inline_min_grade: verified, inline_min_severity: medium, max_inline: 8, nits: summary, block_on: [] }
paths:   { ignore: ["**/*.pb.go", "gen/**"], instructions: [{ glob: "migrations/**", text: "Every migration is reversible." }] }
lanes:   { manifests: { app_pattern: "{env}-{service}", policies: [frazer-policy] }, contracts: { buf: true } }
memory:  { learn: drafts }    # off | drafts
privacy: inherit              # the stricter of org and repo wins
```

```
$ frazer reviewer enable --repos 'pellwyn/*' --depth standard --trigger open,push
$ frazer reviewer policy apply -f review-policy.yaml --dry-run
$ frazer reviews request pellwyn/payee-service#412 --depth deep   # prints the cost estimate first
$ frazer review .                          # review the local diff in a Frazer sandbox
$ frazer review-rules list --state draft && frazer review-rules approve <rule>
```

```
/frazer review [quick|standard|deep] [full]
/frazer pause · /frazer resume · /frazer cancel
/frazer summary · /frazer explain [n] · /frazer diagram
/frazer check [name]                                      # run one pre-merge check
/frazer wrong|useful|resolve [n]                          # feedback reaches the ledger
/frazer remember <rule>                                   # creates a rule draft
/frazer config                                            # effective config, with where each key came from
/frazer run                                               # lets a fork PR run code
/frazer fix [n|all]                                       # an agent opens a stacked PR
@frazer-reviewer <question>                               # chat in the thread
```

04 · What you get

## Built around your repositories.  
And the platform they run on.

-   ### An inbox, not a dashboard
    
    What needs you across repositories: your PRs with findings, rules to approve, failing checks, paused reviews.
    
-   ### A verifier from another family
    
    Every finding of medium severity or higher is checked by a model family other than the one that found it.
    
-   ### Manifest lane
    
    Pull requests to environment repositories, rendered against live GitOps state with your policies and the cost change.
    
-   ### Contract checks
    
    Proto and OpenAPI changes run through `buf breaking`, with the list of consumers they touch.
    
-   ### Quality you can check
    
    Coverage, accepted, refuted, resolved at merge, time to first review and cost per accepted finding.
    
-   ### CLI and MCP
    
    `frazer review .` checks a local diff in a sandbox; coding agents read your rules over MCP before they open a PR.
    
-   ### Zero retention
    
    No index; counts and fingerprints only; zero-retention model providers only.
    
-   ### Tests, previews and fixes
    
    Tests in your devbox image, previews on your own cluster, rollout watch and fixes by an agent.
    

05 · Controls

## It reads. It never pushes.  
Every review has a cap and a record.

### Who may do what

Review policy

Turns on automatic review for repositories by pattern. A repository's `.frazer/review.yaml` changes only the keys the policy marks overridable.

Admins

Approve learned rules, each after a backtest. Nothing is learned silently.

The Reviewer App

Reads code and writes comments and check runs. It never pushes, approves or merges.

Fixes

`/frazer fix` starts an agent session through the separate Frazer Agents App, after a confirm sheet with the cost.

### What is logged

-   A run passport on every review: models, served deployment, fallback, prompt hash, cost and time.
-   Findings, evidence and threads kept **180 days** by default; counts and fingerprints only in zero retention.
-   Code stays in the sandbox and is deleted when the review ends.
-   Secrets are redacted from everything sent out.
-   Replies, reactions and `/frazer wrong` reach the findings ledger, next to the rule drafts they produce.

### At the cap

-   A monthly dollar cap pauses new reviews and **never posts half a review**.
-   Alerts at 50, 80 and 100 % of the cap.
-   A cost estimate before every Deep review.
-   No per-developer hourly limits; fair share per organization.
-   Paused, capped and skipped are explicit check-run results with the reason. A model outage pauses reviews; fallback stays off unless you allow it.

06 · Pricing

## Priced per committer.  
Every review shows its cost.

You pay for the people who commit; agents take no seat. Public repositories are free. Every review shows what it cost, a Deep review shows its estimate first, and a monthly cap stops spend before it surprises you.

[See every price](https://frazer.ai/pricing#lines)

Per committer **$15** per active committer a month: a person with a commit in a reviewed pull request

Your own model key $7.50 per committer, through the [LLM gateway](https://frazer.ai/ai/gateway)

Reviews 100 Quick or Standard per paid committer a month, pooled; then $0.20 each

Deep reviews $1, or $3 with a preview; the estimate comes first

Agents No seat: model tokens at the gateway's price, or your own key at no fee, plus $0.01 to $0.50 a review by depth; the estimate comes first

Spend A monthly dollar cap; never half a review

Questions

## Frazer Reviewer, answered.

What counts as evidence?

A finding goes inline only with an evidence badge: a verifier from another model family traced the code, a rule you approved matched, a tool found something new in this diff, or the change was rendered against live GitOps state. A failing test at the PR's head and metrics or an incident on the code it touches count too. Everything else is folded under Not verified in the summary.

Do I need anything else on Frazer?

No. Frazer Reviewer is its own GitHub App. Install it on the repositories you choose, without granting write access to your code, and use it with nothing else on Frazer.

Will it block my merges?

Not unless you ask. The check run ends neutral. It fails only for checks you set to Block or for findings your policy lists in `block_on`, and your branch protection decides whether that stops a merge.

Which models does it use?

Models you choose, reached only through the Frazer LLM gateway, with your own key or billed by Frazer. The verifier always comes from a different model family than the one that found the issue and the agent that wrote the PR. You can pin models, and a review never falls back to another model silently.

Does it run my code?

Yes, in a sandbox. It reads a checkout, runs tests in your project's devbox image inside a sandbox or a microVM, with no secrets and no write tokens, and can deploy a preview on your own cluster. Fork pull requests run code only after a maintainer types `/frazer run`.

Can I keep my code from being stored?

Yes. In every mode your code stays in the sandbox and is deleted when the review ends. Zero-retention mode also keeps no index and stores only counts and fingerprints; the findings text lives on GitHub. Private placement runs the Reviewer on your own servers, with your own model endpoint.

## More in Agents

-   [**Frazer Agents** Always-on, supervised](https://frazer.ai/agents)
-   [**Agent squads** Managers, workers, objectives](https://frazer.ai/agents#squad)
-   [**Agent images** Lite to GPU, or your own](https://frazer.ai/agents#images)
-   [**Frazer app** Desktop app and editor extensions](https://frazer.ai/app)

## Fewer comments.  
Each one with evidence.

[Connect GitHub](https://frazer.ai/start?product=reviewer) [Read the docs](https://frazer.ai/docs)
