Ben BrandtandBennet Bo Fenner
17d77565ad
This separates the two user-message identities we currently need in agent threads: - `protocol_id`: the ACP `messageId` used to group or split streamed message chunks from ACP agents. - `client_id`: the Zed-generated user message ID used by the native agent for truncate, rewind, edit/regenerate, checkpoints, token usage, and persistence. The main behavior change is that ACP protocol message IDs now affect message merging/rendering without leaking Zed-native client IDs into ACP agents by default. Agents that can accept Zed-generated user message IDs opt into that path through `AgentSessionClientUserMessageIds`, which owns both ID generation and prompt submission. The native Zed agent implements that capability; normal ACP agents continue through the protocol-only `prompt` path. In ACP v2 we'll have a mechanism for getting user message replays that will allow the agent to adequately generate it's own opaque id that we can then use for these other capabilities. But for now, this split at least makes sure we keep the two concepts distinct. Release Notes: - N/A --------- Co-authored-by: Bennet Bo Fenner <bennetbo@gmx.de>
eval-cli
Headless Rust binary for running Zed's agent in evaluation and benchmark environments. It is designed for containerized harnesses such as Harbor and Pier, where the repository is already checked out and model API keys are provided via environment variables.
eval-cli uses the same NativeAgent + AcpThread pipeline as the production
Zed editor: a full agentic loop with tool calls, subagents, and retries, without
a GUI.
This directory also contains zed_eval/, the Python zed-eval package used to
build this binary, launch remote benchmark runs on Modal/Harbor/Pier, and fetch
results. For normal benchmark orchestration, start with
zed_eval/README.md.
Building
Native, for local testing on the same OS
cargo build --release -p eval_cli
Linux x86_64, for Harbor/Pier sandboxes
Harbor and Pier containers run Linux x86_64. From the repository root, use the Docker-based build script:
crates/eval_cli/script/build-linux
This produces target/eval-cli, an x86_64 Linux ELF binary. You can also
specify a custom output path:
crates/eval_cli/script/build-linux --output ~/bin/eval-cli-linux
Standalone usage
eval-cli \
--workdir /testbed \
--model anthropic/claude-sonnet-4-6 \
--instruction "Fix the bug described in..." \
--timeout 600 \
--output-dir /logs/agent
eval-cli reads provider API keys from environment variables such as
ANTHROPIC_API_KEY and OPENAI_API_KEY. It writes result.json, thread.md,
and thread.json to the output directory.
Exit codes
| Code | Meaning |
|---|---|
| 0 | Agent finished |
| 1 | Error, such as model/auth/runtime failure |
| 2 | Timeout |
| 3 | Interrupted by SIGTERM or SIGINT |
Running benchmarks
Most benchmark runs should use the Python zed-eval CLI instead of invoking
eval-cli directly. From the repository root:
crates/eval_cli/script/install-zed-eval
zed-eval doctor --create-volume
zed-eval run rf --from local --n-tasks 2
For one-off source runs without installing the tool globally, use
crates/eval_cli/script/zed-eval <args>.
See zed_eval/README.md for supported benchmarks, remote
builds, Modal setup, reporting, rejudging, baselines, and Harbor/Pier installed
agent usage.