zed-industries/zed · error
invalid model id
Error message
invalid model id '{invalid_id}' What it means
`open_ai::Model::from_id` maps a model id string to the enum's variants; unrecognized ids bail with 'invalid model id {invalid_id}'. It guards against configuring or receiving model names that this OpenAI provider version doesn't know how to handle.
Solutions
- Use one of the supported ids (e.g. 'gpt-4', 'gpt-5.5', 'gpt-6-astra', etc.) in the model setting.
- Update Zed (or the open_ai crate) to a version whose from_id recognizes your model id.
- If you own the code, add a match arm for the new id plus its `id()` counterpart.
- For custom deployments, map them to a supported variant or use an available_models listing to validate before from_id.
Example fix
// before "model": "gpt-4o-mini" // after "model": "gpt-5.5"
Defensive patterns
Strategy: validation
Validate before calling
// validate the configured model id before requests
match open_ai::Model::from_id(&settings.model) {
Ok(model) => model,
Err(e) => { eprintln!("{e}; falling back to default"); open_ai::Model::default() }
} Type guard
fn is_supported_openai_id(id: &str) -> bool {
[
"gpt-4", "gpt-5.5", "gpt-5.5-pro", "gpt-5.6-sol",
"gpt-5.6-terra", "gpt-5.6-luna", "gpt-6-astra",
].contains(&id)
} Try / catch
let model = Model::from_id(&id).unwrap_or_else(|_| {
log::warn!("unsupported model id '{id}', using default");
Model::default()
}); Prevention
- Select model ids from the UI's available-models list instead of free typing.
- Keep Zed updated so newly released OpenAI ids are recognized.
- On from_id failure, surface the supported ids in the error message to users.
- For custom deployments, map them to supported variants before parsing.
When it happens
Trigger: Calling `Model::from_id` with an id not in the match list (e.g. 'gpt-4o', 'o3', a fine-tuned or Azure deployment name) when constructing requests or reading provider settings.
Common situations: Outdated Zed version encountering newer OpenAI model ids returned by the API; users typing unofficial/custom deployment names in the `model` setting; ids from API version mismatches.
Understand the failure class
Background: Invalid enum value errors: "Unknown type", "Invalid scope", "must be one of" — when a string is not on the library's allowed list — this error's family across 23 libraries.
Related errors
- invalid model id
- Zed cannot determine how to run this debug scenario…
- auto_compact threshold of 0 is not valid
- Cannot determine prettier parser for unsaved file
- Cannot have two different hosts in debug configuration
AI-assisted analysis of zed-industries/zed@916fc2b8cb (2026-09-19).
Data as JSON: /api/errors/58db8f2a4316ead4.
Report an issue: GitHub.
Appendix: source
Thrown at crates/open_ai/src/open_ai.rs:155
"gpt-4o-mini" => Ok(Self::FourOmniMini),
"o3" => Ok(Self::O3),
"gpt-5" => Ok(Self::Five),
"gpt-5-mini" => Ok(Self::FiveMini),
"gpt-5-nano" => Ok(Self::FiveNano),
"gpt-5.1" => Ok(Self::FivePointOne),
"gpt-5.2" => Ok(Self::FivePointTwo),
"gpt-5.3-codex" => Ok(Self::FivePointThreeCodex),
"gpt-5.4-nano" => Ok(Self::FivePointFourNano),
"gpt-5.4-mini" => Ok(Self::FivePointFourMini),
"gpt-5.4" => Ok(Self::FivePointFour),
"gpt-5.4-pro" => Ok(Self::FivePointFourPro),
"gpt-5.5" => Ok(Self::FivePointFive),
"gpt-5.5-pro" => Ok(Self::FivePointFivePro),
"gpt-5.6-sol" => Ok(Self::FivePointSixSol),
"gpt-5.6-terra" => Ok(Self::FivePointSixTerra),
"gpt-5.6-luna" => Ok(Self::FivePointSixLuna),
"gpt-6-astra" => Ok(Self::SixAstra),
invalid_id => anyhow::bail!("invalid model id '{invalid_id}'"),
}
}
pub fn id(&self) -> &str {
match self {
Self::Four => "gpt-4",
Self::FourOmniMini => "gpt-4o-mini",
Self::O3 => "o3",
Self::Five => "gpt-5",
Self::FiveMini => "gpt-5-mini",
Self::FiveNano => "gpt-5-nano",
Self::FivePointOne => "gpt-5.1",
Self::FivePointTwo => "gpt-5.2",
Self::FivePointThreeCodex => "gpt-5.3-codex",
Self::FivePointFourNano => "gpt-5.4-nano",
Self::FivePointFourMini => "gpt-5.4-mini",
Self::FivePointFour => "gpt-5.4",
Self::FivePointFourPro => "gpt-5.4-pro",View on GitHub (pinned to 916fc2b8cb)