What you’ll see
As an answer streams, updates arrive in a natural order:The answer
Final answer content when it is ready. The main runtime normally sends one complete response, while clients remain compatible with partial response events.
Developer clients should treat a
final_response with isComplete: true as the canonical complete answer. If partial final_response events arrive, accumulate their content until the complete event replaces it.One active stream per chat
A chat has one active stream at a time. Starting a new message on the same chat replaces any answer that’s still in progress — so a chat always reflects the latest question you asked, and there’s never more than one response competing for the same conversation.Stopping and reconnecting
You can stop a streaming answer at any time. Whatever was generated up to that point is saved to the chat, so you keep the partial answer and can pick up from there. The same holds if a client disconnects mid-answer — say you close the tab or lose your connection. The response stops and everything generated so far is saved to the chat. Nothing is lost: reopen the chat to see the partial answer, then continue with a new message.Because partial answers are always saved, a dropped connection never loses your progress. Reopen the chat to review what was generated, then send a follow-up to carry on.
For developers
Building your own streaming UI or integration? The developer guide documents the full event format — the exact event types and payloads — and how to consume them.Chat & streaming guide
The event stream format and how to handle it in your own client.
Next steps
Chat overview
How grounded, cited answers come together.
Quick vs Deep modes
Choose how deeply each message is answered.
Long conversations
How lengthy chats stay fast and coherent.
Chat & streaming guide
Consume the event stream in your own product.