Agent Runtime Capacity Control and Safe Reclamation

Short answer

Runtime capacity control is a lifecycle problem, not just a numeric limit. A host that manages multiple agent runtimes needs separate rules for admitting a new process, reclaiming capacity that is demonstrably idle, interrupting occupied work only with explicit authority, preserving durable user state, and proving enough teardown to reuse the released slot safely.

Qwen Code PR #12008, merged on 19 September 2026 as b944f9943c2dd3607f9921cc005d4022f51d7422, is a useful current implementation example. It completes a three-stage capacity-control line after PRs #11911 and #11940: first reject excess managed ACP-child starts, then reclaim one eligible empty runtime automatically, and finally let the user choose a specific occupied workspace runtime to stop when automatic reclamation cannot help.

The change is post-v0.24.0 current-main Qwen behavior. Qwen stable remains v0.24.0; the change does not revise ACP, UHP, MCP or A2A wire semantics and does not establish native UHP adoption by Qwen Code.

Capacity needs one authoritative admission boundary

A process limit is only useful if every path that can create a managed runtime passes through the same authority. Counting registered workspaces is insufficient because one workspace can reuse an existing child while preheat, restoration, replacement or another service path can need a new child without creating a new workspace registration.

Qwen PR #11911 introduced opt-in qwen serve --child-heap-mode admit at the shared ACP-child spawn boundary. Reservations and terminating children continue to count until release, while reusing an existing child does not consume another slot. A cold start that would exceed the modeled limit receives a recognizable capacity error instead of silently oversubscribing.

This distinction matters:

Question	Correct authority
May another managed runtime start?	Shared admission/reservation state
Is a workspace registered?	Workspace registry
Is a session loaded?	Session/control-plane state
Has a terminating process actually released capacity?	Physical runtime/process registry
Is the host within real RAM pressure?	Resource measurement/enforcement, if implemented

Qwen’s admit mode is process-count admission derived from its initialized budget model. It is not proof of current RSS, a fixed per-child heap ceiling or complete memory-pressure enforcement. Those are separate controls.

Reclaim empty capacity before interrupting work

Rejecting every cold start at capacity wastes a slot when the last resident runtime is warm but has no live session or pending work. Qwen PR #11940 adds a deliberately conservative second stage:

1. cancel the rejected reservation;
2. choose one least-recently-used eligible empty ACP child;
3. wait for its tracked teardown;
4. attempt admission once more; and
5. start the requested child only if that fresh admission succeeds.

The old workspace registration, files, saved history and runtime services remain available for a later cold recovery. A loaded session, active ACP connection or pending workspace work protects the runtime from this automatic reclamation path.

The architectural rule is automatic reclamation should target capacity that can be proven disposable, not work that merely looks quiet. An idle conversation can still be durable user state. Recent token activity is also not a substitute for authoritative session and pending-work state.

Occupied-runtime recovery requires explicit authority

When capacity remains full because the resident runtimes carry real sessions, policy has to change from reclamation to interruption. PR #12008 makes that transition explicit rather than silently extending the automatic reaper.

The user can inspect affected sessions, choose a specific workspace runtime to stop, or cancel and keep the initiating draft. A confirmed stop preserves workspace registration, files and saved conversations. Connected pages transition to a stopped state and require an explicit Resume before that workspace runtime is restored.

The stop operation is fenced by runtime identity rather than only by workspace name. If the candidate session set or runtime identity changes after preview, an old confirmation is rejected rather than applied to a replacement runtime. Independently connected ACP clients and enabled scheduled work can also make a candidate ineligible for the stop flow.

This gives a reusable safety invariant:

A destructive capacity action should authorize one identified runtime generation, not a mutable logical workspace name.

Without that fence, a slow confirmation can stop a newer runtime that did not exist when the user reviewed the interruption.

Stop acceptance is not release finality

A capacity-recovery API needs more than success: true|false. Starting teardown, observing the root process exit, releasing a registry slot and proving an entire process tree is gone are different facts.

The reviewed #12008 merge preserves those distinctions. Its stop-budget handling separates an in-flight timeout — HTTP 503, failed while cleanup continues — from a timeout between close phases — HTTP 409, incomplete, cleanup ended and a fresh preview is required. Partial or unknown outcomes remain visible, and the system does not automatically issue a second stop operation.

The merge also documents a platform limit: on Windows, Qwen’s registry does not track descendant process groups the same way as POSIX. A released: true result there establishes the tracked root’s settled exit, not proof that every descendant process in a tree is gone.

That is an important general lesson for agent hosts: name exactly what release evidence proves. A logical slot may be reusable under one implementation contract even when stronger whole-tree cleanup proof requires another mechanism.

Guard continuation after capacity release

Stopping a runtime does not reserve its slot for the request that motivated the stop. Another contender can win admission after capacity is released. Qwen therefore treats the original continuation as one guarded attempt rather than a guaranteed transaction.

The Web Shell preserves the exact draft across capacity failure and stop/cancel flows, but continuation is invalidated when its owning context changes. The merged review also fences queued prompts and deferred /plan continuation while the selected runtime is stopped, preventing retained intent from auto-running against a dead or replacement runtime.

This separates four facts that are easy to collapse incorrectly:

• the user authorized a stop;
• teardown released capacity;
• the original draft is still valid for its original context; and
• a fresh admission is currently available.

Only when the required facts still hold should the host continue the initiating action.

Control plane and physical harness should stay distinct

Qwen PR #11916 provides the internal ownership boundary that #12008 builds on. Session policy remains in the ACP control plane: registration, admission/FIFO behavior, terminal deduplication, artifact forwarding and worktree policy. The physical harness owns channel construction, liveness, idle scheduling, reservations, execution and teardown.

Capacity recovery crosses that boundary but should not erase it. A session controller can decide which runtime may be interrupted and preserve durable conversation state; the physical harness remains responsible for actually retiring the process and producing release evidence.

This pattern scales beyond Qwen: policy can move independently of executor mechanics only if the contract keeps logical session ownership and physical process ownership explicit.

Verification boundary

Upstream #12008 reports 2,863 focused unit tests plus 176 HTTP/ACP/browser assertions after integration, and a visible Chromium recovery flow whose regression set passed 28 assertions. The PR records direct macOS validation with Node.js 22.22.3 and local daemon/ACP/Web Shell builds using deterministic loopback model responses.

The same source is explicit about what was not established: Windows and Linux process-tree behavior were not locally exercised; real model providers and actual memory-pressure admission were not tested; fixed heap enforcement remains separate; and broader automatic eviction of loaded idle sessions remains outside this feature. The Windows release-evidence caveat described above is therefore especially important.

Treat these as implementation evidence, not cross-platform certification.

Relation to recovery, ACP and UHP

Session recovery asks whether persisted work is live, interrupted or terminal after history/restart ambiguity. Runtime capacity control asks a different question: when the host cannot admit another executor, which running capacity may be reclaimed or explicitly interrupted without corrupting ownership and durable state? The two areas meet at liveness, identity and finality, but they solve different failure classes.

ACP provides the client↔agent interaction surface used by Qwen’s daemon architecture, but these admission, reclamation and selected-runtime stop semantics are Qwen host behavior, not an ACP v1 or draft-v2 protocol rule. UHP similarly does not standardize this private daemon resource policy. A UHP server or HarnessRouter adapter may front a harness that implements such controls without making them UHP semantics.

HarnessRouter remains independently at v0.18.4 / efd320b313891191967871de28ff4757528ae6a7 at this verification cutoff. Nothing in Qwen #12008 changes the HarnessRouter Qwen adapter or creates a fresh Qwen-specific UHP conformance result.

See UHP vs ACP, Lifecycle, Remote harness execution and Qwen Code for the surrounding external boundaries.

Practical review checklist

When reviewing runtime-capacity behavior in an agent host, verify:

1. One admission authority: all managed-runtime starts reserve against the same limit.
2. Reservations count until release: failed, pending and terminating starts cannot transiently oversubscribe the host.
3. Automatic victims are provably safe: loaded sessions, active clients and pending work protect a runtime from silent reclamation.
4. Interruption is explicit: occupied-runtime eviction requires deliberate authority rather than an idle heuristic.
5. Confirmation is identity-fenced: stale previews cannot stop a replacement runtime.
6. Durable state survives runtime retirement: stopping a process is not deleting the workspace or conversation.
7. Partial outcomes are represented: timeout, refusal, cleanup-in-progress and confirmed release are not collapsed into one boolean.
8. Release evidence is scoped: root exit, registry release and descendant-tree cleanup are distinguished by platform.
9. No blind stop retry: uncertain teardown does not trigger an automatic second destructive action.
10. Continuation is revalidated: a preserved draft runs only if its context is still valid and fresh admission succeeds.
11. Resource claims match the mechanism: process-count admission is not described as live RAM enforcement.
12. Protocol boundaries remain honest: internal host capacity policy is not relabeled as ACP, UHP, MCP or A2A semantics.

Primary sources

• Qwen Code PR #12008 — user-directed ACP runtime stop when capacity is full
• Qwen merge commit b944f994
• Qwen Code PR #11911 — budget-based ACP child admission
• Qwen Code PR #11940 — reclaim idle ACP children when admission is full
• Qwen Code PR #11916 — ACP control-plane / harness boundary
• Qwen Code v0.24.0
• HarnessRouter v0.18.4