Runix Lab describes what it builds as five layers: agents, gateway, models, data and infrastructure, drawn on top of the compute the customer already owns. Each line between two AI infrastructure stack layers is drawn where an interface can be written down and the thing beneath it replaced without the thing above noticing, the test Unix applied to files, pipes, the kernel and system calls. This post explains where each line comes from, why each layer must stand alone, and what the diagram cannot show.
Where the lines come from
Unix lasted because its layers were honest with each other. A program opened a path without knowing whether a disk or a terminal was behind it. A tool read standard input and wrote standard output, so any two could be joined. The kernel did the work for every program, and POSIX later wrote the call interface down so one program could run on machines from different vendors. Userland sat on top and changed freely. The original paper, The UNIX Time-Sharing System (Ritchie and Thompson, Communications of the ACM, 1974), still states the idea most clearly.
The test behind each boundary is the same: can the interface be written down, and can the implementation below it change without the code above it changing? Applied to an AI system in production, it finds five such interfaces: a path, a stage boundary, a served model, one API, and the program on top. That is why five layers, not four or seven. Rebuild AI Unix gives the mission; this post gives the geometry.
Below all five sits Layer 00: the customer's own GPUs, cloud capacity, object storage and Kubernetes. Runix sells none of it; the stack runs on it and replaces none of it.
Five AI infrastructure stack layers, one Unix idea each
Each layer rebuilds one idea, and each is a product with a literal status.
- Everything is a file: Layer 01, Infrastructure. Runix FS, in early access, puts a file system and a multi-tier cache over the object storage a team already runs, so that training jobs, inference servers and agents read datasets, checkpoints and weights through one path, via a FUSE mount, a Hadoop-compatible client, SDKs or a Kubernetes CSI driver. It is built on Curvine, an Apache 2.0 project in the CNCF Sandbox.
- Pipes: Layer 02, Data. Runix Pipeline, in development, is six stages, ingest, clean and dedupe, structure, mask, report and deliver, each leaving something you can inspect, which is what a pipe gave you: one stage's output is readable before it becomes the next one's input. Runix Data, in early access, is the service built on it, with the rules of six domains and code as the focus.
- The kernel: Layer 03, Models. Runix Models, in early access, tunes open-weight models on the customer's own data, evaluates them on held-out sets against the model the customer runs today, and serves them single-tenant behind an OpenAI-compatible API: the kernel does the work, and here it is a model you commission rather than rent.
- One call interface: Layer 04, Gateway. Runix Router, in early access and running traffic, is one OpenAI-compatible API in front of every provider, with central key custody, per-key quotas, and failover that fires mid-request with streaming preserved. The application does not learn which provider answered, as a program does not learn which disk it read.
- Userland: Layer 05, Agents. Runix Code and Runix Comic, both in development, are independent agents for one domain each, with their own harnesses; they sit on top and change freely, and Router is optional in front of their model calls.
Why each layer must be usable alone
A Unix tool is useful by itself; the pipe is a bonus. The same rule holds here as a design constraint: a layer that only works when the layers around it are also bought is a bundle, and a bundle hides which part is actually good.
It shows up in three places. Each product has its own interface, written down: a mount or an SDK, a stage with inspectable output, an API, a diff in a repository. Each has its own price, per deployment, engagement, project, token or plan, not a share of a platform fee. And each has its own status, which is why the statuses differ: four of the seven products in early access, three in development, none described as more than it is.
The handoffs are optional by construction. A model tuned by Runix Models can sit behind Router next to hosted providers, or be called directly. Runix Code can route its model calls through Router, or not. Most teams start at one layer, where their problem is.
The two paths through the stack
Layers are a static picture; what moves through them are two paths, and the stack overview draws both. The request path runs top down: an application or agent calls Router, which sends the request to a hosted provider or a model tuned by Runix Models. The data path runs bottom up: raw material is read from the bucket through Runix FS, cleaned in Pipeline's stages, given a domain's rules by Runix Data, and lands as training and evaluation sets for Models.
The paths meet at Models, where the kernel analogy earns its place: a model is both what a request runs on and what the data path produces. Keeping the paths separate is the pipe idea applied across layers: cleaning data differently does not change how a request is routed, and a provider's bad hour does not reach a training job.
What the AI infrastructure stack layers leave out
A layered diagram is a claim about interfaces, and it is silent about things that decide whether the system works.
- Compute and energy. Layer 00 is a line on the diagram, but it is the largest cost in the system and the part Runix does not sell; the diagram says where the stack stops, not how much GPU a team needs.
- Evaluation. There is no evaluation layer, because evaluation cuts through every layer: Data splits evaluation from training by source, Models measures against the model the customer runs today, and a model change behind Router is only safe if someone watches the signals that move when it does harm.
- Security and compliance. Key custody, data terms, masking and retention each live inside a layer, but the review that asks about them runs across all five.
- The seams. The clean lines are where the hard engineering is: a file-system mode that syncs to the bucket asynchronously is eventually consistent, failover changes which model answered, and a stage boundary is only auditable if someone reads what the stage left.
- People and time. The diagram implies an order; adoption does not follow it. Three of the seven products are in development, and there is no published SLA during early access.
Runix Lab is the brand of Runix AI Inc, and the five layers are its answer to what an operating system for enterprise AI should consist of. The company page lists each product with its literal status and the terms a team would contract under; the layers are a map of the work, drawn to be adopted one at a time.
Questions this raises
Do I have to adopt all five layers?
No. Each layer is a separate product with its own interface, price and status, and most teams start at the one where their problem is: the gateway, the data layer or the file system.
What sits under Layer 01?
Layer 00: the customer's own GPUs, cloud capacity, object storage and Kubernetes. Runix sells none of it; the stack runs on it and replaces none of it.
Which layers are available today?
Runix Router, Runix Models, Runix Data and Runix FS are in early access; Runix Pipeline, Runix Code and Runix Comic are in development. The statuses are literal.