Reviewers & Models

The reviewer catalog, the model each one runs on, the benchmarks behind that choice, and how a lineup is named on a review.

A reviewer is a skill with a model behind it. The catalog is what you name reviewers from; a lineup is the reviewers array on a review and is never a stored object of its own.

The catalog

curl --fail-with-body "https://ionwarp.com/api/v1/reviewers?limit=5" \
  -H "Authorization: Bearer $IONWARP_API_KEY" \
  -H "Project-ID: $PROJECT_ID"

Registry order. Every row carries the reviewer's one model fact at two tiers — model + reasoning_effort (the governed pin the reviewer runs on today) and max (the benchmark leader the one retry runs on when the pinned attempt fails) — plus auto (the ionwarp:<id>:auto spelling of that pin), benchmark_status, and project — whether this project has the reviewer enabled. ?q= searches. A project can pin a different {model, reasoning_effort} per reviewer through ionwarp.review.model_pins; a run's reviewers[] entry outranks that pin.

The models measured for a reviewer

curl --fail-with-body "https://ionwarp.com/api/v1/reviewers/code-review/models" \
  -H "Authorization: Bearer $IONWARP_API_KEY" \
  -H "Project-ID: $PROJECT_ID"

One row per model the benchmarks app has measured for that reviewer, the current pin flagged, each with its benchmark record. benchmark_source names the environment the rows came from; an environment with no benchmarks binding answers benchmark_source_unbound rather than an empty list that reads as "nothing measured".

Naming a lineup

A review takes reviewers as strings, highest-precedence form first:

"security-review@google/gemini-3.8-flash" — this reviewer on this model, for this run only.
"security-review" (or "ionwarp:security-review:auto") — this reviewer on its governed pin.
omit reviewers — the planner picks the lineup from the diff.

Model ids are validated by syntax only (org/model), so any OpenRouter model runs on day one and is priced from the provider's actual usage. A string naming a reviewer that is not in the catalog is refused by name at create time. The object form — {key, skill, model} with skill as an immutable revision — is the advanced form for controlled trials, on the reviews reference.

Enabling reviewers for a project

PATCH /reviewers/{id} with {"enabled": true} (or false) is the one writable field on the per-project reviewer row; it is what the catalog page's switch writes. An enabled roster is what automatic reviews plan from; a lineup named on a review runs regardless of enablement.

Grading a trial, then promoting the winner

GET /reviews/{id} returns the receipt with one row per reviewer — the model that actually ran, verdict, findings count, real cost, phase timings. That is the grading source for every trial; a PR comment is a rendering of it. A model that wins across reviews is promoted by pinning it in the project's configuration (ionwarp.review.model_pins, keyed by reviewer id), and a winner that holds up across projects graduates into the reviewer's own SKILL.md pin.

Next: Reviews for what a lineup produces · Scorecards for the same pin mechanism on repo-wide rubrics · Control Plane for the brakes that stop a run before any reviewer starts.