- DREW'S CALL (2026-08-03): route the 30-target x2-9 wave to SONNET instead of Opus. The §136i
>=120-ins Opus threshold was MY EXTRAPOLATION, never measured; this wave (125-793 ins) probes
exactly the region where there was no data.
- RESULT: 13 banked of 16 that ran = **81%**, vs Opus's 10/13 = 77% on the comparable S8-3 slice.
At least 8 banked SONNET-DIRECT (65 agents spawned: 60 sonnet, 5 opus escalations). Propagated
57 member-matches / 4 failed across 42 overlays. 70 instances. R22 clean-fleet 140/140.
FLEET 96.01% fn / 93.6% instr / 88.0% distinct (77,550 uniq).
=> **Sonnet is at least as capable as Opus on 125-793 ins. The ~120 boundary is too low.**
NOT rewriting it to a specific number yet: 16 samples under a throttle confound cannot name a
cliff. The controlled A/B (task #12) is how that number gets fixed properly.
- THE REAL LIMITER IS CAPACITY, NOT CAPABILITY: 14 of 30 agents were killed by SERVER-side
throttling ("Server is temporarily limiting requests (not your usage limit)") that 30 concurrent
Opus agents did not trigger. Practical rule: run Sonnet waves at ~12-16 concurrency, not 30.
The 14 unrun targets are listed in the checkpoint for a smaller-batch retry.
- Sonnet's work quality was not shallow — three examples: func_8018797C read local-alloc.c and
forced loads into an AGGREGATE to stop find_free_reg greedily taking 3 callee-saved regs;
func_8018D870 used §136c sibling-first for ~70% of the body then blocked a coalesce with a pin;
func_8017E3AC diagnosed an RC-3 callee-saved-order swap and noted the pin must be s32 or a stray
`andi 0xffff` appears.
- MY ERROR, RECORDED: `until [ -s <output> ]` fires at the FIRST LINE of output, not at completion.
It fired mid-propagation and I ran `make clean` on top of a live family_sweep, deleting asm/ and
aborting both the regen and the sweep (corpus's R32 assertion refused to answer rather than return
a wrong stub set — working as designed). No bad bytes: R22 verified 140/140 immediately after, and
the propagation simply re-ran clean. Correct waiter is `pgrep -x make` (exact process name), which
also cannot self-match the way `pgrep -f <pattern>` did when it leaked 4 waiter shells earlier.
Third instance today of ONE root cause: trusting a proxy instead of the thing itself (a weight
column vs a probe §136h; an exit status vs build output §136a; file-existence vs process exit).
Drew T