Streaming Text Shim

Why animate streaming text at all?

There's a moment in every recording session — somewhere between the third and seventh take — when the performer stops thinking about the take and starts thinking about the song. The takes before that point are technically fine; the takes after are the ones you keep. Streaming reveal animations work on a similar threshold. Done badly, they make the reader self-conscious about waiting. Done well, they disappear into the rhythm of reading.

Plain instant-paste rendering looks impatient. It suggests the answer was always there, waiting, and that the model is hiding it. A small, well-tuned animation acknowledges that the words are arriving in real time, and gives the reader something coherent to track instead of a blinking cursor. The trap is dressing it up — big bouncy entrances, color flashes, character-level confetti. Those read as toy interfaces, and they slow comprehension. The default should be near-invisible: a gentle opacity rise or a brief blur fade, calibrated to disappear inside the first 200 milliseconds.

A new unit mounts every 60ms and animates over 400ms. Units overlap — the response feels continuous rather than stepped.

animating

settled

gap between starts = unitDelayMs (60ms)

Current settings

<StreamingText
  text={response}
  unitMode="token"
  unitDelayMs={60}
  transitionDurationMs={400}
  easingPower={3}
  loop
  loopPauseMs={1200}
  blurEnabled
  blurAmount={6}
  opacityEnabled
/>