| name | eta-reporting |
| description | Announce an ETA in the chat for ANY task that will not finish before your next message — background bash commands (run_in_background), Workflow runs, subagents (Agent tool), GPU/RunPod dispatches, PR merge-watchers, monitors, model pulls/training, and multi-minute builds. Fires the moment you launch or hand off long-running work, and again on material change or completion. The user runs many parallel agents and is often away from the terminal; a task with no stated ETA reads as "hung." Use whenever you start something you will report back on later. |
ETA reporting (every long task states when it will land)
The user orchestrates several concurrent AI sessions and frequently steps away. When an agent kicks off background work — a paid GPU run, a Workflow, a merge-watcher, a subagent — and says nothing about timing, the user cannot tell "working, back in ~40 min" apart from "stuck." Every task that will not complete within your current turn must carry an ETA in the chat. This is a communication rule, not an accuracy contest — a rough honest range beats silence.
When this fires
State an ETA whenever you launch or are waiting on work that outlives your message:
Bash with run_in_background: true (monitors, poll loops, long installs, builds)Workflow runs and Agent/subagent spawns- GPU/RunPod dispatches, model pulls, training/eval,
mlx_lm.lora runs
- PR merge-watchers, CI waits,
ScheduleWakeup/loop iterations
- anything you end a message with "I'll report when it's done"
If it finishes inside the same turn, no ETA needed — just report the result.
What to say
- On launch — one line, up front: what it is + when it lands.
▶ RLVR seed-0 GRPO on RunPod — ETA ~35–50 min (pull ~15 + train ~25). I'll report when the receipt lands.
- On material change — if reality diverges from the estimate by more than ~50% or a phase stalls, say so; don't let a stale ETA ride.
⏱ Update: model pull is slow (~20 MB/s), revised ETA ~70 min.
- On completion — actual vs. estimate, briefly.
✅ Landed in 41 min (est. ~45). Result: …
Prefer a range ("~30–45 min") over false precision. If you genuinely can't estimate, say what you're waiting on and give a check-back interval instead ("no firm ETA — I'll re-check every ~20 min until the pod posts a heartbeat").
Calibration (this repo's typical durations)
| Task | Rough ETA |
|---|
| PR CI → admin-merge (green) | ~2–10 min |
| Workflow (2–4 offline builder agents) | ~3–8 min |
| Subagent (focused read+edit) | ~2–6 min |
| RunPod pod boot + SSH/serve ready | ~3–6 min |
| Ollama/model pull (~1 GB) | ~1–3 min; ~83 GB set → 15–70 min (download dominates) |
| LoRA/GRPO train (1.7B–9B, 1 seed) | ~15–45 min on a 48–80 GB GPU |
| 70B judge load + inference pass | ~10–40 min (memory-heavy — a frequent stall point) |
| Ledger-treadmill rebase + re-merge | ~1–5 min |
These are starting points — adjust to the live signal (network speed, GPU tier, queue depth). Timestamps in this repo are UTC; if you quote a clock time, say which.
Don't
- Don't bury the ETA at the end of a wall of text — lead with it.
- Don't state an ETA you won't track. If you promise "~40 min," actually surface the result or a revision around then (a background task's completion notification is your cue).
- Don't fake precision ("ETA 37 min") when you mean "roughly half an hour."
- Don't drop the ETA on retries — a re-dispatched/rebased task gets a fresh ETA.
Why
A stated ETA lets the user leave, parallelize other sessions, and trust that silence is progress, not a hang. It also forces you to reason about cost and duration before launching — which catches "this 3-seed run is 3× the pulls" and "this pod will bill for an hour" while they're still cheap to change. Pairs with [[spark-cluster-ops]] (cost/one-GPU-job discipline) and the background-task notifications the harness already emits.
