Skip to content

docs(bench): record Run C, Sonnet, Run D and a held-out check on real graphs - #290

Draft
tonyketcham wants to merge 3 commits into
claude/agent-memory-context-potency-6sniud-statefrom
claude/agent-memory-context-potency-6sniud-results
Draft

tonyketcham wants to merge 3 commits into
claude/agent-memory-context-potency-6sniud-statefrom
claude/agent-memory-context-potency-6sniud-results

Conversation

@tonyketcham

@tonyketcham tonyketcham commented Oct 19, 2026 •

Copy link
Copy Markdown
Collaborator

Summary of changes

This is layer 10 of a stack. It sits on #289.

This PR adds no code. It records four sets of paid benchmark runs, all on Haiku except where noted.

1. find against no-brief on the 10x graph: look-alike filler, and Sonnet. These runs use the same task texts and find_hash as #286. Figures are for the 245 comparable questions.

Run find correct No-brief correct Only this arm right Read tokens, find ÷ no-brief
Haiku, look-alike filler graph 233.7 214.7 19 to 1 (p < 0.0001) 0.38
Sonnet, plain graph 233.4 226.7 11 to 5 (p = 0.21) 0.56
  • Look-alike filler: 30% of the filler records reuse real subsystem names, and the gain stays at 19. That is the plan's Run C, and it passes.
  • Sonnet: without search Sonnet already does well, so its accuracy gap is small. Search still saves 44% of the reading.
  • Questions that name no Effort: find won 7 to 0 under both models.

2. Run D: proof state added to find. This ran twice on the 97 count, status-history, blocker and dead-evidence questions of the 10x graph. findstate got 181 of 194 question-runs right and find 171 (15 to 5, p = 0.041). It read 18% fewer tokens. That meets the plan's mark for keeping state: at least 4 more per run, with no rise in tokens. The holdout half, which state was not shaped on, points the same way (5 to 1) but is too small to show on its own.

3. A held-out check on two real graphs. Two private project graphs, of 200 and 134 records, tested whether the gains hold on memory nobody tuned against. An author who never saw find or state output wrote 39 and 41 checked questions. Each set ran twice, with three arms.

Graph find No-brief findstate Read tokens, find / no-brief
A 71.7 of 78 66.3 71.3 12,488 / 27,975
B 75 of 82 71 74 12,230 / 24,389
  • find against no-brief: 13 to 3 over both graphs (p = 0.021), at about half the reading.
  • findstate against find: no difference, at the same tokens. The state gain does not show on graphs this small.

Privacy. The private questions, answers, graph copies and run files never enter this repository. Only the totals above are published. The diff was checked for any trace of them before each commit.

Files:

  • run files for the synthetic runs in benchmarks/proof-recall/runs/;
  • four README sections;
  • three measurement Findings in .flatbread-proof/.

Please don't delete this checklist! Before submitting the PR, please make sure you do the following:

  • I added doc comments to any new public exports, and inline comments to any hard-to-understand areas (none added)
  • My changes generate no new console errors locally
  • If applicable, try to include a test that fails without this PR but passes with it (results only, no code)

Does this introduce any non-backwards compatible changes?

  • Yes
  • No

Does this include any user config changes?

  • Yes
    • If so, I have updated the relevant areas of documentation
  • No

🤖 Generated with Claude Code

https://claude.ai/code/session_01DVVnhYL1Bz7mCfEKDoyLMW

Two single runs of `find` against no-brief on the 10x graph, 245
comparable questions each:

- Haiku on the look-alike graph, where 30% of filler records reuse
  real subsystem names: `find` 233.7, no-brief 214.7. The gap of 19 is
  the same as on the plain graph (19 to 1, p < 0.0001), at 0.38 of
  no-brief's read tokens.
- Sonnet on the plain graph: `find` 233.4, no-brief 226.7. The gap of
  6.8 is not significant in one run (11 to 5, p = 0.21), but `find`
  read 44% fewer tokens and made 7 tool calls instead of 18.

On the 24 questions that name no Effort, `find` won 7 to 0 in both.
A measurement Finding records the result.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01DVVnhYL1Bz7mCfEKDoyLMW
Haiku on the 10x graph, twice, on the 97 count, status-history,
blocker and dead-evidence questions:

- `find` plus `state`: 181 of 194 question-runs; `find` alone: 171.
  Only the first was right 15 times, only the second 5 (p = 0.041).
- It read 18% fewer tokens and made 9 tool calls instead of 12.
- On the holdout half, which `state` was not shaped on, it led 83 to
  79 of 88 (5 to 1), the same direction but too small to show alone.

The plan's mark for keeping `state` (4 more per run, no rise in tokens)
is met. The README replaces the note that asked whether to pay for the
run, and a measurement Finding records the result.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01DVVnhYL1Bz7mCfEKDoyLMW
@tonyketcham tonyketcham changed the title docs(bench): record look-alike filler and Sonnet runs of proof find docs(bench): record Run C, Sonnet and Run D Oct 19, 2026
Two real graphs from private projects, 200 and 134 records, tested
whether the gains hold on memory nobody tuned against. Their questions,
answers and run files stay outside this repository; only totals are
published here.

On Haiku, two runs per graph, pooled:

- `find` beat no-brief on both graphs, 13 to 3 over both (sign test
  p = 0.021), at about half the read tokens.
- `find` plus `state` matched `find` alone (1 to 2 and 3 to 4) at the
  same tokens. The `state` gain on the 10x graph does not show on
  graphs this small.

A measurement Finding records the result.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01DVVnhYL1Bz7mCfEKDoyLMW
@tonyketcham tonyketcham changed the title docs(bench): record Run C, Sonnet and Run D docs(bench): record Run C, Sonnet, Run D and a held-out check on real graphs Oct 19, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants