Zed 1.22 subagent compaction: keep Sume job ids out of the summary

Zed 1.22.0 compacts subagent threads automatically and lets spawn_agent pick a model. Hand Sume job ids over explicitly so a summary cannot lose them.

4 min readSume
All posts

Zed 1.22.0, released September 30, 2026, turned on automatic compaction for subagents and added an optional model parameter to spawn_agent. If a subagent submits Sume jobs, write the job ids somewhere a summary cannot drop them, and let the parent read them back with jobs_list when in doubt.

Both Zed changes are from its 1.22.0 release notes, read 2026-10-01. Those notes do not say whether subagents inherit the parent's MCP servers, so check that in your own setup before relying on it.

What did Zed 1.22 change for subagents?

Two items. spawn_agent takes an optional model parameter to choose a model for that spawn instead of the configured subagent model. And compaction is enabled for subagents, so a long subagent thread is summarized automatically.

Why do job ids need protecting from a summary?

A summary keeps the gist, not every opaque string. Sume's jobs page says generation endpoints create durable jobs and to store the job id from the submit response so work can be recovered. If the id is gone from the thread, the job still runs and still bills, but nobody knows which one is yours.

Where a Sume job id can live, read 2026-10-01.
PlaceSurvives compaction?Notes
Mid-thread tool resultNot guaranteedA summary may shorten or omit it
A line you ask the subagent to returnYes, once the parent has itAsk for ids in the final message
jobs_list on SumeYesRead tool; lists the workspace's jobs

How should a subagent report its work?

Ask for a short final message with one line per job: the id, the tool that created it and the idempotency_key used. The parent then calls jobs_wait with up to 20 ids, which the docs say is the way to wait for a parallel fan-out in one call, and jobs_result with the same ids to read the outputs.

Does the model I pick for a subagent change anything on Sume?

Not for the jobs. A Sume tool call takes the same arguments whichever model makes it, and the tools and gates rules, idempotency_key on paid calls and the optional max_spend_usd, apply per call. A smaller model for a polling subagent is therefore a cost choice on the model side only. Give a submitting subagent a stable key per task so a retry replays.

Sources

Related posts

More in Integrations

All Integrations posts

Written by Sume