Introducing NexaCore OS: an AI-native operating system, from the kernel up
Most of the software you touch every day now leans on artificial intelligence. Almost none of your operating system does. The model that answers your questions runs in a datacentre you do not own, reached through an API, mediated by a company whose incentives are not yours. The layer underneath predates all of it. The thing that holds your files, drives your hardware, and arbitrates your attention was designed before any of this existed.
NexaCore OS starts from the opposite premise. If inference and intelligent agents are now primitives of computing, they belong in the kernel, next to processes and files, running on hardware you control. This post is the first in a series: the wide-angle view of what we are building, the choices behind it, how the AI works, and where the project actually stands today. Later posts go deep on each part.
Why a new operating system
Today's operating systems bolt AI on from the outside. Intelligence lives in a chat window or behind a cloud endpoint; the OS is a bystander. Ask a modern assistant to summarise your private notes, and those notes typically leave your machine to be read elsewhere first. That arrangement has three costs. Your data leaves the device to be useful. Your privacy becomes a policy you are asked to trust rather than a property you can verify. And the most important layer of modern computing ends up owned by a handful of companies.
We think the fix is structural, not cosmetic. Make the operating system the orchestrator of AI. Run inference locally by default. Reach for scale by federating with other machines rather than surrendering to a cloud. Enforce privacy in the protocol, so a misbehaving component can't produce valid traffic at all. None of that can be added later as a feature. It has to be the shape of the system from the kernel up.
What it is, and what it isn't
NexaCore OS is an independent open-source project: a from-scratch operating system built on a custom microkernel written in Rust. Not a Linux distribution, not a kernel fork, not a reskin of something that already exists. It has no token, no coin, and no blockchain; decentralization here is an engineering means, not an ideology and not a fundraising device. It is early, and we say so plainly throughout this series.
A microkernel, in Rust
The kernel does as little as possible. It handles memory, scheduling, typed message-passing between processes, the capability primitives, and the contracts to talk to hardware. Everything else runs in user space and communicates over IPC: filesystems, drivers, the network stack, the AI runtime. The payoff is a small trusted computing base. Less privileged code means less code that can compromise the whole system, and a surface small enough to reason about.
Between the kernel (Ring 0) and everything else (Ring 3) sits a frozen system-call ABI. The syscall numbers are fixed; the surface is a stable contract that user-space code and future forks can rely on. That stability is deliberate. An operating system meant to outlive its authors cannot keep moving its own foundations.
Capabilities instead of permissions
NexaCore OS replaces the familiar Unix permission model with capabilities. Every privileged action requires a capability token: a signed structure naming the action, the actor, the resource, and a time bound. Tokens are scoped, short-lived (minutes, not forever), revocable, and attenuable in the style of Macaroons: you can hand out a strictly weaker version of a capability you hold. The master signing keys live in a TPM or secure enclave. A component can reach only what it was explicitly handed, and only for as long as it was allowed. Ambient authority, the quiet source of so many privilege-escalation bugs, is not on the table.
Scripting the system, safely
Automation is where power tools quietly become footguns: a script usually runs with all of your authority, so a single careless line can do anything you can. NexaCore OS ships ncScript, a scripting language governed by an open improvement-proposal process and gated by the same capability model as everything else. A script receives exactly the capabilities it is granted and nothing more. Automating a chore no longer means handing a program the keys to the whole system. Small idea, large consequences. It gets its own walkthrough; for now, the syntax and examples live in the ncScript manual.
How AI actually works here
AI is a system service, exposed the way any other kernel-mediated resource is. A privileged user-space AI Runtime Service owns model lifecycle (loading, versioning, attestation), schedules inference across whatever accelerators are present, and validates every request. Programs reach it through system calls: invoke, stream, embed, classify, transcribe. Each call carries a capability token, and a call without a valid one is refused, exactly like any other privileged operation. Inference is not a network request to a stranger; it is a syscall the OS governs. Models are attested before they run: the runtime refuses to load a model whose signature it cannot verify, so a swapped or tampered model never silently executes.
By default it runs on your machine. The lowest tier performs inference entirely on the local device, with nothing leaving it. The reference direction for the models is mixture-of-experts: sparse activation, where only a couple of experts fire per token. That is how you fit capable models onto hardware people actually own. To be precise about the present tense: today that pipeline is a from-scratch transformer with GGUF model loading and a byte-level tokenizer, running from a Ring 3 process, verified under QEMU and Proxmox. The richer model and scheduling work is ahead, and this series will follow it.
Five agents, each in its own cage
Above the runtime, NexaCore OS boots exactly five system agents, and isolation between them is the whole point. Each gets its own set of capability tokens, its own key-value cache partition (flushed on every context switch), its own compute budget, its own sandbox, and its own stream in a system-wide tamper-evident audit log. The agents are:
- Orchestrator, the coordinator. It reads intent and dispatches work, but never executes system operations itself.
- Guidance, the assistant and educator. It explains, teaches, and translates the system into plain language.
- System Administrator, the technical operator. It can install software, manage drivers, and configure the system. It holds no capability to read your files.
- Security & Performance, the guardian. It watches for threats, enforces taint tracking, gates outputs, and in a high-risk mode can veto actions outright.
- Task, the worker. It does your actual work on your files. It holds no capability to install system software or touch system paths.
Notice the symmetry between the last two. The administrator can change the system but not read your data; the task agent can touch your data but not change the system. That boundary isn't a line in a manual: the compiler enforces it, expressed as capabilities. The Security agent boots first, so it is already watching when the others come up. You can read more on the built-in agents page.
Scaling without surrendering to the cloud
When a workload outgrows one machine, NexaCore OS scales outward in tiers rather than reaching for a datacentre. First your own device. Then a personal cluster of machines you already own. Then an opt-in federated mesh of other NexaCore OS instances. Commercial cloud sits at the very end, an explicit last resort you consent to per request, never the default path. Each step outward trades a little latency for a lot more capacity, and each is something you opt into rather than inherit.
The mesh is where the privacy engineering gets serious. Every connection begins with mutual hardware attestation: two nodes prove to each other, cryptographically, what they are running before any data moves. Payloads are sealed so that only the destination's secure enclave can open them, and each message must carry a proof that it follows the rules. A message that can't produce that proof gets dropped by every honest relay. It is peer-to-peer, and it is emphatically not a blockchain. The mesh protocol deserves its own post, and it will get one.
Privacy by construction
The phrase we keep coming back to is enforced by the protocol, not by policy. The goal is a system where certain guarantees hold by construction: personal data never appears in cleartext on the network, and no node can decrypt data that was not meant for it. Not because a rule forbids it, but because a non-compliant node cannot produce valid messages without breaking the underlying cryptography.
Several mechanisms carry that weight. Data types encrypted by default that cannot even be instantiated with plaintext personal data outside an attested enclave. Local tokenization that strips identifiers before anything is shared. Trusted execution environments that seal data to specific hardware. And, for prompt injection, the defining new attack of the AI era, a two-model design in which the planning model never sees untrusted content directly. We reason about all of this with formal threat modelling rather than intuition, enumerating attacker classes from the malicious local app to the curious cloud to the misaligned model. This, too, is a series of its own.
What runs today
Honesty about maturity is part of the design. NexaCore OS is in Phase 1, released as v0.3.0-alpha.1. The kernel boots bare-metal on x86-64 via UEFI and brings up an interactive graphical desktop. It runs multiple CPU cores, drives NVMe, VirtIO-net, and e1000e hardware from user-space drivers, and serves that from-scratch AI inference pipeline from a Ring 3 process. All of it verified under QEMU and Proxmox virtualization (bare-metal bring-up on physical machines is in progress). The codebase is 79 Rust crates, 6,700+ automated tests, 70 system calls, and 100% Rust with no C runtime.
Equally, much is still ahead. The federated mesh, the full agent framework, and the concrete hardware trusted-execution backends are scaffolded and advancing rather than finished. Every post in this series will be clear about what works, what is mocked, and what is still a specification. You can always check the project status for the current line between the two.
Open by design
NexaCore OS is Apache-2.0, and its protocol specifications are public domain (CC0). The source is public: the full workspace lives on GitHub, where you can read it, build it, run it, and open a pull request. Forks are first-class by design: the protocol is the contract, and any implementation that speaks it interoperates on the same mesh. Openness here is enforced by license and architecture, not worn as a badge.
What comes next
This was the overview. The rest of the series goes one layer at a time: the microkernel and its ABI, the capability model, the agent architecture, the mesh protocol, the privacy primitives. Each post comes with an honest update on where development actually stands. To follow the build, subscribe by RSS or on the devlog; for the architecture in depth right now, start with the technology deep dive.
Everything in this post is checkable: the code, the tests, the status page, the line between what runs and what is still a spec. Hold us to it.
— Matteo Sala, founder