Partial AI answers need a stability metric
In short: Progressive AI answers need a stability receipt for supported claims, reversals, citation arrival and user action before completion.
On 7 October 2026, OpenAI said GPT-6 Instant starts answering web-search questions 44% sooner on average than GPT-5.6 Instant. It can now compose one answer across multiple partial responses while thinking and tool use continue.
That changes the product metric. Time to first visible output is no longer enough; partial AI answers need a stability receipt covering the first supported claim, material reversals, citation arrival and whether the user acted before completion.
GPT-6 separates visible progress from finished evidence
OpenAI's launch account says GPT-6 can interleave thinking with answering and add useful information across partial responses. The ChatGPT release notes put the user consequence plainly: people can start reading while the model continues thinking or using tools.
The 44% figure is an OpenAI internal average for web-search questions. The public material does not publish task-level denominators, partial-to-final claim-reversal rates, citation-arrival distributions or its evaluation protocol. It is evidence of an earlier start, not independent evidence that every early claim is stable.
This October release applies to ChatGPT. OpenAI says the models powering Work and Codex did not change with it; the deployment card separately identifies the October ChatGPT models and the September versions that remain in those products.
A stability receipt measures the answer the user actually saw
My proposed receipt has four timestamps and one count:
| Field | What it captures |
|---|---|
| First visible output | When any answer becomes readable |
| First supported claim | When a citation or tool result supports a claim |
| Final completion | When thinking and tool use finish |
| First user action | When somebody copies, clicks or sends |
| Material reversals | Decision-changing changes before the final answer |
The receipt separates visible progress, evidence arrival, user behaviour and semantic change.
The reversal count should ignore harmless phrasing changes. It should catch an entity, number, recommendation or confidence statement that changes enough to alter the user's decision. That is the semantic cost hidden by a faster first response.
Citation arrival matters separately. A partial answer can state a load-bearing claim before the source card appears. If the user copies the claim during that gap, the product has created an evidence race even when the final answer is properly cited.
The acceptance test I would run on progressive answers
I have not tested the October GPT-6 release for Trigent or a client. My labelled editorial test is to replay a fixed set of search questions, capture every rendered partial state, and compare the earliest supported state with the final response.
Mark each claim as unsupported, supported, changed or withdrawn. Record interaction before completion in the test harness rather than assuming users wait. Segment results by question type and tool path; a single average can hide a category where answers start quickly but settle late.
The pass condition is not zero change. Progressive answers are allowed to improve. The product should set a limit for decision-changing reversals after the first supported claim and prevent consequential actions until the required evidence has arrived.
What's in it for you
- Optimise perceived latency without hiding semantic churn.
- Catch citations that arrive after a user could already act.
- Compare model releases on supported progress, not token theatre.
Measure when an answer becomes safe to use, not merely when it becomes visible.
