Other apps can take memory away from a local model while it works, and a long chat then slows down or gets refused. The memory lock, added in Elzi 4.1.3, keeps a measured amount of memory for the engine so that doesn't happen. It is off until you turn it on. In our test on a MacBook Pro, the time to the first token with the lock on matched a run with no other app competing, while the unlocked engine fell up to 27 % behind.
How to use it
- Open the LeanZero MLX view and go to the Memory tab.
- Choose "Test and lock from the Engine tab". A Memory lock panel appears.
- Run the context test. It measures how much memory this Mac can keep for the mounted model right now and how many tokens of context that buys.
- Press Lock to keep it, or Release to give it back to macOS.
"Lock when the model mounts" takes the lock every time the model loads, sized by the test or by a token count you set. On critical memory pressure the lock gives memory back by default; "Hold the lock" keeps it instead. The panel shows since when it holds, what limited the test, and how much the engine really holds if macOS didn't let it wire all of it.
How it works
The engine wires a reserve of memory pages that other apps can't take. Right before a step needs room, it releases a chunk of that reserve, and it fills the reserve again afterwards. The lock is a minimum, not a cap: context beyond it still runs, on whatever memory is free. Filling the reserve stops at the first macOS memory-pressure warning or when swap starts to grow.
What we measured
| Run | Turn 2 | Turn 3 | Turn 4 | Turn 5 |
|---|---|---|---|---|
| No lock, quiet Mac | 51.4 s | 94.1 s | 87.4 s | 103.6 s |
| No lock, competing app | 50.7 s | 84.7 s | 105.8 s | 131.2 s |
| Lock on, quiet Mac | 49.3 s | 66.5 s | 86.9 s | 101.7 s |
| Lock on, competing app | 48.5 s | 64.4 s | 87.8 s | 103.9 s |
Each setup is compared with itself on a quiet Mac. Without the lock, turns 4 and 5 were 21 % and 27 % slower under competition; with the lock they stayed within 1-2 %, and a second locked run the same day matched again. On turns 2 to 4, decode speed held at 75-89 % of the reference with the lock and fell to 52-60 % without it. In the second run the unlocked engine refused a 144,614-token prompt, while the locked engine served 144,735 tokens.
The app allows about a minute for the context test; our runs finished in under a second. On 6 November 2026 the first test, taken before any prompt, estimated about 30 GB for Qwen3.5-9B's full 262,144-token window. After the first prompt the calibrated figure on the MacBook was 37.2 GB, which is why it pays to test again. We also checked Lock and Release in the released app on the M5 Max Mac Studio.
Limits we know about
- These are two locked runs with one model on one MacBook. Treat the numbers as a first measurement.
- Decode can still slow down under heavy competition (about 20 % in the first run), because macOS compression work is not covered.
- The give-back on critical pressure is proven in tests only. In a live try macOS swapped 12 GiB in 32 seconds without ever reporting critical pressure, so the panel shows swap as well.
- Prompt-cache entries count inside the lock, so the token figure assumes an empty prompt cache. A test before the first prompt is an estimate; test again after it for the calibrated figure.
- The two-Mac split engine doesn't have the lock yet.
Facts on this page were checked against our own test records on 6 November 2026.