aaif-goose/goose · error

Could not resolve model config: {e}

Error message

Could not resolve model config: {e}

What it means

Final fallback step of Agent::model_config_for_session: with a provider and model name in hand, model_config_from_user_config(&provider_name, &model_name) still failed. The {e} payload carries the real cause — typically the provider string is not resolvable to a known provider config, so goose cannot build a ModelConfig (context limit, auth requirements, tool support).

Source

Thrown at crates/goose/src/agents/agent.rs:966

            .config
            .session_manager
            .get_session(session_id, false)
            .await
        {
            if let Some(model_config) = session.model_config {
                return Ok(model_config);
            }
        }

        let config = Config::global();
        let provider_name = config
            .get_goose_provider()
            .map_err(|_| anyhow!("Could not resolve model config: missing provider"))?;
        let model_name = config
            .get_goose_model()
            .map_err(|_| anyhow!("Could not resolve model config: missing model"))?;
        crate::model_config::model_config_from_user_config(&provider_name, &model_name)
            .map_err(|e| anyhow!("Could not resolve model config: {e}"))
    }

    /// When set, all stdio extensions will be started via `docker exec` in the specified container.
    pub async fn set_container(&self, container: Option<Container>) {
        *self.container.lock().await = container.clone();
    }

    pub async fn container(&self) -> Option<Container> {
        self.container.lock().await.clone()
    }

    /// Check if a tool is a frontend tool
    pub async fn is_frontend_tool(&self, name: &str) -> bool {
        self.frontend_tools.lock().await.contains_key(name)
    }

    /// Get a reference to a frontend tool
    pub async fn get_frontend_tool(&self, name: &str) -> Option<FrontendTool> {

View on GitHub (pinned to 3810898a74)

Solutions

  1. Read the {e} suffix — it names the exact construction failure
  2. Verify the provider id against the list shown by `goose configure` / `goose leaderboard`
  3. Update goose to the latest version so new provider ids resolve
  4. For custom providers, validate the config.yaml entry (base_url, model name, API key reference)

Example fix

# before
GOOSE_PROVIDER=open_ai GOOSE_MODEL=gpt-5.2 goose session
Error: Could not resolve model config: ...

# after
GOOSE_PROVIDER=openai GOOSE_MODEL=gpt-5.2 goose session
Defensive patterns

Strategy: try-catch

Validate before calling

let provider_name = config.get_goose_provider()?;
// cheap probe before relying on it in a session:
if goose::model_config::model_config_from_user_config(&provider_name, &model_name).is_err() {
    anyhow::bail!("provider/model pair not constructible: {provider_name}/{model_name}");
}

Type guard

fn model_config_failed(e: &anyhow::Error) -> bool {
    e.to_string().starts_with("Could not resolve model config")
        && !e.to_string().contains("missing provider")
        && !e.to_string().contains("missing model")
}

Try / catch

match agent.model_config_for_session(&session_id).await {
    Ok(cfg) => cfg,
    Err(e) if model_config_failed(&e) => {
        eprintln!("provider/model invalid ({}); run `goose configure`", e);
        std::process::exit(2);
    }
    Err(e) => return Err(e),
}

Prevention

When it happens

Trigger: GOOSE_PROVIDER holds a value that doesn't match any built-in or configured custom provider; a custom OpenAI-compatible provider entry in config.yaml is malformed; version skew where the provider id was renamed or is only available in a newer goose.

Common situations: Typos in GOOSE_PROVIDER (e.g. 'open_ai' vs 'openai'); referencing a recently added provider on an outdated goose binary; broken custom provider definitions under the goose config's custom-providers section.

Related errors


AI-assisted analysis of aaif-goose/goose@3810898a74 (2026-08-16). Data as JSON: /api/errors/b95c0b10633f2df0. Report an issue: GitHub.