**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: - [x] I've reviewed my own diff for quality, security, and reliability - [x] Unsafe blocks (if any) have justifying comments - [x] The content is consistent with the [UI/UX checklist](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist) - [ ] Tests cover the new/changed behavior - [x] 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](https://opencode.ai/zen) subscription. These models use the same OpenCode Zen API endpoints. - **flat-rate monthly access to 7 models** as part of the [OpenCode Go](https://opencode.ai/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](https://opencode.ai/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! <br> https://github.com/zed-industries/zed/pull/49589 added support for OpenCode Zen by implementing a new `opencode` provider. OpenCode Go [could be used by overriding the API URL](https://github.com/zed-industries/zed/pull/49589#issuecomment-4130300454), 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: <img width="434" height="176" alt="Screenshot showing the OpenCode provider configuration, with the newly added toggles" src="https://github.com/user-attachments/assets/3520e114-00c8-4794-84bf-35cd72d9c57e" /> 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 --------- Co-authored-by: Ben Brandt <benjamin.j.brandt@gmail.com> |
||
|---|---|---|
| .. | ||
| .conventions | ||
| .doc-examples | ||
| src | ||
| theme | ||
| .gitignore | ||
| .prettierignore | ||
| .prettierrc | ||
| .rules | ||
| AGENTS.md | ||
| book.toml | ||
| README.md | ||
Zed Docs
Welcome to Zed's documentation.
This is built on push to main and published automatically to https://zed.dev/docs.
To preview the docs locally you will need to install mdBook (cargo install mdbook@0.4.40), generate the action metadata, and then serve:
script/generate-action-metadata
mdbook serve docs
The first command dumps an action manifest to crates/docs_preprocessor/actions.json. Without it, the preprocessor cannot validate keybinding and action references in the docs and will report errors. You only need to re-run it when actions change.
It's important to note the version number above. For an unknown reason, as of 2025-04-23, running 0.4.48 will cause odd URL behavior that breaks things.
Before committing, verify that the docs are formatted in the way Prettier expects with:
cd docs && pnpm dlx prettier@3.5.0 . --write && cd ..
Preprocessor
We have a custom mdBook preprocessor for interfacing with our crates (crates/docs_preprocessor).
If for some reason you need to bypass the docs preprocessor, you can comment out [preprocessor.zed_docs_preprocessor] from the book.toml.
Images and videos
To add images or videos to the docs, upload them to another location (e.g., zed.dev, GitHub's asset storage) and then link out to them from the docs.
Putting binary assets such as images in the Git repository will bloat the repository size over time.
Internal notes:
- We have a Cloudflare router called
docs-proxythat intercepts requests tozed.dev/docsand forwards them to the "docs" Cloudflare Pages project. - The CI uploads a new version to the Cloudflare Pages project from
.github/workflows/deploy_docs.ymlon every push tomain.
Table of Contents
The table of contents files (theme/page-toc.js and theme/page-doc.css) were initially generated by mdbook-pagetoc.
Since all this preprocessor does is generate the static assets, we don't need to keep it around once they have been generated.
Referencing Keybindings and Actions
When referencing keybindings or actions, use the following formats:
Keybindings
{#kb scope::Action} - e.g., {#kb zed::OpenSettings}.
This will output a code element like: <code>Cmd + , | Ctrl + ,</code>. We then use a client-side plugin to show the actual keybinding based on the user's platform.
By using the action name, we can ensure that the keybinding is always up-to-date rather than hardcoding the keybinding.
Keymap Overlays
{#kb:keymap_name scope::Action} - e.g., {#kb:jetbrains editor::GoToDefinition}.
This resolves the keybinding from a keymap overlay (e.g., JetBrains) first, falling back to the default keymap if the overlay doesn't define a binding for that action. This is useful for sections where the documentation expects a special base keymap to be configured.
Supported overlays: jetbrains.
Actions
{#action scope::Action} - e.g., {#action zed::OpenSettings}.
This will render a human-readable version of the action name, e.g., "zed: open settings", and will allow us to implement things like additional context on hover, etc.
Creating New Templates
Templates are functions that modify the source of the docs pages (usually with a regex match and replace).
You can see how the actions and keybindings are templated in crates/docs_preprocessor/src/main.rs for reference on how to create new templates.
Consent Banner
We pre-bundle the c15t package because the docs pipeline does not include a JS bundler. If you need to update c15t and rebuild the bundle, use:
mkdir c15t-bundle && cd c15t-bundle
npm init -y
npm install c15t@<version> esbuild
echo "import { getOrCreateConsentRuntime } from 'c15t'; window.c15t = { getOrCreateConsentRuntime };" > entry.js
npx esbuild entry.js --bundle --format=iife --minify --outfile=c15t@<version>.js
cp c15t@<version>.js ../theme/c15t@<version>.js
cd .. && rm -rf c15t-bundle
Replace <version> with the new version of c15t you are installing. Then update book.toml to reference the new bundle filename.
References
- Template Trait:
crates/docs_preprocessor/src/templates.rs - Example template:
crates/docs_preprocessor/src/templates/keybinding.rs - Client-side plugins:
docs/theme/plugins.js
Postprocessor
A postprocessor is implemented as a sub-command of docs_preprocessor that wraps the built-in HTML renderer and applies post-processing to the HTML files, to add support for page-specific title and meta tag description values.
An example of the syntax can be found in git.md, as well as below:
---
title: Some more detailed title for this page
description: A page-specific description
---
# Editor
The above code will be transformed into (with non-relevant tags removed):
<head>
<title>Editor | Some more detailed title for this page</title>
<meta name="description" contents="A page-specific description" />
</head>
<body>
<h1>Editor</h1>
</body>
If no front matter is provided, or if one or both keys aren't provided, the title and description will be set based on the default-title and default-description keys in book.toml respectively.
Implementation details
Unfortunately, mdBook does not support post-processing like it does pre-processing, and only supports defining one description to put in the meta tag per book rather than per file.
So in order to apply post-processing (necessary to modify the HTML head tags) the global book description is set to a marker value #description# and the HTML renderer is replaced with a sub-command of docs_preprocessor that wraps the built-in HTML renderer and applies post-processing to the HTML files, replacing the marker value and the <title>(.*)</title> with the contents of the front matter if there is one.
Known limitations
The front matter parsing is extremely simple, which avoids needing to take on an additional dependency, or implement full YAML parsing.
- Double quotes and multi-line values are not supported, i.e. Keys and values must be entirely on the same line, with no double quotes around the value.
The following will not work:
---
title: Some
Multi-line
Title
---
neither this:
---
title: "Some title"
---
- The front matter must be at the top of the file, with only white-space preceding it.
- The contents of the
titleanddescriptionwill not be HTML escaped. They should be simple ASCII text with no unicode or emoji characters.