Techniques for token efficiency — a candidate list, deliberately unranked until the numbers exist

[dan-claude-bot]

Moved from #120, minted by triage on 2026-07-28 as a "design record". It is carried verbatim below, unedited. It is here rather than on the board because triage minted it against its own contract, and the issue's own first paragraph says so.

Why this is a thread and not an issue

Its own header, quoted exactly:

📝 DRAFT — design record, not a buildable ticket

Do not claim this. No acceptance criteria, deliberately: every candidate below is a guess about where tokens go, and the engine currently reports no token or cost number at all.

And its title says the rest: "a candidate list, deliberately unranked". An unranked list of guesses, explicitly marked do-not-build, is a discussion — TRIAGE.md's "what you never do" names the move directly: "Mint an issue to 'discuss' something — that is a discussion." Triage did it anyway.

The blocked label made it worse rather than safer. blocked means waiting on another issue or PR (LABELS.md), so on a board scan this read as work that becomes claimable the moment #122 lands. It would not have. #116 records the lesson in this repo's own words: "the queue label is a dispatch signal, not a status annotation. A prose caution under a ready label is not a caution, it is a trap."

What survives, because it is good

The ordering principle — ranked by how cheaply each can be tested, not by expected saving — and the constraint that frames all five candidates:

this fleet's failure mode is not "too slow", it is "silently wrong", so a lossy optimisation in the wrong place is worse than the spend.

That sentence should govern whatever is eventually picked, and candidate 2 (tool-result discipline — "probably the largest single line item and the least glamorous") is very likely the right first move on the numbers.

The outcome: ask — held on the numbers, and the first move is triage's

The question this thread owes an answer to is not "which technique?" It is, in the issue's own words:

The first task after #122 is not to pick one — it is to look at the numbers and find out whether the gut feeling is right and where.

That first act is triage's, not a builder's: reading measurements and ranking candidates is what produces the work order, and it cannot be delegated to whoever picks the ticket up. So this thread is held on #122. When per-session cost is visible, triage ranks the candidates here against real figures and mints the one that wins.

Recorded honestly: danmt's starting position is "I have a gut feeling we're wasting an absurd amount of tokens." Probably right. Still not measurable, and that has not changed since 2026-07-28.

Nothing is waiting on this thread.

---

The design record, as filed on #120 — verbatim

📝 DRAFT — design record, not a buildable ticket

Filed from the sherpa session at danmt's request. Do not claim this. No acceptance criteria, deliberately: every candidate below is a guess about where tokens go, and the engine currently reports no token or cost number at all. Committing to one before #122 lands would encode a guess as a spec — the reason #92 sat blocked for the same thing.

danmt's framing, recorded because it is the honest starting position: "I have a gut feeling we're wasting an absurd amount of tokens." Probably right. Not yet measurable.

Why a list and not a plan

Each technique below trades something. Without #121's numbers there is no way to tell which is buying a real saving and which is buying complexity at the cost of correctness — and this fleet's failure mode is not "too slow", it is "silently wrong", so a lossy optimisation in the wrong place is worse than the spend.

Ordered by how cheaply they can be tested, not by expected saving.

Candidates

1. Terse prompting. Strip prose from the rendered prompts; keep the contract. Cheapest to try, easiest to measure, and the only one with no correctness risk beyond a prompt that is now ambiguous. shared/prompts/*.txt are versioned templates, so an A/B across boxes is mechanical once #122 reports per-session cost.

2. Tool-result discipline. Much of a session's spend is likely tool output the model never uses — full file reads where a range would do, unbounded grep, whole diffs. Not a technique so much as an audit; probably the largest single line item and the least glamorous.

3. A code graph or index. Pre-build a map of the repo so sessions stop re-deriving where things live. Real saving; two real costs — it must be maintained, and a stale index is worse than none, because the agent trusts it. Interacts directly with #119: a shared index is a fleet-wide version of that issue's per-deliverable working notes.

4. Context compression. Summarise long inputs before they reach the model. Highest ceiling, highest risk: compression is lossy by definition and the loss lands where nobody looks. Would need the same treatment #119 gives state context — never compress the volatile half.

5. Prompt-cache alignment. Order the prompt so the stable part is a stable prefix. Costs nothing at runtime and may already be partly true by accident; worth knowing before changing prompt structure for other reasons, since #119's notes-injection could defeat it.

6. Not spawning the session. #91's thesis, and it belongs on this list because it beat every technique here: a session that shouldn't have been spawned is the cheapest possible saving. Handoff was spending a full agent session and a repository clone to make two API calls and write one paragraph. Look for the next one of those before optimising the ones that should exist.

What is already working, unglamorously

Dense triage issues. An issue that names the file and line, states the class, and records what was already checked is paid for once by triage instead of once per builder per round. A builder on #114 does not re-locate duty-review.sh:116, re-derive that the bug is a class, or re-check whether the reporter's named file exists on main.

Worth stating because it is the counterexample to the whole list: the largest token saving found so far came from writing things down properly, not from a technique.

Dependencies

Blocked by #122. Nothing here should be built, and no candidate ranked, until per-session cost is visible. The first task after #122 is not to pick one — it is to look at the numbers and find out whether the gut feeling is right and where.

Related: #119 (working memory vs state memory), which is the same class of optimisation at the session layer and blocked on the same numbers.

[dan-claude-bot]

Update — one of the six candidates stopped being a guess today, and its evidence expires at tomorrow's rollout

This thread's outcome line says the list is held on #122 and closes:

"Still not measurable, and that has not changed since 2026-07-28."

That was true when it was written yesterday and it is now true of five candidates, not six. Re-read from the board rather than from this thread.

Candidate 6 was never a token question

6. Not spawning the session. #91's thesis […] a session that shouldn't have been spawned is the cheapest possible saving. […] Look for the next one of those before optimising the ones that should exist.

Candidates 1–5 all trade an unknown saving against a correctness risk, and none of them can be ranked without a per-session token figure — which is exactly what #122 does not yet emit and why this thread holds. Candidate 6 is a different unit. It does not ask what a session costs; it asks how many sessions should not have run. That is countable from duty.log alone — SESSION END kind= rc= dur= outcome= lines — and it is countable today.

#290 is the vehicle, it is ready and unclaimed right now, and its phase 2 enumerates this candidate's measurement almost word for word:

"Where the sessions went: count × duration × outcome per duty kind per box; the zero-action/busy-tick rate (the #256 shape, now measurable); holds and how long each held."

"Round economics: rounds per PR, verdicts per round, re-review latency, sessions burned by the #286 loop, and what a review round costs end-to-end."

Two things made that possible and neither existed when this thread was written. #256 landed — a zero-action session ending in a question no longer reports outcome=ok — so the busy-tick rate is derivable from the ledger instead of being invisible in it. And #286 landed today: one 📣 re-requesting a changes-requested panel forever, which #290's own framing records as having "burned six reviewer sessions at an unchanged head before a hand stopped it." That is candidate 6's thesis with a number already attached, found by watching hours of operation rather than by any token ledger.

Why this is worth a comment rather than a shrug

The evidence is perishable and the deadline is physical. #290's phase 1 exports each box's ~/duty/ record before that box is upgraded or re-minted, and the 0.1.1 rollout (#280, cut tomorrow morning) upgrades or re-mints exactly those boxes. Boxes are disposable and nothing there is backed up. So the corpus that would rank candidate 6 against two real working days exists today and may not exist next week — while the token figures the other five wait on are not perishable at all, because #122 has not produced any yet.

And the ranking act this thread reserved is the one #290 performs. This thread's own words: "That first act is triage's, not a builder's: reading measurements and ranking candidates is what produces the work order." #290's deliverable is a written report whose findings are each filed as issues, plus a proposed 0.1.2 re-cut recorded on #162 for danmt's ruling. So the instruction to whoever writes that report is the same one #236 was given this morning: what your session accounting shows about sessions that should not have run is this thread's answer on candidate 6 — record it as such, and triage mints from it.

What does not move

Candidates 1–5 stay held on #122, unchanged and for the unchanged reason. #290's corpus carries counts, durations and outcomes — no token or cost figure anywhere in it — so terse prompting, tool-result discipline, a code graph, context compression and cache alignment remain unrankable, and committing to one would still encode a guess as a spec. #122 is open and blocked behind #163; nothing about that moved today.

The ordering principle stands, and it is what makes this split legitimate rather than opportunistic: ranked by how cheaply each can be tested, not by expected saving. Candidate 6 just became the cheapest to test by a wide margin, which is where the list said it would earn its place.

Outcome, restated: ask — held on #122 for five of six candidates, and no longer held for the sixth. Nothing is waiting on this thread, and it gates no issue.

Triage, 2026-08-02.

[dan-claude-bot]

Candidate 6's vehicle is claimed and in flight — the deadline this comment warned about is being met

Short update, from label events rather than from this thread. #290 is no longer ready and unclaimed — @andriujoseba claimed it at 2026-08-02T18:26:00Z, three hours after my comment above said its evidence expires at tomorrow's rollout, and is writing the report on draft PR #311. The "ready and unclaimed right now" line above is left standing as the record of when it was issued.

The split holds exactly as stated. Candidates 1–5 stay held on #122 — the report's corpus carries counts, durations and outcomes and no token or cost figure at all, so nothing in it can rank terse prompting against tool-result discipline. Candidate 6 is the one that stopped being a guess, and its measurement is what #290's phase 2 performs.

One caveat worth having on the record before the numbers arrive, because it is the kind of thing a reader infers wrongly from a good report: a low zero-action rate would not retire candidate 6. The rate counts sessions that ran and did nothing; the candidate's thesis is about sessions that should never have been spawned, and the #286 loop is the proof that those two are different — six reviewer sessions at an unchanged head, each of which did something, all six of which should not have existed.

Triage, 2026-08-02.

[dan-claude-bot]

The corpus landed, candidate 6 has a measured instance — and it is five times smaller than the thing beside it

My comment above said candidate 6 stopped being a guess and that its measurement is what #290's phase 2 performs. Phase 2 has not run — #290 is still claimed @andriujoseba on draft #311, and triage recorded at 10:25Z today that codex-builder is disarmed. But the corpus it feeds on is public as of 2026-08-03T10:18:04Z (dan-claude-bot/crew-corpus, 9442833), so the part of this thread's question that the corpus can answer, triage answered now instead of waiting.

The hold on candidates 1–5 stands, and is now a measurement rather than a claim

There is no token or cost figure anywhere in the corpus. total_tokens, input_tokens, output_tokens, cost_usd — zero hits across all 414 session transcripts and all eight duty.log files. The SESSION END record is kind, key, rc, dur, outcome, full stop.

So nothing in it can rank terse prompting against tool-result discipline, and #122 (blocked, re-read from its label events) is still the only thing that could. Candidates 1–5 are unmoved. The thread's ordering principle survives untouched.

Candidate 6 — "not spawning the session" — priced in wall-clock

Two things the corpus can price, both from dur=:

The #311 flood. 59 resume sessions on codex-builder between the last commit (19:16Z) and the shutdown (00:05Z), 61.7 minutes of model time, mean 63 s, every one rc=0 outcome=ok — the shape that makes this class invisible to any health check that reads exit codes. It is 89% of all resume duty the entire fleet ran in two days (59 of 66 sessions). Its engine defect is filed as #314, ready since this morning, on the 0.1.1 cut.

And the thing next to it, which is bigger. Nine sessions in the same window ended TIMEOUT or FAILED — 2.2% of 411 sessions, burning 305.4 minutes, 8.5% of all fleet wall-clock, every one running to its cap and yielding nothing:

box	kind	outcome	dur
kimi-reviewer	review	TIMEOUT	2700 s
kimi-reviewer	review	FAILED	624 s
kimi-reviewer	operator (floor) ×2	TIMEOUT	1800 s each
claude-triage	mention ×2	TIMEOUT	~1500 s each
claude-triage	hygiene	TIMEOUT	3000 s
claude-reviewer	attention	TIMEOUT	1800 s
claude-builder	build	TIMEOUT	3600 s

Candidate 6's own logic points at the second table, not the first. A session that shouldn't have been spawned is the cheapest possible saving — and a session that ran to its timeout and produced nothing is the same saving, five times over, in the same two days. The flood is the more offensive shape (93 comments, a legible loop) and the smaller number.

The correction this makes to my own comment above

I wrote: "a low zero-action rate would not retire candidate 6 … the candidate's thesis is about sessions that should never have been spawned." That still holds. What I did not anticipate is the direction of the surprise: the measured zero-yield burn is dominated not by sessions that should never have been spawned, but by sessions that were correctly spawned and then did not finish. That is a different defect class with a different fix, and it is not on this list at all.

Not filed, and the reason is the one this thread already established. Findings from this run route through #290's finding set, and a triage mint that front-runs the report inverts what that issue exists to do. #314 is the exception rather than the precedent — the operator pulled it onto the cut. The timeout finding is recorded here and on #290 so the report does not re-derive it.

Outcome unchanged: ask — held on #122

Wall-clock is not spend, and this comment ranks nothing. When per-session cost exists, triage ranks the candidates here against real figures and mints the winner — as this thread has said since 2026-07-28.

Nothing is waiting on this thread.

Triage, 2026-08-03.

[dan-claude-bot]

Candidate 6's vehicle landed and closed — the figure I priced it at is superseded by a wider boundary, and the hold on 1–5 is now a merged statement rather than triage's assertion

#290's report merged at 2026-08-03T12:08:44Z and the issue closed at 12:23:07Z. The deliverable is postmortems/2026-08-01-to-2026-08-02-fleet-run.md on main (525a041) — public, reviewed by four panelists, and its board half re-derivable by anyone.

The hold on candidates 1–5 stands, and stopped being something triage asserts

"The corpus records no token or monetary cost per tick, so neither rate establishes loss on its own."

That is the merged report's own sentence. #122, re-read from its label events rather than from this thread: blocked since 2026-07-28T21:29:05Z, never lifted. Terse prompting, tool-result discipline, a code graph, context compression and cache alignment are unmoved and unrankable, for the unchanged reason, and the ordering principle — ranked by how cheaply each can be tested, not by expected saving — is untouched.

Candidate 6's number is superseded — by a boundary, not by a correction

This morning I priced it at 59 resume sessions / 61.7 minutes, measured from the last commit at 19:16Z. The reviewer-converged figure in the merged report is:

"63 completed resume sessions in 3,954s (1h 5m 54s), all ok, despite the parked head having no doable work."

on a boundary that starts at the 18:51:18 park declaration, excludes the session that posted it, and runs through corpus collection. Mine is a strict subset of that; cite the report's.

And do not carry my "89% of all resume duty" percentage onto it. The report's fleet-wide resume total is 64 / 6,038s and is in-window (2026-08-01 00:00 → 2026-08-02 23:59); the 63 deliberately runs past that window's end — the report says so: "includes the two post-midnight resumes before collection." The two do not divide, and 63/64 is the ratio a reader would compute by accident. The ratio belongs to my window; the priced figure to quote is the report's 3,954s.

The direction-of-surprise correction I made this morning is now the report's own ranked finding

I wrote that the measured zero-yield burn is dominated not by sessions that should never have been spawned but by sessions that were correctly spawned and did not finish. The report puts a multiplier on it:

"nine TIMEOUT or FAILED sessions / 18,325s (305m 25s): 2.2% of the 408 completed sessions but 8.5% of their 215,775s wall-clock. This in-window total is more than four times the 3,954s parked-resume comparator, whose explicitly different boundary runs from the park declaration through corpus collection."

Both boundaries stated in one sentence, which is what makes the comparison legitimate. That class is not on this thread's candidate list and is not a token question either — it is routed to the sentinel's layer-one indicators, recorded on #236.

Two pointers in my comment above are stale

• #314 is not ready. Re-read from its label events: ready 10:34:35Z, claimed @cndgrr 11:20:49Z, PR #318 open and out of draft. Candidate 6's engine defect is being built now.
• The corpus link no longer resolves. dan-claude-bot/crew-corpus went private at 12:10:11Z at @danmt's direction (record), held until after the merge so no reviewer verified against a 404. Access is by request through @danmt; the figures live in the merged report.

Outcome unchanged: ask — held on #122 for candidates 1–5

Wall-clock is still not spend, and nothing here ranks a technique. Candidate 6 has been measured, its instance has a filed and claimed fix, and the class next to it turned out larger — none of which prices a single one of the other five. When per-session cost exists, triage ranks the candidates here against real figures and mints the winner, as this thread has said since 2026-07-28.

Nothing is waiting on this thread, and it gates no issue.

Triage, 2026-08-03.

[dan-claude-bot]

Candidate 6's fix shipped, and the issue candidates 1–5 are held on was closed — one of those is delivery and the other is bookkeeping

Two board events since my comment at 12:34Z, read from the issues rather than from this thread. They point in opposite directions and it is worth not letting the second be mistaken for the first.

1. Candidate 6 — not spawning the session — is the first item on this list to ship

#314 closed at 2026-08-03T13:12:35Z on PR #318 (merged 13:12:34Z), and it went out in 0.1.1, published 15:27:16Z. Three entries in CHANGELOG.md's 0.1.1 section, quoted because they are what actually shipped rather than what the issue asked for:

"Resume dispatches only when a draft's head, a foreign comment or review, or its referenced issue has moved since the last resume — a parked draft no longer wakes a session every tick forever."

"A resume that makes no commit at one head three times running is suppressed until the head moves, with one WARN in duty.log naming the PR, the head and the count."

So the one candidate this thread could price is also the one with a landed fix, thirty-six hours after it stopped being a guess. And its generalisation now has a window: #329 (0.1.6 — wake efficiency) carries it as a to-mint bullet in the operator's own words — "the spawn gate: the duty engine consults 'did anything change' before a session exists — the #314 doable-work gate, generalized to every duty kind." That is candidate 6 as a work item rather than a thesis, and this thread is named on that epic as one of its two evidence threads.

2. Candidates 1–5: the issue they are held on closed, and nothing was delivered by that

#122 closed at 15:54:15Z in the operator-directed board-hygiene pass (the close comment), with blocked still on it — a close does not move the queue label. Its own words: "Not declined and not lost — this issue's work and context are carried by epic #327 […] when that window opens, triage re-opens this issue or mints fresh from it."

The hold's reason is exactly what it was. There is still no token or cost figure: none in the engine, none in the corpus, and the merged report's own sentence stands — "the corpus records no token or monetary cost per tick." Terse prompting, tool-result discipline, a code graph, context compression and cache alignment remain unrankable, and committing to one would still encode a guess as a spec.

What moved is the address. The wake is no longer "when #122 lands"; it is #327 (0.1.3 — telemetry), which carries #121 whole with "#122 capture" named inside its checklist, and which opens by hand when #346 (0.1.2) closes, under the roadmap's release-init cycle. A reader who checks #122 today finds a closed issue and could reasonably conclude either that the ledger shipped or that the question was dropped. Neither is true.

3. The class this thread found and does not own now has a carrier too

My comment this morning recorded the direction-of-surprise: the measured zero-yield burn is dominated by sessions that were correctly spawned and did not finish — nine TIMEOUT/FAILED sessions, 2.2% of sessions and 8.5% of wall-clock, more than four times the parked-resume comparator. That class is not on this candidate list and is not a token question.

It is now on #327's to-mint list, as the "tick-health surface: last-tick age, skip/hold counts, outcome streaks — the numbers the 2026-08-01/02 report mined by hand", and on #236 as indicator 1. Recorded here so this thread's list is not the place someone goes looking for it.

Outcome unchanged: ask — held on the numbers for candidates 1–5

The ordering principle is untouched — ranked by how cheaply each can be tested, not by expected saving — and nothing here ranks a technique. When per-session cost exists, triage ranks the candidates against real figures and mints the winner, as this thread has said since 2026-07-28. The place that produces the figure is now #327's window.

Nothing is waiting on this thread. Re-derived at this write with blockers.jq's own clause parse over all 22 open blocked bodies: every one names #346, and none names this thread.

Triage, 2026-08-03.

[dan-claude-bot]

Two candidates were added to the fleet's efficiency backlog tonight — on an epic, not on the list that claims to be the list

This thread's standing promise is that it is the candidate list, and that triage ranks the candidates here against real figures and mints the winner when per-session cost exists. Two new ones landed at 20:25:19Z, folded onto #329 (0.1.6 — wake efficiency) at @danmt's direction from the fifteen-PR review-friction analysis. Neither appears in the six above. Recording them here so the ranking, when it happens, is over the whole set.

Candidate 7 — risk-tiered panels

Every PR costs panel-size × rounds reviewer sessions, so the panel is the fleet's token amplifier and each added builder multiplies through it. The proposal: a diff whose paths resolve docs-only draws a rotating two-reviewer tier; shared/, cli/, drill/, workflows and the installer draw the full panel; ambiguity rounds up; an AC demanding specific verification routes to full panel regardless of paths. The classifier input already exists — the scope labeler's path map — and panel resolution is already the engine's act (#133).

Candidate 8 — per-duty model-tier routing

Named in the same fold-in as a sibling lever, "recorded in #121's notes and on no epic's surface." Measured: it has a full design record of its own at #92 — the kind → tier table over the nine-duty enum, a BOT_CLI_CHEAP_CMD per-vendor shape deliberately built on the stable yes/no half rather than on model names, the ruling not to route across vendors (one box, one identity, and a second vendor's secret is not worth a rounding error), the unverified fact that grok and kimi may not express a cheap tier at all, and the observation that reasoning effort may be the cheaper axis than model — same binary, same auth, no capability cliff. #121 only names it in passing (line 87). #92 is closed by @danmt 2026-07-28T19:59:03Z with no close comment, still carrying a ready label a blockers-cleared sweep wrote when #90 was hand-closed, which a builder declined to claim on exactly those grounds. Intact and findable; just not where an init would look.

Where they sit against this list's ordering principle

The principle is ranked by how cheaply each can be tested, not by expected saving — and candidate 7 is the first arrival that genuinely tests cheaply, because its premise is a board measurement rather than a token one. Verdict counts and finding counts are public and re-derivable by anyone; per-session cost is still the thing that does not exist.

So triage re-derived its premise instead of repeating it, from the three PRs the fold-in cites, and it did not survive intact — the full measurement is on #329, where the mint will read it. In short: #342 is the clean instance (docs-only, four verdicts, nothing found); #315 is not docs-only by path — it changes fleet-floor/test/cli.sh, so the proposal's own classifier would draw the full panel for it; and #313 is a counterexample — docs-only, one file, and codex's CHANGES_REQUESTED caught a vacuous negative verification in the issue's test plan that grok, claude and kimi all approved past within three minutes. One of four found it. It was fixed by amending the acceptance criteria, on an unchanged tree.

That is this thread's own constraint arriving on the newest candidate, and it is why the sentence at the top of this list still governs:

this fleet's failure mode is not "too slow", it is "silently wrong", so a lossy optimisation in the wrong place is worse than the spend.

A docs tier is a deliberately lossy optimisation on the detection axis. It may well be worth it — idle fourth verdicts on CHANGELOG.md are real — but it is the first candidate on this list whose saving and whose risk are the same mechanism, and it should be ranked knowing that rather than on the strength of "it would have caught everything."

Candidate 8 is unmoved and unrankable, for this list's unchanged reason: #92 states its own gate correctly — without measured per-kind burn the table encodes a guess. Same gate as candidates 1–5, at the same address.

Outcome unchanged: ask — held on the numbers

Candidates 1–5 and 8 are held; candidate 6 shipped in 0.1.1; candidate 7 is newly on the board with a home at #329 and a premise that needs re-measuring before it becomes an acceptance criterion. Nothing here ranks a technique, and the ordering principle is untouched. The place that produces the figure is still #327's window (0.1.3), where #122 and #124 are carried — and, since 20:37:57Z, #121 itself, closed onto that epic with its decomposition ledger intact.

Nothing is waiting on this thread. Re-derived at this write by running blockers.jq's own clause parse over all 22 open blocked bodies and partitioning by full declaration set: 21 parse to {346} alone and #312 to {203, 346} (its co-gate discharged 2026-08-02T21:32:51Z) — none names this thread.

Triage, 2026-08-03.

[dan-claude-bot]

Candidate 6 has a second measured instance, and it shipped this morning — the only line on this list that has ever produced work

One delta since my comment of 2026-08-03 20:48Z. It lands on candidate 6, and on the instruction underneath it rather than on the ranking.

1. Sixteen sessions that could not succeed, in thirty-five minutes

#388 was filed 2026-08-06 from a live incident on kimi-reviewer and closed 2026-08-07T07:41:20Z on PR #393 (bf70f88). Its measurement, quoted from the issue:

kimi-reviewer exhausted its billing-cycle quota mid-tick. […] The engine retried it every five minutes for thirty-five minutes — eight ticks × two repos, sixteen sessions, each starting the CLI, minting a session id, being rejected, and exiting. It would have continued indefinitely; nothing in the loop can end it, because nothing in the loop knows the difference between "try again in five minutes" and "this cannot succeed until a billing cycle rolls over".

That is candidate 6 exactly — a session that shouldn't have been spawned is the cheapest possible saving — at sixteen instances of it, unbounded, with two PRs unreviewable throughout.

2. What shipped, and what it is worth on the incident's own shape

shared/lib/common.sh now carries a per-lane breaker:

• _session_terminal_record counts consecutive terminal dispatches, and any success, timeout, transient failure or unclassified failure resets the count — absent or uncertain hooks are fail-safe by construction;
• at SESSION_TERMINAL_THRESHOLD (default 3) it trips, warns, and alerts exactly once, on the transition;
• _session_terminal_gate then refuses the lane before the CLI starts — SESSION SKIP … reason=terminal-breaker — and a later tick spends one cheap vendor probe instead of a session; a probe that succeeds clears the breaker and dispatch resumes in that same tick.

On the shape #388 recorded, that is three doomed sessions instead of sixteen, the remainder replaced by one probe per tick, and a 🚨 alert where the entire prior signal was sixteen outcome=FAILED acted=unknown lines in a file on a box.

The second blindness the issue names is closed too, and it is the enabling half rather than a footnote: shared/conf/agents/kimi.conf now defines both bot_session_acted and — alone among the three agent confs — bot_session_terminal, the hook that separates a quota-terminated 403 from a network blip. Without a per-vendor classifier the breaker would have to guess, and guessing wrong here stops a healthy lane.

3. What this does to the ordering principle: nothing, and that is the finding

Both of candidate 6's instances arrived the same way and neither came from this list. #91 was found by noticing what handoff was spending; #388 was found by @danmt reading raw session logs on a box, which the issue's own first line calls the finding. The list's ordering principle — rank by how cheaply each can be tested — still has not been exercised once, because the thing it ranks against still does not exist: the engine reports no token or cost number, exactly as the design record said on 2026-07-28.

So the honest status of this page is two-tiered, and worth stating plainly rather than leaving implicit:

	status
candidate 6 — not spawning the session	two instances, both shipped, found by reading incidents. Standing doctrine, not a list entry
candidates 1–5, 8	held on the numbers, unranked, unchanged since 2026-07-28
candidate 7 — a docs review tier	on the board at #329, premise still needs re-measuring; deliberately lossy on the detection axis

Candidate 6's own sentence is the one to carry forward: "Look for the next one of those before optimising the ones that should exist." It has now paid twice, and both times the search was an operator or a session reading a log rather than a technique being ranked.

4. The address of the hold is nearer than it has ever been

0.1.2 is at its cut — #400 is claimed with PR #401 open in draft — so the next window the chain opens is #327 (0.1.3), whose carried set is #122, #124 and #121: the per-session ledger, its console view, and the decomposition ledger itself. That is where the figure this list is held on is produced, and it is one window away rather than the indefinite wait this thread has carried since 2026-08-01.

Nothing here ranks a technique, and no candidate is minted. An issue enters a release by decision, not by triage's default.

Outcome unchanged: ask — held on the numbers

Nothing is waiting on this thread, re-derived at this write by running the pinned 0.6.2 blocked_references over every open blocked body — three of them, parsing to {#407}, {#402, #403} and {#406} — none of which names this thread.

Triage, 2026-08-07.

[dan-claude-bot]

The number this list has been unranked-until since it opened now has a decided shape — and a caveat that bounds how the ranking may be read

One delta since my comment of 2026-08-07 16:24Z, which landed on candidate 6. This one lands on the gate itself. This thread's standing promise is that triage ranks the candidates here against real figures and mints the winner when per-session cost exists; cost did not exist and had no specified shape. As of this morning it has one.

1. What was ruled

The reading taxonomy, 11:10Z, from an operator design session on 0.1.3:

• The session row carries model and token counts — "ledger records — subject: a session or duty — session id, duty kind, outcome, model, token counts", in crew's corpus, append-only and kept.
• Cost is never stored. "Cost is tokens × price(model, date). Store the inputs and compute in the read path" (#123's crew usage); a cached figure carries the rate-table version beside it so it stays re-derivable. The stated reason is the one that matters here — bake cost in at capture and "last month's estimate can never be re-run under a corrected table."

So the figure this thread waits for is not a number, it is tokens by model per session, priced at read. For a ranking that is strictly better than a stored cost: candidates can be re-scored under a corrected price table without re-capturing anything.

2. It settles candidate 8 outright — worth saying, because I filed it as unmeasurable

Candidate 8 — per-duty model-tier routing was added here on 2026-08-03 with a design record of its own at #92 and no way to evaluate it. model on the session row is its measurement: the query that prices a duty kind prices it by tier in the same pass, so "is a cheaper tier adequate for this duty" stops being a question an argument settles. Nothing else on this list gets its evaluation from the schema for free.

Candidate 7 — risk-tiered panels is priced off the same rows — panel-size × rounds in reviewer sessions per duty kind, with the docs-only tier's saving as the difference between two groups of real sessions.

3. The caveat, which bounds the ranking rather than delaying it

Ruled by @danmt in the same session: credential identity on the session row is an operator-declared label, defaulting to the box's own identity. The alternative — a derived non-reversible in-box digest, or the vendor's own account identifier — was considered and declined as overbuilt for an interim, with the residual risk accepted knowingly and in writing:

"undeclared sharing under-attributes, silently, right up to the ceiling, and a declared label cannot detect it."

What that costs a ranking run from this thread: the unit is the declared label, never the box. Two boxes on one credential with distinct labels split one spend across two rows, and no assertion anywhere can catch it — the ruling says so rather than leaving it to be discovered. A ranking that reads per-box totals as per-credential truth under-prices precisely the candidates that touch the busiest shared identity, which on this fleet is the reviewer panel, and therefore candidate 7 — the one candidate on this list whose whole claim is about panel size. So when the ranking runs it states the unit it used, and the declared labels are checked against reality before it runs rather than after.

4. Where this leaves the thread

Answered; still held, and the hold's address is a schema now rather than a window. The ranking is still due when #327 ships capture — that window is still gated on #346's close and 0.1.2 is still at its cut — but the arriving figure is specified well enough that the ranking method can be written before the numbers land, which was not true yesterday. Unchanged: this thread is the whole candidate set, and the ranking runs over all eight or it is not the ranking this thread promised.

Triage 2026-08-09 12:3xZ.

[dan-claude-bot]

The hold has lifted — the grep this thread has been unranked-until now returns hits, and the ranking is due

Triage 2026-09-01, re-measured at main 70bd7d4.

This thread carries no return date, correctly — its wake is an event: "the ranking is still due when #327 ships capture." That event has fired, and nothing woke this thread when it did. It is 8 days late for a structural reason worth naming: an event-keyed wake whose event nobody is watching reads as "nothing due" forever, on every surface — no sweep, no nudge, and not the returns on <date> scan either, which by design skips a thread with no date in it.

Capture shipped. The measurement, run exactly as my comment of 2026-08-09's sibling ran it

The git grep that returned zero hits tree-wide on 2026-08-09 — and was the whole basis of the hold — now returns:

field	files at 70bd7d4
input_tokens	7
output_tokens	7
cost_usd	7
sid=	7
total_tokens	0
num_turns	0

Carried by shared/lib/common/session.sh, shared/lib/common/ledger.sh, shared/conf/agents/claude.conf, shared/conf/model-prices.conf and their three mirrored suites. The session record now has a _session_usage_suffix() emitting cost_usd= and a _session_sid_suffix() emitting sid=, where on 2026-08-09 the SESSION END line ended at reply_tail and nothing else.

The issues that did it are all closed: #475 (capture — #122's re-mint), #485 (vendor quota), #483 (the vitals probe), #538 (sid= and resume), #572 (the per-model price table).

So the condition this thread set for itself is met: the ranking is no longer waiting on a schema, on a window, or on a decision. It is waiting on numbers, which is a different and much shorter wait.

The one thing still genuinely missing, and it is not a schema

The tree can now emit a cost figure; nobody has observed a billed one. #585 — open, blocked — is precisely that gap: "the rate card checked against a real billed claude session, the one figure no builder session can observe." Its evidence surface is a live billed session, which is operator-owned by the same reach test the issue contract applies.

That bounds how this thread's ranking may be read, and it does not block writing it. The candidate set is still all eight and the ranking still runs over all eight or it is not the ranking this thread promised — but the ranking method, which the 2026-08-09 comment already said could be written before the numbers land, can now be written against a real emitted record shape rather than a specified one. The figures that fill it in are #585's, and the fleet corpus that would price them at scale is a collection nobody has re-taken since 2026-08-03T10:25:13Z — 29 days before the engine that replaced it. Re-costing against that corpus would report the old engine's numbers as evidence about the new one, which is the exact error the hold existed to prevent.

Outcome: hold released, still no ask for @danmt

Nothing here is minted by this comment and no label moves. There is no question on this page for you, which is why it carries no return date and still needs none.

The wake condition is re-stated so it cannot go dark again, since the last one did: this thread wakes when #585 lands an observed envelope, or when a fresh fleet corpus is collected — whichever is first. Both are events with a board entry behind them now, which the previous wake condition did not have.

Triage, 2026-09-01.