Review debt

Review debt tells you how the review stage is actually going for your workspace. It shows how long reviews sit before someone looks at them, how long they take to close, how often work bounces back for rework, and what all that review activity costs. The subject is the review queue itself.

This page does not rank your models. For a model or stage comparison, open the Quality report’s By stage and model panel instead — see Stage signals.

Where to find it

Web app: open the Dashboard, find the Velocity panel, and click Review debt. There’s no sidebar entry for this page — the Dashboard panel is the way in.

CLI:

ch quality review-debt

Pass a workspace name, slug, slug path, or full ID as the first argument to scope it elsewhere; without one, the command uses the workspace the CLI is pointed at. See Using the ch CLI for how ch resolves a workspace reference. Add --json to get the raw data instead of the table.

Choosing a window

Both surfaces offer the same four windows:

Window	Covers
Today	The current day, UTC
Yesterday	The previous full day, UTC
Last 7d	The 7 days before today, plus today
Last 30d	The 30 days before today, plus today

The CLI takes --window today, --window yesterday, --window week, or --window month — the default is week. For a custom range, use --since instead, with a relative duration (3d, 12h, 45m) or a full RFC 3339 timestamp — the same grammar as ch costs --since. --since and --window are mutually exclusive, and --since can’t reach back more than 90 days.

In the web app, the window you pick travels in the address bar, so a filtered view is a link you can send to a teammate — see Sharing a view with a link. The page also draws a sparkline of reviews entered per day across the window, so you can spot a spike at a glance.

What each number means

Number	What it tells you
Reviews entered	How many times a task moved into the review stage during the window. A task that bounced back to review twice counts twice.
Review latency (median / p90)	How long a review took, from entering review to leaving it. Only rounds that have actually closed count — one still in review contributes nothing, so this figure can have fewer samples than “reviews entered.”
Wait to first review session	How long a task sat in review before a review session actually started working it. Shown as a median only, with its own sample count.
Tasks at reject cap	Tasks where the reject-loop round cap actually stopped further rework during the window — a real occurrence, not a prediction. It can read 0 even while reject-loop depth (below) looks high, since depth just counts bounces, not tasks that hit the limit. See How work flows for how the cap works, and Blockers and blocked tasks for what happens once it’s hit.
Review spend	The slice of model spend that ran during the review stage, with the turn, task, and session counts behind it and the share served from cache. See Understanding costs for what these terms mean.
Avg review brief size	The average size, in bytes, of the brief handed to review sessions that started in the window.

In the CLI, a figure with no data behind it shows — rather than 0, so “nothing happened” never reads as “instant.” The web app leaves that figure’s tile out entirely instead. Either way, if no reviews were entered in the window at all, the CLI prints (no data) and the web page shows an empty state with a shortcut to widen it.

Reject-loop depth

Below the headline numbers, the web page shows reject-loop depth. For every task sent back to the build stage during the window, review debt counts how many times it looped through review → code or verify → code. It then groups tasks by that count: a DEPTH column, and a TASKS column showing how many tasks hit exactly that many rounds.

This table is part of the page’s main subject. It measures the review queue’s own behaviour, like every headline figure above it.

Comparing models or stages

Review debt measures the review queue, not the agents working it. For a comparison of models or stages, open the Quality report. Its By stage and model panel counts settled stage attempts, worked out from the workflow each task actually ran — see Stage signals for what it measures. To weigh two setups against each other, use Setup comparison.

This page used to carry an older Legacy first-pass history table alongside its own figures. That table was withdrawn: it counted whole tasks rather than stage attempts, it missed any workflow without a verify stage entirely, and it took each row’s stage from a billing snapshot, so a row could disagree with the workflow the task really ran. Stage signals answers the same question without those limits.

Sample CLI output

Here is sample output, with made-up numbers. The window bounds print in your local time, even though the windows themselves are aligned to UTC days.

ch quality review-debt — window Aug 02 01:00 → Aug 10 01:00

  reviews entered:              42
  review latency (median/p90):  3h12m0s / 9h4m0s  (samples: 38)
  wait to first review session:  6m0s  (samples: 40)
  tasks at reject cap:           1
  review spend:                  $12.40  (318 turns, 37 tasks, 44 sessions, 71% cache-read)
  avg review brief size:         8214 bytes  (44 sessions)

  DEPTH  TASKS
  1      6
  2      1

What it covers

Every figure on this page covers the workspace you asked for and every workspace nested beneath it. There is no longer any exception: the one figure that used to leave child workspaces out — the legacy first-pass history — has been withdrawn.

The numbers rely on stages actually named review, code, and verify. If a workflow in your workspace uses different names for those steps, this page won’t show figures for tasks of that type — see Customising workflows to check what your workflows are actually called.

Any member of the workspace can open this page. There’s no separate role or plan requirement.

Acting on what you see

A climbing median review latency, with a low reject-loop depth, usually points at reviewer bandwidth rather than agent quality. The work is landing clean; it is just waiting. A high reject-loop depth is the opposite signal: rework is happening because the work was not right, not because nobody looked at it.

Both of those readings come from this page’s own figures. To find out which model or stage is behind a rework pattern, open the Quality report’s By stage and model panel — see Stage signals.

Reviewing an agent’s work is where you act on an individual task. This page is where you notice the pattern worth acting on.

Related guides

• Stage signals — the Quality report, including the By stage and model panel: the authoritative model and stage comparison
• Setup comparison — weigh two setups against each other
• Monitoring your agents — first-pass rate and the rest of fleet health
• Reviewing an agent’s work — inspect and act on one task’s review
• Understanding costs — what turns, tasks, sessions, and cache-read mean
• How work flows — the reject-loop round cap and stage pipeline
• Blockers and blocked tasks — what happens when the round cap is hit
• Change shape — the size/spread signal on an individual task, and the optional per-stage limit
• Composition outcomes — the sibling quality report: whether letting an agent choose a task’s workflow actually pays off