Skip to content

feat(swarm): raise SwarmCommander parallelism defaults ~1.8-2x (driving function)#8394

Draft
an0mium wants to merge 1 commit into
mainfrom
claude/swarm-parallelism-bump
Draft

feat(swarm): raise SwarmCommander parallelism defaults ~1.8-2x (driving function)#8394
an0mium wants to merge 1 commit into
mainfrom
claude/swarm-parallelism-bump

Conversation

@an0mium

@an0mium an0mium commented Jun 14, 2026

Copy link
Copy Markdown
Collaborator

What

Treats the swarm as a driving function for more parallelism, not a throttle. Raises the SwarmCommanderConfig throughput defaults ~1.8-2x:

Knob Before After ×
max_parallel_tasks 20 40 2.0
max_parallel_branches 16 32 2.0
max_subtasks 15 28 ~1.9
max_cycles 5 9 1.8
budget_limit_usd 50.0 90.0 1.8

Budget is scaled with the parallelism so it doesn't become the new bottleneck under doubled fan-out. The exact-head merge gate + lease-based worker coordination remain the safety layer — wider fan-out relaxes no settlement guarantee (more agents do more work; merge authority is unchanged).

Updated the two default-value assertions in tests/swarm/test_commander.py (test_default_budget → 90.0, test_default_max_parallel → 40) to match the new defaults.

Verification

  • SwarmCommanderConfig() imports and reports the new defaults (tasks 40 / branches 32 / subtasks 28 / cycles 9 / budget 90).
  • ruff check + ruff format --check clean.
  • The tests/swarm/test_commander.py module needs the full swarm import stack (commander → reconciler → supervisor) to execute, which isn't available in the cloud sandbox — CI runs it in the full stack. The two assertion updates are correct-by-construction against the new defaults.

Deliberately NOT changed here (left to the operator)

The real fleet lane count — boss-loop configured_max_parallel_dispatches — defaults to 1 but is pinned to 1 by ~8 tests in test_boss_loop.py and is set operationally via launch args (the CLI already defaults --boss-max-parallel-dispatches to 3, and tranche_queue max_parallel_lanes is operator-supplied). So raising real lane concurrency is a launch/launchd-arg change, not a code-default change — doing it in code would break the pinned tests without changing how the daemon actually launches.

Recommended operator follow-ups (the paired bottleneck): raise --boss-max-parallel-dispatches / --max-parallel-lanes in the boss-loop launchd args, and add GraphQL capacity (App token / second identity / REST fallbacks) so the wider fan-out doesn't starve the shared token — the chronic graphql remaining=0 is the current ceiling on throughput.

Part of the ongoing bottleneck-removal work for higher-throughput autonomous orchestration.


Generated by Claude Code

…ng function)

The swarm should be a driving function for more concurrent lanes/agents, not a
throttle. Raise the throughput defaults in SwarmCommanderConfig:

- max_parallel_tasks   20 -> 40  (2x concurrent work units)
- max_parallel_branches 16 -> 32 (2x concurrent branches/lanes)
- max_subtasks         15 -> 28  (~1.9x decomposition breadth)
- max_cycles            5 ->  9  (1.8x orchestration depth)
- budget_limit_usd   50.0 -> 90.0 (1.8x, so budget does not become the new
  bottleneck under doubled parallelism)

The exact-head merge gate + lease coordination remain the safety layer, so
wider fan-out relaxes no settlement guarantee. Updated the two default-value
assertions in tests/swarm/test_commander.py to match.

Note (not changed here, intentionally): the boss-loop lane count
(configured_max_parallel_dispatches) defaults to 1 but is pinned to 1 by ~8
tests and is set operationally via the launch args (the CLI already defaults
--boss-max-parallel-dispatches to 3). Raising real fleet lane concurrency is a
launch/launchd-arg change, not a code-default change, so it is left to the
operator rather than breaking the pinned tests.

https://claude.ai/code/session_018jfJj5gb9VoLs6VBMnzhrP
@scarmani

Copy link
Copy Markdown
Collaborator

Queue-drain close: this ownerless draft changes swarm concurrency defaults and has been idle since 2026-06-14. The current loop is not settling or merging concurrency policy changes. Closing preserves the Claude branch and keeps recovery reversible; reopen from head c0a8905 with explicit owner/human direction if this parallelism bump should continue.

@scarmani scarmani closed this Jun 30, 2026
@scarmani scarmani reopened this Jun 30, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants