jundot/omlx v0.3.12

on GitHub

0.3.12 is a quick follow-up to 0.3.11. The new memory guard was too conservative on memory-tight Macs and started rejecting models that 0.3.10 had been loading fine (#1431) — sorry to everyone who hit that. This release tunes the dynamic ceiling to match how macOS actually handles memory pressure, and adds a Custom tier so you can pin the ceiling to a specific number if the automatic math doesn't fit your workflow.

Memory guard tuning

• Dynamic ceiling now counts active-memory reclaim potential. 0.3.11's ceiling was psutil.available (= free + inactive only), which left out the memory macOS routinely compresses or swaps to satisfy a new allocation. On a 32 GB Mac that meant a ceiling of ~17 GB instead of the ~26 GB that 0.3.10 had been giving. The new formula reads vm_statistics64 directly and counts a tier-dependent fraction of active memory:

  Tier	Active reclaim	32 GB Mac example*
  Safe	20%	~20 GB
  Balanced	50%	~23 GB
  Aggressive	80%	~26 GB

  * Dynamic ceiling = phys + free + inactive + active × N%. Example assumes an idle 32 GB Mac with free 13 GB, inactive 5 GB, active 10 GB, oMLX phys ~0.5 GB.

  Safe stays well within the immediately reclaimable pool, Balanced lines up with macOS' average ~2-3× compression ratio, Aggressive pushes into swap (panic-safe — Metal cap still clamps).

• Custom tier. Adds a 4th dropdown option. When selected, a number input appears next to the dropdown — type a GB value and the dynamic ceiling pins to that. Useful if you want to reserve a fixed amount for other apps or run a known-size model with no math involved. Still clamped by static reserve and iogpu.wired_limit_mb so an out-of-range value can't panic.

• Admin dashboard rewrite. The "safety buffer" wording and the previous breakdown line are gone. The new line shows the actual reclaim math:

  * Free 463.3 GB + inactive 22.1 GB + (active 18.8 GB × 50% = 9.4 GB) → ceiling 494.9 GB
  

  When the kernel iogpu.wired_limit_mb ends up being the binding constraint, the line switches to / effective ceiling X (kernel limit) so you know the tier math isn't what's deciding the cap.

• Other apps' compression / swap is now factored in. This means Aggressive on a contended system may push macOS into swap thrashing — that's by design ("max ceiling" tier). Safe and Balanced keep memory pressure inside macOS' normal compression range.