ComfyUI generations report wall time only; split queue / execution / download timing

Author: Alan5168Created Sep 3, 2026Updated Sep 3, 2026

Problem

Today the only duration signal around a ComfyUI generation is wall time. On a shared or busy server, wall time conflates three very different things:

  1. queue wait — time between submit() and the server starting execution
  2. actual prompt execution — real GPU/workflow time
  3. download — artifact transfer

Cost tracking, capacity planning, and timeout tuning all need these split. Right now an agent reporting "generation took 240s" cannot tell whether the GPU was busy for 230s or the job sat in queue for 200s.

Proposed change

Add lightweight timing instrumentation to ComfyUIClient.generate():

  • record submit_s, client_queue_and_poll_s, download_s from the client's own clock (time.perf_counter)
  • read server-side execution time from the history entry's execution_startexecution_success timestamps (ComfyUI already records these; needs ms-vs-s normalization since servers differ)
  • expose the result as client.last_timing (dict, None before first run) so any caller — comfyui_video, comfyui_image, comfyui_music — can surface it in result data without API changes

Surface result.data["timing"] in comfyui_video (and ideally the other ComfyUI tools) including wall_s and the derived comfy_prompt_exec_s.

No schema changes, no new dependencies, backwards compatible (callers that ignore last_timing see no difference).

Happy to send a PR with unit tests (history timestamp parsing incl. ms/s normalization, and the generate() instrumentation with a faked client).