SideNote ProStreaming responses you can stop, continue, regenerate and edit
A conversation is not a slot machine. When an answer starts going the wrong way you should be able to stop it, when it stops short you should be able to continue it, and when your question was the problem you should be able to fix the question.
How responses are rendered
Responses stream in as they arrive and render a focused Markdown subset, chosen so that the formatting models actually use comes out right rather than trying to cover every extension.
| Element | Notes |
|---|---|
| Headings | Levels 1 through 3 |
| Paragraphs, bold, italic | Standard emphasis |
| Inline code | Monospaced, inline with the text |
| Fenced code blocks | With language labels, horizontally scrollable and selectable |
| Ordered and unordered lists | Nested content renders as written |
| Block quotes | Standard quoting |
| Pipe tables | GitHub-style, selectable cells, horizontal scrolling |
This is deliberately a subset, not full CommonMark. Embedded HTML is not rendered, and GitHub extensions beyond pipe tables are not implemented. PDF export follows the same subset, so what you see is what you get on paper.
All response text is selectable. Code blocks and wide tables scroll horizontally inside themselves rather than stretching the window. On a wide window the conversation stays in a centred reading column instead of running edge to edge, because a 1,600 pixel line of prose is unreadable no matter how much screen you have.
Copying
- Copy the whole message, user or assistant, from its copy action.
- Copy just the code, from a fenced code block's own copy action. This is the one you use most, and having it separate means you are not stripping prose out of a paste every time.
A successful copy briefly changes the icon and tooltip to confirm it worked, so you are not left guessing whether the click registered.
Controlling a response in flight and after
- StopThe send button becomes a stop button while a request is running. Stopping keeps what has arrived so far as a partial response rather than discarding it.
- ContinueA partial response can be continued, picking up from where it stopped. Useful when a long answer was cut short, and when you stopped it early to check the direction was right.
- RegenerateThe latest assistant response can be regenerated. The same question, another attempt, which is often the fastest fix when an answer is merely unlucky rather than wrong.
- Edit and resendA user message can be edited and resent. Later messages in that branch are replaced, after a confirmation, so the thread stays coherent rather than accumulating contradictory turns.
Edit and resend is the underrated one. When an answer misses, the cause is usually a question that left something out. Editing the original question is both cheaper and more effective than arguing with the answer across three more turns, and it keeps the thread short enough to stay inside the context budget.
When the network misbehaves
Requests run under a two-minute timeout. Transient network failures, HTTP 429 rate-limit responses and server-side 5xx responses are retried up to three total attempts with short incremental delays, so a single blip does not cost you a request you have to reconstruct.
Provider errors are translated into readable messages rather than raw exception text. Rejected credentials, rate limits, invalid requests, timeouts and unreachable endpoints each say what they are, which is usually enough to tell you whether the problem is your key, your quota or your base URL. See troubleshooting when it is not.