255880598d46c5cc299b9d762dbc4e619002af03
556
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 Neel
|
255880598d |
Switch from cargo-machete to cargo-shear (#62643)
This results in ~110 crates being removed, and some orphaned files also. --- Release Notes: - N/A Signed-off-by: Neel <neel@zed.dev> |
||
|
Vlad Ionescuanddino
|
29acba32d5 |
agent: OpenCode model updates (+6 Go, +7/-1 Zen, removed Free) (#61199)
Closes https://github.com/zed-industries/zed/issues/62559 Related discussion: https://github.com/zed-industries/zed/discussions/61160 # Objective Adding newly-released OpenCode models. Removing OpenCode Free models completely. ## Solution > [!TIP] > This pull request is **best reviewed commit-by-commit**! **OpenCode Go**: - added **Kimi K3** as per [[1]](https://github.com/anomalyco/models.dev/blob/89183a9646cf2fa30300f7203a5b4f2ca69d1374/providers/opencode-go/models/kimi-k3.toml) and [[2]](https://github.com/anomalyco/models.dev/blob/dev/models/moonshotai/kimi-k3.toml). Currently, the only supported reasoning level available is `Max` which was validated both with Models.dev data and OpenCode CLI. - added **Grok 4.5** as per [[1]](https://github.com/anomalyco/models.dev/blob/89183a9646cf2fa30300f7203a5b4f2ca69d1374/providers/opencode-go/models/grok-4.5.toml) and [[2]](https://github.com/anomalyco/models.dev/blob/89183a9646cf2fa30300f7203a5b4f2ca69d1374/models/xai/grok-4.5.toml) - added **Tencent Hy3** as per [[1]](https://github.com/anomalyco/models.dev/commit/b013d94872bb5993fad19ad35fadf74cb029516e) and [[2]](https://github.com/anomalyco/models.dev/blob/f63b5ce78dd78869faa0612353b1055f6608dc97/models/tencent/hy3.toml) - added **GPT 5.6 Luna** as per [[1]](https://github.com/anomalyco/opencode/pull/39812) and [[2]](https://github.com/anomalyco/models.dev/blob/dev/providers/opencode-go/models/gpt-5.6-luna.toml) - added **Qwen 3.8 Max** as per [[1]](https://github.com/anomalyco/models.dev/commit/403a7bdd43ac7daeadc8bb755eccabf66a0afb9d) and [[2]](https://github.com/anomalyco/opencode/commit/e9e747245681127c9f3e300aa8c46f2554fdb294) - added **GLM 5.3** as per [[1]](https://github.com/anomalyco/models.dev/blob/3876740bf4f0290e014bc85340e1dba34f0e99a7/models/zhipuai/glm-5.3.toml) and [[2]](https://github.com/anomalyco/models.dev/commit/94a1629610b579fd80f7c488f5e4e8d78c8b6883) and [[3]](https://github.com/anomalyco/opencode/pull/42518) **OpenCode Zen**: - added **Gemini 3.5 Flash Lite** as per [[1]](https://github.com/anomalyco/models.dev/blob/f63b5ce78dd78869faa0612353b1055f6608dc97/providers/opencode/models/gemini-3.5-flash-lite.toml) and [[2]](https://github.com/anomalyco/models.dev/blob/f63b5ce78dd78869faa0612353b1055f6608dc97/models/google/gemini-3.5-flash-lite.toml) - added **Gemini 3.6 Flash** as per [[1]](https://github.com/anomalyco/models.dev/blob/f63b5ce78dd78869faa0612353b1055f6608dc97/providers/opencode/models/gemini-3.6-flash.toml) and [[2]](https://github.com/anomalyco/models.dev/blob/f63b5ce78dd78869faa0612353b1055f6608dc97/models/google/gemini-3.6-flash.toml) - added **Gemini 3.7 Flash** as per [[1]](https://github.com/anomalyco/models.dev/pull/4632) and [[2]](https://github.com/anomalyco/models.dev/commit/b1810e30d7abb11af1092b51aa28cbafc2c440b8) and [[3]](https://github.com/anomalyco/opencode/pull/42390) and [[4]](https://github.com/anomalyco/opencode/pull/42393) - added **Claude Opus 5** as per [[1]](https://github.com/anomalyco/models.dev/commit/e3ae24cdd7fb524d73e1569ed1713991c5ba688c) and [[2]](https://github.com/anomalyco/models.dev/commit/342b5572a06735d0efa8c3c419589051199459d8) - added **Kimi K3** as per [[1]](https://github.com/anomalyco/opencode/commit/a9bebd36530dbab28c4644eb7b35b2b1460b8b90) and [[2]](https://github.com/anomalyco/models.dev/commit/38ccccc20d7d827f99d791d07cc4cedb8b4eec24) - added **Grok 4.6** as per [[1]](https://github.com/anomalyco/models.dev/commit/74789f5a02746cf6c40b75c342432a9d525c28b9) and [[2]](https://github.com/anomalyco/opencode/commit/d92d1e654bd1aa8ccb972b3059825314c1633eb8) and [[3]](https://github.com/anomalyco/models.dev/pull/4575) - added **Muse Spark 1.2** as per [[1]](https://github.com/anomalyco/models.dev/commit/fa03dca90bad225a09263ad6ad227c7f47d0172d) and [[2]](https://github.com/anomalyco/models.dev/blob/3876740bf4f0290e014bc85340e1dba34f0e99a7/models/meta/muse-spark-1.2.toml) and [[3]](https://github.com/anomalyco/opencode/pull/42508) - removed **Claude Opus 4.1** as per [[1]](https://github.com/anomalyco/models.dev/commit/6951484e985fe55646a741ccd3ca1d4b15008e3f) **OpenCode Free**: removed all the models and the whole concept of "OpenCode Free" from Zed. As confirmed [by an Anomaly employee on the OpenCode Discord](https://discord.com/channels/1391832426048651334/1394667004979445931/1537530485356363899), free models are now OpenCode-only since they got abused waaaaay too much by people. Testing shows that even with an active OpenCode Go subscription configured, I can't use Free models in Zed — both Big Pickle and DeepSeek V4 Flash Free failed to reply to a _"hello"_ message and instead returned a rate-limit error. A full removal of OpenCode Free from Zed was implemented in https://github.com/zed-industries/zed/pull/61199/changes/49acbf7c92414c14c453113eb9b886f9bedff7cb as there was no point in keeping a _"Show free models"_ toggle that would confuse users. Users that had `show_free_models` configures in Zed settings will get an `Property show_free_models is not allowed.` notice. Users that had any Custom OpenCode models with `"subscription": "free"` configured will get an `Value is not accepted. Valid values: "zen", "go".` notice. Neither are blocking errors. ## Testing ✅ Kimi K3 on OpenCode Go - happily confirmed Kimi K3 works by running a simple "_rename this variable for me. add a function. delete the function_" test. ✅ Grok 4.5 on OpenCode Go - bravely resisted the continuous and relentless waves of disgust and confirmed Grok 4.5 works by running a simple "_rename this variable for me. add a function. delete the function_" test. I was a bit surprised this worked as I was located in an EU country while testing this. ✅ Hy3 on OpenCode Go - happily confirmed Hy3 works by running a simple "_rename this variable for me. add a function. delete the function_" test. ✅ GPT 5.6 Luna on OpeCode Go - confirmed GPT 5.6 Luna works on OpenCode Go by running a simple "_rename this variable for me. add a function. delete the function_" test. ✅ Qwen 3.8 Max on OpeCode Go - confirmed Qwen 3.8 Max works on OpenCode Go by running a simple "_rename this variable for me. add a function. delete the function_" test. ✅ GLM 5.3 on OpeCode Go - confirmed GLM 5.3 works on OpenCode Go by running a simple "_rename this variable for me. add a function. delete the function_" test. 🤷 I did not test the new OpenCode Zen models (Claude Opus 5, Gemini 3.5 Flash Lite, Gemini 3.6 Flash, Kimi K3, Grok 4.6, Gemini 3.7 Flash, and Muse Spark 1.2) as I don't have a Zen subscription and I am stubbornly refusing to get one. ✅ Confirmed removal of OpenCode Free does not impact the rest of the OpenCode. Confirmed that any Free-related settings generate notices and not errors. Confirmed the OpenCode tab in Setting looks good. ## 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 <details> <summary>Screenshots of the OpenCode Free deprecation warnings</summary> **Notice shown in the corner of Zed**: <img width="345" height="90" alt="Notice banner shown in Zed" src="https://github.com/user-attachments/assets/3e65ba96-582c-424e-9335-1b43d6c632a8" /> **Notice shown in Settings -> LLM Providers -> OpenCode**: <img width="421" height="323" alt="Settings screen showing unexpected values" src="https://github.com/user-attachments/assets/a5eb6005-8576-4311-8b23-9c5baf314d8d" /> **Notice shown in `settings.json`**: <img width="569" height="231" alt="Notices shown in settings.json" src="https://github.com/user-attachments/assets/475375a1-268c-4420-8ef7-a896548e4498" /> </details> --- Release Notes: - Removed OpenCode Free models from Zed's built-in OpenCode provider because they are only available through OpenCode surfaces, such as its external agent through ACP. - Added Kimi K3, Grok 4.5, Hy3, GPT 5.6 Luna, Qwen 3.8 Max, and GLM 5.3 to OpenCode Go. - Added Claude Opus 5, Gemini 3.5 Flash Lite, Gemini 3.6 Flash, Gemini 3.7 Flash, Kimi K3, Grok 4.6, and Muse Spark 1.2 to OpenCode Zen. - Removed the deprecated Claude Opus 4.1 model from OpenCode Zen. ---- > [!TIP] > This pull request is **best reviewed commit-by-commit**! --------- Co-authored-by: dino <dinojoaocosta@gmail.com> |
||
|
Conrad Irwin
|
52f9567fb4 |
Preserve typed errors when listing Anthropic models (#62791)
Anthropic model-list requests currently flatten request, transport, response, and API failures into `anyhow` strings. Callers therefore cannot distinguish an invalid API key from connectivity or provider failures, even though Anthropic returns a structured error payload. This changes `list_models` to return `AnthropicError`, maps each request stage to its existing typed variant, and routes unsuccessful responses through the same structured response handler used by completion requests. The language model provider converts that error at its existing `LanguageModelCompletionError` boundary. A regression test verifies that an authentication response retains both its error category and Anthropic's human-readable message. Testing performed: - `cargo fmt --check` - `cargo nextest run -p anthropic -p language_models` - `./script/clippy -p anthropic -p language_models` Release Notes: - Fixed Anthropic API key errors being reported as generic model-list failures. |
||
|
Eric HolkandAnant Goel
|
a3bf217dba |
Improve explicit compaction for Anthropic models (#62139)
Explicit compaction (`LanguageModel::compact`) was previously implemented only for OpenAI-routed cloud models, which use a dedicated compact operation proxied through `/completions/compact`. Anthropic models only compacted automatically when a request's `compact_at_tokens` trigger was crossed, leaving consumers without a provider-backed way to request compaction immediately. Anthropic has no compact-on-demand operation, but the `compact_20260112` context-management edit provides the necessary pieces: the lowest trigger the API accepts, 50,000 input tokens, combined with `pause_after_compaction`, which stops the response after the compaction block. Explicit compaction requests remove tools so the internal summarizer must produce replacement context while retaining Anthropic's default summarization prompt. The resulting readable summary, optional opaque provider state, and usage are collected consistently. This implements explicit compaction for both direct and hosted Anthropic models. Hosted requests use the normal `/completions` endpoint; gateway support for forwarding the compaction fields landed in zed-industries/cloud#3216. Models expose the 50,000-token minimum so callers can disable explicit compaction below the provider's floor. Calls made below that floor still fail if the stream produces no finalized compaction context. The existing OpenAI compact operation is moved into a provider-specific helper without changing its request, endpoint, response handling, or provider-state ownership. Testing: - `cargo nextest run -p anthropic -p language_models_cloud -p language_models` - `./script/clippy -p anthropic -p language_model -p language_models_cloud -p language_models` - `cargo fmt --all --check` - `git diff --check` Release Notes: - N/A --------- Co-authored-by: Anant Goel <anant@zed.dev> |
||
|
Anant Goel
|
8ecd20779c |
openai_subscribed: Request ungated account model catalog (#62729)
The ChatGPT Codex models endpoint interprets `client_version` as a Codex CLI compatibility version and filters models whose `minimal_client_version` is newer. Zed was passing its unrelated application version, so catalog contents depended accidentally on how Zed's release number compared with Codex's version sequence. A read-only sweep against the authenticated endpoint showed that omitting the parameter returns HTTP 400, ordinary versions receive the expected compatibility-filtered subsets, and `0.0.0` is a special ungated sentinel. The `0.0.0` response had the same model set, ETag, and canonical body hash as current and higher Codex versions, while `0.0.1` returned no models. This moves ownership of that behavior into `openai_subscribed::State`. The normal constructor now always requests the ungated account catalog, and the public constructor that accepted arbitrary host versions is removed so applications cannot accidentally couple model visibility to their own version scheme. The existing initial-load test pins the resulting `client_version=0.0.0` request. Testing performed: - `cargo nextest run -p openai_subscribed` - `cargo nextest run -p language_models openai_subscribed` - `./script/clippy -p openai_subscribed -p language_models` - `cargo fmt --all -- --check` - `git diff --check` Release Notes: - Fixed ChatGPT subscription model discovery to avoid filtering models by Zed's application version. |
||
|
Anant GoelandEric Holk
|
bb1adf9781 |
agent: Share compatible Chat Completions infrastructure (#62652)
OpenAI-compatible providers currently cannot reuse Zed's OpenAI Chat Completions transport unless they also adopt the exact OpenAI request and response types. OpenRouter therefore maintained its own copy of request construction, authentication, status handling, response reading, and server-sent event framing. This change extracts that mechanical transport into two provider-neutral functions in `open_ai`: one for streaming requests and one for non-streaming requests. They accept any serializable request envelope, preserve custom headers and provider names, return untyped JSON for provider-specific decoding, and retain typed failures for serialization, request construction, HTTP transport, response reading, and deserialization. The existing OpenAI entry points remain as compatibility wrappers, so existing callers keep the same API and behavior. The abstraction deliberately stops at the wire boundary. OpenRouter continues to own its request and response schemas, attribution headers, routing controls, cache placement, and API-specific error interpretation. It now adapts the shared framed stream into those OpenRouter types instead of implementing a second HTTP and server-sent event stack. Moving OpenRouter onto the shared path also requires the ordinary Chat Completions schema and event mapper to preserve compatible metadata that OpenRouter already emits. This includes structured reasoning details needed for replay, fragmented reasoning accumulation, prompt-cache read and write usage, and thought signatures attached to tool calls. The stream exposes `[DONE]` explicitly rather than treating it as indistinguishable from an unexpected end of the response body. OpenRouter's routing session identifier is hashed before transmission so Zed's internal thread identifier is not exposed. The diff is larger than the extracted transport alone because the shared API is additive, the compatibility metadata must be represented in the common wire types and event mapper, and the provider-specific adapter remains intentionally independent. Roughly four hundred added lines are focused transport, metadata, error-classification, attribution, caching, and privacy tests. The provider-level OpenRouter implementation becomes smaller while preserving its existing behavior. Testing performed: - `cargo test -p open_ai` - `cargo test -p open_router` - `cargo nextest run -p language_models open_router` - `cargo check -p edit_prediction -p edit_prediction_cli` - `cargo fmt --all -- --check` - `./script/clippy -p open_ai -p open_router -p language_models -p edit_prediction_cli` - `cargo machete` Release Notes: - Improved OpenRouter reasoning continuity and request privacy. --------- Co-authored-by: Eric Holk <eric@zed.dev> |
||
|
Anant Goel
|
9b05e122be |
openai_subscribed: Discover account-specific models (#62651)
ChatGPT subscription model availability is determined by the authenticated Codex backend and can vary by account. The provider currently exposes a bundled static list and defaults to GPT-5.6 Sol, so users can be offered a model that their ChatGPT account subsequently rejects. This change fetches the account-scoped Codex model catalog after loading stored credentials and after sign-in. Requests use the existing OAuth token, ChatGPT account ID, Zed originator, and the Zed client version. Picker-visible models are ordered by the server's priority, and the returned metadata drives model names, context windows, image support, reasoning levels, and Fast Mode support. The bundled list remains available before discovery and when discovery fails. A failed refresh preserves the last usable catalog and surfaces the failure in provider settings, while generation checks prevent a response for an older account or request from replacing newer state. Model discovery uses the same five-second timeout as Codex so a stalled catalog endpoint cannot indefinitely delay authentication. Zed's language model provider now derives its provided, default, recommended, and fast models from that resolved catalog. Testing performed: - `cargo nextest run -p openai_subscribed` - `cargo nextest run -p language_models` - `./script/clippy -p openai_subscribed -p language_models --lib` - `cargo fmt --all -- --check` - `git diff --check` Release Notes: - Fixed ChatGPT subscription accounts offering models that are not available to them. |
||
|
Xin Zhao
|
6206d48ac5 |
deepseek: Support low reasoning effort for V4 models (#62577)
# Objective DeepSeek has released the GA version of its V4 Pro model, and added a new low reasoning effort level for both V4 Flash and V4 Pro. We need to update Zed's DeepSeek provider to sync with this update. Reference: https://api-docs.deepseek.com/updates/ ## Solution Added a new Low reasoning effort level for DeepSeek models. ## Testing Built and ran locally. Screenshots with this change are attached in the Showcase section. ## 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 After this change: <img width="639" height="169" alt="flash" src="https://github.com/user-attachments/assets/5521f6fe-ced9-4842-8783-24c532bf66f6" /> <img width="640" height="181" alt="pro" src="https://github.com/user-attachments/assets/0293d4a2-03f8-41e1-8a3e-31efce9dea17" /> --- Release Notes: - Added support for low reasoning effort for DeepSeek V4 Flash and V4 Pro |
||
|
Neel
|
d91ad71c78 |
language_models: Make GPT-5.6 Sol default for OpenAI subscribed (#62477)
Release Notes: - Make GPT-5.6 Sol default for OpenAI subscribed Signed-off-by: Neel <neel@zed.dev> |
||
|
Bennet Bo Fenner
|
351c150ab1 |
open_ai: Recommend GPT-5.6 Sol (#62417)
Recommends GPT-5.6 Sol for both OpenAI BYOK and OpenAI subscription. Also unifies the naming so that we use the same OpenAI model names for the Zed/OpenAI BYOK and OpenAI subscription providers. Release Notes: - N/A |
||
|
Bennet Bo Fenner
|
925c834e27 |
copilot_chat: Cleanup after removing OAuth via LSP (#62198)
Some cleanup after moving from away from using the LSP for OAuth Release Notes: - N/A |
||
|
Danilo Leal
|
d0f3bd3d58 |
Add dedicated icon for the GPT Subscription provider (#62009)
Just to make it easier to differentiate when using an OpenAI model coming from the GPT Subscription vs. from the API key. Release Notes: - N/A |
||
|
Nitin Krishna MucheliandClaude Sonnet 5
|
669f79be97 |
language_models: Stop logging noisy ChatGPT Subscription auth errors on startup (#61949)
# Objective
- On every startup (and whenever the agent panel initializes), Zed
authenticates all visible language model providers in the background to
populate the model selector. For every other credential-based provider,
"not signed in yet" is reported as
`AuthenticateError::CredentialsNotFound`, which is explicitly treated as
expected and not logged. The ChatGPT Subscription provider instead
returned a generic `anyhow` error, so it logged an `ERROR [agent] Failed
to authenticate provider: ChatGPT Subscription: ...` on every launch,
even for users who have never configured or used it.
- Fixes #60237
> **AI disclosure:** I used Claude (Anthropic) to investigate this
error, write the fix, and draft this PR description, based on a `Failed
to authenticate provider: ChatGPT Subscription` line I noticed in my own
Zed logs. I reviewed the diff and the reasoning below, ran the tests
myself, and understand and take responsibility for the change, per Zed's
[AI
Policy](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#ai-policy).
## Solution
- `OpenAiSubscribedProvider::authenticate` now returns
`AuthenticateError::CredentialsNotFound` (instead of a generic
`anyhow!(...)` wrapped into `AuthenticateError::Other`) when no ChatGPT
credentials are found after the initial load, matching how every sibling
provider (e.g. Anthropic's `ApiKeyState::load_if_needed`) signals "not
configured."
- The user-facing sign-in prompt in the settings UI
(`SUBSCRIPTION_DESCRIPTION`) is unchanged — this only affects the
background authentication sweep's error handling, not what the user sees
when opening provider settings.
## Testing
- `cargo test -p language_models -p openai_subscribed` — all 108 tests
pass, including
`provider::openai_subscribed::tests::test_authenticate_awaits_initial_load`,
which exercises this exact code path.
- `cargo check -p language_models` — compiles cleanly.
- Manually confirmed the log line no longer appears when starting Zed
without ChatGPT Subscription configured.
## Self-Review Checklist:
- [x] I've reviewed my own diff for quality, security, and reliability
- [ ] 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
Before (this fix): startup log ends with a spurious `ERROR` even though
ChatGPT Subscription was never configured.
```
2026-07-30T21:37:46+05:30 INFO [zed] ========== starting zed version 1.15.0+dev.b90735ff317b83c4ec62ab3d73dd5385bbe1624d, sha b90735f ==========
2026-07-30T21:37:48+05:30 WARN [zed::reliability::hang_detection] debug build, only reporting hangs longer then 5s
2026-07-30T21:37:48+05:30 WARN [zed::reliability] Minidump endpoint not set
2026-07-30T21:37:48+05:30 INFO [zed::reliability] memory usage: resident 98 MiB, virtual 426367 MiB
2026-07-30T21:37:48+05:30 INFO [extension_host] extensions updated. loading 2, reloading 0, unloading 0
2026-07-30T21:37:48+05:30 INFO [prompt_store::rules_to_skills_migration] Rules-to-skills migration already marked done; skipping startup migration
2026-07-30T21:37:49+05:30 INFO [zed::reliability] worktree diagnostics: stores 0, slots 0, live 0, visible 0, strong 0, dead weak 0, loading 0, entries 0, visible entries 0, largest none
2026-07-30T21:37:49+05:30 INFO [workspace] Rendered first frame
2026-07-30T21:37:50+05:30 ERROR [agent] Failed to authenticate provider: ChatGPT Subscription: Sign in with your ChatGPT Plus or Pro subscription to use this provider.
```
After this fix: the same startup sequence completes with no `ERROR`
line.
```
2026-07-30T22:11:38+05:30 INFO [zed] ========== starting zed version 1.15.0+dev.a8b25c313176aeee9dc99273f7c28857afed86e0, sha
|
||
|
|
36ce2c40ab |
copilot: Use separate authentication paths for edit prediction and chat (#60535)
Release Notes: - copilot: Improve robustness of copilot chat provider by splitting authorisation paths for edit predictions and chat. Note: Existing users will have to re-authenticate with Copilot --------- Co-authored-by: cameron <cameron.studdstreet@gmail.com> Co-authored-by: zed-zippy[bot] <234243425+zed-zippy[bot]@users.noreply.github.com> |
||
|
Bennet Bo Fenner
|
be07d51f8d |
Move OpenAI subscription code to separate crate (#61787)
Release Notes: - N/A |
||
|
Richard Feldman
|
8457a4ccf4 |
Opus 5 BYOK Support (#61596)
<img width="844" height="404" alt="Screenshot 2026-07-24 at 3 47 04 PM" src="https://github.com/user-attachments/assets/4691a246-bab9-4426-aa0b-6a7cfa2aa486" /> action support, and explicit thinking opt-out behavior. Adds Claude Opus 5 to the Anthropic and Amazon Bedrock BYOK providers, including its documented context and output limits, regional inference profiles, fast mode and comp Release Notes: - Added Claude Opus 5 support for Anthropic and Amazon Bedrock BYOK providers. |
||
|
Nathan Sobo
|
fe4f59add6 |
Add explicit OpenAI conversation compaction and fix Anthropic compaction (#61370)
# Objective Add explicit conversation compaction for OpenAI Responses API models, available through both direct OpenAI connections and Zed Cloud models. Keep finalized replacement context provider-neutral and separate from the lifecycle events emitted while automatic compaction is in progress. ## Solution - Add opt-in explicit compaction support to the `LanguageModel` trait. - Separate streamed `CompactionUpdate` lifecycle events from finalized `CompactedContext`. - Represent provider-native compacted context as an opaque, versioned state owned by the originating provider. - Construct compact requests through the same OpenAI request conversion used for completions, then narrow the request to fields supported by `/responses/compact`. - Preserve and validate the complete canonical replacement window returned by OpenAI. - Replay the replacement window before messages sent after compaction, without resending the superseded transcript. - Support explicit compaction through both the direct OpenAI provider and `CloudLanguageModel`. - Update automatic OpenAI and Anthropic compaction to use the same finalized context representation. - Reject empty, malformed, incorrectly versioned, and incorrectly owned provider state. The corresponding Cloud change adds the `/completions/compact` proxy route: https://github.com/zed-industries/cloud/pull/3099. The downstream Delta UI integration is https://github.com/zed-industries/delta/pull/1739. ## Testing - `cargo nextest run -p anthropic -p open_ai -p language_models_cloud` - `cargo check -p language_models --tests` - `cargo fmt --all --check` - `git diff --check` The focused tests cover request construction, canonical-window preservation and replay, direct and Cloud transports, automatic compaction lifecycle events, malformed provider state, provider ownership, format compatibility, and HTTP failure handling. ## 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: - Added: System messages are now sent through the `instructions` field in OpenAI Responses API requests. |
||
|
Bennet Bo Fenner
|
e387a55757 |
agent: Show effort selector for anthropic compatible providers (#61579)
Follow up to #57207 Release Notes: - agent: Show reasoning effort selector for anthropic compatible providers if model supports adaptive thinking |
||
|
Anant Goel
|
3a547a44df |
bedrock: Fix duplicated messages and colliding tool call ids from Bedrock Mantle (#60998)
## Problem AWS Bedrock's Mantle endpoint (used for GPT-5.x models via the OpenAI-compatible Responses API) has two independent bugs that both cause visible duplication/corruption in the agent panel: 1. **Duplicated message text.** Mantle streams a reply as a series of new `message` output items, where each new item's text is a growing prefix-superset of the previous one, and the full `output_text.delta` sequence is replayed for each item. Forwarding these events through the shared `OpenAiResponseEventMapper` unmodified caused the assistant's reply (and its phase/reasoning metadata) to appear duplicated in the UI. 2. **Colliding tool call ids.** Mantle assigns raw `tool_use` ids as a simple per-request counter (`call_1`, `call_2`, ...) that resets to `call_1` on every request/response cycle to the model — including separate cycles within a single agent turn as it performs tool calls sequentially. Since `acp::ToolCallId` was built directly from that raw id, and `AcpThread::upsert_tool_call` matches tool calls by id across a thread's entire entry list, a later, unrelated tool call reusing a raw id would silently overwrite an earlier, already-completed one instead of appearing as a new entry — visible as "old tool calls getting replaced by new ones." Both were confirmed against real raw Mantle SSE traces and a real persisted thread (`call_1` recurring across 10+ separate request cycles within a single turn). ## Fix **For message duplication:** `MantleResponseEventMapper` wraps `OpenAiResponseEventMapper` and collapses adjacent, same-phase, strict-prefix message extensions into a single logical message, forwarding only the replayed suffix as ordinary incremental text. - Only adjacent, same-phase, strict-prefix extensions are collapsed. Equal, shrinking, divergent, or different-phase messages are still shown as-is. - Any non-message output item (reasoning, tool call) is a hard boundary: it's forwarded unchanged and clears the merge state, so a message after a tool call is never merged with the one before it. - When a message is merged into the previous one, its `StartMessage` and `ReasoningDetails` metadata events are suppressed, since they'd otherwise duplicate what was already emitted for the first message. **For tool call id collisions:** `scoped_tool_call_id(message_ix, tool_use_id)` combines the raw provider id with the index of the `AgentMessage` it belongs to in `Thread::messages`. That index is stable for the lifetime of one request/response cycle (`flush_pending_message` only runs on the next `StartMessage` event), so ids stay unique across the whole thread without needing the raw provider id itself to be globally unique. The index is threaded through explicitly from where each tool call is created (`handle_tool_use_event`/`run_tool`) to where it's later referenced (`process_tool_result`), rather than recomputed later by re-reading `Thread::messages.len()`. We deliberately did not rewrite the raw `tool_use` id itself at the provider layer to make it globally unique, since that id round-trips back to Mantle verbatim as `call_id` in `function_call_output` items on the next request — rewriting it would require a fragile reverse-mapping on every code path that replays tool results. ## Testing - `cargo test -p language_models --lib bedrock` — 23/23 pass (11 tests covering coalescing, independent messages, phase boundaries, tool/reasoning boundaries, chained cumulative extensions, and metadata deduplication). - `cargo test -p agent --lib` — 699/699 pass (2 new regression tests for tool call id scoping: one via live streaming across two request cycles in one turn, one via persistence/`Thread::replay()` across two separate turns). - `script/clippy -p language_models -p agent` — clean. Release Notes: - Fixed duplicated assistant replies and colliding tool calls when using GPT-5.x models on Amazon Bedrock's Mantle endpoint |
||
|
ummon-v
|
50b773f78e |
Add reasoning effort support for Mistral models (#61393)
# Objective Follow-up to #60898 (as suggested by @tomhoule ). That PR marked `mistral-medium-latest` as supporting thinking, but the flag is currently a no-op: unlike Magistral, whose reasoning was native, Mistral Medium 3.5 and Small 4 only emit thinking chunks when the request sets `reasoning_effort: "high"` (see [Mistral's reasoning docs](https://docs.mistral.ai/studio-api/conversations/reasoning)), and the `Request` struct had no such field. Related: #57581 ## Solution - Add a `ReasoningEffort` enum and an optional `reasoning_effort` field to the Mistral `Request`. The field is skipped during serialization when `None`, so requests for non-reasoning models (Codestral, Large, Ministrals) are byte-identical to before. - Set `reasoning_effort: "high"` in `into_mistral()` when the model supports thinking and the request allows it. The rest of the pipeline already works: `MistralEventMapper` handles `MessagePart::Thinking` deltas, and `into_mistral` replays thinking parts into history, matching Mistral's requirement to replay the reasoning trace across turns. - Add `mistral-small-latest` to `supports_thinking()`: it now points to Mistral Small 4, a hybrid reasoning model like Medium 3.5. - Cover the Ministral variants in `Model::from_id()`, which previously rejected `ministral-3b-latest` / `ministral-8b-latest` / `ministral-14b-latest` as invalid ids even though the enum defines them. ## Testing - Added `test_into_mistral_reasoning_effort` covering the three cases: thinking model with thinking allowed (sends `high`), thinking model with thinking disallowed (omits the field), and non-thinking model (omits the field). - Existing Mistral provider tests pass (`cargo test -p language_models mistral`); both touched crates are clippy-clean. - Reviewers can test by configuring a Mistral API key, selecting `mistral-medium-latest` or `mistral-small-latest` in the agent panel, and confirming thinking blocks stream in; with a non-reasoning model like Codestral, requests are unchanged. ## Self-Review Checklist: - [x] I've reviewed my own diff for quality, security, and reliability - [ ] Unsafe blocks (if any) have justifying comments - [ ] 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: - Fixed thinking not being triggered for Mistral Medium 3.5 and Mistral Small 4, and fixed custom Mistral configurations rejecting Ministral model ids |
||
|
Jiby Jose
|
48a2860372 |
agent: Add GPT 5.6 Luna for ChatGPT subscription (#61083)
GPT 5.6 Luna now passes properly though the codex backend --- Release Notes: - agent: Added GPT 5.6 Luna support for ChatGPT subscription |
||
|
Ibrahim KhanandAnant Goel
|
48ba4bada2 |
bedrock: Add GPT-5.6 Sol, Terra, and Luna Mantle models (#61008)
# 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> |
||
|
zerx-labandBennet Bo Fenner
|
f2c6ebf1e5 |
Allow configuring adaptive thinking for Anthropic available_models (#57207)
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> |
||
|
|
a9a23410d7 |
lmstudio: Fix context wheel by including token usage in streaming responses (#57861)
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> |
||
|
Nakano KenjiandBennet Bo Fenner
|
5c48f982fe |
anthropic: Allow configured models to opt into fast mode (#58225)
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> |
||
|
Bennet Bo Fenner
|
f52f557b11 |
agent: Add GPT 5.6 Sol/Terra for ChatGPT subscription (#60743)
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 |
||
|
Bennet Bo FennerandChristopher Biscardi
|
e71f6da86a |
open_ai: Add GPT 5.6 models (#60697)
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> |
||
|
Ben Kunkle
|
aec35a284c |
language_model: Add OpenAI Responses API custom tool support (#60638)
# 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
|
||
|
Anant Goel
|
f47073a215 |
bedrock: Add native support for Bedrock Mantle models (#60480)
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. |
||
|
Vlad Ionescu
|
114307768e |
opencode: Model updates + fixes (#60526)
**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 |
||
|
Bennet Bo Fennerandcameron
|
866babd389 |
agent: Show errors when provider is not authenticated but model is configured (#60417)
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> |
||
|
ArtinandSmit Barmase
|
03d11509fa |
Reduce OAuth scope to avoid Windows credential size limit (#58541)
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> |
||
|
Yi LiuandSmit Barmase
|
2f2abbf7f5 |
language_models: Avoid sending Bedrock cache-point-only messages (#59436)
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>
|
||
|
Edvard HøibyandNeel
|
d3cd53e134 |
Add Claude Fable 5 to Amazon Bedrock (#59016)
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 What: <img width="644" height="445" alt="image" src="https://github.com/user-attachments/assets/b1b01f7d-8ee9-448c-a8c7-ae80c16326e4" /> Tested towards EU region off AWS. Makes Claude Fabel 5 accessible through bedrock. To enable Fable you need to opt in to `provider_data_share` in AWS. [AWS Docs](https://docs.aws.amazon.com/bedrock/latest/userguide/model-card-anthropic-claude-fable-5.html) Release Notes: - Added Claude Fable 5 to the Amazon Bedrock provider. --------- Co-authored-by: Neel <neel@zed.dev> |
||
|
Bennet Bo Fenner
|
e005d148de |
Refactor agent settings UI code (#60274)
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 |
||
|
|
c497b393a1 |
settings_ui: Add OpenAI/Anthropic API-compatible provider form (#60195)
Release Notes: - N/A --------- Co-authored-by: zed-zippy[bot] <234243425+zed-zippy[bot]@users.noreply.github.com> Co-authored-by: Danilo Leal <daniloleal09@gmail.com> |
||
|
|
1d49ff0d33 |
settings_ui: Remove feature flag for AI settings and adjust design (#59860)
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> |
||
|
Ben Brandt
|
5cbea119c5 |
language_models: Rename llama.cpp provider ID (#60112)
Release Notes: - N/A |
||
|
célinaandBen Brandt
|
c93d478488 |
Add llama.cpp as a language model provider (#59964)
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> |
||
|
Tom Houlé
|
8d21284fbb |
language_models: Surface disabled cloud models (#59781)
Extends the support for disabled model state introduced in https://github.com/zed-industries/zed/pull/59606 to Zed Cloud hosted models. Release Notes: - N/A |
||
|
Vlad Ionescu
|
c0f6d84238 |
ai: Add Max reasoning effort (#59806)
# 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 |
||
|
James St-PierreandAnant Goel
|
b0a4efb150 |
open_router: Add prompt caching for Anthropic models (#57498)
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> |
||
|
Sergei RazmetovandAnant Goel
|
6bd3535308 |
language_models: Set support_thinking in Responses API for OpenAI-compatible provider (#59213)
# 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> |
||
|
|
8167681779 |
ollama: Don't abort entire model fetch if one model's details fail to load (#59606)
## 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> |
||
|
Jiby Jose
|
515042eb4d |
Fix compaction happening too early for chatgpt_subscribed (#59686)
# 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. |
||
|
Marshall Bowers
|
57f456c68e |
cloud_api_types: Add ZedVip variant to Plan (#59443)
This PR adds a new `ZedVip` variant to the `Plan` enum. Closes CLO-881. Release Notes: - N/A |
||
|
Anant Goel
|
381dc0bbe3 |
language_models: Clear speed for OpenAI-compatible providers that don't support fast mode (#59496)
`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 |
||
|
Cameron Mcloughlin
|
1b61228523 |
Settings UI agent providers (#58876)
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 ... |
||
|
Agus Zubiaga
|
01b6149a36 |
Support provider-side compaction in the language model clients (#59145)
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 |
||
|
Tom Houlé
|
3d058c4069 |
agent_ui: Fix reporting of 401/403 errors (#59119)
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. |