Hmbown/CodeWhale · error

child wall-time budget exhausted (limit: {}s); raise it with

Error message

child wall-time budget exhausted (limit: {}s); raise it with wall_time_secs or split the work into smaller independent tasks

What it means

The child's wall-time budget expired: either the launch-gate wait consumed the entire budget before the child started (launch_wait_timed_out), or run_subagent did not finish by the deadline via tokio::time::timeout_at. The budget comes from wall_time_secs at spawn (or the agent profile's default_wall_time, else DEFAULT_CHILD_WALL_TIME), and the error names the limit in seconds so you know what to raise.

Source

Thrown at crates/tui/src/tools/subagent/mod.rs:9942

                    acquire_queued_launch_permit(&task, Arc::clone(gate)),
                )
                .await
                {
                    Ok(permit) => _launch_permit = permit,
                    Err(_) => launch_wait_timed_out = true,
                }
            }
            Err(tokio::sync::TryAcquireError::Closed) => {
                crate::logging::warn(format!(
                    "sub-agent launch gate closed for {}; proceeding without backpressure",
                    task.agent_id
                ));
            }
        }
    }

    let result = if launch_wait_timed_out {
        Err(anyhow!(child_wall_time_exhausted_reason(task.wall_time)))
    } else {
        tokio::time::timeout_at(
            deadline.into(),
            run_subagent(
                &task.runtime,
                task.agent_id.clone(),
                task.agent_type,
                task.prompt,
                task.assignment,
                task.allowed_tools,
                task.fork_context,
                task.started_at,
                task.max_steps,
                task.token_budget,
                task.input_rx,
            ),
        )
        .await

View on GitHub (pinned to 0c42157ee5)

Solutions

  1. Raise wall_time_secs at spawn (or the agent profile's default_wall_time) comfortably above expected run time.
  2. Split the assignment into smaller independent child tasks that each fit the budget.
  3. Reduce fan-out concurrency so the launch gate doesn't consume each child's budget before it starts.
  4. Check for stuck steps: per-step API timeouts get their own retry budget (SUBAGENT_API_TIMEOUT_MAX_RETRIES), so repeated slow provider calls can still eat wall time — consider a smaller step timeout.

Example fix

// before
input["wall_time_secs"] = json!(60); // heavy task -> Err 1219

// after
input["wall_time_secs"] = json!(900);
// or split the work into smaller child assignments
Defensive patterns

Strategy: retry

Validate before calling

// Budget sanity check before spawn: estimated work must fit the wall clock.
let budget_secs = input["wall_time_secs"].as_u64().unwrap_or(DEFAULT_CHILD_WALL_TIME_SECS);
if estimated_task_secs > budget_secs {
    input["wall_time_secs"] = json!(estimated_task_secs * 2);
}

Try / catch

match run_child(task).await {
    Err(e) if e.to_string().contains("wall-time budget exhausted") => {
        // read the named limit, raise wall_time_secs (or split the task), then retry once
    }
    r => r?,
}

Prevention

When it happens

Trigger: Spawning with wall_time_secs too small for the assignment; large fan-outs where launch-gate backpressure delays start until the deadline; slow provider steps or stuck tool calls burning the clock.

Common situations: Heavy tasks spawned with default budgets; many concurrent children queuing on the launch gate so each starts with almost no budget left; provider latency spikes or API-timeout retry storms (each retried step still consumes wall time).

Related errors


AI-assisted analysis of Hmbown/CodeWhale@0c42157ee5 (2026-08-20). Data as JSON: /api/errors/0c880b699f61dbb7. Report an issue: GitHub.