Problem
An answer stops partway through, and people cannot tell whether it is still loading or has failed.
Solution
Keep the text that arrived and label the answer as incomplete. Explain the failure in plain language and offer an action that fits the cause.
For a temporary connection problem, offer Retry. Say whether it starts the answer again. For a usage limit, show when access returns or what alternatives remain. Do not send people into a retry loop for a request the assistant has refused.
Detect stalled responses so loading indicators do not run indefinitely. Distinguish an error from a response the person chose to stop. Preserve the incomplete status when the conversation is reused or exported.
Use when
An answer can fail before it finishes, especially when text appears as it is generated.
Don’t use when
The system declined rather than failed. A decline is a refusal, and dressing a policy decision up as a technical fault sends people to retry when they should be rephrasing.
Trade-offs
Partial text can still be useful, but readers may mistake it for a complete answer. Automatic retries can hide brief failures and consume additional usage. Error details should explain the next step without exposing private system information.
Checklist
- Does the partial response survive the failure?
- Is the turn marked incomplete, and does that mark travel with the text?
- Are transient failures, quota exhaustion, and content stops distinguished?
- Does the message say what to do next?
- Is there a timeout on the gap between deltas, or only on the request?
- Does retry regenerate from the start, and does the viewer know that?
- Is a transient failure retried once automatically before anything is shown?
- Does the model see that the previous turn failed?
- Can this state be told apart from a deliberate stop?
- What happens to a tool call that was in flight?
Compare
ChatGPT leaves the partial text in place with a retry control attached to the turn, so a failure is recoverable in one click without losing what arrived. Claude distinguishes overload from other failures explicitly, which tells the viewer whether waiting is a strategy or a waste of time. Perplexity fails earlier in the pipeline more often, at the search step rather than the generation step, so its equivalent state is about sources rather than a truncated answer. GitHub Copilot mostly fails silently and produces no suggestion at all. Invisible is right for an ambient feature. It also means a persistent outage can go unnoticed for a long time.
Related
Streaming response handles text as it arrives. Stop generation marks an intentional interruption. Refusal explains a request the assistant will not or cannot fulfill.
Usage meter handles exhausted allowances. Tool call trace shows failures in actions or lookups.