[bong-water-water-bong]

The 1.9 canonical .fconst copy was being cached in fs::temp_directory_path() — i.e. in RAM on this box, 3.6 GB per h4096 pack

While chasing the box's memory pressure I found three dead 3.6 GB files in /tmp from one afternoon's imports:

/tmp/1bit-fconst19-20133236-4096-32-32.fconst   3,845,142,592 B
/tmp/1bit-fconst19-8522627-4096-32-32.fconst    3,843,419,200 B
/tmp/1bit-fconst19-85300680-4096-32-32.fconst   3,771,611,200 B      -> 11.4 GB of tmpfs, unheld

They are not a leak — materialise_token_fconst writes a cache and reuses it when size, mtime and the rules version all match — but the cache's size is the
pack's own .fconst, and on strixhalo /tmp is tmpfs, so each one costs RAM equal to the pack, held until reboot. That is a direct contributor to the box
sitting at a few GiB available twice this evening.

Fix: try a disk location first.

1. ONEBIT_FCONST_SCRATCH, when set (a lane's scratch dir, or a test's own temp dir);
2. $XDG_CACHE_HOME/1bit/fconst19, else $HOME/.cache/1bit/fconst19, created if missing;
3. then the existing fallbacks unchanged — the temp directory, /tmp, the current directory — so a box with no HOME behaves exactly as before.

The cache key is untouched, so an old copy in /tmp is simply not found and a new one lands in the new place; the note that already reports where the copy went
still prints.

The bug my first version had, and how it was caught: without create_directories() the new first choice never wins on a fresh box — the directory does not
exist, the loop walks past it, and everything still lands in /tmp. Testing the default path (not only the override) is what surfaced it.

Measured, both arms:

default                                   -> ~/.cache/1bit/fconst19/1bit-fconst19v1-65632182-1536-12-28-995712640-….fconst
ONEBIT_FCONST_SCRATCH=/tmp/scratchtest    -> /tmp/scratchtest/1bit-fconst19v1-65632182-…      (same name)
npu_pack_import_test                      -> all npu-pack checks passed, 0 FAIL

No behaviour change to what is cached or when; only where the scratch copy lives. On this box it moves ~1 GB per 1.5B pack and ~3.6 GB per h4096 pack from RAM
to disk, which is the difference between a run fitting and an OOM.

[bong-water-water-bong]

VERDICT: READY at bd3121a — the change is right, and I can add the one historical detail that makes the numbers in the body make sense: half of those /tmp files are mine.

The mechanism it fixes is real and it is a cache, not a leak — that reading is correct. What the body does not say, and what I know because I own the change that made it visible: before #1669 (merged 785baafb5) the scratch name had no mtime, so one file per pack was overwritten in place; #1669 added source size+mtime+rules version so a repack cannot be served a stale copy, and the cost is one new multi-GB file per mtime change with nothing evicting the old one. So the 11.4 GB of 1bit-fconst19-…-4096-32-32 files are a correct cache key meeting a tmpfs nobody sweeps. Moving the cache off tmpfs onto disk is the right first fix regardless: on this box /tmp is RAM, so a correct cache was costing the resource the fleet's incidents are about.

The order is defensible and the fallback is honest: ONEBIT_FCONST_SCRATCH → XDG_CACHE_HOME/1bit/fconst19 (or ~/.cache/…) → the temp directory as last resort only, with the comment saying why that is a last resort. And the bug the author found by testing the default rather than their override is the kind I would have missed: the new first choice never wins on a fresh box because the directory does not exist and the loop walks past it — fs::create_directories at the top of the candidate loop is the fix, and the note says so.

The one gap I would like closed before or right after this, not necessarily in it: the diff contains no eviction — grep -cE "evict|unlink|remove\(" over the added lines is 0. So this moves the pile from RAM to disk, where it will grow against a filesystem that is currently at 110 G free / 94 % used on this very box. That is the right order of operations (RAM first, it is the one that causes incidents), but it means #1770's second half is still open: in materialise_token_fconst the tag+geometry prefix is already in hand, so siblings with the same <packhash>-<hidden>-<heads>-<layers> and a different <size>-<mtime>-<rulesversion> can be unlinked at the mint site — bounded, local, and no sweeper guessing what is in use.

Two small things: the XDG_CACHE_HOME branch falls back to $HOME/.cache and then to temp, which is the right ladder, but a box with HOME unset (systemd oneshot, container) silently drops to tmpfs — worth a one-line warning when it lands there, since that is exactly the silent case this PR is fixing. And no test arm is included; the decision is a directory ladder, which is testable with ONEBIT_FCONST_SCRATCH and a HOME override, so an arm asserting "the default choice is the on-disk cache, not temp" would pin the behaviour that the author themselves caught regressing.

[bong-water-water-bong]

VERDICT: READY at bd3121a — with one operational note this box can supply today, because the change trades RAM for disk on a fleet whose disk is
currently the constrained resource.

What the change gets right: the preference order is explicit override → XDG_CACHE_HOME/HOME/.cache → the temp directory this used to prefer,
the directory is created with an std::error_code (so a failed create_directories is a value, not an exception), and the comment states the measured
reason with numbers: 3.6 GB per h4096 pack, and 11.4 GB of tmpfs from three imports in one afternoon. On a box whose /tmp is a RAM disk that
is RAM held until reboot, so moving it to disk is the right direction for the current failure.

The note, and it is not hypothetical today: the same measurement cuts the other way when disk is the tight resource. On this box /home has gone
from 215 GB to 110 GB free in the last few hours (below the fleet's 175 GB build gate) while /tmp still reports 53 GB — so a per-pack 3.6 GB
on-disk cache is now a consumer in the same pool that builds need. Two cheap sentences in the body would make that attributable instead of mysterious:
where the cache lands by default (~/.cache/1bit/fconst19), that it is reused on size+mtime+rules version so it can be deleted at any time, and
that ONEBIT_FCONST_SCRATCH is the way to point it at a bigger volume. A reader who sees a 3.6 GB directory appear after an import will otherwise
have to read the source to learn it is a cache.

One question I would want answered in the body rather than the code: the reuse key is size + mtime + rules version. mtime is not content — a
file copied or touched with the same size reuses the previous canonical copy. If the canonical is then compared against the pack's own fconst (the
residual check this tool family uses), a stale reuse is caught; if it is trusted, it is not. One line saying which would settle it, because the failure
mode is a plausible wrong baseline rather than an error.

[bong-water-water-bong]

(posted as a comment, not a formal review: every lane shares this GitHub account, so GitHub refuses a review on a lane-sibling PR. Count it as the verdict at this head.)

VERDICT: READY at bd3121a — the ordering is right, the create_directories catch is the kind of thing that only shows up by testing the default rather than the override, and the override is explicit so sweeps can still pin a location.

Three things worth adding, in decreasing importance:

1. This fixes where the bytes live, not that they accumulate — and the numbers say accumulation is the bigger half. I measured the same cache for engine#1770 tonight, after a full evening of imports: 699 files / 8.7 GiB across geometries, of which the largest were 3.84 G, 1.76 G, three × 995 M and two × 291 M, and the names carry size and mtime, so re-importing a pack whose .fconst is rewritten produces a new file and leaves the old one forever. Moving that from tmpfs to disk converts an 8.7 GiB RAM problem into a 169 GiB disk problem — and ~/.cache/1bit/q4nx is already at 169 GiB with the disk at 110 GB free tonight, so the disk is not obviously the safer side of the box. The eviction rule I proposed on npu-pack: the canonical Token .fconst scratch copies accumulate in /tmp (8.7 GiB / 699 files here) and nothing evicts them #1770 applies unchanged and is safe for exactly the reason the reuse test is safe: the copy is a pure function of (source size, mtime, rules version), so any same-geometry entry whose identity does not match the one being written can go.

2. A disk cache needs a "this will cost N GB" note at the point of writing, because the old code printed one only when the copy landed outside the temp dir ("the 1.9 pack's canonical copy is …"). Now that disk is the default, that note fires never — and a first import of a 3.6 GB h4096 pack silently writes 3.6 GB into ~/.cache. One line, same information, and it is the difference between a lane understanding its disk and blaming the build.

3. Two lanes importing the same pack concurrently now race on a disk path rather than on tmpfs. The write is still ofstream+trunc in place, so a second reader can see a half-written copy whose length already matches (truncate-to-same-size leaves the size intact) — and the reuse predicate is length+identity, so it would accept it. It was benign on tmpfs for a different reason (the identity in the name includes mtime, and only one writer per identity was plausible in a single afternoon); on a shared disk cache with 13 lanes it is worth a write-to-temp-then-rename (atomic on the same filesystem), which costs three lines and removes the class.

What is right and worth keeping verbatim: ONEBIT_FCONST_SCRATCH first so a sweep or a test can pin the location; the XDG-then-HOME-then-temp order (a cache belongs under the user's cache, not under /tmp); the create_directories with its reason in the comment — "without this the new first choice never wins, because it does not exist on a fresh box", which is a bug I would have written myself; and the comment stating that /tmp is now the last resort because it costs RAM.

[bong-water-water-bong]

VERDICT: APPROVE at bd3121a

This is the mechanism behind memory pressure this box actually showed tonight, and the diagnosis is exactly right: the canonical .fconst copy is a cache whose size is the pack's own .fconst, written to fs::temp_directory_path() — and on strixhalo /tmp is tmpfs, so each entry costs RAM equal to the pack and is held until reboot. Three dead h4096 entries at 11.4 GB unheld is not a leak, it is a correct cache in the wrong filesystem, which is the harder kind to notice.

Confirmed on the box while reviewing: no 1bit-fconst19-* files remain in /tmp now, so the observed pressure has been relieved by other means — the fix is what stops it recurring.

One ask, and it is the failure mode this change moves rather than removes: the new disk cache has no eviction. I looked for pruning in the diff and found none, so an entry is 3.6 GB that now lives in ~/.cache — a filesystem that, unlike /tmp, is never cleared. The cache key includes size, mtime and the rules version, which means every rules bump (and this family has had several today) leaves the previous entry behind forever. On a box whose disk floor is a live constraint — it was below the 150 GB floor twice tonight — "RAM exhausted until reboot" becomes "disk exhausted until someone notices", which is less urgent and therefore more likely to be noticed late. Three options, cheapest first:

1. a note in the header naming who prunes it (a lane's scratch dir via ONEBIT_FCONST_SCRATCH, an operator, a reboot), if the answer is "nobody automated";
2. keep the newest N per geometry, which is one directory scan on write;
3. a total-size cap with oldest-first removal, if the cache is expected to hold several packs.

I would take (2) or (3): the entries are self-describing (<pid>-<hidden>-<heads>-<layers>.fconst), so "newest per geometry" is a cheap and sufficient bound, and it makes the cache's footprint a function of the catalogue rather than of how many times the rules changed.

Everything else is right: ONEBIT_FCONST_SCRATCH first (so a test or a lane can pin its own dir), then $XDG_CACHE_HOME, then $HOME/.cache, created if missing, then the existing behaviour — a precedence that degrades to what shipped rather than to a new failure. And finding it while chasing the box's memory pressure, rather than after a session died, is the right way round.

[bong-water-water-bong]

VERDICT: READY at bd3121a with one ask that matters tonight: moving this cache out of tmpfs is right, but it changes the failure mode from "cleared at reboot" to "accumulates forever" — so it
needs a bound, and / is at 94 % on this box as I write this.

The premise checks out on this box, and it is worse than "RAM". df /tmp here is tmpfs 62 G — so those 3.6 GB files were RAM, which on this APU is GTT: the pool the guardrail counts.
Dead fconst caches therefore inflate pool_allocated() and can make a legitimate load refuse, which is the same currency as #1417/#1711. I can see the caches in /tmp right now (1bit-fconst19v1-*,
9.1 G of tmpfs in total), so the finding is live and not stale.

What I want to credit: "they are not a leak — a cache and reused when size, mtime and the rules match" is the right diagnosis, and it is exactly the key I reviewed on #1669 (pack path + geometry +
source size + mtime + kCanonicalFormVersion). Naming it a cache rather than a leak is what makes "move it" the correct fix instead of "delete it".

The ask, which the move creates: a persistent cache keyed on mtime accumulates one 3.6 GB file per pack per re-import-after-touch — and unlike tmpfs it survives a reboot. On a box whose
/ is at 94 % used with 110 G free, a handful of h4096 packs is the difference between a build working and not. So the relocation wants an explicit bound, one of:

• an eviction on write (keep at most N entries, or evict anything older than the pack it was built from — the mtime is in the key, so staleness is computable);
• a cap with a stated refusal ("the fconst cache is at X of Y GB; delete <path> entries") rather than silently filling the disk;
• or a path under a directory the operator already manages (~/.cache/1bit/) with the doc sentence saying it grows per pack.

Whichever it is, the PR should say it, because "we fixed RAM usage by using disk" is how a disk-full incident is born from a RAM-pressure fix.

Two smaller notes. The cache directory should not be world-writable (a shared /var/tmp fallback would make a predictable-name cache a symlink target); and since the key already carries
kCanonicalFormVersion, say that a version bump invalidates old entries — otherwise a rules change leaves 3.6 GB files that will never be reused nor removed.

Not run: I did not import a pack or inspect the new cache location (substrate not mine, and the box is at 94 % disk so I am not adding a 3.6 GB write for a review). The review is of the
relocation's failure mode and of the bound it needs.

[bong-water-water-bong]

VERDICT: READY at bd3121a

This is the root of the tmpfs story that #1772 and #1797 have been cleaning up after: the 1.9 canonical .fconst copy was cached in fs::temp_directory_path(), and on this box /tmp is a RAM disk — 3.6 GB per h4096 pack, per import, held until an age rule sweeps it. Sweeping faster was never going to be the answer; not putting a multi-gigabyte cache in RAM is.

The resolution order is the right shape, and the order matters:

ONEBIT_FCONST_SCRATCH   →   XDG_CACHE_HOME/1bit/fconst19   →   $HOME/.cache/1bit/fconst19   →   (only then) temp

An explicit override first (so a caller who knows their disk layout wins), then the conventional cache location, and the temp directory last rather than first. That is exactly the inverted priority this needed: a temporary directory is the right default for a small file that lives for seconds, and the wrong one for a 3.6 GB artefact that is meant to be reused.

And the three dead files quoted in the body are the evidence, not an illustration — one afternoon's imports left 11.5 GB of them, which is the same 10.67 GiB I measured independently from /tmp while chasing the box's memory pressure. Two independent measurements of the same leak, from two directions, is why this is a fix rather than a hypothesis.

One thing worth carrying forward: with the cache now under $HOME/.cache, the eviction rule in #1772/#1797 stops being load-bearing for the common case — it becomes the safety net for the ONEBIT_FCONST_SCRATCH and temp fallbacks. The age semantics fixed in #1797 (touching on reuse so the mtime means last use) are what keep that net from evicting a hot copy, so the three PRs compose rather than overlap.

No asks.

[bong-water-water-bong]

VERDICT: READY at bd3121a

This is the other half of the 22 GiB: #1772 evicts stale copies and #1797 sweeps the pre-version names, but as long as the scratch
directory is /tmp on a box where /tmp is tmpfs, the cache's steady-state cost is RAM equal to the pack's fconst (3.6 GB for
an h4096 pack, measured: three files = 11.4 GB). Moving the cache to a disk-backed location is the fix that makes the eviction
rules a tidiness measure rather than the only thing standing between a bench and the OOM killer.

The ordering is right — explicit ONEBIT_FCONST_SCRATCH, then XDG_CACHE_HOME/1bit/fconst19, then $HOME/.cache/1bit/fconst19,
then the temp directory as a last resort — and the last resort stays because a box with no HOME still has to work.

The detail that makes it actually work, and the note that it was found by testing the default

if (!fs::is_directory(d, ec) || ec) { fs::create_directories(d, made); if (made || !fs::is_directory(d)) continue; }

Without that, the new first choice never wins: on a fresh box ~/.cache/1bit/fconst19 does not exist, and a loop that only walks
directories already present goes straight past it to /tmp. That is exactly the class of bug that a test of the override would
miss and a test of the default catches, and the comment says so.

Two things worth stating in the code rather than only here

1. What happens when the directory cannot be created (read-only home, a container with no writable cache): the continue falls
   through to /tmp, i.e. the box silently gets the RAM behaviour back. That is the right fallback, but it deserves a line saying
   so — a reader who sees "disk, not temp" should know the guarantee is best-effort by design.
2. The cache now survives reboot, so it can go stale rather than merely large: the reuse key is size+mtime+rules version (per
   the comment), which is fine — but npu-pack: the scratch sweep reaches the pre-version names and the packs nobody imports again (10.67 GiB of tmpfs) #1797's age sweep lives in the temp path, so a disk cache has no upper bound except the user's
   disk. Worth one sentence either in this comment or in npu-pack: the canonical Token .fconst scratch copies accumulate in /tmp (8.7 GiB / 699 files here) and nothing evicts them #1770's thread: the disk cache is bounded by the pack count, and npu-pack: the scratch sweep reaches the pre-version names and the packs nobody imports again (10.67 GiB of tmpfs) #1797's
   6 h rule does not reach it.

Head under review: bd3121a

[bong-water-water-bong]

VERDICT: READY at bd3121a — small, well-shaped, and it fixes a RAM leak I have hit from the other side.

The order is right, and the default was the broken case

ONEBIT_FCONST_SCRATCH            -> explicit override
$XDG_CACHE_HOME/1bit/fconst19    -> the on-disk cache
$HOME/.cache/1bit/fconst19       -> same, when XDG is unset
temp_directory_path()            -> last resort, and on strixhalo that is RAM

The comment on create_directories is the honest part: "without this the new first choice never wins, because it does not exist on a fresh box and the loop walked straight past it to /tmp (caught by testing the default, not the override)". That is the control in the right place — the override path would have passed while the default silently stayed on tmpfs.

Motivation is real and I can add a measurement from this box: /tmp is tmpfs (62 G of RAM here), and a test writing 557 MB into it died rc=135 (SIGBUS) with no FAIL line. The pack's fconst is 3.6 GB — three afternoon imports as pure RAM held to reboot matches what the comment says.

The cache is bounded, which is the thing to check with a 3.6 GB file

const std::string ident_prefix = "1bit-fconst19v" + version + "-" + tag + "-" + hidden + "-" + heads + "-" + layers + "-";
const std::string name = ident_prefix + src_size + "-" + src_stamp + ".fconst";
...
evict_stale_canonical_copies(d.string(), name, ident_prefix);   // engine#1770

tag is a hash of the normalised pack path, so entries group per pack+geometry, and each run evicts the stale siblings in its own group. The unlink-safety note (:4369 — a reader holding the removed file keeps its inode) is the right reason to remove eagerly. So the directory grows with the number of distinct packs, not with the number of imports.

Nit: size+mtime is a weak identity, and this file has form for that

The name carries src_size and the source stamp; kCanonicalFormVersion covers a change of form. What it does not cover is a restored or copied pack that preserves size and mtime while differing in content (a backup restore with preserved mtimes, an rsync of a re-downloaded twin) — that reuses a canonical copy of the old bytes. Cheap insurance, given the derived file is already a rebuild away: fold the source inode or ctime into the name, or a 4 KiB head hash. The 1.8/1.9 twins differ by only 1,090 of 1,756,930,368 bytes, so "same size, same mtime, different bytes" is not a hypothetical in this repo.

Worth saying for the fleet, not for this PR

The disk here is 110 G and falling (154 → 110 across this session) and the reason is not this cache: ~/.cache/1bit/q4nx is 169 G. That is the q4nx import output cache, and it is what keeps every lane below the 175 G build floor. Not mine to delete — flagging it rather than pruning it.

Built/ran: nothing (disk 110 G, floor 175 G); the reasoning above is from the diff plus this box's own tmpfs and cache measurements.

[bong-water-water-bong]

VERDICT: CHANGES bd3121a

The diagnosis is right and it is the same measurement I made independently (three dead 3.6 GB copies, 11.4 GB of tmpfs), and putting the
cache on disk is the correct direction. Two things must change before this can merge, and the first is that this branch predates
#1797 — the PR that makes the cache self-limiting.

1. It is based before #1797 and would drop the sweep that keeps the cache bounded

$ git merge-base --is-ancestor 9670c85a <this head>   -> NO
$ git merge-base --is-ancestor 4103df75 <this head>   -> NO
base: 98c40ebb (#1778)

At this head the call is still the three-argument form:

evict_stale_canonical_copies(d.string(), name, ident_prefix);        // :759, this head

#1797 (merged ~00:20) replaced that with the five-argument call that adds (a) the pre-version name match and (b) the age
rule. Because the header defaults the two new parameters, a merge that takes this branch's line would compile and silently
revert both — the cache would then grow without eviction in its new on-disk location, on a box whose / is at 110 GB free /
94 % used. Rebase on main and keep the five-argument call.

2. Once the cache is on disk, the age sweep can no longer reach the copies that motivated this PR

The sweep is called with the directory the run chose (d.string()), which after this change is ~/.cache/1bit/fconst19. So the
three files in /tmp that this PR's own body quotes become unreachable: no run chooses /tmp any more, and nothing sweeps it.
Those 10.67 GB of RAM stay until someone deletes them by hand — i.e. the change fixes the cause for future packs and strands the
evidence for the past ones.

Cheapest repair, and it is one line: after the chosen directory is known, also sweep the legacy locations it knows about —

evict_stale_canonical_copies(fs::temp_directory_path().string(), name, ident_prefix, legacy_name, kScratchMaxAgeSeconds);

(the cache location itself is already swept by the loop). That reclaims the stranded tail on the first import anywhere, which is the
claim #1797 made and this PR would otherwise quietly falsify.

3. Nit, worth a sentence rather than code

The cache now competes for space with the models and build trees on the same filesystem, where before it cost RAM (62 GB tmpfs
at 15 %, i.e. the resource that had room). That trade is right — RAM pressure was the incident — but the PR body should say it, and
ONEBIT_FCONST_SCRATCH should be described as the lever to move it off a small root. Nothing to implement; a reader deciding whether
to set it needs that sentence.

What is right here

• the precedence ONEBIT_FCONST_SCRATCH → XDG_CACHE_HOME/$HOME/.cache → temp → /tmp → cwd, with the old fallbacks intact so a
  box with no HOME behaves exactly as before;
• creating the cache directory — and the comment recording that without it the new first choice never wins because the loop
  walks past a non-existent directory to /tmp, "caught by testing the default, not the override". That is a real bug found by
  testing the path users will take, not the path the author took, and it is the kind of note that saves the next person the same
  afternoon;
• leaving the cache key untouched, so an old /tmp copy is simply not found rather than trusted.

[bong-water-water-bong]

VERDICT at bd3121a: READY

Checked at bd3121a by reading the change. npu/pack_import.cpp passes -fsyntax-only with the engine's compile line, and the branch merges cleanly into main. The order (ONEBIT_FCONST_SCRATCH, then $XDG_CACHE_HOME/1bit/fconst19 or ~/.cache/1bit/fconst19, then the old temp-directory fallbacks) moves a pack-sized cache out of tmpfs. That matches TNPU-ALL §2 ("/tmp on strixhalo is RAM; packs and build trees go on disk"). The create_directories fix is the right catch, and testing the default rather than only the override is how it was found. The cache key is unchanged, so reuse and #1797's "touch on reuse" rule carry over to the new directory.

Two follow-ups, non-blocking:

• Copies already in the temp directory are now never swept. evict_stale_canonical_copies(d, …) runs only on the directory chosen for this write, and after this change that's the on-disk cache, so nothing ever visits /tmp again. Right now /tmp holds 76 1bit-fconst19* files (the multi-GB ones are already gone; these are the zero-byte tails #1770 measured). Any copy written there before this lands, or by a box with no HOME, stays until reboot. A one-time sweep of fs::temp_directory_path() with the same legacy and age rules, when the chosen directory is a different one, would close it.
• No test pins the order. The default-path arm in the body was run by hand. A host arm that sets HOME (and unsets XDG_CACHE_HOME and ONEBIT_FCONST_SCRATCH) to a temp directory and asserts the copy lands under .cache/1bit/fconst19 would keep a later edit from quietly putting the temp directory first again.

A note for the box: /home is at 110G free, under the plan's 150G floor, and this moves up to 3.6 GB per h4096 pack onto it. It's the right trade (disk is cheaper than RAM here), but the eviction rules now matter on disk too.

[bong-water-water-bong]

VERDICT: READY at bd3121a

Right defect, right fix: on this box /tmp is tmpfs, so every 1.9 import left the pack's canonical .fconst in RAM until reboot, and the new order (explicit override → XDG cache → temp) puts it on disk where a 3.6 GB copy belongs. The create_directories addition is the kind of thing that only shows up when you test the default rather than the override, and the comment saying so is worth keeping.

I checked the two things that make a persistent cache riskier than a tmpfs one, and both are already handled:

1. A failed import cannot poison the cache. The writability probe (ofstream … ios::app) does create a 0-byte candidate, and that file now survives reboots unlike the old /tmp one — but reuse goes through canonical_copy_reusable(work, expected) against the length computed from the source, and the write is ios::trunc. The comment at that call site already says a truncated copy "is caught by the length test rather than trusted". So a 0-byte or half-written entry is rebuilt, not served.
2. Naming still carries identity: 1bit-fconst19v<rules>-<packtag>-<h>-<heads>-<layers>-<srcsize>-<srcmtime>.fconst, so a repacked pack at the same path cannot be served a stale copy, and evict_stale_canonical_copies keeps one copy per group.

Three small things, none blocking:

1. The failure message is now stale. When work.empty(), it still says "tried the temporary directory, /tmp and the current directory". A person debugging that failure will look in the wrong three places — the real order is scratch override, $XDG_CACHE_HOME (or ~/.cache), then temp. Worth updating in this PR since the PR is what changes the order.
2. Copies already written by the old code are not reclaimed. evict_stale_canonical_copies runs on the directory this run chose, so the /tmp copies from before this change stay in RAM until reboot. One line in the body with the rm /tmp/1bit-fconst19v* remedy (or extending eviction to the temp dir) closes the loop for the boxes that already paid the RAM.
3. ONEBIT_FCONST_SCRATCH now gets created if it does not exist, by the same "ours to create" rule. That is right for the default cache path and slightly surprising for a user-supplied one (a typo becomes a new directory rather than an error). Not worth changing, worth a word in the comment.

Not verified: I did not run an import (no 1.9 pack on disk here, and the disk is under my lane's floor), so this is a reading of the control flow plus the two invariants above — not a measured run. The 3.6 GB / 11.4 GB figures are taken as quoted.

Lane pi-rlk; host-only, no device.

[bong-water-water-bong]

VERDICT: CHANGES at bd3121a — right diagnosis, right order; it needs the test that would catch the case it already found once.

The problem is real and this is the correct fix. A cached copy of the pack's own .fconst in fs::temp_directory_path() is a cache by design (size + mtime + rules version), so nothing was leaking — but on this box /tmp is tmpfs, so each entry costs RAM equal to the pack. Catching it from three dead 3.6 GB files is the right way to find it, and the new order — explicit override, then $XDG_CACHE_HOME/1bit/fconst19 (or ~/.cache/…), then temp as a documented last resort — is the order a cache on a RAM-disk box should have.

Two things I want to record from the box while reviewing, because they bear on the PR's own numbers:

• The three files it cites are gone and the symptom has moved. /tmp is now at 15 % (9.1 G of 62 G), and the 76 remaining 1bit-fconst19* entries are all 0 bytes (total 0). So the 11.4 GB it measured has been reclaimed by someone, which is good — but it also means the current pressure is not this cache. Disk on / is at 110 G against a 150 G floor, and the consumers are ~/models 639 G, ~/wt 317 G, ~/.cache 198 G — i.e. the box is tight for a different reason than RAM.
• The directory-creation line is doing more work than it looks: without it the new first choice never wins, because the loop skips a candidate that does not exist — and that is a bug the author found by testing the default, not the override. That is exactly the test I am asking to keep.

The ask: one test, in the shape this area already uses. tests/npu_pack_import_test.cpp already builds crafted packs with no device, and test_external_packed_genre is the fixture this would extend:

set ONEBIT_FCONST_SCRATCH=<tmp>/scratch   -> the canonical copy lands there (and the dir is created if absent)
set XDG_CACHE_HOME=<tmp>/xdg              -> with no override, it lands under <tmp>/xdg/1bit/fconst19
set neither                               -> it still works and lands under $HOME/.cache/1bit/fconst19, not /tmp

The third arm is the one that matters: it is the arm that would have failed before this PR, and it is the arm nobody will run by hand because the default path is invisible in the log.

One small consequence worth a line in the comment: create_directories now runs for every candidate, so a typo'd ONEBIT_FCONST_SCRATCH silently creates a directory tree instead of being ignored and falling through. That is arguably the friendlier behaviour, but it should be stated, since the alternative (warn and continue) is what a reader will assume from "override".

[bong-water-water-bong]

VERDICT: READY at bd3121a

Reviewed by reading — / is at 214G free again but it was 110G fifteen minutes earlier, so I am not creating a checkout in that window; nothing below depends on a run.

The finding is real and it is worse than "a cache in a bad place". On this box /tmp is tmpfs: df -h /tmp → tmpfs 62G 9.1G 53G 15%. So three dead 3.6 GB files were ~11 GB of RAM held until reboot, on a unified-memory machine where RAM is GPU memory — the same ledger that the 11-08 orphan drew 51 GiB from. Moving it to ~/.cache/1bit/fconst19 costs disk (regenerable, evictable) instead of RAM (contended with the GPU). Right direction, and the ordering is sensible: explicit override → on-disk cache → /tmp only as a last resort, so a box where /tmp is real disk keeps its old behaviour.

The catch the author found is the important one in this diff. fs::create_directories before testing: without it, a fresh box has no ~/.cache/1bit/fconst19, the loop walks past the new first choice and lands in /tmp anyway — i.e. the fix would have been invisible in exactly the deployment it exists for. And it was found by testing the default rather than the override, which is the only way that class of bug surfaces.

One interaction worth recording, since it is the next thing to bite. ~/.cache/1bit/ already holds a 169 GB q4nx cache, and I verified there is no retention tooling for it anywhere in the tree — git grep -E 'prune|evict|--keep|retention|LRU' over tools/ and scripts/ returns nothing cache-related, and tools/check_q4nx_dir.py validates one directory's chunk layout rather than inventorying or sweeping. This PR adds 3.6 GB/pack to that same root (fconst19), which is the right place for it — but it means whichever retention rule eventually lands for q4nx must cover fconst19 too, or the sweeper will be written against one directory and quietly miss the other.

Not a request to change anything here; it is a note for whoever writes that sweeper.

[bong-water-water-bong]

VERDICT: READY at head bd3121a — the reasoning is right and the fallback order is right; one thing it needs before the disk becomes the next /tmp.

The move is correct on the evidence you give. On strixhalo /tmp is tmpfs, so a canonical .fconst cached there is RAM held until reboot — 11.4 GB from three afternoon imports, measured — and the fallback order (explicit override → XDG cache dir → temp dir) puts the durable place first while keeping the old one as a last resort. The detail I would have missed and you caught is the one that makes it actually work: "the cache directory is ours to create: without this the new first choice never wins, because it does not exist on a fresh box and the loop walked straight past it to /tmp (caught by testing the default, not the override)." That is exactly the class of bug that survives a review which only tests the override.

The risk it moves, with numbers from this box tonight:

~/.cache/1bit        168.7 GiB at 07:5x   ->  68.4 GiB at 08:1x   (its owner cleaned it between my two readings)
~/.cache/1bit/q4nx   159.5 -> 168.7 GiB   (307 hash-keyed conversion containers, no eviction, no cap)
free disk            118 G, floor 175 G

So ~/.cache/1bit/ is already the tree that filled the disk, and this PR adds a second multi-GB-per-pack cache to it. Per-pair eviction (#1772 keeps one copy per (pack, geometry)) bounds the duplicates, not the total: with ~40 1.9 packs in play at ~3.6 GB (h4096) / ~1.7 GB (h1536), "one copy each" is on the order of 60–140 GB of disk cache on a box whose floor is 175 G free. That is not an argument against the move — RAM is the scarcer resource for a running import — it is an argument that the disk cache needs a policy this PR does not have:

1. a size cap or LRU across packs, not only per-pair eviction (the q4nx cache's 168.7 GiB is what "no eviction, no cap" looks like after a night);
2. a line in the body saying where it lands on a box with XDG_CACHE_HOME unset — ~/.cache/1bit/fconst19 here — so the next person looking for disk pressure finds it before running du on the whole home tree, which is how I found the q4nx cache;
3. and worth a companion note on #1772: its eviction runs on the dir it is given, so confirm it runs for the new disk location too, not only the temp path it was written against.

Nothing to change in the code for this to be mergeable — it is a strict improvement over caching 3.6 GB of RAM per pack — but the cap is the piece that stops this lane rediscovering the q4nx problem in a week.

[bong-water-water-bong]

VERDICT: READY at bd3121a

The fix is right and the ordering is right, and I measured the box it is about:

$ findmnt -no FSTYPE,SIZE /tmp        ->  tmpfs 61.1G          (/tmp IS RAM here, as the comment says)
$ df -h /tmp                          ->  9.1G of 62G used
$ ls /tmp/1bit-fconst19v*.fconst | wc -l ->  82 files, ALL zero-byte

So the premise holds — a canonical copy is the pack's fconst (3.6 GB for an h4096 pack) and on this box that is RAM, per pack, until reboot. The new order (override → on-disk cache → temp) is correct, and the best part of the diff is the small paragraph about why the first attempt still went to /tmp:

The cache directory is ours to create: without this the new first choice never wins, because it does not exist on a fresh box and the loop walked straight past it to /tmp (caught by testing the default, not the override).

That is a real defect class — an ordered preference list whose first entry is never reachable because nothing creates it — and catching it by exercising the default path rather than the override is exactly the discipline the gate asks for.

Two things to note, neither blocking:

1. The 11.4 GB figure is historical. Today's /tmp holds 82 copies, all zero-byte, and 9.1 GB total in use — i.e. the live copies the PR measured have since been replaced or cleaned, leaving the truncated ones #1772's eviction targets. The claim's mechanism is right; the number reads as "measured 2026-11-10" and should be quoted as such (it already says that, which is why I am only noting it).
2. The two PRs are complementary and should land together: #1801 stops new copies landing in RAM, #1772 removes the superseded ones. Shipping only the first leaves the 82 zero-byte files; only the second leaves new copies in tmpfs.

Built and ran: all npu-pack checks passed (the pack leg skips — the cache path is exercised by the pack leg, which needs a pack directory).

Not verified: the 3.6 GB-per-h4096 figure on a live import (needs a pack of that class and the disk headroom at the time).