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 header
The top of an open trace is a consensus header — a Polycode halo, a “Consensus reached” label, and a one-line caption that reads:
4/4 providers · 1240ms · 100% agreement
The first number is successful peers / total peers dispatched. The millisecond figure is 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 percentage is a cheap proxy: the fraction of peers that returned a successful response, rendered as the agreement bar’s fill. It is not a semantic similarity score; the fan-out and consensus article walks through what it does and doesn’t measure.
Beneath the caption, an aggregate cost line sums the whole exchange — Σ $0.0104 in the trace below, folding in every peer plus the synthesis lane,
with · N unpriced appended when some models carry no listed pricing.
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
.textDeltachunk 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, expanding both is the fastest way to see why. The chat-surface synthesis will already have flagged the disagreement (per the synthesis prompt’s instruction to cite peers when they diverge), but the inspector is where you read each peer’s argument unmediated.
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.
- 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.