Skip to main content
A turn is one message from you plus everything Cortex does to answer it. Inside a turn the model can call tools, and every call and its result appear in the transcript as a row, so the work is visible rather than hidden behind a spinner. The loop is bounded, and knowing those bounds explains most of what you will see in a long or complicated answer. This page is for readers who want to know what is actually happening between pressing Enter and reading an answer: what goes into a turn, in what order, what is kept afterwards, and what happens when a conversation grows too long to send.
A cited Chat answer with a footnote source panel open beside the conversation.

Interface preview

​
What goes into a turn

Once everything is assembled, Cortex clamps the answer so that the prompt and the output together fit inside the model’s context window.

​
The order of events

1

Your allowance is charged first

The message is counted against your allowance and committed before a single word is written, which is why a request that gets refused costs you nothing. If generation then fails after being charged, the allowance comes back and you see Generation failed. Your allowance for this message has been returned.
2

The message is stored and the turn starts

Your message is saved to the conversation, and the turn begins.
3

Cortex generates on its own side

The answer is produced by Cortex and buffered as it is created, before any of it reaches your browser. That is the reason a dropped connection or a page reload does not lose an answer in progress.
4

The answer arrives in pieces

Words, thinking, tool rows, citations and file cards arrive as they are ready rather than in one block. See Streaming and reconnects.
5

The turn ends for a stated reason

A turn ends because the model finished, because it hit its output ceiling, because you interrupted it, or because it failed. Each of those leaves a different card in the transcript.
Only one live answer can exist in a conversation at a time. While a turn is running, regenerating an answer or editing an earlier message is refused with Wait until the current answer finishes., because either one would put a second live answer into the same thread.

​
What you see while it runs

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 limits of one turn

None of these fail silently.
  • When the round budget runs out, the model is told the budget is exhausted and asked to answer with what it already has, or to ask you how to proceed.
  • When the same call repeats six times without getting anywhere, the loop is broken with The same tool call repeated without progress. Try a different action.
  • A message over the character ceiling is refused with The message is longer than the permitted maximum. Split it, or attach the text as a file.
Eight rounds is Chat’s own budget, chosen for a conversation. Cortex Code allows 48, because working through a repository takes more steps than answering a question. Deep Research runs its own loop with its own caps and does not spend Chat’s eight rounds.

​
When a conversation outgrows the model

A long thread eventually holds more than can be sent to the model. Rather than quietly dropping the beginning, Cortex summarises the earliest messages into a single summary and carries on. A marker appears in the transcript where that happened, saying how many earlier messages were summarised to make room. You keep seeing the original messages; the summary is what the model reads in their place. Compaction happens on whichever of these comes first, and also before a task returns a result and before a Deep Research synthesis: Some things are never summarised away: your own messages, the last question you asked, the active plan, open tasks, open files and your memory profile. Compaction fails closed, so if that set cannot be preserved, nothing is compacted at all instead of something being lost. A conversation holds one summary at a time, and a later compaction replaces the earlier one.

​
What is kept

Because message bodies are stored encrypted and never indexed, Chat search matches conversation titles rather than what was said inside them. Temporary chats are the exception to all of this: they are not listed in Recents, they neither read nor write memory, and they are deleted after 30 days.

​
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 partway down. The card carries a code, and every code has a page under Problems. If the answer stopped rather than failed, Continue picks it back up where it left off.