altAI

Capacity, from machines that already exist.

An open-weight model split across several computers, behind one OpenAI-compatible endpoint. A machine that cannot fit a model scores zero, not slow. Several of them together can serve it.

Download

The engine is inside. No terminal, no Python, no Docker, no address to type — the network's address is already in the app. You will need a join token; the network is invite-only while it is this young.

Apple Silicon

M1 and later · macOS 12+

Download

14.9 MB · sha256 bc7e1e62f2654fca…

Intel

x86-64 · macOS 12+

Download

15.0 MB · sha256 01862dbb67338d3c…

Windows

x86-64 · engine inside

Download

22.5 MB · sha256 03722065d6e12c20…

Linux

no engine inside — see below

x86-64 arm64

7.2 / 7.4 MB · sha256 fb84c8ebda1560fb… / ddfd02bcaa3dc4e6…

xattr -dr com.apple.quarantine "/Applications/Altai Node.app"

export ALTAI_JOIN_TOKEN=<your token>
open "Altai Node.app"

Unsigned, so macOS asks once — that is the xattr line. Both builds run on macOS 12 and later, measured rather than claimed: every library in each archive is built against that floor. The Intel engine gives up Accelerate’s BLAS to get there, which makes prompt processing slower on an Intel Mac — there is no Metal on those to take over.

Windows: unzip, double-click altai-node.exe, and choose More info → Run anyway — it is not code-signed yet. The engine is a CPU build of llama.cpp and needs the Visual C++ Redistributable, which most machines already have; the folder’s read-me says what to do if yours does not. Linux: the node runs and joins, but the archive carries no serving engine — no published llama.cpp build has the RPC backend splitting needs, so it must be built from source and placed beside the binary. The README in the archive says how. Both come from one CI run, built 1 Nov 2026.

You do not have to lend a machine to use the network. There are two ways in, and neither asks anything of your hardware — the model runs on somebody else’s. You will need a word from us either way, because the network is invite-only while it is this young.

In your browser

any OS · nothing to install

Open it

type the word, start talking

As a local endpoint

macOS · Windows · Linux

Same download

not in the current build — see below

The browser page is the whole thing for most people. It speaks to the network directly, so there is nothing to keep up to date and nothing running on your machine when you close the tab.

The local endpoint is for coding tools. Continue, Aider and anything else that speaks the OpenAI API need a web address on your own machine to point at — a browser tab cannot give them one. So the app runs with contributing switched off and serves http://127.0.0.1:18090/v1 for them: no model downloaded, no layers held, no work taken on. It is the same download as the other tab, with one switch flipped.

Not in the build you can download today

The switch is written but has never been compiled, so the archives on the other tab still only know how to contribute. Use the browser page until a build says otherwise. We would rather say this than let you download something and find the option missing.

Whichever way you come in, the machine that answers reads your prompt as ordinary text — it has to, in order to answer. Nothing here is end-to-end encrypted and we will not imply that it is. What is true: you can see which machine served you, and a stage in a group never sees a prompt at all.

What a token gets you

An ordinary token can only ever make your machine a stage: it runs a block of layers and nothing else. It never downloads a model, it is reached only by its own group's head, and nothing on the internet can dial into it. Being trusted to drive a group is a separate privilege the token has to carry, and we do not hand that out.

Architecture

Who does what

Three roles, and any machine can hold any of them. Which one you are offered is decided by what you choose to contribute — the coordinator fits the model to the memory you declared. It never holds model weights and never sees a group’s internal traffic.

stage

Lowest bar. Holds a block of middle layers and runs them for every token. Never downloads a model file and never holds a usable copy of one — its head pushes the tensors it needs. Sees hidden states, never a prompt.

head

Drives a group. Holds the embedding and output layers plus its own block, emits every token, and signs for what it served. Needs the model file on disk. Because it reads prompts in plaintext, this one is a privilege rather than a size — see below.

whole

Highest bar, best performance. Holds a complete model and serves a request start to finish, with no hop between machines and so nothing of the per-token round trip a group pays.

Why head is not simply the next size up

A head receives each prompt and completion in plaintext and signs the receipt for it. Capacity decides what a machine can be; the invite code decides what it is allowed to be. A machine large enough to head a model may still be offered only stage, and the page will say so rather than leave you guessing. A stage needs no such trust, which is why it is the role anyone can take today.

Where this goes next — a stage earns twice

Memory is only one of the two scarce things a stage has. The other is simply being another way in. Today every request enters through one door — ours. The plan is for a stage to also act as a connection gateway, so the network has many doors instead of one, and so someone behind a home router has a route in that does not depend on us being reachable.

A gateway forwards traffic it cannot read. The conversation is encrypted end to end to the machine that answers it; the gateway carries sealed bytes and holds no key to them. That is not a compromise — it is the only version that keeps the promise above, because producing a word requires parts of the model a stage deliberately does not hold. A gateway that could answer you would be a head wearing another name.

Which door you come in by is decided by who has room, never by where you are — we do not look up anyone's location and do not need one. None of this is built yet.

How a request is served, and how a client without a machine gets in Your app any OpenAI client /v1 coordinator assigns roles · routes holds no weights ONE GROUP — ONE UNIT OF CAPACITY head embedding + output its own layers emits the tokens stage layers 15–28 no model file nothing dials in stage layers 29–40 …as many as the model needs gateway forwards, cannot read HIDDEN STATES ROLE ASSIGNMENT whole fits the model alone also one unit of capacity Requests reach a head, or a whole node. Today a stage is reached only by its own head. A gateway would be dialled by clients too — and would still answer none of them. A SECOND WAY IN — NOT BUILT YET thin client any OpenAI client contributes no machine CLIENT ↔ HEAD SEALED SESSION The sealed line passes through the gateway, which would hold no key and answer nothing. Assignment would be by spare capacity, never by location; the coordinator would carry none of it.
Layer numbers are from a real 40-layer split. A stage holds only its own block, so a laptop can join a group serving a model many times larger than it could hold. The sealed line is drawn through the gateway rather than stopping at it, and carries no arrowhead there: the session is encrypted end to end to the head, the gateway holds no key to it, and that is the whole reason anyone would be willing to run one. Either stage could be the gateway; one is drawn doing it. The thin client and the gateway are designed, not built — nothing on that path runs today.

The argument

Why capacity, and not speed

The binding constraint on a frontier-class model is memory, not FLOPs. A fast GPU with 24 GB cannot hold a 600 GB model at any clock speed. Twenty of them can.

And capacity is what is scarce. Datacenter servers are supply-constrained — vendors say so in their own filings and expect it to persist — while the memory in workstations, gaming machines and office hardware is already built, already powered, and mostly idle. It is not waiting on a fab.

So the aim is not to beat a hosted API on price or latency. It is to serve a model that otherwise could not be served at all, for the people who need it, on machines that already exist.

The target

Where this is going

Sparse mixture-of-experts models — DeepSeek-V3, Kimi-K2 — are the problem this exists to solve. They are where the memory wall is worst and where it is most tractable: only a fraction of the experts fire for any token, so the weights that must be resident are far smaller than the weights that must be available.

The route is pipeline stages across a low-latency regional group, each stage running its own block of layers with that block's experts offloaded to ordinary system RAM. Experts never cross the network. Only hidden states do — on the order of 16 KB per token per hop. That is what makes a machine with plenty of RAM and a modest GPU useful, instead of only machines with datacenter cards.

This route does not run yet

In the engine we use, expert offload and pipeline parallelism are currently mutually exclusive — switching on offload disables the pipeline, verified in the engine's own source. The upstream change that would lift it is open and unmerged. Until then the sparse frontier is the design target and not a capability, and nothing here should be read as saying otherwise.

State

What runs today

worksOpenAI-compatible endpoint Tool calls, streaming, usage, error shapes. The compatibility suite is the project's main asset.
worksA model split across two processes A 14B model served through a head and a stage, each holding half the layers, talking over the real tunnel. Both halves were on one machine. Two separate Macs have formed a healthy group but have not yet served a token — the cause is found and fixed and the run is pending, and until it has happened this row says so.
worksJoining over the internet A node registering from another network, with a join token.
worksSleep and rejoin A laptop closes, the group re-forms, the laptop comes back.
not builtSigned receipts Responses carry a receipt id that currently refers to nothing. The next large piece of work.
not yetAnyone joining safely See the notice at the top. This is the gate on opening the network.

Roadmap

What comes next, in order

Intentions, not dates. Each one is listed because something concrete blocks it, and the blocker is named.

The shape we are building toward

Ten machines of 64 GB, in one metro, serving a DeepSeek-V3-class model at roughly 10–20 tok/s. A target, not a result — nothing like it has been run.

Two numbers in that sentence are not taste. Per-token time for one person waiting is W/B + crossings × (c + L) — and the first term does not divide by the number of machines. A stage reads its share, but every stage runs in sequence to make one token, so the same bytes get read either way. Splitting relocates the work; it does not shrink it. There is no optimum group size, only a floor: the smallest group whose memory holds the model. Every machine past that adds capacity and latency, never speed.

Which leaves the crossings, and those are the whole game. Each boundary costs about a millisecond of protocol — measured — plus the network round trip, and the network is the larger number by far. So distance is the lever, not machine count. Ten machines a metro apart land in the target range; the same ten spread across a continent do not. And availability compounds: ten nodes at 99% give 90%, forty at 95% give under 15%.

So it is ten large machines close together, not forty small ones far apart. More-and-smaller is the intuitive answer and the arithmetic says it is wrong. Read “64 GB” as a floor on capacity — what sets speed is memory bandwidth, where two machines of the same size can differ sixfold.

Corrected 4 Nov 2026. This box previously derived an optimum group size from W/(N·B) + N·L — sound algebra on the wrong quantity, since that form describes aggregate throughput under load, not one person waiting. Our own measurements had contradicted it for a week before the algebra was checked. The figures above are arithmetic from measured inputs, not results: nothing of this shape has been run.

the gateNo machine needs the whole model file A head loads the complete model from disk today and pushes each stage its tensors. For a 400 GB model that is a floor no number of extra machines lifts, and it also decides whether a failed head can be replaced at all — a stand-in must already hold the file. Needs per-shard fetch, which means patching the serving engine: its RPC server receives tensors and cannot read them. Solved in the open by others; the cost is carrying a fork.
nextVerify several tokens per trip Every token currently pays the full round trip through the group. Speculative decoding proposes a short run of tokens cheaply and has the group confirm them in one pass, so the trip is paid once per several tokens instead of once each. It is the only improvement here that gets larger as the network gets worse, which is why it matters most to us. The models we are aiming at carry a predictor built in for exactly this, but the engine we use discards it at conversion time and says in its own source that it does not support it yet — so the version available today needs a second small model running on the head, paid for in memory and in time before every batch. How often its guesses are accepted is the number this all rests on, and we have not measured it.
nextPass work stage to stage The head drives everything today, so each boundary is crossed twice — out to a stage and back — and a group of ten pays eighteen crossings per token instead of nine. Handing work straight along the chain halves that. It means changing how the serving engine distributes work, which is why it is listed after the cheaper wins rather than before them.
designingStages as connection gateways A stage has two scarce things and memory is only one — the other is being another way in. Every request today enters through a single door, ours. A stage should also be a door: a route into the network for people who want to use it without running a machine, and one that still works when ours is unreachable. The gateway forwards traffic it cannot read, because producing a word needs parts of the model a stage does not hold; anything that could answer you would be a head under another name. Which door you come in by depends on who has room, never on where you are — we do not look anyone's location up and do not need it.
nextGroup by measured distance Groups form from what a machine declares about where it is. Since distance is the term that dominates everything above, it should form them from round trips actually measured between the machines. The protocol already carries the field; nothing fills it in.
nextMore than one group per model One group serves a model and every machine that joins afterwards is idle, because the scheduler forms a second group for nothing. Until that changes, capacity does not compose past the first group — which is what turns a group into a network.
nextOne machine, several models A machine holds one role and serves one model. An operator with memory to spare should be able to host several and earn from whichever is busy. Serving two whole models already works in the engine; contributing a slice to two split models does not.
designingHeads with something at stake A receipt is an attestation, not a proof: a dishonest machine can sign a false one. Making the machine that signs put up a bond gives the attestation teeth. The honest limit, stated plainly: you can prove a machine was absent, and you cannot yet prove it answered wrongly — so a bond covers availability, not correctness.
designingRecovering from a lost head A group already re-forms around a failure without anyone intervening. What is missing is a term a returning machine can be refused on, and a way to rebuild only the lost part of a conversation instead of starting it again. Requests in flight when a head dies are failed, deliberately: splicing half an answer onto another machine produces text no model generated.
the targetSparse frontier models DeepSeek-V3, Kimi-K2 class. Not blocked where we thought: with enough machines the model fits across their memory and the engine’s offload restriction never applies. The real blocker is the first item on this list.
parkedCPU-only nodes A machine with many cores, a lot of RAM and no GPU is the machine the sparse route wants. Renting that capacity to run other people’s code is not what we will do: the only thing such a machine has that a datacentre does not is a home IP address, and that is worth far more to abuse than to anyone legitimate.

Limits

What it does not claim

It does not serve frontier models today. What has actually run is a 14B open-weight model split across two Macs; the near-term target is 32B–70B dense. The sparse-frontier ambition above is the problem being worked on, not a description of what you would get this morning.

It is not cheaper than a hosted API. At the speeds a pipeline across several machines runs, electricity alone costs more per token than the market price of a hosted model. The argument is capability, not price.

A receipt will be an attestation, not a proof. When they exist, a receipt will say that a node asserted it produced an output. A dishonest node can sign a false claim, and nothing here will imply otherwise.

Operators

Running a node

One file, opened. It profiles the machine, proposes how much to contribute, opens a page in your browser, and joins. No terminal, no Python, no Docker, no address to type. You set the ceilings; the coordinator never asks for more than you allowed.

export ALTAI_JOIN_TOKEN=<the token you were given>
open "Altai Node.app"

A stage downloads nothing — its head sends it the tensors for its own layers. Only a head or a whole node needs the model file on disk.