stella inspect
Show the exact context a past model call was sent, rebuilt from recorded receipts and verified against the digests taken at emission.
Answer "what did the model actually see?" for any past call. stella inspect rebuilds the exact message array a model was sent — system prompt included — from the receipts recorded at the time, and re-checks it against the digests taken at emission. Entirely local; no API key, no network, and it never writes.
Synopsis
stella inspect # executions that have receipts
stella inspect <EXEC> # that execution's model calls
stella inspect <EXEC> --step <N> [--turn <T>] [--call-seq <S>]What it does
Every model call records a receipt: the ordered list of context blocks it sent, plus the bytes of the blocks the event journal cannot otherwise resolve (the system prefix and the assembled user/recall message). stella inspect replays that receipt against the journal to reconstruct the call's Vec<CompletionMessage>.
It reads <workspace>/.stella/private/store.db only. Like stella stats, it refuses to create .stella/ as a side effect of being asked a question — if there's no store yet, it says so.
Flags
| Flag | Meaning |
|---|---|
--turn <T> | Turn instance within the execution. Default 0. |
--step <N> | Step to reconstruct. Omit to list the execution's calls instead. |
--call-seq <S> | Which model call at that step. Default 0. |
--format <text|json> | text (default) prints a role-delimited transcript; json gives the messages plus the verification verdict. |
--full | Print message bodies in full instead of eliding long ones. |
Why --call-seq exists
A single step can involve more than one model call. The engine's own worker call is always 0; the overflow summarizer that may run during that step's compaction is 1; the pipeline's management roles (triage, judge, plan, guidance, conversational) allocate 2 and up.
These auxiliary calls assemble their own prompts — a role task prompt, an optional settings-supplied system override, and a rendered transcript that exists nowhere else — so their receipt is the only record of what they sent. stella inspect <EXEC> lists every recorded call with its role, so you rarely have to guess a sequence number.
Reading the verification banner
execution 42 · turn 0 · step 3 · call-seq 0
7 message(s)
verified: every journal-resolved block re-hashed to its recorded digestTwo failure modes are reported separately, because they mean very different things:
| Line | Meaning |
|---|---|
! N block(s) could not be resolved | A documented coverage gap — budget-abort synthetic tool results, discarded speculation, or attachments. The rest of the transcript is still faithful. |
!! N block(s) did NOT re-hash to their recorded digest | The journal is torn or was altered. Treat the reconstruction as untrustworthy. |
The system prefix and the assembled user message are stored as local bytes rather than resolved from the journal, so their digest check is tautological and is deliberately not counted as evidence. The proof lives in the journal-resolved kinds.
What it can't show you
- Executions from before the receipts plane landed. They have no receipt rows and are omitted from the index rather than listed as empty.
- The literal wire bytes. Receipts are taken before the provider adapter runs, and adapters transform the system block on the way out — Anthropic keeps only the last system message and inserts cache breakpoints, OpenAI and Gemini join system messages with
\n\n. A receipt is the canonical pre-adapter view of the call. - Tool JSON schemas. The manifest records the messages, not the tool definitions sent alongside them.
Receipts never leave your machine. The content-free export boundary (stella-store's egress guard) strips prompts, paths, and tool payloads from anything replicated off-box, and is enforced by a compile-time column allowlist plus a sentinel-poisoning test. See Telemetry.