[WaterrrForever]

What

Outside a terminal, cloud render now writes the status and elapsed time once a minute while a render stays in the same status. Before, it wrote a line only when the status changed. The style-sampling remix guide now says the cloud reports no frame count, and how to check on a job the CLI stopped waiting for.

Why

This comes from the v0.9.16 style-sampling run. Agents run cloud render with output going to a log file, not a terminal.

• What they saw: queued 0.1s, then rendering 2.1s, and nothing more until the job completed. 3D shot jobs took 8–28 minutes.
• What they did: one agent killed its client after 12.5 minutes and dropped the shot. Another reported its job as "never finished". Both jobs (4f653364…, 26d2d44e…) did complete on the server.
• Why the log can't say more: the API's render detail has no progress field. GET /v3/hyperframes/renders/{id} returns status only.
• What this changes: a slow render and a stalled one now look different in the log, and the guide stops asking for progress the CLI cannot give.

Related work

• A real percentage needs the render service to report frames rendered. That needs a cutroom or API change and is a separate task.
• Siblings: fix(cli): media-use voices says whose clones it lists, and --voice takes language codes #7261.

How

• logsTick: a new function decides when a non-TTY tick prints. It prints when the status changes, or when 60 s have passed since the last printed line.
• TTY and --json: unchanged. The TTY line already redraws the elapsed time on every poll.
• remix.md §7: report the elapsed time the log prints each minute; a 3D shot can sit at rendering for 20 minutes and still finish; check a job with cloud get <id>.

Test plan

• Unit test: logsTick stays quiet within the minute and prints after 60 s or on a status change.
• Test run: src/commands/cloud/ passes, 38 tests.
• Static checks: oxfmt, oxlint and tsc report nothing on the touched files. lint-skills, check-core-skills and check-skill-mirror pass.
• Comment ratchet: not run locally, because git 2.25 on this machine is too old for it. CI runs it. The one comment I touched was reworded, and none were added.
• Manual: no live cloud render. The sign-in on the test machine has expired.

🤖 Generated with Claude Code

https://claude.ai/code/session_01HebQXPiLcYKQfvPWB3Fgxy

[jerrai-bot-heygen]

Reviewed at 02a0e10086cc8e15aef70af67cd926cc5ad0bf81. The non-TTY branch reuses the existing pollUntilTerminal tick (no extra timer), prints immediately on a status change and again when at least 60 seconds have elapsed since the last line. TTY redraw and JSON silence remain on their existing branches; terminal completion, timeout and request failure still flow through the existing poller/error path. The style-sampling guide now correctly calls the figure elapsed time rather than frame progress. Unit coverage checks the threshold and status-change predicate; it does not exercise a live cloud render or the full polling/output path. At review time some Windows engine/CLI checks were still running; pending CI is an independent merge gate, not a defect in the code.

Nonblocking nuance: a user-configured poll interval over 60 seconds cannot emit exactly each minute because output is sampled only on ticks. That setting already trades polling frequency for silence, while the default 2-second cadence delivers the stated behavior. Code approval only; no merge, enqueue or live render by me. — Jerrai

[jrusso1020]

Reviewed at 02a0e10086cc8e15aef70af67cd926cc5ad0bf81.

Need: yes · Size: ok · Reuse: existing pollUntilTerminal ticks and elapsed clock · Simpler: already minimal; no heartbeat scheduler · Structure: fine
Risk: low — bounded logging change; render submission and lifecycle are unchanged.

render.ts:997 prints on a status transition or on the first successful polling tick at least 60 seconds after the previous printed tick. The timestamp resets after every printed line. The existing strict stdout.isTTY branch is unchanged, and --json returns before either output branch.

No interval timer is introduced. Terminal success/failure, timeout and API errors leave the same polling loop; the new logging adds no handle that can keep the process alive. SIGINT retains normal process termination.

Verification: seven existing poll tests pass. Executable probes using exact transpiled pollWithProgress/logsTick/pollUntilTerminal functions, with fake clock/client and formatting stubs, passed non-TTY minute/reset boundaries, status changes, TTY redraw parity, JSON silence, completed/failed states, API error and timeout. A separate subprocess running the actual poll module exited promptly on SIGINT. bun scripts/gen-skills-manifest.ts --check passes. The full cloud command suite could not collect with borrowed dependencies (stale workspace exports/missing dependencies); no full CLI build or live cloud render was exercised.

The heartbeat is tied to successful GETs: a custom poll interval above a minute produces correspondingly less frequent lines. It reports client polling activity, not server frame progress.

Verdict: APPROVE
Reasoning: The existing polling loop supplies the heartbeat without adding timer cleanup obligations or changing TTY/JSON behavior.

— Rames (hf-review)