Desk log: first token arrived, answer still running

The desk clock starts when the prompt leaves

A user submits a question. The screen stays blank. After a pause, words begin appearing, and the wait suddenly feels different. The answer is not finished, but the user can see that something is happening.

That change is the practical value of streaming. Instead of holding the entire answer until it is complete, an application receives and displays pieces as they arrive. Streaming can make a conversation feel more responsive without making the underlying model finish any sooner.

For the duty desk, this means one stopwatch is not enough. We need to distinguish the wait before useful text appears from the wait until the whole answer is ready.

The first-token clock measures only the opening wait

Time to first token, often shortened to TTFT, describes the delay before a model starts returning output. A token is a small unit of text, sometimes a word and sometimes only part of one. Streaming events may contain several tokens, so a network chunk is not necessarily a single token.

The exact measurement boundary matters. A provider may measure from when its server receives a request. Your application may measure from when it sends the request. The person at the keyboard experiences everything from clicking Send to seeing readable text.

Those clocks can disagree without any of them being broken. Network travel, relay processing, rendering, and buffering can sit between the model and the screen. For a user-facing dashboard, label the metric clearly: time from submission to first visible text is often the most useful starting point.

A quick opening does not promise a quick finish

Imagine two answers. One starts almost immediately, then arrives in slow bursts. The other takes longer to start but completes smoothly. The first may feel better for a moment, while the second may deliver a usable result sooner.

Track these separate observations rather than collapsing them into a single speed score:

• Record how long the user waits before the first readable content appears.
• Record whether delivery continues steadily or pauses after the opening words.
• Record how long the complete answer takes to arrive.
• Record whether the answer finishes successfully or stops with an error.

For a short factual reply, completion time may dominate. For a long explanation, an early useful paragraph can let someone begin reading while the rest arrives.

A quiet stream can still hide active work

Before text appears, a service may be handling a queue, processing a long prompt, or doing internal computation. A tool-using workflow may also need to fetch information or execute an action before producing an answer.

Meanwhile, receiving an HTTP response or an initial stream event does not necessarily mean readable text has arrived. Some events carry metadata or tool-call information. Measure the first content your interface actually displays, not merely the first byte on the connection.

If output appears all at once despite streaming being enabled, inspect the path. A proxy, server framework, or client can buffer chunks. Test the raw stream and the rendered interface separately before blaming the model.

The next shift needs comparable test conditions

Keep the prompt, output instructions, and measurement boundaries consistent when testing. Record the selected model and repeat the test; one request is only one observation. If you try Claude Haiku 4.5 and Gemini 2.5 Flash, do not assume either will always start faster. Prompt size, service conditions, and routing can change the result.

Relay365 fits when you want a pay-as-you-go relay desk for multiple model families through a shared integration. It works with Claude Code, Codex, Gemini CLI, and OpenAI SDK clients. The API base is https://api.api365relay.com; OpenAI clients add /v1. A shared endpoint is convenient, but it does not guarantee identical streaming behavior across models.

If that setup suits your workflow, create a Relay365 account and test a representative prompt with streaming enabled. Keep the first-visible-text clock and the completion clock side by side. The shift note should say when useful output appeared, whether it kept moving, and whether the answer finished—not merely that streaming was switched on.