In some rare cases, the auto-generated block gets stuck in
`.git/info/exclude`. We now auto-clean it.
Closes#38374
Release Notes:
- Remove auto-generated block from git excludes if it gets stuck there.
1. Previously, checkpoints only appeared when an agent's edit happened
immediately after a user message. This is rare (agent usually collects
some context first), so they were almost never shown. This is now fixed.
2. After this change, a checkpoint is created after every edit
operation. So when the agent edits files five times in a single dialog
turn, we will now display five checkpoints.
As a bonus, it's now possible to undo only a part of a long agent
response.
Closes#36092, #32917
Release Notes:
- Create agent checkpoints more frequently (before every edit)
Some APIs fail when they get this parameter
Closes#36215
Release Notes:
- Fixed OpenAI-compatible providers that don't support prompt caching
and/or reasoning
1. Don't send diagnostics if there are more than 10 of them. This fixes
an issue with sending 100kb requests for projects with many warnings.
2. Don't send speculated_output and outline, as those are currently
unused.
Release Notes:
- Improved edit prediction latency
There were two different underlying reasons for the issues with
ctrl-number and ctrl-punctuation:
1. Some keys in the ctrl-0..9 range send codes in the `\1b`..`\1f`
range. For example, `ctrl-2` sends keycode for `ctrl-[` (0x1b), but we
want to map it to `2`, not to `[`.
2. `ctrl-[` and four other ctrl-punctuation were incorrectly mapped,
since the expected conversion is by adding 0x40
Closes#35012
Release Notes:
- N/A
We no longer rely on the `author` field to tell if a change was made by
the user or the agent. The `author` can be set to `User` in many
situations that are not really user-made edits, such as saving a file,
accepting a change, auto-formatting, and more. I started tracking and
fixing some of these cases, but found that inspecting changes in
`diff_base` is a more reliable method.
Also, we no longer show empty diffs. For example, if the user adds a
line and then removes the same line, the final diff is empty, even
though the buffer is marked as user-changed. Now we won't show such
edit.
There are still some issues to address:
- When a user edits within an unaccepted agent-written block, this
change becomes a part of the agent's edit. Rejecting this block will
lose user edits. It won't be displayed in project notifications, either.
- Accepting an agent block counts as a user-made edit.
- Agent start to call `project_notifications` tool after seeing enough
auto-calls.
Release Notes:
- N/A
This tool needs more polishing before being generally available.
Release Notes:
- agent: Disabled `project_notifications` tool by default for the time
being
Gradually remove details from a patch to keep it within the size limit.
This helps avoid using too much context when the user pastes large
files, generates files, or just makes many changes between agent
notifications.
Release Notes:
- N/A
This change improves user/agent collaborative editing.
When the user edits files that are used by the agent, the
`project_notification` tool now pushes *diffs* of the changes, not just
file names. This helps the agent to stay up to date without needing to
re-read files.
Release Notes:
- Improved user/agent collaborative editing: agent now receives diffs of
user edits
Previously, we sent notifications repeatedly until the agent read a
file, which was often inefficient. With this change, we now send a
notification only once (unless the files are modified again, in which
case we'll send another notification).
Release Notes:
- N/A
This commit introduces the `project_notifications` tool, which
proactively pushes notifications to the agent.
Unlike other tools, `Thread` automatically invokes this tool on every
turn, even when the LLM doesn't ask for it. When notifications are
available, the tool use and results are inserted into the thread,
simulating an LLM tool call.
As with other tools, users can disable `project_notifications` in
Profiles if they do not want them.
Currently, the tool only notifies users about stale files: that is,
files that have been edited by the user while the agent is also working
on them. In the future, notifications may be expanded to include
compiler diagnostics, long-running processes, and more.
Release Notes:
- Added `project_notifications` tool
The agent now checks if a tool is enabled in the current profile before
calling it. Previously, the agent could still call disabled tools, which
commonly happened after switching profiles in the middle of a thread.
Release Notes:
- Fixed a bug where the agent could use disabled tools sometimes
Removing it for two reasons:
1. We need a better implementation that doesn't hurt caching and doesn't
distracts the agent too much (see
https://github.com/zed-industries/zed/pull/32876 for more context)
2. Current insertion point of notifications doesn't play well with
Claude Thinking models (see
https://github.com/zed-industries/zed/issues/33000#issuecomment-2991709484)
I think we should get this code back in a form of a tool. But for now,
I'm dropping it to resolve recent issues.
Closes#33000
Release Notes:
- N/A
Previously, the OpenRouter models list (~412kb) was being downloaded
around 10 times during startup -- even when OpenRouter was not
configured.
This update addresses the issue by:
1. Fetching the models list only when OpenRouter settings change.
2. Skipping API calls if OpenRouter is not configured.
Release Notes:
- Avoid unnecessary requests to OpenRouter
When the user edits one of the tracked files, we used to notify the
agent by inserting a user message at the end of the thread. This was
causing a few problems:
- The agent would stop doing its work and start reading changed files
- The agent would write something like, "Thank you for letting me know
about these changed files."
This fix contains two parts:
1. Changing the prompt to indicate this is a service message
2. Moving the message higher in the conversation thread
This works, but it slightly hurts caching.
We may consider making these notification messages stick in history,
trading context tokens count for the cache.
This might be related to #30906
Release Notes:
- N/A
---------
Co-authored-by: Marshall Bowers <git@maxdeviant.com>
This format is enabled for Google models as they seem to prefer it.
A relevant unit eval's pass rate has increased from 0.77 to 0.98.
Diff-fenced format looks like this (markdown fences and a line hint are
optional):
```diff
<<<<<<< SEARCH line=42
...
=======
...
>>>>>>> REPLACE
```
Release Notes:
- Agent: Gemini models now use the diff-fenced format when making edits
These changes help the agent edit files when `<old_text>` matches more
than one location.
First, the agent can specify an optional `<old_text line=XX>` parameter.
When this is provided and multiple matches exist, we use this hint to
identify the best match.
Second, when there is ambiguity in matches, we now return the agent a
more helpful message listing the line numbers of all possible matches.
Together, these changes should reduce the number of misplaced edits and
agent confusion.
I have ensured the LLM Worker works with these prompt changes.
Release Notes:
- Agent: Improved locating edits
Here’s how it looks after the fix:
.
White is white and black is black, as intended.
In some cases, dimmed colors were poorly defined, so I took
`text.dimmed` values.
Note that white is defined exactly as the background color for light
themes. Similarly, black is the exact background color for dark themes.
I didn’t change this, but many themes intentionally make white and black
slightly different from the background color. This prevents issues where
programs assume, say, a dark background and set the foreground to white,
making text invisible. I'm not sure if we want to adjust these themes to
address this; just noting it here.
Closes#29379
Release Notes:
- Fixed ANSI black and ANSI white colors in built-in themes
When `<old_text>` points to more than one location in a file, we used to
edit the first match, confusing the agent along the way. Now we will
return an error, asking to expand `<old_text>` selection.
Closes #ISSUE
Release Notes:
- agent: Fixed incorrect file edits when edit locations are ambiguous
This code path is not really an error, as it can happen due to normal,
albeit uncommon, actions. Like, for example, this scenario:
1. Create a thread X in Zed instance A
2. Open Zed instance B
3. Delete the thread X in instance A
4. Close instance B. This will write non-existing thread id X to
`agent-navigation-history.json`
5. Open Zed instance C. It won't be able to load the thread X.
Another way to get into this state is by running Zed with LMDB and
SQLite thread storages side-by-side.
In any case, this is not severe enough for an error.
Closes #ISSUE
Release Notes:
- N/A
Previously, LMDB was used for storing threads, but it consumed excessive
disk space and was capped at 1GB.
This change migrates thread storage to an SQLite database. Thread JSON
objects are now compressed using zstd.
I considered training a custom zstd dictionary and storing it in a
separate table. However, the additional complexity outweighed the modest
space savings (up to 20%). I ended up using the default dictionary
stored with data.
Threads can be exported relatively easily from outside the application:
```
$ sqlite3 threads.db "SELECT hex(data) FROM threads LIMIT 5;" |
xxd -r -p |
zstd -d |
fx
```
Benchmarks:
- Original heed database: 200MB
- Sqlite uncompressed: 51MB
- sqlite compressed (this PR): 4.0MB
- sqlite compressed with a trained dictionary: 3.8MB
Release Notes:
- Migrated thread storage to SQLite with compression
We report the total number of input tokens by summing the numbers of
1. Prompt tokens
2. Cached tokens
But Google API returns prompt tokens (1) that already include cached
tokens (2), so we were double counting tokens in some cases.
Release Notes:
- Fixed bug with double-counting tokens in Gemini
The fix prevents data loss, but it also results in a somewhat confusing
UX. Specifically, after the user has made changes to an AI-created file,
selecting "Reject" will leave AI changes in place.
This is because there's no trivial way to disentangle user edits from
the edits made by the AI.
A better solution might exist. In the meantime, this change should do.
Closes
* #30527
Release Notes:
- Prevent data loss when reverting changes in an agent-created file
This change instructs models to wrap new file content in Markdown fences
and introduces a parser for this format. The reasons are:
1. This is the format we put a lot of effort into explaining in the
system prompt.
2. Gemini really prefers to do it.
3. It adds an option for a model to think before writing the content
The `eval_zode` pass rate for GEmini models goes from 0% to 100%. Other
models were already at 100%, this hasn't changed.
Release Notes:
- N/A
## Issue
The agent may run very slowly on projects that contain many or large
binary files not listed in `.gitignore`.
## Solution
Temporarily rewrite `.git/info/exludes` to ignore:
- Common binary files based on the extension
- Files larger than 2 MB
## Benchmark
I measure the time between sending an agent message in UI ("hitting
Enter") and actually sending it to an LLM. Ideally, it should be
instant. Numbers for a 7.7 GB Rust project with no .gitignore.
Filter | Time
----------------------------------|-----
No filter (= before this change) | 62 s
Exclude common file types only | 1.46 s
Exclude files >2MB only | 1.16 s
Exclude both | 0.10 s
## Planned changes:
- [x] Exclude common binary file types
- [x] Exclude large files
- [ ] Track files added by agent so we could delete them (we can't rely
on git for that anymore)
- [ ] Don't block on waiting for a checkpoint to complete until we
really need it
- [ ] Only `git add` files that are about to change
Closes #ISSUE
Release Notes:
- Improved agent latency on repositories containing many files or large
files
This is needed for apples-to-apples comparison of different agent
models.
Another change is that now `cargo -p eval` accepts model names as
`provider_id/model_id` instead of separate `--provider` and `--model`
params.
Release Notes:
- N/A
This change improves `eval_extract_handle_command_output` results for
all models:
Model | Pass rate before | Pass rate after
----------------------------|------------------|----------------
claude-3.7-sonnet | 0.96 | 0.98
gemini-2.5-pro | 0.35 | 0.86
gpt-4.1 | 0.81 | 1.00
Part of this improvement comes from more robust evaluation, which now
accepts multiple possible outcomes. Another part is from the prompt
adaptation: addressing common Gemini failure modes, adding a few-shot
example, and, in the final commit, auto-rewriting instructions for
clarity and conciseness.
This change still needs validation from larger end-to-end evals.
Release Notes:
- N/A
1. Add system prompt: this is how it's called from threads. Previously,
we were sending
2. Fix an issue with writing agent thought into a newly created empty
file.
Release Notes:
- N/A
---------
Co-authored-by: Ben Brandt <benjamin.j.brandt@gmail.com>
Co-authored-by: Antonio Scandurra <me@as-cii.com>
This eval checks that Edit Agent can create an empty file without
writing its thoughts into it. This issue is not specific to empty files,
but it's easier to reproduce with them.
For some mysterious reason, I could easily reproduce this issue roughly
90% of the time in actual Zed. However, once I extract the exact LLM
request before the failure point and generate from that, the
reproduction rate drops to 2%!
Things I've tried to make sure it's not a fluke: disabling prompt
caching, capturing the LLM request via a proxy server, running the
prompt on Claude separately from evals. Every time it was mostly giving
good outcomes, which doesn't match my actual experience in Zed.
At some point I discovered that simply adding one insignificant space or
a newline to the prompt suddenly results in an outcome I tried to
reproduce almost perfectly.
This weirdness happens even outside the Zed code base and even when
using a different subscription. The result is the same: an extra newline
or space changes the model behavior significantly enough, so that the
pass rate drops from 99% to 0-3%
I have no explanation to this.
Release Notes:
- N/A
- Evals returning an error (e.g., LLM API format mismatch) were silently
skipped in the aggregated results. Now we count them as a failure (0%
success score).
- Setting the `VERBOSE` environment variable to something non-empty
disables string truncation
Release Notes:
- N/A
Thread doesn't run pending tools when `stop_reason` is not `ToolUse`.
Perhaps we should change that so that it always runs pending tools if
there are some, but for now this change just fixes setting `stop_reason`
for Google models.
Release Notes:
- N/A
1. The `edit_file` tool tended to use `create_or_overwrite` a bit too
often, leading to corruption of long files. This change replaces the
boolean flag with an `EditFileMode` enum, which helps Agent make a more
deliberate choice when overwriting files.
With this change, the pass rate of the new eval increased from 10% to
100%.
2. eval: Added ability to run eval on top of an existing thread. Threads
can now be loaded from JSON files in the `SerializedThread` format,
which makes it easy to use real threads as starting points for
tests/evals.
3. Don't try to restore tool cards when running in headless or eval mode
-- we don't have a window to properly do this.
Release Notes:
- N/A
This change enables fuzzy search on model providers and names. For
example, the query "z41" will match "zed/gpt-4.1".
Release Notes:
- Agent: Improved model selection with fuzzy search support
This change:
1. Catches attempts to use missing tools. If this happens, we now send
Agent a message listing available tools, after which Agent can
gracefully recover. Prior behavior: thread would stop in a broken state.
Example of a hallucinated call and a message we send back:
2. Adds evals for hallucinated tool use and imagined edits
3. Adds ability to configure a profile name in evals.
Release Notes:
- N/A
This change updates the system prompt to conditionally include
`grep`-related instructions based on whether the `grep` tool is enabled.
Implementation details:
1. Add a `has_tool` handlebars helper.
2. Pass the `model` to all locations where the prompt is built.
3. Use `{{#if has_tool "grep"}}` in the system prompt to gate
`grep`-specific instructions.
Testing:
- Unit tests for the `hasTool` helper.
- Unit tests to verify that `grep`-related instructions are included /
omitted from the prompt as appropriate.
- Manual agent evaluation:
- Setup: Asked the Agent "List all impls of MyTrait in the project"
using a custom "No tools" profile (all tools disabled).
- Before the change: The Agent attempted to call `grep`, encountered an
error, then realized the tool was unavailable.
- After the change: The Agent immediately asked to enable a search tool.
Note: in principle, `grep`/`read_file` tool descriptions alone might be
enough, but to confirm this we need more evaluation. If it turns out to
be true, we'll be able to remove grep-specific instructions from the
system prompt and undo this change.
Release Notes:
- N/A
One motivation is that the outlines returned by `read_file` for large
files list line numbers assuming an inclusive `end_line`. As a result,
when the agent uses these outlines for `read_line` calls, it would
otherwise miss the last line.
Release Notes:
- N/A
Backtrace of the panic in the Agent pane:
```
Thread "<unnamed>" panicked with "called `Option::unwrap()` on a `None` value" at crates/markdown/src/parser.rs:264:55
https://github.com/zed-industries/zed/blob/3fdbc3090d2cc5c2e24014009cccbe5e7c55d217/src/crates/markdown/src/parser.rs#L264 (may not be uploaded, line may be incorrect if files modified)
0: zed::reliability::init_panic_hook::{{closure}}
at /home/silver/develop/zed/crates/zed/src/reliability.rs:56:29
1: <alloc::boxed::Box<F,A> as core::ops::function::Fn<Args>>::call
at /rustc/05f9846f893b09a1be1fc8560e33fc3c815cfecb/library/alloc/src/boxed.rs:1990:9
std::panicking::rust_panic_with_hook
at /rustc/05f9846f893b09a1be1fc8560e33fc3c815cfecb/library/std/src/panicking.rs:839:13
2: std::panicking::begin_panic_handler::{{closure}}
at /rustc/05f9846f893b09a1be1fc8560e33fc3c815cfecb/library/std/src/panicking.rs:697:13
3: std::sys::backtrace::__rust_end_short_backtrace
at /rustc/05f9846f893b09a1be1fc8560e33fc3c815cfecb/library/std/src/sys/backtrace.rs:168:18
4: rust_begin_unwind
at /rustc/05f9846f893b09a1be1fc8560e33fc3c815cfecb/library/std/src/panicking.rs:695:5
5: core::panicking::panic_fmt
at /rustc/05f9846f893b09a1be1fc8560e33fc3c815cfecb/library/core/src/panicking.rs:75:14
6: core::panicking::panic
at /rustc/05f9846f893b09a1be1fc8560e33fc3c815cfecb/library/core/src/panicking.rs:145:5
7: core::option::unwrap_failed
at /rustc/05f9846f893b09a1be1fc8560e33fc3c815cfecb/library/core/src/option.rs:2015:5
8: core::option::Option<T>::unwrap
at /home/silver/.rustup/toolchains/1.86-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/option.rs:978:21
markdown::parser::parse_markdown
at /home/silver/develop/zed/crates/markdown/src/parser.rs:264:37
9: markdown::Markdown::parse::{{closure}}
at /home/silver/develop/zed/crates/markdown/src/markdown.rs:282:51
10: <core::pin::Pin<P> as core::future::future::Future>::poll
at /home/silver/.rustup/toolchains/1.86-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/future/future.rs:124:9
11: async_task::raw::RawTask<F,T,S,M>::run
at /home/silver/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/async-task-4.7.1/src/raw.rs:557:17
12: async_task::runnable::Runnable<M>::run
at /home/silver/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/async-task-4.7.1/src/runnable.rs:781:18
13: gpui::platform::linux::dispatcher::LinuxDispatcher::new::{{closure}}::{{closure}}
at /home/silver/develop/zed/crates/gpui/src/platform/linux/dispatcher.rs:44:25
14: std::sys::backtrace::__rust_begin_short_backtrace
at /home/silver/.rustup/toolchains/1.86-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/sys/backtrace.rs:152:18
15: std::thread::Builder::spawn_unchecked_::{{closure}}::{{closure}}
at /home/silver/.rustup/toolchains/1.86-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/thread/mod.rs:559:17
16: <core::panic::unwind_safe::AssertUnwindSafe<F> as core::ops::function::FnOnce<()>>::call_once
at /home/silver/.rustup/toolchains/1.86-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/panic/unwind_safe.rs:272:9
17: std::panicking::try::do_call
at /home/silver/.rustup/toolchains/1.86-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/panicking.rs:587:40
18: __rust_try
19: std::panicking::try
at /home/silver/.rustup/toolchains/1.86-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/panicking.rs:550:19
std::panic::catch_unwind
at /home/silver/.rustup/toolchains/1.86-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/panic.rs:358:14
std::thread::Builder::spawn_unchecked_::{{closure}}
at /home/silver/.rustup/toolchains/1.86-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/thread/mod.rs:557:30
20: core::ops::function::FnOnce::call_once{{vtable.shim}}
at /home/silver/.rustup/toolchains/1.86-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/ops/function.rs:250:5
21: <alloc::boxed::Box<F,A> as core::ops::function::FnOnce<Args>>::call_once
at /rustc/05f9846f893b09a1be1fc8560e33fc3c815cfecb/library/alloc/src/boxed.rs:1976:9
<alloc::boxed::Box<F,A> as core::ops::function::FnOnce<Args>>::call_once
at /rustc/05f9846f893b09a1be1fc8560e33fc3c815cfecb/library/alloc/src/boxed.rs:1976:9
std::sys::pal::unix::thread::Thread::new::thread_start
at /rustc/05f9846f893b09a1be1fc8560e33fc3c815cfecb/library/std/src/sys/pal/unix/thread.rs:106:17
22: start_thread
at ./nptl/pthread_create.c:447:8
23: clone3
at ./misc/../sysdeps/unix/sysv/linux/x86_64/clone3.S:78:0
Segmentation fault
```
Release Notes:
- N/A *or* Added/Fixed/Improved ...
---------
Co-authored-by: Conrad Irwin <conrad.irwin@gmail.com>
While visually unintrusive, these navigation links enable proper
navigation in readers and extensions like Vimium that rely on
rel=next/prev
Release Notes:
- N/A
This update generates a single self-contained .html file that shows an
overview of evaluation threads in the browser. It's useful for:
- Quickly reviewing results
- Sharing evaluation runs
- Debugging
- Comparing models (TBD)
Features:
- Export thread JSON from the UI
- Keyboard navigation (j/k or Ctrl + ←/→)
- Toggle between compact and full views
Generating the overview:
- `cargo run -p eval` will write this file in the run dir's root.
- Or you can call `cargo run -p eval --bin explorer` to generate it
without running evals.
Screenshot:
Release Notes:
- N/A
This adds `last.message.json` file that contains the full request plus
response (serialized as a message from assistant for consistency with
other messages).
Motivation: to capture more info and to make analysis of finished runs
easier.
Release Notes:
- N/A
Alt+. is a useful terminal/readline feature that cycles through the last
arguments of previous commands in history. Unlike many other shortcuts,
it doesn't conflict with anything important globally, so it can be
safely enabled by default.
Release Notes:
- N/A
This fixes the panic that happened in debug builds in Wayland when
focusing/defocusing window in the edit mode:
```
"Thread "main" panicked with "CursorStyle::None should be handled separately in the client" at crates/gpui/src/platform/linux/wayland.rs:40:17"
```
Full log:
[stacktrace.txt](https://github.com/user-attachments/files/19814411/stacktrace.txt)
@smitbarmase, you seem to have worked on this code. Tagging you for
visibility :)
Release Notes:
- N/A
This change fixes a bug in the worktree initialization.
Details: `git ref-parse --verify $HASH` just checks that $HASH is a
well-formed hash and will successfully return even if $HASH doesn't
exist.
Release Notes:
- N/A
Oleksiy Syvokon
