RECEIPT: the measured curve behind “the more tasks we assigned, the more efficient, more accurate, and cheaper every single model got”

Dispatch D-BP223-PQ005-037, seat PQ005-037 (Opus 5.5), dispatched by PQ005 on the Founder’s word “do that now”. Written 2026-09-27T01:58Z (date -u). Files only: no site change, no database write, no send.

Sentence under test (the Founder’s): “in our massive marathon sessions using MnemosyneC, the more tasks we assigned, the more efficient, more accurate, and cheaper every single model got.”

Prior-work check (build-verb gate, 2026-09-27T02:0xZ): the gate’s name-token candidates were opened (HARDWIRE\LEDGER\WORK_RECEIPTS\D-BP163-M0-024_seg-standard-curve_receipt.md is a qPCR standard-curve canon task; BISHOP_DROPZONE\FIRST_COMPLETE_COST_RECEIPT_BP160.md is a one-question MMLU-Pro dollar total; BISHOP_DROPZONE\D-BP167-M0-023_RETURN_session_receipt_and_cost_report.md is a single-session transcript cost report). None builds a per-task curve for the June marathons. The nearest prior measurement is BISHOP_DROPZONE\D-BP223-PQ001-006-CONTEXT-CARRY-RECEIPT\ (Claude Code SEG vs non-SEG sessions, July onward, signs disagree), which this receipt does not repeat.

THE SHORT ANSWER

1. Across the marathon week, yes, per task cost and time fell by about half. Every Sonnet 4.6 SEG (sub-agent task) in the three orchestrated June marathons, 31 SEGs in start-time order from 2026-06-15 to 2026-06-20: the first third averaged $2.70 per SEG, the last third $1.30 (ratio 0.48, linear trend falling), at Anthropic list price with prompt caching. Input tokens per SEG fell from 7.06M to 2.86M (0.41), active time per SEG from 1,546 s to 629 s (0.41), tool calls per SEG from 160 to 52 (0.32). Session means: 2026-06-15 $2.82 per SEG, 2026-06-16 $2.17, 2026-06-20 $1.33.
2. Inside one session, no: the same kind of task got MORE expensive as the context filled, not less. Every model request re-reads the whole context, and the reconstructed input per request tracks the context size at r = 0.98 to 0.997 in all three sessions. Like-for-like tasks (the orchestrator’s short reply to each landed SEG) cost 1.46x to 2.10x more in the last third of each session than in the first third, with caching.
3. “More accurate” is not measurable from this record. No per-task correctness field exists. The on-screen matrices show every wave essentially all pass (6 of 6 in the 40 percent wave; 6 GREEN and 1 AMBER, fleet-blocked, in the 7-SEG wave), so there is no room to show a rise, and no record of one.
4. “Every single model” is not supported. Every session found is one model family: claude-sonnet-4-6 (orchestrators) and claude-4.6-sonnet-medium-thinking (SEGs), in Cursor. No other model is in these records.
5. The 68 of 70 plow has no per-question log on this machine. The only per-question plow log on disk is a different run (BP078 Phase A, 2026-06-08), and its time per question is flat (72.5 s first third, 70.4 s last third).

1. WHAT SESSIONS WERE FOUND, AND WHERE

Starting point: <estate>\Documents\LianaBanyanPlatform\BISHOP_DROPZONE\D-BP223-PQ005-031-FOUNDER-RECEIPTS-MARATHON\RECEIPT_FOUNDER_MARATHON_SESSIONS_AND_68_OF_70_v1.md (screenshot times are Central, UTC minus 5 in June) and <estate>\Documents\LianaBanyanPlatform\HARDWIRE\LEDGER\DORA\eblets\reference_off_the_charts_context_gauge_screenshots_and_reingestion_receipt_bp223.eblet.md.

Located by streaming every file in <estate>\Documents\LianaBanyanPlatform\BISHOP_DROPZONE\D-BP223-BM0-X010-023-CORPUS2\CURSOR_STAGING\ (2,886 Cursor conversations; script find_sessions.py) for turns dated 2026-06-14 to 2026-06-21, then reading the same conversations from the scratch copy of the Cursor database, opened read-only and immutable: <estate>\Documents\LianaBanyanPlatform\BISHOP_DROPZONE\D-BP223-BM0-X010-023-CORPUS2\DB_SCRATCH_COPIES\cursor__global__global.vscdb (the staging .jsonl export keeps only text and timestamps; the database keeps durations, tool calls and Cursor’s own token counts).

Full header data: SESSIONS_FOUND.json.

Not found: Claude Code transcripts for June. The Claude Code store <estate>\.claude\projects\*\*.jsonl (266 files, streamed by find_cc_sessions.py) begins 2026-07-26; nothing from 2026-06-10 to 06-25 is on disk. The June marathons ran in Cursor. Per-question log of the 2026-06-15 01:47 Central plow: not found (section 6).

2. WHAT EACH RECORD HOLDS AND LACKS

Holds (measured by Cursor, per message): timestamp; tool call and tool name; turnDurationMs (Cursor’s own active time for the turn); thinking duration; the final context total; and a prompt usage tree giving Cursor’s own estimated token count for every message still in the prompt, in order.

Lacks: billed tokens per request. Every bubble’s tokenCount field is 0 in all seven sessions and all 31 SEGs (column bubble_tokenCount_nonzero). No dollar figure, no cache-read count, no per-task correctness field. The Cursor bill itself is not on disk.

Therefore the token and dollar numbers below are reconstructed, not billed: each model request’s input = the fixed prompt overhead (system prompt, tools, rules, skills, MCP, sub-agent definitions) plus every conversation message before it, using Cursor’s per-message estimates scaled so they sum to Cursor’s own conversation total (scale 1.20 to 1.25 in A, B, C); output = the assistant message’s own tokens (thinking not counted). Dollars use Sonnet 4.6 list price ($3 input, $15 output, $0.30 cache read, $3.75 cache write per million tokens) in two versions: no cache, and with cache (everything the previous request already sent is a cache read, the rest a cache write). Ratios (last third over first third) do not depend on the price or the scale factor.

Validation of the reconstruction against Cursor’s own readings. Cursor wrote its measured context size on some Founder turns. Session A: 8 readings, 48,024 to 159,732; the reconstruction’s growth over the same turns is 0.914 of Cursor’s, and the step-by-step growth correlates at r = 0.990. Session B: 9 readings, 79,074 to 119,237; growth ratio 0.890, r = 0.997. So the reconstruction follows Cursor’s own counter closely and, if anything, understates growth by about 10 percent.

Summarization (context compaction), which limits D, E, F, G and the A SEGs. When Cursor summarizes, earlier messages leave the prompt tree. Sessions A, B, C orchestrators: no summary (every turn has token data). Sessions D, E, F, G: summarized (6,727 to 12,422 summary tokens; E keeps tokens for only 3 of its 25 turns), so for them only the measured fields (active time, tool calls) are used, never tokens. SEGs: all 22 SEGs in B and C are unsummarized; 7 of the 9 SEGs in A were summarized, so A’s SEG costs are lower bounds (their pre-summary requests are missing). That bias makes the fall from A to C, if anything, understated.

3. THE NUMBERS

First third mean, last third mean, ratio (last over first), and the sign of a plain least-squares line, per series. From CURVE_STATS.json, computed by compute_curves.py from the CURVE_DATA_*.csv files.

3a. The fleet of SEGs across the week (the “more tasks” axis)

CURVE_DATA_FLEET_SEGS_20260615_20260620.csv, graph CURVE_FLEET_SEGS_20260615_20260620.png. 31 SEGs, thirds of 10.

Per session: A (2026-06-15, 9 SEGs, lower bound) $2.82 per SEG, 7.42M input tokens, 1,658 active s, 171 tool calls; B (2026-06-16, 11 SEGs) $2.17, 5.03M, 785 s, 77; C (2026-06-20, 11 SEGs) $1.33, 2.93M, 622 s, 53.

Without A (B and C only, 24 unsummarized SEGs, thirds of 8): $2.41 to $1.22 (0.50), input 0.45, active time 0.78, tool calls 0.60. All falling.

Inside one session the SEG trend is mixed: A rising (2.12, lower bound), B rising (1.31), C falling (0.35; wave 2 of 7 SEGs averaged $1.17 against wave 1 of 4 at $1.61, tool calls 46.9 against 64.5, active time 638 s against 593 s).

3b. Inside each orchestrator session, as the context filled

Graphs CURVE_A_20260615.png, CURVE_B_20260616.png, CURVE_C_20260620.png; data CURVE_DATA_A_20260615.csv and siblings. A task is one user turn and everything until the next user turn; two kinds exist, a Founder turn (real work) and a SEG result notice (Cursor injects one when each SEG lands; the orchestrator writes a short reply). The final notice in each session has no reply on record and is excluded from cost.

C has only 2 Founder turns (too few for thirds); its falling all-task line is a mix effect (two big dispatch turns early, small notices late), not cheaper work.

3c. The counter-check: context rises, so did per-task cost rise or fall?

Context at the start of each task rose in every session (A 23.8% to 87.1%, B 23.7% to 66.4%, C 25.2% to 87.8%). Correlation of reconstructed input per request with context at task start: A 0.997, B 0.982, C 0.985. At list price without caching, cost per Founder turn tracks context at r = 0.995 (A) and 0.416 (B). With caching the link weakens (A 0.553, B minus 0.447 for Founder turns) because a cached re-read costs a tenth of a fresh one, and in B the Founder turns also used fewer tool calls later (4.3 to 2.0). Plain reading: inside one context, a task of the same kind costs more late than early; caching and shorter turns can hold a Founder turn’s cost roughly flat (session B), but nothing in the record shows a task getting cheaper because the context was fuller.

3d. Single-seat sessions (measured fields only)

Graphs CURVE_D_20260615.png to CURVE_G_20260620.png. Active seconds per Founder turn, first to last third: D 5.2x rising (n=3), E falling to near zero (n=5, the last turns were one-line exchanges), F 3.6x rising (n=9), G 10.0x rising (n=6). Tool calls per turn: D, E, F falling, G rising. No consistent direction; these do not support or refute the sentence.

4. THE GRAPHS

• CURVE_FLEET_SEGS_20260615_20260620.png: cost and active time per SEG, all 31, colored by session, dashed linear trend. This is the one that matches the sentence.
• CURVE_A_20260615.png, CURVE_B_20260616.png, CURVE_C_20260620.png: per task cost (Founder turns and SEG notices), context percent at task start (its own panel, no second axis), and cost per SEG in dispatch order.
• CURVE_D_20260615.png, CURVE_E_20260616.png, CURVE_F_20260615.png, CURVE_G_20260620.png: active seconds and tool calls per Founder turn.
• CURVE_PLOW_BP078_20260608.png: seconds per plowed question, BP078 Phase A (a different run from the 68 of 70).

5. TELEMETRY TOOLS (read only, nothing recorded)

• mcp__librarian__get_session_telemetry: returns only the current seat’s tracker (10 calls since 2026-09-26T04:57Z). Nothing about June.
• mcp__librarian__test_telemetry_timeline with test_id 1f64b973...: data_available: false, 0 snapshots.
• mcp__librarian__test_telemetry_cost_savings since 2026-06-14: 134 snapshots, actual spend $0, counterfactual $0, savings $0. No per-task cost.
• mcp__librarian__substrate_savings_summary (all): 102 rows, earliest 2026-04-25; it refuses a savings headline (2 of 102 rows carry a counterfactual). No June per-task series.
• mcp__librarian__record_substrate_savings: not called (write tool; this dispatch is read only).

6. THE PLOW

The 68 of 70 run (MnemosyneC v0.3.5, 2026-06-15 01:47:46 Central) left no per-question log on this machine. Searched: files modified 2026-06-15 00:00 to 03:00 Central under <estate>\Documents\LianaBanyanPlatform\benchmarks, <estate>\Documents\mnemosyne and <estate>\.mnemosynec (only two starter chocolate files matched); the app data folders AppData\Roaming\MnemosyneC, AppData\Roaming\mnemosyne, .mnemosyne, .mnemosynec (no June 14 to 16 files; the one results file, .mnemosynec\test-data\mmlu-pro\results\plow_smoke_M0_results.json, is dated 2026-06-12); two librarian searches (“plow per-question results 70 questions 316 eblets v0.3.5 June 15”, “316 eblets”: no results); a pheromone query (hits are canon eblets, not logs). The on-screen tally in the screenshot remains the only record of that run. The CLI bundle in the “J files 15 Jun 2026” folder says it was built for gemma2:2b and may have run on another machine; that is not verified.

The only per-question plow log on disk is <estate>\Documents\LianaBanyanPlatform\benchmarks\plow_phase_a_bp078.log (2026-06-08, 120 questions, all “ok”; CURVE_DATA_PLOW_BP078_20260608.csv). Seconds per question 72.5 first third, 70.4 last third (0.97, line essentially flat); facts accepted per question 11.5 to 10.3; seconds per accepted fact 7.4 to 8.7 (rising). It measures mining time, not model cost, and its follow-on test (test_phase_b_bp078.log, gemma4:12b) scored 0 PASS, 37 FAIL, 79 ANDON. It does not support the sentence.

7. PLAIN-SENTENCE FINDINGS

1. Across the June 2026 marathon week (31 Sonnet 4.6 SEG tasks in Cursor, 2026-06-15 to 2026-06-20), the later tasks cost about half as much as the earlier ones: $2.70 to $1.30 per task at list price with caching, with 59 percent fewer input tokens, 59 percent less active time and 68 percent fewer tool calls.
2. The fall holds day by day ($2.82, $2.17, $1.33 per SEG on 06-15, 06-16, 06-20) and holds without the first day’s lower-bound figures ($2.41 to $1.22 across B and C).
3. The record cannot say why: the tasks were not the same size, so “the fleet got more efficient” and “the later tasks were smaller” cannot be separated from these files.
4. Inside one session the opposite holds for like-for-like tasks: each request re-reads the whole context, so the same kind of task cost 1.5 to 2.1 times more at the end of a session than at the start.
5. Accuracy did not measurably change; the record has no per-task correctness and the waves that were scored on screen were essentially all pass.
6. One model family only: every session is Sonnet 4.6 in Cursor.
7. The 68 of 70 plow has no per-question log on this machine.

8. WHAT THE FOUNDER MAY NOW SAY, AND WHAT HE STILL MAY NOT

He may now say, with this receipt: “In our June marathon week, as we kept assigning more tasks to Sonnet 4.6 sub-agents, each task got cheaper and faster: the last ten of 31 cost about half what the first ten did (about $1.30 against $2.70 at list price), finished in about 40 percent of the time, and used about a third as many tool calls.” He should say “about half” and “in our Cursor sessions of 2026-06-15 to 2026-06-20”, and if pressed, that the tokens are reconstructed from Cursor’s own per-message counts because Cursor does not store the bill. He may not yet say “every single model” (one model family is on record), “more accurate” (no correctness series exists), “cheaper as the context grew” (inside a session the same kind of task got more expensive as context filled), or that MnemosyneC caused the fall (the tasks changed size across the week and the record cannot separate the two). A paired run (the same task list, run once early and once late, or with and without the substrate, with billed usage captured) would be the receipt for those.

FILES (all in <estate>\Documents\LianaBanyanPlatform\BISHOP_DROPZONE\D-BP223-PQ005-037-MARATHON-COST-CURVE\)

• Scripts: find_sessions.py (locate Cursor conversations by date), find_cc_sessions.py (Claude Code store date range), extract_cursor_curve.py (all CURVE_DATA csv files and SESSIONS_FOUND.json; Rule 66 siblings extract_cursor_curve.superseded.*.py), compute_curves.py (all statistics, CURVE_STATS.json, all PNG files); inspection helpers peek_composer.py, peek_bubbles.py, peek_usage.py, peek_tree.py, align.py, coverage.py (print field names and numbers only).
• Data: CURVE_DATA_A_20260615.csv, CURVE_DATA_B_20260616.csv, CURVE_DATA_C_20260620.csv, CURVE_DATA_D_20260615.csv, CURVE_DATA_E_20260616.csv, CURVE_DATA_F_20260615.csv, CURVE_DATA_G_20260620.csv, CURVE_DATA_A_20260615_SEGS.csv, CURVE_DATA_B_20260616_SEGS.csv, CURVE_DATA_C_20260620_SEGS.csv, CURVE_DATA_FLEET_SEGS_20260615_20260620.csv, CURVE_DATA_PLOW_BP078_20260608.csv, SESSIONS_FOUND.json, CURVE_STATS.json.
• Graphs: CURVE_A_20260615.png, CURVE_B_20260616.png, CURVE_C_20260620.png, CURVE_D_20260615.png, CURVE_E_20260616.png, CURVE_F_20260615.png, CURVE_G_20260620.png, CURVE_FLEET_SEGS_20260615_20260620.png, CURVE_PLOW_BP078_20260608.png.

Secrets: no secrets file was opened. The Cursor composer rows carry two encryption-key fields; the scripts never read or print them, and no message text is written to any output (the SEG outcome keyword counts are computed in memory from the redacted staging export and only the counts are saved).