Hmbown/CodeWhale · error

Fleet task `{}` requests thinking tier `{effort}` for `{}` /

Error message

Fleet task `{}` requests thinking tier `{effort}` for `{}` / `{}`, but that exact model route does not support thinking; choose inherit, auto, or off, or select a reasoning-capable model

What it means

The task or its agent profile requests an explicit thinking tier (reasoning_effort such as low/medium/high/max), but the exact resolved route — this provider plus this wire model id — reports thinking_supported = false via `provider_capability`. The check is per exact model route, not per provider, and it only runs when the route resolves; unresolved-route errors belong to the model-route validator. The launch is refused instead of silently sending a thinking flag the model ignores.

Source

Thrown at crates/tui/src/fleet/worker_runtime.rs:160

        effective_fleet_reasoning_effort_for_role(task.worker.as_ref(), agent_profile)
    else {
        return Ok(());
    };
    if matches!(effort.as_str(), "inherit" | "auto" | "off") {
        return Ok(());
    }
    let Some(route) = resolve_fleet_route_with_config(task, agent_profiles, session_model, config)
    else {
        // The model-route validator owns unresolved-route errors and produces
        // the more useful provider/model diagnosis.
        return Ok(());
    };
    let provider = ApiProvider::parse(&route.provider_kind).unwrap_or(ApiProvider::Custom);
    let capability = crate::config::provider_capability(provider, &route.wire_model_id);
    if capability.thinking_supported {
        return Ok(());
    }
    bail!(
        "Fleet task `{}` requests thinking tier `{effort}` for `{}` / `{}`, but that exact model route does not support thinking; choose inherit, auto, or off, or select a reasoning-capable model",
        task.id,
        route.provider_id,
        route.wire_model_id,
    );
}

/// Build a sub-agent worker spec after resolving workspace Fleet profile input.
///
/// This keeps Fleet and sub-agents on the same runtime substrate: profile files
/// and task-level role/loadout intent are composed into the existing
/// `AgentWorkerSpec` / `WorkerRuntimeProfile` pair, then optionally intersected
/// with a parent profile when the caller has one.
/// A worker workspace is isolated when it is a linked git worktree that sits
/// outside the coordinating manager's workspace (and does not contain it):
/// its mutations cannot overlap the shared checkout, so its launch manifest
/// must not claim the shared-workspace coordination scope (#5036).
fn worker_workspace_is_isolated(

View on GitHub (pinned to 0c42157ee5)

Solutions

  1. Set the profile's reasoning_effort to `inherit`, `auto`, or `off` so no unsupported tier is requested.
  2. Select a reasoning-capable model for that profile if you really need the tier.
  3. For custom model ids, check that your capability/provider mapping classifies the model correctly instead of defaulting to non-thinking.

Example fix

# before (agent profile TOML)
id = "implementer"
model = "fast-chat-model"
thinking = "high"

# after
id = "implementer"
model = "fast-chat-model"
thinking = "off"
Defensive patterns

Strategy: validation

Validate before calling

// Before submitting, confirm the requested tier is compatible with the exact route.
fn tier_is_compatible(effort: Option<&str>, provider: ApiProvider, wire_model: &str) -> bool {
    match effort {
        None | Some("inherit") | Some("auto") | Some("off") => true,
        Some(_) => crate::config::provider_capability(provider, wire_model).thinking_supported,
    }
}

Type guard

fn route_supports_thinking(provider: &str, wire_model_id: &str) -> bool {
    let provider = ApiProvider::parse(provider).unwrap_or(ApiProvider::Custom);
    crate::config::provider_capability(provider, wire_model_id).thinking_supported
}

Prevention

When it happens

Trigger: An agent profile with `reasoning_effort = "high"` (alias `thinking`/`reasoning` in TOML) while the resolved route is a non-reasoning model; changing a profile's model but keeping its saved thinking tier; custom/self-hosted model ids with no capability mapping.

Common situations: Switching from a reasoning model to a fast chat variant for cost and forgetting the tier; profiles shared across providers where only some variants support reasoning; new model ids the capability table classifies as non-thinking.

Related errors


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