EngineNumbersExactControl CentreAtlasLabTalk to us
Barx Compute · local inference engine

Big models.Small machines.

Barx streams a mixture-of-experts model from your SSD instead of holding all of it in memory. An 80-billion-parameter model, a 45 GB file, runs in 5.5 GB at 18–23 tokens a second on the CPU alone. And it gives the same answer, bit for bit, however your prompt arrives.

Evaluate Barx See the numbers
80Bparameters, about 3B active per token
5.5 GBmemory, counted honestly, file cache included
18–23tokens a second while writing, CPU only
0.26 sto the first token when it reads as you type

Qwen3-Next-80B-A3B, 4-bit. Apple M5 Pro laptop, 24 GB. Measured November 2026.

From 45 GB on disk to 5.5 GB in memory

What we build

One engine.
Everything it makes possible.

Barx Engine

Runs models larger than your memory. Experts stream from storage, the hot ones stay in a counted budget, and the next ones are fetched before they are needed.

How it works

Exact by construction

Full-precision attention and kernels that reproduce the reference result bit for bit. The answer never depends on how the prompt was read.

Why it matters

Barx Control Centre

See what is using your memory, storage and processor. Fix it in one click. Undo it in one click.

Take a look

Atlas

A private assistant that runs on Barx. It works with the network off, and every answer comes with a receipt.

Meet Atlas
Barx Engine

The model lives on your SSD. Only what’s needed visits memory.

A mixture-of-experts model uses a small part of itself for each token. The 80B model has 512 experts in every layer, and each token wakes about ten of them. Barx treats memory as a cache for those experts, not as a home for the whole model.

  • A counted expert budget2–4 GB, sized to the machine. Everything is counted: the engine, its workers, and the model’s pages in the file cache.
  • Fetched before it’s neededBarx predicts which experts come next and reads them while the cores are still busy, so the SSD and the processor work at the same time.
  • Prompts read 3.4× fasterOur own batched 4-bit kernels for Apple silicon: a 5,196-token document went from 51 to 175 tokens a second, with identical results.
  • Speaks the Ollama APIChat, generate, embeddings, model pulls and the rest. Apps that already talk to Ollama connect to Barx unchanged.
One layer, live · 512 expertsIllustration
0tokens
0%served from memory
0fetched from SSD
Already in memory Fetched from SSD In the budget Shared expert
Numbers

Measured, not modelled.

Same model file, same settings, same machine. Barx against stock llama.cpp, the engine Barx is built on, with the model file dropped from memory before every run.

Barx vs stock llama.cpp

Qwen3-Next-80B-A3B · same 45 GB file · CPU only · cold start

Writing speed

≈ 9× faster

tokens per second across four writing tasks · higher is better

Barx
17.6–22.8
llama.cpp
1.7–2.6

First token, new chat

16× sooner

seconds · lower is better

Barx
6.8 s
llama.cpp
111 s

Memory used

43% less

GB, process plus model pages in the file cache · lower is better

Barx
5.5 GB
llama.cpp
9.6 GB

How soon it starts talking

Barx, 80B model · first token in four situations

  1. Typed ahead0.26–0.34 s

    Barx reads your message while you type it. Enter starts the answer.

  2. Warm0.66–0.94 s

    The chat is loaded and you press Enter.

  3. Restored1.6 s

    A conversation’s state comes back from disk.

  4. Cold7.9–8.6 s

    The model was just loaded and its instructions are new.

0.1 s1 s10 s
169 tok/s

Long documents

Reading a 5,196-token document on the CPU, with the model streamed from the SSD.

63%

Expert reads served from memory

With a 3 GB expert budget, on recorded traces. The rest are fetched from the SSD ahead of time.

Level

Where the model fits in memory

On a small model that already fits, Barx runs within a few percent of established runtimes. The gap opens when the model outgrows the machine.

Reference run, 6 November 2026, with our benchmark kit. Apple M5 Pro laptop, 24 GB · 8,192-token context · greedy decoding · identical engine settings · model file evicted from the file cache before each engine starts. Ratios compare range midpoints. Measured by us; independent reproduction is under way.

All at once In pieces As you type Identical bits
One question, three ways of reading itSame answer
Exact

Same question. Same answer. Every way you ask it.

Most engines change their arithmetic with batch size, thread count and how a prompt is split, so one question can come back worded differently. Barx doesn’t. Attention runs in full precision for every batch, and every fast kernel reproduces the reference result exactly.

~1,000×closer to exact float64 math: error 1–⁠5×10−6, was 2–⁠6×10−3
0 of 234,108values that differ between our fast batched kernel and the reference
Same speedfull precision cost nothing measurable on the 80B model
Barx Control Centre

Your machine, explained.
Every fix, undoable.

A Mac app that runs the engine and shows what is using your memory, storage and processor, in the same units Activity Monitor and Finder use. Each fix is one click, logged with what changed after it, and reversible.

Barx
barx.

Overview

Everything at a glance

Memory14.9 GBof 24 GB · pressure normal
Storage212 GBfree of 994 GB
EngineRunning80B model · 5.5 GB
Last answer21.8tokens a second
Chrome is holding 5.1 GB42 tabs · 9 helper processes
5.1 GBShow tabs
Old build cachesOwned by Xcode · rebuilt when needed
18.4 GBReview
Ask Nucleus: “why are my fans loud?”Coming soon

Interface preview with example data.

Fixes you can take back

Moves to the Trash are recorded item by item, so Put Back always works. Every fix is logged with what was measured after it.

Honest units

Memory as Activity Monitor counts it, storage as Finder counts it. Swap traffic right now, not swap in use, is what slows a machine, so that’s what we show.

Ask Nucleus

Describe a problem in plain words and get the fix. It will run on Nucleus, our own model, on your computer.

Atlas

An assistant that runs where you are.

Atlas is our assistant, built on Barx. It answers from your own computer, works with the network off, and shows its work.

  • KIRAThe assistant inside Atlas. It knows the machine it runs on and plans around it.
  • GlassBox receiptsEvery answer carries a record of what ran, what it used and what changed, with undo.
  • Endless chatOld turns fold away and the conversation’s state is kept on disk, so a long chat comes back in about 1.6 seconds.
  • Answers as you finish typingAtlas hands your message to Barx while you write it, so the reply starts about a third of a second after Enter.
AtlasOn this computer
What’s the difference between memory pressure and memory used?
Ran locallyFirst token 0.31 s21 tok/sNo sources needed80B · Barx
Underneath

The record lives outside the model

Your work is kept as typed, versioned, content-hashed state in a local store, not inside one vendor’s chat transcript.

Models interchange

Context is compiled, not copied

Before a model runs, Barx compiles the context it needs into a packet for that engine. Switch models and nothing is lost.

Checked before recorded

Evidence comes first

Every change is validated for authority, evidence, freshness and grounding before it becomes part of the record.

A model can propose anything.
It cannot assert what the evidence doesn’t support.

In the lab

What’s next, with its status.

Nothing here has shipped yet. We show where each piece stands, because the targets only mean something if you can see how far away they are.

In testing

The GPU’s tensor units, the CPU’s exact bits

Prompt multiplies move to the GPU’s int8 tensor units while every result stays identical to the CPU’s.

159 → 281 tok/slong document · every answer unchanged
Target

A whole assistant in 6 GB, no GPU

Assistant, model and engine together in about 6 GB on a laptop without a graphics processor, still giving strong answers.

6 GBeverything counted, file cache included
Mission

Trillion-parameter models on an 8 GB laptop

CPU only. Far from reached today, and the bar doesn’t move to make it easier.

≤ 2 s · ≥ 10 tok/sfirst token · writing speed
In design

Nucleus, our own model

Small for every token it writes, built for the jobs it is chosen for rather than everything at once. It will power Ask Nucleus.

Ask Nucleusin the Control Centre, on your computer
How we work

Fast is easy to say.
We’d rather show it.

Private by construction

No telemetry, no cloud account, no background upload. Models run on your hardware.

Every number has a run

Each figure here comes from a logged run, and we built a benchmark kit so others can check them on their own machines.

Exactness is kept, not toggled

A change to the engine must give the same bits at every batch size and thread count, or it doesn’t go in.

Failures stay on the record

Experiments that disproved their own idea are kept, with the reason. So are features we measured and chose not to ship.

Memory counted honestly

When we say 5.5 GB, that includes the engine, its workers and the model’s pages in the file cache. Nothing hidden in another process.

Credit where it’s due

The engine builds on llama.cpp and ggml. Streaming experts from flash was studied before us, including Apple’s “LLM in a Flash”.

Build on Barx.

We license the engine to teams shipping local AI: in apps, on devices and across platforms. Evaluations are open: start with our benchmark kit and check every number on this page on your own hardware.

karthik@barxcompute.com Back to the numbers