Workflow tool: unbounded frontier-model fan-out with no pre-launch disclosure, cap, or live meter

Type: Feature request / safety gap
Component: Workflow tool (multi-agent orchestration)
Client version: 2.1.260
Platform: macOS (darwin 25.6.0)
Plan: Max (20x)

Summary

A single Workflow invocation spawned 59 frontier-tier agents and consumed ~127M tokens in 23 minutes — roughly 19% of a full weekly Max 20x allowance — with no pre-launch disclosure of fleet size or model tier, no enforced ceiling, and no live consumption meter.

The root cause was a workflow script authored with no opts.model pins, so every agent silently inherited the frontier session model. Nothing in the launch path surfaced that, and nothing bounded the fan-out.

What happened

On 2026-09-05 at 12:53:44 PM EDT, a workflow was launched with this shape:

export const meta = {
  name: 'branch-adversarial-review',
  phases: [
    { title: 'Find',   detail: 'six independent lenses over the branch diff' },
    { title: 'Verify', detail: 'three refuters per deduped finding, majority rule' },
    { title: 'Critic', detail: 'what lens or claim is still missing' },
  ],
}

The script was 13,700 characters. It contained zero model: pins and zero effort: pins. Every agent() call therefore inherited the frontier session tier.

The Verify phase multiplied three refuters per deduped finding, unbounded. Six lenses produced ~17 findings, yielding 6 + 51 + 1 ≈ 58 agents.

Measured cost (from local session transcripts)

| Metric | Value |
|---|---|
| Frontier-tier agents spawned | 59 |
| API calls | 1,386 |
| Tokens consumed | ~127M |
| Wall clock | 23 min (13:00:00–13:23:37 EDT) |
| Share of weekly Max 20x quota | ~19% |

51 of the 59 agents were mechanical refuters — work that a haiku or sonnet pin would have handled at a small fraction of the cost.

Expected behavior

Launching a fleet this size and this expensive should not be silent. Specifically:

1. Pre-launch disclosure. The permission dialog shows the workflow's description, but not the two things that determine cost: projected agent count and the model tier those agents will run at. Both are knowable before execution.
2. An enforced ceiling. The tool description states a size guideline ("keep workflows under 15 agents"). This run spawned 59. The guideline appears to be advisory to the model only, with no runtime enforcement — so a script that ignores it runs anyway.
3. Explicit model resolution. An agent() call with no opts.model silently resolves to the frontier session tier. For a fan-out primitive, inheriting the most expensive tier is a costly default. It should either require an explicit pin or default downward.
4. A live meter. Once running, there is no visible consumption rate, no per-agent accounting, and no way to see a fleet approaching a limit until the limit is hit.

Actual behavior

All four are absent. The workflow ran to completion, and the cost was only reconstructable afterward by parsing ~/.claude/projects/**/*.jsonl by hand.

Why this is worth fixing

Fan-out is the single highest-variance cost primitive in the product. The cost is set by two numbers (agent count × model tier) that are determined at authoring time and are fully inspectable before a single token is spent — yet neither is surfaced at the moment the user approves the run.

The failure is also silent in the worst direction: the cheapest thing to write (a script with no pins) produces the most expensive possible execution.

Suggested fixes, roughly in order of value

• Show projected agent count and resolved model tier per phase in the launch dialog.
• Enforce the configured workflow size guideline at runtime; require explicit opt-in to exceed it.
• Warn (or refuse) when a script contains no opts.model pin, rather than silently inheriting frontier.
• Default unpinned agent() calls to a mid tier instead of the session tier.
• Provide a running token/cost meter for in-flight workflows, and a hard per-workflow ceiling.
• Expose per-workflow and per-agent usage in /usage rather than only aggregate percentages.

Notes

No billing overage was incurred (usage credits: $0.00) — the cost landed entirely on plan quota. The issue is the absence of visibility and bounds, not a metering error. I verified the client-side token counts against my own transcripts; /usage reports percentages only, so an exact reconciliation against server-side accounting was not possible.