You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Follow up parallel lanes with measured capacity and deferred execution controls #1979
The concurrent lane runtime in agent-harness#1978 defaults to four lanes and clamps using host available memory and raw remaining ancestor-cgroup memory, with a configurable provisional 2 GiB per-lane budget. The budget is policy, not a measured child footprint; the 4 GiB seat limit is not used as a usage estimate.
Track the next adaptive-capacity increment:
Measure child memory during the first real concurrent phase and recalibrate the provisional budget.
Evaluate conservative reclaimable-cache credit, excluding dirty/writeback memory and avoiding double counting. Preserve raw readings and test the distinction between reclaimable cache and process usage.
Incorporate usable CPU, load, memory pressure, swap and between-child admission without deriving worker count from core count alone.
Retain default four, configurable ceilings, serial fallback with recorded reasons, and serialized heavy verification.
Other deferred parallel-lane items: direct-session execution gates, cross-phase defaults and pool cap, explicit stale-lane recovery, stronger process-tree quiescence evidence, Claude machine-verified ownership, and dynamic ownership claims after measurement. These remain separate from the skill-wording follow-up.
Two non-blocking wording follow-ups from agent-harness#1980 are retained here for the next documentation change:
Distinguish initial lane failure reasons (untrusted_lane_closeout, lane_transport_refused, and integrated verification failures) from lane_recovery_required on unresolved resume. Existing stop/preservation behavior is correctly described; this improves diagnostic precision.
Describe four as the default configurable ceiling and name --max-parallel-lanes / PHASE_LOOP_MAX_PARALLEL_LANES in the skill paragraphs. The runner documentation already describes the overrides and capacity behavior.
Neither changes runtime behavior or blocks the default-four outcome. They are deferred to avoid regenerating unchanged behavior and restarting the in-flight verification solely for optional prose precision.
Activity
ViperJuice commentedon Nov 11, 2026
Two non-blocking wording follow-ups from agent-harness#1980 are retained here for the next documentation change:
untrusted_lane_closeout,lane_transport_refused, and integrated verification failures) fromlane_recovery_requiredon unresolved resume. Existing stop/preservation behavior is correctly described; this improves diagnostic precision.--max-parallel-lanes/PHASE_LOOP_MAX_PARALLEL_LANESin the skill paragraphs. The runner documentation already describes the overrides and capacity behavior.Neither changes runtime behavior or blocks the default-four outcome. They are deferred to avoid regenerating unchanged behavior and restarting the in-flight verification solely for optional prose precision.