The review pipeline

A review in Diffgazer is a fixed sequence of steps that turns your git diff into a ranked list of issues. The work that finds those issues is split across review lenses: focused perspectives like correctness, security, or performance. Each lens is driven by its own agent, a named reviewer that knows how to look for one kind of problem. You pick which lenses run, the pipeline runs their agents over your changes, and what comes back is a deduplicated, severity-sorted report.

Every review moves through the same four steps in order. The labels below are the exact ones the UI shows as the review progresses.

Collect diff

The pipeline reads your changes from git. By default that means unstaged changes; staged mode reads what you have already added with git add. If there is nothing to review, the step stops and tells you which mode to try instead. Anything under .diffgazer/ is dropped before analysis so the tool never reviews its own state files. If you passed an explicit file list, the diff is narrowed to just those files.

Project context

Before any agent runs, Diffgazer builds a short snapshot of the repository: a small graph and summary that gives the agents something to reason against beyond the raw patch. This step is best-effort. If the snapshot fails to build, the review keeps going with empty context rather than aborting.

Review issues

This is where the agents do their work. The active lenses run over the diff, each agent reporting the issues it finds for its lens. Results from every lens are merged, near-duplicate issues are collapsed, anything below your severity threshold is filtered out, incomplete issues are dropped, and the survivors are sorted by severity. If a lens fails, the others still finish and the report notes the partial result.

Generate report

The surviving issues are assembled into the final report, which is then persisted to disk along with the branch, commit, profile, lenses, and how long the run took. Once this step completes, the review is saved and available in your history.

Once the diff is collected, Diffgazer estimates what it will cost as a prompt and compares that to a per-call budget: the smaller of the model's context window minus the tokens reserved for the answer, and the effectiveCallTokenCap setting. The cap defaults to 49,152 tokens (48k) even when the model advertises a much larger window, because models read a short call better than a full one — long-context evaluations show review quality dropping well before large windows fill. You can raise or lower the cap in configuration if your model handles longer calls well.

A diff under the budget runs exactly as described above, one call per lens. A diff over it is never truncated or refused: it is split into batches of whole files, kept in diff order, and each lens reads its batches sequentially, one call per batch. A file is never split across batches. Every batch's prompt still names every changed file, so the model knows what else changed by name, but its <code-diff> carries only that batch's files.

Splitting has a cost, and Diffgazer says so up front: a batched review starts with a warning stating the batch count and the estimated input tokens for the whole run. A finding that spans two batches — a function changed in one file, its caller in another — is invisible to any single call. That is what the synthesis pass is for: after all lenses settle, one extra dispatch reads a digest of every collected issue (severity, category, file, lines, title) plus the full changed-file list, and reports cross-file problems only, attributed to lens synthesis. It sees the digest and the file names, not the diffs, so it connects findings the batches already made; it cannot surface a cross-file bug no batch flagged any side of. If the synthesis dispatch fails, it is reported like any other failed lens and the review still completes.

A batched review also costs more than a single call, so the per-review budget envelope (input tokens, response bytes, and wall time) is raised before the first dispatch to the plan's disclosed estimate plus 20% headroom — an admitted review is not stopped mid-run by a budget sized for one call. The per-review spend cap is never raised: it is your money, so a batched plan whose worst case runs past it is refused up front, naming the cap, instead of being started and stopped halfway. Single-batch reviews keep the configured budgets untouched, and their prompts, events, and warnings are identical to a review run before batching existed.

Two hard failures survive batching. A single file that does not fit the model's window even on its own stops the run, naming the file, its estimated tokens, and the window — batching splits between files, never inside one. And one fixed ceiling remains at 10MB, for the lockfiles and vendored trees no model choice would rescue. A diff over 512KB that still fits one call starts the review with an advisory, because one pass over that much change finds less than several narrower ones.

Five lenses ship with Diffgazer, and each maps to exactly one agent. The lens is the perspective you choose; the agent is the reviewer that applies it.

A sixth lens id, synthesis, exists but is never yours to pick: the engine dispatches its Synthesizer agent only after a review that ran in more than one batch, and its cross-file issues appear in the report like any other lens's.

Which lenses run comes from an ordered fallback: an explicit lens list wins, then the active profile's lenses, then your configured default lenses. Settings validation guarantees that the configured list is non-empty. See providers and models for how each agent reaches your AI provider.

The agentExecution setting decides whether agents run one at a time or all at once. It defaults to sequential, so by default each lens runs in turn rather than concurrently. Switching it to parallel raises the concurrency to the number of active lenses, so every agent runs at the same time. Findings from successful lenses use the same merge, filter, and sort rules in both modes, but the final reports are not guaranteed to match. The extra concurrency can trigger provider rate limits or transient failures. If one lens fails, the others continue and produce a partial report. You set this in configuration; see transport failed for what to do when an agent drops out.

The review backend accepts a lens filter, a profile, or an explicit file list when starting a review, but the web app only sends the review mode and relies on your saved default lenses. The git status and diff routes likewise have no dedicated screen. Treat these as backend capabilities, not features you can reach from the web app today. See the API reference for the complete mounted paths.

• Providers and models covers how agents talk to your configured AI provider.
• Review output describes the shape of the report this pipeline produces.