Review debt

Review debt tells you how the review stage is actually going for your workspace: 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. Where first-pass rate asks “did this model get it right the first time?”, review debt asks the question from the other side of the table: how is the review queue itself doing?

Where to find it

Web app: open the Dashboard, find the Tasks completed 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.

The two breakdown tables

Below the headline numbers, two tables appear — each only when it has rows to show:

First-pass rate by model and stage. The exact same breakdown ch quality first-pass-rate shows on its own — see that guide for what each column means. It’s repeated here because it’s the other half of the same story: review debt shows how the review queue is doing; first-pass rate shows how often work reaches review clean in the first place.

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, then groups tasks by that count: a DEPTH column and a TASKS column showing how many tasks hit exactly that many rounds.

Sample CLI 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)

  MODEL   STAGE   COMPLETED  FIRST-PASS  RATE
  sonnet  review  30         27          90%
  opus    review  8          8           100%

  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 — except the first-pass-rate table, which covers only the workspace you asked for and doesn’t include its children. The web page repeats this caveat in its own subtitle.

The numbers rely on stages actually named review, code, and verify. If a task type in your workspace uses different names for those steps, this page won’t show figures for tasks of that type — see Customising task types and 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, alongside a healthy first-pass rate, usually points at reviewer bandwidth rather than agent quality — the work is landing clean, it’s just waiting. A high reject-loop depth paired with a low first-pass rate for a given model or stage is the opposite signal: rework is happening because the work wasn’t right, not because nobody looked at it. Either way, 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

• 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