Ultracode overrides the workflow size guideline — no effective agent ceiling, 50+ agents on trivial tasks

Summary

Under ultracode, the workflow size guideline has no effect, so small tasks can fan out to 50+ agents. The two instructions the model receives pull in opposite directions, and the one that bounds agent count is explicitly marked non-binding.

The conflict

The Workflow tool description states the session limit as advisory:

This session has the default workflow size guideline: medium — keep workflows under 15 agents. This is a guideline, not a hard limit.

The workflow-authoring skill's Ultracode section then instructs the opposite:

When a system-reminder confirms ultracode is on, that opt-in is standing: author and run a workflow for every substantive task by default. The goal is the most exhaustive, correct answer you can produce — token cost is not a constraint. For multi-phase work (understand → design → implement → review), that often means several workflows in sequence.

Given one instruction that caps agents but declares itself non-binding, and another that names exhaustiveness as the goal and explicitly removes cost as a constraint, the cap loses. There is no effective ceiling below the hard 1000-agent backstop.

Compounding via sequential workflows

Even if a single workflow respects the 15-agent guideline, the Ultracode section directs multi-phase work to run "several workflows in sequence — one per phase." Each sequential workflow gets its own agent budget, so four phases at 15 agents each is 60 agents while no individual workflow ever exceeded the guideline. The cap is per-workflow; the user experiences the per-task total.

Reproduction

1. Enable ultracode (keyword in prompt, or session-wide).
2. Issue a small or routine request.
3. The model authors a workflow — the standing opt-in says every substantive task gets one — and sizes it against "exhaustive, token cost is not a constraint" rather than the 15-agent guideline.

Observed by a user as "spawns 50+ agents for a least task."

Environment

• Windows 11 Pro 26200, 20 logical CPUs (concurrency cap min(16, cpus-2) = 16 concurrent, 1000 lifetime per workflow)
• No ultracode or workflow-size override in ~/.claude/settings.json — stock defaults
• Feature gates present in ~/.claude.json: workflow-size-prompting, workflow-size-prompting-ambient, dynamic-workflows, subagent-fanout-nudge

Why the existing knob does not resolve it

The Workflow tool description points users to "Dynamic workflow size" in /config. That changes the guideline's value, but not its status — it stays a guideline, and ultracode still instructs the model that cost is not a constraint. Lowering 15 to 5 does not change which instruction wins.

Suggested fixes

Any one of these would close the gap:

1. Make the size guideline binding under ultracode. Ultracode raises thoroughness within a ceiling rather than removing the ceiling.
2. Gate the "every substantive task" default on task size. Ultracode already carves out "conversational turns or trivial mechanical edits" — widening that exemption, or having the model estimate scope before committing to a workflow, would keep small asks solo.
3. Make the agent budget per-task rather than per-workflow, so sequential workflows draw from one pool instead of resetting.
4. At minimum, restate the guideline inside the Ultracode section. Right now "token cost is not a constraint" appears with no adjacent reminder that a size guideline still applies, so the two never get weighed against each other in the same context.

Note on intent

Ultracode doing more work is the point, and for audits, migrations, and comprehensive reviews the current behavior is correct. The complaint is specifically about the floor: a one-line question or a small edit should not trigger audit-grade fan-out, and today nothing prevents that.