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
- Set the profile's reasoning_effort to `inherit`, `auto`, or `off` so no unsupported tier is requested.
- Select a reasoning-capable model for that profile if you really need the tier.
- 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
- Default profiles to `thinking = "inherit"` and pin tiers only per task that needs reasoning.
- When swapping a profile's model, re-check its saved reasoning_effort against the new route.
- Maintain a note of which model ids are reasoning-capable per provider you use.
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
- fleet task {task_id} has duplicate tag {tag}
- fleet task {} environment variable name cannot be empty
- Fleet task `{}`: {reason} (source={source})
- Fleet task `{}` pins model `{}` with {} (source={source}), b
- fleet task '{}' is write-capable but declares no workspace.w
AI-assisted analysis of Hmbown/CodeWhale@0c42157ee5 (2026-08-20).
Data as JSON: /api/errors/8c900d8f882f4ee5.
Report an issue: GitHub.