Hmbown/CodeWhale · error

bounded to model output cap

Error message

bounded to model output cap

What it means

In `reserve_handback` (crates/tui/src/tools/subagent/budget_handback.rs:165), the computed output token count is converted from `u64`/`usize` to `u32` with `u32::try_from(...).expect("bounded to model output cap")`. The invariant is that output token counts never exceed the model output cap, so they always fit in `u32`. A panic here means that invariant was violated — the reservation computed an output value larger than `u32::MAX`.

Solutions

  1. Verify the model output cap configured for the worker is a sane, finite value.
  2. Clamp the computed `output` to the model output cap before the conversion.
  3. Replace the `expect` with an explicit error return if unbounded estimates are possible.
  4. Add a test asserting reservations stay within the configured output cap.

Example fix

// before
u32::try_from(output).expect("bounded to model output cap")
// after
let output = output.min(model_output_cap as u64);
u32::try_from(output).unwrap_or(u32::MAX)
Defensive patterns

Strategy: validation

Validate before calling

// Guard before reserving: output must fit u32
fn output_fits_u32(output: u64) -> bool { output <= u32::MAX as u64 }

Type guard

fn bounded_output(output: u64) -> Option<u32> { u32::try_from(output).ok() }

Try / catch

// Replace expect with explicit clamping and error reporting
let out = u32::try_from(output)
    .map_err(|_| ToolError::execution_failed(format!("output estimate {output} exceeds model output cap")))?;

Prevention

When it happens

Trigger: Calling `reserve_handback` (via budget handback coverage markers or shared-ancestor/source-cap reservation paths) when the estimated output tokens computed from input tokens saturate or are otherwise unbounded, exceeding `u32::MAX`.

Common situations: A misconfigured model output cap (e.g. a cap parsed as a sentinel like `u64::MAX` or a bogus config value), or an arithmetic path that saturates `usize` before the conversion.

Understand the failure class

Background: "value must be between 0 and 1" / "out of range" / "must not be negative" errors: fixing range-validation failures across open-source libraries — this error's family across 42 libraries.

Related errors


AI-assisted analysis of Hmbown/CodeWhale@433685b202 (2026-09-15). Data as JSON: /api/errors/c54746353e7b7d55. Report an issue: GitHub.

Appendix: source

Thrown at crates/tui/src/tools/subagent/budget_handback.rs:165

            return Err("a hand-back turn is already in flight");
        }
        let available =
            narrow_optional_limit(self.available_worker_tokens(worker, false), local_remaining)
                .unwrap_or(allowance)
                .min(allowance);
        let output = available
            .saturating_sub(input_tokens)
            .min(u64::from(output_cap));
        if output < MIN_HAND_BACK_OUTPUT {
            return Err(
                "remaining token allowance cannot cover the estimated report input and output",
            );
        }
        let reservation = Arc::new(input_tokens.saturating_add(output));
        self.handback_reservations
            .insert(worker.to_string(), Arc::downgrade(&reservation));
        Ok((
            u32::try_from(output).expect("bounded to model output cap"),
            reservation,
        ))
    }
}

pub(super) enum Outcome {
    Report { text: String, usage_reported: bool },
    Fallback(String),
    Cancelled,
}

pub(super) fn repair_stopped_tool_calls(messages: &mut Vec<Message>, cause: &str) {
    let final_calls = messages
        .iter()
        .rev()
        .find(|message| message.role == Role::Assistant)
        .into_iter()
        .flat_map(|message| &message.content)

View on GitHub (pinned to 433685b202)