Server-side tools like web search can run past a single turn. The API returns stop_reason "pause_turn" to say the turn is unfinished, not failed. Build a client that resumes it, and prove to yourself the difference between resuming and starting over.
What to build
- Enable a server-side tool (web search) and send a query broad enough to take multiple rounds.
- Detect stop_reason "pause_turn" specifically — not as a fallback in an else branch.
- Resume by sending the paused response's content back unmodified as the next assistant turn.
- Continue until stop_reason becomes "end_turn".
- Instrument the loop: count resumptions and total tokens per resumption.
Done when
- pause_turn is handled as its own branch alongside tool_use and end_turn.
- The paused content is echoed back verbatim — nothing is regenerated or summarised.
- The run completes without ever re-issuing the original user message.
- You can explain why mutating the paused content breaks resumption.
If you want to go further
- Add a resumption cap and a clean fallback message when it is exceeded.
The trap this exercise teaches
Treating pause_turn as an error and retrying from the top. That discards completed work, doubles cost, and can loop indefinitely on a slow tool.
Before you start
The theory behind this build is covered in pause_turn and server-side tools. If any step below is unfamiliar, read that first — the exercise assumes it. Primary source: Claude Docs — Tool use.
Check yourself against the exam
This exercise sits in Domain 1, which is 27% of the CCAR‑F exam. Once you have built it, run a domain drill in the study app and see whether the questions read differently.