A session echo is not one result line. It is one instruction, then several tool calls, then one summary. Understanding that shape is what lets you locate the failing layer.
The usual structure
- You send a sentence. The host sends it to the model with context.
- The model decides to call a tool first (say, list a directory) and returns a tool call, not an answer.
- The host runs the tool, appends the result as a new message, and calls the model again.
- The model sees the result and either calls another tool or answers.
- The final reply lands in the UI and the loop ends.
The key point: every extra tool call costs a full model round trip. So a long wait usually means many round trips, not a slow network.
Capturing it as primary material
- Copy the whole output into a text file, not just the last sentence.
- Record: start time, end time, number of tool calls, retries.
- If you rerun the same task with different wording, keep both — comparing tool-call counts beats comparing wall-clock time.
Do not judge by total duration alone. Same task, double the time, same call count means network or server variance. Call count going from two to seven means a wording problem, and fixing the wording beats changing networks.
When you need this
Three cases: proving a bug is reproducible, deciding whether a slowdown is the model or the environment, and keeping evidence that something used to work. The third is gold after an upgrade breaks your usual command.