WASTE Files

Nothing in the engine changed: a binary built from this tag decodes exactly as 0.6.4 did, and no container format moved. What changed is on either side of it — converting K3 on the disk you actually have, and how long a reply the server gives a client that never asked for a length.

Added

• tools/convert.py --reclaim {off,dry,on} — deletes each source shard once its last consumer has published, so peak staging is the container plus the shards still owed rather than the container plus all of them. On K3 that is the difference between 1.42 TB of staging beside a 982 GiB container — two disks — and one. It is safe because every tensor has exactly one consumer, so a shard whose last consumer has finished is never opened again. --reclaim also runs the trunk pass first: it consumes every non-expert tensor, and while it ran last almost no shard was ever spent. The reordering is neutral — off, dry and on produce byte-identical containers.

Off by default, and not reversible. A reclaimed shard has to be downloaded again, and verify_container.py loses the comparison against source for good — which is why pipeline.sh now converts one probe layer and round-trips that while the checkpoint is still whole, before converting the rest. Stages renumber to six; stage 4 passes --skip-trunk because stage 2 built it, a K3 trunk being hours to do twice.

It refuses before deleting rather than during: --experts, a container inside the checkpoint or the reverse, a shard that is neither on disk nor already reclaimed, and a bank that is not a whole bank — bank_is_sound walks the records by their own block counts for 48 bytes each, which catches a bank truncated by a kill, a full disk, or a torn rename. Releases are recorded in <src>/.reclaimed, fsynced ahead of the unlink, because a name recorded but not deleted costs nothing while the reverse is indistinguishable from an unfinished download. K3.md has the refusals and the ledger discipline.

Proven on a copy of a real Kimi-Linear checkpoint rather than on stubs: --layers 1,2 --reclaim on deleted exactly the one shard the dry pass named (4.7 GiB, 92 -> 87 GB), left the other 19 unchanged, and wrote a container that reads back 256 records with 0 problems. The second run over the now-incomplete source refuses — pointing at --skip-trunk — and deletes nothing while refusing.

Changed

• The server's default --max-tokens is 4096, was 512. Clients mostly do not send the field; Open-WebUI does not unless you set it in the model's advanced parameters, so the server default was every reply's length, and a reply that ends at the cap is indistinguishable from a model that stopped on its own. --ctx never lifted it and could not: the limit is clamped to the room left after the prompt, so raising the context only ever lowers the cap. This is a behaviour change, not a fix — a deployment that relied on 512 to bound per-request cost should now pass --max-tokens explicitly. Engine.generate's own default is untouched: the server always passes the value, so the two never meet.

• SERVE.md documents Open-WebUI — the base URL, why no compatibility mode is needed, --host 0.0.0.0 for a client in a container, the background title and tag requests that queue behind the reply on the lock every generation takes, and reasoning_content, which a client that does not know the field renders as a server that has stopped.

Fixed

• A resumed --reclaim run believed the download ledger over the disk. ST.have() reads fetch_weights.sh's .download-state, so a shard that the run had itself consumed still read as present and both refusals were skipped. Absence is now asked of the filesystem, and have() only asked whether a shard that is there finished downloading. The pipeline test found it; the file-backed test stub could not have, and now mirrors mxfp4.ST, trap included.