opencode: Model auto-discovery

[Vlaaaaaaad]

TL;DR: now that models.dev data is not 100% terrible, automatically fill the OpenCode model list.

Objective

This will avoid all the "Zed is missing models from OpenCode because the list is hardcoded" issues. See #56869 (comment) for a short overview or #55359, #54589, #58256, #58806 and then #54880, #55574, #56278, #56328, #57076, #57556, #57792, #58743, and #59236 for the whole drama (and probably a few issues/PRs/comments I missed) 😅

Might start a whole new chain of "OpenCode model config is wrong" + "Please go report that to OpenCode so they fix the data on Models.dev" issues 🙃 For the record, I am totally fine delaying the merge of this PR!

Solution

Background

When OpenCode was implemented in Zed Agent (both the original Zen-only version and then the current Zen+Free+Go version) a hardcoded list of models was used. This was both inline with other providers and it was the only valid option: there was nowhere to get the data from and the information needed to configure models was split in multiple places (OpenCode docs, OpenCode's Models.dev, hardcoded stuff in OpenCode, etc). Even this mid-May a lot of the required data was missing!

Over the past month, Anomaly (the company behind OpenCode) has been hard at work on making Models.dev the single source of truth for model configuration (mostly since they wanna use that in OpenCode too): reasoning details were added, bugs were fixed, automation was cleaned up, enhanced checks were configured, and so on. Last week there was still some missing data (DeepSeek in OpenCode CLI supported low, medium, high, and max reasoning levels but only high and max were mentioned on the data, for example) or buggy data (for 6-ish hours there as a wrong endpoint set for Qwen models) but all those issues seem to be fixed now so finally we can implement model auto-discovery in Zed 🎉

Implementation details

Short version: instead of hardcoded models, get the data from Models.dev, parse it into models + model configuration details, and use it in Zed. To not ruin performance, cache this and respect etag + 304 Not Modified . Also, I have fabulous risk management skillsanxiety and not too much confidence in Models.dev, so there's a ton of error handling.

Testing

The overall implementation has been under testing for more than 3 weeks now, but the exact code on this PR only got some quick manual tests and validation: a "rename this variable for me. add a function. delete the function" test was ran using a few models.

This is quite a big change (almost a re-write) and I am not very confident, neither in the code nor in the data, so I would suggest having this remain in Zed Preview for a bit longer?

Review tips and Notes

First off, this is a huge PR and I apologize for that! I tried splitting it into easier-to-review commits but there is still a lot of code that could not be avoided. I'd suggest reviewing this commit-by-commit but since we're doing almost a re-write, reviewing only the final code might make sense?

Notes:

• there is a bunch of super-verbose error handling and retries and logging. That's not due to dumb LLMs but very much due to me not trusting the reliability of models.dev and me wanting to make failures super-clear and easy to debug. If y'all think this is me going overboard, I am happy to remove it!
• performance is terriblenot great and there's nothing we can do about it. Feature Request: Support precise filtering of vendor id in the api anomalyco/models.dev#1749 means the full https://models.dev/api.json has to be downloaded, which is a chonky JSON that is more than 2MB and that contains data for more than 140 providers with a ton of models. Depending on the connection and latency, this means 1) a small delay and 2) cached data is ruined by updates to any of the non-OpenCode providers. There's no alternative to this — https://opencode.ai/zen/v1/models and https://opencode.ai/zen/go/v1/models only have the model names and we need the model configuration details too and those are only available on models.dev which only offers huge JSONs 😞
• parallel tool call support is missing from the data available on Models.dev (see Request: New column for parallel tool calling anomalyco/models.dev#202) but OpenCode developers said on Discord that "almost all models worth using support parallel tool calling natively" and I manually confirmed that to be true for all OpenCode Go models
• this has been in the works for a while now and this went through a ton of changes, so some code might look weird or unnatural to y'all but totally normal to me since I've been working on this for so long. Please let me know if that is the case!

Decisions I made:

• no auto-update. I did consider running the auto-discovery every 15 minutes or every hour or whatever, but that would've been a bit too chaotic (potential surprises, mid-work interruptions, Zed doing too many network calls, etc)
• no opt-in. I did initially have an enable_model_autodiscovery checkbox but I did not see the point in keeping that option (folks on restricted networks / slow networks / WiFi-less plane can't use LLMs, using OpenCode only with custom models makes little sense, etc)
• no hardcoded models kept. I did consider this option, especially since I am worried about the data quality on Models.dev, but that would have been difficult (complex merging logic, duplicate names, unclear icons or sourcing notes for each model in the list, etc) for no benefit (custom models can be used if the data is wrong for 1 model until the data is fixed)
• not too much logging. I only kept serde_json::to_string_pretty for the model cache and a Last updated timestamp and I decided against logging a bunch of details about the cached models (too many logs or too many UI changes for little value, high complexity, user confusion, etc)
• no cost data. The data from Models.dev also includes the cost for each model which would be nice to display in Zed, but right now that looks terrible so the data is dropped:

Showcase

A few screenshots

Model list:

Settings, failure:

Settings, in progress:

Settings, normal:

Self-Review Checklist:

• I've reviewed my own diff for quality, security, and reliability
• Unsafe blocks (if any) have justifying comments
• The content adheres to Zed's UI standards (UX/UI and icon guidelines)
• Tests cover the new/changed behavior
• Performance impact has been considered and is acceptable (eh, debatable — see above)

---

Release Notes:

• OpenCode: Auto-discover the model list (use data from models.dev instead of a hardcoded list in Zed)
• OpenCode: Enable parallel tool calls for all models
• OpenCode Zen: Fix thinking for Google models

[Vlaaaaaaad]

FYI: Models.dev will sometime in the future get a new V2 API/schema: anomalyco/models.dev#3037

[Vlaaaaaaad]

Yeah, no, I am closing this PR — testing the reliability and accuracy of Models.dev on Zed users is, in my opinion, a disgusting proposal.

I appreciate and love using Zed for LLM-assisted development because Zed is somewhat more stable (not bleeding edge with a ton of experimental features that get added and removed every day and that force users to adopt&change their workflow regularly, but not many months behind either) and well thought out (for example, Zed wasn't the first to have parallel agents but when Zed added parallel agents it was fabulously integrated and a great experience) and this PR is completely against that. As a user, I would much rather have outdated models / have to define a Custom OpenCode model myself than getting a broken list of models or broken model configs.

The bugfixes and tiny enhancements from this PR will be added in a new PR which will also update the models (adding reasoning levels to all models). I'll do that on Monday/Tuesday 🤞

When OpenCode V2 launches and when Models.dev V2 launches and is used by OpenCode and is shown to be stable, the model auto-discovery implementation from this PR can be resurrected, maybe with a toggle between "Use hard-coded model configurations" and "Use Models.dev to auto-discover model configurations".

Apologies for the churn!

[Vlaaaaaaad]

FYI: it looks like a bigger API revamp is happening as part of OpenCode V2: potentially moving to https://console.opencode.ai/inference/openai/v1 instead of https://opencode.ai/zen/v1, for example. After OpenCode V2 launches I'll look at doing the optional auto-discovery implementation, assuming I have the bandwidth 🤞

[Tobbe]

As always, thanks for your work on OpenCode support in Zed @Vlaaaaaaad