BootGPT puts its neural-network runtime inside a 512-byte boot sector, loads an 11.5 KB int8 model from the next 23 disk sectors, and starts generating imaginary Linux boot messages. According to the project repository, it runs in 16-bit real mode on a 386, without an operating system or C runtime.
The project appeared on Hacker News on October 31, 2026, as recorded in an archived submission listing. Its purpose is deliberately narrow: produce text that resembles a machine starting up, complete with timestamps, PCI addresses and ACPI messages for hardware that never existed.
The interesting achievement is the implementation budget. BootGPT has eight characters of context and one hidden layer. It is an educational size-coding exercise, not a capable assistant or a miniature replacement for today’s LLMs. For developers, its useful contribution is a compact example of how model architecture, integer arithmetic, firmware services and verification fit together.
The Model Is Behind the Boot Sector, Not Inside It
BootGPT’s headline size needs one important distinction: the assembly runtime fits in the first sector; the model’s data does not.
The README describes a 512-byte master boot record, with the inference engine and BIOS handling squeezed into a 510-byte code budget. Model weights, vocabulary and strings occupy the following sectors. Keeping those bytes outside the runtime is what makes the single-sector implementation possible. The repository documents the split explicitly.
| Component | Documented arrangement | Practical meaning |
|---|---|---|
| Boot sector | 512 bytes, with a 510-byte code budget | Holds the inference runtime and BIOS plumbing |
| Following data sectors | 23 sectors | Hold model weights, vocabulary and strings |
| Model | Character embeddings and one hidden layer | Predicts the next character from a very short context |
| Execution environment | 16-bit real mode on a 386 | No operating system or C runtime |
| Output | Fictional Linux boot logs | Generated text, not actual hardware diagnostics |
The sector arithmetic also clarifies the size claim. Twenty-three 512-byte sectors provide 11,776 bytes, or exactly 11.5 KiB. The README calls this 11.5 KB. Together, the boot sector and those data sectors account for 12,288 bytes, or 12 KiB of sector capacity. That is not a claim about the final image’s size or its complete memory footprint.
The runtime uses BIOS interrupt int 13h to load the weights and int 10h to print characters. Those firmware services supply the basic disk and display operations that an operating system would normally help provide. BootGPT eliminates the OS and language runtime, but still relies on the BIOS environment.
I’d treat the code-and-data split as the most useful part of the size claim. “A model in 512 bytes” would hide the storage requirement. A complete inference engine in one sector, backed by a small, separate data payload, is both precise and technically interesting.
Eight Characters of Context Set the Quality Ceiling
BootGPT’s documented network uses character embeddings, one hidden layer and a softmax during training. Its context window is eight characters. Despite the GPT name, this is a small feed-forward character model, not a GPT-style transformer. The README makes that limited architecture clear.
Eight characters are enough to pick up local patterns: punctuation, fragments of device names, hexadecimal-looking addresses and pieces of recurring log messages. They cannot preserve a meaningful account of a long boot session. A plausible line therefore offers no assurance that the next line will describe the same kernel, disk or hardware.
The training data is tailored to make that limitation less conspicuous. The repository’s corpus_gen.py creates 3 MB of synthetic dmesg-style text. Each generated boot session uses one kernel version and one disk, reproducing the repetition found in real logs. The author explains that this repetition helps such a small network produce recognizable output.
That is a consequential design choice. Boot logs have a strong visual grammar, with recurring prefixes, brackets, numbers and familiar subsystem names. A tiny model can imitate those local features without tracking what an actual computer is doing.
The README’s examples show the resulting mix: recognizable Linux-style formatting alongside damaged words, odd fragments and inconsistent-looking values. These are expected consequences of the architecture and training setup. The text is entertainment, not evidence of detected hardware or a running Linux kernel.
Int8 Changes the Arithmetic, Too
The training script quantizes the model to signed 8-bit values using power-of-two scales. Int8 represents integer values from −128 to 127, allowing compact storage.
Quantization also changes what the runtime must calculate. Multiplication, accumulation, scaling and activation need to produce useful results with integer arithmetic. Power-of-two scales simplify the relationship between stored integer values and their numerical interpretation.
The README describes an integer forward pass built around imul and idiv, including a soft-clipping activation implemented with cdq and idiv. It also describes runtime selection as argmax with timer-seeded noise, with a linear congruential generator included in the Python simulation.
The important engineering point is that exporting small weights is only part of the job. The deployment arithmetic must be specified closely enough that training-side code can predict what the assembly will actually do.
Build and Run It With NASM and QEMU
The repository includes assembly source, corpus generation and training scripts, build and launch scripts, and an MIT license. Its documented quick-start uses NASM, QEMU and Python with NumPy.
On a Mac with Homebrew available, the README’s commands are:
brew install nasm qemu
python3 -m venv .venv && .venv/bin/pip install numpy
./build.sh
./run.sh
Run these from the downloaded project directory. The first command installs the assembler and emulator. The second creates a local Python environment and installs NumPy. The supplied scripts then handle the project’s build and QEMU launch workflow.
The repository’s files divide the exercise into useful stages:
corpus_gen.pygenerates synthetic boot-log training data.train.pytrains and quantizes the model, and simulates the deployed integer calculations.boot.asmcontains the runtime, including disk loading, inference and screen output.record.pyrecords the demonstration through a headless QEMU monitor connection.
QEMU is the sensible starting point. It lets developers inspect the boot behavior without writing an image to physical media, and it supports the debugging workflow described by the author. The runtime also reboots on any keypress, so there is no chat prompt or interactive assistant interface.
The README says the resulting disk.img can be written to a USB stick and booted on BIOS hardware. That condition matters: this is a BIOS-oriented image, so readers should not assume it will boot directly on a UEFI-only machine. Writing a raw image to a USB device can overwrite its contents; an emulator avoids that risk while exploring the project.
Python Mirrors the Assembly to Catch Real Bugs
BootGPT’s strongest teaching material may be its verification strategy.
The training script simulates the exact integer arithmetic used by the assembly, including the pseudorandom sampler. The author reports that its output matches the boot-sector output character for character. That is the project’s reported result; this article does not include an independent reproduction. The README documents the intended comparison.
Matching the deployed arithmetic matters because a floating-point reference can miss implementation differences introduced by quantization. A mismatch might come from numerical choices, sampling state or an ordinary assembly bug. Reproducing the integer path in Python narrows the search.
Frequently Asked Questions
3 questions
1Does the Whole Model Fit in 512 Bytes?
No. The boot sector contains the assembly runtime. The model weights, vocabulary and strings live in the following 23 disk sectors.
