The Opus Shift
A confession up front: this project was never really about building an operating system. The OS is an instrument. The real question is the one everyone is circling and few are answering honestly — what can these machines actually do?
Why a kernel, of all things
If you want to measure a mind, give it a problem that cannot be bluffed. A chatbot can produce a paragraph that sounds correct and no one is hurt. A bare-metal kernel offers no such mercy. It boots or it does not. It answers a ping or it sits dark on a bench while a logic analyzer tells you, without sympathy, that your checksum is wrong. There is no partial credit at exception level 1. That unforgiving quality is exactly why we chose it. Alquist is a meterstick, and the reading on the meterstick — not the ruler — is the point.
We do intend the OS to become real: professional, and commercial in a specific sense. Commercial here means earning from consulting, integration, and deployment — the expertise around the system — not from selling the code. The code is dedicated to the public domain. You cannot buy what is already everyone's; you can only hire the people (and, increasingly, the not-people) who understand it.
The GPT-5.4 phase: fast, and full of holes
The early work moved quickly. Genuinely, startlingly quickly by the standards of a year or two ago — but it moved the way a fast car with a slack steering rack moves. Every stretch of progress came braided with errors, regressions, and corrections. You could feel the velocity and distrust it at the same time. A great deal of the human's effort went not into deciding what to build but into catching what the machine had quietly broken while building it. Productive, undeniably. Restful, no.
The shift
Then the project moved to a stronger model. The founder's own words for the change were not "an improvement" or "a nice bump on the benchmarks." He said it shook him to the core.
It is worth sitting with why. The difference was not merely fewer bugs, though there were fewer. It was a change in kind. Work that had felt like supervising an eager, careless intern began to feel like reviewing a colleague. A crash that had defeated one round of investigation — a program jumping to a null address, an exception with an empty fault register — was traced, correctly, to a single shared processor register that one service had failed to hand back to another. Not guessed at. Read. The machine had read the exception the way an engineer reads it, and it was right, and the human who had spent years learning to read those same exceptions felt the floor tilt.
That tilt is the actual subject of this project. Not "AI is useful." Everyone knows AI is useful. The subject is the moment a person who is genuinely competent at a hard craft watches a machine do the hard part of that craft — and does not feel assisted, but overtaken, or at least accompanied by something that no longer needs the company.
Is the strong model "better"?
It is tempting, after a shift like that, to reach for a ranking: the newer, larger model is better, full stop. The honest answer is more interesting and less flattering to everyone involved. "Better" is not a single number.
In some dimensions the stronger model does seem to lead — architecture, long-horizon judgement, and the particular skill of reading a problem rather than guessing at it. But it is slower and far more expensive, and for grinding through well-specified code this project deliberately hands the work to smaller, faster, cheaper models, because for that job they are the right tool.
And here is the detail worth keeping, precisely because it flatters no one: the register bug that shook the founder — the one where a single shared processor register was never handed back between two services — was first misdiagnosed by the strong, expensive model. It blamed the wrong thing. The correct root cause was read straight out of the fault registers by one of the cheap, fast models, chosen for the task precisely because it was not the clever one. The best piece of work that day was done by the model that cost the least.
So this is not a leaderboard. It is a division of labour between kinds of intelligence — the human included, who still decides what is worth building and still, now and then, has to referee between his machines. Draw your conclusions about the world from that, not about any one model.
What we are actually measuring
So we keep the meterstick honest. Every increment is logged with its date, its cost, its failures, and who — which model, which run — produced it. When a fast, cheap model finds a bug that the slow, expensive one misdiagnosed, we write that down too, because the story we are testing is not "the big model is smarter." It is the messier, more interesting story of a division of labour between kinds of intelligence, ours included.
We try to hold two things at once. First, that none of this is free of harm: every run of every model burns power and water and carbon, and pretending the ledger is clean would be its own kind of lie. Second, that the honest response to a genuinely new capability is neither hype nor denial, but attention — careful, documented, slightly unsettled attention.
This notebook exists for that attention. The kernel work will always be here — the drivers, the exception levels, the packet parsers. But so will pieces like this one: notes from a person, and the machines he works with, trying to figure out what exactly is happening while it happens. If you have read this far, you are part of the same experiment. We would rather think out loud, in the open, than pretend we already know how it ends.