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
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
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.
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.
GitHub Enterprise Cloud with Data Residency requires API requests to use
the tenant-specific `api.<subdomain>.ghe.com` hostname. Copilot Chat
previously treated configured enterprise hosts like GHES, which produced
an unsupported `/api/graphql` URL, and stored all OAuth credentials
under the same GitHub.com key.
Use the GHE.com API hostname shape for configured enterprise tenants and
scope stored credentials by GitHub hostname. Changing the configured
host now clears active authentication state and loads credentials for
the new tenant, with guards against stale asynchronous loads.
Enterprise endpoint discovery failures are now surfaced instead of
silently falling back to the public Copilot endpoint. GitHub.com retains
its existing endpoint and fallback behavior.
Release Notes:
- Fixed GitHub Copilot Chat authentication and API routing for GitHub
Enterprise Cloud
Removes an unnecessary dependency on settings as
`settings::OpenAiReasoningEffort` just points to
`language_model::ReasoningEffort`
Release Notes:
- N/A
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>
This PR uses https://github.com/zed-industries/zed/pull/57758 as a base
and adds tests, cleans up the comments, and checks changes the database
query used in auth.db to include oauth key.
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:
- Fixed GitHub Copilot Chat showing an empty model dropdown for users on
newer Copilot SDK builds
---------
Co-authored-by: Alexander Shlemov <eodus@users.noreply.github.com>
Co-authored-by: cameron <cameron.studdstreet@gmail.com>
We were storing reasoning output inside `RedactedThinking` which causes
issues when switching mid-turn from an OpenAI to an Anthropic model.
This implementation fixes this by storing it inside `reasoning_details`,
which matches our responses implementation in `open_ai.rs`
See
https://github.com/microsoft/vscode-copilot-chat/blob/main/src/platform/endpoint/node/responsesApi.ts
For whatever reason the copilot chat extension sets `summary: []`, this
is what our implementation does too
Closes#56385
Release Notes:
- Fixed an issue where the agent would error when using Copilot as a
provider and switching between OpenAI and Anthropic models
Fix two issues with reasoning support in the Copilot provider:
- Responses API path: use the user's thinking_effort setting instead of
hardcoding Medium effort
- Chat Completions path: compute and pass thinking_budget when thinking
is enabled, instead of unconditionally setting it to None
Self-Review Checklist:
- [x] I've reviewed my own diff for quality, security, and reliability
- [ ] Unsafe blocks (if any) have justifying comments
- [ ] The content is consistent with the [UI/UX
checklist](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
- [ ] Tests cover the new/changed behavior
- [ ] Performance impact has been considered and is acceptable
Closes#52140
Release Notes:
- Fixed a bug where copilot wouldn't use the thinking level the user's
have set
---------
Co-authored-by: Bennet Bo Fenner <bennetbo@gmx.de>
Co-authored-by: Bennet Bo Fenner <bennet@zed.dev>
**Observed behavior:** Inline assistant failed for GPT-4.1,
Gemini, and other non-Anthropic models. Claude worked correctly because
Anthropic's API accepts `"any"` as a valid value.
## Fix
Renamed `ToolChoice::Any` → `ToolChoice::Required` in both
`copilot_chat.rs` and `responses.rs`, matching the convention used by
other OpenAI-compatible providers (`open_ai`, `lmstudio`,
`open_router`).
`copilot_chat::ToolChoice` is a wire type only for the
`/chat/completions`
path — Anthropic models go through `into_anthropic()` and never touch
it,
so no per-model logic is needed.
Also fixes the same serialization bug in `responses::ToolChoice`, which
was not covered by the original approach, and adds regression tests for
both.
## Affected models
- `gpt-4.1` via copilot_chat provider
- `gemini-*` via copilot_chat provider
- Likely affects all OpenAI-compatible models routed through
copilot_chat
## Screenshots
**Bug (only Claude works, Gemini and GPT-4.1 fail):**
<img width="598" height="209" alt="image"
src="https://github.com/user-attachments/assets/bbd418d9-7de3-4191-9ca9-fd1961534e23"
/>
**Fix:**
<img width="532" height="154" alt="image"
src="https://github.com/user-attachments/assets/86bb0f8e-67e6-4417-9b78-b1b7ad328e9e"
/>
**Result:** After the fix, all models work correctly via inline
assistant.
## Release Notes
- Fix inline assistant 400 errors for GPT-4.1, Gemini, and other
non-Anthropic models via the copilot_chat provider (`tool_choice` was
sending `"any"` instead of `"required"`)
### Description
Related Discussions: #44499, #35742, #31851
Display cost multiplier for GitHub Copilot models in the model selectors
(Both in Chat Panel and Inline Assistant)
<img width="436" height="800" alt="image"
src="https://github.com/user-attachments/assets/c9ebd8fa-4d55-4be8-b3e1-f46dbf1f0145"
/>
### Some technical notes
Although this PR's primary intent is to show the cost multiplier for
GitHub Copilot models alone, I have included some necessary plumbing to
allow specifying costs for other providers in future. I have introduced
an enum called `LanguageModelCostInfo` for showing cost in different
ways for different models. Now, this enum is used in `LanguageModel`
trait to get the cost info.
For now to begin with, in `LanguageModelCostInfo`, I have specified two
ways of pricing: Request-based (1 Agent request - GitHub Copilot uses
this) and Token-based (1M Input tokens / 1M Output tokens). I had
initially thought about adding a `Free` type, especially for Ollama but
didn't do it after realizing that Ollama has paid plans. Right now, only
the Request-based pricing is implemented and used for Copilot models.
Feel free to suggest changes on how to improve this design better.
Release Notes:
- Show cost multiplier for GitHub Copilot models
---------
Co-authored-by: Danilo Leal <daniloleal09@gmail.com>
## Fix incorrect context size limits for GitHub Copilot Chat models
Fixes#44909
### Problem
The agent panel was displaying incorrect token limits for GitHub Copilot
models. Users reported that:
- The agent panel always showed a **128K token limit** for all GitHub
Copilot models, regardless of their actual context window size
- Claude models (e.g., Claude 3.7 Sonnet, Claude Opus 4.5) were showing
~90K instead of their actual 200K context window
- GPT-4o was showing 110K instead of its actual 128K context window
- Users could continue using models beyond the displayed limit, which
worked but was confusing
### Root Cause
The `max_token_count()` method in `copilot_chat.rs` was returning
`max_prompt_tokens` instead of `max_context_window_tokens`:
```rust
// Before (incorrect)
pub fn max_token_count(&self) -> u64 {
self.capabilities.limits.max_prompt_tokens
}
```
GitHub's API returns three different token-related fields:
- `max_context_window_tokens`: The **full context window size** (e.g.,
200K for Claude 3.7)
- `max_prompt_tokens`: GitHub's limit for prompt input (e.g., 90K for
Claude 3.7)
- `max_output_tokens`: Maximum output tokens (e.g., 16K)
The `max_token_count()` method in the `LanguageModel` trait is expected
to return the **full context window size** — this is consistent with all
other providers (Anthropic returns 200K for Claude, OpenAI returns 128K
for GPT-4o, etc.).
### Solution
<img width="583" height="132" alt="Screenshot 2026-01-25 at 1 07 53 AM"
src="https://github.com/user-attachments/assets/847e2fdb-635d-44bc-a630-2d4867ba8c32"
/>
Changed `max_token_count()` to return `max_context_window_tokens`:
```rust
// After (correct)
pub fn max_token_count(&self) -> u64 {
self.capabilities.limits.max_context_window_tokens as u64
}
```
### Impact
| Model | Before | After |
|-------|--------|-------|
| Claude 3.7 Sonnet | 90,000 | **200,000** |
| Claude Opus 4.5 | 90,000 | **200,000** |
| GPT-4o | 110,000 | **128,000** |
### Testing
Added a new test
`test_max_token_count_returns_context_window_not_prompt_tokens` that:
1. Deserializes model JSON with distinct `max_context_window_tokens` and
`max_prompt_tokens` values
2. Verifies Claude 3.7 Sonnet returns 200,000 (context window), not
90,000 (prompt tokens)
3. Verifies GPT-4o returns 128,000 (context window), not 110,000 (prompt
tokens)
All existing tests continue to pass:
```
running 4 tests
test tests::test_unknown_vendor_resilience ... ok
test tests::test_max_token_count_returns_context_window_not_prompt_tokens ... ok
test tests::test_resilient_model_schema_deserialize ... ok
test result: ok. 4 passed; 0 failed
```
Release Notes:
- copilot: Fixed incorrect context window size displayed for GitHub
Copilot Chat models in the agent panel.
## Summary
Fixes#47540 - Anthropic Claude models not appearing in GitHub Copilot
Chat model picker.
## Problem
Users reported that Anthropic Claude models (Claude Sonnet 4, Claude
Opus 4, etc.) were not appearing in the model picker when using GitHub
Copilot Chat, even though:
- The GitHub Copilot API returns these models
- The models have `model_picker_enabled: true`
- Users have valid Copilot subscriptions with access to these models
## Root Cause
The issue was in the `ModelSupportedEndpoint` enum deserialization. The
enum only defined two variants:
```rust
pub enum ModelSupportedEndpoint {
#[serde(rename = "/chat/completions")]
ChatCompletions,
#[serde(rename = "/responses")]
Responses,
}
```
Anthropic Claude models use the `/v1/messages` endpoint, which wasn't
defined. When deserializing the API response, serde failed with:
```
Error("unknown variant `/v1/messages`, expected `/chat/completions` or `/responses`")
```
Because the crate uses resilient deserialization via
`deserialize_models_skip_errors()`, the entire Claude model was silently
skipped rather than causing a hard failure. This meant users saw no
error - the models simply didn't appear.
## Solution
### 1. Added `/v1/messages` endpoint variant
```rust
pub enum ModelSupportedEndpoint {
#[serde(rename = "/chat/completions")]
ChatCompletions,
#[serde(rename = "/responses")]
Responses,
#[serde(rename = "/v1/messages")]
Messages, // NEW: Anthropic models use this endpoint
#[serde(other)]
Unknown, // NEW: Future-proofing for unknown endpoints
}
```
### 2. Removed incorrect `dedup_by()` call
The previous code deduplicated models by family:
```rust
.dedup_by(|a, b| a.capabilities.family == b.capabilities.family)
```
This incorrectly filtered out model variants that share the same family
(e.g., `claude-sonnet-4` and `claude-sonnet-4-thinking`). Removed this
call to preserve all model variants.
### 3. Removed unused import
Removed `use itertools::Itertools;` which was only used for the
now-removed `dedup_by()`.
## Changes
| File | Change |
|------|--------|
| `crates/copilot_chat/src/copilot_chat.rs` | Added `Messages` and
`Unknown` variants to `ModelSupportedEndpoint` enum |
| `crates/copilot_chat/src/copilot_chat.rs` | Removed `.dedup_by()` call
that incorrectly filtered models |
| `crates/copilot_chat/src/copilot_chat.rs` | Removed unused
`itertools::Itertools` import |
| `crates/copilot_chat/src/copilot_chat.rs` | Added 8 new unit tests |
## Test Coverage
Added 8 new unit tests to ensure the fix works and prevent regression:
| Test | Purpose |
|------|---------|
| `test_models_with_pending_policy_deserialize` | Verifies models with
non-"enabled" policy states deserialize correctly (they're filtered
later) |
| `test_multiple_anthropic_models_preserved` | Verifies multiple Claude
models are not incorrectly deduplicated |
| `test_models_with_same_family_both_preserved` | Verifies models
sharing the same family (e.g., thinking variants) are both preserved |
| `test_mixed_vendor_models_all_preserved` | Verifies models from
different vendors (OpenAI, Anthropic, Google) are all preserved |
| `test_model_with_messages_endpoint_deserializes` | **Critical test**:
Verifies `/v1/messages` endpoint deserializes correctly |
| `test_model_with_unknown_endpoint_deserializes` | Verifies unknown
future endpoints deserialize to `Unknown` variant |
| `test_model_with_multiple_endpoints` | Verifies models with multiple
endpoints deserialize correctly |
| `test_supports_response_method` | Verifies the `supports_response()`
method logic for endpoint routing |
### Test Results
```
running 10 tests
test tests::test_model_with_messages_endpoint_deserializes ... ok
test tests::test_model_with_multiple_endpoints ... ok
test tests::test_model_with_unknown_endpoint_deserializes ... ok
test tests::test_models_with_pending_policy_deserialize ... ok
test tests::test_models_with_same_family_both_preserved ... ok
test tests::test_mixed_vendor_models_all_preserved ... ok
test tests::test_multiple_anthropic_models_preserved ... ok
test tests::test_resilient_model_schema_deserialize ... ok
test tests::test_supports_response_method ... ok
test tests::test_unknown_vendor_resilience ... ok
test result: ok. 10 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out
```
## How to Test Manually
1. Sign in to GitHub Copilot in Zed
2. Open the model picker (Agent panel → model selector dropdown)
3. Verify that Anthropic Claude models appear in the list:
- Claude Sonnet 4
- Claude Opus 4
- Other Claude variants (if enabled in your GitHub Copilot settings)
## Checklist
- [x] Code compiles without errors
- [x] `./script/clippy --package copilot_chat` passes with no warnings
- [x] All unit tests pass
- [x] Change is focused on a single bug fix
- [x] No unrelated refactoring or feature additions
<img width="320" height="400" alt="Screenshot 2026-01-24 at 11 57 21 PM"
src="https://github.com/user-attachments/assets/d5e17e1b-da80-4f4d-a218-d50d35114a21"
/>
Release Notes:
- Fixed Anthropic models not appearing in the Copilot Chat model picker
---------
Co-authored-by: Piotr Osiewicz <24362066+osiewicz@users.noreply.github.com>
- **copilot: Fix double lease panic when signing out**
- **Extract copilot_chat into a separate crate**
- **Do not use re-exports from copilot**
- **Use new SignIn API**
- **Extract copilot_ui out of copilot**
Closes#7501
Release Notes:
- Fixed Copilot providing suggestions from different Zed windows.
- Copilot edit predictions now support jumping to unresolved
diagnostics.
Mikayla Maki