"Free disk" on the colibri GLM-5.2 model returned 200 OK three times and freed
4 KB. The 400 GB was in /AI/offloads/colibri/models--mastouri--…, and the HF cache
held that model as a SYMLINK into it — so _do_delete_model deleted the link's
entry, found nothing else it knew about, and truthfully reported success.

Two separate failures, fixed separately.

IT DID NOT SAY HOW MUCH. Freeing 4 KB and freeing 400 GB were the same
{"success": true}. Every branch now measures what it removed and returns
freed_bytes/freed_human; the UI prints it, and says so plainly when the answer is
zero ("Nothing was on disk for this model — freed 0 B. Its files may live
somewhere coderai has not been told about."). This is the part that would have
made the problem visible on the first click instead of the third.

IT ONLY LOOKED IN TWO PLACES. codai/models/weight_stores.py adds the rest:

- The configured offload directory AND its siblings, one level. Engines are
  pointed at sibling roots by convention — coderai offloads to …/offloads/nvidia
  and colibri's weights landed in …/offloads/colibri. The scan widens where we
  LOOK; it never widens what we delete, which stays an exact models--<repo> name
  match. Nothing is ever removed by prefix or pattern.
- register_weight_root() for an engine that does not follow that convention.
  Deliberately not called from colibri_worker/ds4_worker: at import time
  config_manager is not loaded yet, so the offload directory is '' and the
  registration would be dead code. The sibling scan runs at DELETE time, off
  config, and covers both.

Measuring the size honestly took two passes:

- symlinks are not followed or counted (an HF snapshot is a tree of links into
  blobs/, so following them doubles the number);
- hardlinks are counted once by (device, inode), since a cache that links rather
  than copies would otherwise report the weights once per link.

And purging a store leaves the cache entry that pointed INTO it dangling, which
still looks like a present model to anything that only stats the name — so
dangling links to a purged store are pruned too.

Verified against the real model before touching it: a dry run found exactly one
path, 399.8 GB, and nothing else among the nine roots it searched. The delete
then freed it — /dev/nvme0n1p4 went from ~96% to 1% used, 444 GB free.

(Worth recording: I first read df on /AI and reported the space had NOT come back,
before noticing /AI/offloads is its own mount. Same wrong-filesystem mistake as
earlier in this session. The deletion had worked the whole time.)

100 tests.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0182DhR1eFNPQyGmDrpHbedY