Fleet task `{}` pins model `{}` with {} (source={source}), b

Error message

Fleet task `{}` pins model `{}` with {} (source={source}), but that route does not resolve to a real model on any configured provider, so the worker cannot launch. The runtime never infers a provider from a model's spelling — set an explicit provider for this model in the profile, or switch the role to `inherit`.

What it means

The task pins a concrete model, but route resolution found no real model matching it on any configured provider, so the worker cannot launch. The runtime deliberately never infers a provider from a model's spelling (a name like "gpt-..." does not auto-select OpenAI); without a resolvable route the launch is refused rather than sent to a wrong provider. The message tells you whether an explicit provider was set or resolution fell through to the session/default provider.

Source

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

        let route = resolve_fleet_route_with_config(task, agent_profiles, session_model, config);
        if route.is_some() {
            validate_fleet_reasoning_effort(task, agent_profiles, session_model, config)?;
        }
        if !pinned_model {
            continue;
        }
        // A concrete model is pinned at the task/profile level; it must resolve
        // to a real provider route or the worker cannot launch.
        if route.is_some() {
            continue;
        }
        let provider = explicit_provider
            .map(|provider| format!("provider=`{provider}`"))
            .unwrap_or_else(|| {
                "no explicit provider (resolves against the session/default provider)".to_string()
            });
        bail!(
            "Fleet task `{}` pins model `{}` with {} (source={source}), but that route does not \
             resolve to a real model on any configured provider, so the worker cannot launch. \
             The runtime never infers a provider from a model's spelling — set an explicit \
             provider for this model in the profile, or switch the role to `inherit`.",
            task.id,
            model,
            provider
        );
    }
    Ok(())
}

/// Reject an explicit Fleet thinking tier when the exact resolved route does
/// not advertise reasoning support. `inherit`, `auto`, and `off` are valid on
/// every route because they do not force a reasoning payload. This check is
/// deliberately performed at run creation, after the same route resolver used
/// for launch, so the UI cannot save a profile that will silently downgrade or
/// fail at spawn time (#4866).

View on GitHub (pinned to 0c42157ee5)

Solutions

Set an explicit provider for the model in the agent profile, so resolution targets the right catalog.
Verify the exact model id against the provider's current model list and fix typos or outdated names.
Configure the provider fully (credentials, base_url) so its models are resolvable at all.
If you do not need a pin, switch the role to `inherit` to ride the session model.

Example fix

# before (agent profile TOML)
id = "reviewer"
model = "deepseek-chatx"   # typo, resolves nowhere

# after
id = "reviewer"
provider = "deepseek"
model = "deepseek-chat"

Defensive patterns

Strategy: validation

Validate before calling

// Pre-flight: a pinned model must resolve on a configured provider before you submit the spec.
fn model_resolves(model: &str, provider: Option<&str>, configured: &ModelCatalog) -> bool {
    match provider {
        Some(p) => configured.serves(p, model),
        None => configured.serves_any(model),
    }
}

Try / catch

if let Err(e) = build_worker_spec(&task, &profiles) {
    let msg = e.to_string();
    if msg.contains("does not resolve to a real model") {
        // fix the pin: explicit provider, correct model id, or role = "inherit"
    }
}

Prevention

Never rely on model-name spelling to imply a provider — set the provider explicitly.
Keep a checked list of valid provider/model pairs and lint task specs against it.
When a provider renames models, grep your profile TOMLs for the old id before upgrading.

When it happens

Trigger: A typo in the pinned model id; an explicit provider set in the profile but the model absent from that provider's catalog; the provider unconfigured (no credentials/base_url) so nothing resolves; a role carrying a pinned model that no longer exists after a provider-side rename.

Common situations: Upgrading a provider SDK/config that renamed model ids; profiles written for one provider used against another; models behind an allowlist-restricted API key that hides them from resolution.

Related errors

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