Watch & compare
Timeouts and retries
Different ways to see the same idea. Play one cut at a time, then return to the guide to try it yourself.
Why we recommend Retry budget
Start with Retry budget: its clock keeps draining through the wait and second attempt, then runtime code blocks another request and returns STATUS UNKNOWN. One retry owner makes the complementary cost of nested retries concrete by counting six downstream calls before reducing them to three. The revised original is the clearest demonstration that a service can finish after its caller times out, but it does not show an overall deadline or exhaustion.
Revised original · 21 sec
Timeout does not cancel work
A read can finish remotely after its caller times out; a bounded retry waits, then makes a new attempt.
Read the video sequence
- A normal read receives a response before the attempt timeout. The caller accepts it.
- A separate read starts at 7s. The caller waits three seconds, then times out while the service keeps working.
- During a sampled 4.5-second backoff, the service completes at 12s. Its late response arrives at 13.2s and is rejected by the expired attempt. Timeout did not cancel the work.
- The delay indicator clears and the caller uses the second and final permitted attempt. This read succeeds.
- The accepted result and two-attempt limit hold, then fade to black. This cut illustrates per-attempt waiting and late responses; it does not show an overall deadline, retry exhaustion, or fleet-level jitter.
About this cut
Production: Original prototype; model not recorded.
Revision: gpt-6-astra comparative review.
Read-only request; write safety requires documented idempotency or reconciliation.
Per-attempt timeout and a two-attempt limit are shown; operation-wide deadline and retry exhaustion are not.
One sampled delay does not demonstrate fleet-level jitter. Timing is illustrative.
Audio analysed, not physically heard.
Recommended · Astra · 26 sec
Retry budget
A retry consumes the existing tool-operation budget; when it expires, runtime code blocks further attempts and reports an unknown outcome.
Read the video sequence
- An agent asks for CI status. The runtime sends a read, receives a completed status, and returns a known result. This normal operation uses part of its own budget.
- A new logical read begins. Its twelve-second shared budget starts at 00:08. The service does not reply, and the first attempt times out after five seconds.
- The runtime waits two seconds before retrying. This is one illustrative sampled backoff; the shared budget continues shrinking from seven to five seconds.
- The runtime sends its second and final allowed attempt. The retry uses the five seconds remaining in the original budget; the timer does not reset.
- The deadline closes the runtime gate. The agent receives an unknown status. A repeated request is blocked before it reaches CI. This limits caller retries; it does not prove that remote work stopped.
About this cut
Production: gpt-6-astra.
Illustrative CI read and runtime policy; 12 seconds, two attempts, and a two-second sampled delay are not production defaults.
The runtime gate must be implemented in code; persistent prompts do not enforce budgets or permissions.
The video does not demonstrate fleet-level jitter, write idempotency, or cancellation of remote work.
Audio analysed, not physically heard; self-reviewed, with no comparative ranking.
Alternative · Sol · 32 sec
One retry owner
An agent's retry loop can multiply a tool's retries; one code-enforced policy bounds attempts and total waiting.
Read the video sequence
- A code-search request passes from the agent through a read tool to the code index. One service call succeeds and the result returns.
- The index becomes unresponsive. The agent invokes the tool twice, and the tool makes three attempts each time. Six service calls accumulate as the waits time out.
- The policy changes in the orchestration code: the agent may invoke the tool once, and the tool alone owns up to three total service attempts, including the initial call. A six-second budget appears.
- The tool makes three reads with two sampled backoff waits of 1.3 and 1.8 seconds. The same time budget drains during calls and waits. These timings illustrate one scenario, not a guarantee.
- The overall budget expires before the last call can use its full individual timeout. The tool stops at three calls and returns a failed tool result; the agent hands off without restarting the read. The index still shows Unresponsive: no result was observed, which does not establish whether remote execution stopped. The result holds, then the screen fades to black.
About this cut
Production: gpt-6.1-sol.
Revision: gpt-6-astra comparative review.
Illustrative read-only code search; timing and attempt limits are examples, not production recommendations or recovery guarantees.
The two waits show one sampled jittered-backoff sequence; many-client de-synchronization is not demonstrated.
One six-second downstream budget includes calls and backoff waits; the third attempt’s response wait ends early at that deadline. Client stopping does not cancel already running remote work.
Retry limits and permissions require harness/tool enforcement with SDK retries accounted for; persistent prompts alone do not enforce them.
Audio was analyzed for levels, cue timing and spectrum, not physically listened to; no comparative quality recommendation is claimed.
These animations use sound effects rather than narration. The written guide explains the mechanism and its limits. Model names describe how a cut was made, not a quality ranking.
What the review found
- Astra 08–20s shows a single twelve-second budget: five seconds waiting, two seconds backoff, then at most five seconds for the last attempt. Its 20–23s unknown result and blocked repeat make the runtime stopping rule more explicit than either alternative.
- Sol 05.3–16s makes two agent invocations × three tool attempts visible as six persistent call slots. At 19.1–25.1s one retry owner uses three attempts within six seconds, including two waits; the deadline cuts the third response wait short.
- Baseline 10–13.4s uniquely keeps the remote service working after local TIMEOUT, then rejects its late response. Its successful retry at 14.5–17.1s is useful contrast, but cannot substitute for Astra’s exhausted-budget ending.
- At 350px, Astra has the clearest actor/state hierarchy. Baseline’s enlarged labels now communicate the late-response mechanism, though its dispersed layout requires more eye movement; Sol’s call slots preserve the count when individual timeout labels change quickly at 06–14s.
- Baseline’s sampled backoff is now 4.5 seconds (10–14.5s), with the stale success state reset before retry and the delay indicator removed. Astra’s long countdown buys arithmetic clarity; Sol’s 26.4–29.6s final hold is readable but slightly slack.
- None of the three depicts many clients, safe write retries, or confirmed remote cancellation. Baseline 10–14.5s and Sol 20.1–24.2s illustrate sampled waits, not proof of fleet-level jitter; the guide supplies these boundaries.