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.

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.
| Place | Survives compaction? | Notes |
|---|---|---|
| Mid-thread tool result | Not guaranteed | A summary may shorten or omit it |
| A line you ask the subagent to return | Yes, once the parent has it | Ask for ids in the final message |
jobs_list on Sume | Yes | Read 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
- AI video from Cursor, Grok Bot or ChatGPT: where tools landed in 2026
Vendor changelogs dated 17 Sep to 30 Sep 2026 show creative tools reaching agent hosts. A dated table, and how a Sume MCP connection fits a host.
- Airtable API 5 requests per second per base: writing back Sume results
Airtable allows 5 requests per second per base and a 30-second wait after a 429. How to write Sume job results back without tripping it.
- Airtable attachment URLs expire in hours: feeding Sume an image
Airtable attachment download URLs expire after at least 2 hours, and Sume accepts only fetchable public HTTPS media URLs. Copy the image to a stable URL first.
- Airtable upsert with fieldsToMergeOn: one row per Sume job id
Airtable's performUpsert merges on 1-3 fields. Merge on a Sume job_id field so webhook retries update one row instead of creating duplicates.
Written by Sume