Self-Review Checklist:
- [x] I've reviewed my own diff for quality, security, and reliability
- [x] Unsafe blocks (if any) have justifying comments
- [ ] 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
## Summary
Adding an OpenRouter API key did not populate the model list until the
app was
restarted. `set_api_key` stored the credential but never triggered a
model
fetch, so until re-authentication happened (on restart or a settings
change)
the picker showed only the user-configured `settings.available_models`,
not the
models returned by the OpenRouter API.
This makes `set_api_key` refresh the models right after the key is
stored,
mirroring how `authenticate` already does it.
## Changes
- `set_api_key` awaits the credential store and then calls
`restart_fetch_models_task`, so the API model list loads immediately
after a
key is entered (and is cleared when the key is removed).
- `fetch_models` now maps `list_models` errors via
`LanguageModelCompletionError::from`, preserving the real OpenRouter
error
message instead of wrapping it in a generic `Other(...)`.
Release Notes:
- Fixed OpenRouter models not appearing until restart after adding an
API key
Signed-off-by: Zhiwei Liang <zhiwei.liang@zliang.me>
Closes#58305
OpenAI sunset GPT-5.2 and GPT-5.3-Codex in Codex for ChatGPT account
logins on June 2nd, so sending to them via the ChatGPT Subscription
provider now fails with error. This PR removes those models from ChatGPT
Subscription model list.
Release Notes:
- Removed the retired GPT-5.2 and GPT-5.3 Codex models from the ChatGPT
Subscription provider.
Add a `custom_headers` setting to each HTTP-based language model
provider
(Anthropic, Bedrock, DeepSeek, Google, LM Studio, Mistral, Ollama,
OpenAI,
OpenAI-compatible, OpenCode, OpenRouter, Vercel AI Gateway, and xAI) so
users
can attach extra headers to every outgoing request. Headers managed by
Zed
(authentication, content-type, etc.) cannot be overridden and are
skipped with
a warning.
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
Release Notes:
- Added support for configuring custom HTTP headers on language model
providers via `language_models.<provider>.custom_headers`.
Signed-off-by: Aurabindo Pillai <mail@aurabindo.in>
This primarily
- requires components to have a description as well as a preview
(especially having no preview makes no sense)
- implements some basic previews where missing
- adds a scrollbar to the preview navigation
with a sadly large diff due to reformatting (less indentation 🎉 ), but
very little changes at its core.
Release Notes:
- N/A
<img width="627" height="752" alt="Screenshot 2026-05-28 at 1 20 22 PM"
src="https://github.com/user-attachments/assets/0a7825f0-73c5-49e9-b59a-83924a45de98"
/>
Adds Claude Opus 4.8 for BYOK providers, including Anthropic fast-mode
handling and Bedrock/OpenCode model definitions.
Closes AI-336
Release Notes:
- Added Claude Opus 4.8 BYOK support
## Summary
This started from #57636, after we saw ChatGPT subscription/Codex
requests stall over the past week. OpenCode v1.15.11 shipped related
resilience fixes for the same class of Codex subscription endpoint
issues, so this ports the relevant pieces into Zed's native ChatGPT
subscription provider.
When Zed asks ChatGPT/Codex for a response, sometimes the server
connection can get stuck before it even sends the first response
headers. Before this PR, Zed could wait indefinitely, which looks like
OpenCode/Zed “stalling.”
This PR makes Zed:
- Wait up to 10 seconds for the server to start responding.
- If nothing comes back in that window, treat it as a temporary
network/API failure.
- Let the existing retry logic try again instead of leaving the user
stuck.
- Send a stable session-id header so OpenAI’s Codex backend can
associate requests with the same Zed agent thread.
- Add tests to make sure:
- stuck-before-response requests time out,
- normal slow streaming responses are not cut off,
- ChatGPT subscription requests send the right session header,
- the agent retries this kind of failure.
intended user-facing result is: fewer “the assistant is just sitting
there forever” failures when using ChatGPT subscription models.
## Verification
- cargo test -p open_ai responses
- cargo test -p language_models openai_subscribed
- cargo test -p agent test_send_retry_on_http_send_error
- cargo check -p open_ai
- cargo check -p language_models
- cargo check -p agent
Release Notes:
- Fixed ChatGPT subscription requests stalling indefinitely before
response headers arrive.
Until now, the cloud-hosted model list was only refreshed in response to
events that exercise the LLM token (a `UserUpdated` push, an
organization change, or `PrivateUserInfoUpdated`). If a user wasn't
actively using AI features around the time we shipped new models, the
list could stay stale until they restarted Zed.
This is the second step toward fixing that, after #57078 made the cloud
websocket reconnect on its own. We now treat each successful (re)connect
as a hint that the server state may have changed, so possibly new model
definitions will be available, and trigger a model list refresh.
The trigger is a new `Client::cloud_connection_id()` watch that bumps a
counter each time the websocket handshake completes.
`CloudLanguageModelProvider::State` subscribes to it and, on every tick
after the initial `0`, schedules a debounced refresh (with jitter, so we
don't have all active clients trying to reconnect at the same time after
we deploy in cloud).
Closes CLO-713.
Release Notes:
- The list of Zed hosted models is now refreshed automatically, without
requiring a restart
It look like this:
<img width="1698" height="688" alt="grafik"
src="https://github.com/user-attachments/assets/02a37271-63d3-42da-887f-e17b31e8d9ca"
/>
The idea is to avoid people turning on fast mode without understanding
the financial implications. It also clarifiers (in the BYOK case) why
they might not see a difference between fast mode enabled and disabled.
Release Notes:
- N/A
---------
Co-authored-by: Danilo Leal <daniloleal09@gmail.com>
Co-authored-by: zed-zippy[bot] <234243425+zed-zippy[bot]@users.noreply.github.com>
Same mechanism as for BYOK: `service_tier == priority`. Most of the work
is already done. When validating this in manual testing, I noticed we
get back `service_tier == auto` in the response, unlike in the regular
OpenAI API scenario with BYOK, but apparently [it doesn't mean priority
tier wasn't
applied](https://github.com/openai/codex/issues/14204#issuecomment-4033184620).
It's not a hard confirmation, but the model does seem to respond faster
when I toggle fast mode on.
Release Notes:
- Added Fast Mode (priority service tier) support to OpenAI models used
through the ChatGPT subscription provider.
Maps the existing `Speed::Fast` plumbing to OpenAI's `service_tier:
"priority"`, which matches what "fast mode" in Codex does. Relevant docs
[here](https://platform.openai.com/docs/api-reference/chat/create#chat-create-service_tier).
Like for the existing Anthropic fast mode we have a
`Model::supports_priority` method for the variants on
https://openai.com/api-priority-processing. Pro, nano, and legacy gpt-4
are excluded; Custom defaults to false.
This is gated to staff only for now (not in this diff, but the existing
fast mode feature), until we have the mechanism to require confirmation
before you enable fast mode.
Release Notes:
- Added support for Fast Mode (priority service tier) on the OpenAI API
provider.
For long threads we will spend more and more time cloning the messages
just to save them to the database, as we need a copy of everything to do
so asynchronously. Messages are really expensive to clone though and we
accumulate a lot of them really fast, so even for smaller threads we
start seeing pauses in the millisecond range. The fix to this is fairly
simple though, we never mutate the messages once pushed to the vec, so
just Arc them.
This PR also slightly changes `UserMessage` to be a bit faster to clone
as well.
Release Notes:
- Fixed a cause of stutters when interacting with the agent
Also makes sure we are properly catching and processing thinking events.
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)
- [x] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
Release Notes:
- google: Support thinking levels for Google models.
We were storing reasoning output inside `RedactedThinking` which causes
issues when switching mid-turn from an OpenAI to an Anthropic model.
This implementation fixes this by storing it inside `reasoning_details`,
which matches our responses implementation in `open_ai.rs`
See
https://github.com/microsoft/vscode-copilot-chat/blob/main/src/platform/endpoint/node/responsesApi.ts
For whatever reason the copilot chat extension sets `summary: []`, this
is what our implementation does too
Closes#56385
Release Notes:
- Fixed an issue where the agent would error when using Copilot as a
provider and switching between OpenAI and Anthropic models
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)
- [x] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
Closes: #56857 Title generation failing on agent threads with OpenAI
models from subscription
Currently title generation requests are made without any system prompt
which causes instructions to be not set, and the request fails. This
change makes sure there is always instructions set (api does not seem to
care if its empty or not)
Release Notes:
- N/A
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)
- [x] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
Closes: #56844
Release Notes:
- Added support for specifying effort level when using OpenAI models via
ChatGPT subscription
Adds a new language model provider that lets users authenticate with
their ChatGPT Plus/Pro subscription and use OpenAI models
(codex-mini-latest, o4-mini, o3) directly in the Zed agent — without
needing a separate API key.
## How it works
1. **OAuth 2.0 + PKCE sign-in**: Uses OpenAI's official Codex CLI client
ID to run an authorization code flow. A local HTTP server on
`127.0.0.1:1455` captures the callback, exchanges the code for tokens,
and stores them in the system keychain.
2. **Token refresh**: Access tokens are automatically refreshed when
they're within 5 minutes of expiry, using the stored refresh token.
3. **Responses API**: Requests go to
`https://chatgpt.com/backend-api/codex/responses` using the existing
`open_ai::responses` client (Responses API format, not Chat Completions
which was deprecated for this endpoint in Feb 2026).
4. **Required headers**: `originator: zed`, `OpenAI-Beta:
responses=experimental`, `ChatGPT-Account-Id` (extracted from JWT),
`store: false` in the body.
## Files changed
- `crates/open_ai/src/responses.rs`: Add `store: Option<bool>` field to
`Request`; add `extra_headers` param to `stream_response` for
per-provider header injection
- `crates/language_models/src/provider/openai_subscribed.rs`: New
provider (sign-in UI, OAuth flow, token storage/refresh, model list)
- `crates/language_models/src/provider/open_ai.rs`,
`open_ai_compatible.rs`, `opencode.rs`: Pass `vec![]` for new
`extra_headers` param
- `crates/language_models/src/language_models.rs`: Register the new
provider
- `crates/language_models/Cargo.toml`: Add `rand` and `sha2` deps for
PKCE
## Open questions / known gaps
- [ ] **Terms of service**: Usage appears to be within OpenAI's ToS
(interactive use via their official CLI client ID), but needs legal
sign-off before shipping
- [ ] **Redirect URI**: Currently `http://localhost:1455/auth/callback`
— may need to match exactly what OpenAI's Codex CLI uses
- [ ] **UI polish**: The sign-in card is functional but minimal; needs
design review
- [ ] **Error messages**: OAuth error responses from the callback URL
aren't surfaced to the user yet
- [ ] **`o3` availability**: o3 may require a higher subscription tier;
consider gating it
## Testing
Sign-in flow was designed to match the Copilot Chat provider pattern.
Manual testing against the live OAuth endpoint is needed.
Release Notes:
- Added ChatGPT subscription provider, allowing users to use their
ChatGPT Plus/Pro subscription with the Zed agent
---------
Co-authored-by: Zed Zippy <234243425+zed-zippy[bot]@users.noreply.github.com>
Co-authored-by: Richard Feldman <richard@zed.dev>
Co-authored-by: Richard Feldman <oss@rtfeldman.com>
Co-authored-by: Agus Zubiaga <agus@zed.dev>
#56472 broke Copilot chat
> Failed to connect to API: 400 Bad Request {"message":"cache_control:
Extra inputs are not permitted"}
This PR makes it so that we still use the legacy caching approach for
Copilot
Release Notes:
- N/A
The Bedrock Converse API supports placing `CachePoint` blocks inside the
`system` field, but we were sending the system prompt as a single
`SystemContentBlock::Text`, which leaves the system tokens dependent on
whatever message-level breakpoint happens to fall within the 20-block
lookback window.
This widens `bedrock::Request.system` from `Option<String>` to
`Vec<BedrockSystemContentBlock>` and has `into_bedrock` emit
`[Text(system), CachePoint(Default)]` whenever the model supports prompt
caching. The system prompt now anchors its own cache prefix, on top of
the existing tool-list anchor and per-message breakpoint, so a stable
system prompt keeps producing cache hits even when earlier conversation
turns change.
Bedrock does not support automatic caching or the 1-hour TTL, so the
default 5-minute ephemeral cache is the only option for this provider.
Release Notes:
- Improved Bedrock prompt cache utilization by anchoring the system
prompt as its own cache prefix
Code had been assuming (erroneously, but understandably) that
LlmApiToken::acquire would give them a valid token.
This is not true, as those tokens expire and you must call refresh
explicitly.
Add some helpers to do the retry for you, and rename acquire to cached
to be
clearer about the intent.
Closes #ISSUE
Release Notes:
- Fixed some rare cases where API requests would fail with Unauthorized
## Background: Amazon Bedrock Guardrails
AWS Bedrock Guardrails enables configurable safety and compliance
controls for generative AI applications:
- Evaluates both user inputs and model responses against policies.
:contentReference[oaicite:8]{index=8}
- Can block or filter content based on harmful categories, denied
topics, PII, or hallucination criteria.
:contentReference[oaicite:9]{index=9}
- Guardrails are applied during inference API calls by specifying
`guardrailIdentifier` and `guardrailVersion` in the request.
:contentReference[oaicite:10]{index=10}
Relevant AWS documentation:
- User Guide:
https://docs.aws.amazon.com/bedrock/latest/userguide/guardrails.html
- How Guardrails Works:
https://docs.aws.amazon.com/bedrock/latest/userguide/guardrails-how.html
- API Reference (GuardrailConfiguration):
https://docs.aws.amazon.com/bedrock/latest/APIReference/API_GuardrailConfiguration.html
Some AWS environments enforce IAM policies that require a guardrail to
be specified on every Bedrock API call (via a `StringEquals` condition
on `bedrock:GuardrailIdentifier`). Without this, Zed returns
`AccessDenied` and Bedrock models are completely unusable in those
environments.
This adds two optional settings, `guardrail_identifier` and
`guardrail_version`, to the Bedrock provider config. When set, a
`GuardrailStreamConfiguration` is attached to every `converse_stream`
request. When unset, behaviour is identical to before.
```json
{
"language_models": {
"bedrock": {
"guardrail_identifier": "arn:aws:bedrock:us-east-1:123456789012:guardrail/abc123",
"guardrail_version": "DRAFT"
}
}
}
```
`guardrail_version` defaults to `"DRAFT"` if omitted.
Release Notes:
- agent: Added `guardrail_identifier` and `guardrail_version` settings
for AWS Bedrock, enabling use in environments where IAM policies require
a guardrail on all model requests
---------
Co-authored-by: Bennet Bo Fenner <bennetbo@gmx.de>
Most compelling reason to make this change is that we don't have to ship
a new Zed binary if Anthropic releases a new model
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)
- [x] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
Release Notes:
- anthropic: Dynamically fetch available models from Anthropic API
---------
Co-authored-by: Ben Brandt <benjamin.j.brandt@gmail.com>
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)
- [x] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
Closes#55998
Release Notes:
- ollama: Fixed issue where specifying `auto_discover: false` would
still auto discover models
"msg.string_contents();" return more than just content. It also return
tool result (which need special handling, and should be emitted from the
tool role) and thinking (which need already implemented special
handling).
This resulted in thinking being sent as content, which apparently
ollama’s gemma4 parser didn’t handled well, and caused a number of issue
that manifested by 1. outputting end of though token where unappropriate
and 2. repeating things endlessly
Self-Review Checklist:
- [x] I've reviewed my own diff for quality, security, and reliability
- [x] Unsafe blocks (if any) have justifying comments
- [ ] The content is consistent with the [UI/UX
checklist](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
(no UI/UX impact)
- [ ] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable (a quick
review, without benchmark, show that this should be at least as fast as
the previous code. This is called only exceptionally anyway.)
Closes#55537
Release Notes:
- Fixed "thinking" text being badly formatted when sent to Ollama
Self-Review Checklist:
- [x] 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](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
- [x] Tests cover the new/changed behavior
- [ ] Performance impact has been considered and is acceptable
Release Notes:
- Mistral: Added Ministral 3 models and removed deprecated models
---------
Signed-off-by: Gabriel Linder <linder.gabriel@gmail.com>
OpenCode API endpoints for DeepSeek were [moved from
Anthropic-compatible to
OpenAI-compatible](https://github.com/anomalyco/opencode/pull/24500) and
DeepSeek requires interleaved reasoning enabled to work. I ran a
_"rename this variable to potato"_ test and I can confirm DeepSeek V4
Flash and Pro both work now 🎉
Some other OpenCode Go models were marked [on
models.dev](https://github.com/anomalyco/models.dev/tree/dev/providers/opencode-go/models)
as supporting `interleaved_reasoning` so they too got that enabled. Kimi
K2.5 and Kimi K2.6 continue to fail with
https://github.com/zed-industries/zed/issues/51743
(https://github.com/zed-industries/zed/pull/55085 seems to hint at this
being [an OpenCode
issue](https://github.com/zed-industries/zed/issues/51743#issuecomment-4336785765)?),
but all other models seem to work fine both with `interleaved_reasoning`
and without it 🤷 I assume it's better to have that turned on? Again, the
intersection of OpenAI Chat Completions API, different models, different
inference providers, how they all work together is something I know
nothing about!
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
Release Notes:
- OpenCode Go: use correct DeepSeek endpoints
- OpenCode: add support for interleaved_reasoning
Follow up to #54826, after which the fallback model would be selected
instead of the cloud model when starting Zed
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)
- [x] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
Release Notes:
- N/A
Removes the Vercel v0 Provider, as the v0 API has been
depredated/removed (https://api.v0.dev/v1)
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
Release Notes:
- agent: Removed Vercel v0 provider as it has been deprecated by Vercel
Leftovers after https://github.com/zed-industries/zed/pull/53651
Updated models:
- **Zen**: GPT 5.5 and GPT 5.5 Pro - not tested because I don't have a
Zen subscription and I stubbornly refuse to get one
- **Go**: DeepSeek V4 Pro and DeepSeek V4 Flash - failing due to
https://github.com/anomalyco/opencode/issues/24224
- **Go**: MiMo V2.5 and MiMo V2.5 Pro - tested, confirmed working
- **Free**: Ling 2.6 Flash, [available for "a limited
time"](https://x.com/opencode/status/2046717718028513694) - tested,
confirmed working
- **Free**: Hy3 Preview, [available until May
8](https://x.com/opencode/status/2047328981435756824) - tested,
confirmed working
When testing the new models and comparing with OpenCode CLI, I realized
the
[variants](https://opencode.ai/docs/models/#built-in-variants)/thinking
effort configuration was not supported by the Zed Agent implementation.
I added that for OpenCode Go models, after manually checking what each
model supports in OpenCode. Reasoning levels and everything seems to
work (UI looks good, model works) but I have no idea how to specifically
test reasoning levels without doing a full benchmark 🤷
I did not add the same thing for OpenCode Zen models because I could not
figure out a way to get the supported variants.
@benbrandt let me know if you want me to take this out of this PR and to
keep just the model updates!
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
Release Notes:
- OpenCode: add new models (GPT 5.5, DeepSeek V4, MiMo V2.5, Ling 2.6,
Hy3)
- OpenCode Go: add support for configurable reasoning effort levels
---------
Co-authored-by: Ben Brandt <benjamin.j.brandt@gmail.com>
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)
- [x] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
Closes #ISSUE
Release Notes:
- N/A
From the
[docs](https://developers.openai.com/api/docs/guides/migrate-to-responses#responses-benefits):
> Better performance: Using reasoning models, like GPT-5, with Responses
will result in better model intelligence when compared to Chat
Completions. Our internal evals reveal a 3% improvement in SWE-bench
with same prompt and setup.
Agentic by default: The Responses API is an agentic loop, allowing the
model to call multiple tools, like web_search, image_generation,
file_search, code_interpreter, remote MCP servers, as well as your own
custom functions, within the span of one API request.
Lower costs: Results in lower costs due to improved cache utilization
(40% to 80% improvement when compared to Chat Completions in internal
tests).
Stateful context: Use store: true to maintain state from turn to turn,
preserving reasoning and tool context from turn-to-turn.
Flexible inputs: Pass a string with input or a list of messages; use
instructions for system-level guidance.
Encrypted reasoning: Opt-out of statefulness while still benefiting from
advanced reasoning.
Future-proof: Future-proofed for upcoming models.
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
Closes #ISSUE
Release Notes:
- Always use Responses API for OpenAI models
This PR fixes an issue introduced in
https://github.com/zed-industries/zed/pull/54397 where the Zed Cloud
provider would not be reflected as "authenticated" if a connection to
Collab was attempted, but could not be established.
This was especially noticable when running Zed against a local version
of Cloud and not having Collab running.
This restores the original logic prior to that change.
Release Notes:
- N/A
**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>
## Summary
Users who add custom OpenAI models under
`language_models.openai.available_models` can set `capabilities.images:
true` to declare that the endpoint accepts image inputs. Today, that
setting is silently ignored: the Agent panel's image-attach button stays
disabled regardless, and the only workaround is to switch to a built-in
OpenAI model, attach the image, and switch back.
Root cause: `Model::Custom` does not carry a `supports_images` field,
and the OpenAI provider's `supports_images()` for the `Custom` arm
hardcodes `false`.
## Changes
1. `crates/settings_content/src/language_model.rs`: add `images: bool`
to `OpenAiModelCapabilities` with `#[serde(default)]` so existing
settings.json files keep working unchanged.
2. `crates/open_ai/src/open_ai.rs`: add `supports_images: bool` to
`Model::Custom` with a matching serde default.
3. `crates/language_models/src/provider/open_ai.rs`: pass
`model.capabilities.images` into the `Model::Custom` variant in
`provided_models`, and return the stored value from `supports_images()`
for `Custom`.
Existing `Model::Custom { .. }` match sites (`completion.rs:829`,
various in `open_ai.rs`) all use `..` so they continue to compile
without change.
## Testing
- `cargo check -p settings_content -p open_ai -p language_models`:
clean.
- I was not able to complete `./script/clippy` locally: the build
stalled on the first-time `webrtc-sys` download for livekit-rust-sdks
(TLS close_notify failure on docs.rs mirror). Happy to rerun once CI has
cached artifacts.
- Manually verified the capability plumbing by tracing: settings.json ->
`OpenAiModelCapabilities.images` -> `Model::Custom { supports_images }`
-> `supports_images()` -> `Thread::prompt_capabilities` ->
`SessionCapabilities.supports_images()` -> `build_add_context_menu` gate
in `thread_view.rs`.
## Related Issues
Closes#50752
Release Notes:
- Fixed custom OpenAI models ignoring the `capabilities.images` setting
in `language_models.openai.available_models`.
This contribution was developed with AI assistance (Codex).
---------
Co-authored-by: Matt Van Horn <455140+mvanhorn@users.noreply.github.com>
No, sadly, the title is not a typo. See
https://www.githubstatus.com/incidents/zsg1lk7w13cf for the context.
I'll read with joy and popcorn through that root cause analysis.
It makes literally zero sense what happened here, but for some completly
bonkers reason GitHub completely messed up the merge queue with
https://github.com/zed-industries/zed/pull/54632.
I have no idea how it happened. It makes literally zero sense. A PR
going into the merge queue should have the same LoC when getting out of
it. GitHub obviously does not check this. GitHub causes extra work with
a feature that is supposed to save time.
Thanks, I guess.
Release Notes:
- N/A
---------
Co-authored-by: Danilo Leal <daniloleal09@gmail.com>
Zhiwei Liang