Frame the SSE token relay experiment

Success is not “I followed the tutorial.” Success is producing evidence that: client receives ordered data events and a terminal done event; cancel stops further writes. The accepted input is narrow on purpose: upstream chunk iterator, response headers, abort signal. That narrowness is what lets you inspect every field and prevents a toy demo from being narrated as a production system.

Record the baseline you must beat: non-streaming JSON endpoint latency for the same prompt. If the finished artifact cannot beat that baseline on the fixture below, stop and revise the claim before writing more code.

export const acceptance = {
  project: "an HTTP endpoint that relays model text as Server-Sent Events while preserving cancellation and final usage",
  invariant: "every accepted stream ends exactly once as done, error, or client cancellation",
  expected: "The client renders \u201cHello \ud83d\udc4b\u201d in order, receives done once, and closes cleanly.",
} as const;

Expected evidence: The client renders “Hello 👋” in order, receives done once, and closes cleanly.. Treat the printout as a claim about this fixture, not as proof that the toolchain merely started.

For the SSE relay for model tokens, a decorative win often looks like a clean run that never checks time-to-first-byte, event count, cancel stops within N events. Write the metric down now so later pages cannot redefine success after the fact. Also note the operational threat you will eventually gate on: streaming secrets from upstream error bodies to the browser.

For streaming-responses, write the claim on a sticky note in this exact shape: “Given upstream chunk iterator, response headers, abort signal, the SSE token relay will …”. Fill the ellipsis with the observable part of: client receives ordered data events and a terminal done event; cancel stops further writes. Tape the baseline beside it: non-streaming JSON endpoint latency for the same prompt. If someone later replaces your metric with a vibe check, the sticky note is how you push back.

Also sketch the one-sentence user story: a person uses this output to stream tokens to a client while honoring cancel and partial failure. If that sentence needs a dashboard, a model zoo, or five services, the lab scope is too wide—shrink the fixture (fake chunk iterator yielding three tokens then done) until the story fits on one screen.

Decide now whether live network calls are allowed on page 1. For this lab they usually are not; inventory and contracts should run offline against fake chunk iterator yielding three tokens then done. Note the metric you will eventually require (time-to-first-byte, event count, cancel stops within N events) so page 4 cannot invent a softer target. The characteristic failure to keep in mind is buffering the whole answer before first byte, or ignoring client disconnect.

At the experiment brief stage for streaming-responses, the job is narrower than finishing a product demo. You are creating one progressive evidence piece about fake chunk iterator yielding three tokens then done that later pages inherit without redefining success. Keep that fixture small enough to inspect by hand, keep outputs copy-pasteable as text, and refuse to narrate this baseline as if it were a production SLA: non-streaming JSON endpoint latency for the same prompt.

For this page specifically, success looks like a falsifiable claim and baseline written before coding while still centering the user decision to stream tokens to a client while honoring cancel and partial failure. If you cannot point to a file, command, or assertion that proves that for the SSE token relay, stay on this page instead of advancing.

Glossary: tool · Glossary: structured output · Cheatsheet: production ops signals

Next