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.

Provider TraceI
Per-provider trace
A
Anthropic
Claude Sonnet 4.6
streaming · usage pending
streaming
queued
O
OpenAI
GPT-4o
streaming · usage pending
streaming
TTFT 210ms
G
Gemini
Gemini 2.5 Pro
streaming · usage pending
streaming
Apple Intelligence
Apple System Language Model
streaming · usage pending
streaming
TTFT 95ms
Inspector while a fan-out is in flight

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.

Provider TraceI
Consensus reached
4/4 providers · 1240ms · 100% agreement
Σ $0.0104
Per-provider trace
A
Anthropic
Claude Sonnet 4.6
✓ 1240ms
First tok
280ms
Total
1240ms
In / Out
847 / 412
Cost
$0.0024
O
OpenAI
GPT-4o
✓ 1100ms
First tok
210ms
Total
1100ms
In / Out
847 / 489
Cost
$0.0031
G
Gemini
Gemini 2.5 Pro
✓ 860ms
First tok
330ms
Total
860ms
In / Out
847 / 376
Cost
$0.0008
Apple Intelligence
Apple System Language Model
✓ 420ms
First tok
95ms
Total
420ms
In / Out
847 / 312
Cost
Free
Inspector after a four-peer fan-out finishes

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, 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.