Streaming and a Better User Experience

Run your agent on a real task and you'll notice something uncomfortable: nothing happens for twenty seconds, then a wall of text appears. Was it working? Stuck? Doing something you didn't want? A silent agent feels slow even when it's fast, and it's hard to trust because you can't see what it's doing.

Streaming fixes both problems. In this lesson you'll switch your agent to the SDK's streaming API so words appear as the model writes them, and you'll surface tool activity as it happens: "fetching a page," "writing a file." You'll restructure the agent to emit a clean stream of events, then render those events two ways: in a polished terminal CLI and in a small web page. Same agent, two interfaces, no duplicated logic.

Why streaming changes how an agent feels#

Without streaming, the API holds the whole response until the model finishes, then sends it at once. With streaming, it sends small pieces as they're generated, using server-sent events (SSE), a simple standard where the server keeps an HTTP connection open and pushes messages down it.

The total time to finish barely changes. What changes is time to first feedback, which is what people actually perceive. Seeing the first words within a second or two, and seeing "● get_weather" the moment the model decides to call it, makes the agent feel responsive and, just as important, legible. Users can stop a run that's heading the wrong way instead of discovering it at the end.

For agents there's a second, practical reason. Long outputs with a high max_tokens can take minutes, and the SDKs expect you to stream requests like that rather than hold one HTTP request open for the whole generation. Streaming is the default posture for any agent.