Resuming and streaming

Whether a disconnected or crashed run can be resumed (continuing the same in-progress answer) or needs a full retry (asking again) depends on exactly how the last turn ended, not on how long ago it disconnected.

Resumability rules

• A run that ended on a plain finished text answer is NOT resumable — the turn already completed.
• A run that ended mid tool-call (the model was waiting on a tool result), or on a non-assistant turn, IS resumable — the model still owes a follow-up.
• This resumability rule is applied consistently everywhere a client might ask "can I resume this" — there's no separate, looser check used just to decide whether to show a resume affordance.

(Note: This is a runtime logic guarantee. Network disconnections or host API timeouts behave according to the host platform's infrastructure, but the engine's assessment of whether a given checkpoint is continuable remains absolute.)

What you see in traces

The execution's status field tells you whether a run is still running, awaiting approval, or in a terminal state — a client-side stream disconnect does not by itself change this status.

Authoring implications

If your integration surfaces a Resume vs. Retry choice after a disconnect, base it on the execution's actual terminal or tool-call state, not on elapsed time or client-side guesswork.