The cost of a second attempt.

A retry can turn a temporary failure into a completed request. It can also add latency, consume capacity and incur another charge. Good observability keeps the recovery and its consequences visible.

Count attempts and outcomes separately

One successful user request may contain more than one provider call. A request success rate and an attempt failure rate therefore describe different things. Preserve both concepts instead of assigning every attempt the final request outcome.

Set a budget for recovery

Decide which errors are retryable and place bounds on attempts and elapsed time. Use the provider's guidance for backoff and rate limits. Retrying indefinitely can worsen an overloaded system and produce a poor user experience.

Include the waiting time

A request timeline includes the first attempt, any delay and the next attempt. If waiting is part of your application's behaviour, represent it explicitly rather than making two provider spans appear adjacent when they were not.

State the pricing assumption

A failed attempt is not automatically free or billable. The outcome depends on the provider and the stage at which failure occurs. The template's retry demonstration uses an illustrative failed-attempt charge equal to one quarter of the normal model-call cost.

Consider side effects

Repeating a tool call may repeat its external effect. Design the operation and its retry policy together, and use appropriate idempotency mechanisms where the service supports them. A visual timeline can explain this decision; it cannot make the underlying operation safe on its own.