opencode: Add support for OpenCode Go

[Vlaaaaaaad]

TL;DR: add support for OpenCode Go (flat-rate monthly subscription) along the already-implemented OpenCode Zed (pay-as-you-go billing).

Warning

This code was written by LLMs, under the supervision of a so-called developer that never wrote Rust profesionally and that spends more time in Pages&Keynote than in an IDE.

Self-Review Checklist:

• I've reviewed my own diff for quality, security, and reliability
• Unsafe blocks (if any) have justifying comments
• The content is consistent with the UI/UX checklist
• Tests cover the new/changed behavior
• Performance impact has been considered and is acceptable

Background

OpenCode offers a few different ways to access models:

• free access to 3 models, with feedback and data used to improve the model. These models use the OpenCode Zen API endpoints, but have different usage limits (200 requests per 5 hours) and have a different privacy policy. Some people disable or block the free models, some people are super-excited to have access to LLMs for free, and some people like using the free models to test new LLMs (at launch MiMo-V2 had 2 free weeks of usage, for example).
• pay-as-you-go access to 30 models as part of the OpenCode Zen subscription. These models use the same OpenCode Zen API endpoints.
• flat-rate monthly access to 7 models as part of the OpenCode Go subscription. These models use the OpenCode Zen API endpoints with an extra /go appended to the path. There are 5-hour, weekly, and monthly usage limits and, additionally, users can toggle a switch in the OpenCode Console to use Zen models with their pay-as-you-go billing after the Go limits are hit.

There's also a currently-paused OpenCode Black flat-rate subscription with way higher usage limits and with access to more models, with $100 and $200 monthly plans.

The whole thing is a bit messy, but it's great value and highly reliable LLM access!

#49589 added support for OpenCode Zen by implementing a new opencode provider. OpenCode Go could be used by overriding the API URL, but that is a terrible user experience: some models have to be manually added, the model list always shows the 30-something OpenCode Zen models, and free models cannot be used at all.

I was annoyed by the experience of using OpenCode Go with Zed and this past week I had to test a bunch of LLMs and providers and harnesses, so I took this on as a test case 🙂

Implementation

This PR makes the OpenCode provider more general (not just for Zen) and adds an OpenCodeModelSubscription concept which is then used to implement support for OpenCode Go. The free models are also broken out into their own subscription for a prettier model list.

For a better user experience, the different subscriptions can be enabled or disabled, both in the settings file and in the UX:

The code was written by LLMs, but I do understand it and I did a bunch of "manual" iterations and "manual" tweaks. Still, my Rust experience is non-existent so I won't feel offended if y'all reject this PR! I did consider alternatives (adding a new opencode-go provider and renaming this to opencode-zen, for example, or adding support for custom API URLs in OpenCode custom models which would've been the smallest code change but a terrible user experience, and so on) but all alternatives would have been, in my opinion, a worse user experience.

Tests I did:

• confirmed OpenCode Go models work as expected
• confirmed OpenCode Zen Free models work as expected
• confirmed I get an error when trying to use OpenCode Zen models since I don't have that subscription
• confirmed the subcription toggles work as expected (model are shown/hidden, settings file is updated)

Notes:

• this PR is best reviewed commit-by-commit. I did not create a separate PR for the model updates to minimize delays
• my exeprience with Rust is roughly zero, but I tried to strike a balance between idiomatic Rust and easy-to-read code
• users of the OpenCode provider might have to do some re-configuration after this PR is merged since the model identifiers now include the subscription, eg claude-haiku-4-5 is now zen/claude-haiku-4-5. Since this is a relatively new provider and the impact is small, I preffered that rather than adding complex migration/mapping logic.
• does changing the provider name from "OpenCode Zen" to "OpenCode" break anything for y'all at Zed?
• does changing the telemetry id from "opencode/<model-id>" to "opencode/<subscription>/<model-id>" break anything for y'all at Zed?

---

Release Notes:

• OpenCode provider: add support for OpenCode Go