Receipts and activity#
A receipt is the durable record of a run: which tools were called, with what inputs, and what each returned. The activity view is where you read them.
What is this for?#
An agent's summary of its own work is a claim. The receipt is the record you can check that claim against — including which model actually answered, and what it cost.
How do I use it?#
Open a turn's activity to see, for that turn:
| What you see | Meaning |
|---|---|
tool calls (input and result) | Every action that ran, in order |
| Model identity | Which model actually answered — the lane and model that served the turn, not merely what you selected. A pinned model that could not run says so; no other model silently substitutes. |
| Cost | What the turn spent — per-call cost against your caps, and where applicable the pricing basis. A refusal before the provider was contacted costs nothing and says so. |
| Fault records | The typed failures the turn hit, with their stable codes |
| Payment receipts | For wallet actions: the proposal, its approval, and what was actually sent |
What permission or connection does it require?#
None — receipts are local records, stored with the workspace, on your machine.
What can go wrong?#
- A missing or garbled record fails its consistency check and the answer is marked unverified (
evidence_corruption) rather than silently trusted. - A turn that failed carries its fault code — in the activity view and in any bug report you export. The code says what happened, what may already have happened, and what to do next.
- Cost figures reflect what the runtime measured. Where a paid result never arrived, the outcome is marked unknown — never rewritten into "nothing was charged".
What do I do next?#
Read the receipt before trusting a result; look up any code in the Error Book. To report a problem, the bug reporter attaches the typed fault codes (and nothing else from the record) — see Bug reporting and privacy.