# Objective
- Adds the three GPT-5.6 models (Sol, Terra, and Luna) that OpenAI now
serves through AWS Bedrock's `bedrock-mantle` endpoint, so they can be
selected as built-in models under the Amazon Bedrock provider.
- Follows up on the native Bedrock Mantle support added in #60480.
- Addresses the feature request in
https://github.com/zed-industries/zed/discussions/61003.
## Solution
- Adds `Gpt5_6Sol`, `Gpt5_6Terra`, and `Gpt5_6Luna` variants to
`MantleModel` in `crates/bedrock/src/models.rs`, with per-model
`id`/`request_id`/`display_name` and shared capability arms.
- All three are Responses-API, `bedrock-mantle`-only models, so they
reuse the existing Mantle request/response plumbing, region gating,
bearer-token auth, and model-picker wiring (`MantleModel::iter()`) with
no other changes required.
- Metadata mirrors the AWS Bedrock model cards
([Sol](https://docs.aws.amazon.com/bedrock/latest/userguide/model-card-openai-gpt-56-sol.html),
[Terra](https://docs.aws.amazon.com/bedrock/latest/userguide/model-card-openai-gpt-56-terra.html),
[Luna](https://docs.aws.amazon.com/bedrock/latest/userguide/model-card-openai-gpt-56-luna.html)):
272K context window, image input, tool and thinking support, and
`openai.gpt-5.6-{sol,terra,luna}` request IDs.
- Updates the Amazon Bedrock section of "Use a Gateway" to mention the
GPT-5.6 family.
## Testing
- `cargo test -p bedrock` — adds `test_gpt_5_6_mantle_model_metadata`
and extends `test_builtin_mantle_models_use_responses_protocol`; all
pass.
- `cargo test -p language_models mantle` — the consumer crate compiles
and all Mantle tests pass.
- `./script/clippy -p bedrock` passes with no new warnings; docs pass
`prettier --check`.
## Self-Review Checklist:
- [x] I've reviewed my own diff for quality, security, and reliability
- [x] Unsafe blocks (if any) have justifying comments — N/A, no unsafe
code
- [x] The content adheres to Zed's UI standards — N/A, no UI change
- [x] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
---
Release Notes:
- Added GPT-5.6 Sol, Terra, and Luna models to the Amazon Bedrock
provider via the `bedrock-mantle` endpoint.
---------
Co-authored-by: Anant Goel <anant@zed.dev>
Split off from #57105 per @maxdeviant's review.
`language_model_core::ModelMode` previously had only `Default` and
`Thinking` variants. As a result, `available_model_to_anthropic_model`
in the Anthropic provider had a dead branch for `AdaptiveThinking` that
was never reachable from settings, and users manually configuring Claude
models via `available_models` could only toggle extended thinking on/off
— they could not opt into adaptive thinking and its
low/medium/high/xhigh/max effort selector. This matters most for users
on third-party Anthropic-compatible proxies, where the `/v1/models`
endpoint may not report a `capabilities` block, leaving
`available_models` as the only path to enable adaptive thinking.
Add an `Adaptive` variant to `ModelMode` and map it to
`AnthropicModelMode::AdaptiveThinking` in the Anthropic provider's
settings conversion. Users can now write:
```json
{
"language_models": {
"anthropic": {
"available_models": [
{
"name": "claude-opus-4-7",
"display_name": "Claude Opus 4.7",
"max_tokens": 1000000,
"max_output_tokens": 128000,
"mode": { "type": "adaptive" }
}
]
}
}
}
```
and get the full adaptive-thinking UX in the agent panel.
### Impact on other providers
`ModelMode` is re-exported by Google (`GoogleModelMode`) and OpenRouter.
Both already use non-exhaustive `matches!` checks for `Thinking`, so the
new variant naturally falls through to "no thinking" without compile
breakage. Bedrock defines its own local `ModelMode` enum and is
unaffected. `cargo check --workspace --all-targets` passes.
### Tests
Three new tests in `crates/language_models/src/provider/anthropic.rs`
covering Adaptive / Thinking / Default settings → model mapping:
- `cargo test -p language_models --lib provider::anthropic::`: 3/3
passing.
- `./script/clippy --package language_models --package
language_model_core`: clean.
Release Notes:
- agent: Added support for `"mode": { "type": "adaptive" }` for custom
anthropic to enable adaptive thinking
---------
Co-authored-by: Bennet Bo Fenner <bennetbo@gmx.de>
LM Studio doesn't show the context token wheel (#53790) because token
usage is
never reported in streaming responses.
Causes:
1. `stream_options` was missing from the request. Without
`stream_options: { include_usage: true }`, the LM Studio API omits
`usage`
from every streaming chunk entirely.
2. The event mapper discarded usage data in the final chunk.
OpenAI-compatible
servers send the usage summary in a trailing chunk that has an empty
`choices`
array. The old guard treated that as an error, so even when usage was
present
it was thrown away before emitting a `UsageUpdate` event.
Fix:
- Add `StreamOptions { include_usage: bool }` and `stream_options` to
`ChatCompletionRequest`, and always set it to `true` for streaming
requests.
- Move usage handling in `LmStudioEventMapper::map_event` to run
*before* the
empty-choices guard, mirroring the OpenAI provider's approach.
- Add four unit tests for `map_event` covering the fixed behavior.
Release Notes:
- Fixed LM Studio not showing the context window usage wheel.
<img width="1184" height="1080" alt="Screenshot_20260527_130449"
src="https://github.com/user-attachments/assets/97eb8500-39dd-4824-aaf8-f0422b62119d"
/>
---------
Co-authored-by: Gabriele Ancillai <gabriele.ancillai@sofka.com.co>
Co-authored-by: Bennet Bo Fenner <bennetbo@gmx.de>
Adds support for enabling Anthropic fast mode on configured models.
Previously, Anthropic models configured through
`language_models.anthropic.available_models` were always marked as not
supporting fast mode, so `speed: "fast"` would be stripped before
sending requests even when the configured model supported Anthropic fast
mode.
This adds an optional `supports_fast_mode` field to configured Anthropic
models. When enabled, the model is marked as supporting fast mode and
the required Anthropic beta header is added automatically. Built-in
fast-mode model detection remains the fallback when the setting is
omitted.
Testing:
- `cargo fmt --package anthropic --package language_models --package
settings_content`
- `cargo test -p language_models available_model --lib`
- `cargo test -p anthropic from_listed_enables_fast_mode --lib`
- `cargo check -p language_models`
- Manual: verified in a local build that a configured Anthropic model
can send fast mode requests correctly.
Release Notes:
- agent: Allow specifying if fast mode is supported for custom anthropic
models
Co-authored-by: Bennet Bo Fenner <bennetbo@gmx.de>
Release Notes:
- agent: Added GPT 5.6 Sol & Terra for ChatGPT subscription. Note: GPT
5.6 Luna is not available yet, since OpenAI has not unlocked access for
third-party clients
Co-authored-by: Christopher Biscardi <chris@christopherbiscardi.com>
Add new GPT 5.6 models
Release Notes:
- open_ai: Added support for GPT 5.6 Sol/Terra/Luna
---------
Co-authored-by: Christopher Biscardi <chris@christopherbiscardi.com>
# Objective
Allow zed's language model stack to express OpenAI Responses API custom
tools (freeform text-input tools with an optional lark/regex grammar),
so downstream consumers can offer tools like a freeform `apply_patch` to
GPT models.
## Solution
- `LanguageModelRequestTool` now carries a Function-vs-Custom input
variant; `LanguageModelCustomToolFormat` models text/grammar formats.
- `LanguageModelToolUse.input` becomes a typed
`LanguageModelToolUseInput::{Json, Text}`. Serialization is tagged so
persisted Text inputs round-trip losslessly; legacy plain JSON values
still deserialize as `Json`.
- `open_ai` gains the custom tool wire types (tool definition,
`custom_tool_call`/`custom_tool_call_output` input items with
string-or-content-part outputs, output item, and
`custom_tool_call_input` delta/done stream events). The Responses event
mapper accumulates raw text deltas into `ToolUse` events, and history
replay derives custom-vs-function tool results from the matching
`ToolUse` by id.
- All non-OpenAI providers and the Chat Completions path error
explicitly when a request contains custom tools — no silent drops or
empty-schema coercions.
Release Notes:
- N/A
Adds native support for AWS Bedrock's Mantle endpoint
(`bedrock-mantle`), which serves models with no `Converse`/`Invoke`
support on `bedrock-runtime`, such as GPT-5.5, GPT-5.4, and Grok 4.3 but
more importantly **open-weight** models
Closes#60471
## What's changed
- Renamed the existing `Model` enum in the `bedrock` crate to
`ConverseModel`, and added a new `MantleModel` enum for Mantle-only
models. Mantle models reuse the existing OpenAI-compatible Chat
Completions/Responses request and response plumbing
(`into_open_ai`/`into_open_ai_response`,
`OpenAiEventMapper`/`OpenAiResponseEventMapper`) already used by the
native OpenAI and OpenAI-compatible providers, rather than introducing
new marshalling code.
- Added a `BedrockMantleModel` language model that routes requests to
the `bedrock-mantle` endpoint, dispatching to Chat Completions or the
Responses API depending on the model. Mantle models appear in the model
picker alongside Converse models under the same Bedrock provider.
- Added region gating: `bedrock-mantle` is only available in a subset of
AWS Regions, so using a Mantle model outside of them surfaces a clear
error naming the current Region and the supported ones, instead of an
opaque HTTP failure.
- Implemented Bedrock bearer token authentication for Mantle requests: a
configured Bedrock API key is used as-is, and every other auth method
(IAM credentials, named profile, SSO, automatic) derives a short-term
token by locally SigV4-presigning a `CallWithBearerToken` request. This
requires no extra network round trip and no token caching, since
re-signing locally is cheap.
- Added a specific error for the 403 you get when your credentials have
`bedrock:CallWithBearerToken` but not the separate
`bedrock-mantle:CallWithBearerToken` permission Mantle models require,
since this is the most common misconfiguration.
- Added a `mantle_available_models` setting so custom models served
through `bedrock-mantle` can be configured, the same way other providers
support custom models via `available_models`.
- Documented Mantle models and the new setting in the Amazon Bedrock
section of [Use a
Gateway](https://zed.dev/docs/ai/use-a-gateway#amazon-bedrock).
## Testing
- Added unit tests covering: the local SigV4 bearer-token signing
(including a byte-for-byte cross-check against a reference
implementation), Mantle endpoint URL construction, the
Mantle-supported-regions list, thinking-effort normalization, and the
settings-to-model protocol mapping.
- `cargo test -p bedrock -p language_models -p settings_content -p
settings` passes.
- `./script/clippy` passes with no new warnings.
Release Notes:
- Added native support for AWS Bedrock's Mantle endpoint, enabling
GPT-5.5, GPT-5.4, and Grok 4.3 through the Amazon Bedrock provider.
**TL;DR**: model updates + reasoning levels + fixes discovered when
working on https://github.com/zed-industries/zed/pull/60373
# Objective
Since the model auto-discovery PR was
[cancelled](https://github.com/zed-industries/zed/pull/60373#issuecomment-4886521448),
here is a manual model list update! I also copied the stand-alone
bugfixes/enhancements from that PR.
## Solution
A lot of manual work 😅
**OpenCode Zen**:
- added Fable 5 and Sonnet 5
- added models that were previously only available on OpenCode Go: GLM
5.2, Kimi K2.7 Code, and Minimax M3
- added reasoning levels for all models. I started from the data on
[`Models.dev`](https://models.dev) (the `/api.json` raw data), and then
I matched that with what is shown in the OpenCode CLI and what I know to
be true
**OpenCode Go**:
- added reasoning levels for GLM 5.2
**OpenCode in general**:
- added `protocol` validation for the settings, by moving from a random
`String` to an `enum`, for both nicer error messages (random strings or
typos will get an error instead of using `openai_chat` by default) and
to avoid issues like [folks saying non-existent protocols are a
thing](https://github.com/zed-industries/zed/issues/56869#issuecomment-4550154554)
- enabled parallel tool calls by default. As per [OpenCode developer on
Discord](https://discord.com/channels/1391832426048651334/1471233160993050918/1472020924881702912),
_"almost all models worth using support parallel tool calling
natively"_. Manual tests confirmed all OpenCode Go models support this
correctly (and was enabled by default on the OpenCode side for all but 1
model). I initially wanted to skip this from the release notes, but I
added it so folks are aware of it in case any issues are caused by this
being enabled for all models
- allegedly fixed Google thinking since reasoning levels / thinking
effort levels were added for Google models and an auto-checker LLM
highlighted that was not properly configured
- added support for the new-ish `supports_disabling_thinking` so
thinking-only models don't get a no-impact toggle to disable thinking
I have no idea if any of the Free models will disappear in 2 days or
not, so I did not update those 🤷 (as per decision in
https://github.com/zed-industries/zed/issues/56869#issuecomment-4466637648)
## Testing
The Zen and Google changes were not tested as I don't have a Zen
subscription and I stubbornly refuse to get one.
The Free&Go changes were tested by running a "_rename this variable for
me. add a function. delete the function_" test with a few different
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 adheres to Zed's UI standards
([UX/UI](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
and
[icon](https://github.com/zed-industries/zed/blob/main/crates/icons/README.md)
guidelines)
- [ ] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
---
Release Notes:
- Agent: OpenCode settings now validate `protocol` values
- Agent: OpenCode only shows the "Disable thinking" toggle if thinking
can indeed be disabled/enabled
- Agent: OpenCode models now enable parallel tool calls by default
- Agent: Updated OpenCode Zen models (added Fable 5, Sonnet 5, GLM 5.2,
Kimi K2.7 Code, and Minimax M3)
- Agent: Added OpenCode Go GLM 5.2 reasoning effort levels
- Agent: Added reasoning effort levels for all OpenCode Zen models
- Agent: Fixed thinking for OpenCode Zen Google models
This PR improves the onboarding experience when using the agent panel.
Previously we would pick a fallback model in case the provider failed to
authenticate/was slow to resolve models. However, this code had a race
condition (for providers that resolve models dynamically like
Anthropic/GitHub Copilot), since we pick a fallback immediately after
all providers have been authenticated. However, at that point the
configured provider might not have resolved its models, so we would fall
back to a different provider. At some point we added a workaround for
the zed.dev provider.
We landed on a much simpler approach that eliminates the race condition:
We only pick a fallback model in case the user actually has no model
configured in his settings. In case the user has a model configured, we
won't fallback and show an actionable error message:
1. Model is not set and no fallback available
<img width="862" height="78" alt="image"
src="https://github.com/user-attachments/assets/e8e7472a-1c05-4cd2-8efc-49e6d921b0a4"
/>
2. Model is set, but provider is not authenticated
<img width="865" height="65" alt="image"
src="https://github.com/user-attachments/assets/3c8cbf1d-7dd5-4b2e-809a-61e6662721a3"
/>
3. Model is set, provider is authenticated, but model is not in model
list
<img width="863" height="63" alt="image"
src="https://github.com/user-attachments/assets/b97defa2-3fb4-4ec0-b3c6-26878d1c815c"
/>
4. Model is set, but provider is not recognised
<img width="865" height="67" alt="image"
src="https://github.com/user-attachments/assets/ecff1e3f-4f6b-47eb-a25d-125a104baafc"
/>
This plays well with the reason why we have the fallback model in the
first place: We only want to pick a fallback for users that open Zed for
a first time and e.g. have an Anthropic API key present in their
environment. As soon as the user manually changes his provider/model we
won't apply the fallback anymore.
Release Notes:
- agent: Improved error messaging when provider is not configured
- agent: Improve fallback model selection
---------
Co-authored-by: cameron <cameron.studdstreet@gmail.com>
I encountered an issue where I couldn't sign in to ChatGPT Subscription
on Windows:
```
ChatGPT subscription sign-in failed to persist credentials:
Failed to write credentials to Windows Credential Manager:
占位程序接收到错误数据。 (0x800706F7)
```
Interestingly, only one of my three ChatGPT accounts had this problem —
the other two signed in successfully.
## What I Found
After investigating, I noticed that the OAuth scope in
`openai_subscribed.rs` requests 6 permissions:
```
openid profile email offline_access api.connectors.read api.connectors.invoke
```
I wrote a test script to measure token sizes and found that:
- With 6 scopes: my problematic account's token was **2578 bytes**
- With 4 scopes (removing `api.connectors.read` and
`api.connectors.invoke`): the same token was **2516 bytes**
Since Windows Credential Manager has a 2560-byte limit
(`CRED_MAX_CREDENTIAL_BLOB_SIZE`), this could explain why some accounts
fail while others succeed — it depends on the base token size.
## My Hypothesis
The issue seems to be that:
- Error code `0x800706F7` = `RPC_X_BAD_STUB_DATA` (size limit, not
format)
- Accounts with larger base tokens exceed the limit when the extra 48
chars are added
- Accounts with smaller base tokens still fit, which is why this isn't
universally reproducible
I'm not 100% certain this is the root cause, but the evidence seems to
point in this direction.
## Proposed Fix
I removed `api.connectors.read` and `api.connectors.invoke` from the
OAuth scope, since:
- These scopes don't appear to be used by Zed's current ChatGPT
integration
- OpenCode (another tool using the same OAuth provider) successfully
uses only 4 scopes
- This fix allowed my problematic account to sign in
However, I'd like to ask the maintainers:
- Are there plans to use OpenAI Connectors API in the future?
- Are there security or compliance reasons for requesting these extra
scopes?
If the answer is yes to either, we'd need a different approach (e.g.,
splitting credentials, using encrypted file storage, or checking token
size before storage).
## Testing
- [x] Verified my problematic account now signs in successfully
- [x] Verified my other accounts still work
- [x] Ran `cargo check -p language_models` (compilation successful)
- [ ] Would appreciate help testing on macOS/Linux
## Questions
1. Does this analysis make sense?
2. Are there any other considerations I'm missing?
3. Would it be helpful to add a size check with a clearer error message
for future cases?
I'm happy to adjust this approach based on your feedback.
Release Notes:
- Fixed ChatGPT Subscription sign-in failing on Windows for some
accounts by removing unused OAuth scopes (`api.connectors.read`,
`api.connectors.invoke`) that pushed JWT tokens over Windows Credential
Manager's limit.
---------
Co-authored-by: Smit Barmase <heysmitbarmase@gmail.com>
When prompt caching is enabled, `into_bedrock` pushes a `CachePoint`
block
onto a message's content whenever `message.cache && supports_caching` is
true.
This push happens before the `if bedrock_message_content.is_empty() {
continue; }`
guard. As a result, a message whose content filters down to empty (for
example,
a message that contained only content stripped during conversion) still
gets
appended to the request carrying nothing but a `cachePoint`. Bedrock
rejects such
a message with a `ValidationException`, breaking the whole request.
The Anthropic path is already internally consistent here: in
`crates/language_models/src/provider/anthropic.rs` (around the message
assembly
in `completion.rs`) the empty-content check runs first, so an empty
message is
dropped before any cache marker is attached. The Bedrock path should
behave the
same way.
This change gates the `CachePoint` push on non-empty content
(`&& !bedrock_message_content.is_empty()`), so an empty message is left
empty and
then skipped by the existing `continue`, exactly mirroring the Anthropic
ordering.
The fix is minimal and touches only the cache-point condition.
Release Notes:
- Fixed Bedrock requests failing with ValidationException when the last
message filtered to empty content while prompt caching was enabled.
---------
Signed-off-by: Yi LIU <yi@quantstamp.com>
Co-authored-by: Smit Barmase <heysmitbarmase@gmail.com>
This PR removes/simplifies some APIs that were leftover after moving the
agent settings from the agent panel into the agent settings UI.
Behavior/UI should be identical.
- Removed `ConfigurationViewTargetAgent` since only a single variant was
used
- Removed `configuration_view` and `configuration_view_v2` and replaced
it with `settings_view`
- Removed all the custom configuration views that were replaced by the
API key view abstraction
- Removed `intitial_title` and `initial_description` and moved it to
`ProviderSettingsView`
Release Notes:
- N/A
Closes AI-159
Closes AI-434
Closes AI-435
Release Notes:
- Key agent-related settings now live in the settings editor, close to
all other settings available in Zed. This specifically includes the move
of LLM providers, external agents, and MCP servers to the settings
editor.
---------
Co-authored-by: zed-zippy[bot] <234243425+zed-zippy[bot]@users.noreply.github.com>
Co-authored-by: Bennet Bo Fenner <bennetbo@gmx.de>
Hi there, I'm Celina from Hugging Face! Opening this PR to add
[llama.cpp](https://llama.app) as a model provider
# Objective
Today Zed users running llama.cpp have to fall back to the generic
OpenAI-compatible provider, which means no auto-discovery (the router
mode (`llama serve`) discovers models from the cache and loads them on
demand) and manual configuration of every model and its capabilities.
This PR makes `llama.cpp` a first-class provider with the same
auto-discovery experience.
## Solution
- Add a `llama_cpp` client crate with the OpenAI-compatible chat types
(`/v1/chat/completions`, including `reasoning_content`) and the
discovery types (`/v1/models`, `/props`), mirroring the existing
`ollama` crate.
- Add the provider in
`crates/language_models/src/provider/llama_cpp.rs`, modeled on the
Ollama provider (settings, configuration view, event mapping).
- Auto discover served models and their context length and tool/vision
support from `/props`. Set `auto_discover: false` to list models
manually instead.
- An unloaded model can't be inspected without loading it, so it is
listed with optimistic defaults (large context, tools enabled) and is
usable from the first message; its real context length and tool support
are filled in once it loads. These live behind a shared map, so a model
already selected in an open conversation picks them up without being
re-selected.
- Show load progress. The provider subscribes to `/models/sse` and
surfaces each model's load progress (e.g. "Loading weights 42%") in its
display name, reconciling stale labels against `/v1/models`. Builds
without `/models/sse` degrade gracefully - no progress, and no
capability refresh after the initial discovery.
- Add settings (`api_url`, `auto_discover`, `available_models` with
per-model `max_tokens` / `supports_tools` / `supports_images`,
`context_window`, `custom_headers`), the provider icon, a `default.json`
entry, and documentation under "Use a Local Model".
No new dependencies: the crate reuses existing workspace dependencies,
and shared state uses `std::sync::RwLock`.
## Testing
- Unit tests in both new crates cover wire/response parsing, model
discovery for single-model and router shapes, the cold-start optimistic
defaults, the in-place capability refresh once a model loads, and the
`/models/sse` event handling (state changes, load failure, load
progress).
- Built Zed locally and ran it against a local `llama serve` router:
confirmed models are discovered without manual configuration, that the
first message works before a model has finished loading, that load
progress is shown in the model's display name while it loads, and that
the reported context length and tool support refine to the model's real
values once it finishes loading.
- Platforms: tested on macOS (Apple Silicon).
## 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 adheres to Zed's UI standards
([UX/UI](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
and
[icon](https://github.com/zed-industries/zed/blob/main/crates/icons/README.md)
guidelines)
- [x] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
## Showcase
The generation speed (tokens/sec) depends on the machine you're running
the model, here it's a Apple M3 Max 64GB running a 4-bit quant of
https://huggingface.co/Qwen/Qwen3.5-35B-A3B. For the load progress
status, make sure to upgrade your llama.cpp version to the latest build.
https://github.com/user-attachments/assets/0254f6ef-abe9-42ed-810b-ef1a5b8fa3bd
---
Release Notes:
- Added llama.cpp as a language model provider
---------
Co-authored-by: Ben Brandt <benjamin.j.brandt@gmail.com>
# Objective
More and more models are supporting the `max` reasoning effort (DeepSeek
V4, GLM 5.2, etc) and that was missing from Zed.
## Solution
Added `ReasoningEffort::Max` level and implemented support for that
across providers. For most providers this is a no-op as they don't
support that (`max` is missing from `supported_reasoning_levels()`) but
for some providers this required tiny changes: for OpenCode there is now
a proper difference between `xhigh` and `max` (this bug was actually
what triggered this whole PR) and for DeepSeek reasoning levels were
migrated from a custom `deepseek::ReasoningEffort`.
## Testing
Tested and confirmed working with a simple _"rename this variable for
me. add a function. delete the function"_ test across a few providers
(OpenCode, GitHub Copilot, and DeepSeek).
## 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 adheres to Zed's UI standards
([UX/UI](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
and
[icon](https://github.com/zed-industries/zed/blob/main/crates/icons/README.md)
guidelines)
- [ ] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
## Showcase
N/A
---
Release Notes:
- OpenAI-compatible: added support for `max` reasoning levels
- OpenCode: added support for `max` reasoning levels
Closes https://github.com/zed-industries/zed/issues/52576
## Overview
Adds prompt caching support for Anthropic Claude models when accessed
via OpenRouter.
This mirrors Zed's native Anthropic provider by using explicit per-block
`cache_control` breakpoints:
- A long-lived 1-hour breakpoint on the system message's last text
block, covering the tools and system prefix.
- A default 5-minute breakpoint on the last `cache: true` conversation
message.
The implementation intentionally avoids OpenRouter's top-level automatic
`cache_control` field so routing remains available across
Anthropic-compatible providers including Anthropic, Bedrock, and Vertex
AI. It also adds `session_id` sticky routing from the request thread ID
and maps OpenRouter cache usage fields into Zed's token usage
accounting.
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:
- Fixed Anthropic prompt caching when using OpenRouter.
---------
Co-authored-by: Anant Goel <anant@zed.dev>
# Objective
Fix OpenAI-compatible reasoning/thinking support. Previously,
`OpenAiCompatibleLanguageModel` never reported thinking support, so
configured `reasoning_effort` values did not reliably reach the wire and
Responses API reasoning state could miss `include:
["reasoning.encrypted_content"]`.
Fixes#58289
Addresses #59207 for OpenAI-compatible Responses models configured with
`reasoning_effort`.
## Solution
- Treat a non-`none` configured `reasoning_effort` as OpenAI-compatible
thinking support.
- Expose common OpenAI-style effort levels in the agent UI, using the
configured effort as the default.
- Honor selected reasoning effort for OpenAI-compatible chat-completions
requests.
- Send `reasoning_effort: "none"` when thinking is disabled for a
configured reasoning model.
- Preserve native OpenAI behavior by continuing to use native
model-specific supported efforts and `max_completion_tokens`.
- Add an OpenAI-compatible `max_tokens_parameter` capability for
endpoints that expect output limits as `max_tokens`.
- Parse common streamed thinking fields (`reasoning` and
`reasoning_content`).
- Add provider setup UI and docs for configuring OpenAI-compatible
reasoning models.
## Testing
- `cargo fmt -p language_model_core -p agent_ui -p language_models`
- `cargo test -p language_models provider::open_ai_compatible::tests
--lib`
- `cargo test -p language_models provider::open_ai::tests --lib`
- `cargo test -p open_ai completion::tests --lib`
- `cargo test -p agent_ui
agent_configuration::add_llm_provider_modal::tests --lib`
- `git --no-pager diff --check`
## 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 adheres to Zed's UI standards
([UX/UI](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
and
[icon](https://github.com/zed-industries/zed/blob/main/crates/icons/README.md)
guidelines)
- [x] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
---
Release Notes:
- Improved OpenAI-compatible provider setup for reasoning models.
---------
Co-authored-by: Anant Goel <anant@zed.dev>
## Summary
Fixes#37815.
`State::fetch_models()` calls `/api/tags` to list models, then calls
`/api/show` for **every** model in that list to get its capabilities,
collecting the results with `collect::<Result<Vec<_>>>()?`. If
`/api/show` errors for even one model, the whole batch fails and
`fetched_models` is never populated. Since `is_authenticated()` is
defined as `!self.fetched_models.is_empty()`, this means a single bad
model permanently breaks both authentication state and the model picker
for the entire Ollama provider - with no error surfaced anywhere (not
the UI, not the logs), which matches the reports in #37815 of "Connect
does nothing" / "no logs, no nothing".
I hit this myself: I had a stale local reference to an Ollama Cloud
model that had been retired server-side. `/api/show` for that one model
returned `410 Gone`, which silently broke Connect and the model picker
for every other model too. Removing the retired model with `ollama rm`
fixed it immediately, which confirmed the root cause.
## Fix
Instead of aborting the whole fetch on the first error, skip individual
models that fail `/api/show` and log a warning, keeping the rest.
Extracted this into a small `skip_failed_models` helper so it's
unit-testable without mocking HTTP.
## Disclosure
I used Claude (Anthropic's Claude Code) to help track down this root
cause (tracing through `fetch_models`/`is_authenticated` in this file)
and draft the fix + tests below. I reviewed and understand the change -
it's a small, targeted fix to a single function plus two unit tests for
the new helper.
## Test plan
- [x] `cargo check -p language_models` passes
- [x] `cargo test -p language_models --lib ollama::` - all 3 tests pass
(the 2 new ones plus the existing
`test_merge_settings_preserves_display_names_for_similar_models`,
unaffected by this change)
- [x] `cargo fmt -p language_models -- --check` - no diff
## Release Notes
Release Notes:
- Fixed Ollama models silently failing to show up in the model picker
(and "Connect" appearing to do nothing) when a single model's details
couldn't be fetched, e.g. a retired Ollama Cloud model
---------
Co-authored-by: MrSubidubi <finn@zed.dev>
Co-authored-by: Ben Brandt <benjamin.j.brandt@gmail.com>
# Objective
Fixes auto-compaction for ChatGPT Subscription / Codex-backed GPT models
by treating the Codex `context_window` as the usable context budget
instead of reserving an inferred `128k` output budget.
- Fixes#59555
## Solution
Zed previously reported `max_output_tokens = 128_000` for
`openai_subscribed` models. Generic agent code subtracts
`max_output_tokens` from `max_token_count` when computing the effective
input budget, so `openai_subscribed` models ended up with:
- `max_token_count = 272_000`
- `max_output_tokens = 128_000`
- effective compaction budget = `144_000`
- default `90%` threshold = `129_600`
## Testing
Tested with a heavy prompt to confirm that the auto compaction is indeed
now triggered at 90% (default)
<img width="385" height="183" alt="image"
src="https://github.com/user-attachments/assets/da569152-f687-4366-868a-a6559b948ce5"
/>
This made Zed compact around the halfway point of the actual Codex
context window.
Codex model metadata exposes `context_window = 272000` and does not
expose a `max_output_tokens` cap. Codex also compacts against the
context window directly, rather than subtracting an output reservation.
The subscribed backend also rejects the `max_output_tokens` request
parameter, so Zed already omits it when serializing requests.
This change makes `openai_subscribed` report no known max output token
cap, which matches also that split token display is disabled for these
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 adheres to Zed's UI standards
([UX/UI](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
and
[icon](https://github.com/zed-industries/zed/blob/main/crates/icons/README.md)
guidelines)
- [X] Tests cover the new/changed behavior
- [X] Performance impact has been considered and is acceptable
---
Release Notes:
- agent: Fix compaction happening too early when using the ChatGPT
subscription provider.
`OpenAiCompatibleLanguageModel::stream_completion` (used for custom
OpenAI-compatible providers) forwarded `request.speed` straight into
`into_open_ai`/`into_open_ai_response`, which translate `Speed::Fast`
into OpenAI's `service_tier` field. Custom OpenAI-compatible endpoints
don't recognize that field and reject the request.
`speed` can end up set even for a provider that doesn't support fast
mode: `Thread::inherit_parent_settings` copies `speed` from a parent
thread to a subagent without checking whether the subagent's model
supports it.
Every other provider sharing this conversion code already guards against
this (`open_ai.rs`, `anthropic.rs`, `anthropic_compatible.rs`,
`language_models_cloud.rs`). This adds the same guard for
`OpenAiCompatibleLanguageModel`.
Release Notes:
- Fixed requests to OpenAI-compatible providers (e.g. Baseten) sometimes
including an unsupported `service_tier` parameter
Manage various LLM settings (previously in agent panel) in settings UI.
Behind a feature flag, not staff shipped
Release Notes:
- N/A or Added/Fixed/Improved ...
Adds provider-side context compaction support to the Anthropic and
OpenAI API clients. Client plumbing only; not wired into the UI.
Release Notes:
- N/A
When a Zed Business organization hits its token spend limit, the agent
panel told the user to "check that your API key has access to this
model", and did not display the error message returned by the server.
The message about checking your API key was the generic 401 and 403
error for all language model providers. This is also incorrect in
general since there are no API keys involved in the Zed and ChatGPT
Subscription providers.
So this commit changes the message for authentication errors (401s) to
be provider-specific, with the current message about invalid API key as
the default, and overrides for the providers that don't use API keys.
And the authorization error messages (403s) now include the server error
message. So the spend-limit case now reads "Permission Denied —
Token-based spending limit reached." instead of talking about API keys.
<img width="1888" height="426" alt="grafik"
src="https://github.com/user-attachments/assets/cf9e07cd-66f0-4f8d-828c-79b875edcf2d"
/>
Telemetry event names (`invalid_api_key`, `no_api_key`) are kept
unchanged to avoid breaking existing dashboards.
Release Notes:
- Fixed agent panel errors telling users to check their API key when the
provider doesn't use one (Zed account, ChatGPT subscription). Permission
errors also now show the provider's actual message.
Claude Fable 5 always thinks and cannot honor a request with thinking
disabled, but the cloud models listing gives clients no way to tell it
apart from models where thinking is optional (e.g. Claude Opus 4.6):
both report `supports_thinking: true` plus the same adaptive effort
levels. As a result, the agent panel shows a thinking toggle for Fable
even though turning it off isn't actually supported.
zed-industries/cloud#2789 adds a `supports_disabling_thinking` field to
the models listing. This PR mirrors it through
`cloud_llm_client::LanguageModel` (serde-defaulted to `false`, so a
server without the field is treated as "don't claim thinking can be
turned off") and exposes it as
`LanguageModel::supports_disabling_thinking()`, forwarded from the
listing by `CloudLanguageModel`. The agent panel now hides the thinking
toggle for models that report `false`, showing only the effort selector.
The trait default is `true`: every non-cloud provider in the tree treats
thinking as toggleable today, and only the cloud listing knows about
always-thinking models.
Draft until zed-industries/cloud#2789 lands and deploys.
Release Notes:
- Fixed the agent panel offering a thinking toggle for models that
cannot run with thinking disabled.
<img width="325" height="201" alt="Screenshot 2026-06-09 at 1 38 32 PM"
src="https://github.com/user-attachments/assets/a6518073-1e17-41ff-a8fc-cb279fcd4436"
/>
Adds support for Anthropic's Claude Fable 5 model when using your own
Anthropic API key. Because Fable 5 cannot be offered under Zero Data
Retention (Anthropic retains inference logs for 30 days), this gates the
model behind an explicit data-retention consent: a new
telemetry.anthropic_retention setting (default off, surfaced in the
Privacy section of the settings UI), and a hard, non-retryable check in
the cloud completion path that raises a typed error when consent is
missing.
When Fable 5 declines a request, it transparently falls back to Claude
Opus 4.8 (matching Anthropic's server-side behavior), and the agent
panel shows a callout for the consent error with "Switch to Opus 4.8" /
"Accept" actions that resume the failed turn so the user's message
continues without retyping.
Closes AI-382
Release Notes:
- Add Claude Fable 5 to Anthropic BYOK
---------
Co-authored-by: Mikayla Maki <mikayla@zed.dev>
This PR makes it so we always pass up an organization ID when creating
an LLM token.
We should have an organization ID in all cases.
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
- [ ] 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.
