Runix Lab has one goal, and it fits in three words: rebuild AI Unix. We want enterprise AI to run on an operating system that is efficient, stable and built for the companies that have to sign for it, instead of on the pile of scripts, keys and one-off integrations most teams run on today. This post explains what we mean by that, what we have built so far, and what is still in development.
Why Unix
Unix was written at Bell Labs at the end of the 1960s, and programs written for it decades ago still run. That is not an accident of hardware. It rests on a handful of ideas that turned out to be right:
- Everything is a file. Disks, devices and streams are all read and written the same way, so a program does not need to know what is behind a path.
- Small tools, joined by pipes. Each program does one job, and the output of one becomes the input of the next, where you can inspect it.
- A kernel that does the work, and manages the machine on behalf of every program that runs on it.
- One call interface. Programs ask the kernel for what they need through system calls, and POSIX later wrote that interface down, so the same program could run on machines from different vendors.
- Userland. Applications sit on top and can change freely, without touching anything beneath them.
None of those ideas is about a particular machine. They are about keeping the layers of a system honest with each other, so that each can be replaced without breaking the rest.
What enterprise AI is missing
Look at how most companies run AI in production and you find the opposite. Training data is copied out of the bucket onto local disks before every job, because object storage is not a file system. Data cleaning lives in scripts that one person understands and nobody can audit. Every model provider comes with its own SDK, its own keys and its own ways of failing, and they are wired into the application directly. The models themselves are rented, never owned, even for the narrow, repeated tasks where a smaller model of your own would do. And applications are written against one vendor's API, so changing any layer beneath them means changing them too.
The cost shows up in the same places every time: GPUs that wait on storage, outages that start with someone else's bad hour, and security and procurement reviews that stall because nobody can say where the keys and the data actually go.
Five layers, one idea each
We are rebuilding those ideas as five layers. Each one is a product a team can use on its own, and each is built to hand off to the layer above it. The statuses are literal.
- Everything is a file: Runix FS, in early access. A POSIX file system and a multi-tier cache over the object storage you already run, so training jobs, inference servers and agents read datasets, checkpoints and weights through one path. It is built on Curvine, an open-source CNCF Sandbox project, and deployed into your own cloud account.
- Small tools, joined by pipes: Runix Pipeline and Runix Data. Pipeline, in development, is the tooling: the six stages from ingestion to delivery, each one leaving something you can inspect. Data, in early access, is the service built on it, with the rules that differ from one field to the next: code, which is our focus, then finance, cybersecurity, legal, embodied AI and AI for Science.
- A kernel that does the work: Runix Models, in early access. Open-weight models fine-tuned on your own data, evaluated against the model you run today before anything ships, and served on dedicated capacity.
- One call interface: Runix Router, in early access and running traffic. One OpenAI-compatible API in front of every model provider, with central key custody, per-key quotas and failover that fires mid-request, so the application above it does not need to know which provider answered.
- Userland: Runix Code and Runix Comic, both in development. A coding agent that works in your repository under review gates, and a studio that takes a comic drama from script to published episode.
Underneath all five sits the part we do not sell: GPUs, power and cloud capacity. The stack runs on the compute you already have and replaces none of it.
What efficient, stable and enterprise-grade mean here
Those three words are easy to write, so here is what each one means in terms of what the layers already do.
- Efficient. GPUs read from a cache instead of waiting on the bucket. Requests are routed by cost and health. A small tuned model takes the jobs a large general one does not need to do.
- Stable. Failover between providers happens mid-request with streaming preserved. File-system metadata is replicated with Raft. Every data stage leaves something you can inspect, so a bad answer can be traced back to the record that caused it.
- Enterprise-grade. A registered US company to contract with, with an MSA and DPA on request. Provider keys held centrally, not scattered across repositories. Deployment into your own cloud account where the data has to stay. And your content is never used to train a model you did not ask for.
Just as plainly, what we do not claim: we hold no SOC 2, ISO 27001 or PCI certification, there is no published service level during early access, and a product marked in development is not something you can buy yet.
Where to start
You do not have to adopt the whole stack. Most teams start at one layer: the gateway, when the problem is keys, contracts and provider outages; the data layer, when the problem is what the model learns from; or the file system, when GPUs are waiting on storage. Tell us which problem you have and we reply within one business day, from the engineers who build and run it.