yenru0/zed
1
0 Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
40,151 Commits 5 Branches 0 Tags
main
Commit Graph
578 Commits
Author SHA1 Message Date
yenru0 fe62a99bf5 gwen: Purge remaining Zed branding from user-facing surfaces 
Sweep every user-visible product string to Gwen: app menus (Quit,
Hide, Gwen Repository), feedback links (repo/issues now point at
github.com/kk376/zed, email to yenru@yrkaierx.com), move-to-Applications
and update dialogs, provider and settings copy, CLI help, installer and
desktop/flatpak/snap/plist metadata.

Rename user-facing settings values with back-compat aliases: base_keymap
"Gwen" (accepts "Zed"), fonts ".GwenMono"/".GwenSans" (accept
".ZedMono"/".ZedSans"), icon theme "Gwen (Default)". Fix F10
app-menu keymap arguments to "Gwen" and align the Windows installer
AppMutex with release_channel::app_identifier(). Internal identifiers,
wire protocol names, upstream service URLs and legal attribution are
intentionally kept.
 2026-09-29 09:24:34 +09:00
yenru0 eb2c399f24 gwen: Sweep remaining user-visible Zed strings 2026-09-23 10:16:19 +09:00
Agus Zubiaga c5d6f0b2ca language_model: Allow explicit prompt cache keys (#64460) 
## Objective

Related conversations can’t share an OpenAI cache key without also
sharing a thread ID. We currently derive `prompt_cache_key` directly
from `thread_id`, tying cache reuse to conversation identity.

## Solution

Add an optional `prompt_cache_key` to `LanguageModelRequest` and use it
in both OpenAI Chat Completions and Responses conversions. We still fall
back to `thread_id` when no key is supplied, so existing callers keep
their current behavior.

This lets callers share a cache key across parent and child
conversations while keeping their conversation and transport identities
separate.

## Testing

Added regression coverage for explicit keys, legacy fallback, provider
capability gating, and serialization compatibility.

## 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
- [x] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable

Release Notes:

- N/A
 2026-09-18 18:44:49 +00:00
Anant Goel 30ba5d4ddb open_ai: Add GPT-6 Astra API support (#64420) 
## Objective

Make GPT-6 Astra selectable through the OpenAI API-key provider. The
built-in catalog omitted it, even though it was available through the
separately fetched ChatGPT subscription catalog.

## Solution

Add `gpt-6-astra` with its documented context/output limits, reasoning
efforts, image support, and Responses capabilities. Existing model
defaults remain unchanged.

Handle two API compatibility differences found during review: Astra
rejects `temperature`, and its Fast-mode responses return `service_tier:
"fast"` even when requested as `"priority"`. Both request converters now
omit Astra's temperature, and response decoding accepts the new spelling
while preserving legacy serialization. Two focused regressions cover
these failures without duplicating the catalog declaration.

References: [Astra
model](https://developers.openai.com/api/docs/models/gpt-6-astra),
[migration
guide](https://developers.openai.com/api/docs/guides/latest-model?model=gpt-6-astra),
[Fast mode](https://developers.openai.com/api/docs/guides/fast-mode).

## Testing

- `corgi test -p open_ai --lib`: 88 passed.
- `corgi check -p language_models --lib`: passed.
- `corgi fmt -p open_ai -p language_models -- --check` and `git diff
--check`: passed.
- Live API probes confirmed model availability, a successful Responses
function-tool call with parallel calls enabled, the `fast` response
spelling, and rejection of configured temperature.
- During development, Delta's existing API-key catalog test passed with
a temporary local dependency override and an Astra frontier expectation.
The override was removed; Delta's dependency bump is separate.
- Validation was on macOS. No interactive picker, browser, or Cloud
Runner workflow was exercised; image input, compaction, and Fast-mode
regional availability were checked against the docs rather than live
workflows.

## Before merge

The README contains the repository-required human-review confirmation
marker. The author must remove it after reviewing. Delta will need a
separate dependency bump after this change lands. Cache-preserving
reasoning-effort updates are outside this change.

Release Notes:

- Added GPT-6 Astra to the OpenAI API-key model picker.
 2026-09-18 05:32:51 +00:00
Finn Evers 20d55798db Fix cargo shear warnings (#64340) 
Also updates CI to always run this - that way we ensure that disabling
or enabling tests does not become stale at some point and thus can
safely add this.

Release Notes:

- N/A
- [GPUI] N/A
 2026-09-17 08:49:31 +00:00
Xiaobo LiuBennet Bo FennerBennet Bo Fenner
 		1469507d1b deepseek: Update DeepSeek Flash to V4.1 (#64014) 
# Objective

deepseek API: https://api-docs.deepseek.com/updates/

## Solution

deepseek rename deepseek v4 flash to deepseek flash



https://github.com/user-attachments/assets/72c473c9-a4bf-49e0-a7d6-0217a6dcc65b


---

Release Notes:

- agent: Added support for DeepSeek Flash 4.1

---------

Signed-off-by: Xiaobo Liu <cppcoffee@gmail.com>
Co-authored-by: Bennet Bo Fenner <bennetbo@gmx.de>
Co-authored-by: Bennet Bo Fenner <bennet@zed.dev>
 2026-09-16 09:49:13 +00:00
marius851000andBennet Bo Fenner 78de9335df ollama: Make tool call image output accessible to the model (#64121) 
# Objective

- Tool call can output image. Ollama did not support that, and dropped
them when generating the Ollama request. The images are now properly
added.
- Fixes #64054 

## Solution

- Convert the data from Zed’s internal structure to Ollama’s structure
- Should avoid allocation if there is no images (the most common path)
(untested).

## Testing

- Tested with qwen3.6:35b via Ollama. It can read and describe image,
with query such as "Describe zébrette_le_matin_22_novembre_1913.jpg"
(the file not being directly embedded). The agent use the read_file
tool.

## Self-Review Checklist:

- [x] I've reviewed my own diff for quality, security, and reliability
- [x] Unsafe blocks (if any) have justifying comments (there are none)
- [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) (no UI changes)
- [ ] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable

## Showcase

<details>
  <summary>Transcription of a test query</summary>

## User

Describe zébrette_le_matin_22_novembre_1913.jpg

## Assistant

<thinking>
The user is asking me to describe an image file:
"zébrètte_le_matin_22_novembre_1913.jpg". This appears to be a
newspaper/magazine cover or page from "Le Matin" dated November 22,
1913. I need to read this image file to see what's in it. Let me find it
first.
</thinking>

Let me locate and examine that image file first.

**Tool Call: No matches**
Status: Completed

```json
{
  "offset": 0,
  "current_matches_page": [],
  "all_matches_len": 0
}
```

## Assistant

<thinking>
Let me try different variations of the filename.
</thinking>

**Tool Call: 1 match**
Status: Completed

file:///home/marius/sec/a/z%C3%A9brette_le_matin_22_novembre_1913.jpg

## Assistant

<thinking>
Found it. Let me read the image file.
</thinking>

**Tool Call: Read file `zébrette_le_matin_22_novembre_1913.jpg`**
Status: Completed

`Image`

## Assistant

<thinking>
Now I can describe the image. It's a black-and-white illustration from
what appears to be a French newspaper ("Le Matin" dated November 22,
1913).

The image depicts an elegantly dressed woman descending a staircase. She
is wearing:
- An elaborate headdress with what looks like ostrich feathers or plumes
- A decorative crown or tiara
- Long earrings
- Multiple strands of pearls around her neck
- A flowing, ornate dress with fur trim (a stole/cape)
- A long necklace

The style is Art Nouveau/Art Déco. She appears to be a society figure
attending some gala or fancy dress event. The illustration has a
halftone dot pattern typical of newspaper printing from that era.


I'm wondering what "zébrètte" refers to—it might be the name of the
person depicted, the caption associated with this illustration, or
perhaps a specific fashion item.
</thinking>

## Description: *Zébrètte* (Le Matin, 22 novembre 1913)

This is a black-and-white newspaper halftone illustration from the
French daily **Le Matin**, dated November 22, 1913. It depicts an
elegantly dressed woman descending a staircase — likely covering a
high-society or gala event.

### Key details:

- **Headdress**: The most striking feature is an elaborate plumed hat
with large ostrich-style feathers rising above her head, paired with a
decorative crown/tiara.
- **Attire**: She wears a flowing gown adorned with ornate patterns,
draped under a luxurious fur-trimmed stole (or capelet). Her dress has
intricate embellishments on the bodice and legs of the skirt.
- **Accessories**: Multiple strands of pearls around her neck, long
dangling earrings, and an additional long necklace chain add to the
opulent look.
- **Pose & setting**: She steps down a staircase with a swirling Art
Nouveau–style railing behind her, suggesting she has just arrived at or
is leaving a grand event (a ball, premiere, or society gathering).
- **Artistic style**: Rendered in a sketchy, expressive line-drawing
style typical of early 20th-century French illustration. The halftone
dot pattern reveals it was printed in a newspaper.

The caption title *"Zébrètte"* likely refers to either the nickname of
the woman depicted or a costume/carnival reference (suggesting "striped"
or zebra-print), though without the surrounding text from the original
page, that detail remains ambiguous.

---

The image in question, I had used as an illustration for one my blog
post, as said by the AI from the Le Matin of the 22 november 1913, via
Gallica
(https://mariusdavid.fr/blog/z%C3%A9bressez%C3%A9brellez%C3%A9brette/)

<img width="944" height="2488" alt="image"
src="https://github.com/user-attachments/assets/3075a56e-b1ec-4906-ab8e-97d32400dc75"
/>


</details>

---

Release Notes:

- Fixed Ollama not being able to access images from tool call

---------

Co-authored-by: Bennet Bo Fenner <bennetbo@gmx.de>
 2026-09-16 09:00:29 +00:00
Thibaud Guillaume-Gentil fc13b40a69 language_models: Add SuperGrok OAuth provider (#63248) 
# Objective

Grok in the agent is BYOK only today (`x_ai` plus an API key from
console.x.ai). SuperGrok is a separate subscription, so you either pay
twice or you skip Grok in Zed. This makes SuperGrok a first-class LLM
provider, same idea as ChatGPT Subscription or GitHub Copilot Chat.

Discussion:
https://github.com/zed-industries/zed/discussions/63114#discussioncomment-18158663

## Solution

Adds a SuperGrok provider next to the API-key one. Sign in / Sign out is
in Settings → AI → LLM Providers, same shape as ChatGPT Subscription.
Tokens go in the OS keychain, not settings.json.

Shipped models: Grok 4.6 (default), Grok 4.5, Grok Build 0.1. Reasoning
effort on 4.5/4.6 matches the BYOK xAI provider (no `none`, default
high, 4.6 has xhigh). Some Grok plans still get HTTP 403 after a
successful login. The error says the account cannot use this API and
points at the API-key provider.

## Testing

I have been running this locally for a few days on macOS 27 (public
beta) with a SuperGrok Heavy subscription. No issues so far.

`cargo test -p x_ai_subscribed --lib` and `cargo test -p language_models
--lib provider::x_ai_subscribed` pass.

## 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

SuperGrok LLM provider settings:

<img width="956" height="816" alt="Screenshot 2026-08-26 at 13 41 17"
src="https://github.com/user-attachments/assets/ef2d464a-66ad-416a-a924-725a18d41164"
/>

---

Release Notes:

- Added SuperGrok sign-in so a SuperGrok subscription can use Grok
models in the agent
 2026-09-16 07:01:45 +00:00
MartinYe1234 616ac232d4 Add provider-backed input token counting (#64194) 
## Stack

Part 2 of the split. #64047 is merged, and this PR now targets `main`.
Current main was merged into this branch without rewriting history. The
diff contains only counting/consent work and the required README review
acknowledgment (8 files, +837/-80). The Copilot metadata sibling #64195
does not depend on this PR.

## Summary

Add optional provider-backed input counting for direct Anthropic, direct
OpenAI Responses, and hosted Anthropic/OpenAI models. Preserve
structured input and reuse provider conversion, authentication refresh,
and client request limiting. Unsupported providers return `None`;
provider and malformed-response errors remain visible.

Keep the existing hosted data-retention consent rule common to counting,
native compaction, and generation. Counting never sends input before
consent. The matched Cloud endpoint support is merged; its deployment
remains a prerequisite for downstream callers.

This PR does not change Copilot prompt/context metadata, compaction
thresholds, or tooltips. No chunking or paid tests are introduced.

## Validation

- After resolving the main merge: 226 tests passed across anthropic,
open_ai, language_models, and language_models_cloud. Main’s consolidated
output-limit tests and renamed serialization test are preserved.
- Scoped script/clippy passed for anthropic, open_ai, language_models,
and language_models_cloud.
- Formatting and whitespace checks passed.
- Coverage includes images, structured request fields, authenticated
hosted requests, unsupported providers, error propagation, and consent
rejection before HTTP.
- No live provider calls were made.

Release Notes:

- Fixed data-retention consent checks for hosted counting and compaction
requests.
 2026-09-15 14:52:14 +00:00
MartinYe1234 411b31e9a5 Add per-request model output limits (#64047) 
## Stack

- This PR: output-limit plumbing, based on `main`.
- #64194: provider input counting and consent, based on this branch.
- #64195: Copilot metadata and consumers, independently based on this
branch.

After this PR lands, rebase/retarget both children onto `main` as
needed, especially after a squash merge. At split time, a synthetic
merge of the two child heads exactly matched the saved pre-split source
tree. PR1 has since consolidated overlapping tests without changing
production code.

## Summary

Part 1 of a three-PR split: add optional per-request
`max_output_tokens`, forward it through provider payloads, and clamp it
against known output limits. Unset requests preserve existing defaults.
Unknown Copilot output metadata is not treated as a zero-token maximum
when forwarding a cap.

This PR also supplies the combined-window and native-capability
interfaces used by downstream budget calculations. It does not add
input-token counting, data-retention consent integration, or change
Copilot prompt/context metadata, compaction thresholds, or tooltips.
Those changes are split into two child PRs based on this branch.

The net diff is 24 files, +438/-55. Forward narrowing commits preserve
the original review history; there was no force-push.

## Test consolidation

Eight overlapping standalone tests have been folded into existing
conversion tests, preserving coverage of unset limits, explicit limits,
clamping, and serialized payloads. Four distinct tests remain separate:
request serialization compatibility, Copilot wire formats, DeepSeek
conversion (no existing conversion suite), and hosted OpenAI
normal-completion HTTP behavior. This cleanup changes no production Rust
code.

## Validation

- Latest run: 269 tests passed across anthropic, google_ai, open_ai,
language_models, copilot_chat, and language_models_cloud.
- Five extended existing tests failed when cap selection was temporarily
broken and passed after restoration. No mutations remain.
- Latest scoped script/clippy, formatting, and whitespace checks passed.

Earlier split validation:

- 229 tests passed across language_model_core, anthropic, open_ai,
copilot_chat, and language_models_cloud.
- Scoped script/clippy passed for copilot_chat, language_models_cloud,
language_models, agent, and agent_ui.
- Formatting and whitespace checks passed.
- Permanent tests cover payload propagation, absent/explicit limits,
unknown output metadata, direct and hosted native-compaction caps, and
hosted OpenAI clamping.
- No live provider requests were made for the split.

## Review notes

The separately identified fixed/non-interleaved thinking-budget versus
smaller output-cap concern remains open in this PR; it must not be
hidden in the counting or metadata PRs. The README acknowledgment is
retained for human review.

Downstream applications using input counting must consume the counting
child PR as well, not repin to this branch alone.

Release Notes:

- N/A
 2026-09-14 20:15:15 +00:00
Katie Geer 797fa3b3d9 Update Zed trial copy for the $5 GPT Luna offer (#63969) 
## Summary

Updates Zed trial copy for
[CLO-1373](https://linear.app/zed-industries/issue/CLO-1373/update-zed-to-show-the-dollar5-gpt-luna-trial).

- Show $5 of GPT Luna and unlimited edit predictions across pre-sign-in,
Free-plan, and active-trial onboarding.
- Clarify that the 14 days begin when the trial starts, rather than when
the welcome panel is viewed, and retain no-credit-card messaging.
- Update hosted-model trial descriptions and use "Start Free Trial" for
onboarding and AI configuration trial CTAs.
- Document GPT Luna-only trial hosted-model access and the shared
Zed/Delta $5 trial balance.

This is a copy-only change. Trial eligibility, subscription creation,
trial timing, billing, model-access enforcement, button actions, URLs,
and telemetry are unchanged. Paid, Student, Business, and VIP plan
descriptions are unchanged. This does not implement the offer on the
backend.

## Verification

- Rust formatting and `git diff --check` passed.
- Prettier check passed for the pricing documentation.
- Source checks confirmed the offer wording and unchanged callbacks,
URLs, telemetry, and other plan definitions.
- Katie built and launched Zed with `cargo run -p zed --bin zed`, then
reviewed Component Preview and requested the final CTA wording.
Formatting and diff checks were rerun after that wording adjustment; the
final adjustment has not been rebuilt.
- Confirmed the branch merges cleanly with the latest `main`.

Release Notes:

- Improved trial descriptions to show $5 of GPT Luna and unlimited edit
predictions for 14 days from trial start.
 2026-09-09 14:50:23 +00:00
morgankreyKirill BulatovChristopher Biscardi
 		342bafafee Send session headers on all OpenCode requests (#63702) 
Fixes https://github.com/zed-industries/zed/issues/63672

OpenCode Go now requires the `x-opencode-session` header on every model
request. Zed previously sent the header only when a request already had
a thread ID, so inline assistance, terminal assistance, and other
standalone requests could omit it and risk rejection.

This change makes the OpenCode provider add the header to every request.
Existing thread and assist session IDs are reused when available.
Standalone requests receive a generated non-empty ID. Thread title and
summary requests now carry the thread ID so related requests keep the
same session scope.

The change also adds tests for missing, empty, and invalid IDs, plus a
wire-level test that verifies the header reaches the HTTP client. The
provider test file stays separate so the implementation remains under
1,000 lines.

Testing:

- `cargo fmt --all -- --check`
- Focused OpenCode, thread summary, and thread title tests
- `cargo check -p agent_ui -p sidebar`
- `GITHUB_ACTIONS=1 ./script/clippy -p language_models`
- `git diff --check`

Release Notes:

- Fixed OpenCode Go requests that could fail when Zed omitted the
session header.

---------

Co-authored-by: Kirill Bulatov <kirill@zed.dev>
Co-authored-by: Christopher Biscardi <chris@christopherbiscardi.com>
 2026-09-03 18:29:10 +00:00
tidelyandMrSubidubi 32a0e6b48b settings_ui: Fix layout issues with recently created GitHub accounts (#63630) 
# Objective

Fixes #62169

Accounts which are marked "too young" have layout issues within the LLM
settings. Example provided in the linked issue.

## Solution

Allow the provider controls to shrink to the available width instead of
retaining their content width. Also make the young-account configuration
fill that width so the warning wraps correctly without collapsing the
provider description.

I think the "Upgrade to Pro" looks a little stretched now, but I don't
know how to fix it without allocating even more space for the already
large setting section. Could we possibly shorten the 30-day requirement
explanation? Regardless, it's much better than what it was before :D

## Testing

- I added a debug selector to be able to write a regression test for
layout issues. Since the UI may change, the tests only enforce the rough
layout.
- Compiled with `too_young_account` being `true` and `false`, checking
that the UI looks okay.


## 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

<details>
  <summary>Click to view showcase</summary>

Before:

<img width="639" height="678" alt="image"
src="https://github.com/user-attachments/assets/45ed32b0-8987-49d1-8bbd-a12f7917570a"
/>


After:

<img width="640" height="225" alt="image"
src="https://github.com/user-attachments/assets/bb39a847-7d36-4597-b16d-6a6ccb872817"
/>

</details>

---

Release Notes:

- Fixed layout issues in settings when using recently created GitHub
accounts

---------

Co-authored-by: MrSubidubi <finn@zed.dev>
 2026-09-03 15:16:07 +00:00
Finn EversandAnant Goel af2c5b36c7 Unify language model event stream handling (#63520) 
Closes https://github.com/zed-industries/zed/issues/63314
Closes https://github.com/zed-industries/zed/issues/42584

Follow-up to https://github.com/zed-industries/zed/pull/62652

Removes a lot of duplicated code in favor of throwing it
into`language_core` as well as removing duplicate struct definitions
that were only different because of entirely unused fields.

Furthermore, improves error-messages so that these untagged enum errors
are no longer a thing in an effort to make this more maintainable in the
future.

Lastly, includes a small but nice improvement changing a `Value` to a
`RawValue` so that we don't have to clone for deserialization in that
specific case.

Release Notes:

- Improved streaming for OpenAI-compatible providers.

---------

Co-authored-by: Anant Goel <anant@zed.dev>
 2026-09-02 15:41:05 +00:00
Neel 16a55e429a language_models: Allow cancelling ChatGPT Subscription setup (#63627) 
On `main`, the only way to interrupt ChatGPT Subscription setup is to
restart Zed.

---

Release Notes:

- Add a button to cancel ChatGPT Subscription setup
 2026-09-02 13:50:06 +00:00
Mikayla Maki cd0241b7e3 anthropic: Handle Claude Fable 5.1 API changes (#63571) 
Claude Fable 5.1 introduces two breaking Messages API changes that
produce 400 errors with request shapes Zed currently sends. This change
adapts the shared Anthropic request path so the model works out of the
box, without restructuring how requests are built.

The first change is thinking-block prefix binding. Fable 5.1 binds each
thinking block to the exact conversation prefix that produced it, and
replaying a block after anything earlier changed (the system prompt, the
tools array, or an edited turn) fails the whole request with a 400
reading "The block is bound to a different conversation". Zed routinely
rebuilds the system prompt and tool list between requests (rules file
changes, profile switches, MCP servers coming online), so this would
surface as a hard error mid-thread. Requests to Fable 5.1 now send the
`thinking-binding-controls-2026-08-01` beta header with
`thinking.block_binding.prefix_mismatch_behavior: "drop_block"`, which
makes the API drop invalidated blocks and continue instead of rejecting
the request. Claude Mythos 5.1 doesn't run this check and is excluded.
The cloud and Copilot Chat paths pass `block_binding: None` since their
proxies control the upstream beta headers; opting in there belongs
server-side.

The second change is that forced tool use (`tool_choice: "any"` or
`"tool"`) now returns a 400. Zed sends `"any"` from inline assist's
streaming-tools path, which is on by default. The Anthropic and
Zed-cloud providers now report `tool_choice: any` as unsupported for
Fable/Mythos 5.1, and inline assist already degrades gracefully to
prompt-guided auto tool choice, which is Anthropic's recommended
migration.

Finally, `claude-fable-5-1` and `claude-mythos-5-1` are added to the
compaction model list. This matters more than a routine table update:
with prefix binding, server-side compaction is the sanctioned way to
trim history without invalidating thinking blocks. Everything else
already carries over via the existing `claude-fable-5` id prefix logic
(data-retention consent, Opus 4.8 refusal fallback, which remains a
permitted fallback target for 5.1). Bedrock is intentionally untouched.

Deeper follow-up work is deferred: keeping conversation history
append-only so blocks aren't invalidated in the first place (turn-scoped
system messages, mid-conversation tool changes) and monitoring
`input_transformations` for drop reporting.

Testing:

- New unit tests covering the `block_binding` wire format (sent for
`claude-fable-5-1` only) and beta-header wiring in `Model::from_listed`.
- `cargo nextest run` for `anthropic`, `language_models`,
`language_models_cloud`, and `copilot_chat`; `cargo fmt --check`.

Release Notes:

- Improved support for Claude Fable 5.1
 2026-09-01 18:58:47 +00:00
Conrad Irwin c67c5c150b Send complete tool JSON schemas to every provider (#63342) 
Zed asked each language model which JSON Schema dialect it wanted, and
rewrote every tool's schema into that dialect before sending it.
`LanguageModelToolSchemaFormat` had grown three variants, and providers
picked between them by model name, so Grok and Gemini took a lossy path
while everything else did not.

The subset exists because Google's `FunctionDeclaration.parameters`
field accepts an OpenAPI-flavored schema rather than JSON Schema, and
`adapt_schema_to_format` tried to translate into it. The translation was
best-effort: constructs it could not represent were left in place and
the function still returned `Ok`. The shape schemars produces for a Rust
`String | Vec<String>` union survives as a nested `anyOf` whose outer
node carries no `type`, and Vertex rejects the entire request over it,
taking every other tool down with it. Where the translation did fail,
the caller logged the error and dropped the tool, so the model silently
lost a capability.

Google now offers `parametersJsonSchema` alongside `parameters`, which
takes plain JSON Schema, and every other provider we ship documents JSON
Schema for function parameters. So the first commit switches
`into_google` to `parametersJsonSchema`, and the second deletes the
dialect: `LanguageModelToolSchemaFormat`,
`LanguageModel::tool_input_format`, `adapt_schema_to_format`, and the
per-model branching in every provider go away, along with
`x_ai::Model::requires_json_schema_subset`.

What remains is `normalize_tool_schema`, which every tool now passes
through. It strips `$schema`, `title`, and `description` from the root,
which no provider reads and which cost tokens; gives an object schema an
explicit `"properties": {}`, which OpenAI requires; and inlines
same-document `$ref`s. That last part is carried over from the deleted
code and matters only for context servers: MCP's Python SDK derives
input schemas through pydantic, which emits `$defs` and `$ref` for any
nested model or enum, and `zod-to-json-schema` emits `definitions` for
reused shapes, while Google rejects references outright. Built-in tools
never contain one, because `root_schema_for` inlines subschemas during
generation. A schema whose references cannot all be resolved is passed
through untouched and the reason logged, so a provider explains what is
wrong instead of receiving something half-rewritten.

## Providers whose behavior changes

| Provider | Models affected | Before | After |
|---|---|---|---|
| Google | all | `JsonSchemaSubset` in `parameters` | full JSON Schema
in `parametersJsonSchema` |
| Zed Cloud | Google, xAI | `JsonSchemaSubset` | full JSON Schema |
| Copilot Chat | Google, xAI, unknown vendors | `JsonSchemaSubset` |
full JSON Schema |
| xAI | Grok 4.3, 4.5, 4.6, 4.20 Reasoning, 4.20 Non-Reasoning |
`JsonSchemaSubset` | full JSON Schema |
| OpenRouter | model ids containing `gemini` or `grok` |
`JsonSchemaSubset` | full JSON Schema |
| Vercel AI Gateway | all | `JsonSchemaSubset` | full JSON Schema |
| OpenAI-compatible | all | `JsonSchemaSubset` | full JSON Schema |
| Bedrock Mantle | all | `JsonSchemaSubset` | full JSON Schema |
| Everything else | — | `JsonSchema` | unchanged apart from
normalization |

One deliberate difference for the last row: the old `JsonSchema` path
also injected `additionalProperties: false` into object roots, and
normalization does not. Nothing depends on it. Serde ignores unknown
fields, so a model inventing an argument never broke deserialization,
and OpenAI's strict function calling — the one feature that requires the
flag — is never enabled: every `ToolDefinition::Function` in the tree
passes `strict: None`. It was also only ever applied on the `JsonSchema`
path, so Google, Grok, Vercel and Bedrock Mantle users never received
it. Dropping it makes behavior uniform rather than removing a guarantee.

## Verification

This was checked against live providers rather than by reasoning about
documentation. A harness in the Delta repository dumps all 24 built-in
tool schemas from this branch and submits them with `tool_choice: none`
to each provider, so the only thing under test is whether the provider
accepts the schemas. Anthropic, OpenAI (chat and responses), Gemini,
xAI, Baseten, OpenRouter (Gemini and Grok), Vercel AI Gateway (Gemini
and Grok), Copilot (Gemini and Grok), the ChatGPT subscription, Bedrock
Converse, Bedrock Mantle (GPT and Grok), and Zed Cloud (Anthropic,
OpenAI, and Google) all accepted them. DeepSeek, Mistral, and OpenCode
were not probed for lack of a key.

The failure this fixes is reproducible on the route that broke. Vertex,
not the Gemini Developer API, is what enforces the constraint: the
harness pins the `grep` declaration production generated, replays it to
Vertex through Zed Cloud in the legacy `parameters` field, and gets back
the exact `INVALID_ARGUMENT` naming `parameters.globs`, while the same
route accepts this branch's schemas through `parametersJsonSchema`. The
Gemini Developer API accepts the broken shape on every model tried, so a
direct API key would never have caught it.

Testing:

- `cargo nextest run -p language_model_core -p google_ai -p agent` for
the schema, `into_google`, MCP and built-in tool tests
- New tests cover reference inlining for the shapes pydantic and zod
produce, recursive references, and unresolvable references
- `built_in_tool_schemas_are_normalized` asserts every built-in tool is
present and normalized
- `crates/agent/examples/dump_tool_schemas.rs` prints the definitions
the harness consumes
- 21 live provider probes with the complete tool set

Release Notes:

- Fixed Gemini rejecting requests because Zed translated tool schemas
into a restricted dialect it could not represent
 2026-08-28 14:06:27 +00:00
Kim WittenburgBennet Bo FennerBennet Bo Fenner
 		2f3ceb37ce open_router: Support effort-based reasoning (#61308) 
# Objective

- This PR adds support for effort-based reasoning for OpenRouter models
- This PR correctly configures whether OpenRouter models support
reasoning or not
- Fixes #58843 (already closed, was converted to #58848 )

## Solution

- The OpenRouter `/v1/models` endpoint includes data about supported
effort levels (see
[docs](https://openrouter.ai/docs/guides/best-practices/reasoning-tokens#discovering-per-model-reasoning-options))
and model capabilities
- This PR uses this data to populate the "effort" dropdown in the agent
panel (compare #56411 which added a similar feature for OpenAI) and to
provide better model metadata (`supports_thinking`,
`supports_disabling_thinking`).
- If a model supports `max_tokens`-based thinking, effort levels will
still be shown. OpenRouter automatically converts effort levels into an
appropriate `max_tokens` budget
([docs](https://openrouter.ai/docs/guides/best-practices/reasoning-tokens#reasoning-effort-level)).
This way users are not limited to a fixed `max_tokens` budget.
- Some models return `"supported_parameters": ["reasoning"]` with
`"reasoning": {"mandatory": false}`. From the docs I am not quite sure
what that's supposed to mean. The PR interprets these models with a
binary thinking on/off switch.

The PR also fixes the inverted logic where
`supports_parallel_tool_calls` would always return `false`, which would
then result in `parallel_tool_calls: None` for the actual API call
(which enables parallel tool calls by default). So the result of
`supports_parallel_tool_calls` was interpreted opposite to what I would
expect. The PR now returns `true` from `supports_parallel_tool_calls`
and adapts the corresponding call. There is no change in behavior
(`parallel_tool_calls` are always enabled in practice), it just fixes
the code logic.

## Testing

I tested the changes manually in an instance started via `cargo run`:
- I tested using GLM 5.2 and GPT 5.5. The reasoning effort is being
shown in the agent panel. Changing the effort level changes the amount
of thinking that the model does (e.g. on "Extra High" I consistently see
thinking blocks, on lower levels I sometimes do. I don't see thinking
blocks when thinking is disabled).
- Some models with `"reasoning": {"mandatory": false}` can be called
with effort levels. I am not sure if it actually makes a difference, but
the API doesn't reject it. Maybe there are configuration options that
are not currently exposed by this PR. I think the approach in this PR is
a safe default though.
- To test this PR:
  1. Build it via `cargo run`
  2. Set an OpenRouter API Key
3. Open the Agent panel and select different models. Notice that the
effort level selector and the thinking toggle is dynamically
shown/hidden/populated based on the model.

## Self-Review Checklist:

- [x] I've reviewed my own diff for quality, security, and reliability
- [x] Unsafe blocks (if any) have justifying comments
- [x] The content 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 support for effort-based reasoning when using OpenRouter models

---------

Co-authored-by: Bennet Bo Fenner <bennet@zed.dev>
Co-authored-by: Bennet Bo Fenner <bennetbo@gmx.de>
 2026-08-26 17:39:50 +00:00
Bennet Bo Fenner 732d67cac8 Move language model stream mapping to background executors (#63241) 
Language model event mappers run as part of lazy completion streams.
Because these streams are polled on the main thread, repairing and
parsing large streamed tool inputs can freeze the UI.

This moves completion stream mapping to background executors. A bounded
channel preserves event order and backpressure, while dropping the
stream cancels its background task. The change covers all providers that
perform this work.

Release Notes:

- Fixed UI hangs when language model providers stream large tool inputs.
 2026-08-26 17:36:06 +00:00
Bennet Bo FennerandYang Yang 42440a5a92 x_ai: Add Grok 4.5 and Grok 4.6 models (#63234) 
Release Notes:

- xAI: Add Grok 4.6 and Grok 4.5 models

Co-authored-by: Yang Yang <geraint0923@gmail.com>
 2026-08-26 08:04:05 +00:00
Conrad Irwin c8518b3317 Preserve language model provider rejection details (#63095) 
Language model providers can reject a request inside an otherwise
successful response stream. Those failures were represented by
overlapping completion-error variants and provider-specific code enums,
and OpenAI Responses errors such as `cyber_policy` fell through to
`Other`. Agent sessions consequently retried permanent provider
rejections and user interfaces lost the provider's actionable message.

This gives every provider-originated failure one shared representation.
`ProviderRejection` preserves the provider, exact message, retry delay,
raw provider code, and an HTTP status only when one was actually
reported. `ProviderErrorCategory` supplies the normalized meaning used
by shared UI and policy code. Provider adapters map their native wire
errors into that category explicitly, so typed SDK exceptions and errors
embedded in successful streams no longer fabricate HTTP statuses.

Retry selection is independent from error construction.
`LanguageModelCompletionError::retry_delay` owns transient
classification and a bounded schedule of 5, 10, 20, then 40 seconds. A
provider-supplied `retry_after` overrides that schedule. The scheduling
layer adds positive jitter of up to 10%, while interactive requests and
evaluation runs retain their own attempt budgets. Permanent status-less
errors such as `cyber_policy` do not retry. OpenRouter also keeps its
numeric body code distinct from an optional HTTP status, including for
errors embedded in a stream.

Testing performed:

- `corgi test -p language_model_core`
- `corgi test -p anthropic` (33 tests)
- `corgi test -p open_ai` (77 tests)
- `cargo nextest run -p open_router -p copilot_chat -p
language_models_cloud -p language_models` (125 tests)
- `cargo nextest run -p agent -p agent_ui` (1,153 tests; 11 skipped)
- `cargo check -p open_router -p copilot_chat -p language_models_cloud
-p language_models -p agent -p agent_ui`
- `./script/clippy -p language_model_core -p anthropic -p open_ai -p
open_router -p copilot_chat -p language_models_cloud -p language_models
-p agent -p agent_ui` completed the release Clippy phase; Cargo Shear
then reported the repository's existing warnings
- `cargo fmt --all --check`

Suggested .rules additions

None.

Release Notes:

- Fixed permanent language model provider rejections being retried and
displayed without their actionable provider message.
 2026-08-24 19:36:04 +00:00
Conrad Irwin a637a0a25d language_model: Include hosts in transport errors (#62990) 
Language model transport errors currently retain only a provider display
name after an HTTP request fails. Downstream clients therefore cannot
tell users which configured endpoint was unreachable without parsing the
source error or hard-coding provider names.

Make the request hostname a required part of
`LanguageModelCompletionError::HttpSend` and preserve it through the
Anthropic, OpenAI-compatible, OpenRouter, Vercel AI Gateway, and Zed
Cloud transports. Each transport captures the parsed hostname from the
request URI before sending it, using the configured base URL as the
defensive fallback. This supports production, development, and custom
endpoints without string matching.

Tests exercise transport failures through the real request paths and
verify hostnames for Anthropic, ChatGPT Subscription, generic
OpenAI-compatible providers, and Zed Cloud.

Testing:

- `cargo fmt --check`
- `cargo nextest run -p anthropic -p open_ai -p open_router -p
language_models_cloud -p language_models` — 209 tests passed
- `cargo check -p agent -p agent_ui --all-targets`
- `git diff --check`
- `./script/clippy -p language_model_core -p anthropic -p open_ai -p
open_router -p language_models_cloud -p language_models` — clippy
passed; the script subsequently failed in the repository-wide `cargo
shear --deny-warnings` step on 203 pre-existing target and doctest
configuration warnings

Release Notes:

- Improved language model connection errors to identify the unreachable
host.
 2026-08-21 14:53:09 +00:00
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>
 2026-08-20 10:08:48 +00:00
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>
 2026-08-19 11:07:38 +00:00
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.
 2026-08-18 03:44:43 +00:00
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>
 2026-08-17 04:27:38 +00:00
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.
 2026-08-17 00:54:13 +00:00
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>
 2026-08-14 22:42:27 +00:00
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.
 2026-08-14 20:44:17 +00:00
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
 2026-08-14 09:38:52 +00:00
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>
 2026-08-11 15:37:15 +00:00
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
 2026-08-10 09:16:24 +00:00
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
 2026-08-05 11:17:54 +00:00
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
 2026-07-31 15:06:40 +00:00
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 a8b25c3 ==========
2026-07-30T22:11:38+05:30 WARN  [zed::reliability::hang_detection] debug build, only reporting hangs longer then 5s
2026-07-30T22:11:38+05:30 WARN  [zed::reliability] Minidump endpoint not set
2026-07-30T22:11:38+05:30 INFO  [zed::reliability] memory usage: resident 104 MiB, virtual 426360 MiB
2026-07-30T22:11:38+05:30 INFO  [extension_host] extensions updated. loading 2, reloading 0, unloading 0
2026-07-30T22:11:39+05:30 INFO  [prompt_store::rules_to_skills_migration] Rules-to-skills migration already marked done; skipping startup migration
2026-07-30T22:11:39+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-30T22:11:39+05:30 INFO  [workspace] Rendered first frame
2026-07-30T22:11:40+05:30 INFO  [git::repository] opening git repository at ".../zed/.git" using git binary "/usr/bin/git"
```

Release Notes:

- Fixed a noisy "Failed to authenticate provider: ChatGPT Subscription"
error being logged on every startup for users who have not configured
the ChatGPT Subscription provider

Co-authored-by: Claude Sonnet 5 <noreply@anthropic.com>
 2026-07-30 20:07:31 +00:00
Bennet Bo Fennercameronzed-zippy[bot]
 		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>
 2026-07-30 10:34:16 +00:00
Bennet Bo Fenner be07d51f8d Move OpenAI subscription code to separate crate (#61787) 
Release Notes:

- N/A
 2026-07-28 14:17:18 +00:00
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.
 2026-07-24 19:56:07 +00:00
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.
 2026-07-24 16:53:45 +00:00
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
 2026-07-24 12:48:41 +00:00
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
 2026-07-23 18:40:30 +00:00
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
 2026-07-21 14:51:27 +00:00
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
 2026-07-16 07:43:30 +00:00
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>
 2026-07-15 16:31:19 +00:00
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>
 2026-07-14 15:04:47 +00:00
Gabriele AncillaiGabriele AncillaiBennet Bo Fenner
 		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>
 2026-07-10 15:32:21 +00:00
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>
 2026-07-10 15:01:47 +00:00
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
 2026-07-10 08:10:51 +00:00
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>
 2026-07-09 17:37:43 +00:00
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
 2026-07-09 12:05:50 +00:00