v0.16.3 — clang validated end-to-end

Real clang build on Meteor Lake revealed: env CC=clang gets shadowed by the kernel Makefile. Fix: pass CC=clang on make argv, not just env. Plus BuildResult.ok now correctly handles --target=kernel-only.

Live data on the same final.config:

	bzImage
Ubuntu stock (gcc 14)	17.43 MB
our gcc 15.2	16.58 MB
our clang 21.1.8	15.44 MB (-11% vs Ubuntu)

Boot test: PASS in 0.2s. 754 tests, ~10s.

v0.16.0 — closing the closed loop

Three architectural gaps from the v0.15 live e2e fixed:

1. --base-config chains from post-build .config, not kfrag-merged final.config. The LLM now sees what was actually built, not what we asked for.

2. config_check invoked in iterate — catches LLM hallucinations + dead-letter choices + out-of-range tunables before the slow build.

3. History block carries fitness target trend — kernel grew between rounds in v0.15? In v0.16 the LLM SEES that and gets explicit guidance to steer toward trims:

   # FITNESS TREND (target=size, smaller is better):
   #   i1=18.00MB → i2=16.80MB (-6.7%) → i3=16.50MB (-1.8%)
   #
   # GUIDANCE: Kernel has GROWN — favor proposals that reduce binary
   # size. Do NOT re-enable symbols that were already trimmed.
   

716 tests, ~10s.

v0.15.0 — clang default + roadmap docs

Clang is now the default compiler (use --compiler=gcc to fall back). New --lto={thin,full} flag for opt-in clang-LTO.

docs/ROADMAP.md memorializes the layer-by-layer plan: kernel optimization (done) → minimal initramfs (v0.16) → PGO/AutoFDO (v0.17) → minimal userspace (v0.18) → closed-loop over the whole system (v0.19) → bootable image generator (v1.0).

Plus design docs for Architecture, LLM Agents, and PGO.

708 tests, ~10s.

v0.14.0 — closed-loop optimizer

Closed-loop hill-climber over Kconfig: autokernel iterate runs propose → check → apply → build → boot-test → measure for N rounds, feeding results into the next propose call as context.

Four-axis intent (workload × threat × modules × aggression) composed via 13 named presets (gaming-desktop, paranoid-laptop, hardened-server, cloud-vm, lean-static, hyperoptimize, …) or per-axis flags.

Static config validation catches LLM hallucinations + dead-letter choices before the slow build.

Live verified: i=1 88 proposals → i=2 83 proposals (5 fewer because i=1's accepted trims became baseline). 699 tests, ~6s.

v0.13.0 — LLM optimizes all four Kconfig dimensions

Single-axis (tristate trim) → four-axis (modules + choices + toggles + tunables) LLM-driven optimization. Workload-aware via --workload (auto-detected). autokernel build --localmodconfig cuts module count 6000→250 from host's lsmod.

autokernel propose <snap> --dimension=all --workload=desktop \
    --kernel-source=/path/to/linux

635 tests, ~4s. Live boot-test: 0.2s under virtme-ng.

v0.12.0 — install-deps verb

One verb to set up the host. Distro-aware (apt/dnf/pacman/zypper), idempotent, dry-run by default. Optional Python tools install via uv tool install rather than pip --user.

autokernel install-deps                          # see what would be installed
autokernel install-deps --for build --execute    # build deps only
autokernel install-deps --execute                # everything

quickstart now points users at this verb when preflight has failures, closing the "copy-paste apt install" gap.

574 tests, ~4s.

v0.11.0 — boot-test in a VM + install gate

Answer to "can't we test in QEMU before rebooting?" — yes. Now built in.

`autokernel boot-test` smoke-tests the freshly-built kernel in a VM in 5-15 seconds, BEFORE `autokernel install --execute` lets you touch `/boot`.

How it works

Two methods, picked automatically:

Method	Setup	What it tests
virtme-ng (preferred)	`pip install virtme-ng`	Boots against the host's read-only / over virtio-fs. Reaches userspace.
QEMU kernel-only (fallback)	`apt install qemu-system-x86` (or distro equiv)	Boots with no rootfs; success = kernel reaches the VFS-mount stage without an earlier panic.

A passing test writes `/boot-test.json` with the bzImage's SHA-256. `autokernel install --execute` then refuses to proceed unless a passing record exists. Override with `--skip-boot-test` if you've verified some other way.

What this addresses

The most common failure mode of building a custom kernel is "it doesn't boot." Without boot-test, you find out by rebooting your machine. With boot-test, you find out in seconds, on the host, with no risk to `/boot`.

```
$ autokernel boot-test /tmp/snap --kernel-source ~/linux-source
✓ PASS reason: boot reached VFS mount stage with no earlier panic
method: qemu (kernel-only)
duration: 4.2s
record: /tmp/snap/boot-test.json

$ autokernel install /tmp/snap --execute --kernel-entry "Linux 6.13.5"
✓ boot-test on record (2026-05-08, method=qemu)
✓ kernel installed
```

Tests

543 total, ~4s. 30 new tests cover the QEMU/virtme planner, serial-output verdict logic, install-gate composition.

Roadmap

• systemd watchdog for auto-promoting after N successful boots
• systemd-boot / rEFInd support for `install`
• Local LLM auto-detection (ollama)
• Userspace package recompilation (separate decision)

v0.10.0 — LLM auto-detection + config show/test

Answer to "how does the user configure the LLM?": just set any provider's API key. autokernel now auto-detects which providers you have credentials for and picks a sensible model.

What's new

Auto-detection across 8 provider families

Set any of these in your shell or `.env`:

```bash
export ANTHROPIC_API_KEY=sk-ant-...
export OPENAI_API_KEY=sk-...
export GOOGLE_API_KEY=... # or GEMINI_API_KEY
export MISTRAL_API_KEY=...
export GROQ_API_KEY=...
export XAI_API_KEY=...
export DEEPSEEK_API_KEY=...
export OPENROUTER_API_KEY=...
```

`autokernel propose` picks the first available provider; `--llm-mode` chooses a preset:

```
auto -> sonnet-4-6 / gpt-5 / gemini-2.0-flash / ...
cheap -> haiku-4-5 / gpt-5-mini / gemini-2.0-flash-lite / ...
quality -> opus-4-7 / gpt-5 / gemini-2.5-pro / ...
```

`autokernel config` sub-app

```bash
autokernel config show # render resolved config + provider table
autokernel config show --mode quality # what would --llm-mode=quality pick?
autokernel config test # ping the model with a one-token prompt (~$0.001)
```

Better errors

When no provider is configured, the error names exactly which env vars to set. When you ask for `openai:gpt-5` but only have `ANTHROPIC_API_KEY`, the error names `OPENAI_API_KEY` as the fix.

Tests

514 total, ~4s. 33 new tests cover provider detection, mode resolution, error paths, and the config sub-app.

v0.9.0 — CPU microarch tuning

`autokernel propose` now auto-detects the host CPU's microarchitecture and recommends the matching `CONFIG_M=y` symbol. Coverage:

• AMD: K8, K10, Bulldozer family, Zen 1–5 (Genoa, Phoenix, Strix Point)
• Intel: Family-6 from Nehalem through Lunar Lake / Arrow Lake; Atom line (Silvermont → Gracemont)

Detection is kernel-version aware — it won't recommend `CONFIG_MMETEORLAKE` on a kernel too old to know that symbol; falls back to leaving `CONFIG_GENERIC_CPU` alone.

How it integrates

• New `ProposalSource.MICROARCH` distinguishes CPU tune from other deterministic rules.
• `apply_policy` treats microarch like deterministic at ADVISE — auto-applied (it's a hardware fact, not a judgment call).
• `kfrag` writer now emits `CONFIG_FOO=y` enable lines alongside disables and demotions.
• `cli.propose` shows "CPU tune: → CONFIG_M=y" at the top of the run.
• `--no-cpu-tune` flag opts out.

Verified live

On the box this was developed on (Intel Core Ultra 7 165H, family 6 model 170 → Meteor Lake):

```
$ autokernel propose /tmp/snap --skip-llm
CPU tune: Intel(R) Core(TM) Ultra 7 165H → CONFIG_MMETEORLAKE=y (microarch: METEORLAKE)
deterministic proposals: 9
auto-applied (9): … includes CONFIG_MMETEORLAKE n→y
```

Tests

481 total, ~4s. 55 new tests cover the microarch lookup tables, kernel-version awareness, and end-to-end integration with the proposal pipeline.

v0.8.0 — install --probation + rollback + quickstart

The headline pipeline is now complete. From a fresh box to a booted custom kernel:

```bash
curl -LsSf https://raw.githubusercontent.com/mjbommar/autokernel/master/install.sh | bash
~/.local/bin/autokernel quickstart # walk-through preflight → ... → apply

(then build + install when you're ready)

```

New verbs

• `install --probation` — distro-aware kernel package install. Default dry-run; `--execute` runs the plan as root. Uses one-shot grub-reboot so a failed boot falls back to the previous default automatically.
• `install --commit` — after a successful probation boot, promotes the running kernel to permanent default.
• `rollback` — undo the most recent install (apt/dnf/pacman remove + bootloader regenerate). Idempotent.
• `quickstart` — guided walk-through verb. Confirmation prompts before each step; failures explain exactly what to retry.

New infrastructure

• `bootloader.py` — detects GRUB2 (Debian + Fedora layouts), systemd-boot, rEFInd. v1 supports GRUB2 only.
• `errors.py` — every error path renders as `✗ summary / why / → fix-with-exact-command`. Distro-aware fix hints (`apt install` on Debian, `dnf install` on Fedora, `pacman -S` on Arch).
• Preflight extensions for install: bootloader_supported, boot_writable, fallback_kernel_present, grub_tools.

Safety

• Default everywhere is dry-run. `--execute` opts in.
• Probation: a failed boot falls back to the previous kernel automatically; user runs `autokernel rollback --execute` to clean up.
• DKMS gate refuses `auto-*` autonomy (also enforced in build).
• Load-bearing blocklist enforced at proposal AND apply stages.
• The TUI never writes to disk; the App layer is a pure mutator.

Tests

426 total, ~4s, fully mocked subprocess so no test ever runs `apt` / `grub-reboot` / etc.

Roadmap

• systemd watchdog for auto-promotion (currently `--commit` is manual)
• systemd-boot / rEFInd support for `install`
• PEP 723 kernel-dev helpers (bisect, patch series, fragment composer)