flash demo — recorded on macOS (Apple silicon)

Scenario 1: Get ready — version, the guest bundle, restart the background services (flashhostd, flashpoold, flashgpud; flashnetd on Linux).
Scenario 2: Create a FlashVM — 1 CPU, 256 MB, no network; its boot time.
Scenario 3: Create a FlashVM with a network — one NAT card built by flashnet; boot time, IP, the whole command's time.
Scenario 4: Run commands inside the VMs — hello world; fetch a page (HTTP and HTTPS); a background command listed and killed; a file copied in, read and deleted; --json --changes reporting an edit, a rename and a delete in one call.
Scenario 5: Network walls — --egress public: the internet reached, the router refused; the connection log as a table; the rule changed to none while it runs.
Scenario 6: Share a folder — host folder read and written from inside the VM, seen on the host.
Scenario 7: Watch a VM — flash inspect as a readable table; its log; live numbers while it downloads 60 MB and computes (Downloaded grows, CPU climbs).
Scenario 8: Change a running VM — CPU cap timed at 200 and 1000; memory taken and given back (balloon); download speed capped and lifted; pause and resume; a run-length limit that can be lowered but not raised, lowered to 5 s and the VM stops itself.
Scenario 9: Talk to a VM — a program inside answers HTTP and replies to a message, with no network card.
Scenario 10: Stop, list and remove VMs — flash ls; stop one, then remove it; remove the rest.
Scenario 11: Warm pool — 5 VMs booted ahead of time.
Scenario 12: Use VMs from the pool — two claimed in milliseconds, each runs a job; compared with scenarios 2 and 3; what the waiting VMs cost.
Scenario 13: Clean up the pool — used VMs removed; the pool removed with the VMs it held.
Scenario 14: Network pool — Linux: 5 network cards built ahead of time, 5 VMs start on them and reach the internet, then cleaned up. macOS and Windows: one line, skipped.
Scenario 15: Snapshot and restore — a counting VM saved to a file and removed; restored, it carries on.
Scenario 16: Clone — three new VMs from the same snapshot, each carrying on from the saved count.
Scenario 17: Sleep and wake — a VM with a network card sleeps (no process, no memory), wakes and carries on, network and rules included.
Scenario 18: Move a VM to another computer — with a second machine of the same kind: the snapshot is copied there and the VM carries on there. Otherwise it says why it is skipped.
Scenario 19: Forking — a project set up once, forked into three copies, three fixes tried at once, flash diff of the winner, the winner kept.
Scenario 20: Undo: checkpoints and rewind — the same project; three steps with --checkpoint, step 2 is the mistake; flash history as a table (sizes as this machine stores them); rewind to checkpoint 2 and the file is back.
Scenario 21: Undo for files on this computer — a shared folder on this computer rewinds with the VM, file for file.
Scenario 22: Hidden API keys — a VM with no internet uses an API key through FlashVMM's proxy; the key is searched for inside the VM and not found; the call is counted outside.
Scenario 23: GPU pool — a model loaded once on the host GPU; three VMs ask it questions at once; who used it.
Scenario 24: One machine or many — the machine's room for VMs, a too-big VM refused and a smaller one accepted; a controller. With a second machine: the refused VM placed there; with one of the same kind, a running VM moved live (its counter carries on). Without one, it says what was skipped and why, including SSH's own error.
Scenario 25: An AI assistant drives FlashVMM — through flash-mcp: start a VM, run a command, remove it.
Scenario 26: Put an AI agent in jail — an AI assistant's commands run in a separate, throwaway computer that sees only your project.

FlashVMM live demo: the real flash demo, all 26 scenarios