Skip to content

Follow up parallel lanes with measured capacity and deferred execution controls #1979

Open

Description

@ViperJuice

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.

Activity

  1. ViperJuice commented on Nov 11, 2026

    @ViperJuice
    CollaboratorAuthor

    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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions