Hmbown/CodeWhale · error

Fleet task ` ` cannot resolve its inherited model ` ` with…

Error message

Fleet task `{}` cannot resolve its inherited model `{model}` with {provider} (source={source}); attach the live route config for custom providers before creating the run

What it means

When the route is unresolved and the model was inherited (not pinned — sources like session/run default), validate_fleet_task_routes fails with this error. The inherited model `{model}` cannot be resolved with the effective provider (explicit profile provider or the session/default provider), and the fix is to attach the live route config, which custom providers require to prove their endpoint and model catalog.

Solutions

1. Attach the live route config (pass Some(&Config) to validate_fleet_task_routes / run creation) so custom providers can be resolved.
2. Set an explicit, non-custom provider on the agent profile for the task.
3. Change the task role to `inherit` against a resolvable session provider.
4. Pick a session model that resolves on the currently configured providers.

Example fix

// before
let run = fleet_run.create(tasks)?; // no config attached

// after
let run = fleet_run.create_with_config(tasks, &resolved_session_config)?;

if inherited_model && config.is_none() && provider_is_custom() {
    return Err("attach live route config before creating the run");
}

When it happens

Trigger: Calling validate_fleet_task_routes where resolve_fleet_route_with_config returns None and the effective model source is not `task.model`/`agent_profile.model` — i.e. the model is inherited from the session/run while only a provider name (possibly custom) or no provider is available, and no live route config proves the route.

Common situations: Creating a Fleet run without attaching resolved Config while the session model points at a custom provider endpoint; CI or headless contexts where the run is constructed from stored task specs but the session route config was never loaded.

Understand the failure class

Background: "X is required", "must be set", "cannot be empty": the missing-required-config error family, from Vertex AI project/location to WeChat keys — this error's family across 18 libraries.

Related errors

• Fleet task ` `: (source= )
• advisor model ` ` resolved only to a custom provider kind…
• agent profile path is not a directory
• agent profile provider cannot be empty
• agent profile provider must be a simple provider id

AI-assisted analysis of Hmbown/CodeWhale@73e0f67d83 (2026-09-22). Data as JSON: /api/errors/f77dc646fcaedc68. Report an issue: GitHub.

Appendix: source

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

        let route = resolve_fleet_route_with_config(task, agent_profiles, session_model, config);
        let provider = explicit_provider
            .map(|provider| format!("provider=`{provider}`"))
            .unwrap_or_else(|| {
                "no explicit provider (resolves against the session/default provider)".to_string()
            });
        if route.is_none() {
            if pinned_model {
                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
                );
            }
            bail!(
                "Fleet task `{}` cannot resolve its inherited model `{model}` with {provider} \
                 (source={source}); attach the live route config for custom providers before \
                 creating the run",
                task.id,
            );
        }
        validate_fleet_reasoning_effort(task, agent_profiles, session_model, config)?;
    }
    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).
fn validate_fleet_reasoning_effort(

View on GitHub (pinned to 73e0f67d83)