[BUG] Could not fetch OpenCode Zen (Agents) model list. Using bundled model list. fetch failed

[leiyu1980]

🐛 What happened?

vscode 1.129.0 After startup, the model list only shows the default model, which is inconsistent with the output of opencode zen list. Additionally, the full list of Zen models sometimes flashes briefly before disappearing.

🔄 Steps to reproduce

1.It appears immediately upon startup.

✅ What did you expect?

Can pull and display the list normally

🖥️ Environment

• Extension version: 0.4.1
• VS Code version: 1.129.0
• Provider:
• Model: All

📸 Logs or screenshots (optional)

Could not fetch OpenCode Go model list. Using bundled model list. fetch failed
Could not fetch OpenCode Zen (Agents) model list. Using bundled model list. fetch failed

[ltmoerdani]

Thanks @leiyu1980. The "flashes briefly before disappearing" detail is what unblocked this, actually. I'd been reading #78 as a picker crash again, like the one we fixed in #53 last month. Wrong instinct.

Your symptom is something dumber and more boring: the network fetch at startup was fragile, and we never built it to fail gracefully.

Here's what I found in the code. Node's built-in fetch is undici under the hood, and undici's defaults are not friendly to a picker that needs to feel snappy. Headers can wait up to 300 seconds before timing out, and there's no connect timeout at all, so one flaky DNS lookup or a stale keep-alive socket at boot could either hang the picker for the full five minutes or silently drop it to the bundled list. VS Code 1.129's new agent host also spins up a lot more concurrent resolution calls into the provider than 1.128 did, which made the race surface more often. The undici maintainers consider this expected behavior, by the way. nodejs/undici#5450 is essentially the same bug report, closed with "use retries."

The shame is that the fix is obvious in hindsight. I should have written it this way the first time.

What changed in #80:

The fetch now hard-caps at 15 seconds per attempt. A hung TCP connection can no longer hold the picker hostage for five minutes. Then there are up to three retries with exponential backoff (500ms, 1s, 2s), but only for errors that are actually worth retrying: ECONNRESET, EAI_AGAIN, UND_ERR_CONNECT_TIMEOUT, HTTP 408/429/5xx, and the generic TypeError: fetch failed wrapper. HTTP 4xx and caller-side cancellation don't get retried, because retrying a bad API key or a cancelled resolution would just waste time.

Two smaller things came out of the same investigation. The User-Agent header was hardcoded as opencode-copilot-chat/0.3.6 while the actual extension version had moved to 0.4.1. Strict gateways can drop anonymous or stale-agent requests quietly, so the header now reads from package.json at runtime. And every successful fetch gets cached to globalState for one hour, so when all three retries fail the picker falls back to the last known-good list rather than the stale bundled snapshot. That last bit is what should actually kill the flash-then-disappear behavior you saw.

One honest caveat. If your network is blocking opencode.ai outright, corporate proxy, firewall, something configured at the OS level, none of this helps. The extension can't route around a hard block. In that case the lever is VS Code's http.proxy setting, not anything in our code.

To verify once it ships: turn off your network entirely and reload the window. Pre-fix, the picker would empty out or flash. Post-fix, it should stay populated from the one-hour cache, and the Output channel (filter by "OpenCode") will log [fetchModels] ... Using cached model list (...) instead of just dropping silently.

Two things from your end would help me confirm this actually solves your case rather than just papers over it:

1. What OS are you on, and is there a proxy, VPN, or corporate firewall between you and the open internet? The retry logic assumes the failure is transient. If it's a persistent block, we're solving the wrong problem.
2. After startup, if you run OpenCode Go: Refresh Models (or OpenCode Zen: Refresh Models) from the Command Palette, does the list eventually populate, or does it stay empty? If Refresh works but startup doesn't, that's a different signature than "always broken."

I'd rather know now if this is the wrong fix than ship it and have you reopen the issue next week.

PR is #80. Reviewer hasn't signed off yet, but the branch builds clean if you want to try it locally before release.

[leiyu1980]

Thanks so much for the incredibly detailed explanation and the swift fix in PR #80! It's truly impressive to see the thorough investigation and thoughtful improvements you've made.
To help you further validate the solution, here are the details you requested:
My setup: I'm on Windows 11, and I do use a VPN and am behind a corporate firewall. That said, I don't believe the network is a hard block, as I can still use the default model within "Opencode Go" without issues. The problem seems isolated to the model list refresh functionality.
Regarding the Refresh command: I checked the Command Palette thoroughly, but unfortunately, neither OpenCode Go: Refresh Models nor OpenCode Zen: Refresh Models appears to be available in my current version.
Given that the default model works, it sounds very much like the transient failure scenario you described, where the startup fetch is getting delayed or dropped, causing the "flash and disappear" behavior. I'm really looking forward to testing the new retry and caching logic once it's released!
Thanks again for your dedication to resolving this.

[ltmoerdani]

@leiyu1980 Two things, and the first is me walking back something I told you.

When I asked you to run OpenCode Go: Refresh Models from the Command Palette, that command didn't exist. Not under that name. It was a sub-item inside OpenCode Go: Manage Provider, and Zen didn't have a Manage Provider command at all. So you'd have searched the palette forever. You were right to push back, and that pushback is what surfaced the gap.

PR #81 now registers three top-level commands: OpenCode Go: Refresh Models, OpenCode Zen: Manage Provider, OpenCode Zen: Refresh Models. They skip the Manage menu and go straight to a fresh fetch. The next time the picker looks stale, the command you'd instinctively type will actually be there.

The second thing. Your environment info didn't just confirm the bug, it broke my theory of the bug.

I'd written up #78 as transient socket reuse, the undici race that the maintainers themselves call expected behavior. But you said POST requests to /chat/completions were going through fine while GET /models was getting dropped, on the same host. That signature doesn't fit socket reuse. It fits something dumber: SSL-inspecting corporate proxies like Zscaler, Netskope, and Fortinet treat anonymous GETs with no Accept or Content-Type as scanner traffic and silently drop them, even on allow-listed hosts. POSTs with a JSON content type look like real API calls and pass.

The fetch now sends an explicit Accept: application/json header. Small change. Combined with the retry and the one-hour cache from the first commit, it should cover your case whether the cause is the proxy, the VPN tunnel still warming up at boot, the undici race, or some mix of all three. I'm hedging on "should" deliberately.

If you want to test before release, the branch is fix/issue-78-model-list-fetch-resilience and the version is 0.4.2. Side-loading a .vsix is the fastest path. The two signals I'd look for:

After install, run OpenCode Zen: Refresh Models from the Command Palette. A toast saying "OpenCode Zen models refreshed" means the firewall theory was right, and the picker should stay populated. If it still fails, open the Output panel, filter by "OpenCode", and paste back the line that starts with [fetchModels] OpenCode Zen:. That line will tell me whether the request timed out, got rejected with a status code, or hit the retry path. Each of those points at a different layer and a different fix.

I'm holding the PR as a draft until you've verified. If it works, I'll mark it ready and ship. If it doesn't, I'd rather find out now than read about it in a reopened issue next week.

Your report is doing real work. The Windows plus VPN plus corporate firewall combo is exactly the configuration I can't reproduce from here, so the back-and-forth is genuinely how this got pinned down.

[leiyu1980]

I'm currently using version 0.4.3. The Opencode Zen model list no longer flickers and displays the model list stably. However, for some unknown reason, it only shows the Free models. I've already topped up 20 dollars on Zen and enabled some paid models in the Zen control panel.