Download GLaDOS ISO

Write the image to a USB stick. It is a hybrid image, so any of these work:

# Linux / macOS. Check the device name first, this overwrites it
sudo dd if=glados-1.2.28.iso of=/dev/sdX bs=4M status=progress oflag=sync

• On Windows, Rufus in DD mode.
• Anywhere, balenaEtcher handles the ISO directly.

1. Write the image and leave the stick in.
2. Reboot and open the firmware boot menu. Commonly F11, F12, F8 or Esc.
3. Pick the USB device listed under UEFI.
4. Watch the boot log. It prints the memory map it was handed, the size of heap it managed to get, every device it finds on the PCI bus, and a pass or fail line for each self-test.

That log rewards a read. Twenty-seven sections run at boot, twenty-three of which can be re-run on demand as named suites: fifteen sets of published cipher vectors through the crypto primitives, the heap and the timer, the ACPI namespace walk against your own firmware's tables, and a check that the grammar the sampler is given admits exactly the applet names it should. An ECDSA bug once sat visible in that output for an entire debugging session while the person reading the screen was scrolling past it.

A Windows 3.1-styled desktop with a window manager, a taskbar and a terminal, and behind that a shell. gen generates text and ask answers a question, both from the model in kernel space. if lists interfaces, dhcp takes a lease, dns resolves a name and https example.com / fetches a page over a TLS 1.3 connection that this kernel negotiated itself, down to the X25519 key exchange. battery reads a charge by evaluating the AML your firmware ships in its DSDT, because on a laptop there is no other way to get one. agent hands the model a goal and a step budget: it picks an applet through a grammar that makes wrong names unreachable, reads what the applet prints, and writes a transcript to /ai/episodes. think poses a question to the same mind while the shell stays yours. crypto, tensor and model re-run the self-tests on demand, and help lists the rest.

A running system can fetch a new kernel image, check it against a signing key compiled into the one already running, and stage it for the next boot. The previous image is kept as a rollback copy, and a boot that fails to reach the memory map falls back to it.

An image booted from this ISO cannot update itself. ISO 9660 is read-only and there is no writable EFI partition on it, so there is nowhere to stage anything. Updating needs an installed system. The update command says so directly when it cannot find a boot volume to write to.

Weights are not updated this way. They are 570 MB to 1.9 GB and the network stack has a 32 KB receive window with no resume, so a new checkpoint arrives by downloading a new image from this page.

Commands: update reports what is running and what the channel last offered, update check asks, update fetch downloads and verifies, and update stage writes it for the next boot after you type back eight characters of the image digest.

Development happens against one laptop, an MSI Thin GF63 12UC, and that is the only machine any of this is meaningfully tested on.

It should boot on most x86-64 UEFI systems. Nothing in the boot path is vendor-specific and the graphics path is plain GOP, which every UEFI implementation provides. Storage and networking are a different story, because a driver has to match a chip: there is one for Intel e1000, one for Realtek RTL8168, one for NVMe and one for xHCI, and that is the whole list. So expect a working desktop and a working model, and treat your disk and your network card as an open question.

The battery reading is a further open question, and in the other direction. It goes through an interpreter that runs your firmware's own bytecode, which is universal by construction, but the embedded controller it reaches through has never had its success path exercised: QEMU models no controller, so under emulation only the timeout is proven and every figure shown is a fallback.

Is the GLaDOS ISO free?

Free to download and free to run. The source is published under all-rights-reserved, which means you are welcome to read it. Redistributing it or building derivatives from it needs asking.

Will it damage my computer or my files?

It runs from the USB stick and installs nothing. NVMe writes are locked at boot and only unlock if the driver finds a disk region that was explicitly set aside for it, and every error path locks them again. On a laptop whose disk is entirely allocated to Windows there is no such region, so storage initialisation fails and says so, which is the intended outcome.

Which image should I take?

The SmolLM2 image if you are running it under emulation, because it is the only one that fits QEMU's 516 MB disk ceiling and it is four times faster per token. The Qwen3-0.6B image on real hardware with 2 GB of RAM. The 2B images want 5 GB, and 8 GB for the 32k context variant.

Can I run it in a virtual machine?

Yes, with UEFI firmware, which means OVMF. Use the SmolLM2 image: QEMU's built-in FAT support caps the whole emulated disk at 516 MB and every other image is larger than that. Give the guest at least 2 GB of RAM as well, because the weights are read into memory before ExitBootServices and the guest has to have somewhere to put them.

Why does it need Secure Boot disabled?

Because the kernel is not signed by a key your firmware trusts. Getting one would mean going through a Microsoft-signed shim, which is a matter of distribution and paperwork.

How fast is the model?

Generation is bound by memory bandwidth, so the useful rule is that each token costs roughly one pass over the weights. That makes the 570 MB Qwen3 checkpoint about 4.4 times slower per token than the 135 MB SmolLM2 one. Around 155 MB of Qwen3 is the output classifier alone, which is why restricting that final matrix multiply to the tokens a grammar can actually reach is such an effective optimisation.

Does it send anything anywhere?

No. There is no telemetry and no network activity at all unless you type a command that causes some. There is an updater, and it runs only when you ask it to: nothing checks for a new version on its own, at boot or on a timer. The model runs locally because there is nowhere else for it to run.