A stop command returning is not the same thing as model memory being released.

The failure mode is easy to miss in a local runtime: the command reports success, the UI moves on, and the next load is expected to behave as if the old model is gone. But if a child process still owns mappings, handles, or GPU allocations, that assumption is wrong. You can end up reading stale available-memory numbers, reusing a slot too early, or debugging a “ghost model” that was never actually unloaded.

The useful discipline here is to tie release to process identity, not to command status. Lizard tracks the model-owning process tree and records release proof only when the owning processes actually exit. That gives you something concrete to inspect later: not just that a stop was requested, but that the process tree which held residency is gone.

That matters when you are deciding whether to load a larger model, whether to trust a memory reading, or whether a failed unload needs to be retried instead of ignored. It also makes the lifecycle easier to reason about in mixed setups where one engine spawns helpers and another one keeps a worker warm. If the owning tree is still alive, residency is still real.

I’ve found this is one of those details that only seems optional until the first time a large load collides with a process that was assumed dead. What’s the most reliable signal your stack uses to prove the previous model actually left memory?

Engineering fact: Lizard tracks the model-owning process tree and records release proof so a stopped model is not declared unloaded merely because a command returned.

Lizard The AI Runtime You'll Own—Not Rent.

Receive two professional Windows AI runtimes with lifetime updates. Run AI at native speed, keep every conversation private, and stay independent with intelligent hardware optimization and no cloud dependency.

Read the relevant Lizard page

#modellifecycle #processtracking #localai #windowsai #gpu

<!-- lizard-marketing-slot:day-24-am -->