sizing: budget from actual free memory at startup, not total device RAM (field-driven; expected contentious)

[penta2himajin]

Observation

All sizing derives from total device RAM, never from what is actually free:

• DeviceCalibration.physicalRAMGB() (DeviceCalibration.swift:30-33) = ProcessInfo.processInfo.physicalMemory, overridable only by QWISP_DEVICE_RAM.
• tier(_:) (:36-41) maps that to (mode, C).
• strictStreamingC(tierC:) (:63-92) is the one budget-aware step, and its budget is MTLDevice.recommendedMaxWorkingSetSize — a static per-device ceiling, not a live reading.

There is no host_statistics64 / os_proc_available_memory / vm_stat call anywhere in swift/Sources.

Consequence: on a 16GB Mac already holding 4–5GB in a browser plus the agent harness itself, qwisp sizes as if it owned the machine, and the difference lands in swap. This is the standing complaint in #86, and it is something I said publicly on 2026-07-19 I was evaluating and then never filed — which is why it silently went nowhere. Filing it so it gets a yes or an explicit no.

Why this is not obviously a win

• Free memory is not a stable quantity. Read once at startup, the browser opened five minutes later is invisible. A reading taken at the wrong moment mis-sizes the process for its entire lifetime, and the failure is silent.
• It taxes every user to fix a subset. Dropping C because the machine looked busy costs decode tok/s permanently. The strict streaming collapses ~10x on real 16GB Macs (systematic across 5 machines) — investigation + call for a probe run #69 fit rule is already conservative (80% of the working set).
• macOS "free" is a misleading number. Purgeable, compressed and file-backed pages mean vm_stat's free count is not what qwisp can take without causing eviction. Choosing the wrong term yields a rule that is worse than the static one because it is unpredictable.
• The competing fix runs the other direction: shrink the footprint (serialize: MLX free-buffer pool is unbounded (lane-only cacheLimit) — measured +7.7GB on a long prefill #162) instead of detecting the pressure.

Step 0

Establish that the input is measurable at all, before changing any sizing:

1. On a 16GB machine (or qwisp simulate at that tier), log candidate terms at startup — os_proc_available_memory(), host_statistics64 free/inactive/purgeable/compressed, recommendedMaxWorkingSetSize — alongside the footprint the process actually reaches.
2. Repeat idle and under realistic load (browser + agent harness).
3. Decide from the data whether any single term predicts "how much can qwisp take before this machine swaps" to within one C step (32).

Kill criteria, fixed before looking: if no candidate term predicts the swap threshold to within one C step across the idle/loaded pair, close it — sizing from a number that does not predict the outcome is worse than the static rule, because it fails silently. If one does, the change is a clamp on top of the existing fitC, never a replacement for it.

Refs

#86 (field report; where this was promised) · #69 / PR #70 (strictStreamingC, the existing budget-fit rule this would clamp) · #162 (reduce footprint — the competing approach) · DeviceCalibration.swift:30-92