The inspector

Every fan-out leaves a receipt. Each peer’s tokens, dollars, latency, and raw text are written into the per-exchange trace at finalize time, and the inspector is the surface that lets you read them. The inspector is where you go to answer “why did this turn cost what it cost,” “which peer wrote the words I’m reading,” and “what did the others say that didn’t make it in.” It is the audit layer on top of consensus.

Opening the inspector

Press ⌘⇧I from anywhere in the chat window. The inspector slides in as a third column on the right; press the same shortcut again to dismiss it. There is also a toolbar button in the main view that does the same thing, and a “Toggle Inspector” entry in the View menu — the keyboard shortcut is what you’ll reach for most often.

The inspector is per-exchange, and it follows the newest turn on its own — the one streaming, or the last one that finished. Pivoting to an older turn takes an explicit action: View trace in that answer’s action row (alongside Copy and Regenerate) selects that exchange, opening the inspector if it was closed. Clicking a citation link in the answer text, or a provider pill in its SOURCES row, does the same and lands on that peer’s card. Plain body text is not a pivot target, though — clicking a turn at large leaves the inspector where it was. Conversations keep their traces — closing and reopening a session brings them back, and they survive a Polycode restart because they live in the same local store as the chat itself.

The consensus overview card

The top of a finished trace is the consensus overview card — a Polycode halo, a “Consensus reached” label, and two mono caption lines:

4/4 answered · 1240ms
1 split · 1 solo · Σ $0.0104

The first line is attendance: how many dispatched peers returned a successful response, and the total fan-out time — the slowest peer’s latency, since fan-out is parallel and the round ends when the last peer settles.

The second line is what the panel did. 1 split · 1 solo counts the claims in the answer the panel diverged on and the claims only one side spoke to (No splits when there were none of either). Σ $0.0104 is the aggregate for the whole exchange, folding in every peer plus the synthesis lane, and every round when a debate ran; · N unpriced is appended when some models carry no listed pricing.

The agreement bar

Beneath the captions is a three-segment bar, and beneath that its legend:

50% uncontested · 25% split · 25% solo   ⓘ

This measures agreement, not attendance — the two are different numbers and the card shows both. Each sentence or list item of the synthesized answer is classified from its own citations: uncontested where the answer cites nobody, split where it cites two or more sides, solo where it cites one. The ⓘ states the rule in the app:

Uncontested sentences carry no citation, because synthesis never cites universal agreement. A split cites two or more sides. A solo cites one side.

The segments read left to right in that order. A sentence that only acknowledges an unavailable provider (“Gemini timed out before returning”) is a status note and is left out of the percentages entirely, so a provider failing never inflates the agreement figure.

Fan-out and consensus walks through the rule and its limits; disagreement and adoption covers what you can do with a split once you’ve found one.

While a fan-out is still running there is no consensus card at all — the top of the trace is the live primary-lane card, whose status chip walks through queued, TTFT Nms, synthesizing…, and ready as the round progresses. The consensus card appears once the whole exchange finalizes.

Per-provider trace cards

Below the header, one trace card per peer. Each card carries the provider logo, the model name, and a tiny chip on the right summarizing status and latency.

The primary peer — the one whose synthesis you’re reading in the chat — is marked with a crown and a heavier border. That visual cue answers “whose words am I actually reading” without needing to cross-reference the synthesis prompt or the provider list.

The 4-stat grid

Each finalized trace card carries a 2×2 stat grid:

• First tok — how long until this peer started streaming. The live-feel number. Captured from the first .textDelta chunk the peer emitted; held in a lock-protected per-peer store and stamped onto the response at finalize time.
• Total — how long until this peer finished. The wallclock latency.
• In / Out — token counts as reported by the provider.
• Cost — dollars for this peer’s call, computed at exchange time from the model’s listed pricing × the tokens used. The figure is locked in when the exchange runs; later pricing changes don’t retroactively rewrite it. A model with no listed pricing renders —; an on-device model renders Free.

Cells render as monospaced numbers so trace cards line up cleanly when you’re comparing two peers side by side. A peer that never streamed (timeout, cancel, no chunks) renders First tok as — — graceful degradation for the cases where a real value doesn’t exist.

Drilling into one peer

Each card carries a Full response disclosure — click it to read that peer’s complete text. A peer that called a tool gets a second, independent TOOLS (N) disclosure below the body: it’s on the card whether or not the text is expanded, it opens and closes on its own, and it auto-opens when a call failed (its header then appends · N failed). The crown on the primary’s card marks which peer’s words ended up in the synthesized reply, so “whose answer am I reading” is answerable from the trace alone.

If two peers disagreed, you no longer have to find that by expanding cards and comparing prose. A Where the panel split section sits between the overview card and the trace stack, with a card per contested claim naming the sides and quoting each one — and hovering a finished card reveals Copy, Diff vs answer, and Use as answer. All of that is covered in disagreement and adoption. The full response well remains the place to read a peer’s argument unmediated and at length.

Roles and rounds

Two things a mode can change show up on the trace cards.

A Critic is labelled. A mode can give any panel member the Critic role, which asks it to argue the strongest case against the likely consensus and name failure modes while still giving a complete answer. Its trace card — and its side of any split card — carries a Critic chip, so an outlying reply reads as the role doing its job rather than as a provider being wrong. The primary is always a Panelist and never carries a chip.

A debate round is disclosed. With Rounds set to Debate, every peer runs twice: it sees the other peers’ first drafts (labelled Draft A, Draft B, … with no provider names attached) and revises once before synthesis. On a finished debate exchange each card’s final is its round-2 reply, and the superseded draft sits under a Round 1 draft disclosure with its own latency, tokens, and cost.

Every round is a billed call, so both rounds count toward the aggregate Σ and toward Settings → Usage. That is why a debate exchange costs roughly twice a single pass, and why its Σ is not the sum of the visible finals.

While the extra round is in flight the overview card says so — the title becomes Debate in progress and the caption reads Debate round · N revising in place of the attendance line, with no counts and no bar, because no finalized rows exist yet.

Tool calls live in the trace

When a peer calls a tool — a built-in file tool or an MCP tool — the call shows up inline on that peer’s card under the TOOLS (N) disclosure: the tool name, a best-effort target path lifted from the call’s arguments, and a single trailing status. The statuses are mutually exclusive, not stacked. A call that ran shows its latency (412ms); a repeat call served from the answer’s execution cache shows cached instead — the work ran once, and this row joined the shared result. A call that errored shows failed (412ms) (or failed · cached). A call that never produced a result shows pending, running, or — if you denied it — rejected, with no latency. The tools and approvals article covers the approval model end-to-end; this section here just notes that the audit trail lives in the inspector, attributed per peer, so “which peer called what tool, and how did that call end” is a single click away.

Per-exchange, not per-session

A common confusion: the inspector is per-turn, not per-conversation. The trace data lives on the exchange record, so an inspector pane bound to turn 3 of a conversation shows turn 3’s fan-out — point it at turn 7 and you see turn 7’s. Receipts travel with the conversation history; deleting a conversation deletes its traces.

What’s next

• Fan-out and consensus — the math behind the numbers the inspector reports.
• Disagreement and adoption — the split cards, the compare sheet, and adopting a peer’s reply as the answer.
• Tools and approvals — how tool calls show up inline in trace cards and how to manage the approvals that govern them.
• FAQ — short answers to the questions inspector traces often raise.