This PR disables `parallel_tool_calls` for the models that support it,
as the Agent currently expects at most one tool use per turn.
It was a bit of trial and error to figure this out. OpenAI's API
annoyingly will return an error if passing `parallel_tool_calls` to a
model that doesn't support it.
Release Notes:
- N/A
This makes context essentially work the same way as `read-file`,
increasing the likelihood of cache hits.
Just like with `read-file`, we'll notify the model when the user makes
an edit to one of the tracked files. In the future, we want to send a
diff instead of just a list of files, but that's an orthogonal change.
Release Notes:
- agent: Improved caching of files in context
---------
Co-authored-by: Antonio Scandurra <me@as-cii.com>
This PR adds the token count to the active thread view. It doesn't
behaves quite like Assistant 1 where it updates as you type, though; it
updates after you submit the message.
<img
src="https://github.com/user-attachments/assets/82d2a180-554a-43ee-b776-3743359b609b"
width="700" />
---
Release Notes:
- agent: Add token count in the thread view
---------
Co-authored-by: Agus Zubiaga <hi@aguz.me>
Release Notes:
- Fixed a rendering bug that caused context in the agent to not wrap
properly.
---------
Co-authored-by: Conrad Irwin <conrad.irwin@gmail.com>
Co-authored-by: Zed AI <ai+claude-3.7@zed.dev>
### Context
The Anthropic API fails if a request message contains a tool use and no
`Text` segments or it only contains empty `Text` segments. These are
cases that the model itself produces, but the API doesn't support
sending them back.
#27917 fixed this by appending "Using tool..." in the thread's message,
but this causes the actual conversation to include it, so it would
appear in the UI (we would actually display a gap because we never
rendered its markdown, but "Using tool..." would show up when the thread
was restored).
### Solution
We'll now only append this placeholder when we build the request, so the
API still sees it, but the UI/Thread doesn't.
Another issue we found is that the model starts mimicking these
placeholders in later tool uses which is undesirable. So unfortunately,
we had to add logic to filter them out.
Release Notes:
- agent: Improved rendering of tool uses without text
---------
Co-authored-by: Bennet <bennet@zed.dev>
Previously the "Thinking..." step would show up as pending, even though
the user cancelled the generation:
<img width="672" alt="image"
src="https://github.com/user-attachments/assets/c9cdce0a-d827-4e23-96f5-b150465911a7"
/>
Release Notes:
- Fixed an issue where the thinking step would show up as pending even
when the generation was cancelled
This happened because of two reasons:
- `Workspace::recent_navigation_history` didn't include the current file
- The context picker added the current file to a exclude list
The latter was actually intentional because we already show the file in
the suggested context, but now that we actually have mentions, it's just
inconvenient not to have it there.
Release Notes:
- N/A
This was accidentally getting added due to increased feature
unification. We've manually excluded reqwest to go back to the desired
behavior: remote_server, doesn't depend on openssl.
Release Notes:
- N/A
Co-authored-by: Mikayla Maki <mikayla.c.maki@gmail.com>
This adds a "workspace-hack" crate, see
[mozilla's](https://hg.mozilla.org/mozilla-central/file/3a265fdc9f33e5946f0ca0a04af73acd7e6d1a39/build/workspace-hack/Cargo.toml#l7)
for a concise explanation of why this is useful. For us in practice this
means that if I were to run all the tests (`cargo nextest r
--workspace`) and then `cargo r`, all the deps from the previous cargo
command will be reused. Before this PR it would rebuild many deps due to
resolving different sets of features for them. For me this frequently
caused long rebuilds when things "should" already be cached.
To avoid manually maintaining our workspace-hack crate, we will use
[cargo hakari](https://docs.rs/cargo-hakari) to update the build files
when there's a necessary change. I've added a step to CI that checks
whether the workspace-hack crate is up to date, and instructs you to
re-run `script/update-workspace-hack` when it fails.
Finally, to make sure that people can still depend on crates in our
workspace without pulling in all the workspace deps, we use a `[patch]`
section following [hakari's
instructions](https://docs.rs/cargo-hakari/0.9.36/cargo_hakari/patch_directive/index.html)
One possible followup task would be making guppy use our
`rust-toolchain.toml` instead of having to duplicate that list in its
config, I opened an issue for that upstream: guppy-rs/guppy#481.
TODO:
- [x] Fix the extension test failure
- [x] Ensure the dev dependencies aren't being unified by Hakari into
the main dependencies
- [x] Ensure that the remote-server binary continues to not depend on
LibSSL
Release Notes:
- N/A
---------
Co-authored-by: Mikayla <mikayla@zed.dev>
Co-authored-by: Mikayla Maki <mikayla.c.maki@gmail.com>
This PR adds the ability to edit previous user messages in the thread.
Release Notes:
- Agent: Added the ability to edit previous user messages
(Preview-only).
This fixes a bug in #27568 that caused flickering in the git panel's
checkbox state when staging and unstaging entire files. The problem is
that that stage/unstage action first saves the target path (if it's open
as a buffer), and we do a targeted git status scan in response to that
filesystem event, which makes its way to the git panel and causes it to
clear its pending state before the actual stage or unstage has gone
through.
The fix is to not clear the panel's pending state for git repository
events that originated from a targeted scan (i.e. one that was triggered
by FS events for repo paths, as opposed to events inside `.git` which
cause all statuses to be recomputed).
Release Notes:
- N/A
This PR makes the command permission prompt part of the tool card and
allow users to straight away change the `always_allow_tool_actions`
setting via the "Always Allow" button from that card. If that button is
clicked, that setting is turned on, and any command that requires
permission from that point on will auto-run.
Additionally, if a bash command spans multiple lines, we show the line
count at the end of the command string. (Note: this is not perfect yet
because it can likely be not visible by default, but we didn't think
this was a major blocker for now. We'll work on improving this next).
### Thread View
<img
src="https://github.com/user-attachments/assets/00f93c39-990f-4b79-84ec-0427b997167f"
width="500"/>
### Settings View
<img
src="https://github.com/user-attachments/assets/52d32435-7c8d-4ab4-a319-6cabc007267b"
width="500"/>
Release Notes:
- N/A
---------
Co-authored-by: Thomas Mickley-Doyle <tmickleydoyle@gmail.com>
Co-authored-by: Bennet Bo Fenner <bennetbo@gmx.de>
Co-authored-by: Nathan Sobo <nathan@zed.dev>
Co-authored-by: Antonio Scandurra <me@as-cii.com>
This PR removes the `use_any_tool` method from the `LanguageModel`
trait.
It was not being used anywhere, and doesn't really fit in our new tool
use story.
Release Notes:
- N/A
We were including the context at the end which meant it never got
cached. We'll now include it with the first message that introduced it
so it's cached as long as it doesn't change.
This is an improvement, but we probably still need to think of ways to
optimize caching for cases where files in context change.
Release Notes:
- N/A
It's super easy to undo those changes. In a future PR, we should also
avoid requiring confirmation in the batch tool if all the underlying
tools don't require confirmation.
Release Notes:
- N/A
This PR removes an unneeded `else if` branch that was the same as the
previous branch in the conditional.
Doesn't seem necessary to run this twice.
Release Notes:
- N/A
This PR makes it so if we receive a tool use from the model without any
corresponding text, we'll insert some placeholder text to keep the
conversation in a well-structured format.
This aims to fix an error that Antonio was seeing:
Release Notes:
- N/A
This PR updates the tool names in the default profiles, as they were not
updated after the tool names were changed to snake_case in #27903.
Release Notes:
- N/A
This seems to improve the performance of `gemini-2.5-pro-exp-03-25`
significantly.
We know define a single `Tool` that has multiple `FunctionDeclaration`s,
instead of defining multiple `Tool`s with a single
`FunctionDeclaration`.
Oddly enough the `flash` models seemed to work perfectly fine with the
multiple `Tool { ... }` definitions
Release Notes:
- N/A
