The number that decides which model runs well on a Mac is not total memory, it is the memory the GPU is allowed to take. On Apple silicon that budget is roughly three quarters of unified memory, so a Mac with 48 GB has about 37 GB available to a model, and a model whose weights are larger than the budget will either refuse to load or fall back to swapping and become unusable. The practical rule is to keep the file on disk under about two thirds of your available budget, because context and key-value cache grow on top of the weights as the conversation gets longer. Grux OS reads the actual hardware, computes that budget, and rates each model in its catalogue as a good fit, tight, or not worth downloading.
system_profiler SPHardwareDataType | grep Memory.| Unified memory | Roughly available to a model | Comfortable model size on disk |
|---|---|---|
| 16 GB | about 12 GB | up to about 8 GB |
| 24 GB | about 18 GB | up to about 12 GB |
| 36 GB | about 27 GB | up to about 18 GB |
| 48 GB | about 37 GB | up to about 24 GB |
| 64 GB | about 48 GB | up to about 32 GB |
| 128 GB | about 96 GB | up to about 64 GB |
The Local Models surface reads your hardware profile rather than asking you for it, budgets the memory, and scores each model in a curated catalogue against the result. It returns one recommendation instead of a list, and it will tell you what not to bother with, which is the more useful half.
On an M4 Pro with 48 GB it reports about 37 GB available, marks Qwen 3 Coder 30B a good fit at 19.0 GB on disk, and marks a 35B at 24.0 GB as tight. That is the whole feature: the answer before the download rather than after it.
A model is sold by parameters and downloaded by bytes, and the ratio between them is the quantisation. The same 30B model can be a 19 GB file, or three times that at higher precision. Sizing a download by parameter count is how a Mac that could have run the model ends up swapping on one that never fitted.