A reasoning model thinks 11 seconds before the first word — what should the UI show?

## The problem this creates Extended-thinking models spend real time reasoning before emitting an answer token. As of mid-2026 that phase routinely runs for seconds and, at high effort settings on the largest models, for tens of seconds. From the client's point of view the request has been accepted, the stream is open, and nothing readable is arriving. Users interpret that exactly as an application hang: they reload, they resubmit, or they leave. A reload is the worst outcome available — the original generation usually keeps running and gets billed, and the user now waits a second full cycle. So the design problem is not "make the model faster". It is: the first answer token cannot move, therefore move the first *visible* token. ## Fill the gap with real signal A spinner conveys only "something is happening", which is precisely the claim the user has stopped believing after five seconds. The strong option is to show the model's own progress. Providers typically expose the reasoning phase as a stream of summarized thinking, and rendering those summaries as short status lines gives the user genuine, changing evidence that work is progressing — and it usually tells them something useful about how the request was understood, which is a chance to cancel early if the model has misread the task. Where no thinking stream is available, the next-best signals are honest and structural: name the phase ("reading the attached documents"), show elapsed time, or show progress through pipeline stages your harness actually knows about. Any of these beats an animation with no information content. ## Present it as provisional, not as the answer The thinking stream must be visually and semantically separate from the answer. It is exploratory: the model may consider an approach and reject it, and a summary line can contradict what the final answer says. If a user reads it as a claim, you have shipped a correctness bug through the UI. Practical rules that hold up in review: put it in a distinct, muted region; collapse or replace it once the answer begins, so the finished output does not carry rejected reasoning next to it; do not let it be copied or exported as part of the answer; and label it clearly as a summary of the model's process rather than as verbatim internal state. ## Keep the exit available A long wait is the moment users most want a way out, so the cancel control has to be present and obvious throughout the thinking phase — not appearing only once tokens start. Cancelling must actually propagate so generation stops rather than continuing invisibly. This pairs with the thinking summary: because the user can see what the model has understood, they can make an informed decision to stop within the first few seconds instead of waiting out a wrong answer. ## Distinguish thinking from stalled Long thinking and a broken stream look identical from the outside. Run a watchdog on the client: if no event of any kind has arrived for some threshold, change the message — acknowledge the delay, keep the elapsed timer running, and offer retry alongside cancel. If your transport sends periodic keep-alive events, absence of those is a stronger stall signal than absence of content. The important part is that the interface never sits unchanged for a long period, because an unchanging interface is how users conclude a system is dead. ## What not to do Do not fabricate progress. A progress bar timed to a historical average is a lie that breaks the moment a request runs long, and users who catch it stop trusting every indicator you show. Do not silently buffer the whole answer so it appears "all at once, quickly" — you have then given up the streaming benefit entirely and made the blank period longer. Do not report your latency as time to first byte and declare the problem solved: the byte arrived, the user saw nothing, and only a client-measured time to first *visible* token reflects what actually happened. ## The judgment call There is a real product tradeoff underneath: heavier reasoning buys better answers and costs perceived responsiveness. The UI techniques above buy you room to spend that time, but they do not make it free — a user staring at a status line for forty seconds is still waiting. Deciding how much thinking a given request class should get is a separate lever, and the honest framing in an interview is that the interface can make a long wait tolerable and legible, not that it can make it invisible.