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
- Read the {e} suffix — it names the exact construction failure
- Verify the provider id against the list shown by `goose configure` / `goose leaderboard`
- Update goose to the latest version so new provider ids resolve
- 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
- Validate provider ids against `goose configure` before saving them to env/config
- Upgrade goose when adopting new provider ids
- Log the wrapped {e} — it pinpoints the construction failure
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
- Could not resolve model config: {error}
- Provider not set
- Could not resolve model config: missing provider
- Provider '{}' has dynamic_models: false but no static models
- Invalid base URL '{}': {}
AI-assisted analysis of aaif-goose/goose@3810898a74 (2026-08-16).
Data as JSON: /api/errors/b95c0b10633f2df0.
Report an issue: GitHub.