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
Fix two related bugs in the Ollama edit-prediction provider config
(`Settings > AI > Edit Prediction > Configure Providers`):
1. The Ollama model dropdown showed only a single model (the
currently-configured one), regardless of what models were actually
available on the configured server.
2. Ollama never appeared as a selectable option in the "Active Provider"
list, even when fully configured.
Both bugs shared the same root cause: several places in the
edit-prediction code path read from the Assistant's separate Ollama
*language model* provider (`language_models.ollama.*`, used by the AI
panel/agent) instead of the edit-prediction-specific
`edit_predictions.ollama.*` settings. These are two independent Ollama
connections that can point at different servers, so the edit-prediction
UI was effectively showing/gating on the wrong provider's state.
This changes fixes#47393
## Solution
- **Model dropdown**: Added
`edit_prediction::ollama::fetch_models_from_server`, which queries
`/api/tags` directly against the edit-prediction's own configured
`api_url`, independent of the Assistant's Ollama provider. The dropdown
now re-fetches from that URL every time it's opened, so changing the
server URL and reopening the dropdown shows the new server's models.
- **Model filtering**: Fetched models are filtered to those Zed can
infer a completion prompt format for (`infer_prompt_format`), so
chat-only and embedding models (e.g. `nomic-embed-text`, `llama3:70b`)
no longer clutter the list. This function was extracted from
`edit_prediction_registry.rs` (previously private, used only for
prompt-format resolution) into `edit_prediction::fim` so it can be
shared between the dropdown filter and the existing routing logic — same
behavior, no duplication.
- **Provider visibility**: `get_available_providers` now gates Ollama's
visibility on `edit_predictions.ollama.is_some()` (i.e. whether the user
has configured a model), matching the existing pattern already used for
the OpenAI-Compatible provider, instead of checking the unrelated
Assistant provider's authentication state. Removed the now-dead
`ollama::is_available`/`ensure_authenticated` functions and the startup
call that existed solely to make that broken check eventually pass.
## Testing
- Added unit tests for `infer_prompt_format` covering all known model
families
(qwen/codellama/deepseek-coder/starcoder/codestral/glm/zeta/sweep) and
confirming unsupported models (chat/embedding) correctly return `None`.
- Added an async test for `fetch_models_from_server` using a fake HTTP
client, verifying it filters to FIM-capable models and returns them
sorted.
- Added a regression test, `test_ollama_provider_routes_to_fim_model`,
verifying that Ollama + a known model (`qwen2.5-coder:3b`) resolves to
`EditPredictionProviderConfig::Zed(EditPredictionModel::Fim { format:
Qwen })` — this exercises the exact routing path underlying the
provider-visibility fix.
- Manually verified end-to-end against a real local Ollama server:
configured a custom `api_url`, confirmed the model dropdown populated
with the server's actual models, selected one, and confirmed Ollama
appeared in and could be selected from the Active Provider list, with
predictions successfully returned.
- Ran `cargo check` and `./script/clippy` on all touched crates
(`edit_prediction`, `settings_ui`, `edit_prediction_ui`, `zed`); no
warnings.
- Not tested: the `get_available_providers` gating change itself has no
direct test (it's a one-line settings check whose underlying resolution
is covered by the `zed`-crate regression test above); Windows/Linux were
not tested, only macOS.
## 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>
Now when we open the dropdown model selector on Ollama section we will
see the available models in the current server that we are trying to use
<img width="903" height="755" alt="image"
src="https://github.com/user-attachments/assets/873c662b-3624-4530-811c-6f07ab518e35"
/>
Now Ollama will be displayed as provider in the edit prediction
providers dropdown
<img width="903" height="755" alt="image"
src="https://github.com/user-attachments/assets/9dfe737d-6527-4ecd-9803-3d0959075c34"
/>
</details>
---
Release Notes:
- Fixed Ollama edit predictions not appearing as a selectable provider
and the model dropdown showing only a single model instead of the models
available on the configured server
Closes https://github.com/zed-industries/zed/issues/59689
Symbolicating the reporter's profile (21s of typing, Windows) showed
`Window::draw` taking 63% of the main thread at ~62 redraws/s (p95 draw
= 40ms), and 30.9% of the *entire* main thread inside
`EditorconfigStore::properties()`:
every `LanguageSettings` lookup — several per frame via
`DisplayMap::tab_size`, `MultiBuffer::language_settings`, indent guides,
and `LspStore::supports_range_formatting` — re-ran the full editorconfig
resolution (ancestor walk plus `ec4rs::Section::apply_to` over every key
of every section) and then cloned the whole `LanguageSettings` struct.
Real-world `.editorconfig` files carry hundreds of irrelevant keys
(`dotnet_*`, `ij_*`, ...), so the per-call map assembly dominated:
`RtlAllocateHeap` 7.3%, `memcmp` 7.0%, `memcpy` 6.6%,
`Properties::find_idx` 5.9% self time.
## Commit 1: resolve only the editorconfig properties Zed reads
- `EditorconfigStore::properties()` now applies only the 7 keys Zed
consumes (`indent_style`, `indent_size`, `tab_width`, `end_of_line`,
`max_line_length`, `insert_final_newline`, `trim_trailing_whitespace`)
instead of materializing every key of every matching section.
- Worktrees with no editorconfig at all now return `None` early instead
of allocating an empty `Properties` and forcing a `LanguageSettings`
clone on every lookup.
- Adds an `editor_render_with_editorconfig` benchmark: maximized window,
file-backed buffer at `src/app/components/editor_pane.ts`, a root
`.editorconfig` shaped after [the second
report](https://github.com/zed-industries/zed/issues/59689#issuecomment-5475124891)
(no `root = true`, a `[*]` section with ~3200 keys, 25 sections with
large `{...}` alternation lists) plus a 4-level nested chain, and a
typing workload (insert/delete + cursor moves).
```
main (f034409b6a): time: [37.905 ms 38.005 ms 38.107 ms]
time: [38.069 ms 38.157 ms 38.248 ms]
this commit: time: [2.8547 ms 2.8618 ms 2.8702 ms]
time: [2.8372 ms 2.8435 ms 2.8510 ms]
```
The candidate is ~13x faster.
GPUI frame report over the same workload: window draw p50 12.71 ms →
0.76 ms, p99 23.38 ms → 1.22 ms; frame budget overruns 556 → 0.
## Commit 2: cache resolved `LanguageSettings` per buffer
- `Buffer` and `BufferSnapshot` now hold `resolved_settings:
Arc<LanguageSettings>`, recomputed by a `SettingsStore` global observer.
- Global methods for retrieving the settings are still there, but buffer
only uses them for multi buffer's `language_settings_at` with an
injected language different from the buffer's primary; cold scopes such
as extension API, LSP workspace configuration, server startup still use
the global resolution
Same benchmark, same method, on top of commit 1 (alternated runs, quiet
machine):
```
commit 1: time: [2.8547 ms 2.8618 ms 2.8702 ms]
time: [2.8372 ms 2.8435 ms 2.8510 ms]
this commit: time: [1.6256 ms 1.6325 ms 1.6403 ms]
change: [-42.685% -42.270% -41.854%] (p = 0.00 < 0.05)
time: [1.6221 ms 1.6284 ms 1.6352 ms]
```
Window draw p50 0.76 ms → 0.47 ms, p99 1.22 ms → 0.69 ms, max 1.02 ms;
zero frame-budget overruns on both sides.
Combined, the benchmark's per-keystroke cost drops ~23x vs `main`
(37.9–38.2 ms → 1.62–1.64 ms).
Release Notes:
- Improved typing and rendering performance in projects that use
`.editorconfig` files.
LSP 3.18 allows servers to send [`MarkupContent` diagnostic
messages](https://microsoft.github.io/language-server-protocol/specifications/lsp/3.18/specification/#diagnostic),
guarded by the client capability
`textDocument.diagnostic.markupMessageSupport`.
- Advertise `markup_message_support` only while pull diagnostics are
enabled because `textDocument.diagnostic` is the pull-model capability.
LSP 3.18 currently has no equivalent capability for push diagnostics:
https://microsoft.github.io/language-server-protocol/specifications/lsp/3.18/specification/#diagnosticClientCapabilitieshttps://github.com/microsoft/language-server-protocol/issues/2246
- Handle `string | MarkupContent` messages in both push and pull
diagnostic paths: markdown-kind messages populate the existing
`Diagnostic::markdown` field (rendered in hover popovers and the
diagnostics panel), plaintext-kind markup remains plain text, and plain
string messages keep going through the adapter's
`diagnostic_message_to_markdown`.
- Preserve server-provided markup for code actions sent back to the
originating server, avoid forwarding markup diagnostics to other
servers, and render diagnostic metadata without altering the
server-provided markdown.
- Carry the markup kind over RPC via a new optional
`LspDiagnostic.markup_message_kind` proto field so remote/collab
projects round-trip `MarkupContent` messages.
Depends on the lsp-types change that turns `Diagnostic.message` into a
`DiagnosticMessage` enum (`string | MarkupContent`):
https://github.com/zed-industries/lsp-types/pull/15
Once merged, Cargo.toml can point to the upstream commit.
Note that Zed already rendered some plain-string diagnostics as Markdown
through language-specific adapter hooks, including `rust-analyzer`. This
adds protocol-level support for diagnostics explicitly sent as LSP 3.18
`MarkupContent`, while preserving the existing adapter fallbacks.
As a result, this does not introduce a new diagnostics rendering
pipeline.
Server-provided Markdown is routed through the existing
`Diagnostic::markdown` path, with small fixes to handle Markdown-only
updates and block content correctly.
## Showcase
Example from [JETLS.jl](github.com/aviatesk/JETLS.jl) (a Julia language
server):
> Before
<img width="924" height="160" alt="Screenshot 2026-07-15 at 16 05 40"
src="https://github.com/user-attachments/assets/b19fe9e3-50e3-44e4-9b4d-ac8bd438d3d6"
/>
> After
<img width="924" height="160" alt="Screenshot 2026-07-15 at 14 13 05"
src="https://github.com/user-attachments/assets/359c3382-118d-4fa6-aa91-6bd3661d3d28"
/>
---
Release Notes:
- Added support for rendering LSP 3.18 Markdown diagnostic messages from
language servers.
---------
Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
Co-authored-by: Kirill Bulatov <mail4score@gmail.com>
# Objective
Add configurable inline completion debounce timeout
Fixes/implements #23159
## Solution
I initially wanted to make a global setting for this, but it would
conflict with hardcoded debounces in codestral (150ms) and copilot
(75ms) which I assume are there for a reason.
So I ended up using the same mechanism used for the hardcoded debounce
in Codestral (`DEBOUNCE_TIMEOUT`) and Copilot
(`COPILOT_DEBOUNCE_TIMEOUT`)
and made it accessible and configurable for all providers.
Also fixed a bug with `DelayMs` `Display` trait adding "ms" into the
input field which then fails to parse something like "150ms" as a `u64`
by implementing `FromStr` which strips the "ms" suffix if present.
So now both "1000" and "1000ms" are parsed correctly and apply.
If the parsing fix is not relevant enough I can open a separate issue +
PR for that (and the inconsistent use and therefore display of
`Option<u64>` vs `Option<DelayMs>` in other ms input fields).
## Testing
#### Did you test these changes? If so, how?
Added a separate test which passes
`test_refresh_prediction_from_buffer_honors_debounce_duration`
Manually tested with openapi compatible prediction
All other tests in affected crates pass (`cargo test -p settings_content
-p settings_ui -p editor -p edit_prediction -p language
`)
#### How can other people (reviewers) test your changes? Is there
anything specific they need to know?
Open provider settings and adjust debounce, then see how long it takes
for a prediction to render.
#### If relevant, what platforms did you test these changes on, and are
there any important ones you can't test?
Tested on Fedora 43 KDE, but it shouldn't matter as none of the affected
code is platform specific.
## 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
https://github.com/user-attachments/assets/14efa628-765e-4c2a-ac44-01aaa3657097
---
Release Notes:
- Added configurable inline completion debounce timeout, fixes#23159
---------
Co-authored-by: Ben Kunkle <ben@zed.dev>
Closes#62796. Follow-up to #62110.
# Objective
The range of a diagnostic entry is anchored when it is ingested, so it
follows edits. The ranges in the related information kept on the
diagnostic were the ones the server published. A code action request
carried both and reported the same note at two different lines: the
entry Zed flattened that note into had followed the edit, the related
information had not.
The distance does not correct itself either. When diagnostics are merged
rather than replaced, the existing entries are re-collected from their
anchors while the payload is cloned as it is, so the two positions drift
further apart with every edit that passes.
`mlir-lsp-server` shows what this costs. `MLIRTextFile::getCodeActions`
takes the line number out of `relatedInformation`, and
`getCodeActionForDiagnostic` resolves it against its own current
document, reading that line to copy its indentation before inserting the
`expected-note` check.
## Solution
The related information moves from `Diagnostic` onto
`DiagnosticEntry<T>`, next to the range it belongs with. The locations
of the diagnostic's own file are then in the same coordinate space as
that range: anchors inside the buffer, points in the worktree's store.
`Diagnostic` carries no coordinates again, so nothing that is only
meaningful inside one buffer travels with a payload that outlives it.
Every transition goes through `DiagnosticEntry::map_coordinates`: the
unsaved-edit adjustment and the clipping when diagnostics are ingested,
the anchoring in `DiagnosticSet::new`, and the conversion back to points
in `merge_diagnostic_entries`. Only the diagnostic's own range is
widened when it is empty, since that is for how it is rendered, while
the related locations are reported back as the server framed them.
Locations in another file have nothing here to anchor to and are kept as
published, which is also what `mlir-lsp-server` expects, since it skips
them.
`DiagnosticEntryRef` is left alone. It is what the rendering path
iterates, down to the scrollbar markers that walk every diagnostic of
the buffer on each frame, so nothing there converts or allocates. The
entries are read through `diagnostic_entries_in_range` where the request
is built, and `diagnostics_in_range` is now implemented on top of it.
The field is an `Option`, as an empty `Arc<[_]>` still allocates and
most diagnostics carry no related information.
`data` has the same staleness and cannot be anchored, as it is opaque.
## Commits
The third commit is mechanical: it introduces `DiagnosticEntry::new` and
rewrites the literals at its call sites, so that the last commit holds
only the change of behaviour.
## Testing
Three tests, all failing before this change. The first two are added as
separate commits, so that they can be run against `main`:
- `test_code_actions_related_information_follows_edits` edits above the
note and requests code actions, where the two positions for it used to
disagree.
- `test_code_actions_related_information_drifts_across_merges` edits and
pulls diagnostics twice, where the distance used to be every line
inserted since the diagnostic was published rather than the last edit
alone.
- `test_code_actions_related_information_of_disk_based_diagnostics`
publishes a diagnostic computed against the file on disk while the
buffer holds an unsaved edit, covering the adjustment the two positions
share.
- `cargo test -p project`
- `cargo test -p language -p diagnostics -p editor`
- `cargo fmt --all -- --check`
- `./script/clippy -p project -p language`
## 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:
- Fixed language servers receiving outdated positions for the related
information of a diagnostic when code actions are requested.
# Objective
Prevent V4 cursor markers from appearing in edit prediction previews or
accepted edits.
## Solution
Replace the cursor marker with an internal sentinel before sub-line
diffing, so matching source text cannot reconstruct the marker.
## 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:
- N/A
# Objective
- Stop enabling edit prediction jumps by default for Zed staff.
## Solution
- Disable the staff default for the `edit_prediction_jumps` feature
flag.
## Self-Review Checklist:
- [x] I've reviewed my own diff for quality, security, and reliability
- [x] Unsafe blocks (if any) have justifying comments
- [x] The content adheres to Zed's UI standards
([UX/UI](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
and
[icon](https://github.com/zed-industries/zed/blob/main/crates/icons/README.md)
guidelines)
- [ ] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
---
Release Notes:
- N/A
This adds support for running self-hosted Sweep Next Edit edit
prediction models through Zed's OpenAI-compatible provider. The target
use case is a local deployment based on
[sweepai/sweep-next-edit-1.5B](https://huggingface.co/sweepai/sweep-next-edit-1.5B),
using the rewrite-window prompting approach described in [OSS Next
Edit](https://blog.sweep.dev/posts/oss-next-edit). Personal user testing
shows impressive quality from this small edit prediction model.
This is valuable because it allows more flexibility for Zed users to
self-host state of the art next edit prediction models!
This PR addresses the self-hosted workflow discussed in
https://github.com/zed-industries/zed/discussions/50929.
Note that the self-hosted model path needed more than just a new
dropdown value. Zed has to build the rewrite-window prompt shape the
model expects, map the rewritten window back into anchored edits, and
make `prompt_format: "infer"` work with the filename-style model
identifiers that llama-server local server reports.
The main changes are:
- add a `Sweep` prompt format for OpenAI-compatible edit prediction
providers and route it to a dedicated `SweepPrompt` model path
- build Sweep rewrite-window prompts from the active cursor window,
recent change history, and related file excerpts
- convert rewrite responses back into anchored edits and suppress no-op
rewrites
- add fixed cursor-window extraction used by the Sweep rewrite prompt
path
- recognize `sweep-next-edit` model names during `infer`, including
filename-style identifiers such as
`sweepai_sweep-next-edit-1.5B_sweep-next-edit-1.5b.q8_0.v2.gguf`
- reject reserved Sweep prompt tokens before sending malformed requests
to a self-hosted server
- update the docs to describe the actual Sweep rewrite-window prompt
format
Local setup used for manual verification:
```sh
llama-server \
--hf-repo sweepai/sweep-next-edit-1.5B \
--hf-file sweep-next-edit-1.5b.q8_0.v2.gguf \
--ctx-size 8192 \
--host 127.0.0.1 \
--port 8080
```
```json
{
"edit_predictions": {
"provider": "open_ai_compatible_api",
"open_ai_compatible_api": {
"api_url": "http://127.0.0.1:8080/v1/completions",
"model": "sweepai_sweep-next-edit-1.5B_sweep-next-edit-1.5b.q8_0.v2.gguf",
"prompt_format": "infer",
"max_output_tokens": 512
}
}
}
```
The request that produced this PR included screenshots of the
OpenAI-compatible provider configuration and the prompt format dropdown
with `Sweep` selected.
Tests added in this branch:
- `test_sweep_prompt_format_routes_to_sweep_prompt_model`
- `test_fixed_line_window_around_cursor_start_middle_and_end`
-
`test_sweep_prompt_request_prediction_diffs_rewritten_window_into_anchored_edits`
-
`test_sweep_prompt_request_prediction_returns_none_for_identical_rewrite`
-
`test_original_window_for_current_window_uses_latest_pre_edit_snapshot`
-
`test_original_window_for_current_window_returns_none_without_matching_history`
-
`test_recent_change_block_from_event_formats_original_and_updated_sections`
Verification run locally:
- `cargo test -p zed sweep_prompt_format_routes`
- `cargo test -p zed subscribe_uses_stale_provider_config`
- `cargo test -p edit_prediction sweep_prompt`
- `cargo test -p edit_prediction
fixed_line_window_around_cursor_start_middle_and_end`
- `cargo test -p edit_prediction
test_sweep_prompt_request_prediction_diffs_rewritten_window_into_anchored_edits`
- `cargo test -p edit_prediction
test_sweep_prompt_request_prediction_returns_none_for_identical_rewrite`
- `./script/clippy -p zed -p edit_prediction -p settings_content`
Release Notes:
- Added support for self-hosted Sweep Next Edit models in
OpenAI-compatible edit predictions, including the `sweep` prompt format
and `infer` detection for `sweep-next-edit` model names.
---------
Co-authored-by: Ben Kunkle <ben@zed.dev>
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>
# Objective
Prevent accepted v4 edit predictions from moving the cursor past the
model's predicted position.
## Solution
Keep the cursor's base anchor fixed while applying inserted text, then
apply the model-provided offset. Add regression coverage based on the
reported cursor jump.
## 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:
- N/A
# Objective
- Fix V4 edit prediction requests failing for local Windows projects
because native path separators do not match Unix-formatted context paths
on the server.
## Solution
- Canonicalize serialized buffer paths through the existing `RelPath`
representation.
## 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
## Suggested .rules additions
- Paths serialized for edit prediction APIs must use `RelPath`'s Unix
representation rather than platform-native `PathBuf` formatting.
---
Release Notes:
- N/A
# Objective
Add remote (SSH) and collaboration support for trashing and restoring
files in the project panel, which in turn enables undo/redo of trash
operations against remote and collab projects.
Relates to #5039.
## Solution
- Updated the project panel undo system to carry `TrashId` instead of
`TrashedEntry`.
- Using `TrashedEntry` could get hairy, as it includes paths, which
wouldn't play too nicely when using, for exapmle, macOS as the client
and Windows as the host. Using a simple identifier is much easier in
this regard and simplifies implementation.
- Enabled the Trash action and context-menu entry on remote projects,
and removed the command palette filter in `ProjectPanel::new` that was
still hiding the action on remote.
- As far as I can tell, there isn't a reliable way to detect whether a
given remote actually supports the OS trash, so we expose the action
everywhere rather than guessing. On a remote without trash support the
action will fail when invoked but this is a conscious tradeoff until we
find a better way to handle this.
- `fs` now tracks trashed files in a `SlotMap<TrashId, TrashedEntry>` on
each `Fs` implementation. Trashed files are referenced by an opaque
`TrashId` instead of passing a `TrashedEntry` around, which avoids
serializing filesystem paths in remote messages.
- Split the old `delete_entry(trash: bool)` API into distinct
`trash_entry`/`trash_file` (returning a `TrashId`) and
`delete_entry`/`delete_file` across `Project`, `Worktree`,
`LocalWorktree` and `RemoteWorktree`.
- This lets us drop the optional trash result (`Option<TrashedEntry>`)
from the delete path and require a `TrashId` from the trash path.
- Added new proto messages (`TrashProjectEntry`,
`TrashProjectEntryResponse`, `RestoreProjectEntry`,
`RestoreProjectEntryResponse`) to let clients request the host to trash
or restore entries.
- This deprecates `DeleteProjectEntry::use_trash`, but the host still
honors it. An older collab peer may request trashing via that flag
instead of the newer `TrashProjectEntry`. If the host ignored it, a
newer host would permanently delete a file the user meant to send to the
trash. The field will be removed in a later PR once all supported peers
use `TrashProjectEntry`.
## Testing
The following tests were introduced to ensure the new behavior is
correctly tested:
* `remote_server::remote_editing_tests::test_remote_trash_restore` –
Tests trashing a project entry in remote
*
`remote_server::remote_editing_tests::test_remote_delete_project_entry_with_trash`
– Test to ensure we continue respecting `DeleteProjectEntry::use_trash`
until it is fully removed
* `project_panel::tests::undo::trash_directory_undo_redo` – Not related
to these changes but a nice to have as we were missing a test ensuring
that trashing and then undoing and redoing it for a directory works as
expected
Besides these, the following scenarios were manually tested against a
remote session on the same machine (macOS):
- Trashing → Undo (Restore) → Redo (Trashing)
- Batch Trashing → Undo (Batch Restore) → Redo (Batch Trashing)
- Rename → Undo (Rename) → Redo (Rename)
- Move → Undo (Move) → Redo (Move)
- Batch Move → Undo (Batch Move) → Redo (Batch Move)
## Self-Review Checklist:
- [x] I've reviewed my own diff for quality, security, and reliability
- [x] Unsafe blocks (if any) have justifying comments
- [ ] The content 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
- [ ] Performance impact has been considered and is acceptable
Release Notes:
- N/A
---------
Co-authored-by: Yara <git@yara.blue>
# Objective
Closes EP-89
- Replace ambiguous `Other` edit prediction telemetry for known editor
lifecycle events.
## Solution
- Classify editor creation, provider changes, user information changes,
Vim mode changes, and settings changes through the existing trigger
pipeline.
## Self-Review Checklist:
- [x] I've reviewed my own diff for quality, security, and reliability
- [x] Unsafe blocks (if any) have justifying comments
- [x] The content adheres to Zed's UI standards
([UX/UI](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
and
[icon](https://github.com/zed-industries/zed/blob/main/crates/icons/README.md)
guidelines)
- [ ] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
---
Release Notes:
- N/A
This is necessary to remove some `util` dependencies from crates, as
well as better sharing for our projects. This also includes the WIP
AbsPath abstraction as well as some bug fixes from internal tooling.
Release Notes:
- N/A or Added/Fixed/Improved ...
# Objective
Closes EP-202
Prevent V4 edit predictions from leaking `<|user_cursor|>` markers into
users' buffers.
## Solution
- Strip cursor marker text from emitted prediction edits, including when
`text_diff` splits the marker across edit fragments.
- Preserve literal marker-like text that already exists in the buffer.
## Testing
- `cargo test -p edit_prediction prediction_edits_for_single_file_diff
-- --nocapture`
- `cargo test -p edit_prediction --lib`
- `cargo fmt --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:
- N/A
# Objective
- Describe the objective or issue this PR addresses.
- If you're fixing a specific issue, use "Fixes #X" for each issue as
[described in the GitHub
docs](https://docs.github.com/en/issues/tracking-your-work-with-issues/using-issues/linking-a-pull-request-to-an-issue#linking-a-pull-request-to-an-issue-using-a-keyword).
## Solution
- Describe the solution used to achieve the objective above.
## Testing
- Did you test these changes? If so, how?
- Are there any parts that need more testing?
- How can other people (reviewers) test your changes? Is there anything
specific they need to know?
- If relevant, what platforms did you test these changes on, and are
there any important ones you can't test?
## 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
> This section is optional. If this PR does not include a visual change
or does not add a new user-facing feature, you can delete this section.
- Help others understand the result of this PR by showcasing your
awesome work!
- If this PR includes a visual change, consider adding a screenshot,
GIF, or video
- A before/after comparison is very useful for changes to existing
features!
While a showcase should aim to be brief and digestible, you can use a
toggleable section to save space on longer showcases:
<details>
<summary>Click to view showcase</summary>
My super cool demos here
</details>
---
Release Notes:
- N/A or Added/Fixed/Improved ...
# Objective
Part of EP-10
Closes EP-118
- Describe the objective or issue this PR addresses.
- If you're fixing a specific issue, use "Fixes #X" for each issue as
[described in the GitHub
docs](https://docs.github.com/en/issues/tracking-your-work-with-issues/using-issues/linking-a-pull-request-to-an-issue#linking-a-pull-request-to-an-issue-using-a-keyword).
## Solution
- Describe the solution used to achieve the objective above.
## Testing
- Did you test these changes? If so, how?
- Are there any parts that need more testing?
- How can other people (reviewers) test your changes? Is there anything
specific they need to know?
- If relevant, what platforms did you test these changes on, and are
there any important ones you can't test?
## 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
> This section is optional. If this PR does not include a visual change
or does not add a new user-facing feature, you can delete this section.
- Help others understand the result of this PR by showcasing your
awesome work!
- If this PR includes a visual change, consider adding a screenshot,
GIF, or video
- A before/after comparison is very useful for changes to existing
features!
While a showcase should aim to be brief and digestible, you can use a
toggleable section to save space on longer showcases:
<details>
<summary>Click to view showcase</summary>
My super cool demos here
</details>
---
Release Notes:
- N/A or Added/Fixed/Improved ...
Co-authored-by: Nbarry <nbarry@zed.dev>
# Objective
Closes EP-78
- Describe the objective or issue this PR addresses.
- If you're fixing a specific issue, use "Fixes #X" for each issue as
[described in the GitHub
docs](https://docs.github.com/en/issues/tracking-your-work-with-issues/using-issues/linking-a-pull-request-to-an-issue#linking-a-pull-request-to-an-issue-using-a-keyword).
## Solution
- Describe the solution used to achieve the objective above.
## Testing
- Did you test these changes? If so, how?
- Are there any parts that need more testing?
- How can other people (reviewers) test your changes? Is there anything
specific they need to know?
- If relevant, what platforms did you test these changes on, and are
there any important ones you can't test?
## 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
> This section is optional. If this PR does not include a visual change
or does not add a new user-facing feature, you can delete this section.
- Help others understand the result of this PR by showcasing your
awesome work!
- If this PR includes a visual change, consider adding a screenshot,
GIF, or video
- A before/after comparison is very useful for changes to existing
features!
While a showcase should aim to be brief and digestible, you can use a
toggleable section to save space on longer showcases:
<details>
<summary>Click to view showcase</summary>
My super cool demos here
</details>
---
Release Notes:
- N/A or Added/Fixed/Improved ...
# Objective
Closes EP-9
- Describe the objective or issue this PR addresses.
- If you're fixing a specific issue, use "Fixes #X" for each issue as
[described in the GitHub
docs](https://docs.github.com/en/issues/tracking-your-work-with-issues/using-issues/linking-a-pull-request-to-an-issue#linking-a-pull-request-to-an-issue-using-a-keyword).
## Solution
- Describe the solution used to achieve the objective above.
## Testing
- Did you test these changes? If so, how?
- Are there any parts that need more testing?
- How can other people (reviewers) test your changes? Is there anything
specific they need to know?
- If relevant, what platforms did you test these changes on, and are
there any important ones you can't test?
## 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
> This section is optional. If this PR does not include a visual change
or does not add a new user-facing feature, you can delete this section.
- Help others understand the result of this PR by showcasing your
awesome work!
- If this PR includes a visual change, consider adding a screenshot,
GIF, or video
- A before/after comparison is very useful for changes to existing
features!
While a showcase should aim to be brief and digestible, you can use a
toggleable section to save space on longer showcases:
<details>
<summary>Click to view showcase</summary>
My super cool demos here
</details>
---
Release Notes:
- N/A or Added/Fixed/Improved ...
---------
Co-authored-by: Oleksiy Syvokon <oleksiy.syvokon@gmail.com>
Co-authored-by: Oleksiy Syvokon <oleksiy@zed.dev>
# Objective
Fix OpenAI-compatible reasoning/thinking support. Previously,
`OpenAiCompatibleLanguageModel` never reported thinking support, so
configured `reasoning_effort` values did not reliably reach the wire and
Responses API reasoning state could miss `include:
["reasoning.encrypted_content"]`.
Fixes#58289
Addresses #59207 for OpenAI-compatible Responses models configured with
`reasoning_effort`.
## Solution
- Treat a non-`none` configured `reasoning_effort` as OpenAI-compatible
thinking support.
- Expose common OpenAI-style effort levels in the agent UI, using the
configured effort as the default.
- Honor selected reasoning effort for OpenAI-compatible chat-completions
requests.
- Send `reasoning_effort: "none"` when thinking is disabled for a
configured reasoning model.
- Preserve native OpenAI behavior by continuing to use native
model-specific supported efforts and `max_completion_tokens`.
- Add an OpenAI-compatible `max_tokens_parameter` capability for
endpoints that expect output limits as `max_tokens`.
- Parse common streamed thinking fields (`reasoning` and
`reasoning_content`).
- Add provider setup UI and docs for configuring OpenAI-compatible
reasoning models.
## Testing
- `cargo fmt -p language_model_core -p agent_ui -p language_models`
- `cargo test -p language_models provider::open_ai_compatible::tests
--lib`
- `cargo test -p language_models provider::open_ai::tests --lib`
- `cargo test -p open_ai completion::tests --lib`
- `cargo test -p agent_ui
agent_configuration::add_llm_provider_modal::tests --lib`
- `git --no-pager diff --check`
## Self-Review Checklist:
- [x] I've reviewed my own diff for quality, security, and reliability
- [x] Unsafe blocks (if any) have justifying comments
- [x] The content adheres to Zed's UI standards
([UX/UI](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
and
[icon](https://github.com/zed-industries/zed/blob/main/crates/icons/README.md)
guidelines)
- [x] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
---
Release Notes:
- Improved OpenAI-compatible provider setup for reasoning models.
---------
Co-authored-by: Anant Goel <anant@zed.dev>
# Objective
- Simplify edit prediction jumps enough to re-enable the staff flag.
- Defer diagnostic-triggered jump refreshes until we know we need them.
## Solution
- Remove the diagnostic refresh trigger path and its supporting state.
- Keep jumps driven by ordinary prediction requests only.
## Testing
- Not run.
## Self-Review Checklist:
- [x] I've reviewed my own diff for quality, security, and reliability
- [x] Unsafe blocks (if any) have justifying comments
- [x] The content adheres to Zed's UI standards
([UX/UI](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
and
[icon](https://github.com/zed-industries/zed/blob/main/crates/icons/README.md)
guidelines)
- [ ] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
---
Release Notes:
- 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 or Added/Fixed/Improved ...
# Objective
## Solution
- Describe the solution used to achieve the objective above.
## Testing
- Did you test these changes? If so, how?
- Are there any parts that need more testing?
- How can other people (reviewers) test your changes? Is there anything
specific they need to know?
- If relevant, what platforms did you test these changes on, and are
there any important ones you can't test?
## 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
> This section is optional. If this PR does not include a visual change
or does not add a new user-facing feature, you can delete this section.
- Help others understand the result of this PR by showcasing your
awesome work!
- If this PR includes a visual change, consider adding a screenshot,
GIF, or video
- A before/after comparison is very useful for changes to existing
features!
While a showcase should aim to be brief and digestible, you can use a
toggleable section to save space on longer showcases:
<details>
<summary>Click to view showcase</summary>
My super cool demos here
</details>
---
Release Notes:
- N/A or Added/Fixed/Improved ...
# Objective
Prevent unbounded ep request sizes
## Solution
Use same token limiting logic used for snippets, on diagnostic messages
## Testing
- Did you test these changes? If so, how?
- Are there any parts that need more testing?
- How can other people (reviewers) test your changes? Is there anything
specific they need to know?
- If relevant, what platforms did you test these changes on, and are
there any important ones you can't test?
## 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
> This section is optional. If this PR does not include a visual change
or does not add a new user-facing feature, you can delete this section.
- Help others understand the result of this PR by showcasing your
awesome work!
- If this PR includes a visual change, consider adding a screenshot,
GIF, or video
- A before/after comparison is very useful for changes to existing
features!
While a showcase should aim to be brief and digestible, you can use a
toggleable section to save space on longer showcases:
<details>
<summary>Click to view showcase</summary>
My super cool demos here
</details>
---
Release Notes:
- N/A or Added/Fixed/Improved ...
This PR makes it so we always pass up an organization ID when creating
an LLM token.
We should have an organization ID in all cases.
Release Notes:
- N/A
Self-Review Checklist:
- [x] I've reviewed my own diff for quality, security, and reliability
- [x] Unsafe blocks (if any) have justifying comments
- [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 or Added/Fixed/Improved ...
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 or Added/Fixed/Improved ...
This migrates the `Workspace::show_error` method to take a generic type
that implements `WorkspaceError` instead. That trait containts methods
to show a proper error message but most importantly means to help with
providing actions given certain errors.
The intention for this is rather easy: Whenever we show an error to the
user on the workspace level, that error should be
- actionable to a degree, even if that is only opening logs or whatnot
- show a message that is understandable to the user
- for not-too-critical errors, should hide after a certain delay and not
force the user to dismiss it using their mouse.
For now, there exist trait implementations for string error types and
anyhow errors. The long term goal here is to get rid of these altogether
and migrate everything to be strongly typed and especially actionable
instead.
Self-Review Checklist:
- [ ] I've reviewed my own diff for quality, security, and reliability
- [ ] The content is consistent with the [UI/UX
checklist](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
- [ ] Tests cover the new/changed behavior
- [X] Performance impact has been considered and is acceptable
Release Notes:
- N/A
---------
Co-authored-by: Kirill Bulatov <kirill@zed.dev>
Co-authored-by: Ben Brandt <benjamin.j.brandt@gmail.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
Closes #ISSUE
Release Notes:
- N/A or Added/Fixed/Improved ...
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 or Added/Fixed/Improved ...
---------
Co-authored-by: Oleksiy <oleksiy@zed.dev>
Pause edit prediction requests for 10 seconds after receiving a 408
timeout response. This should help Cloud to recover from spikes.
Release Notes:
- N/A
This change adds metrics for evaluating editable context collectors and
the collectors themselves:
- `cursor excerpt`: small area around the cursor.
- `current-file`: the full file that contains the cursor.
- `edit-history`: excerpts around edit history edits.
- `edit-history-file`: full files referenced by the edit history.
- `git-log`: files related to the cursor file according to recent git
co-change history.
- `oracle-file`: full files referenced by the expected patches. This is
an oracle/evaluation-only source because it uses the target patch.
Individual collectors can be enabled by passing a comma-separated list
like this: `ep context --type=edit-history,current-file`. There's also a
preset, `--type=editable`, which will enable all collectors except
oracle.
This change also adds the
`.prompt_input.related_files[0].excerpts[0].context_source` field.
Editable context is only accessible via ep-cli for now.
Release Notes:
- N/A
---------
Co-authored-by: Eric Holk <eric@zed.dev>
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 or Added/Fixed/Improved ...
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#57962
## What
When a user is not signed in to their Zed account, the edit prediction
system was still attempting a cloud API request on every keystroke. The
request would fail deep in the credential check
(`CloudApiClient::build_request`) with a `ClientApiError::NotSignedIn`
error, which propagated back up and was logged at `ERROR` level via
`.log_err()` at line 2389 of `edit_prediction.rs`.
## Why
The sign-in check was happening too late — only discovered after async
tasks were already spawned and the full request pipeline entered. This
fix gates the request at the top of `request_prediction_internal`,
returning `Task::ready(Ok(None))` immediately before any inputs are
built or tasks spawned.
The guard mirrors the existing `is_cloud` provider check already used
elsewhere in the same file, and only applies to the `Zeta` model on the
cloud provider path. Local providers (Ollama, `OpenAiCompatibleApi`) and
other models (Mercury, Fim) are unaffected.
Note: I haven't added a test for this — testing the early-return would
require mocking auth state, which I wasn't sure was worth the complexity
for a one-liner guard. Happy to add one if preferred.
Release Notes:
- Fixed noisy `not signed in` error log on every keystroke when not
signed in to Zed
---------
Co-authored-by: Oleksiy Syvokon <oleksiy@zed.dev>
Co-authored-by: MrSubidubi <finn@zed.dev>
Co-authored-by: David3u <3udavid@gmail.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
Closes #ISSUE
Release Notes:
- N/A or Added/Fixed/Improved ...
---------
Co-authored-by: zed-zippy[bot] <234243425+zed-zippy[bot]@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
Closes #ISSUE
Release Notes:
- N/A or Added/Fixed/Improved ...
Maps the existing `Speed::Fast` plumbing to OpenAI's `service_tier:
"priority"`, which matches what "fast mode" in Codex does. Relevant docs
[here](https://platform.openai.com/docs/api-reference/chat/create#chat-create-service_tier).
Like for the existing Anthropic fast mode we have a
`Model::supports_priority` method for the variants on
https://openai.com/api-priority-processing. Pro, nano, and legacy gpt-4
are excluded; Custom defaults to false.
This is gated to staff only for now (not in this diff, but the existing
fast mode feature), until we have the mechanism to require confirmation
before you enable fast mode.
Release Notes:
- Added support for Fast Mode (priority service tier) on the OpenAI API
provider.
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 or Added/Fixed/Improved ...
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 or Added/Fixed/Improved ...
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 or Added/Fixed/Improved ...
Self-Review Checklist:
- [x] I've reviewed my own diff for quality, security, and reliability
- [x] Unsafe blocks (if any) have justifying comments
- [x] The content is consistent with the [UI/UX
checklist](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
- [ ] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
Closes #ISSUE
Release Notes:
- Added the ability to input the "expected patch", i.e. what the model
should have predicted in the `edit prediction: rate completions` modal
Code had been assuming (erroneously, but understandably) that
LlmApiToken::acquire would give them a valid token.
This is not true, as those tokens expire and you must call refresh
explicitly.
Add some helpers to do the retry for you, and rename acquire to cached
to be
clearer about the intent.
Closes #ISSUE
Release Notes:
- Fixed some rare cases where API requests would fail with Unauthorized
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 or Added/Fixed/Improved ...
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 or Added/Fixed/Improved ...
yenru0
tidely