# MacBook Storage, Time Machine, and Local Model Audit

Date: 2026-08-31

## Verified current state

- Internal APFS capacity: 2.0 TB
- Physically unallocated space before snapshot deletion: about 18 GiB
- Physically unallocated space after snapshot deletion: about 202 GiB
- Physically unallocated space after the completed 18.49 GiB ProRes batch: about 182 GiB
- Time Machine automatic interval: 3,600 seconds (hourly)
- Local Time Machine snapshots removed: 23 verified APFS snapshot UUIDs
- Verified remaining Data-volume snapshots after cleanup: zero
- Approximate physical space reclaimed from snapshots: 184 GiB
- Time Machine was idle during this audit
- First CR3/ProRes batch: 34 of 34 files passed technical decode, but playback review rejected the grouping; do not use these masters
- Corrected grouping preview: 71 true-burst H.264 clips rendered and verified; replacement CR3 masters are pending user motion approval
- The active oMLX workload was using `Qwen3.8-27B-oQ4e-fp16-mtp`; it was not interrupted
- The validated generic burst workflow is installed at `/Users/sammacmini/.pi/agent/skills/burst-photo-processing` on the Mac mini

## Why hourly snapshots became expensive here

APFS snapshots store changed blocks rather than complete copies. This MacBook has unusually high model-cache churn, so hourly snapshots can temporarily retain blocks that oMLX or model download tools replace or delete.

Time Machine is explicitly configured with `AutoBackupInterval = 3600`. The preferred replacement architecture is:

1. Put Time Machine in manual mode so it no longer creates hourly local snapshots.
2. Attach a dedicated backup disk to the Mac mini.
3. Share that disk as a Time Machine-capable SMB destination.
4. Schedule one native `tmutil` backup attempt nightly with `launchd`.
5. If the Mac mini or share is unavailable, exit without retry loops and try again the next night.

The dedicated drive should ideally be 4 TB or larger for a 2 TB MacBook. A smaller drive can work if regenerable AI caches and downloaded model stores are excluded. Automatic Time Machine remains enabled in preferences; switch Backup Frequency to **Manually** in System Settings to prevent the hourly local-snapshot pattern from returning.

## Storage inventory

| Store | Approximate size | Assessment |
|---|---:|---|
| `/Users/Sam/.omlx/cache` | 356.6 GiB | Runtime prompt/SSD cache, not model weights |
| `.../.omlx/cache/_gdn_sidecars` | 292.1 GiB | Main reclaim opportunity once oMLX is idle |
| `/Users/Sam/.lmstudio/models` | 100.1 GiB | Actual downloaded model weights |
| `/Users/Sam/.cache` | 100.0 GiB | Mixed application/download caches |
| `/Users/Sam/.ollama/models` | 43.0 GiB | Ollama model weights |
| `/Users/Sam/MLXModels` | 30.7 GiB | Separate MLX model store |
| `/Users/Sam/Sam Storage` | 302.5 GiB | Live user data; do not treat as cache |
| `.../Sam Storage/Photography` | 164.8 GiB | Photography source data |
| `.../Sam Storage/Lightroom` | 128.0 GiB | Lightroom data |

### oMLX cache finding

oMLX currently permits a `353GB` SSD cache. Its startup scan reported about 353 GB total, including about 289 GB of GDN sidecars, while only a handful of blocks matched the current cache geometry and many older blocks were skipped as incompatible.

Decoded cache-signature evidence:

- About 72 GiB is tied to the deleted `Qwen3.6-35B-A3B-oQ6-mtp` planner at 2048-token geometry, with another smaller 35B oQ6 group at 4096-token geometry.
- About 157 GiB is tied to `Qwen3.8-27B-oQ4e-mtp` using the older 2048-token/TurboQuant signature.
- The current 27B session uses 4096-token geometry and has much smaller recently written cache groups.
- A new Jundot oQ6 model must not reuse the deleted Pulsate model's cache merely because both expose the same bare model ID; the weights differ.

Recommended controlled cleanup after the active session finishes:

- Clear the oMLX SSD/prefix cache using oMLX's supported cache control rather than deleting hashed files manually.
- Reduce `ssd_cache_max_size` from 353 GB to approximately 96 GB initially.
- Re-run the long-prefix workload and measure reuse before deciding whether 64, 96, or 128 GB is the right long-term cap.
- Do not clear the cache while the current model request is active.

## Model inventory and missing Pi Agent planner

The deleted planner was verified from the oMLX log:

- Previous directory: `/Users/Sam/.lmstudio/models/Pulsate1680/Qwen3.6-35B-A3B-oQ6-mtp`
- Model ID still referenced by both Pi catalogs: `Qwen3.6-35B-A3B-oQ6-mtp`
- The deletion also removed its oMLX per-model settings.

The MacBook currently has these larger models:

| Model | Approximate size |
|---|---:|
| `Jundot/Qwen3.6-27B-oQ6-mtp` | 22.1 GiB |
| `Jundot/Qwen3.8-27B-oQ4e-fp16-mtp` | 16.7 GiB |
| `Jundot/Qwen3.8-27B-oQ4e-mtp` | 15.8 GiB |
| `scottlowry/Qwen3.8-27B-oQ4e-mtp-scottlowry` | 15.8 GiB |
| `True2456/Qwen3.8-27B-AWQ-5.0bpw` | 16.2 GiB |
| `tongrow/MLX-Qwopus3.5-9B-Coder-oQ4-fp16-mtp` | 5.8 GiB |
| `Jackrong/MLX-Qwopus3.5-9B-v3-4bit` | 4.7 GiB |

### Recommended planner replacement

Selected candidate: `Jundot/Qwen3.6-35B-A3B-oQ6-fp16-mtp`.

Reasons:

- Jundot is the oMLX developer, so the publisher and runtime are aligned.
- It preserves the Qwen3.6 35B-A3B planner family, 6-bit target weights, and native FP16 MTP path.
- It is published by Jundot, the oMLX developer, and was uploaded through oMLX.
- It is approximately 30 GB and is appropriate for the MacBook's 64 GB unified-memory capacity.
- The MacBook already has saved oMLX settings profiles for closely related Jundot 35B variants.

The lower-risk alternative is `mlx-community/Qwen3.6-35B-A3B-4bit`, published through the established MLX Community organization. It is also approximately 20.4 GB, but oMLX-specific MTP behavior should be validated before making it the Pi Agent default.

## Cleanup candidates requiring approval

The snapshot cleanup below was explicitly authorized and completed. The remaining cache/model items were not deleted.

1. Existing Time Machine local snapshots: completed; 23 snapshots removed and approximately 184 GiB reclaimed.
2. Stale oMLX SSD/GDN cache: potentially hundreds of gigabytes; clear only while oMLX is idle.
3. Incomplete Hugging Face download `Litwein/Qwable-v2-oQ4e-DWQ-MTP-Vision-MLX`: about 17.9 GiB.
4. Duplicate or empty model directories reported by oMLX discovery.
5. Redundant Qwen3.8 27B variants, but only after functional comparison and explicit selection.

## Safe execution order and status

1. **User action pending:** set Time Machine Backup Frequency to **Manually** in System Settings.
2. **Completed:** remove the 23 explicitly authorized local snapshots.
3. **Pending:** wait until oMLX is idle, then clear stale cache through its supported control and lower the cap.
4. **Deferred for better Wi-Fi:** download and smoke-test the replacement 35B planner.
5. **Pending after live model verification:** update both Pi catalogs to the new distinct model ID.
6. **Future backup work:** attach/configure a dedicated server disk and enable one nightly native backup attempt.
7. **Correction pending approval:** review the 71 corrected true-burst H.264 clips, then rerender only the approved groups from CR3 to ProRes.
8. **Completed:** update and resync the reusable burst workflow with the corrected 0.25-second split, five-frame minimum, three-second finished-duration rule, longest-first motion tiers, and CR3-to-JPEG vision bridge. All eight scripts start under the Mac mini's Python 3.9 without restarting Pi Agent.

## Deferred model task

- Selected download: `Jundot/Qwen3.6-35B-A3B-oQ6-fp16-mtp` (approximately 30 GB).
- Wait for reliable/high-bandwidth Wi-Fi before downloading.
- Do not reuse the deleted Pulsate model's SSD/GDN cache with the Jundot weights.
- After download: verify all six weight shards and model discovery, clear the stale cache while oMLX is idle, configure a bounded cache ceiling, smoke-test tool use, then update both Pi catalogs to the new distinct model ID.