How Live AI Progress Reaches the Browser

A live progress bar is a distributed system in miniature. The GPU worker knows about nodes and sampling steps. The product knows about jobs and stages. The browser needs authorized, ordered, resumable updates.

1. ComfyUI emits a node or sampler progress message with a provider prompt ID.
2. The worker maps that message to the application job and a product stage.
3. The worker persists meaningful state changes and publishes a safe event.
4. An API process subscribes and finds authorized connections for that job.
5. The browser reduces the event into local UI state.
6. A slower refresh path reconciles the UI with durable state.

Movey uses this layered translation because internal node IDs should not become a permanent public contract. The UI can display “Encoding video” while the workflow changes from one encoding node to another.

RFC 6455 defines WebSocket as an HTTP upgrade followed by framed, two-way communication over one TCP connection. The WHATWG HTML standard defines EventSource streams using text/event-stream and supports a last-event identifier for reconnection.

{
  "type": "job.progress",
  "job_id": "job_456",
  "attempt_id": "attempt_2",
  "sequence": 17,
  "stage": "generating",
  "progress": 67,
  "message": "Generating motion",
  "occurred_at": "2026-07-23T21:00:00Z"
}

Include enough identity to reject stale messages. Sequence numbers help detect duplicates and reordering. Stage names should be stable product vocabulary. A human-readable message may change without breaking client logic.

ComfyUI’s server messages include execution_start, executing, progress, executed, cached-node notifications, and execution errors. A bridge should preserve diagnostic detail in structured logs while publishing only safe user-facing fields.

A reconnecting browser may receive an old event after it has already fetched a newer durable state. The reducer should compare sequence or version values rather than blindly applying arrival order.

• Ignore events for another authenticated owner or job.
• Ignore an earlier attempt after a retry starts.
• Ignore a lower state version than the current snapshot.
• Treat completed, failed, and cancelled as terminal for that attempt.
• Fetch a fresh snapshot after reconnect before resuming live events.

A sampler with value 6 and max 9 is two-thirds through its sampling loop. It is not necessarily two-thirds through wall-clock time. Model loading may dominate the beginning, and VAE decoding or video encoding may dominate the end.

Use measured stage weights when historical timing is stable. Otherwise show named stages and an indeterminate indicator. Never let a progress bar reach 100 before the output is durable and readable.

Knowing a job ID must not grant access to its progress or output. Authenticate the connection, authorize each subscription, and recheck ownership when the server sends data. Do not place long-lived secrets in URLs.

Events should not include raw prompts, signed asset URLs, stack traces, provider credentials, or filesystem paths. The browser needs a stage, percentage, safe message, and stable identifiers.

1. Load the current job snapshot over authenticated HTTP.
2. Open the live channel and subscribe to the job.
3. Apply only newer authorized events.
4. When disconnected, keep the last known state and start slower polling.
5. Reconnect with bounded backoff.
6. Fetch another snapshot before trusting the resumed stream.
7. Stop all refresh work when the job reaches a durable terminal state.

Protocol standards and current ComfyUI server documentation used for the transport and message behavior.

• RFC 6455: The WebSocket Protocol defines the upgrade handshake and two-way framed transport.
• WHATWG server-sent events defines EventSource, event-stream framing, and last-event identifiers.
• ComfyUI server messages documents execution, progress, cached, and completion message types.
• ComfyUI server routes documents the WebSocket, queue, history, and interrupt routes.