Guides
Reading thinking and tool calls
A reply is not a paragraph. It is an ordered list of Parts — text you read, reasoning the NPC did on the way, and each Tool it called with what came back. This guide is about reading that list.
Turn thinking on
Reasoning is off by default, per NPC. Open the NPC's edit form and set Thinking to Brief, Moderate or Thorough. The form says plainly what it costs: extra tokens on every Message, and not every model supports it.
Tool calls need nothing switched on. Any Tool you have granted an NPC renders when it is used. See Adding Tools and MCP Servers.
What a reply looks like while it arrives
Three dots appear as soon as you send, and stop the moment anything at all shows up — including a reasoning Part, which is often what arrives first.
From there, Parts render in the order the Provider produced them. An NPC that thought, called a Tool, then thought again reads that way. Nothing is reordered, and nothing is held back until the reply is finished.
Reasoning
Reasoning renders as a collapsed disclosure with a brain icon, visibly separate from the answer. Its summary line reads Thinking… while it is still arriving and Thought before answering once it has settled. Open it to read the reasoning; leave it shut and the answer reads as one clean piece of prose.
It is a native disclosure, so it opens with the keyboard and is announced as expandable.
Reasoning is never part of a Message's flattened text. Copying a reply, or a Conversation title generated from one, contains the answer and not the reasoning behind it.
Tool calls
Each Tool call is its own disclosure with a wrench icon, and the summary line is the Tool's name. Open it and you get:
- Input — the arguments the NPC sent
- Result — what came back
Payloads are pretty-printed, and one that is already a string — a command's output, a stack trace — is shown as itself rather than as a quoted JSON scalar. Long payloads scroll inside the disclosure rather than pushing the Conversation around.
A call that is still running
While a call is in flight the summary reads tool_name — running, and opening
it shows the Input and the line Waiting for a result…. A slow Tool looks slow
rather than looking like a stalled reply.
A call that failed
A failed call is still there. The summary reads tool_name — failed, the
wrench turns red, and the payload is labelled Error instead of Result.
Nothing vanishes: a Tool that could not do its job is exactly the Part you need
when the answer is wrong.
Stopping, failing, and retrying
Stop a reply mid-flight and everything that had already arrived is kept. A Stopped marker appears under the Message, with a Retry button.
A reply that fails outright keeps its Parts and adds a second bubble carrying the error, again with Retry. The error stays next to the Message it belongs to rather than disappearing as a notification.
Reloading
Reload the page and the Conversation renders exactly as it streamed — same Parts, same order, same open-and-shut disclosures. The Parts are stored on the Message and rebuilt by the same fold that produced them live, which is what makes the two identical rather than merely similar.
Messages written before Parts existed have no Parts stored. They still render, as plain text.
Limits worth knowing
A single turn is bounded at twelve Tool steps. An NPC that keeps calling Tools without producing an answer stops there rather than running on.
Long Conversations are windowed before they are sent to the Provider, and what falls off the front is replaced by a rolling summary, so a Conversation past the model's context window keeps working. See Working with Memory.