Restoring the Models on a Clean Mac

By this point I had separate model configurations for the two Macs, measured context limits, and several runtime builds to keep track of. The previous post also covered the access settings I wanted to manage separately. I needed a way to preserve that setup without reconstructing it from terminal history.

This matters for the agent experiments that started the series. If I change a model or its settings and get different results, I want to be able to return to the earlier configuration. I also want to be able to reset a Mac without losing the work needed to make those models run.

I put together an offline recovery library on an external SSD, including the model files, pinned source, Python wheels, native runtimes, and Apple toolchain material. Then I reset the M5 and restored from it. I handled the administrator and license prompts myself. The installer finished with:

RESTORED ALL EIGHT PROFILES. No persistent servers started.

I then started each model, checked its status, requested a generation, and stopped it before moving to the next one. All eight passed. That was the first full test of this M5 library on a factory-reset machine.

What the clean restore tested

Before the reset, the qualification records said that offline component restores had passed over independently provisioned files. They explicitly did not claim a factory-reset restore.

The reset removed that uncertainty about the existing installation. It was still a narrower inference test than the earlier qualification: I ran generation smoke tests for all eight models, without repeating the long-input or separate image tests. The evidence summary records which checks ran before and after the reset.

The restore also exercised a dependency that would have been easy to miss on a working Mac. Xcode setup initially couldn’t find the Metal compiler. The installer then imported the archived Metal Toolchain 17F109, checked the compiler, and continued. Keeping the model files and source alone would have left that part of the setup unfinished.

One repository, machine-specific kits

The storage layout settled into this shape:

LLM/
  .git/
  restore-all.sh
  machines/
    m3-ultra-256gb/
      DwarfStar/
      Orca/
    m5-max-128gb/
      DwarfStar/
      Orca/
      optional-models/
    m5-ultra-256gb/       # Reserved; not qualified.

Git lives at LLM/, above the machine directories. It tracks the small material that explains the installation: scripts, configuration, manifests, and reviewed records. The large payloads remain outside Git history.

The model files need their own backup and checksums: recovering the Git repository alone wouldn’t recover those ignored files. Keeping them outside Git lets me review changes to the scripts and configuration without putting hundreds of gigabytes of weights into each kit’s history.

The installed locations under ~/Downloads stayed separate from the SSD layout. The managers run from internal storage, including the streaming model’s installed files. After a successful restore, the recovery SSD can be ejected without taking the service away.

Each kit retained its own required assets. I avoided cross-kit links that would make one machine’s recovery depend on another machine’s directory. The M5 work also preserved the M3 engine pins and existing manager interface. A cosmetic cleanup was not a sufficient reason to disturb a working installation.

Eight accepted models

The M3 had nine profiles. The M5 finished with eight.

An Orca DeepSeek conversion was still incomplete. Cancelling it meant stopping its supervisor as well as the conversion process, after checking their identities. Otherwise the supervisor could start a later step after the visible process disappeared.

I retained the verified original MXFP4 shards as optional future-work assets. The incomplete output and redundant internal download copies were removed only after the SSD originals had been verified.

I also removed that profile from the installer, manifests, manager help, and model tables, and renamed the M5 Orca kit to reflect its four working models. The retained shards are explicitly optional. Restoring the eight accepted models doesn’t depend on finishing that conversion.

Copying the library

After the M5 restore test, I copied its library to the other SSD and used an M2 Mac to inspect both drives. The M2 was a verification host, not a newly qualified inference target.

Both copies had the same Git revision and contained 4,082 filesystem entries and 3,593 regular files. Names, sizes, permissions, and symlink targets matched. The copied Git database passed its integrity check.

I initially started a full content hash. That reads every byte on both drives: about 4.9 TB for these two logical copies. The first implementation was CPU-bound. Switching the large-file hashing to the built-in OpenSSL implementation raised observed disk reads to about 1.5 GB/s per drive.

I then chose the shorter verification scope. It hashed 3,400 small files on each drive, checked all 617 tracked files against Git, and checked the available small-file manifest entries. Those checks passed. The 193 large files on each drive were not all fully rehashed in that comparison.

The quick comparison therefore verified the copied structure, Git state, and small-file contents. It left the large model contents unverified in that copy. Their earlier checksums don’t prove that every byte survived the later copy unchanged.

The copy-check summary records the exact scope. Model weights may be downloadable again from their upstream repositories, but that depends on continued availability and access. It is still worth keeping the archives that already restored successfully.

What I kept separate from restore

The restore does not add firewall exceptions, change the router, configure Tailscale, or leave persistent servers running. Those operations change how the machine is exposed and when it consumes resources. They belong to explicit operating steps.

Likewise, synchronization after independent work needs more care than copying a folder over another folder. The two Git histories must be preserved and reconciled, while payload differences are inspected and verified separately. Replacing .git is not a merge strategy.

The command reference contains the restore and lifecycle commands for each accepted machine. It also calls out the older M3 single-model manager’s different argument syntax.

That finishes the installation work I needed before returning to the agent experiments. I can restore the accepted configurations and check that they generate, and I have records of the longer inputs they handled. I still need to test them on the work described back in February: reading specifications, proposing useful tests, and helping triage the failures. Those results will determine which of these models I keep using.

Retrospective entry for October 23. Assembled October 24; the SSD-copy verification above took place on October 24.

Reference: Local inference operations