Skip to main content
An answer in Cortex Chat is not one response that appears when it is finished. It is a live sequence of small pieces: words, thinking, tool rows, citations, files and, at the end, a reason the turn stopped. You can read along, interrupt, and pick up where the answer left off. This page covers what appears while an answer is being written, how to stop and resume one, what happens when your connection drops or you go offline, and why an error can turn up part way through an answer that started normally.

​
What you see while an answer is written

While this is happening the composer reads Cortex is responding… and the send button becomes Stop responding. A tool row’s label is deliberately short and human. A long tool result is shortened for display, and the row says how much was cut. The compaction marker tells you how many earlier messages were summarised but does not show the summary itself: your original messages stay in the transcript, and the summary is what the model reads in their place. How Chat works explains when that happens.

​
Stop an answer and pick it back up

Nothing is destroyed by stopping or regenerating. Only one live answer can exist in a conversation at a time, which is why regenerating or editing during a live turn is refused with Wait until the current answer finishes. Attempting a second answer anyway raises Concurrency limit reached. Continue is only ever offered on an answer that stopped. On anything else it answers That answer cannot be continued., and regenerating is the right move instead. Conversations covers versions and branches in full.

​
Steer or queue while it writes

You do not have to wait in silence for a long answer.
  • Steer this reply sends a correction into the answer that is being written. The placeholder says what it is for: Steer while Cortex is still writing…
  • Queue a follow-up… parks your next message instead. It shows as a Queued follow-up chip and is sent when the current answer finishes.
A queued follow-up can be taken back with Return queued follow-up to the composer. Only the owner of the conversation can do that, and anyone else gets Only the owner can return this follow-up.

​
When the connection drops

The answer is produced on Cortex’s side and buffered as it is created, before any of it reaches your browser. Your browser keeps track of how much it has received. If the connection drops it reconnects, says where it stopped, and the rest is replayed to it. What you see is Reconnecting, gaining an attempt number from the second try onwards, together with The answer picks up where it stopped. Then the words carry on from where they were, rather than starting over.
Reloading the page during an answer does not lose it. The work continues on Cortex’s side, so a reload shows the answer still being written, or finished. Do not resend the same message to recover an answer in progress, because that starts a second turn.
The resumable window is generous but not endless. Once a turn’s buffer is gone, Chat says This stream is no longer resumable. Reload the conversation. Reloading then shows the finished answer if the turn completed on its own. That state is reported as Gone.

​
When you are offline

Losing the network before you send is handled separately from losing it during an answer. The composer switches to You are offline — your message will wait here and holds your text. A toast confirms Sending when back online, and the message goes out when the connection returns. One thing to watch: the wait is tied to the chat you are in. If you navigate away with a message still waiting, it is dropped, and you are told rather than left to wonder: A waiting message was discarded because you left this chat.

​
Tool rows and the round budget

A turn can pass through the tool phase more than once. The model asks for a tool, Cortex runs it, the result enters the transcript, and the model keeps writing. That loop is bounded, which is why a turn that uses tools looks unfinished for longer than one that does not. None of these ends the turn silently. When the round budget runs out the model is asked to answer with what it already has, or to say how it would like to proceed. When the same call repeats without getting anywhere, the loop is broken with The same tool call repeated without progress. Try a different action., and rephrasing the request is usually the fix.

​
Why an error can appear inside a good answer

By the time something fails, the response has usually already started. The failure therefore arrives as part of the answer rather than as a refusal before it, which is why an answer can begin normally and then show an error card part way down. The card carries a code, and every code has a page under Problems. If a turn fails after your allowance was charged, the allowance comes back and you see Generation failed. Your allowance for this message has been returned. A turn that was cut short instead reports The action was interrupted., and Continue or Regenerate takes it from there.