Pimp My IDE / garage dispatchBack to the garage
October 10, 2026 / agent sessions / memory residency

Idle threads need a heat sink.

Zed 1.23.2 can cap how many idle agent threads stay loaded. The setting points at a larger interface problem. Running work, loaded state, and durable history are different things.

Unload an idle thread to reclaim memory. Do not make the interface look as if the conversation was deleted, the process stopped, or the work was reviewed.
Work stateRunningMemory stateLoadedRecord stateSaved

A thread has more than one life.

Zed 1.23.2 added agent.max_idle_retained_threads. The setting controls how many idle, loadable agent threads stay in memory. Its default is five. The implementation also rechecks retained threads when they move to Idle, which closes a case where a thread could finish after the user switched away and remain loaded until a later cleanup trigger.[1][2]

That is a memory-residency rule. It is not a work limit, a deletion policy, or a statement about how much memory one thread uses. The pull request includes a regression test for a limit of zero. It does not publish per-thread memory measurements or a benchmark for choosing the default.

"Idle" describes work. "Loaded" describes memory. "Saved" describes whether the record can return.

Put the three states on the panel.

Zed's Agent Panel can run several threads at once. Each thread has its own agent, context window, and conversation history. The documentation also says archived threads remain in Thread History and can be restored. Some history and checkpoint behavior depends on the external-agent integration.[3]

An honest thread switcher should show work state and memory state separately. A running thread may sit offscreen and still need a process, a wake lock, or a stop control. An idle thread may stay loaded for a fast return. A parked thread may keep its durable conversation while releasing live UI state. Those labels stop "not visible" from becoming a dangerous synonym for "not running."

Protect work states before applying the cap.

The retention cap should apply only to threads that meet the product's idle and loadable contract. Active, generating, waiting-for-confirmation, and error-recovery states need explicit treatment. A memory rule should never become an accidental cancellation rule.

Use recency only after state eligibility. Keep the newest eligible idle threads loaded up to the cap. Park the rest. If a parked thread is selected, load it and reconsider the least-recent eligible thread. Show that swap in the interface instead of making the panel hitch with no explanation.

Running processes need their own witness.

Visual Studio Code 1.141 takes a related but separate approach for background shells. Its Copilot harness displays a Background Shells control with each command, elapsed time, and available output. A shell leaves that list when the command finishes.[4]

That control tracks live processes. An idle-thread cap tracks retained UI and agent state. Do not merge them into one vague "session" badge. A parked conversation can still have a child process if lifecycle ownership is broken. A loaded conversation can have no running process at all.

Choose the cap with measurements.

Start at the product default. Measure editor memory after opening and revisiting a realistic number of threads. Record reload latency for a parked thread. Test a running thread that finishes while offscreen. Test a waiting-for-confirmation thread. Restart the editor and prove which records return.

Then set the cap for the machine and work pattern. The slider below drafts the Zed setting and demonstrates state sorting. It uses sample threads, not host telemetry. It does not measure memory, launch an agent, stop a process, or prove that history is durable.

Interactive makeover / slider plus lifecycle sorter

Set the cooling cap.

This browser-local rig combines a native range control, an explicit thread-state rack, and a copyable Zed setting. It replaces one unexplained number field.

Classify stateApply idle capRecord policy

Idle thread retention

Choose how many eligible idle threads stay loaded in this five-thread sample. Running, active, and waiting threads remain outside the cap.

Demo range5 idle threads loaded

This control models retention. It never changes a thread's work state or claims a memory saving.

{ "agent": { "max_idle_retained_threads": 5 } }

Traditional purpose replaced: a bare numeric setting. Better version: the native slider updates a state-sorted rack, plain-language result, and copyable policy record.

Thread rack5 idle loaded / 0 parked

Work state before memory state

The first three cards are protected by work state. The five idle cards sort by recency.

Patch reviewActive

Selected now. Outside the idle cap.

Integration testRunning

Command still active. Outside the idle cap.

Release approvalWaiting

Needs confirmation. Outside the idle cap.

Parser fixLoaded

Idle 2 minutes. Eligible rank 1.

Docs passLoaded

Idle 9 minutes. Eligible rank 2.

Schema auditLoaded

Idle 18 minutes. Eligible rank 3.

Theme repairLoaded

Idle 34 minutes. Eligible rank 4.

Old benchmarkLoaded

Idle 61 minutes. Eligible rank 5.

Idle sorter
Default sample stateFive eligible idle threads stay loaded. No sample thread is parked.
Sources read / October 10, 2026 UTC

Source log

Open the thread record
  1. Zed stable release 1.23.2, released October 7, 2026 and read October 10, 2026 UTC. The release notes establish that the stable release added a setting for how many idle agent threads remain loaded.
  2. Zed pull request 64547, "agent: Add configurable idle thread retention", merged September 28, 2026 and read October 10, 2026 UTC. The pull request establishes the setting name, default of five, idle-transition cleanup, subscription cleanup, and regression test for a zero limit. It does not publish memory measurements.
  3. Zed Agent Panel documentation, read October 10, 2026 UTC. The documentation describes independent multiple threads, per-thread context and history, archiving and restoration, and integration-dependent history features.
  4. Visual Studio Code 1.141 release notes, "Keep track of background shells", released October 7, 2026 and read October 10, 2026 UTC. This is an adjacent interface example for visible running-process state. It does not document Zed's memory behavior.

Artifact boundary: this dispatch read the stable notes, implementation pull request, and product documentation. It did not build Zed, run the regression test, profile memory, or compare thread reload latency. The rig is a policy teaching tool with eight fixed sample threads.