People can abort from early content; abort rights are streaming’s main gain

What it is

The first three propositions already name the wrong object. The person hits stop; the next two minutes of tokens are never generated, quota is unburned, the wrong draft does not keep growing. Whether streaming is worth doing hangs mainly on whether this can happen. Abort as payoff means: if an early signal cannot become a stop, the signal only makes people watch the error more anxiously to the end; if it can become a stop, streaming is what cuts the waste.

That stop exists as a control is one requirement. This entry asks whether stop is the reason streaming was built.

Why it happens

The decision space of an early signal is continue / stop / change the prompt. Of the three, stop saves the most wall-clock and quota, and depends most on process visibility. With a block arrival, people can only discard after the end; the cost is already paid. Streaming turns “pay then discard” into “see the sign, halt.” If they cannot stop, process visibility lengthens time spent with the wrong draft, and the gain is negative.

Abort is therefore not an accessory safety feature of streaming. It is the step that cashes the early signal. Without it, the signal has no product exit.

Studying it

Set generations that are judgably wrong in the front. Compare: stream with no abort, stream with abort, block arrival then discard. Dependent variables: wasted tokens / time, final length of the wrong draft, delay before changing the prompt. Independent variables: whether abort is available early, clarity of the sign.

Time and quota saved are the lead gain measures. Satisfaction cannot substitute: some people will “watch the error finish” and still rate streaming as nicer — that is waiting feel, not this gain.

Where it stops holding

When the user wants to watch the process (a worked solution), abort is not the goal and the gain sits elsewhere. When signs are unreliable and false stops cut generations that would have succeeded, net gain of abort rights falls; a buffer of “stop / wait one more sentence” is needed. If ownership of the leftover slice after abort is undefined, people hesitate to stop — the gain is eaten by a downstream ownership problem. This entry does not treat how the stop control is drawn, only whether stop is where the value sits.

Applying it

• Put abort at the same moment and in the same viewport as the early signal, so “see wrong → stop” has no gap spent hunting a control.
• Measure whether streaming is working with abort rate × mean time saved, not with “felt faster.”
• Treat drift patterns (wrong language, wrong object) as success cases: earlier stops are better, not more complete generations.
• Check: on a task that is wrong in the front, how many people stop in the first third of total duration. Almost none, and abort rights did not cash the early signal.

Related

• Same group: L3.11.1 The value of streaming is an early signal one can judge, not a shorter total duration · L3.11.3 Incomplete and complete content must be visually distinguishable · L3.11.4 Structured output passes through temporarily illegal intermediate states while streaming · L3.11.5 After abort, ownership of what was already generated must be clear: usable, redo, or void
• Nearby: L3.06 Streaming Presentation · L4.05 Interruptibility and Rollback
• Search terms: abort as payoff · early stop · cut wasted tokens