NNyquest docs

Streaming

Replies usually appear as the model generates them, so you can start reading before the answer is finished. The same response handling is shared across chat themes on desktop and phones.

Pauses and long answers

Output can arrive in bursts. Reasoning, tool work, and provider delays can create pauses before or between visible words. A pause alone does not mean the request has failed.

Ordinary chat supports longer responses with a 15-minute request deadline and a 90-second upstream idle limit. These transport limits are separate from the model's output-token limit: a model can reach its output limit sooner, even when the connection closes normally.

Scrolling up while output arrives lets you read earlier text without following every new token. Use Jump to latest when it appears to return to the newest output.

Incomplete or unavailable answers

If a response stops before completion is confirmed, chat keeps the text and images received so far. An Incomplete answer notice explains the recorded reason when available, such as an output limit, timeout, provider failure, or interrupted connection. A failed request with no answer shows Answer unavailable.

These labels describe the answer, not its billing outcome. Partial output can still incur charges, and a settled charge does not prove that an answer finished.

Older saved responses may not have completion metadata. Their stored text alone does not establish whether generation completed.

Reload the saved answer

For a saved conversation, Reload saved answer appears on an incomplete or failed response when the app has an identifier for it.

  1. Keep the partial output already shown.
  2. Choose Reload saved answer to check the matching stored response.
  3. Review its recorded status and check Usage before deciding whether another model request is needed.

Reload reads the saved result without sending another generation request. It does not continue the answer or guarantee that more text is available. If the result has not been saved yet, wait briefly and reload again. A failed reload keeps the output already displayed.

Sending the same prompt again is a new request and can generate another charge. Avoid using a new generation to check whether an earlier one succeeded.

Splicer runs

Splicer has its own Finish with available answers, Stop run…, and Reload saved run controls. Complete and partial participant answers remain separately readable even when synthesis does not finish. See Multi-Model Splicer for those controls and billing states.

How the stream is delivered

Chat submits POST /v1/chat/completions with stream: true and reads Server-Sent Events over HTTPS. The app appends response content as events arrive and records completion separately from the visible text. Providers can send chunks rather than individual words; very short replies can finish before streaming is noticeable.

Where to next