max_plan_tasks was set against context risk alone, never against cold-prefix cost #201

New issue

Closed

opened 2026-08-16 17:16:07 +00:00 by john · 1 comment

john commented

2026-08-16 17:16:07 +00:00

Owner

The trade nobody has priced

workflow.max_plan_tasks is 8 on this repo. It exists to keep one dispatch from
exceeding its context, and it pushes toward MORE, SMALLER plans.

For prefix cost that is exactly backwards. Every subagent dispatch pays a full
cold prefix as cache-WRITE: its contract skill, its rung file, the shared phase
context, and its own plan. Six dispatches today meant six cold prefixes. Splitting
one plan into two does not split that cost, it duplicates it.

The figures

Over the last 7 days on this repo, cache-write is 37.5% of the bill
(60,880,839 at the 5m rate plus 47,800,186 at the 1h rate, 108,681,025
billed-equivalent combined). That is the term dispatch count drives.

The same effect shows in session length. Short sessions never amortize their
prefix:

Session length	Sessions	be/msg
11-30 msgs	5	55,346
31-100 msgs	97	15,341
101+ msgs	124	17,582

3.6x, and a small dispatch is structurally the same shape as a short session.

The counter-argument, which is real

A plan that exceeds one context produces a checkpoint return, a fresh-context
re-dispatch, and a continuation that re-reads the report file to find out what it
already did. /cad-suggest currently reports 14 checkpoint returns across the
record and names workflow.max_plan_tasks as the key that concerns them, which is
evidence pointing the OTHER way.

So this is not "raise the number". It is: the two forces are in direct opposition,
one is measured and the other is not, and the current value was set against only
the measured half.

What would settle it

Nothing can be argued until turns and window are recorded per dispatch. Once they
are, the question becomes arithmetic: does a phase run as N plans cost more or
less than the same work as N/2 plans, counting checkpoints, re-dispatches and cold
prefixes on both sides. Run it on a real phase both ways and read the number.

Blocked on the tool-call/turn recording issue. Filed now so the trade is written
down rather than re-derived.

## The trade nobody has priced `workflow.max_plan_tasks` is 8 on this repo. It exists to keep one dispatch from exceeding its context, and it pushes toward MORE, SMALLER plans. For prefix cost that is exactly backwards. Every subagent dispatch pays a full cold prefix as cache-WRITE: its contract skill, its rung file, the shared phase context, and its own plan. Six dispatches today meant six cold prefixes. Splitting one plan into two does not split that cost, it duplicates it. ## The figures Over the last 7 days on this repo, cache-write is 37.5% of the bill (60,880,839 at the 5m rate plus 47,800,186 at the 1h rate, 108,681,025 billed-equivalent combined). That is the term dispatch count drives. The same effect shows in session length. Short sessions never amortize their prefix: | Session length | Sessions | be/msg | |---|---|---| | 11-30 msgs | 5 | **55,346** | | 31-100 msgs | 97 | 15,341 | | 101+ msgs | 124 | 17,582 | 3.6x, and a small dispatch is structurally the same shape as a short session. ## The counter-argument, which is real A plan that exceeds one context produces a checkpoint return, a fresh-context re-dispatch, and a continuation that re-reads the report file to find out what it already did. `/cad-suggest` currently reports **14 checkpoint returns** across the record and names `workflow.max_plan_tasks` as the key that concerns them, which is evidence pointing the OTHER way. So this is not "raise the number". It is: the two forces are in direct opposition, one is measured and the other is not, and the current value was set against only the measured half. ## What would settle it Nothing can be argued until turns and window are recorded per dispatch. Once they are, the question becomes arithmetic: does a phase run as N plans cost more or less than the same work as N/2 plans, counting checkpoints, re-dispatches and cold prefixes on both sides. Run it on a real phase both ways and read the number. Blocked on the tool-call/turn recording issue. Filed now so the trade is written down rather than re-derived.

john added the

needs-decision

proposal

labels

2026-08-16 17:16:07 +00:00

john added this to the v3.5.3 milestone

2026-08-16 17:17:44 +00:00

john commented

2026-08-18 00:23:26 +00:00

Author

Owner

Decided in Phase 4 (PLN-01) on cadence/v3.5.3, not yet merged to main. The ceiling was re-decided against BOTH forces - context risk and cold-prefix cost - with the arithmetic recorded rather than asserted: 3bf1653 (docs(4-3): the plan-task ceiling re-decided against both forces, with the arithmetic), a8d7946 (the decision reaches the schema purpose and the catalog row), b52fd6c (the schema states the ceiling the planner actually enforces). Falsifier 9e5529e, watched failing at 617a2a1. Closing as decided; the code lands with v3.5.3.

Decided in Phase 4 (PLN-01) on `cadence/v3.5.3`, not yet merged to main. The ceiling was re-decided against BOTH forces - context risk and cold-prefix cost - with the arithmetic recorded rather than asserted: `3bf1653` (`docs(4-3): the plan-task ceiling re-decided against both forces, with the arithmetic`), `a8d7946` (the decision reaches the schema purpose and the catalog row), `b52fd6c` (the schema states the ceiling the planner actually enforces). Falsifier `9e5529e`, watched failing at `617a2a1`. Closing as decided; the code lands with v3.5.3.

john closed this issue

2026-08-18 00:23:34 +00:00