Working memory vs state memory — carry what is expensive to rebuild, never carry what goes stale

[dan-claude-bot]

Moved from #119, 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 said so itself.

Why this is a thread and not an issue

Its own three section bodies, quoted exactly:

• Tasks — "Deliberately none yet. This issue is the design; the task list is written once run_session records no token or cost figure — capture the usage block and the pool identity #122 says what the sessions actually cost."
• Acceptance criteria — "Deliberately none yet — same reason."
• Open questions — genuinely open — five of them, including "what goes in the notes, and who decides?" and "does it beat cold start, and after which round?"

An issue is a work order a builder must be able to execute without asking anyone anything (TRIAGE.md). No tasks, no acceptance criteria and five open questions is not a work order — and acceptance criteria are not optional furniture: they are the builder's definition of done and the reviewer's review spec, verbatim. Without them nobody downstream has a spec at all. .ceremony/TRIAGE.md names this exact move in its "what you never do" list: "Mint an issue to 'discuss' something — that is a discussion." Triage did it anyway, five times, and this is one of the five.

The blocked label was the sharper problem. It means waiting on another issue or PR (LABELS.md) — which reads, to a scanning builder, as work that becomes claimable when #122 lands. It would not have been. This board wrote that lesson down itself, on #116: "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." A prose caution under blocked is the same trap with a longer fuse.

What survives, because it is good

The working context / state context split is the sharpest idea on this board about session cost, and it is a decision, not a question:

the mechanism must carry working context and refuse to carry state

with the reasoning that --resume carries both undifferentiated, and a round-3 session that "remembers" round 1's head is the exact bug class the fleet spent 2026-07-28 killing (#114). That belongs in whatever eventually gets built, and it is why this thread exists rather than a wontfix.

The outcome: ask — and the questions are not answerable yet

Not by @danmt, not by triage, not by a builder. Every one of them is a question about a crossover point — does carrying notes beat a cold start, and after which round — and the engine currently reports no token or cost number at all. That is #122's job.

So this thread is held on #122, deliberately, for the reason the issue already gave: "writing the table now would encode a guess as a spec" (the same reason #92 sat blocked). When #122 lands and the numbers exist, triage returns here, asks the five questions against real figures, and mints from the answers.

Nothing is waiting on this thread. It gates no issue and blocks no builder.

---

The design record, as filed on #119 — verbatim

Filed from the sherpa session at danmt's request. Blocked by #122 — deliberately. The premise is that cold-start sessions waste a lot; nobody can currently say how much, because the engine records no token or cost number at all. Building on a gut feeling is how #92 was blocked for the same reason: "writing the table now would encode a guess as a spec."

The waste

Every duty session is a cold start: run_session() runs claude … -p "$prompt" with no --continue and no --resume. A builder answering round 3 of a PR re-reads the repo, re-finds the same locations, and re-writes the same throwaway search scripts it wrote in round 1.

That part is straightforwardly wasted. What is not obviously wasted is the re-reading of state — and the difference is the whole design.

Two kinds of context, and only one is safe to carry

working context	where files live, what the code does, what was already tried and rejected	expensive to rebuild, safe to carry
state context	the head SHA, the verdicts, what main looks like now, which labels stand	cheap to re-read, dangerous to carry

--resume carries both, undifferentiated. A round-3 session that "remembers" round 1's head is the exact bug class this fleet spent 2026-07-28 killing: verdicts keyed to stale heads (#114), dependency declarations that never re-validate their own completeness (#96), a reviewer approving without re-reading.

So the mechanism must carry working context and refuse to carry state.

Why a written working-memory artifact beats --resume

danmt's framing — "each session writes work-related notes and a little map of what it has; instead of resuming you say continue doing X, here's some background" — is the better mechanism, on five counts:

1. It is curated. The agent writes what is worth keeping. A transcript accumulates everything, including dead ends and stale state.
2. It is auditable. A reviewer or operator can read the notes. A session transcript is private to one box.
3. It is vendor-portable. A file works identically for claude, codex, grok and kimi. --resume is per-vendor and may not exist for three of the four — the same per-vendor wall the tier question hit.
4. It resists context rot. danmt's own concern, and the sharpest argument against naive resume: a transcript grows monotonically and an agent drifts. A notes file can be capped, and rewritten rather than appended.
5. It survives. ~/duty/work/ already exists (install.sh:160) and is preserved across installs. A session transcript dies with a box rebuild or a gold restore.

It is also the architecture this fleet already chose. #196/#91 ruled that the engine gathers context, the model transforms, and the engine keeps the artifact. This is that same shape applied to a different duty: the engine assembles working notes plus current state, the session works, the engine keeps the notes. One pattern, not two.

Not every duty wants this

Builders and reviewers: yes. Multi-round work on one deliverable is where working context is rebuilt over and over.

Triage: no — and the reason generalises. danmt's read is right: triage's answer is to make the issue carry enough context to be cheap to re-read. That is not a consolation prize, it is a better optimisation, because triage's output is every downstream session's input. 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.

There is evidence for this already. A builder picking up #114 does not need to locate shared/lib/duty-review.sh:116, re-derive that the bug is a class rather than a site, or check whether the file the reporter named still exists on main — triage did that once. The issues written on 2026-07-28 are expensive to produce and cheap to consume, and that is the trade this issue is about, made at a different layer.

Open questions — genuinely open

• What goes in the notes, and who decides? Agent-authored free-form, or an engine-imposed structure (files touched, approaches rejected, where things live)? Free-form rots; structured constrains.
• Where exactly? ~/duty/work/<repo>#<num>/ is the obvious home, but a worktree-local file has better locality and worse durability.
• When is it discarded? On merge is obvious. On a rebase, or when the head moves substantially, is not.
• Does it beat cold start, and after which round? The crossover is unknown and unknowable without run_session records no token or cost figure — capture the usage block and the pool identity #122. It may be that round 2 pays and round 5 does not.
• Does it interact badly with prompt caching? A stable prefix caches; injecting a mutating notes file may defeat that. Needs measuring, not reasoning.

Tasks

Deliberately none yet. This issue is the design; the task list is written once #122 says what the sessions actually cost.

Acceptance criteria

Deliberately none yet — same reason. What it must eventually satisfy:

• working context persists across rounds of one deliverable; state context never does
• the mechanism degrades to today's cold start where a vendor or a box cannot support it
• the saving is measured, not asserted, against The fleet spends a shared metered resource with no instrument — session accounting per credential pool #121's numbers

Dependencies

Blocked by #122. That issue's --output-format json change returns both the usage numbers that would justify this and the session id that a --resume variant would need — one change, two unlocks. Neither this nor #121 gates 0.1.0.

Related: #120 (token-efficiency techniques), which is the same class of speculative optimisation blocked on the same numbers.

[dan-claude-bot]

Correction — this thread says all five questions wait on #122, and that is true of two of them. The hold stands; its stated reason was too wide.

Re-read at 0a29cd6 and against label events rather than against this thread, which has carried no triage comment since it was opened on 2026-08-01.

The hold's premise is intact. Re-verified rather than assumed: there is still no token or cost figure anywhere in the engine. run_session() — still the only path by which a session is spawned — logs kind, key, rc, dur, outcome, and since #256 acted and reply_tail. No usage block, no cost, no token count; a whole-tree grep for usage, input_tokens, output_tokens and cost across shared/lib/ returns nothing. #122 has carried blocked since 2026-07-28T21:29:05Z and it has never been lifted. So the crossover is as unknowable today as it was.

What this thread got wrong about itself

Its outcome section says:

"Every one of them is a question about a crossover point — does carrying notes beat a cold start, and after which round"

That is true of two of the five, and false of three. Read back against the list the thread itself wrote:

open question	is it a crossover question?
What goes in the notes, and who decides? — free-form vs engine-imposed structure	No. A design decision. "Free-form rots; structured constrains" is a trade-off argument, and no token figure resolves it either way.
Where exactly? — ~/duty/work/<repo>#<num>/ vs worktree-local	No. Locality vs durability, decidable from the repo: ~/duty/work/ already survives installs (install.sh), a worktree does not survive a merge — and #168 is open precisely because worktrees get removed.
When is it discarded? — on merge, on rebase, on a head move	No. A correctness question, and this thread already contains its own answer: notes carry working context and refuse to carry state, so a head move discards nothing, because nothing head-shaped was ever in there.
Does it beat cold start, and after which round?	Yes. The genuine crossover.
Does it interact badly with prompt caching?	Yes — and the thread says it: "needs measuring, not reasoning."

The sentence mattered because it is the one doing the holding. Stated as written, it says nothing here can be thought about until #122 lands. What is actually true is narrower and more useful: three of these are decidable now, and deciding them would still not produce an issue — for a different reason than the one given.

Why the hold stands anyway, stated honestly

Because the question that gates a mint is not what would the mechanism look like but is it worth building, and that one is squarely on the crossover. A fully-specified mechanism whose saving nobody has measured is the same failure this thread was moved off the board for — "writing the table now would encode a guess as a spec" — one layer down: the guess stops being "what does the table say" and becomes "that a table is worth having at all". Deciding the three answerable questions today would produce a tidy spec for a thing with no demonstrated prize, and a builder would execute it faithfully. So:

Outcome unchanged: ask — held on #122. What moves is the reason: it is held on the value, not on all five questions being unanswerable. Naming that correctly matters because it names what would actually lift the hold — a number, not a design meeting.

What did become measurable, and it expires tomorrow morning

The crossover needs token figures. The size of the prize does not, and that part is countable today from the ledger the fleet already writes.

The engine names its own re-entry sessions. run_session's kind is exactly the axis this thread's mechanism would serve: resume, ci-red, rebase and review are all sessions that re-enter work which already exists — the ones that rebuild working context from cold — while build is the first pass over an issue. Their count and their dur= are on every SESSION END line in duty.log, and acted= now says which of them ended having done nothing. Summing them bounds what a working-memory artifact could ever save, in wall-clock, with no token figure anywhere in the calculation. If that total is small, this thread's mechanism is not worth building whatever the crossover turns out to be — and that is answerable from two real working days rather than from argument.

One limit, stated so nobody over-reads the ledger: key is repo-scoped for build and review and PR-scoped only for ci-red and rebase (call sites). So rounds per PR has to come from the board side, not from duty.log alone. Both halves are in scope for the same report.

#290 is where that corpus lives, it is ready and unclaimed right now, and the deadline is physical. Its 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 on them is backed up. The token figures this thread waits on are not perishable — #122 has produced none and will produce them whenever it lands. This evidence is perishable and it is gone next week.

So the instruction to whoever writes that report is the same one #236 and #233 were given: what the re-entry session kinds cost across 2026-08-01/02 is this thread's upper bound on the prize — record it as such, and triage returns here with it.

What does not move

The working context / state context split is unchanged and is still the sharpest thing on this board about session cost — a decision, not a question, and the reason this thread exists rather than a wontfix. Nothing about #121, #122 or #123 moved: all three are open, and #122 is blocked.

Nothing is waiting on this thread. Re-derived from the parsed dependency declarations of all 52 open issues: no open issue's blocker set names it.

Triage, 2026-08-02.

[dan-claude-bot]

The report this thread waits on is being written now — the wake is unchanged, and the instruction has an addressee at last

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 and is writing the report on draft PR #311. The sentence in my comment three hours ago that says it is unclaimed and startable stopped being true this evening; it is left standing as the record of when the instruction was issued.

Nothing this thread concluded moves. The hold is still on the value question rather than on all five open questions, still lifted by a number and not by a design meeting, and #122 is still open with no token or cost figure anywhere in the engine.

What changes is only that this thread's asked-for figure now has someone to compute it. Restated so it is findable from the report side rather than only from here: the total wall-clock spent in resume, ci-red, rebase and review sessions across 2026-08-01/02 is this thread's upper bound on the prize — what a working-memory artifact could ever save, with no token figure in the calculation. #290's phase 2 already requires count × duration × outcome per duty kind, so that number falls out of work the report must do anyway; no scope is being added to a claimed issue on this thread's account, and none is asked for.

When the report lands, triage returns here and reads the bound off it. If it turns out small, this thread's mechanism is not worth building whatever the crossover says — which is the outcome this thread has been holding open for.

Triage, 2026-08-02.

[dan-claude-bot]

The bound this thread asked for is computed — off the corpus rather than the report, and the answer relocates the prize

My comment three seats up promised: "When the report lands, triage returns here and reads the bound off it." The report has not landed — #290 is still claimed @andriujoseba on draft PR #311, and triage recorded at 10:25Z today that the codex-builder box is disarmed, so its resume is an operator act with no date on it. Waiting for the report was therefore not a schedule.

What did land is the corpus, exported 2026-08-03T10:18:04Z and public: dan-claude-bot/crew-corpus at commit 9442833. The bound this thread asked for falls out of it directly, so triage read it now rather than waiting. Anyone can re-derive it — clone, then aggregate the SESSION END lines of every box's duty.log:

grep -h 'SESSION END' */duty/duty.log   # ts, kind=, key=, rc=, dur=, outcome=

1. First, the premise this thread is held on — verified, not assumed

No token or cost figure exists anywhere in the corpus. A grep for total_tokens, input_tokens, output_tokens and cost_usd across all 414 session transcripts and all eight duty.log files returns zero files. The SESSION END line carries kind, key, rc, dur and outcome, and nothing else.

So the hold on #122 (blocked since 2026-07-28T21:29:05Z, re-read from its label events) is unchanged and now proven by measurement rather than asserted from the code. This thread's five questions are all crossover questions; a crossover needs a price; there is still no price.

2. The bound, as asked for

Window 2026-08-01T12:54:39Z → 2026-08-03T09:57:14Z, seven duty boxes, 411 sessions, 60.02 hours of model wall-clock.

kind	sessions	total	median
review	156	20.63 h	351 s
build	46	15.34 h	1137 s
triage	34	7.58 h	779 s
hygiene	41	6.39 h	434 s
mention	40	4.74 h	274 s
attention	15	2.02 h	—
resume	66	1.73 h	59 s
operator	8	1.16 h	—
ci-red	4	0.40 h	—
rebase	1	0.04 h	—

The four kinds this thread named — resume, ci-red, rebase, review — total 227 sessions and 22.79 hours, 38.0% of the run. That is the number, and it is an upper bound in the strict sense: it is what those sessions cost in total, not what a working-memory artifact could save from them.

3. What the number changes, and it is not the outcome

The prize is not where this thread's body puts it. The body's split says "Builders and reviewers: yes", and the mechanism it describes — notes carried across rounds of one deliverable, so a round-3 session stops re-deriving round 1 — reads most naturally as a fix for resume. Resume is 1.73 h of the 22.79, 2.9% of the whole run, at a 59-second median. It is the cheapest duty kind the fleet runs.

review is 20.63 h — 90.5% of the bound and a third of the entire run. If a working-memory artifact is worth building, the measured case for it is a reviewer re-reading one PR across rounds, not a builder resuming a draft. Adding build (15.34 h), which the thread's own reasoning arguably includes, takes the bound to 38.13 h, 63.5% of the run — and both large halves are the two duties where one deliverable is visited repeatedly, which is this thread's thesis surviving contact with numbers.

Two caveats, both load-bearing, and neither is a hedge:

• Wall-clock is not spend. A 59-second resume session may still ship a large prompt and a pile of tool results; a 20-minute review may be mostly waiting. Nothing here ranks a technique, and this comment deliberately does not.
• An upper bound is not a saving. Every one of those 22.79 hours would have to be pure re-derivation for the prize to equal it, which it plainly is not.

Outcome unchanged: ask — held on #122

Held for exactly the reason it always was: writing the table now would encode a guess as a spec. What changed is that the guess is smaller — the thread now knows the shape of the run it wants to optimise, and knows that a mechanism aimed at resume sessions would be aimed at 2.9% of it.

Nothing is waiting on this thread, and it gates no issue. Re-checked against #122's label events rather than this thread: still blocked, still the wake.

Triage, 2026-08-03.

[dan-claude-bot]

The bound's source moved from the corpus to main — the clone recipe in my comment above no longer runs, and the two session tables differ only by their windows

This morning's comment computed this thread's upper bound off the corpus and told any reader they could re-derive it: "Anyone can re-derive it — clone, then aggregate the SESSION END lines." They cannot, as of 2026-08-03T12:10:11Z: dan-claude-bot/crew-corpus went private at @danmt's direction (record on #290), deliberately held until after the report merged. Access is now by request through @danmt.

The public replacement landed in the same minutes: #290's report merged 12:08:44Z and the issue closed 12:23:07Z. It is postmortems/2026-08-01-to-2026-08-02-fleet-run.md on main (525a041), and it carries the session table this thread needs.

Two tables, two totals, one difference — and it is the window

Both are now on the record and they do not agree at the units. They are reconciled by their filters and by nothing else, so both filters are stated here rather than left for a reader to discover:

	window	sessions	wall-clock
my table, 10:40Z	first record 2026-08-01T12:54:39Z → corpus collection 2026-08-03T09:57:14Z	411	60.02 h
the merged report	2026-08-01 00:00 → 2026-08-02 23:59	408 completed	215,775 s (59h 56m 15s)

Mine ran ten hours further into 2026-08-03, against a fleet that was largely shut down overnight — which is why forty-five hours of window buys three sessions. The report also names dan-claude explicitly as a box contributing zero session records rather than dropping it silently, which mine did not. The report's is the citable pair: it is reviewed, its derivation is stated, and its per-kind counts sum exactly to its total.

The bound, recomputed from the public split

The report gives count and summed duration per kind but does not sum this thread's four. From its own figures — review 155 / 74,120s, resume 64 / 6,038s, ci-red 4 / 1,429s, rebase 1 / 139s:

81,726 s = 22h 42m — 37.9% of the run. My figure on the wider window was 22.79 h / 38.0%. The bound is unchanged in everything that matters and is now checkable by anyone with a clone of main.

And the relocation of the prize survives, on the public numbers. resume is 6,038 s — 2.8% of the whole run; review is 74,120 s — 34.4%. The mechanism this thread's body describes reads most naturally as a fix for resume sessions, and resume is the cheapest duty the fleet runs. If a working-memory artifact is worth building, the measured case for it is a reviewer re-reading one PR across rounds.

One thing does not survive the access change, and it is worth saying rather than leaving implied. The per-kind medians I published this morning — review 351 s, build 1137 s, resume 59 s and the rest — are not in the report, which publishes counts and sums only. Nobody can re-derive them without operator access to the corpus. They stand as measured and they are no longer independently checkable; where a median matters to an argument, get access rather than quoting me.

What has not moved

The working context / state context split is unchanged and is still the sharpest thing on this board about session cost — a decision, not a question. The hold is still on the value rather than on all five open questions, still lifted by a number and not by a design meeting, and the number still does not exist: the report's own words are "The corpus records no token or monetary cost per tick." #122, re-read from its label events, has carried blocked since 2026-07-28T21:29:05Z and it has never been lifted.

Outcome unchanged: ask — held on #122. An upper bound is not a saving, and wall-clock is not spend. Nothing is waiting on this thread, and it gates no issue.

Triage, 2026-08-03.

[dan-claude-bot]

The issue this thread is held on was closed three hours ago — not delivered, and the hold now points at a window rather than at a number's arrival

This thread's hold has read "held on #122" since 2026-08-01, and my comment at 12:35Z restated it. Re-read from that issue's timeline rather than from this thread: #122 closed at 2026-08-03T15:54:15Z, in the operator-directed board-hygiene pass, with blocked still on it — a close does not move the queue label, so a scan still reads it as held.

What the close was, in its own words (the comment):

"Closed for board hygiene at the operator's direction: the open board carries epics and the current window only. 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."

So the hold's reason is untouched and only its address moved. No cost figure shipped in the interval: 0.1.1 published at 15:26:53Z and its changelog section carries no usage capture, and the merged report's sentence — "the corpus records no token or monetary cost per tick" — is still the state of the evidence. What is no longer true is the wake: "when #122 lands" now names a closed issue, and this thread is the surface that recorded it.

The corrected wake, in two parts

the price	#327 (0.1.3 — telemetry) carries #121 whole, its checklist naming "#122 capture" inside it. #327 opens when #346 (0.1.2) closes, and it opens by hand — the release-init cycle on the roadmap, where triage re-opens #122 or mints fresh from it against the then-current tree.
the mechanism	#329 (0.1.6 — wake efficiency) names this thread and #233 by number as its evidence threads, and its to-mint list carries cross-session working memory in the operator's own two kinds (2026-08-03): the handoff — episodic, per-claim, "a structured note written at checkpoint/death and read first on resume (files read, hypotheses, next edit)" — and the toolshed — procedural, fleet-wide, "session-written scripts promoted to an indexed library agents consult before writing".

That second row is what this thread has never had: a carrier. Its comments have ended "triage returns here and mints from the answers" since 2026-08-01 — the mint now lands in #329's window instead, and this thread is what that window's init reads.

The split this thread exists for survives into it intact. The handoff is working context per deliverable, the toolshed is working context per fleet, and neither is state. Carry what is expensive to rebuild, never carry what goes stale is the sentence both bullets are written against.

One thing worth carrying into that init rather than discovering there. On the merged report's public numbers, resume is 6,038 s — 2.8% of the run and review is 74,120 s — 34.4%. #329's framing puts the bill on the flood's re-read checkpoints, which is resume-shaped; the measured case for a working-memory artifact is a reviewer re-reading one PR across rounds. That is this thread's own finding, and it is the one thing in it that a builder handed #329's bullet would otherwise get backwards.

Outcome unchanged: ask — held on the numbers

Held for the reason it always was: writing the table now would encode a guess as a spec, an upper bound is not a saving, and wall-clock is not spend. What moved is the address — the price is #327's, the mechanism is #329's — and "when #122 lands" is no longer a sentence anyone should wait on.

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]

The window that produces the number this thread is held on is the next one — and 0.1.2 is at its cut tonight

First comment here since 2026-08-03 18:02Z, which corrected the hold's address from "when #122 lands" to the price is #327's, the mechanism is #329's. Re-measured at main's head f5bd61c rather than carried forward.

1. The premise, re-verified by execution rather than quoted

There is still no token or cost figure anywhere in this tree. A grep for input_tokens, output_tokens, total_tokens, cost_usd, num_turns and total_cost across the whole repository at f5bd61c returns zero hits. common.sh:239 still ends a session with kind, key, rc, dur, outcome, acted and reply_tail, and nothing else.

So the hold stands for exactly the reason it always did: writing the table now would encode a guess as a spec, and the guess still has no price.

2. The address stopped being indefinite

My last comment said the price is produced at #327's (0.1.3) release-init. Read from that epic's body rather than from the roadmap's summary of it, its carried set is a re-open of #122 (capture) and #124 (vendor quota), plus a fresh mint from #121's decomposition ledger — #123 and #125 having been ruled onto #328.

And 0.1.3 is now the next window. 0.1.2 is at its cut: #400 is claimed with PR #401 open in draft, #346 is still open, and #327's gate is "opens when #346 closes", by hand.

That is the first time this thread's wake has had a near date rather than a chain of them. "When #122 lands" was never a schedule; "the window after the one being cut" is one, and the thing that opens it is a triage act rather than a sweep.

3. One new ledger line the next bound computation must not miss

The bound this thread published was summed off SESSION END lines. Since 2026-08-07 there is a second class of record: #388's per-lane terminal breaker, merged on #393, writes SESSION SKIP kind= key= reason=terminal-breaker count= for a dispatch refused before the CLI starts.

Two consequences for whoever recomputes at #327's init, neither of them a change to this thread's conclusion:

• a future run's session count is no longer the whole dispatch count, and a SESSION END-only aggregation will silently under-report what the fleet decided to do;
• it is a saving that shipped with no cost figure in the argument at all — found by reading an incident, priced in sessions rather than tokens. That is not evidence against measuring; it is a reminder that this thread's hold is on this mechanism's value, not on the idea that value must be measured before anything can ship.

4. What has not moved

The working context / state context split — carry what is expensive to rebuild, never carry what goes stale — is unchanged and still a decision rather than a question. So is the finding a builder handed #329's bullet would otherwise get backwards: on the merged report's public numbers resume is 6,038 s, 2.8% of the run and review is 74,120 s, 34.4%. The mechanism reads most naturally as a fix for resume sessions; the measured case for it is a reviewer re-reading one PR across rounds.

The census in my last comment is void. It read "over all 22 open blocked bodies: every one names #346." Board at this write: 31 open — 19 epic, 6 post-merge, 3 blocked, 2 claimed, 1 ready (19+6+3+2+1 = 31), zero needs-triage, attention, stale and offsite, two open PRs (#401 draft, #410 at state:needs-human). Blocker parse: #406 → {#402, #403}, #408 → {#406}, #411 → {#408}; union {#402, #403, #406, #408}, none of them this thread. One needs-ruling stands on the board, on #400 since 2026-08-07T21:32:17Z — the release cut's drill-sequencing ask, naming nothing here.

Outcome unchanged: ask — held on the numbers

An upper bound is not a saving and wall-clock is not spend. Nothing is waiting on this thread, and it gates no issue. The wake is #327's init; absent real activity before then, triage returns on 2026-08-14 under the same 7-day discipline #317, #338 and #351 carry.

Triage, 2026-08-07.

[dan-claude-bot]

This thread stopped being a consumer of 0.1.3 and became a constraint on it — and the cost ruling applied this thread's own principle to a schema

One delta since my comment of 2026-08-07 21:42Z. The premise is re-executed first, because this thread's standing discipline is that it re-runs rather than carries forward.

1. The premise, re-run at main's head

At a237f42: a git grep for input_tokens, output_tokens, total_tokens, cost_usd, num_turns and total_cost across the whole tree returns zero hits, and common.sh:239 still ends a session with kind, key, rc, dur, outcome, acted and reply_tail — nothing else. Unchanged through the whole 0.1.2 drill wave. The hold stands for exactly the reason it always did: writing the table now encodes a guess as a spec, and the guess still has no price.

2. This thread is now cited inside the window's scope reasoning

The boundary annotation of 10:52Z records that the design session considered re-cutting 0.1.3 and 0.1.4 on a metrics-vs-events line — machine readings in one window, the event ledger in the next. It was declined for four reasons, and one of them is this thread, by number:

"#122's capture cannot move. The invariants recorded here are explicit: 'Structured output capture returns the session id — the same change is the handle 0.1.6's handoff memory needs (discussion #232). Capture it in this window's build or that arc re-opens this one.' Moving event capture to 0.1.4 either breaks that dependency or creates a forward reference across two hand-gated windows."

That is a different standing from waiting behind a window. The session id this thread needs as its handle is one of the reasons 0.1.3 keeps event capture at all — so a re-cut that would have stranded this thread was declined partly because it would have stranded this thread. Recorded here because nothing in this thread would tell a reader that, and the re-cut question is the kind that comes back at window-open.

3. The cost ruling is this thread's rule, applied to a schema by someone not citing it

this thread's title	the taxonomy, 11:10Z
carry what is expensive to rebuild	"the session row must carry model as well as token counts" — the inputs are captured because they cannot be reconstructed afterwards
never carry what goes stale	"estimated cost, burn rate, spend-against-quota — store: nowhere, computed at read"; bake a cost figure in at capture and a vendor price change becomes "a data migration"

The deliberate exception is what shows the rule was reasoned rather than coincided with: where a derived figure is cached for speed, the rate-table version is stored beside it, so the cached value stays re-derivable. Carrying the staleness marker with the stale thing is the only honest way to cache a derived value — and it is the sharpest statement of this thread's doctrine anywhere on this board, sitting in a telemetry schema rather than in an agent-memory design.

That matters here for one reason: this thread's hard question has always been where the line between the two memories actually falls on a real artifact, and this is the first time the fleet has drawn it on one. Whatever 0.1.6 carries between sessions can now cite a shipped precedent instead of re-arguing from the title.

4. Where this leaves the thread

Answered; still held, and the address is unchanged — the price is #327's, the mechanism is #329's. Neither window has opened, and 0.1.2 is still at its cut with three members open. What moved is standing rather than schedule.

Triage 2026-08-09 12:3xZ.

[dan-claude-bot]

The hold has lifted — this thread's own grep returns hits now, and the guess it refused to encode has a price

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

This thread carries no return date, correctly — its wake is an event. It is nonetheless 8 days late, for the reason worth naming: an event-keyed wake whose event nobody watches reads as "nothing due" forever. No sweep, no nudge, and not the returns on <date> scan either, which by design skips a dateless thread. Recorded rather than passed over, because this is the third dateless thread in a row to have gone dark this way.

The measurement this thread's hold rested on has inverted

My comment of 2026-08-09 ran a git grep at a237f42 for input_tokens, output_tokens, total_tokens, cost_usd, num_turns and total_cost across the whole tree and got zero hits, with common.sh:239 ending a session at kind, key, rc, dur, outcome, acted, reply_tail. The stated hold: "writing the table now encodes a guess as a spec, and the guess still has no price."

Re-run identically at 70bd7d4:

field	files
input_tokens	7
output_tokens	7
cost_usd	7
sid=	7
total_tokens	0
num_turns	0

shared/lib/common/session.sh now carries _session_usage_suffix() — emitting cost_usd= onto the SESSION END line — and _session_sid_suffix(), with sid= pinned last in the wire order. The record shape this thread was a constraint on rather than a consumer of is built.

Every issue that carried it is closed: #475 (capture — the re-mint of #122, whose immovability the boundary annotation justified by naming this thread), #485, #483, #538 and #572.

The forward reference this thread was cited to protect held. The boundary annotation's fourth reason for declining the metrics-vs-events re-cut was "#122's capture cannot move … Capture it in this window's build or that arc re-opens this one", with discussion #232 named in the quoted invariant. Capture landed in 0.1.3, in this window's build. The arc did not re-open. Saying so explicitly because a dependency that is honoured leaves no trace, and this one was load-bearing enough to decide a window boundary.

What the hold becomes, rather than simply ending

The guess now has a shape and does not yet have a price. #585 — open, blocked — is the gap: "the rate card checked against a real billed claude session, the one figure no builder session can observe." The emitted cost_usd is computed off #572's table; nobody has yet checked that table against a billed statement, and its evidence surface is one no agent session reaches.

So this thread's principle — carry what is expensive to rebuild, never carry what goes stale — applies to itself one more time: the record shape is safe to build against now, and the cost figures in it are not yet safe to reason about. That is a narrower hold than the one it replaces, and it is the honest one.

Outcome: hold narrowed, still no ask for @danmt

Nothing 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: this thread wakes when #585 lands an observed billed envelope, or when a fresh fleet corpus is collected — the last one was taken 2026-08-03T10:25:13Z, 29 days before the engine that now emits these fields, so it prices the wrong engine. Both are events with a board entry behind them, which the previous wake condition did not have.

Triage, 2026-09-01.