The run log

Everything a run did is written to one log. Not a summary here and the detail somewhere else: one append-only record, where each fact is written by the same database transaction that earned it. A row is never edited afterwards, and nothing compacts or trims the store. The model's context window gets bounded on its way to the model. What we keep does not shrink.

You read that one record two ways. The timeline is the run as it happened. The transcript is the conversation the model saw. Same rows, different question.

The timeline

The timeline sits on the run screen and is always open. It starts with the trigger that fired the run and ends with how the run settled. Every line is clickable, and a click opens the line onto whatever it actually carries.

What you will see in it:

• Triggered by. The source that started the run, with a preview of the text the trigger carried.
• Thinking. The model is working on a turn.
• Reasoning. The model's own summary of what it was working out. This is the summary the model produces, because raw chain of thought does not exist on the wire. What there is, is what we show.
• Tool calls. One line per call: the tool name, a preview, and how long it took. Open the line and you get the arguments and the result verbatim, at full length, not the preview. This is the audit record, and it is on the same row as the duration, because "how long did that take and what did it return" is one question.
• Messages. What the agent said, rendered exactly as it wrote it. Never reformatted as Markdown, because formatting hides characters on a surface whose whole job is showing you the truth.
• Handoffs, when one agent passes to another.
• Gates and approvals. See below.
• How it ended. Completed, failed (with the reason), rejected, or cancelled with the note you typed when you stopped it.

Click any row and a panel opens beside the timeline with that row's raw payload, in full. One click target, two depths.

Codified runs group by step

On a run the codified workflow executed, the rows nest under the step that produced them. A step heading carries its name, its kind, a status dot, and how long it took. A retried step shows an attempt chip, and every attempt keeps its own heading rather than overwriting the one before it. Open a heading and you get that attempt's input, output and error.

The step heading carries a preview. The step's full input and output live in the run's step record, which the console reads separately and which you can also fetch over the API. Step payloads run to megabytes routinely, so the timeline points at them instead of copying them.

Gates appear in the timeline while you are still deciding

A gate that has been presented and not yet answered is promoted to an amber card in the timeline that reads Waiting on your approval, with the exact values the approver is being shown, spelled out in place. You do not have to click anything to find out what the run is waiting for.

Once you decide, the timeline gains a line saying who approved or rejected it. An approval opens onto the values that were actually approved, including any edits you made. A rejection opens onto the reason you gave. Deciding happens in the Inbox, not on the run screen: see Approvals and gates.

The transcript

The transcript is a separate section on the run screen, collapsed by default on codified runs and open by default on agentic ones. It is every turn, tool call and result the model actually saw, verbatim and in order, with nothing reshaped. Each line expands onto the raw item.

Two things about it are worth knowing:

• A transcript can outlive its run. When a trigger carries a session key, one conversation continues across several runs. The transcript then shows that whole conversation, because the whole conversation is the context this run's model was given. The section says shared conversation when that is what you are looking at.
• A long transcript is read from the end. You get the most recent items and a line saying so. The stored record is complete; the page just does not load all of it at once.

Credentials never enter the record

Secrets are removed on the way in, not on the way out, so no store ever holds one. That happens two ways, because a secret can arrive two ways.

A tool whose whole job is handling a credential keeps its name and its call identity in the record and loses its arguments; those lines show a redacted chip. Separately, every credential value granted to the run is stripped out of anything written down, wherever it appears, including a tool result that hands one back under no name a list could match. Which credentials a run had access to stays visible. The values do not.

Honest gaps

• Hosted tools report no duration. Web search, file search, the code interpreter and image generation do not fire timing hooks, so their rows appear with what they did and no elapsed time. We would rather show a blank than a number we made up.
• A tool that raised may never show a completion. The started line stays, and nothing invents an end for it.
• Not every run has a transcript. A codified run whose overwatching agent never needed to engage has nothing to show there, and the section says so rather than pretending the conversation is missing.

Reading a run outside the console

Every run surface is a read on the same API you can call yourself, with your API key or your session: