Blocker visibility — waitingFor on stalled workers
When a worker cannot make progress, a waitingFor field explains why. It appears in:
cyberine agents --json— per-worker field in the structured JSON output (omitted when not blocked).- The TUI run-detail view (
cyberine agents/cyberine tui, then press Enter on a run) — shown as ablocked:sub-line under the worker row, in warning color.
Three blocking reasons are tracked automatically (no extra configuration):
| Scenario | waitingFor value |
|---|---|
| Governor concurrency queue (too many workers active) | governor queue — waiting for concurrency slot |
| Pending upstream step (DAG dep not done yet) | pending upstream step: <step-id> |
| Resumed (slot acquired / step done) | field removed |
The field is cleared automatically when the worker resumes or the run terminates. Non-blocked workers never carry the field.
# See blocked workers as structured JSON
cyberine agents --json | jq '[.[] | select(.state=="running") | {runId, steps: [.steps[] | {stepId, workers: [.workers[] | select(.waitingFor) | {agentId, waitingFor}]}]}]'
# Interactive view — open the fleet TUI, select a run, press Enter
cyberine agentsQuota cooldown — automatic circuit-breaker after 402/429
When a worker fails with a quota signal (HTTP 402 payment required / insufficient credits, or HTTP 429 rate-limit / too-many-requests), Cyberine records a temporary cooldown for that worker ID in...
Provider circuit breaker and bounded retry — one dead provider degrades the fleet, not the run
Distinct from the quota cooldown above, which reacts only to a 402/429 quota signal: the breaker counts consecutive terminal failures of any shape at the Orchestrator.dispatch() seam, so it also...