What doubled dispatches per correct change at 12 July, and what keeps them climbing?

30 September 2026 · 23 min read · Claude (version 1, LIN-3170), Claude (version 2 corrections, LIN-3171), for John Kershaw

Mostly wakes: follow-ups that wake a held autopilot when one of its children reaches a boundary. Fresh sessions per correct change rose once, in July, and have been flat since August. Counting every dispatch rather than only those whose log line names the ticket, a correct code change took 7.6 dispatches in the fortnight before 12 July and 20.0 in the fortnight after (both repos). Of that rise, +3.0 is fresh sessions and +9.4 is follow-ups; 8.0 of the later fortnight's follow-ups are wakes. The step came in two stages. Between 5 and 12 July (the logs have nothing in between) fresh sessions rose, and follow-ups rose as cold resumes of sessions that had already finished. From 10 July a finished session is closed rather than held (LIN-1219), so a follow-up to it resumes it cold; why fresh sessions rose is not found. Follow-ups per held session rose from 15–16 July, when every stepper beat began to wake its parent rather than only the first (LIN-1357). Since then the climb is mostly wakes (10.0 of the 16.3 added since late July): 8.0 per correct change in late July, 9.5 in August, 16.1 in early September and 18.0 in late September. Fresh sessions stayed at 10.6–11.5. Every figure here charges a follow-up to the ticket of the session it entered. From 13 September a wake also names the ticket of the child that woke it (LIN-2121). Charged that way, late September's wakes into epics' and Runners' sessions land on the child change too, and the figure is 28.8. Part of the climb that model-choice.md reported is an artefact of its count: from mid-July until 13 September it left out 40–47% of each ticket's dispatches. For September, the steady-base map's supervision rows cover 53–59% of the dispatches, depending on the count. The remaining 32–36% is mostly planning, review and close-out legs, the stepper beats inside plan and implementation sessions, and cheap-tier sessions whose kind cannot be read. No candidate row names it.

Findings

The count model-choice.md used sees only part of each ticket, and the part it sees changed twice. That paper counted a dispatch only when its own block in the runner's log names the ticket (model-choice.md:170). The runner prints Issue: only when the dispatch item carries an issue id. Follow-ups began inheriting one from their anchor on the evening of 12 July (LIN-1292, 2c9eec3d). Wakes began carrying one on 13 September (LIN-2121, 8372d336), and it is the id of the child whose boundary triggered the wake, not of the session it enters. The share of follow-up items with their own Issue: line was 9% in early July, 16–24% from mid-July to mid-September, and 82% from 16 September. This paper's count charges a fresh session to its own Issue: line and a follow-up to the ticket of the session it enters (the root of its followUpTo chain):

Merge period (code changes, both repos)	Changes	Correct	model-choice.md count	All dispatches	Fresh sessions	Follow-ups
29 Jun–12 Jul	80	63	5.4	7.6	5.1	2.5
13–26 Jul	118	84	11.5	20.0	8.1	11.9
27 Jul–31 Aug	251	165	13.3	22.4	10.6	11.8
1–13 Sep	125	74	17.2	32.6	11.5	21.1
14–28 Sep	85	66	47.0	36.3	11.5	24.8

All figures are per correct, complete change. The first column of figures reproduces model-choice.md's own all-tier count, 5.4 → 11.5 at the step, which it splits into 5.3 → 10.4 (frontier) and 7.1 → 12.9 (mid) (model-choice.md:144). By the full count, the step was 2.6-fold, not two-fold. The model-choice count left out 29% of the dispatches before the step and 40–47% from the step to mid-September. In the last fortnight it is higher than the full count. Wakes now name the child's ticket, so it charges the change with wakes that entered an epic's or a Runner's session. There were 12.5 such wakes per correct change in the last fortnight. Counted that way, the last fortnight is 47.1, not 36.3. Wakes into sessions of tickets that are not code changes (epics, docs and open tickets, Runners) were a quarter to half of all wakes in each week from mid-July to mid-September, and two-thirds or more after. Before 13 September no count charged them to a change.

At the step, the new dispatches came in two stages. Only tickets whose runner history and last merge both fall inside one logged window are counted here. That keeps out the thin June logs and the 6–11 July gap:

Cohort (first dispatch and last merge inside the window)	Correct	Per correct change	Fresh	Follow-ups	Of which cold resumes	Median per ticket
1–5 Jul	51	6.8	4.5	2.4	0.2	4
12–15 Jul	18	12.9	7.9	5.0	2.6	8
16–26 Jul	73	20.2	7.8	12.4	2.6	13

Every ticket in the first two cohorts, and 94 of the 103 in the third, went from first dispatch to last merge in under a day, so the short first window is not what makes the first cohort cheaper. The 12–15 July cohort is not fully observed: the run logs also have nothing from 13 July 15:23 to 14 July 16:50, and the oplog shows 103 items in 12–14 July that no run log holds. Its figure is a floor. The first stage added fresh sessions and cold resumes. Warm follow-ups stayed at 2.2–2.4 per correct change. In 1–5 July, 3 of 321 follow-ups resumed a session that had already finished. In 12–15 July, 67 of 222 did. Among all fresh sessions, the share later held open for follow-ups was 19% in 1–5 July and 20% in 12–15 July, then 33% in 16–26 July and 18% in August. Each held session took 4.8, then 4.7, then 7.4 follow-ups, and 8.4 in August. So follow-ups per held session did not change on 12 July itself. They changed from 15–16 July and stayed changed. Wakes and held autopilots were not new then: both began on 30 June–2 July (LIN-826 5fc2bdd7, LIN-886 f261380, LIN-906), before the first cohort.

What lines up with each stage, and what is only coincidence. Dates are first-parent commits on origin/main (scripts/survey-doubling-git.mjs).

Date	Repo	Change	What it did to the count
30 Jun–2 Jul	both	Wakes into subscribed parents; held-and-woken autopilots; steppers; hold on by default (LIN-826, LIN-886, LIN-791, LIN-906)	Present in both cohorts, so they cannot explain the step. They are the machinery the later rise runs on
5 Jul	LV	A terminal wake at most once per subscription edge, in place of one wake ever per item (LIN-1059)	Lands at the end of the first cohort. The 12–15 July cohort's held sessions behave like 1–5 July's, so no visible effect
10 Jul	SD, LV	A DONE session is no longer held: it finalizes and its window closes (LIN-1219, LIN-1100). The autopilot stops closing windows itself (LIN-1206)	LIN-1219 sends a follow-up to a finished session through a cold resume on its own item, not a new session. It lines up with cold resumes of finished sessions rising from 0.2 to 2.6 per correct change. The warm follow-ups did not fall, so these resumes are extra follow-ups, and this data does not say what sent them
11 Jul	SD	AWAITING_EXTERNAL: follow-ups to a session waiting on another party land instead of being rejected (LIN-1260)	Small: 5 of 222 follow-ups in 12–15 July resumed an AWAITING_EXTERNAL session
6–12 Jul	both	Parallel child fan-out (LIN-874), the opencode harness (LIN-1077), dispatch defaults (LIN-1094–1099), and others	Fresh sessions rose from 4.5 to 7.9 in this window. No commit read here explains it, and kinds before 16 July cannot be read
12 Jul	SD	Sessions run at the dispatch's tier (LIN-1285); Stop-hook cap 9 → 1000 and a re-fire for silent sessions (LIN-1266, LIN-1280); the oplog starts	The tier switch is coincidence for this question. model-choice.md found both tiers doubled. Stall re-fires stay near one per correct change throughout
12 Jul	LV	Follow-ups inherit the anchor's issue id (LIN-1292)	Log only: the step in the model-choice count
15–16 Jul	LV	A terminal wake for every distinct stepper beat, not only the first on each edge (LIN-1343, LIN-1357)	Lines up with the second stage: follow-ups per held session 4.7 → 7.4, follow-ups 5.0 → 12.4 per correct change. The held share's rise to 33% in the same days did not last
17 Jul	LV	Dispatch presets per kind (LIN-1390)	Same fortnight. It sets models, not legs; no count mechanism found
26 Jul	LV	Plan-review leg (LIN-1602)	Arrives as a new component: plan-review 0 → 1.1 fresh sessions per correct change in August
13 Sep	LV	Wakes carry the triggering child's issue id (LIN-2121)	Log only for the model-choice count. For any count that follows the Issue: line, it moves wakes into epics' and Runners' sessions onto the child change
13–17 Sep	LV	Passage Runner and legs live; single-anchor legs run as steppers (LIN-2872)	Lines up with wakes 16.1 → 18.0 per correct change, all of it on tickets a passage flew (below)

Which components stepped, which ramped, and which arrived later. In the stacked series, wakes stepped in mid-July, at about 8 per correct change. They held near 10 through August, ramped to 16 in early September, and reached 18 in late September. Fresh worker legs ramped through late July and early August: research, plan, plan-review, implementation, review and close-out together went from 5.8 to 9.3. They have since stayed between 8.1 and 9.3. Within them, review sessions held at 1.8–2.5. Review rounds per ticket rose from 0.86 in June to 1.82 in July (survey-check-3.md:248-249); review sessions cannot be counted before 16 July, so this data cannot show that rise itself. Plan-review arrived on 26 July and has run at 1.0–1.2 since. Autopilot launches ran at 0.9 per correct change until September and 1.3–1.4 after. Beats into worker sessions ran at 2–3, then 4.5–4.8 in September. Of the 595 such beats a transcript read (29 August on), 544 (91%) are stepper beats ("beat N/M"). Before 16 July no kind can be read, because the bootstrap header that names it did not exist yet.

Tickets did not need more steps after August. Each step was cut into more beats, and more supervisors were woken by each beat. Fresh sessions per correct change went 8.1, 10.6, 11.5 and 11.5 by period, and the per-ticket median went 5, 7, 6, 8. Follow-ups went 11.9, 11.8, 21.1 and 24.8, with a median of 6, 3, 9 and 14. That is where-the-effort-goes.md's finding (:25, :135), now split by kind. The follow-ups each autopilot session took went 8.6, 10.2, 11.9 and 14.3. Worker phases took few: after July a plan session took 0.4–0.9 beats, an implementation session 0.4–1.2, and review and close-out under 0.3. The number of wakes per worker event (a fresh worker session or a beat) is the clearest single measure:

Period	Wakes per worker event	Wakes into a passage leg or Runner	Wakes into a stepper	Quiet share of wakes read
13–26 Jul	0.93	–	–	not readable
27 Jul–31 Aug	0.83	–	–	not readable
1–13 Sep	1.19	0	673 of 1,191	22%
14–28 Sep	1.40	371 of 1,190	406	12%

Every layer above a worker wakes once per boundary it is subscribed to. The late-September rise sits on the tickets a passage flew. The 12 changes with any dispatch in a Runner's or leg's lineage (9 correct) took 81.8 dispatches and 41.2 wakes per correct change, at 1.62 wakes per worker event. The other 73 (57 correct) took 29.1 and 14.4, at 1.32, below early September's 16.1 wakes. Above the changes, the passage layer also adds wakes into the Runner's session, which is the passage epic's. Charged to the child change, as the log names them, those and the epic autopilots' wakes raise late September to 2.24 wakes per worker event. They were not charged to changes before 13 September, so that figure cannot be set against earlier periods.

Re-beats inside a dispatch follow the wakes, not the gates. These are Stop-hook turns that are not dispatch items, counted per correct change from the oplog:

Period	Stop-hook turns	"Not done yet" verdicts	PENDING-EXTERNAL pauses	Stall re-fires
13–26 Jul	56	5.1	8.4	1.2
27 Jul–31 Aug	60	4.0	9.4	0.6
1–13 Sep	76	2.7	14.4	0.8
14–28 Sep	81	4.0	19.2	0.9

PENDING-EXTERNAL pauses track the wakes almost one for one: a woken supervisor that has nothing to do says it is still waiting and parks again. The completion gate ("not done yet") and the stall machinery are flat or falling. Compaction is negligible: 15 compaction markers in the 2,012 transcripts kept since 29 August.

Holding size fixed, the rise holds at every production-size band, and it is steepest for the largest changes. Dispatches per correct change, both repos:

Production lines	29 Jun–12 Jul	13–26 Jul	27 Jul–31 Aug	1–13 Sep	14–28 Sep
0 (docs or tests only)	2 (2 correct)	19 (6)	10.8 (28)	5.8 (18)	39.6 (24)
1–49	8.8 (18)	16.5 (27)	14.1 (68)	20.8 (16)	20.6 (19)
50–299	6.3 (32)	21.2 (45)	26.9 (72)	31.9 (36)	32.3 (27)
300 and over	9.5 (13)	23.2 (12)	32.0 (25)	42.2 (22)	56.5 (20)

Every band with more than a handful of changes nearly doubled or more at the step (1–49 lines 1.9-fold, 50–299 3.4-fold, 300 and over 2.4-fold). From August to late September the 300-line band rose by three-quarters, the 1–49 band by about half and the 50–299 band by a fifth. Docs-only work fell back in August and early September. In late September it rose to 40. The passage epics themselves (LIN-3099 and LIN-2888, whose own dispatches are the Runner's) are left out of every figure.

Both repos show it. LinearViewer went 8.5 → 22.1 → 23.0 → 30.7 → 38.8 dispatches per correct change over the five periods. simple-dispatcher went 4.1 → 15.6 → 19.3 → 45.8 → 40.0, on 10–29 correct changes a period. In both, wakes carry the rise: 19.6 and 22.5 wakes per correct change in the last fortnight. A change that touched both repos counts in both.

September by the steady-base map. Code changes merged 1–28 September, both repos, 140 correct. Each dispatch goes to one bucket, in this order. The first column charges follow-ups as the rest of this paper does: 4,803 dispatches, 34.3 per correct change. The second charges them as the log names them from 13 September: 5,520 dispatches, 39.4 each.

Bucket (docs/steady-base.md map row)	Per correct change (share), session entered	Per correct change (share), as the log names them
2. Passage layer: every dispatch in a Runner's or leg's lineage	2.8 (8%)	6.0 (15%)
1. Quiet wakes: the supervisor wrote nothing before its next wake	2.5 (7%)	4.0 (10%)
3. Supervision that acted: autopilot launches and wakes followed by a write, dispatch, push or PR action (a ceiling for row 3)	13.0 (38%)	13.4 (34%)
8. Review rounds after the first, and the re-implementation between them (a ceiling)	2.4 (7%)	2.4 (6%)
Test or CI beats: stepper beats named for tests, CI, push or PR	1.1 (3%)	1.1 (3%)
Not in any row: plan, plan-review, research, implementation, review and close-out sessions not counted above	7.0 (20%)	7.0 (18%)
Not in any row: other stepper beats	2.8 (8%)	2.8 (7%)
Not in any row: kind unread and other	2.6 (8%)	2.7 (7%)

The order matters only among rows 1–3, whose total does not change. The passage bucket is almost all wakes, and 56% of the passage wakes read were quiet. Taking quiet wakes first moves them to row 1: by the log's naming, row 1 becomes 18% and row 2 7%. Taking the passage layer last leaves it nearly empty and row 3 at 41%. Row 7 (size the process to the change) is a lens across these buckets, not a bucket. Changes of 1–49 production lines outside the high-risk paths took 15% of September's code dispatches, at 20.7 per correct change against 34.3 for all code (23.8 against 39.4 by the log's naming). Docs-only changes took 25.1 per correct change. Row 3's share is a ceiling. "Acted" here means any outward write, and what-supervisors-do.md found most of a supervisor's actions mechanical (:23, :81). Of all September wakes read, charged as the log names them, 33% had no outward action before the next task. That matches that paper's 31% of wakes that change nothing. The quiet share is much lower in the wakes into the change's own sessions (18% outside the passage layer) and much higher in the passage layer and in epics' sessions. Row 8 is also a ceiling, because this data cannot tell a round that changed only tests from one that changed code.

What the share in no row holds. By the log's naming it is 1,787 dispatches, 12.8 per correct change. Two-thirds are fresh sessions and one-third follow-ups.

• Legs, 979. Close-out 199, review 197 (each ticket's first review; later ones are row 8), plan 191, implementation 160 (before the first review), plan-review 153 and research 79. Not all are first rounds: 215 are a second or later session of the same kind on the ticket. That is 84 plans, 84 plan-reviews, 40 close-outs and 7 others. Plan-review repeats outnumber first plan-reviews, 84 to 69.
• Beats, 430. They go into plan sessions (152), implementation sessions before review (136), research (73) and plan-review (54). Of those with a name, 299 are numbered stepper beats, mostly middle beats (210) and last beats (84). By their titles, 130 are planning work (framing, decisions, writing the plan), 76 verification or adversarial review, 28 building, 10 posting and 8 re-grounding. For the other 65, the title names none of these.
• Kind unread and other, 378. About 280 are cheap-tier sessions on the opencode harness and the follow-ups into them. They leave no Claude Code transcript, and their prompt length does not decode to a kind. The rest are custom (39), blocked (18), triage (9) and a few design, bug, scoping and spike sessions.

The share is the same in the two halves of September (897 and 890 dispatches). A fifth of it (336) is on tickets a passage flew.

Method

• Population. A change is survey-model-git.mjs's: a ticket whose id names a first-parent commit on origin/main in either repo, dated by its last merge. Correct and complete come from the same-day scorecard snapshot (survey-scorecard.mjs). A change counts only if the runner logged at least one dispatch for it, as in model-choice.md. Code changes (production lines above zero) are the main series. Docs-only changes are shown by size. Passage epics are left out.
• Dispatches. Every item in simple-dispatcher/state/dispatcher*.log (20 June on; nothing for 27 June 21:24 to 1 July 22:03, 4 July 16:24 to 5 July 15:43, 5 July 20:27 to 11 July 21:19, or 13 July 15:23 to 14 July 16:50; the oplog shows the runner was working in the last) that opened a fresh session, was resumed cold, or was signalled warm into a held one. Aborts, rejects and busy re-queues are not counted. A fresh session belongs to the ticket on its own Issue: line. A follow-up belongs to the ticket of the session it enters: the Issue: line of the root of its followUpTo chain. Version 1 used the follow-up's own Issue: line where it had one, which from 13 September names the triggering child's ticket; that reading is given where it differs. A dispatch is dated by its first oplog event (12 July on) or by its position in its log file. There are 19,450 dispatches, and no proxy calls were made.
• Kind. It is exact where a local transcript fetched the item: 29 August on, 3,408 items. Before that, a fresh session's kind is decoded from the logged length of its bootstrap prompt. The # LIN-n · kind header (16 July on, LIN-1361) adds the kind's length to one of three fixed bases (dispatcher.js:1250-1266). On September's exact launches the decoder is right 172 of 188 times for autopilot, 151 of 155 for close-out, and 282 of 319 for review (the rest are custom, triage or design, which are also six letters). It is right every time for plan, plan-review, research and implementation. Autopilot and close-out share a length; a session that later took a follow-up is read as an autopilot. A follow-up takes the kind of the session it enters: a wake if that is an autopilot, a beat if it is a worker. The follow-up routes (warm signal, cold resume and the target session's phase) come from the run logs' [follow-up] lines.
• Passage layer, quiet wakes. A Runner is an autopilot session carrying the passage prompt. A leg is an autopilot on an issue a Runner dispatched, from 17 September. A wake is quiet when the supervisor's transcript shows no proxy write, dispatch, kickoff, push or PR action before its next task arrives. Wakes whose transcript is missing are split by the measured quiet share, and beats whose name is unread by the measured test/CI share.
• Re-beats. Stop-hook entries, "not done yet" verdicts and PENDING-EXTERNAL posts come from the oplog; stall re-fires come from the run logs; compactions come from the transcripts.
• Scripts. scripts/survey-doubling-runner.mjs, survey-doubling-transcripts.mjs, survey-model-git.mjs --since 2026-05-01 --out data/survey-doubling/git.json, survey-doubling-git.mjs, survey-doubling-analyse.mjs and survey-doubling-figures.mjs. Snapshots go to the git-ignored data/survey-doubling/; the scorecard is the same-day data/survey/scorecard.json. survey-doubling-analyse.mjs prints the log's-naming figures. scripts/survey-check-4-doubling.mjs rekey writes the runner snapshot charged to the session entered; survey-doubling-analyse.mjs and survey-doubling-figures.mjs run on it unchanged print this paper's main figures and draw its charts. The same script's other subcommands print the cohort shapes, the follow-up routes, the passage split, the bucket orders and the breakdown of the share in no row.

Limits

• July's run-log undercount (survey-check.md:146). The logs have nothing from 6–11 July or from 13 July 15:23 to 14 July 16:50, and are thin before 1 July, so tickets merged in those weeks lose part of their history. Bias: the early-July gap lowers the pre-step figure and so overstates the step; the mid-July gap lowers the 12–15 July cohort. The 1–5 July window has no run log from 4 July 16:24 to 5 July 15:43; whether the runner was stopped then cannot be told. The 1–5 and 16–26 July cohorts avoid both and still show 6.8 → 20.2, so the direction holds. The size of the step rests on 51 and 73 correct changes, and the first stage on 18.
• Kinds before 16 July cannot be read. The pre-step fresh sessions and follow-ups have no kind. Bias: none on the totals. It does prevent a kind-by-kind account of the step's fresh sessions, which is why no mechanism for them is found.
• Two ways to charge a wake. A wake is caused by the child's boundary but runs in the supervisor's session. Only the session is recorded before 13 September, so only that reading runs through every period. Bias: it leaves out the supervision above a change (epics' autopilots, the Runner) in every period alike, so it understates each ticket's full cost but not the trend. The log's reading overstates the late-September rise.
• The decoder mislabels a few launches. Twelve per cent of decoded "review" launches are other six-letter kinds, and 6% of autopilot/close-out calls are swapped. Bias: review and autopilot are slightly high before 29 August. The totals and the fresh/follow-up split are unaffected.
• 30-day retention. Transcripts, and so exact kinds, quiet wakes and the passage layer, exist only from 29 August. Bias: direction unknown for the period split. September's attribution measures what August's cannot, so this paper cannot say whether August's wakes were as quiet.
• September is immature. Late-September changes are young, and their correct and complete verdicts may fall as faults are found, which would raise the per-correct-change figures. Tickets still open on 30 September are missing entirely, and their dispatches are the long-running ones. Bias: September's figures are understated. The passage split rests on 9 correct changes.
• Quiet is read from actions, not outcomes. A supervisor that only re-armed a wait, or wrote a note, counts as acted if it posted anything. Bias: row 1 is understated and row 3 overstated.
• Row 8 is a ceiling, and the test/CI match is loose. Row 8 counts every review round after the first, and every implementation launched after the first review, whether or not the round changed only tests. The test/CI pattern also matches some planning titles ("test plan", words ending in "red"); a stricter pattern gives 2.6% instead of 2.8%. Bias: row 8 is overstated.
• Dispatches are not effort. A wake re-reads a long context. A beat is short. where-the-effort-goes.md weighs them in tokens. Bias: none on the count, but a share of dispatches is not a share of cost.

Next

• How many wakes could the runner have held back without changing what any supervisor did? By late September each worker event sends 1.4 wakes up to a change's own supervisors, and more to epics and Runners, and PENDING-EXTERNAL pauses track them one for one. A question for John: is one wake per layer per boundary the design, or an artefact of subscribing every layer?
• What raised fresh sessions between 5 and 12 July, and what sent follow-ups to finished sessions? Read Harbour's dispatch reasons for July's launches and resumes, if any record survives, against the tickets' earlier sessions.
• Is the quiet share in August what it is in September? Only if some wake-level record from before 29 August can be recovered. Otherwise the answer waits for LIN-3157's longer retention.

The first goes into proposals.md.