A housing authority casework assistant issues a request that invokes a long-running server-side tool. The response comes back with stop_reason set to pause_turn and no final answer. What does this signal, and how should the caller resume?
Select an answer to reveal the explanation.
Short Explanation
pause_turn is the model tapping the brakes on a long errand, not abandoning it. Send the paused response's content back and the same turn picks up where it left off.
Full Explanation
Long-running server-side tools cannot hold a connection open indefinitely, so the API needs a way to hand control back mid-turn without discarding progress. A housing-authority casework assistant that treats every non-final response as a failure will restart work that was merely paused, paying twice for the same lookup.
Pause_turn marks an intermediate state of a turn still in flight. The resume protocol is to include the paused response's content in the next request, which lets the model continue that same turn rather than starting over. The orchestrator's job is a loop that recognizes pause_turn, re-submits, and treats the turn as finished only on a terminal stop_reason such as end_turn.
An exhausted output budget is reported as max_tokens, and restarting from the original user message would throw away completed work. A tool failure surfaces as an error result for that tool rather than as a pause, and rewriting a server-side tool as a client-side one is an unrelated architectural change. Human approval is not part of the pause_turn contract; approval gating is an application-level control the caller adds itself, not a tool_result flag.
Exam caveat: the resume loop needs a bound—an unbounded pause_turn cycle against a misbehaving tool will spin indefinitely. Operational check: cap resume iterations per turn, log each pause_turn with elapsed time, and alert when a single casework turn exceeds the expected number of resumptions.