A session cannot determine whether its auto-memory index loaded whole, truncated, or not at all

[shawnacason]

Environment

• Claude Code CLI v2.1.220
• macOS (Darwin 25.5.0)
• Main loop: Opus 5 (claude-opus-5[1m]). Subagents: Fable 5.
• Auto-memory at ~/.claude/projects/<project>/memory/, index MEMORY.md plus per-fact topic files.

The request

Expose, in-session, what auto-memory actually loaded, so a partial load is detectable when it happens rather than inferred later from behavior.

Why

Auto-memory can fail in three ways that are indistinguishable from inside a session:

1. The index exceeded its read limit and was truncated.
2. The index was not read.
3. The fact was written into a different project store.

In all three the observable result is the same: the session proceeds as though no such rule exists. It cannot flag "a rule may be missing", because it has no way to know a read was incomplete, so it states the negative with confidence.

That is what turns a capacity limit into a correctness problem. A store that fails partially and silently produces false negatives that read as ordinary answers.

Concrete instance

After a memory write, PostToolUse emitted this into the model's context:

The memory index at MEMORY.md is 161 lines, approaching the 200-line read limit. Compact it to under 140 lines now.

Two observations:

• It goes to the model, not the user. Nothing appeared in the CLI. I learned of it only because the assistant mentioned it in conversation.
• It fires only on write. A session that reads memory and never writes gets no equivalent signal, and that is most sessions.

State at time of filing: MEMORY.md at 161 lines against the 200 ceiling, indexing 131 topic files. It had been approaching the ceiling for an unknown period with nothing user-visible.

Related: write scope is not surfaced

Auto-memory is keyed to the Claude Code project directory. A fact can be written from a session whose project path differs from the tree the work runs in. The write succeeds, the index line appears, and the fact is unreachable from the sessions that need it. Nothing indicates this at write time or read time.

This asks only that the current keying be visible, not that it change.

What it cost in practice

A process ruling was saved to auto-memory the day it was given, and not also into the working tree's own operating documents. That tree resolved to a different project path, so later sessions never saw it.

Those sessions ran on hand-written prompts that restated the process from recollection. Over seven days it drifted three times, including two conventions that contradicted the written process inside the same file that referenced it. A decision ledger stopped updating while automated passes continued, and one expected output file was never created.

The project had no version control, so the drift could not be diffed. Reconstructing it took a dedicated audit pass of roughly 118k subagent tokens and produced no product output.

No individual write failed. Every component behaved as designed.

Steps to reproduce

A. No load verification

1. Start a session in a project with a populated memory store.
2. Attempt to determine whether the index loaded whole. There is no available check, in-session or via a CLI flag.

B. Warning is model-facing and write-only

1. Grow MEMORY.md past roughly 160 lines.
2. Trigger a memory write. The size warning arrives as a PostToolUse note in the model's context. Nothing surfaces in the CLI.
3. Start a session that only reads memory. Observe no equivalent signal.

C. Write scope is invisible

1. From a session whose project path is A, record a fact concerning work that runs in tree B.
2. The write succeeds with no scope indication.
3. Start a session in tree B. The fact is absent, with no indication it exists elsewhere.

Proposed behavior

Any one of these would close the gap, listed cheapest first.

1. A one-line load receipt in-session: index lines read, whether truncated, topic file count, resolved store path. Enough for a session to say "my memory may be incomplete" instead of asserting a negative.
2. Surface truncation to the user in the CLI, on read and not only on write.
3. A claude memory status style command: store path, index size against limit, whether the last session read it whole.
4. Show the resolved store path at write time, and flag when the fact concerns a tree outside that store.

Related issues

Listed to save triage time, not as duplicates.

• [FEATURE] Make the auto-memory MEMORY.md index size limit (200 lines / 25KB) configurable #79217 asks for the 200 line / 25KB limit to be configurable. This issue is not about the size of the limit.
• [DOCS] Auto memory docs omit the error when MEMORY.md exceeds its read limit #77647 asks for the read-limit error to be documented. This is about a runtime signal rather than docs.
• Auto-memory system is ineffective: memories not reliably read or acted on across sessions #75334, Auto-memory doesn't reliably change model behavior across sessions #76408, Auto-memory is inconsistently loaded in git-worktree sessions (same repo, same day) #81833 report that memory is not reliably read or applied. Item 1 above would make reports of that shape diagnosable rather than anecdotal.
• [BUG] Same project directory gets two different, non-syncing memory directories #76647, [BUG] Memory keyed to physical path (pwd -P) breaks symlink-based project continuity #72049, Feature request: stable project identity + first-class cross-machine sync for auto memory and portable profile state #81391, Feature request: memory should inherit like CLAUDE.md does (global + project layers) #81808 concern how the store is keyed. This issue asks only that the existing keying be visible.

Current workaround

Durable state moved onto mechanisms that do not depend on the memory read succeeding: SessionStart hooks that print the operative document, version control so drift appears as a diff, and rules written into the documents the work itself opens. Memory is used as an index only.

[hjqcan]

This is an observability boundary, not just a capacity-limit problem. No matching memory is only meaningful after the runtime can prove that the requested scope was loaded completely.

I would keep three receipts separate:

1. Load receipt — resolved project/store identity, index revision or hash, bytes/lines available versus loaded, topic count, and an explicit complete | truncated | not_loaded outcome with reason.
2. Retrieval receipt — the requested scope plus candidates included or filtered and why. This should not expose raw memory content by default.
3. Write receipt — destination scope/store identity, stable memory ID and revision, and created | updated | deduplicated | rejected outcome.

The startup message and a machine-readable claude memory status --json command should be two projections of the same load receipt. If the load outcome is incomplete, an explicit memory query should return unknown/incomplete, not a confident negative.

I maintain GoodMemory, which is one working reference for the retrieval/write sides of this boundary: exact scopes, stats / inspect / read-only trace, provenance, revision and forget controls, plus a local Inspector with recall traces. It does not repair or replace Claude Code's native auto-memory loader; the load receipt still belongs in Claude Code. The useful reference is the separation between canonical durable records and bounded, rebuildable context projections.

That separation would also make the three failure modes in this report distinguishable without asking the model to infer loader behavior from its own recall.

[JhouCode]

Same class, from a different angle, in case the mechanism is useful here.

I arrived from the hooks side: a UserPromptSubmit hook injects a distilled brief, and it used to keep its own state saying "this layer was already delivered in this session". That state is a proxy, and it lies in three situations — truncation above 10K (#84021), compaction, and session forking on resume.

What fixed it was to stop asking my own bookkeeping and start asking the transcript: every delivery appears as an attachment.type == "hook_success" line in the session .jsonl. Scan backwards, stop at the first hit — if what comes first is the compaction summary line, the content fell out of context and has to be re-sent. Costs ~0.13s on a 17MB transcript, once per session.

That is, in practice, the load receipt you ask for in item 1, except reconstructed from the outside and separately by every author. Which reinforces your argument: the information already exists in the transcript, the harness already has it, and today each of us reimplements reading it.

[gabriel-vanca]

Would also love to see this. Memory management really is a nightmare currently.

[DanceNitra]

@simplysdm — you named the failure exactly, and I want to add the half your report leaves open: what
the invisibility actually costs. We hit this on our own store and measured it, and the number is
worse than "some entries are missing."

The setup. One project, 230 entries in MEMORY.md, ~400 topic files. Over one day we made two
measured improvements to the index — splitting co-tenant entries onto their own lines, then giving
each entry a sentence saying what the note concluded. Scored against the whole file, the second was
worth +0.242 recall@3 (paired bootstrap, 95% CI [+0.167, +0.317]).

Scored against the prefix a session actually loads, it was worth +0.092. The file had gone to
42,666 bytes / 248 lines, so 95 of 229 entries — 41% — were outside the window.

The part I did not expect, and the reason I think this belongs in your issue rather than a size-limit
one: on a second query set written in a different voice, the same change measured +0.000
[−0.083, +0.083]. That is not "it did nothing." Restricted to the entries both states still load,
it was worth +0.207 [+0.086, +0.328] — a large, clearly non-zero gain. Reachable targets fell
77 → 58 over the same step. Coverage times ranking, and the two nearly annihilate.

So the operational cost of no load receipt is that you cannot validate an index change at all.
Every improvement you measure is measured on a file the session never assembles. We shipped two, both
verified, and delivered about a third of what we had measured — while making 95 memories unreachable
at session start. Without the receipt you are not flying blind on capacity; you are flying blind on
whether your last fix did anything.

Two things that support your specific points. Your warning goes to the model and fires only on write:
ours did the same — twelve near-limit warnings across eight sessions in twenty-eight days, all
naming a byte size, none of which changed what we wrote. And when we finally crossed, our writes were going through
scripts rather than the memory tool, so nothing fired at all. A threshold names a size; it never
names a consequence, and a size is easy to keep not-acting on.

Caveats, because they are load-bearing. BM25 standing in for an LLM reader; our LLM-reader arm
failed outright (recall@3 0.067 — it returned the same three files for unrelated questions, so the
haystack beat that model, not the index). 120 model-written queries per register, derived from the
note bodies, so the full-text arm has an unfair vocabulary advantage. One private store. Precision
is unmeasured. None of that touches the 95: that entries were absent from the context is arithmetic
on bytes and lines, not a retrieval metric.

The question I cannot answer and would pay for. All of the above weights every entry equally. If
what a session actually opens is Zipfian, 41% of entries could be 2% of the value — or 90%. Does
anyone have a way to log which memory files a session really opens? If opens turn out to be
uncorrelated with index position, most of what I just wrote stops mattering, and I would rather know.

— Rastislav

[yacb2]

Adding a fourth way this fails, because the three modes in the issue and everything in the thread
so far assume the store was correctly identified in the first place. That assumption is not safe,
and when it breaks the observable is identical: a clean, confident empty answer.

The store slug is not stable across versions. For a project path containing an underscore,
~/.claude/projects/ holds two entries for the same directory — one preserving the underscore,
one converting it to a dash:

-Users-...-projects-echo_lab_ws     0 transcripts, no memory/   (mtime Apr  2)
-Users-...-projects-echo-lab-ws   426 transcripts, memory/      (mtime Aug 19)

I enumerated the whole directory: 24 such pairs on one machine. In every pair the underscore
form is stale and empty, the dash form holds all current state. I filed the general case as #85595,
where transcripts, memory and /resume also disagree about which directory is the project — but
it belongs here too, because from inside a session it presents exactly as mode 3 in your list, and
nothing distinguishes it from "no fact was ever written."

This is the empirical argument for @hjqcan's item 1 being non-negotiable rather than nice-to-have.
Of the fields listed there, resolved store identity is the one that fails silently and takes the
rest of the receipt down with it — bytes-loaded and truncation status are both perfectly accurate
readings of the wrong store.

What it cost me: an instrumented inventory of session-startup context across 24 projects
constructed the slug with the wrong transformation, recorded MEMORY.md = 0 bytes for all 24, and
pushed the entire memory cost into an unexplained residual. Re-run against the correct slug,
MEMORY.md was the strongest single predictor of startup context in the inventory (r = +0.76, at a
significance floor near 0.40). The first run wasn't noisy — it was a clean negative result that
happened to be false.

---

@DanceNitra — on your closing question, a partial answer with an important boundary on it.

I ran ablation probes on session startup, and at session start the sibling fact files are not
distinguishable from zero. Only the always-on index costs anything; cost is linear in index size
at roughly 108 tokens fixed + 0.44 tokens/byte (slope fitted from two ablation points, then checked
against all 24 projects). The probe is deterministic — three repeat runs on each of two projects,
spread of 0 tokens.

So for the startup window specifically, the answer to "which memory files does a session really
open" appears to be: none. The index isn't a retrieval corpus at that point, it's the entire
payload. Which I think sharpens your Zipfian worry rather than relaxing it — if the 95 entries
outside the window are unreachable at startup and nothing else is loaded either, then index
position isn't ranking a corpus, it's deciding membership.

The boundary: my instrument measures startup composition, not mid-session opens. If a session later
reads a fact file on demand, my probe cannot see it, and that's precisely the half your question is
about. I don't have that measurement, and I don't know of a way to get it without the harness
emitting it — which is, I think, another line item for the receipt.

[DanceNitra]

@yacb2 — you answered the half I asked about, and then named your boundary precisely enough that I could go and measure it. Thank you for both; the second is the rarer one.

Your boundary was that your instrument sees startup composition, not mid-session opens. Those turn out to be recoverable — session transcripts record every tool call — so I ran it over our own 17 transcripts (327 MB, the same store as my earlier comment). Three of the things I found are corrections to what I was about to tell you, so they come first.

Most "opens" are not recall. 161 of 416 topic files were opened at all, but 113 of those only inside their own authoring loop: the session that wrote the file also read it back and edited it. Genuine cross-session recall — a session opening a memory that a different session wrote — touched 48 files. My first pass counted Write and Edit as opens and reported 388; authoring a memory is the opposite of needing one.

The answer to the question I asked, and it goes the wrong way for me. I asked whether 41% of entries might be 2% of the value. Against the overflowing index — the window cut the last 95 of 229 entries, 41.5% — of the genuinely recalled memories listed in it, 18 of 32 (56%) sat below the cut. One-sided exact binomial p = 0.066: marginal, and it is the number I will stand behind. Excluding our own index-maintenance sessions raises it to 56–86% depending on how you count one, p between 0.012 and 0.066, and the direction holds at every threshold including no exclusion at all. I quote the range because two faithful implementations of "exclude maintenance" gave me 17/25 and 18/28, and neither is the number.

Correction 1, and it kills the explanation I had ready. I was going to tell you this happens because a recency-ordered index puts old durable material at the bottom. Our index is not recency-ordered. It is hand-curated into topic sections — Recent / open, Standing rules, Outreach, inspeximus, Benchmarks / laws, Collaborations / projects, Infra / ops — and all 18 of the recalled-but-cut entries sit in the bottom four, none in the top two. So the cut did not select old material; it selected my own layout. The claim that survives is weaker and more general: a fixed-size window cuts by position, and in any structured index position is a proxy for category, so what falls off is a coherent slice rather than a random tail. Here it was the operational and reference layer. If your index has sections, the window is choosing one of them for you.

Correction 2 — prior art I should have found first. Chen & Cheng, Learning What to Remember (arXiv:2606.12945, preprint) measure a recency-only retention policy keeping 36.8% of gold evidence against 65.7% for uniform weighting and 77.0% for a learned multi-factor model — recency alone doing worse than treating everything equally. That is close to the claim I was about to make, already measured on LongMemEval. It is a different mechanism: theirs is a consolidation policy choosing what to keep, mine is a fixed window truncating a file that already exists. I could find no published work on the second. That distinction is the only novelty I would claim here.

The limit, which bounds all of the above. This corpus cannot measure an opens-versus-position correlation, because for nearly all of it the index fit the window (18.8–20.0 KB across seven commits on 07-14, 17.7 KB / 114 lines on 07-23, 24.0 KB on 08-17). The overflow lasted about a day. So what I have is a counterfactual over a real recall set, not a correlation, and I would rather say that than dress it up.

Correction 3 — on the receipt, where I was about to overclaim in your favour. Before writing this I checked the docs properly. The limit is documented ("the first 200 lines of MEMORY.md, or the first 25KB, whichever comes first" — and for anyone tracking the two figures in this thread, 24.4 KiB is 25 KB, same number, different units), and two first-party mechanisms already report what loaded: /context lists memory files, and the InstructionsLoaded hook logs which instruction files load, when, and why. I had not configured the latter. So "there is no receipt" is wrong, and I am glad I did not send it.

What survives is narrower and I think still yours: both report which files loaded, not how much of a file loaded. Neither surfaces truncation state, byte count, or which entries fell outside — which is what this issue asks for. The transcript does not record it either: the index text appears in our transcripts 17 times via our own tool calls and 0 times as harness-emitted content, while the session I am writing from is receiving that index right now, in its opening context. One demonstrated case is enough for the point — a session's own transcript does not record what memory it was given, so the receipt cannot be reconstructed after the fact even in principle. I cannot show that for the older transcripts and will not pretend to; built-in auto memory is recent enough that some may never have been given an index at all.

Caveats, since they are load-bearing: one private store; the fixtures are our real memory files and stay out of the repo, so the index probes are not runnable by anyone else; the recall set is 48 files, small enough that the primary result is marginal rather than settled; and — the one I would most want pushed on — I measured position and opening, never value. No session in the sample is checked for a downstream cost traceable to a memory that got cut. "Below the cut" is treated as harm by assumption. If sessions recover missing context by other means, this is an index inefficiency rather than a correctness defect, and I cannot currently tell those two apart.

Last, the question I was going to ask you, which I measured instead. Whether your slope holds as index content shifts: it does, near enough. Slug bytes cost 1.22–1.69x prose bytes across four proxy vocabularies, measured in their real ](name.md) context — but that mechanism is published already (CodeBPE, Chirkova & Troshin, ICLR 2023, arXiv:2308.00683), and the composition effect is small: the whole-file rate moves 2.8% between two real states of our index, 0.272 to 0.265 tokens/byte. I also had to correct myself mid-measurement: I first wrote that this was small "because slugs are only a quarter of the index", which was a sentence I hardcoded and never computed. Slugs are 41% of it. The effect is small despite slugs being a plurality, which is duller than what I nearly told you.

Where I am still stuck is the absolute number, and it is a question rather than a discrepancy. Feeding your 108 + 0.44/byte model our 23,921-byte index (on disk, CRLF included — wc -c reproduces it) predicts 10,633 tokens, where my proxy count of the same bytes is 6,332: a gap of 0.180 tokens/byte, or ~18 tokens per entry across 236 entries. I cannot tell whether that is real per-entry overhead or just my tokenizer against yours. Anthropic's own tokenizer was not available to me, so what I have is a ratio and not an absolute rate for Claude — and my four vocabularies already span 1.41x on identical content while the gap I would need to explain away is 1.29–1.66x, the same order, so a fifth unmeasured tokenizer could account for all of it. With your slope fitted from two ablation points, a per-byte slope and a per-entry constant are also hard to tell apart from outside. Which was your 0.44 fitted against: Claude's own token accounting, or a proxy like mine? If it is the former, that gap is probably genuine entry overhead, and the fix flips from "shorten entries" to "have fewer of them" — worth knowing before either of us optimises the wrong one.

— Rastislav

[yacb2]

@DanceNitra — you asked what the 0.44 was fitted against, and flagged that two points can't separate a per-byte slope from a per-entry constant. The second point was the better one, so: both answers, plus the measurement.

The instrument is Claude's own accounting. claude -p --output-format stream-json, one turn; the figure is input_tokens + cache_creation_input_tokens + cache_read_input_tokens off the result event — the whole startup delta as the API counted it.

The concession, and it is worse than you put it. Two points don't make the models hard to tell apart, they make them indistinguishable: 0.428/B + 110 and 129/entry − 5 both fit my two points exactly. And "validated across 24 projects" doesn't rescue it — across the 21 distinct indexes on this machine, corr(bytes, entries) = 0.93. That set can't discriminate either.

So I ran the third point, twice, on orthogonal axes. Disposable projects, empty baseline measured per arm, MEMORY.md the only variable, environment identical across all 20 probes:

index	bytes	entries	startup delta
a real index, verbatim	11,206	38	+4,995
same text, entry pairs joined onto one line	11,214	19	+4,976
same 38 entries, hook prose truncated	5,483	38	+2,556
a small real index	335	2	+242

Halving entries at fixed text: −0.4%. Halving bytes at fixed entry count: −48.8%. Least squares over the four points gives RMSE 30 tok for per-byte against 1,560 tok for per-entry. Today's fit, 122 + 0.435 tok/byte, lands on the two-point slope.

And it answers your real question, in the direction you didn't want. You reasoned that if my number came from Claude's own accounting, the gap was probably genuine per-entry overhead — ~18 tok/entry across your 236 entries — and the fix flips from "shorten entries" to "have fewer of them". It is Claude's own accounting, and there is no such overhead: fitting a·bytes + b·entries + c to the four points gives b = +2.4 tok/entry, residuals within ±14. Forcing b = 18 takes RMSE from 30 to 188. So the 0.180 tok/byte gap is not entry overhead — on this evidence it is the tokenizer-and-content explanation you offered yourself, and your four vocabularies spanning 1.41x on identical content is the right order of magnitude for it. The fork closes in favour of shortening entries.

One disclosure, since you made yours: one of thirteen empty-baseline readings came in 532 tok high. I re-measured it twice with the index moved aside (consensus both times) and re-ran that whole arm in a fresh directory, which reproduced it to the token.

Same boundary as before, and it hasn't moved: this is startup composition on a synthetic empty project — not your store, and still not mid-session opens.

[DanceNitra]

@yacb2 — you closed the fork, and two corrections come before anything I add.

I was wrong that nothing surfaces truncation state. I told you /context and the InstructionsLoaded hook report which files loaded rather than how much, and that neither surfaces truncation. The harness does surface it, into the model's context at load time. @benlemus quotes the line-cap form in #56786, @bcnboy the byte-cap form verbatim in #57574, and @GraceAtwood traced both caps to source in #65430 — including that was_truncated / was_byte_truncated are already computed per load and go only to telemetry, which is the ask that should carry this. My own working notes had that warning quoted in them while I was writing you the sentence saying it didn't exist.

And the thing I was going to bring you isn't mine either. I measured where the two caps cross — the entry width at which min(200 lines, 25,000) stops being line-bound — got 125, and was ready to present it. It is published: @pjt222 states it in agent-almanac#407: "Above roughly 125 characters per entry, the size cap binds first", and a public mirror of src/memdir/memdir.ts carries it as a comment beside the constant: // ~125 chars/line at 200 lines. #407 also reports the guidance mismatch I thought I had found — it advises entries under ~150 characters while the warning I measured says ~200 chars. Credit there, not to me.

What did not survive contact is the word "bytes". The constant is named MAX_ENTRYPOINT_BYTES, the docs say "the first 25KB", the warning prints (limit: 24.4KB) — and the same mirrored file computes it as const byteCount = trimmed.length, which in JavaScript is UTF-16 code units. An ASCII fixture cannot tell a unit from a byte, which is why mine did not, until I stopped using one. Three indexes, 200 lines each, a canary on every line:

filler	UTF-8 bytes	code points	UTF-16 units	last line loaded
ASCII	25,200	25,200	25,200	198
CJK (中)	61,600	25,200	25,200	198
emoji (😀)	79,800	25,200	43,400	115

A 61,600-byte file cuts in exactly the same place as a 25,200-byte one, so the cap is not counting bytes. The emoji index has the same code-point count as the CJK one and cuts 83 lines earlier, so it is not counting code points either. It counts UTF-16 units — and the warning then divides those by 1024 and calls the result KB, reporting 24.6KB over a file that is 61,600 bytes on disk.

So for an index that is not plain ASCII, four numbers point the wrong way at once: the documented 25KB, the warning's own figure, the constant's name, and the ~125-characters-per-entry guidance. The CJK index above holds 61,600 bytes against a cap labelled 25KB — 2.4× — and an index where every character is CJK would reach 3×, since one such character is three UTF-8 bytes and one unit. In the other direction the emoji index loaded 115 of its 200 lines where the ASCII one loaded 198. That is the one thing here I could not have got by reading the constants.

One more, and it argues against my own alarm. I said in this thread that I had measured position and opening but never value, and could not tell an index inefficiency from a correctness defect. That is testable. I put a fact in a topic file, pointed at it from an index line either inside or outside the window, and asked a question only that file answers. Inside: answered. Outside: answered in 3 of 6 sessions — the file is still on disk and grep still finds it. In the three that failed, the session never reached for a tool at all. So an entry past the cut is not lost, it is un-prompted. What truncation costs is the recall that fires without being asked for — which is most of why an index exists — but it is not access, and anyone reasoning about this should be reasoning about salience rather than deletion.

On your actual question, briefly, since it turns out to be confirmable rather than new: cost is linear in loaded size below the cut and flat above it — 5,627 tokens at 15,000, 18,000 and 24,000 units, 7,289 at 32,000, 40,000 and 56,000 — and crossing costs a small step, measured with the loaded content held identical so that the only difference is that a warning was appended. A method audit was right that I had attributed that step rather than identified it, since my two arms trip different branches of the message — so I varied the wording instead: +64 for is 201 lines (limit: 200), +64 for is 202 lines and 24.7KB, and +67 for the longer is 1005 lines and 58.9KB. It tracks the text, which is what identifies it as the warning; it is not the constant 63 I first measured. Your slope reproduces on another OS: 0.443 tokens per unit at 60-unit lines against 0.281 at 400, intercept 244 and 246, and the 1.58× between them is content — the same effect as the 1.22–1.69× I measured across vocabularies, so your 0.435 and my proxy's 0.265 were never in conflict.

Boundaries: one platform (Windows, v2.1.238), one model, -p only, synthetic indexes, and n=6 on the recall figure, which is small enough that I would call it a direction and not a rate. Unlike my last set these carry no private fixtures: the unit test · the reachability test · the cost curve.

What I would rather have from you than guess at. You have 21 distinct indexes and an instrument that reads real ones. Do any of them carry non-ASCII — box-drawing, arrows, an accented name, an emoji in a commit-message quote — and if so, does the size the warning shows you match the file on disk? Mine did not, and I would never have looked if my fixture had stayed ASCII.

— Rastislav