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. Click any turn in the chat and the inspector pivots to that turn’s trace. 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.
When a fan-out is still running, the header shows a streaming indicator instead — the consensus card is suppressed until at least one peer settles.
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.
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
Click into a card to expand it. The expanded view shows the full text of that peer’s response and — if the peer called a tool — a per-tool breakdown: which tool, a target-path summary, how long it ran, and the approval outcome. 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, with the tool name, a target-path summary, the latency, and the approval outcome. 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 was it approved” 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 — open 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.