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.
## 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
# 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>
## 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
## Summary
Replace GPUI's shared asset futures with owning cache entries. The
mutex-backed waiter collection in futures::future::Shared can contend
between a worker and the browser main thread, where blocking waits are
forbidden.
- Keep loading on the background executor, with one foreground task
publishing the cached result and notifying interested views.
- Deduplicate loads and view registrations; cancel pending work on
eviction without allowing completion to update a replacement entry.
- Change App::fetch_asset to return Option<A::Output>, remove
ImageLoadingTask, and make ImageCacheItem an opaque owning entry.
- Migrate the retain-all image cache and image gallery LRU example.
Repository-wide search found no further callers requiring migration.
Results become visible after the foreground completion task publishes
them. Entries expose neither cloneable nor awaitable task handles.
Release Notes:
- N/A
OpenAI's Codex endpoint reports an exhausted ChatGPT subscription with
HTTP 429 and `error.type = "usage_limit_reached"`, but no `error.code`.
The Responses parser discarded the type and classified the response from
its status alone, making it appear to be transient request throttling.
This preserves `error.type` in both Responses and Chat Completions
parsing, considers both OpenAI discriminator fields during
classification, and falls back from the more-specific `error.code` to
`error.type` when populating the existing provider rejection code.
Usage-limit errors retain OpenAI's message and are not retried as
transient 429s.
The regression coverage exercises initial HTTP failures, Responses
stream errors, Chat Completions stream errors, unknown OpenAI-compatible
provider types, and precedence when both code and type are present.
Release Notes:
- Fixed ChatGPT subscription usage limits being shown as temporary
OpenAI request throttling.
OpenAI can return HTTP 404 during temporary service disruptions, but
language model errors currently classify that status as permanently
missing. Treat OpenAI 404 responses as transient while leaving other
providers unchanged, and expose the shared transient classification so
retry executors can consume it directly instead of inferring it from a
first-attempt delay.
Release Notes:
- Improved recovery when OpenAI temporarily returns HTTP 404 errors.
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>
Anthropic reports a context-window overflow with HTTP 400 and a message
of the form `prompt is too long: N tokens > M maximum`. The
`BAD_REQUEST` arm of `ProviderErrorCategory::from_http_status` only
recognized OpenAI's phrasings (`context_length_exceeded`, "exceeds the
context window"), and `parse_prompt_too_long` only ran for HTTP 413, so
these rejections were classified as `InvalidRequest` instead of
`PromptTooLarge`. This affects every wire path that classifies by
upstream HTTP status, including Zed cloud's `upstream_http_400` code,
and it silently disables any downstream handling keyed on the
`PromptTooLarge` category. This change sniffs the Anthropic phrasing on
400 responses too, carrying the provider-reported token count.
Closes AI-462
Release Notes:
- Fixed Anthropic "prompt is too long" errors reported with HTTP 400 not
being recognized as context-window overflows.
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
OpenAI can return structured provider failures either as Responses
stream events or as non-success HTTP responses. The streaming path
classified the provider's error code, while the HTTP path treated the
body as opaque and classified only its status. As a result, exhausted
credit could look like a retryable rate limit, and prompt policy
rejections looked like generic provider failures.
This change gives billing failures their existing payment-required
category and adds a content-policy category for `invalid_prompt` and
`cyber_policy`. It also parses OpenAI's standard HTTP error envelope and
sends both HTTP and stream failures through the same classifier while
preserving the original status, code, and message. Responses with
another body format retain the previous status-based fallback.
Release Notes:
- N/A
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.
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.
# 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.
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>
Map OpenAI's context_length_exceeded errors (both the in-stream error
events sent by the Responses API / ChatGPT Codex backend and HTTP 400
responses carrying the code) to
LanguageModelCompletionError::PromptTooLarge. This stops pointless
retries and surfaces the dedicated token-limit UI instead of a raw error
string.
Also record a synthetic request token usage when a completion fails with
PromptTooLarge, so the context indicator reports Exceeded rather than
the stale usage of the last successful request, and the next prompt
qualifies for auto-compaction.
Ought to help a bit with
https://github.com/zed-industries/zed/issues/59600
Release Notes:
- N/A or Added/Fixed/Improved ...
---------
Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
Co-authored-by: zed-zippy[bot] <234243425+zed-zippy[bot]@users.noreply.github.com>
# Objective
Allow zed's language model stack to express OpenAI Responses API custom
tools (freeform text-input tools with an optional lark/regex grammar),
so downstream consumers can offer tools like a freeform `apply_patch` to
GPT models.
## Solution
- `LanguageModelRequestTool` now carries a Function-vs-Custom input
variant; `LanguageModelCustomToolFormat` models text/grammar formats.
- `LanguageModelToolUse.input` becomes a typed
`LanguageModelToolUseInput::{Json, Text}`. Serialization is tagged so
persisted Text inputs round-trip losslessly; legacy plain JSON values
still deserialize as `Json`.
- `open_ai` gains the custom tool wire types (tool definition,
`custom_tool_call`/`custom_tool_call_output` input items with
string-or-content-part outputs, output item, and
`custom_tool_call_input` delta/done stream events). The Responses event
mapper accumulates raw text deltas into `ToolUse` events, and history
replay derives custom-vs-function tool results from the matching
`ToolUse` by id.
- All non-OpenAI providers and the Chat Completions path error
explicitly when a request contains custom tools — no silent drops or
empty-schema coercions.
Release Notes:
- N/A
Closes#60162.
MCP servers whose tool `inputSchema` uses `$ref`/`$defs` (e.g., Notion
MCP v2.x, and any server using Zod/Pydantic-generated schemas) are
silently rejected with:
```
ERROR Schema cannot be made compatible because it contains "$ref"
```
The affected tools are dropped from the agent panel — the user never
sees them and there is no user-visible error.
## Root cause
`adapt_to_json_schema_subset` rejects any schema containing `$ref` via
`UNSUPPORTED_KEYS`:
```rust
const UNSUPPORTED_KEYS: [&str; 4] = ["if", "then", "else", "$ref"];
```
This is hit by every provider that uses `JsonSchemaSubset` format
(Google Gemini, xAI Grok, OpenAI-compatible proxies, Vercel AI Gateway,
Copilot Chat for Google/xAI vendors, OpenRouter for gemini/grok models).
Providers using `JsonSchema` (Anthropic direct, OpenAI direct) don't hit
this check — `$ref` is passed through to the API, which may or may not
handle it correctly.
This is not an edge case. Every modern MCP server using Zod
(TypeScript), Pydantic (Python), or JSON Schema with shared definitions
generates `$ref`/`$defs` in tool schemas.
## Fix
Add a `resolve_refs` step in `adapt_schema_to_format` that dereferences
all `$ref` pointers using the document's own `$defs` (or legacy
`definitions`) map, making the schema self-contained before
format-specific processing. Applied at the entry point so both
`JsonSchema` and `JsonSchemaSubset` formats benefit.
**Scope note:** previously `JsonSchema` providers (Anthropic direct,
OpenAI direct) received the raw `$ref`/`$defs` and were expected to
handle it themselves — which most do not. After this change, both paths
receive a self-contained schema with refs inlined. This is intentional:
it fixes the same root cause for both paths and avoids provider-specific
behavior divergence.
Supported `$ref` forms:
- `#/$defs/<name>` (JSON Schema draft 2019-09+)
- `#/definitions/<name>` (draft 4-7 legacy)
Edge cases:
- **Nested `$ref`** (definition references another definition): resolved
recursively.
- **Sibling properties alongside `$ref`** (e.g. `{ "$ref": "...",
"description": "..." }`, legal under draft 2019-09+): merged onto the
resolved definition, with siblings overriding the definition's keys.
- **Cyclic references** (A → B → A, or self-referential schemas like a
Tree node): replaced with an empty schema `{}` ("any JSON value"). The
tool still works, just without type info for that recursive field.
- **Unsupported `$ref` forms** (e.g., external URLs): returns an error
with a clear message.
- **Missing definition target**: returns an error naming the missing
ref.
## Testing
Added 10 unit tests in `crates/language_model_core/src/tool_schema.rs`
that cover the patterns produced by Zod/Pydantic-generated MCP schemas:
- `test_refs_are_resolved_via_adapt_schema_to_format` — basic `$ref` →
`$defs` resolution
- `test_refs_in_defs_are_resolved` — nested `$ref` (definition
references another definition)
- `test_refs_in_array_items_are_resolved` — `$ref` inside `array.items`
- `test_legacy_definitions_prefix_is_supported` — old
`#/definitions/<name>` prefix
- `test_schema_without_defs_is_unchanged` — schemas with no `$defs` are
unaffected
- `test_refs_fail_for_unsupported_prefix` — external URL refs error
clearly
- `test_refs_fail_for_missing_definition` — missing target errors
clearly
- `test_cyclic_refs_are_replaced_with_empty_schema` — A → B → A cycle
replaced with `{}`
- `test_self_referential_ref_is_replaced_with_empty_schema` — Tree-like
self-ref replaced with `{}`
- `test_ref_sibling_properties_are_preserved` — sibling properties
alongside `$ref` are merged onto the resolved definition
Existing tests (which call `adapt_to_json_schema_subset` and
`preprocess_json_schema` directly) are unaffected — the fix is additive
at the `adapt_schema_to_format` level.
## Disclosure
I used an LLM to help draft the implementation and tests. I reviewed and
understand the change — it adds one new function (`resolve_refs`) with
two helpers (`parse_ref`, `resolve_refs_recursive`), plus unit tests.
Release Notes:
- Fixed MCP tools with `$ref`/`$defs` in their `inputSchema` being
silently rejected by providers using the JSON Schema Subset format
(Google Gemini, xAI Grok, OpenAI-compatible proxies, etc.). Tools from
servers like Notion MCP v2.x, and any server using Zod or
Pydantic-generated schemas, now work correctly.
---------
Co-authored-by: Bennet Bo Fenner <bennetbo@gmx.de>
Co-authored-by: Bennet Bo Fenner <bennet@zed.dev>
# 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
# 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>
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
Stop the Zed cloud LLM provider from funneling completion failures
through anyhow::Error and collapsing them into
LanguageModelCompletionError::Other (which surfaced as a generic
"Request failed.").
- perform_llm_completion now returns a typed
LanguageModelCompletionError, mapping each failure to its real variant
(SerializeRequest, HttpSend, ApiReadResponseError, and ApiError-derived
status variants).
- response_lines yields a typed ResponseStreamError so mid-stream read/
deserialize failures become ApiReadResponseError/DeserializeResponse
without a runtime downcast.
- Add a first-class PaymentRequired variant for HTTP 402 and remove the
now-dead PaymentRequiredError struct and its anyhow downcast checks.
Self-Review Checklist:
- [ ] 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)
- [ ] Tests cover the new/changed behavior
- [ ] Performance impact has been considered and is acceptable
Closes #ISSUE
Release Notes:
- N/A
---------
Co-authored-by: Piotr Osiewicz <24362066+osiewicz@users.noreply.github.com>
Co-authored-by: zed-zippy[bot] <234243425+zed-zippy[bot]@users.noreply.github.com>
<img width="325" height="201" alt="Screenshot 2026-06-09 at 1 38 32 PM"
src="https://github.com/user-attachments/assets/a6518073-1e17-41ff-a8fc-cb279fcd4436"
/>
Adds support for Anthropic's Claude Fable 5 model when using your own
Anthropic API key. Because Fable 5 cannot be offered under Zero Data
Retention (Anthropic retains inference logs for 30 days), this gates the
model behind an explicit data-retention consent: a new
telemetry.anthropic_retention setting (default off, surfaced in the
Privacy section of the settings UI), and a hard, non-retryable check in
the cloud completion path that raises a typed error when consent is
missing.
When Fable 5 declines a request, it transparently falls back to Claude
Opus 4.8 (matching Anthropic's server-side behavior), and the agent
panel shows a callout for the consent error with "Switch to Opus 4.8" /
"Accept" actions that resume the failed turn so the user's message
continues without retyping.
Closes AI-382
Release Notes:
- Add Claude Fable 5 to Anthropic BYOK
---------
Co-authored-by: Mikayla Maki <mikayla@zed.dev>
Adds the flat context compaction marker data model and replays persisted
markers into native agent transcripts as static dividers. This lets
compacted thread boundaries deserialize, render, and export to Markdown
without enabling automatic compaction behavior yet.
Release Notes:
- Improved agent threads to show restored context compaction dividers in
conversations
For long threads we will spend more and more time cloning the messages
just to save them to the database, as we need a copy of everything to do
so asynchronously. Messages are really expensive to clone though and we
accumulate a lot of them really fast, so even for smaller threads we
start seeing pauses in the millisecond range. The fix to this is fairly
simple though, we never mutate the messages once pushed to the vec, so
just Arc them.
This PR also slightly changes `UserMessage` to be a bit faster to clone
as well.
Release Notes:
- Fixed a cause of stutters when interacting with the agent
Follow-up to #49292:
- **Bug fix in `push_any_of_constraint`**: when both an `anyOf` and a
non-empty `allOf` were already present at the same level, the existing
`anyOf` was silently dropped. Now it's always preserved.
- **Canonical OpenAPI nullability**: collapse `{nullable: true}`-only
entries out of `anyOf` onto the parent so `anyOf: [{type: "string"},
{type: "null"}]` becomes `{type: "string", nullable: true}` (the form
Gemini actually expects) instead of `anyOf: [{type: "string"},
{nullable: true}]`.
- **Compile-time path consistency**: route `ToJsonSchemaSubsetTransform`
through the same `convert_null_in_types_to_nullable` helper so
Rust-defined tools using `Option<T>` also keep nullability on Gemini,
instead of silently truncating to the non-null type.
- Drop an unnecessary clone in `push_any_of_constraint` and simplify
`convert_types_to_any_of_defs`.
- Add a small `obj()` test helper and a regression test for the `anyOf +
allOf + multi-type` case.
Release Notes:
- Fixed `Option<T>` tool parameters being sent to Gemini without their
nullability, and fixed tool schemas with `anyOf` + `allOf` losing
constraints during the OpenAPI 3.0 conversion
Co-authored-by: Daniel Strobusch <1438302+dastrobu@users.noreply.github.com>
Self-Review Checklist:
- [x] I've reviewed my own diff for quality, security, and reliability
- [x] Unsafe blocks (if any) have justifying comments
- [x] The content is consistent with the [UI/UX
checklist](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
- [x] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
Release Notes:
- N/A
Self-Review Checklist:
- [x] I've reviewed my own diff for quality, security, and reliability
- [x] Unsafe blocks (if any) have justifying comments
- [x] The content is consistent with the [UI/UX
checklist](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
- [x] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
Closes #ISSUE
Release Notes:
- N/A
Closes#53919
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:
- gemini: Fixed an issue with MCP servers specifying tools with specific
schemas
When toggling fast mode, the setting is now written to `settings.json`
under `agent.default_model.speed`, so new threads start with the same
speed. This follows the same pattern as `enable_thinking` and `effort`.
The `speed` field uses the existing `Speed` enum (`"fast"` /
`"standard"`) rather than a boolean, to leave room for future speed
tiers.
Example settings:
```json
{
"agent": {
"default_model": {
"provider": "zed.dev",
"model": "claude-sonnet-4",
"speed": "fast"
}
}
}
```
cc @benbrandt
Release Notes:
- N/A
---------
Co-authored-by: Ben Brandt <benjamin.j.brandt@gmail.com>
- `language_model` no longer depends on provider-specific crates such as
`anthropic` and `open_ai` (inverted dependency)
- `language_model_core` was extracted from `language_model` which
contains the types for the provider-specific crates to convert to/from.
- `gpui::SharedString` has been extracted into its own crate (still
exposed by `gpui`), so `language_model_core` and provider API crates
don't have to depend on `gpui`.
- Removes some unnecessary `&'static str` | `SharedString` -> `String`
-> `SharedString` conversions across the codebase.
- Extracts the core logic of the cloud `LanguageModelProvider` into its
own crate with simpler dependencies.
Release Notes:
- N/A
---------
Co-authored-by: John Tur <john-tur@outlook.com>
yenru0
Tom Houlé