packages/os/linux/variants/milady-tails/docs/mode-parity.md
elizaOS Live v1.0 has two independent boot choices:
The product requirement is that the same capabilities are available in all four combinations. Mode changes can affect speed, persistence, and trace footprint, but they must not silently remove features.
Status as of 2026-05-19: Phase 3-7 overlays are present in source, and a recent ISO artifact passed the normal QEMU greeter/desktop/app-service path. Rebuild and repeat validation for the exact release commit if the branch moves. Treat the table below as the target acceptance matrix until Phase 8 produces evidence from QEMU and real USB across all four modes.
Evidence rule: mark a row as production-ready only after it is exercised in QEMU and on a real USB boot. Until then, "Yes" means required product behavior, not completed validation. Persistence rows are especially pending until real USB create/unlock/delete behavior is proven.
| Feature | Normal + amnesia | Normal + persistent USB | Privacy + amnesia | Privacy + persistent USB |
|---|---|---|---|---|
| elizaOS normal GNOME window launches and is supervised | Yes | Yes | Yes | Yes |
| Local LLM chat | Yes | Yes | Yes | Yes |
| BUILD_APP with local stub | Yes | Yes | Yes | Yes |
| BUILD_APP with Claude CLI | Yes | Yes | Yes, slower | Yes, slower |
| Voice stack | Yes | Yes | Yes | Yes |
| SET_WM / wallpaper / shell actions | Yes | Yes | Yes | Yes |
| GPU acceleration | Yes | Yes | Yes | Yes |
| Cloud APIs | Fast | Fast | Slow or provider-blocked | Slow or provider-blocked |
| OAuth flows | Expected | Expected | May be blocked by provider | May be blocked by provider |
| Chromium browser windows | Yes | Yes | Known v1.0 gap | Known v1.0 gap |
| Chat history survives reboot | No | Yes | No | Yes |
| Built apps survive reboot | No | Yes | No | Yes |
| Downloaded models survive reboot | No | Yes | No | Yes |
| Wi-Fi passwords survive reboot | No | Yes | No | Yes |
| API keys survive reboot | No | Yes, encrypted in LUKS-backed state | No | Yes, encrypted in LUKS-backed state |
If a future phase discovers a capability that cannot work in one of the four modes, the gap must be recorded here before merge. The preferred fix is to restore feature parity. A documented caveat is acceptable only when the phase plan explicitly defers the fix.