Tiny en­gine, im­mense model. Run GLM-5.2 (744B-parameter MoE) on a con­sumer ma­chine with ~25 GB of RAM — in pure C, with zero de­pen­den­cies, by stream­ing ex­perts from disk.

$ ./coli chat 🐦 col­i­brì v1.0 — GLM-5.2 · 744B MoE · int4 · stream­ing CPU ✓ pronto in 32s · res­i­dente 9.9 GB › ciao! ◆ Ciao! 😊 Come posso aiu­tarti oggi?

The idea

A 744B Mixture-of-Experts model ac­ti­vates only ~40B pa­ra­me­ters per to­ken — and only ~11 GB of those change from to­ken to to­ken (the routed ex­perts). So:

the dense part (attention, shared ex­perts, em­bed­dings — ~17B params) stays res­i­dent in RAM at int4 (~9.9 GB);

the 21,504 routed ex­perts (75 MoE lay­ers × 256 ex­perts + the MTP head, ~19 MB each at int4) live on disk (~370 GB) and are streamed on de­mand, with a per-layer LRU cache, an op­tional pinned hot-store, and the OS page cache as a free L2.

The en­gine is a sin­gle C file (c/glm.c, ~2,400 lines) plus small head­ers. No BLAS, no Python at run­time, no GPU re­quired (an opt-in CUDA tier for pinned ex­perts ex­ists — see be­low).

What’s im­ple­mented

Faithful GLM-5.2 (glm_moe_dsa) for­ward — val­i­dated to­ken-ex­act against a trans­form­ers or­a­cle (teacher-forcing 32/32, greedy 20/20 on a tiny-ran­dom model with the real ar­chi­tec­ture).

MLA at­ten­tion (q/kv-LoRA, in­ter­leaved par­tial RoPE) with com­pressed KV-cache: 576 floats/​to­ken in­stead of 32,768 (57× smaller — GLM-5.2 has 64 heads and no GQA).

DeepSeek-V3-style sig­moid router (noaux_tc, rout­ed_s­cal­ing_­fac­tor), shared ex­pert, first-3-dense lay­ers.

Native MTP spec­u­la­tive de­cod­ing — GLM-5.2′s own multi-to­ken-pre­dic­tion head (layer 78) drafts to­kens that the main model ver­i­fies in one batched for­ward. The head must be int8 (the con­verter does this by de­fault): at int4 draft ac­cep­tance col­lapses to 0 – 4% and spec­u­la­tion never en­gages; at int8 it’s 39 – 59% ac­cep­tance, 2.2 – 2.8 to­kens/​for­ward (community-measured, #8). Lossless — and stays loss­less un­der sam­pling via re­jec­tion sam­pling. Honest caveat from the same mea­sure­ment: on a cold cache each ver­i­fied draft routes to ex­tra ex­perts (~660 → ~1100 ex­pert-loads/​to­ken), so spec­u­la­tion can be a net time loss un­til the cache/​pin warms up — the adap­tive guard and DRAFT=0 are there for that.

True sam­pling — tem­per­a­ture + nu­cleus, de­faults tuned for int4 re­al­ity (0.7 / 0.90; the of­fi­cial 1.0 / 0.95 sam­ples quan­ti­za­tion noise from the tail).

Integer-dot ker­nels (Q8_0-style int8 ac­ti­va­tions, AVX2 mad­dubs): int8 mat­muls 1.4 – 2.5× faster (119 GFLOP/s mea­sured), int4 1.8× in batch — rout­ing de­cided per shape by mea­sure­ment (int4 sin­gle-row stays f32: it mea­sured slower).

MLA weight ab­sorp­tion (DeepSeek trick) for de­code: no per-to­ken k/​v re­con­struc­tion — the query ab­sorbs kv_b, con­text is pro­jected af­ter at­ten­tion. Validated ex­act: TF 32/32 and gen­er­a­tion 20/20 with ab­sorp­tion forced every­where.

Async ex­pert reada­head: while one block of ex­perts is be­ing mul­ti­plied, the ker­nel is al­ready read­ing the next (WILLNEED).

Quantization ker­nels: int8 / packed int4 / packed int2, per-row scales, AVX2, de­quant-on-use. Packing val­i­dated bit-iden­ti­cal to the int8 con­tainer.

DSA sparse at­ten­tion — GLM-5.2′s light­ning in­dexer, faith­ful to the ref­er­ence glm_­moe_dsa mod­el­ing: per-layer top-2048 causal key se­lec­tion (full/shared in­dexer lay­ers), auto-de­tected from the out-idx-* weights (–indexer con­verter mode, ~189 MB ex­tracted from the FP8 repo). Validated ex­act: forc­ing the se­lec­tion to keep every key re­pro­duces dense at­ten­tion to­ken-for-to­ken. DSA=0 dis­ables, DSA_TOPK over­rides.

KV-cache per­sis­tence — con­ver­sa­tions re­open warm across en­gine restarts: serve mode ap­pends the com­pressed MLA KV to .coli_kv af­ter every turn (~182 KB/token, crash-safe) and re­sumes it at startup with zero re-pre­fill. Validated byte-iden­ti­cal to an un­in­ter­rupted ses­sion. KVSAVE=0 dis­ables.

Router-lookahead prefetch (PILOT=1, ex­per­i­men­tal) — the next lay­er’s rout­ing is 71.6% pre­dictable from the cur­rent lay­er’s post-at­ten­tion state (measured); a ded­i­cated I/O thread prefetches those ex­perts while the cur­rent layer com­putes.

Batch-union MoE: in pre­fill (and MTP ver­i­fi­ca­tion), each unique ex­pert of the batch is read once and ap­plied to every po­si­tion that routes to it.

Byte-level BPE to­k­enizer in C (GPT-2-style with Unicode-property regex, 320k merges).

RAM safety: the ex­pert cache is auto-sized from MemAvailable at startup — an hon­est peak pro­jec­tion (working set, KV, MTP row, re­con­struc­tion buffers) so the ker­nel OOM-killer never fires.

Offline FP8→int4 con­verter (c/tools/convert_fp8_to_int4.py): down­loads one shard at a time (~5 GB), de­quants (128×128 block scales), re­quan­tizes to the en­gine’s con­tainer, deletes the shard — the 756 GB FP8 check­point never needs to ex­ist on disk at once. Resumable.

Honest num­bers (WSL2, 12 cores, 25 GB RAM, NVMe via VHDX)

This is not fast. It is a 744B fron­tier-class model an­swer­ing cor­rectly on a ma­chine that costs less than one H100 fan. Warm cache, pinned hot ex­perts and MTP push the use­ful-re­sponse la­tency down con­sid­er­ably; the physics of the disk does the rest.

SSD note

Cold starts are heavy on ran­dom reads (~11 GB/token), but reads don’t mean­ing­fully wear an SSD — col­i­brì’s stream­ing is read-only. The real con­cerns un­der heavy use are (1) swap traf­fic if the sys­tem runs out of RAM (writes do wear the drive — keep a sane –ram bud­get; col­i­brì’s auto-bud­get is de­signed to stay clear of swap) and (2) sus­tained ther­mals: hours at full read duty cy­cle will heat cheaper dri­ves. Monitor drive tem­per­a­ture and health.

Download the model

A pre-con­verted GLM-5.2 int4 model for col­i­brì is avail­able on Hugging Face:

https://​hug­ging­face.co/​jlnsrk/​GLM-5.2-col­ibri-int4

If the MTP files there are still the int4 head (see #8 — sizes 1765523544/2686077736/536747200 = int4, un­us­able), grab the int8 MTP heads from the com­mu­nity clone by matey-0: https://​hug­ging­face.co/​ma­teogr­gic/​GLM-5.2-col­ibri-int4-with-int8-mtp

Download the repos­i­tory and point COLI_MODEL to its di­rec­tory:

COLI_MODEL=/path/to/GLM-5.2-colibri-int4 ./coli chat

This skips the FP8 → int4 con­ver­sion step en­tirely.

Thanks DatPat for your help!

Quick start

cd c ./setup.sh # checks gcc/​OpenMP, builds, self-tests

# ONE com­mand does every­thing model-side: down­loads GLM-5.2-FP8 shard by shard # (never needs the full 756 GB at once), con­verts to the int4 con­tainer, then # con­verts the MTP head for spec­u­la­tive de­cod­ing. Resumable at any point. # Conversion (only) needs python with: pip in­stall torch safeten­sors hug­ging­face_hub numpy ./coli con­vert –model /nvme/glm52_i4 # ~400 GB free on a real ext4/​NVMe path

# chat — RAM bud­get, ex­pert cache and MTP are all de­tected au­to­mat­i­cally: COLI_MODEL=/nvme/glm52_i4 ./coli chat

Inspect the planned stor­age hi­er­ar­chy be­fore load­ing the model:

COLI_MODEL=/nvme/glm52_i4 ./coli plan COLI_MODEL=/nvme/glm52_i4 ./coli plan –gpu 0,1 –ram 128 –vram 48 –json

# ap­ply the bounded plan to the nor­mal run­ner COLI_MODEL=/nvme/glm52_i4 ./coli chat –auto-tier

coli plan reads only safeten­sors head­ers and re­ports the mod­el’s ex­act dense/​ex­pert foot­print, run­time RAM re­serve, safe ex­pert-cache cap, and bounded VRAM hot tier. Its ver­sioned JSON out­put is in­tended to be shared by the CLI, API server, Web UI, and desk­top shell; it does not al­lo­cate model ten­sors or start in­fer­ence. –auto-tier ap­plies the same plan to chat, run, serve, and bench­marks. It sets the RAM bud­get and con­text im­me­di­ately; the VRAM tier is en­abled only when the cur­rent glm bi­nary is linked with CUDA. Explicit flags and en­vi­ron­ment vari­ables keep prece­dence over au­to­matic val­ues.

The en­gine at run­time is pure C — python is only used by the one-time con­verter.

OpenAI-compatible API

coli serve keeps one model process loaded and ex­poses a text-only OpenAI-compatible HTTP API. The gate­way uses only the Python stan­dard li­brary; in­fer­ence still runs in the same de­pen­dency-free C en­gine.

cd c COLI_MODEL=/nvme/glm52_i4 COLI_API_KEY=local-secret ./coli serve \ –host 127.0.0.1 –port 8000 –model-id glm-5.2-col­ibri

curl http://​127.0.0.1:8000/​v1/​chat/​com­ple­tions \ -H ‘Authorization: Bearer lo­cal-se­cret’ \ -H ‘Content-Type: ap­pli­ca­tion/​json’ \ -d ‘{ “model”: “glm-5.2-colibri”, “messages”: [{“role”: “user”, “content”: “Hello”}], “stream”: true }’

Implemented end­points are GET /v1/models, GET /v1/models/{model}, POST /v1/chat/completions, and legacy POST /v1/completions. Chat and com­ple­tion re­quests sup­port JSON re­sponses, SSE stream­ing, us­age counts, max_­to­kens/​max_­com­ple­tion_­to­kens, tem­per­a­ture, and top_p. The ex­ten­sion en­able_­think­ing: true en­ables GLM-5.2′s rea­son­ing block; the stan­dard rea­son­ing_­ef­fort field also en­ables it un­less set to none.

The first ver­sion is de­lib­er­ately text-only and serves one gen­er­a­tion at a time: the 744B model stays in one per­sis­tent process, so con­cur­rent HTTP re­quests queue in­stead of load­ing du­pli­cate model copies. Tools, im­age/​au­dio in­put, cus­tom stop se­quences, log prob­a­bil­i­ties, and to­ken penal­ties re­turn an ex­plicit er­ror rather than be­ing silently ig­nored. The de­fault bind ad­dress is lo­cal­host; set COLI_API_KEY be­fore ex­pos­ing the server be­yond the ma­chine.

Browser ac­cess from the Vite de­vel­op­ment server and Tauri lo­cal ori­gins is en­abled by de­fault. Repeat –cors-origin https://​your-ui.ex­am­ple to al­low an­other ex­act ori­gin, or use –cors-origin ‘*’ only on a trusted lo­cal net­work.

The en­gine owns one mu­ta­ble KV con­text, so HTTP gen­er­a­tion uses a bounded FIFO ad­mis­sion queue in­stead of pre­tend­ing to run un­safe par­al­lel se­quences. Configure it with –max-queue N (default 8) and –queue-timeout SECONDS (default 300), or the COLI_MAX_QUEUE / COLI_QUEUE_TIMEOUT en­vi­ron­ment vari­ables. Saturated and timed-out re­quests re­ceive OpenAI-shaped HTTP 429 er­rors be­fore stream­ing head­ers are sent. GET /health ex­poses ac­tive/​queued/​com­pleted/​re­jected coun­ters, and suc­cess­ful gen­er­a­tion re­sponses in­clude x-col­ibri-queue-wait-ms.

Experimental res­i­dent CUDA back­end

col­i­brì in­cludes an opt-in CUDA back­end for model-res­i­dent ten­sors. Streaming ex­perts de­lib­er­ately re­main on the orig­i­nal CPU path for now: copy­ing an ex­pert from NVMe to the GPU on every use would only re­place the disk bot­tle­neck with a PCIe bot­tle­neck. Resident quan­tized ten­sors are up­loaded lazily once and reused.

cd c make cuda-test CUDA=1 # q8/​q4/​q2/​f32 ker­nel cor­rect­ness make CUDA=1 # op­tional dense-path ex­per­i­ment (hot ex­perts are con­fig­ured be­low) COLI_CUDA=1 COLI_GPU=0 CUDA_DENSE=1 SNAP=/nvme/glm52_i4 ./glm 64 4 4

Requirements: Linux, an NVIDIA dri­ver, and a CUDA Toolkit un­der /usr/local/cuda (override with CUDA_HOME=/path/to/cuda). CUDA_ARCH=native builds for the GPU in the cur­rent ma­chine; set an ex­plicit ar­chi­tec­ture when cross-com­pil­ing. Requesting CUDA with a CPU-only bi­nary, an in­valid de­vice, or an un­avail­able run­time fails at startup in­stead of silently falling back.

The nor­mal make build and run­time be­hav­ior are un­changed. CUDA de­faults to an ex­pert-only ac­cel­er­a­tor: res­i­dent dense/​at­ten­tion ten­sors stay on CPU be­cause fix­ture mea­sure­ments show that mov­ing them does not help while ex­pert I/O is the bot­tle­neck. CUDA_DENSE=1 keeps the ear­lier all-res­i­dent ex­per­i­men­tal path. A mea­sured PIN pro­file can pro­mote its hottest ex­perts into the per­sis­tent VRAM tier while keep­ing the rest in RAM:

STATS=stats.txt SNAP=/nvme/glm52_i4 ./glm 64 4 4 # col­lect rout­ing fre­quen­cies first COLI_CUDA=1 COLI_GPU=0 CUDA_EXPERT_GB=16 \ PIN=stats.txt PIN_GB=160 SNAP=/nvme/glm52_i4 ./glm 64 4 4 # multi-GPU ex­pert tier, 96 GB to­tal bud­get across six de­vices COLI_CUDA=1 COLI_GPUS=0,1,2,3,4,5 CUDA_EXPERT_GB=96 \ PIN=stats.txt PIN_GB=160 SNAP=/nvme/glm52_i4 ./glm 64 4 4

Selected ex­perts are up­loaded dur­ing startup, so ca­pac­ity fail­ures oc­cur be­fore in­fer­ence and the log re­ports their ex­act ten­sor foot­print. The bud­get is clamped against free VRAM af­ter re­serv­ing the pro­jected dense res­i­dent set and 2 GB of run­time head­room per se­lected de­vice. With COLI_GPUS, CUDA_EXPERT_GB is a to­tal bud­get across the de­vice set; ex­perts are as­signed whole to the least-loaded de­vice that can hold them. A NUMA-local RAM back­ing store is not im­ple­mented yet.

Current lim­i­ta­tions: de­vices use in­de­pen­dent con­texts and syn­chro­nous host-staged ac­ti­va­tion copies—there is no P2P/NCCL de­pen­dency yet. The ker­nels are cor­rect­ness-first cus­tom ker­nels rather than cuBLAS/​Ten­sor Core ker­nels. This draft in­ten­tion­ally makes no end-to-end speedup claim be­fore the full model is bench­marked.

For a re­pro­ducible back­end A/B with­out the full check­point, gen­er­ate the de­ter­min­is­tic 313M-parameter glm_­moe_dsa fix­ture and run fixed-to­ken re­play:

cd c python tools/​make_glm_bench_­model.py –output /nvme/colibri-bench-medium –device cuda python tools/​bench­mark_cu­d­a_­fix­ture.py –model /nvme/colibri-bench-medium –gpu 0

The fix­ture has ran­dom weights and is not a lan­guage model. It ex­ists only to pre­serve the real MLA/MoE/streaming shapes and com­pare CPU stream­ing, dense-only CUDA, CPU hot-store, and CUDA hot-ex­pert ex­e­cu­tion with iden­ti­cal re­play to­kens.

Web in­ter­face

web/ con­tains a com­mu­nity-con­tributed browser UI (React + TypeScript, ~390 lines of source, a pure API client — it never touches the en­gine di­rectly):

cd web npm ci && npm run dev # then point it at an OpenAI-compatible end­point

It speaks the stan­dard OpenAI Chat Completions pro­to­col with SSE stream­ing, so it works against the col­i­brì OpenAI-compatible server (in re­view, #21) or any other com­pat­i­ble end­point. Nothing leaves the end­point you con­fig­ure. The ter­mi­nal coli chat re­mains the first-class in­ter­face.

Useful knobs (env or flags): –temp T to­ken sam­pling tem­per­a­ture (default 0.7 + nu­cleus 0.90 — tuned for int4; 0 = greedy), –topp 0.7 adap­tive ex­pert top-p (30 – 40% less disk), –ngen N max to­kens per an­swer (:piu in chat con­tin­ues a trun­cated one), –repin N adapt RAM/VRAM hot ex­perts every N emit­ted to­kens, AUTOPIN=0 dis­able the learn­ing cache’s auto-pin, THINK=1 en­able GLM-5.2′s rea­son­ing block, DRAFT=n MTP draft depth, TF=1 teacher-forc­ing val­i­da­tion, PILOT=1 router-looka­head disk prefetch (experimental — see be­low), CAP_RAISE=0 don’t auto-grow the ex­pert cache.

The ex­pert cache auto-sizes to your RAM (since 2026 – 07-10): the en­gine now raises the LRU cap to fill your –ram bud­get in­stead of only low­er­ing it. Before this fix a 128 GB ma­chine ran with the same 8-experts/layer cache as a 16 GB one (issue #12) — if you bench­marked col­i­brì be­fore this date, re­run: your num­bers were capped.

Router-lookahead prefetch (PILOT=1, ex­per­i­men­tal): GLM-5.2′s ex­pert rout­ing is mea­sur­ably pre­dictable ahead of time — ap­ply­ing layer L+1′s router to layer L’s post-at­ten­tion state re­calls 71.6% of the true top-8 (vs 41.3% for “same ex­perts as last to­ken”). PILOT=1 uses this to is­sue next-layer ex­pert reada­head from a ded­i­cated I/O thread while the cur­rent layer com­putes. On our dev box the disk is al­ready ~80% sat­u­rated, so it mea­sures neu­tral; on ma­chines where com­pute and disk are bal­anced (like the Ryzen AI 9 in is­sue #12: 43% disk / 46% mat­mul) it should over­lap real work — mea­sure­ments wel­come.

The learn­ing cache: the en­gine records which ex­perts your us­age ac­tu­ally routes to (.coli_usage next to the model, up­dated every turn) and at startup au­to­mat­i­cally pins the hottest ones in spare RAM. col­i­brì lit­er­ally gets faster the more you use it.

Live tier adap­ta­tion (–repin N, opt-in): at safe turn bound­aries, a de­cay­ing ses­sion heat map re­places cold pinned ex­perts with hot­ter streamed ex­perts. Replacement loads the ex­pert from disk into the ex­ist­ing RAM slot; GPU-backed slots im­me­di­ately re­fresh the same VRAM tier bud­get. A 25% hys­tere­sis and a four-swap limit pre­vent tier thrash­ing. Persistent .coli_usage re­mains the long-term sig­nal and is not de­cayed.

Conversations re­open warm (.coli_kv, since 2026 – 07-10): coli chat per­sists the com­pressed MLA KV-cache to disk af­ter every turn (~182 KB/token, ap­pended in­cre­men­tally, crash-safe). Close the chat, re­open it to­mor­row — the model still re­mem­bers the whole con­ver­sa­tion and zero re-pre­fill hap­pens: val­i­dated byte-iden­ti­cal to an un­in­ter­rupted ses­sion. :reset clears it, KVSAVE=0 dis­ables it.

Got a bet­ter ma­chine? Try it — here’s what to ex­pect

col­i­brì was built on de­lib­er­ately hum­ble hard­ware (12 cores, 25 GB RAM, NVMe be­hind a WSL2 VHDX that caps ran­dom reads at ~1 GB/s). Every one of those con­straints is a knob your ma­chine can turn up. The en­gine needs: Linux (or WSL2), gcc with OpenMP, AVX2, ≥16 GB RAM, and the ~370 GB int4 model on a lo­cal NVMe (ext4 — never a net­work/​9p mount).

How to test it, in or­der:

cd c && ./setup.sh # build + ar­chi­tec­ture self-test (expects 32/32)

# 1) mea­sure YOUR disk the way the en­gine uses it (parallel 19 MB ran­dom reads): gcc -O2 -fopenmp iobench.c -o iobench ./iobench /path/to/glm52_i4/out-00069.safetensors 19 64 8 0 # buffered, 8 threads ./iobench /path/to/glm52_i4/out-00069.safetensors 19 64 8 1 # O_DIRECT

# 2) chat; watch the per-turn stats line (tok/s, ex­pert hit-rate, RSS): COLI_MODEL=/path/to/glm52_i4 ./coli chat

# 3) record ex­pert us­age, then pin the hottest ex­perts in your spare RAM: STATS=stats.txt ./coli chat PIN=stats.txt PIN_GB=20 ./coli chat # scale PIN_GB to your free RAM

# 4) qual­ity bench­marks (MMLU/HellaSwag/ARC): ./coli bench

Back-of-envelope pre­dic­tions (decode is disk-bound: a cold to­ken costs ~11.4 GB of ex­pert reads; MTP spec­u­la­tion roughly halves the ef­fec­tive cost once the cache is warm; RAM turns cold reads into free cache hits):

These are es­ti­mates, not mea­sure­ments — if you run col­i­brì on se­ri­ous hard­ware, please open an is­sue with your num­bers: real dat­a­points from bet­ter ma­chines are ex­actly what this pro­ject needs next.

Community bench­marks (measured)

Real num­bers from real ma­chines, stock build (setup.sh, gcc 13), greedy de­cod­ing, –ngen 32, MTP ac­tive:

Takeaways: with 24 GB of RAM the en­gine auto-caps the ex­pert cache to 2 slots/​layer, so de­code stays cold even on a disk 2 – 2.7× faster than the dev box — on small-RAM ma­chines the RAM cap, not the disk, is the bind­ing con­straint, ex­actly as the table above pre­dicts; –topp 0.7 alone bought a clean 1.6× end-to-end speedup. The M5 Max dat­a­point lands right on the table’s sec­ond row: ~1 tok/​s of a 744B model on a lap­top SSD — and its 14 GB/s disk shifts the bot­tle­neck back to RAM bud­get and ker­nels. The Framework 13 rows are the cache the­sis proven end-to-end on one ma­chine: 0.29 → 0.37 tok/​s (hit 28% → 66%, spec­u­la­tion fi­nally en­gag­ing at 52% ac­cep­tance) just by giv­ing the cache its RAM — int8 MTP head + a big­ger cap + the learned pin. The cap part is now au­to­matic (cap auto-raise, 2026 – 07-10).

Quality bench­mark — help wanted

We have never mea­sured how much the int4 quan­ti­za­tion costs in ac­cu­racy — the har­ness is built and wired, but scor­ing is one for­ward per an­swer op­tion, and on the dev box’s ~1 GB/s disk a full run takes the bet­ter part of a day. This is the sin­gle most valu­able thing a faster ma­chine can con­tribute. The code is here and ready; one com­mand runs it end to end (it auto-down­loads the datasets on first use):

cd c ./coli bench # hel­laswag, ar­c_chal­lenge, mmlu — 40 ques­tions each ./coli bench hel­laswag –limit 200 # one task, more ques­tions ./coli bench mmlu ar­c_chal­lenge –ram 100 # pick tasks, set a RAM bud­get

It prints per-task ac­cu­racy (log-likelihood scor­ing, EleutherAI-harness style). Published full-pre­ci­sion GLM-5.2 scores on these tasks sit around 85 – 95%; if our int4 con­tainer lands within a few points, the quan­ti­za­tion is val­i­dated — if it does­n’t, we know to in­vest in mixed / grouped-scale quan­ti­za­tion. If you have the hard­ware to run this, please open an is­sue with the num­bers — it’s the mea­sure­ment the pro­ject is miss­ing.

Supporting the pro­ject

col­i­brì is a one-per­son pro­ject, writ­ten and tested en­tirely on a 12-core lap­top with 25 GB of RAM — the num­bers above are the ceil­ing of what I can mea­sure at home. If this pro­ject is use­ful or in­ter­est­ing to you and you’d like to sup­port its de­vel­op­ment (better test hard­ware trans­lates di­rectly into a faster en­gine for every­one: real NVMe scal­ing data, big­ger pinned caches, int2/​int3 qual­ity sweeps on real bench­marks), you can:

⭐ star the repo and share it;

🐛 open is­sues with bench­mark num­bers from your hard­ware;

💬 reach out via GitHub is­sues if you’d like to spon­sor de­vel­op­ment or do­nate hard­ware.

Every con­tri­bu­tion, from a dat­a­point to a disk, moves the ceil­ing.

Repo lay­out

Makefile root build/​check en­try point c/ ├── glm.c sin­gle-file GLM en­gine ├── st.h, tok.h, json.h run­time head­ers ├── back­end_cuda.* op­tional CUDA tier ├── Makefile build and lo­cal checks ├── coli user-fac­ing CLI ├── ope­nai_server.py OpenAI-compatible HTTP gate­way ├── setup.sh one-com­mand lo­cal setup ├── tools/ of­fline con­ver­sion, fix­tures and bench­marks ├── scripts/ long-run­ning con­ver­sion helpers └── tests/ de­pen­dency-free C and Python tests web/ browser UI (pure OpenAI-API client, com­mu­nity-main­tained)

The run­time path in­ten­tion­ally stays flat and read­able: glm.c plus its small head­ers. Auxiliary Python and shell tool­ing is grouped sep­a­rately and is never a run­time de­pen­dency of the en­gine.

I spent a rather em­bar­rass­ing amount of time try­ing to match up Run­ning Train‘s hy­per-re­al­is­tic train lines and Japanese ter­rain with the real world. And in do­ing so, I paid the game the high­est pos­si­ble com­pli­ment. This ex­tra­or­di­nar­ily re­al­is­tic sim made by one-per­son de­vel­op­ment team Novatetsu Games is in fact set in a fic­tional re­gion of Japan, but is cre­ated so lov­ingly that you’ll be­lieve it’s real life.

I’m not ex­actly a train en­thu­si­ast, nor in­deed par­tic­u­larly au fait with the range of train sim games pre­vi­ously avail­able, but in Running Train I’ve found some­thing ab­solutely cap­ti­vat­ing. And most bizarrely, I’ve found that qual­ity not by ac­tu­ally play­ing it, but rather by let­ting it play it­self. While the game en­cour­ages you to mas­ter the rea­son­ably sim­ple con­trols of its range of per­fectly crafted en­gines, you can also just set it to play it­self and then take over the free cam­era as it does. Doing so has brought me so much plea­sure.

Played prop­erly, Run­ning Train asks you to care­fully con­trol your speed, brak­ing, and prompt, safe ar­rival at train sta­tions, and re­wards or pe­nal­izes you ac­cord­ingly. By turn­ing off in-game guides and even the UI, you can earn higher scores and more credit, con­tribut­ing to your over­all rat­ing for each of the 42 dif­fer­ent routes it cur­rently fea­tures. These routes fea­ture ten 12-minute routes on the fic­tional Fukugawa Line, and a fur­ther 32 of hugely vary­ing length on the equally made up Sankai Main Line. They can be as short as six min­utes, or as long as 44, each set at dif­fer­ent times of day.

And oh my good­ness, it’s so pretty. Vast stretches of imag­ined Japanese towns and coun­try­side have been cre­ated (40 kilo­me­ters of track, ap­par­ently), and it’s not just ran­domly placed as­sets. Jumping into that free cam­era, I could­n’t be­lieve it when I no­ticed that even pow­er­lines are log­i­cally placed, with wires be­gin­ning at sub­sta­tions, then stretch­ing across py­lon net­works. Roads are filled with traf­fic, cars are parked in bays out­side apart­ment build­ings, Shinto tem­ples sit on hill­sides, fer­ries bob on the sea while waves lap onto shores.

The key thing about all these de­tails is that…you don’t see most of them from the train! If you stuck with the dri­ver cam, you’d miss al­most all of it. It’s so much ef­fort that the de­vel­op­ers could eas­ily have got­ten away with­out, but it adds so much by be­ing in­cluded. It’s also pos­si­ble to play any of the routes in dif­fer­ent weather con­di­tions, from sunny days to tor­ren­tial rain, or in­deed in ei­ther spring or win­ter, with op­tional bliz­zards cov­er­ing the en­tire game in snow.

Zoom out far enough—and for some rea­son it will let you—and you see the tiles, the roads that don’t line up, and the var­i­ous tricks and tech­niques that al­low it to look so re­al­is­tic from low down. But don’t do that! That’s silly. This is a train sim, not a plane sim, you’ve no busi­ness in the sky.

From those who know what they’re do­ing, Steam re­views could not be more glow­ing. “Honestly, I re­ally, re­ally do not know what to say,” be­gins one, be­fore adding, “Hands down the most beau­ti­ful train sim that has been re­leased on the mar­ket thus far. The mod­el­ing is top tier. The en­vi­ron­ment de­tails, the clouds, the light­ing, the weather ef­fects all of it is just ab­solutely in­sane!”

Another says, “Best train sim­u­la­tor game so far!” while a third com­pli­ments the solo dev for in­clud­ing sup­port for the Zuiki MASCON, a be­spoke pe­riph­eral for train dri­ving sims.

This is all for the Early Access re­lease, and there are still big plans to make the game far more de­tailed. The de­vel­oper wants to add a pas­sen­ger sys­tem (currently the trains run empty) and a con­duc­tor mode, and the ul­ti­mate goal is up to 100 km of track. The hope is to have that all done by the end of next year.

As it is, you can ab­solutely en­joy it as a top-notch train sim, but for me the ex­pe­ri­ence has been about let­ting the model rail­way run it­self as I swoop about in the cam­era. It’s a rare plea­sure.

Running Train is out now in Early Access on Steam for $18.

The United States Army spent the last two decades op­ti­miz­ing sus­tain­ment for per­mis­sive en­vi­ron­ments de­fined by un­con­tested sup­ply lines, con­trac­tor sup­port, and sta­tic for­ward op­er­at­ing bases. As the National Defense Strategy shifts to­ward strate­gic com­pe­ti­tion and mul­tido­main op­er­a­tions, how­ever, this ef­fi­ciency-dri­ven model has be­come a li­a­bil­ity. In large-scale com­bat op­er­a­tions, vic­tory will de­pend less on which force fields the most ad­vanced weapons and more on which can sus­tain com­bat power un­der per­sis­tent at­tack. A lethal ma­neu­ver force with­out a sur­viv­able lo­gis­ti­cal back­bone is sim­ply a sta­tion­ary tar­get wait­ing to cul­mi­nate.

The Weight of History: Lessons in Logistical Overreach

History pro­vides stark, re­cur­ring warn­ings against ne­glect­ing the sus­tain­ment tail in fa­vor of the com­bat teeth. A prime ex­am­ple is found in Operation Barbarossa, the German in­va­sion of the Soviet Union in 1941. German mech­a­nized for­ma­tions shat­tered Soviet de­fenses and ad­vanced hun­dreds of miles within weeks. Yet they rapidly out­ran their lo­gis­tics net­work.

The German high com­mand had planned for a short, de­ci­sive cam­paign. It failed to ac­count for the im­mense dis­tances, the lack of paved roads, and the mis­match in rail­way gauges that pre­vented German trains from uti­liz­ing Soviet rail lines with­out ex­ten­sive mod­i­fi­ca­tion. Despite un­prece­dented ini­tial bat­tle­field suc­cesses, the cam­paign in­evitably fal­tered. Fuel, am­mu­ni­tion, win­ter cloth­ing, and re­place­ment parts failed to keep pace with the ad­vanc­ing Panzer groups.

The fa­mous halt be­fore Moscow in the win­ter of 1941 was not pri­mar­ily a tac­ti­cal de­feat in­flicted by the Red Army; it was a sys­temic fail­ure in sus­tain­ment. The Wehrmacht’s op­er­a­tional bril­liance was en­tirely nul­li­fied by its lack of strate­gic en­durance. The les­son here is clear: Operational reach is strictly dic­tated by lo­gis­ti­cal and sus­tain­ment ca­pac­ity. Modern armies, fix­ated on the speed and lethal­ity of their own mech­a­nized and avi­a­tion as­sets, risk re­peat­ing this ex­act er­ror if they as­sume that sup­ply will keep pace with the ma­neu­ver force.

Furthermore, the Army must un­learn the lo­gis­ti­cal lessons from Operations Desert Storm and Iraqi Freedom. In 1991, the US mil­i­tary spent six months build­ing mas­sive “iron moun­tains” of sup­plies in Saudi Arabia, com­pletely un­hin­dered by Iraqi in­ter­dic­tion. In 2003, while sup­ply lines were stretched, US forces still en­joyed ab­solute air su­premacy and elec­tro­mag­netic dom­i­nance. In a fu­ture peer con­flict, the US Army will not be granted a six-month, un­con­tested build-up phase, nor will it op­er­ate un­der friendly skies.

The Crucible of Ukraine: The Transparent Battlefield

If his­tory pro­vides the the­ory, the on­go­ing war in Ukraine of­fers a bru­tal con­tem­po­rary les­son: Modern armies col­lapse when they run out of lo­gis­tics, not when they run out of weapons. Pervasive sens­ing, pre­ci­sion fires, and in­ex­pen­sive drone sys­tems have ef­fec­tively elim­i­nated the tra­di­tional rear area. Sustainment nodes, con­voys, and dis­tri­b­u­tion routes are now per­sis­tently ex­posed to de­tec­tion and at­tack, mak­ing sur­viv­abil­ity and dis­per­sion pre­req­ui­sites for op­er­a­tional en­durance.

During the open­ing phase of the in­va­sion, the forty-mile-long Russian con­voy that stalled north of Kyiv in February 2022 demon­strated how fuel short­ages, main­te­nance fail­ures, and in­ter­dicted move­ment cor­ri­dors can im­mo­bi­lize op­er­a­tional ma­neu­ver. Ukrainian forces by­passed ar­mored spear­heads to strike vul­ner­a­ble fuel and sup­port con­voys, ex­pos­ing the mech­a­nized for­ma­tions’ de­pen­dence on un­in­ter­rupted sus­tain­ment. Multiple Russian for­ma­tions stalled not be­cause they were tac­ti­cally de­feated, but be­cause their lo­gis­ti­cal sup­port col­lapsed.

As the con­flict evolved into a war of at­tri­tion, the vul­ner­a­bil­ity of cen­tral­ized lo­gis­tics be­came even more pro­nounced. Long-range pre­ci­sion fires, par­tic­u­larly HIMARS, en­abled Ukraine to sys­tem­at­i­cally tar­get Russian am­mu­ni­tion de­pots and rail hubs deep be­hind the front. Russia’s sub­se­quent dis­place­ment of lo­gis­ti­cal nodes far­ther from the bat­tle­field de­graded both the speed and vol­ume of ar­tillery re­sup­ply, demon­strat­ing how at­tacks on sus­tain­ment ar­chi­tec­ture can di­rectly re­duce com­bat ef­fec­tive­ness at the point of con­tact.

Core Vulnerabilities: Moving Bulk Class III and Class V at Scale

To un­der­stand the scope of the prob­lem, one must ex­am­ine the stag­ger­ing con­sump­tion rates in­her­ent to large-scale com­bat op­er­a­tions. The two most crit­i­cal vul­ner­a­bil­i­ties in the cur­rent US Army sus­tain­ment ar­chi­tec­ture are the di­min­ished ca­pac­ity to move bulk Class III (fuel) and Class V (ammunition) at scale, and the over­re­liance on cen­tral­ized, eas­ily tar­getable in­fra­struc­ture.

This is par­tic­u­larly ap­par­ent in the or­ganic sus­tain­ment ar­chi­tec­ture of an ar­mored brigade com­bat team, which con­sumes tens of thou­sands of gal­lons of fuel daily dur­ing high-in­ten­sity com­bat. Moving this vol­ume of fuel from the di­vi­sion sup­port area through the brigade sup­port area and for­ward to the com­bat trains com­mand post re­quires a mas­sive fleet of heavy tac­ti­cal ve­hi­cles. Current fuel dis­tri­b­u­tion plat­forms re­main large, lightly pro­tected, and read­ily de­tectable by their ther­mal and elec­tro­mag­netic sig­na­tures, while main­te­nance short­falls and in­con­sis­tent op­er­a­tional readi­ness re­duce avail­able dis­tri­b­u­tion ca­pac­ity. The cur­rent dis­tri­b­u­tion sys­tem lacks the phys­i­cal re­silience and pro­tec­tion needed to with­stand the re­lent­less deep-strike at­tacks ex­pected from a peer ad­ver­sary.

Similarly, the am­mu­ni­tion ex­pen­di­ture rates ob­served in Ukraine should alarm every Army plan­ner. Wars be­tween in­dus­trial pow­ers are fun­da­men­tally con­tests of in­dus­trial ca­pac­ity. Artillery, air de­fense in­ter­cep­tors, and pre­ci­sion-guided mu­ni­tions are be­ing con­sumed at rates not seen since World War II. The US mil­i­tary’s cur­rent stock­pile depth, com­bined with the dif­fi­culty of trans­port­ing ex­tremely heavy 155-millimeter ar­tillery shells and guided mul­ti­ple-launch rocket sys­tem pods across con­tested oceans and de­graded the­ater road net­works, poses a crit­i­cal threat to com­bat en­durance. Without the abil­ity to con­tin­u­ously and se­curely re­sup­ply the front, even the most tech­no­log­i­cally ad­vanced com­bat for­ma­tions will rapidly cul­mi­nate, ren­der­ing their tac­ti­cal over­match ir­rel­e­vant.

Adapting the Architecture: From Static Nodes to Agile Networks

Large brigade sup­port ar­eas op­ti­mized for coun­terin­sur­gency-era ef­fi­ciency have be­come li­a­bil­i­ties in large-scale com­bat op­er­a­tions. Concentrated per­son­nel, ve­hi­cles, and ma­teriel cre­ate lu­cra­tive tar­gets for ad­ver­saries equipped with per­sis­tent sur­veil­lance and long-range pre­ci­sion strike sys­tems.

To sur­vive in con­tested en­vi­ron­ments, the Army must tran­si­tion from a cen­tral­ized hub-and-spoke sus­tain­ment model to a de­cen­tral­ized net­work of smaller, dis­persed, mo­bile, and sig­na­ture-man­aged nodes. Sustainment el­e­ments must be ca­pa­ble of re­lo­cat­ing with the same fre­quency as ma­neu­ver bat­tal­ion tac­ti­cal op­er­a­tions cen­ters, while dis­trib­uted caching of fuel, wa­ter, and am­mu­ni­tion across con­cealed lo­ca­tions should re­place the cur­rent re­liance on large, cen­tral­ized sup­ply dumps.

This trans­for­ma­tion must be paired with de­lib­er­ate in­vest­ment in cam­ou­flage, con­ceal­ment, and de­cep­tion tai­lored to sus­tain­ment op­er­a­tions. Multispectral sig­na­ture re­duc­tion, dis­ci­plined elec­tro­mag­netic man­age­ment, and strict emis­sions con­trol are no longer op­tional en­hance­ments but op­er­a­tional ne­ces­si­ties. Sustainment forces must be trained to op­er­ate in GPS-denied en­vi­ron­ments where poor sig­na­ture man­age­ment in­vites rapid de­tec­tion, tar­get­ing, and in­ter­dic­tion.

Arming the Sustainers: Survivability and Organic Protection

On a non­lin­ear bat­tle­field, sus­tain­ment forces can no longer de­pend on ma­neu­ver units for pro­tec­tion and must pos­sess or­ganic de­fen­sive ca­pa­bil­i­ties. Brigade sup­port bat­tal­ions and com­bat sus­tain­ment sup­port bat­tal­ions re­quire em­bed­ded counter–un­manned air­craft sys­tems and short-range air de­fense as­sets ca­pa­ble of de­feat­ing aer­ial threats at the point of at­tack.

Additionally, the Army must rein­vest in up-ar­mor­ing its lo­gis­ti­cal fleet. While adding ar­mor re­duces pay­load ca­pac­ity and in­creases fuel con­sump­tion, vi­o­lat­ing the peace­time gospel of ef­fi­ciency, it is a manda­tory trade-off for sur­vival. We must also ac­cel­er­ate the de­vel­op­ment and field­ing of au­tonomous and semi­au­tonomous re­sup­ply plat­forms. Unmanned ground ve­hi­cles and heavy-lift cargo drones can take over the most dan­ger­ous last mile re­sup­ply mis­sions, mov­ing crit­i­cal Class III and V to the ab­solute edge of the for­ward line of troops with­out risk­ing hu­man lives in highly con­tested kill zones.

The Cultural Imperative: Elevating the Sustainment Enterprise

Ultimately, the fail­ure to mod­ern­ize the tac­ti­cal sus­tain­ment en­ter­prise is not just a pro­cure­ment is­sue; it is a cul­tural fail­ure within the Army. Army mod­ern­iza­tion cul­ture con­tin­ues to priv­i­lege in­vest­ments in ma­neu­ver and fires over sus­tain­ment and re­silience, pri­or­i­tiz­ing ad­vanced fire­power, next-gen­er­a­tion com­bat ve­hi­cles, and deep-strike ca­pa­bil­i­ties. In con­trast, sus­tain­ment re­mains an in­sti­tu­tional af­ter­thought, of­ten rel­e­gated to the back­ground of op­er­a­tional plan­ning and bud­get al­lo­ca­tion.

The no­tion that am­a­teurs talk tac­tics and pro­fes­sion­als talk lo­gis­tics is fre­quently dis­cussed in mil­i­tary acad­e­mies and war col­leges, yet it is rarely re­flected in the Army’s bud­get re­quests or mod­ern­iza­tion pri­or­i­ties. The out­dated con­cept of the tooth-to-tail ra­tio, which im­plies the lo­gis­ti­cal tail is a bu­reau­cratic waste that must be min­i­mized to sup­port the com­bat teeth, must be fun­da­men­tally re­ex­am­ined. In mod­ern war­fare, the tail is the pri­mary tar­get. If the tail is sev­ered, the teeth are ren­dered use­less.

If the Army is se­ri­ous about prepar­ing for peer con­flict, it must el­e­vate sus­tain­ment to a pri­mary warfight­ing func­tion. This means grant­ing it the same level of in­tel­lec­tual in­vest­ment, pro­tec­tive pri­or­i­ti­za­tion, and in­sti­tu­tional pres­tige as ma­neu­ver and fires. At com­bat train­ing cen­ters, ro­ta­tional units must face sig­nif­i­cant lo­gis­ti­cal chal­lenges. Umpires should reg­u­larly dis­able un­de­fended base sup­port ar­eas and com­pel brigade com­man­ders to op­er­ate with­out fuel or ar­tillery am­mu­ni­tion. Such con­di­tions would force com­man­ders to in­no­vate un­der con­tested sus­tain­ment con­di­tions rather than op­er­ate with ar­ti­fi­cially un­in­ter­rupted sup­ply lines.

The US Army can­not rely on soft­ware, pre­dic­tive main­te­nance al­go­rithms, or ar­ti­fi­cial in­tel­li­gence to solve the bru­tal, phys­i­cal chal­lenges of in­dus­trial war­fare. While data an­a­lyt­ics can op­ti­mize a sup­ply chain, they can­not ar­mor a fuel truck, shoot down a loi­ter­ing mu­ni­tion, or phys­i­cally trans­port 155-millimeter shells through a bar­rage of pre­ci­sion fires.

The Army’s suc­cess in fu­ture con­flict will not be de­ter­mined by whose tanks have the thick­est ar­mor or whose mis­siles have the longest range. It will be de­ter­mined by whose sus­tain­ment en­ter­prise can sur­vive, adapt, and func­tion un­der per­sis­tent, bru­tal, and mul­tido­main at­tack. Wars be­tween mas­sive in­dus­trial pow­ers are fun­da­men­tally con­tests of en­durance. Right now, the Army risks en­ter­ing that con­test with a lo­gis­ti­cal back­bone built en­tirely for peace­time ef­fi­ciency, not wartime sur­vival. This is no longer just a mod­ern­iza­tion gap; it is a glar­ing strate­gic vul­ner­a­bil­ity that de­mands im­me­di­ate, de­ci­sive, and well-funded ac­tion. The Army’s fu­ture suc­cess will not be de­ter­mined solely by su­pe­rior plat­forms or longer-range fires, but by whether its sus­tain­ment en­ter­prise can en­dure un­der per­sis­tent at­tack. Without re­ori­ent­ing mod­ern­iza­tion to­ward sur­viv­abil­ity, dis­per­sion, and en­durance, the Army risks field­ing a force op­ti­mized for tac­ti­cal ex­cel­lence yet vul­ner­a­ble to op­er­a­tional cul­mi­na­tion. In the next war, lo­gis­tics will not merely en­able vic­tory; it will de­ter­mine it. The Army risks field­ing a force op­ti­mized for tac­ti­cal ex­cel­lence but not for sus­tained op­er­a­tional mo­men­tum.

Major Jonathan Buckland currently serves in the J33 on the Joint Staff. His pre­vi­ous as­sign­ments in­clude serv­ing as the ex­ec­u­tive of­fi­cer of 5th Squadron, 7th Cavalry Regiment, 1st Armored Brigade Combat Team (ABCT), 3rd Infantry Division; op­er­a­tions of­fi­cer for 3rd Battalion, 69th Armor Regiment, 1/3 ABCT; and fu­ture op­er­a­tions chief for 3rd Infantry Division. He has a bach­e­lor’s de­gree in English from the Virginia Military Institute, a mas­ter’s de­gree in in­ter­na­tional stud­ies from the University of Kansas, and a mas­ter’s in op­er­a­tional stud­ies from the Army Command and General Staff College.

The views ex­pressed are those of the au­thor and do not re­flect the of­fi­cial po­si­tion of the United States Military Academy, Department of the Army, or Department of Defense.

Image credit: Spc. Rebeca Soria, US Army

Today, we’re ex­cited to in­tro­duce Muse Spark 1.1, the lat­est model from Meta Superintelligence Labs and a sig­nif­i­cant up­grade from Muse Spark. Muse Spark 1.1 is a mul­ti­modal rea­son­ing model built for agen­tic tasks, with ma­jor gains in tool and com­puter use, cod­ing, and mul­ti­modal un­der­stand­ing.

With these im­prove­ments, Muse Spark 1.1 ad­vances the per­for­mance-ef­fi­ciency fron­tier. Together with this week’s launch of Muse Image, this re­lease brings us closer to our vi­sion of per­sonal su­per­in­tel­li­gence: mod­els that help you pur­sue your goals, cre­ate what you imag­ine, deepen your re­la­tion­ships, and take ac­tion on what you value most.

Along with this re­lease, we are launch­ing a pub­lic pre­view of the new Meta Model API where de­vel­op­ers can ac­cess Muse Spark 1.1. The model is avail­able now in “Thinking” mode in the Meta AI app and on meta.ai.

Evaluations

Agents

Muse Spark 1.1 de­liv­ers ex­cep­tional per­for­mance in per­sonal agen­tic tasks that re­quire plan­ning and or­ches­tra­tion across a range of ex­ter­nal apps and ser­vices. It zero-shot gen­er­al­izes to new na­tive tools, MCP servers, and cus­tom skills.

It tack­les com­plex pro­jects sig­nif­i­cantly faster than Muse Spark, as it is trained to or­ches­trate multi-agent sys­tems to op­ti­mize end-to-end la­tency. As the main agent, it can gather con­text, make a plan, and del­e­gate ex­e­cu­tion across par­al­lel sub­agents. As a sub­agent, it ad­heres to its job, un­der­stands avail­able tools, and knows when to es­ca­late back to the main agent.

Muse Spark 1.1 can ac­tively man­age its con­text win­dow of 1 mil­lion to­kens. It re­mem­bers ac­tions, re­trieves in­for­ma­tion from much ear­lier work, and com­pacts in a way that keeps the crit­i­cal steps needed for later work.

Computer Use

Muse Spark 1.1 ex­cels at com­puter-use work­flows that un­fold across mul­ti­ple ap­pli­ca­tions with in­for­ma­tion chang­ing on-the-fly. It main­tains con­text across ex­tended ses­sions, adapts to evolv­ing re­quire­ments, and nav­i­gates un­fa­mil­iar in­ter­faces with min­i­mal hu­man in­ter­ven­tion.

Rather than rea­son­ing through every desk­top step one click at a time, Muse Spark 1.1 un­der­stands when to au­to­mate and when to use the in­ter­face di­rectly. We trained the model to write scripts when au­toma­tion is faster, click when di­rect in­ter­ac­tion is sim­pler, and gen­er­ate batches of ac­tions at each step.

Agentic din­ner party or­ga­ni­za­tion: In real-world ap­pli­ca­tions, new con­text arises that changes the task. Muse Spark 1.1 no­tices these changes when plac­ing the din­ner or­der and makes nec­es­sary up­dates with­out user in­ter­ven­tion.

Coding

Coding per­for­mance for Muse Spark 1.1 im­proved sub­stan­tially on real-world tasks in­volv­ing large, com­plex code­bases. It can di­ag­nose and fix com­plex bugs, im­ple­ment new fea­tures in en­ter­prise-grade sys­tems, and ex­e­cute large code mi­gra­tions. In use cases like cre­at­ing web ap­pli­ca­tions and end-to-end ques­tion an­swer­ing, Muse Spark 1.1 shows large gains over our first model.

We trained our model to smoothly adapt to di­verse har­nesses and re­li­ably han­dle com­plex multi-turn dy­nam­ics. Muse Spark 1.1 per­forms well with pop­u­lar agen­tic cod­ing se­tups, sup­port­ing com­mon fea­tures like plan­ning mode, goal con­di­tion­ing, sub­agent del­e­ga­tion, and con­text com­paction.

Debugging demo in OpenCode: Muse Spark 1.1 builds a chat web app, takes au­to­mated screen­shots to iden­tify user-vis­i­ble fail­ures, traces is­sues back to rel­e­vant code to im­ple­ment fixes, and val­i­dates these changes. The model seam­lessly com­bines cod­ing, mul­ti­modal un­der­stand­ing, and tool call­ing.

Across Meta, de­vel­op­ers and re­searchers are us­ing Muse Spark 1.1 daily to build faster and work smarter. On our pri­mary in­ter­nal cod­ing eval­u­a­tion, Meta Internal Coding Bench, Muse Spark 1.1 sig­nif­i­cantly im­proves upon Muse Spark and is com­pet­i­tive with lead­ing al­ter­na­tives.

Researchers are now also au­tomat­ing model de­vel­op­ment and eval­u­a­tion tasks by lever­ag­ing Muse Spark 1.1 in their work­flows.

DeepSWE eval­u­a­tion in OpenCode: Muse Spark 1.1 eval­u­ates it­self on a sub­set of DeepSWE tasks across dif­fer­ent rea­son­ing strengths and pro­duces an analy­sis dash­board based on the re­sults.

Multimodal

Along with cod­ing and agen­tic ca­pa­bil­i­ties, Muse Spark 1.1 ex­cels in per­cep­tion, mul­ti­modal rea­son­ing, and tool use. It can in­ter­act with real en­vi­ron­ments and pro­duce grounded out­puts with strengths in vi­sual-to-code ar­ti­fact gen­er­a­tion, ul­tra-de­scrip­tive im­age and video cap­tion­ing, and agen­tic work­flow ex­e­cu­tion for mul­ti­modal use cases.

Muse Spark 1.1’s mul­ti­modal ca­pa­bil­i­ties are es­pe­cially valu­able when per­cep­tion and ac­tion need to hap­pen to­gether. The model can in­spect vi­sual and au­dio, pre­serve de­tails across a long work­flow, and use those de­tails while op­er­at­ing com­put­ers on the user’s be­half.

Facebook Marketplace agent: Using video shot from a smart­phone, Muse Spark 1.1 ex­tracts use­ful pho­tos and rea­sons about the prod­uct to op­er­ate a user’s browser and make a Facebook Marketplace list­ing on the user’s be­half.

Safety

We con­ducted ex­ten­sive safety eval­u­a­tions be­fore de­ploy­ment, fol­low­ing the Advanced AI Scaling Framework, which de­fines eval­u­a­tions, threat mod­els, and de­ploy­ment thresh­olds for our most ad­vanced mod­els.

Across all fron­tier risk cat­e­gories — Chemical & Biological, Cybersecurity, and Loss of Control — our eval­u­a­tions show Muse Spark 1.1 op­er­ates within safe mar­gins. Muse Spark 1.1 demon­strates strong re­sis­tance to di­rect jail­breaks and in­di­rect at­tacks from un­trusted data, prompt in­jec­tion, and de­vel­oper-prompt at­tacks. Consequently, it shows bet­ter ad­ver­sar­ial ro­bust­ness, lower hal­lu­ci­na­tion rates, and re­duced syco­phancy.

Our full safety pos­ture for 1.1 is doc­u­mented in our Muse Spark 1.1 Evaluation Report.

Availability

For the first time, de­vel­op­ers can be­gin build­ing with Muse Spark 1.1 via the new Meta Model API, now in pub­lic pre­view. Early part­ners of Muse Spark 1.1 praise the model as a com­plete agen­tic foun­da­tion, pair­ing long con­text han­dling with strong cod­ing and rea­son­ing ca­pa­bil­i­ties to han­dle large-scale agen­tic work­loads.

“What’s most im­pres­sive about Muse Spark is how much it packs into one model: mas­sive mil­lion-to­ken con­text, full mul­ti­modal sup­port (images, video, PDFs), built-in search with ci­ta­tions, strong rea­son­ing, top-tier cod­ing abil­i­ties (particularly fron­tend and de­sign), struc­tured out­put, and par­al­lel tool call­ing — all in a clean OpenAI-compatible pack­age. A com­plete agen­tic foun­da­tion.”

— Amjad Masad, CEO of Replit

“Meta is clearly build­ing for se­ri­ous agen­tic cod­ing — strong tool use at a price point that makes it vi­able to run real cod­ing work­loads at scale. That com­bi­na­tion is rare, and it’s ex­actly why we wanted Cline de­vel­op­ers to have ac­cess early.”

— Saoud Rizwan, CEO of Cline

“When tested against Box’s en­ter­prise work eval­u­a­tion set, Muse Spark de­liv­ered en­ter­prise ca­pa­bil­i­ties com­pet­i­tive with to­day’s lead­ing fron­tier mod­els. That level of in­tel­li­gence, com­bined with its strengths in struc­tured, pro­ce­dural work­flows across in­dus­tries such as pro­fes­sional ser­vices, pub­lic sec­tor, and in­dus­trial op­er­a­tions, makes it a com­pelling choice for or­ga­ni­za­tions.”

— Yashodha Bhavnani, VP of AI Products at Box

We’re thrilled to be re­leas­ing Muse Spark 1.1, a tes­ta­ment to our re­search mo­men­tum. We have even more ca­pa­ble mod­els in train­ing and look for­ward to shar­ing what’s to come.

Written by:

Meta Superintelligence Labs

Share:

Today, we’re ex­cited to in­tro­duce Muse Spark 1.1, the lat­est model from Meta Superintelligence Labs and a sig­nif­i­cant up­grade from Muse Spark. Muse Spark 1.1 is a mul­ti­modal rea­son­ing model built for agen­tic tasks, with ma­jor gains in tool and com­puter use, cod­ing, and mul­ti­modal un­der­stand­ing.

With these im­prove­ments, Muse Spark 1.1 ad­vances the per­for­mance-ef­fi­ciency fron­tier. Together with this week’s launch of Muse Image, this re­lease brings us closer to our vi­sion of per­sonal su­per­in­tel­li­gence: mod­els that help you pur­sue your goals, cre­ate what you imag­ine, deepen your re­la­tion­ships, and take ac­tion on what you value most.

Along with this re­lease, we are launch­ing a pub­lic pre­view of the new Meta Model API where de­vel­op­ers can ac­cess Muse Spark 1.1. The model is avail­able now in “Thinking” mode in the Meta AI app and on meta.ai.

Evaluations

Agents

Muse Spark 1.1 de­liv­ers ex­cep­tional per­for­mance in per­sonal agen­tic tasks that re­quire plan­ning and or­ches­tra­tion across a range of ex­ter­nal apps and ser­vices. It zero-shot gen­er­al­izes to new na­tive tools, MCP servers, and cus­tom skills.

It tack­les com­plex pro­jects sig­nif­i­cantly faster than Muse Spark, as it is trained to or­ches­trate multi-agent sys­tems to op­ti­mize end-to-end la­tency. As the main agent, it can gather con­text, make a plan, and del­e­gate ex­e­cu­tion across par­al­lel sub­agents. As a sub­agent, it ad­heres to its job, un­der­stands avail­able tools, and knows when to es­ca­late back to the main agent.

Muse Spark 1.1 can ac­tively man­age its con­text win­dow of 1 mil­lion to­kens. It re­mem­bers ac­tions, re­trieves in­for­ma­tion from much ear­lier work, and com­pacts in a way that keeps the crit­i­cal steps needed for later work.

Computer Use

Muse Spark 1.1 ex­cels at com­puter-use work­flows that un­fold across mul­ti­ple ap­pli­ca­tions with in­for­ma­tion chang­ing on-the-fly. It main­tains con­text across ex­tended ses­sions, adapts to evolv­ing re­quire­ments, and nav­i­gates un­fa­mil­iar in­ter­faces with min­i­mal hu­man in­ter­ven­tion.

Rather than rea­son­ing through every desk­top step one click at a time, Muse Spark 1.1 un­der­stands when to au­to­mate and when to use the in­ter­face di­rectly. We trained the model to write scripts when au­toma­tion is faster, click when di­rect in­ter­ac­tion is sim­pler, and gen­er­ate batches of ac­tions at each step.

Agentic din­ner party or­ga­ni­za­tion: In real-world ap­pli­ca­tions, new con­text arises that changes the task. Muse Spark 1.1 no­tices these changes when plac­ing the din­ner or­der and makes nec­es­sary up­dates with­out user in­ter­ven­tion.

Coding

Coding per­for­mance for Muse Spark 1.1 im­proved sub­stan­tially on real-world tasks in­volv­ing large, com­plex code­bases. It can di­ag­nose and fix com­plex bugs, im­ple­ment new fea­tures in en­ter­prise-grade sys­tems, and ex­e­cute large code mi­gra­tions. In use cases like cre­at­ing web ap­pli­ca­tions and end-to-end ques­tion an­swer­ing, Muse Spark 1.1 shows large gains over our first model.

We trained our model to smoothly adapt to di­verse har­nesses and re­li­ably han­dle com­plex multi-turn dy­nam­ics. Muse Spark 1.1 per­forms well with pop­u­lar agen­tic cod­ing se­tups, sup­port­ing com­mon fea­tures like plan­ning mode, goal con­di­tion­ing, sub­agent del­e­ga­tion, and con­text com­paction.

Debugging demo in OpenCode: Muse Spark 1.1 builds a chat web app, takes au­to­mated screen­shots to iden­tify user-vis­i­ble fail­ures, traces is­sues back to rel­e­vant code to im­ple­ment fixes, and val­i­dates these changes. The model seam­lessly com­bines cod­ing, mul­ti­modal un­der­stand­ing, and tool call­ing.

Across Meta, de­vel­op­ers and re­searchers are us­ing Muse Spark 1.1 daily to build faster and work smarter. On our pri­mary in­ter­nal cod­ing eval­u­a­tion, Meta Internal Coding Bench, Muse Spark 1.1 sig­nif­i­cantly im­proves upon Muse Spark and is com­pet­i­tive with lead­ing al­ter­na­tives.

Researchers are now also au­tomat­ing model de­vel­op­ment and eval­u­a­tion tasks by lever­ag­ing Muse Spark 1.1 in their work­flows.

DeepSWE eval­u­a­tion in OpenCode: Muse Spark 1.1 eval­u­ates it­self on a sub­set of DeepSWE tasks across dif­fer­ent rea­son­ing strengths and pro­duces an analy­sis dash­board based on the re­sults.

Multimodal

Along with cod­ing and agen­tic ca­pa­bil­i­ties, Muse Spark 1.1 ex­cels in per­cep­tion, mul­ti­modal rea­son­ing, and tool use. It can in­ter­act with real en­vi­ron­ments and pro­duce grounded out­puts with strengths in vi­sual-to-code ar­ti­fact gen­er­a­tion, ul­tra-de­scrip­tive im­age and video cap­tion­ing, and agen­tic work­flow ex­e­cu­tion for mul­ti­modal use cases.

Muse Spark 1.1’s mul­ti­modal ca­pa­bil­i­ties are es­pe­cially valu­able when per­cep­tion and ac­tion need to hap­pen to­gether. The model can in­spect vi­sual and au­dio, pre­serve de­tails across a long work­flow, and use those de­tails while op­er­at­ing com­put­ers on the user’s be­half.

Facebook Marketplace agent: Using video shot from a smart­phone, Muse Spark 1.1 ex­tracts use­ful pho­tos and rea­sons about the prod­uct to op­er­ate a user’s browser and make a Facebook Marketplace list­ing on the user’s be­half.

Safety

We con­ducted ex­ten­sive safety eval­u­a­tions be­fore de­ploy­ment, fol­low­ing the Advanced AI Scaling Framework, which de­fines eval­u­a­tions, threat mod­els, and de­ploy­ment thresh­olds for our most ad­vanced mod­els.

Across all fron­tier risk cat­e­gories — Chemical & Biological, Cybersecurity, and Loss of Control — our eval­u­a­tions show Muse Spark 1.1 op­er­ates within safe mar­gins. Muse Spark 1.1 demon­strates strong re­sis­tance to di­rect jail­breaks and in­di­rect at­tacks from un­trusted data, prompt in­jec­tion, and de­vel­oper-prompt at­tacks. Consequently, it shows bet­ter ad­ver­sar­ial ro­bust­ness, lower hal­lu­ci­na­tion rates, and re­duced syco­phancy.

Our full safety pos­ture for 1.1 is doc­u­mented in our Muse Spark 1.1 Evaluation Report.

Availability

For the first time, de­vel­op­ers can be­gin build­ing with Muse Spark 1.1 via the new Meta Model API, now in pub­lic pre­view. Early part­ners of Muse Spark 1.1 praise the model as a com­plete agen­tic foun­da­tion, pair­ing long con­text han­dling with strong cod­ing and rea­son­ing ca­pa­bil­i­ties to han­dle large-scale agen­tic work­loads.

“What’s most im­pres­sive about Muse Spark is how much it packs into one model: mas­sive mil­lion-to­ken con­text, full mul­ti­modal sup­port (images, video, PDFs), built-in search with ci­ta­tions, strong rea­son­ing, top-tier cod­ing abil­i­ties (particularly fron­tend and de­sign), struc­tured out­put, and par­al­lel tool call­ing — all in a clean OpenAI-compatible pack­age. A com­plete agen­tic foun­da­tion.”

— Amjad Masad, CEO of Replit

“Meta is clearly build­ing for se­ri­ous agen­tic cod­ing — strong tool use at a price point that makes it vi­able to run real cod­ing work­loads at scale. That com­bi­na­tion is rare, and it’s ex­actly why we wanted Cline de­vel­op­ers to have ac­cess early.”

— Saoud Rizwan, CEO of Cline

“When tested against Box’s en­ter­prise work eval­u­a­tion set, Muse Spark de­liv­ered en­ter­prise ca­pa­bil­i­ties com­pet­i­tive with to­day’s lead­ing fron­tier mod­els. That level of in­tel­li­gence, com­bined with its strengths in struc­tured, pro­ce­dural work­flows across in­dus­tries such as pro­fes­sional ser­vices, pub­lic sec­tor, and in­dus­trial op­er­a­tions, makes it a com­pelling choice for or­ga­ni­za­tions.”

— Yashodha Bhavnani, VP of AI Products at Box

“Muse Spark 1.1 is an awe­some model for run­ning agents. Fast, pow­er­ful, and fun with OpenClaw.”

— Dave Morin, OpenClaw Foundation

We’re thrilled to be re­leas­ing Muse Spark 1.1, a tes­ta­ment to our re­search mo­men­tum. We have even more ca­pa­ble mod­els in train­ing and look for­ward to shar­ing what’s to come.

Written by:

Meta Superintelligence Labs

Share:

Jul 4, 2026 6:30 AM

Apple built a tool for peo­ple with cog­ni­tive dis­abil­i­ties, but I ac­ci­den­tally dis­cov­ered it’s also the best kids’ phone setup no one is talk­ing about—not even Apple.

Photo-Illustration: WIRED Staff; Getty Images; Courtesy of Apple

I have been look­ing at clas­sic dumb phones for months. Not out of nos­tal­gia—though the first phone I bought with my own money was the Nokia 8210, and I still think about it (launched in October 1999 at Paris Fashion Week, it was then the world’s small­est and light­est mo­bile). But the day I’ve been dread­ing has come: It’s fi­nally time for my son to get his first phone.

Come September, he will have to walk across town to school on his own. But if he’s go­ing to be walk­ing around out in the world with­out me, then a track­ing tag won’t cut it. He is far too young to have un­fet­tered ac­cess to the in­ter­net and so­cial me­dia plat­forms, but what if he gets lost? A clas­sic Nokia, sup­ply­ing just texts and calls, won’t come to his aid. Maps and sat­nav re­quire a web con­nec­tion.

In short, he needs a smart­phone that’s not a smart­phone. As a fam­ily deeply em­bed­ded in the Apple ecosys­tem, we first looked to set dra­con­ian re­stric­tions on my child’s Apple ac­count. But, amaz­ingly, it im­me­di­ately be­came ob­vi­ous that it is im­pos­si­ble to block the use of Safari on iOS. Yes, you can re­strict ac­cess to the app, but chil­dren have quickly found workarounds for such mea­sures, such as ask­ing friends to mes­sage them links, which can by­pass re­stric­tions when opened.

There are third-party apps such as Dumb Phone for iPhones and the Minimalist Phone app for Android users, but what irks me about these is that they charge you for the priv­i­lege of re­mov­ing ac­cess to ap­pli­ca­tions from your phone. Not adding—re­mov­ing. My head can’t fathom the logic of pay­ing for things to be taken away from a phone.

Surely there must be a way to set up an iPhone as the per­fect dumb phone for chil­dren—one with ac­cess to only the apps you deem ap­pro­pri­ate, no in­ter­net browser, but with all-im­por­tant track­ing and nav­i­ga­tion abil­i­ties—with­out hav­ing to pay an­other com­pany to make it work? Well, there is. It’s been hid­ing in the iOS Accessibility menu the whole time. And, in­ex­plic­a­bly, it’s a fea­ture Apple barely talks about.

My son’s stripped-back iPhone run­ning just six apps. No in­ter­net al­lowed but with nav­i­ga­tion in case he gets lost.

It’s called Assistive Access. Introduced with iOS 17, Apple de­signed it for those with cog­ni­tive dis­abil­i­ties. If you’ve never en­coun­tered or stum­bled across it, it’s a dis­tinc­tive iOS ex­pe­ri­ence: fewer op­tions, more fo­cused fea­tures, eas­ier to nav­i­gate. The aes­thetic is ideal for kids: large, friendly tiles for the apps re­place the smaller icons of the “normal” Apple in­ter­face.

Here’s how you set it up: Head into Settings, tap Accessibility, scroll down to the General sec­tion at the very bot­tom, and tap Assistive Access. Now, tap Set Up Assistive Access, then Continue. It will then ask you to se­lect your pre­ferred ap­pear­ance: rows or a grid. I sug­gest choos­ing a grid. This is how you get those su­per-large tiles. Now the OS will ask you to se­lect al­lowed apps—tap the green plus icon next to the apps you want to al­low.

Crucially, this is where, un­like with Apple’s stan­dard child screen-time re­stric­tions, you can choose to com­pletely block in­ter­net brows­ing by sim­ply not al­low­ing Safari, Chrome, or any other sim­i­lar app. And, un­like with those screen-time re­stric­tions, if some­one texts your child a link, it won’t work. Why? Assistive Access is de­signed to pre­vent ac­ci­den­tal nav­i­ga­tion, so the sys­tem re­stricts un­ex­pected web brows­ing.

Even though Assistive Access on Apple de­vices al­lows in­ter­net ac­cess, it is heav­ily re­stricted by de­sign, and it’s turned off by de­fault. In this mode, the phone treats any link in a mes­sage as plain text, pre­vent­ing the user from ac­ci­den­tally leav­ing the sim­pli­fied in­ter­face.

Made for care­givers or trusted sup­port­ers, the user must specif­i­cally add in­ter­net-en­abled apps like Messages, Safari, or third-party web apps to the Assistive Access in­ter­face. And once you add, say, Messages or Calls, you then choose whether your child can con­tact or be con­tacted by every­one, their con­tacts only, or just se­lected fa­vorites.

You can even choose to have the key­pad or speaker be avail­able in Calls. Want the time dis­played on the lock screen? Check that box. Make the mute switch in­op­er­a­ble? Tick. Decide how no­ti­fi­ca­tions ap­pear? That too. The Music app only ac­cesses playlists you preap­prove. It’s all, well, child’s play to put to­gether.

Once you’re happy with your kid-ap­pro­pri­ate apps, you set a unique four-digit Assistive Access pass­code. This lets you turn the sim­pli­fied OS on and off. To leave Assistive Access, triple-click the side but­ton on Face ID de­vices or the Home but­ton on iPhones with Touch ID, and it’ll bring up the pass­code prompt that lets the de­vice switch back to the nor­mal iPhone in­ter­face.

You set up a unique pass­code to turn Assistive Access mode on or off.

It’s pos­si­ble to al­lows apps that use the in­ter­net, such as Maps, but bar web browsers com­pletely.

My cho­sen setup? My son only gets Calls, Messages, Maps, Camera (so we can video call, but I’ve ruth­lessly turned off self­ies), Photos, and Music. Nothing else. I’ve turned an old, un­used iPhone 13 lan­guish­ing in a drawer into the best six-app dumb phone money has­n’t bought. Not a bad thing at a time when Apple’s prices are sky­rock­et­ing.

What’s more, this can now grow with him. Right now, I’m toy­ing with adding Wallet so he can pay for things with his Acorns Early ac­count. If I want to add Safari or Spotify or a game or two in the fu­ture, a delve back into the Assistive app set­tings lets me do so with one press. And I’m se­cure in the knowl­edge that there is ab­solutely no workaround here. In this mode, my child is in­ca­pable of do­ing any­thing that re­quires nav­i­gat­ing stan­dard iOS Settings or sys­tem user in­ter­face lay­ers. Unless he gets my Assistive Access pass­code, what I deem off-lim­its re­mains off-lim­its.

It’s nearly all up­side and no down­side. A cus­tomiz­able, com­pletely safe dumb phone with no monthly fee but with the added ben­e­fit of FaceTime, nav­i­ga­tion, and Find My track­ing, made from a de­vice I had ly­ing in a drawer that slots straight into our fam­i­ly’s Apple ecosys­tem.

When I first set the phone up, I was wor­ried I was miss­ing some­thing, that this so­lu­tion could not be as good as it ap­peared. So I took the iPhone into an Apple Store and showed it to a sup­port staffer. “What have you done?” he said, look­ing in­cred­u­lously at my son’s iPhone with its six dumb tiles. “This is a much bet­ter so­lu­tion than Screen Time. I’m go­ing to have to tell my col­leagues about this.” I told him it was Assistive Access. “We don’t get trained on that,” he ad­mit­ted. “But this is great.”

Yes, it’s odd that Apple does­n’t train all its store staff on this laud­able fea­ture, but it’s baf­fling that it does­n’t shout about how good Assistive Access is for mak­ing a kid’s dumb phone. I asked Apple di­rectly why it does­n’t mar­ket this buried fea­ture in this way. Has it ever con­sid­ered mak­ing a ver­sion of Assistive Access for chil­dren, a kids’ OS, in ef­fect? While Apple helped me with all my tech­ni­cal queries for this piece, it de­clined to an­swer these ques­tions.

It’s more than a lit­tle in­ter­est­ing that the com­ing re­vamped Screen Time drop­ping in iOS 27 this September adopts some of the key ben­e­fits of Assistive Access, in par­tic­u­lar the abil­ity, for the first time, to re­move ac­cess to Safari when set­ting up a child’s pro­file.

So, what’s the down­side? Well, Assistive Access runs slug­gish, but my kid was so ex­cited to get a phone, he did­n’t care one bit. Initially, Assistive Access did not rec­og­nize Screen Time lim­its and would com­pletely over­ride them, how­ever since iOS26 dropped in 2025 Apple has tweaked the mode so thank­fully it does now link with screen lim­its that have been set up. Voicemail, how­ever, is dis­abled in Assistive Access, mean­ing par­ents will have to rely on texts if a child does­n’t an­swer a call. You also can­not turn off an iPhone in Assistive Access mode; you have to re­vert it to nor­mal iOS to do this.

Perhaps more wor­ry­ingly, on one oc­ca­sion, my son man­aged to freeze the Messages app in Assistive Access mode by try­ing to search through loads of emo­jis. I was even able to re­peat this freez­ing when he showed me what he did. The only way to un­freeze Messages was to take it out of Assistive Access mode, then put it back in—some­thing he can­not do on his own. He was able to use the other five apps just fine when Messages fell over, though.

So far, there have been no other is­sues, apart from wor­ry­ing my son will now lose an ex­pen­sive iPhone—but at least we’ll be able to track it, just as we did when he left it at school the other day.

Jeremy White is se­nior in­no­va­tion ed­i­tor at WIRED, over­see­ing gear cov­er­age, with a fo­cus on EVs and lux­ury. He also ed­its gear for the US and UK print edi­tions. Prior to WIRED, he was a dig­i­tal ed­i­tor at the Financial Times and tech ed­i­tor at Esquire in the UK. And … Read More

Wired Coupons

REG AD

SYSTEMS

In pro­duc­tion on mil­lions of boxes and the pay­off is a 25% re­duc­tion in ma­chines needed for some in­fer­ence work­loads

Meta is re­cov­er­ing DDR4 mem­ory from old servers, in­stalling it in new ma­chines, and us­ing a cus­tom Compute Express Link (CXL) ASIC to share the mem­ory across ap­pli­ca­tions — with­out en­coun­ter­ing la­tency prob­lems.

The so­cial net­work­ing gi­ant calls its tech “Vistara” and will pre­sent it at ISCA 2026 on Monday, but The Register found the com­pa­ny’s pa­per ahead of the talk. Our sis­ter site, Blocks and Files, also hap­pens to have re­ported on this on Friday.

The doc­u­ment opens with the ad­mis­sion that Meta can’t in­crease the amount of mem­ory in around 40 per­cent of its vast server fleet, mean­ing mil­lions of servers can’t han­dle some of its work­loads. That’s un­for­tu­nate be­cause the ex­pected ser­vice life of its servers is three to five years, but mem­ory is use­ful for seven to ten years.

REG AD

Meta’s re­sponse is to rip DDR4 DIMMs from old servers, put them into new ma­chines that rely on DDR5, and turn it all into a pool of ca­pac­ity — which in the­ory makes it pos­si­ble to com­pose vir­tual servers that share re­sources across mul­ti­ple phys­i­cal hosts.

REG AD

The pa­per points out that CXL is hard to put into pro­duc­tion be­cause shar­ing mem­ory across hosts can mean low band­width, high la­tency, and ex­tra com­put­ing over­heads to man­age ad­di­tional mem­ory lay­ers. Those prob­lems can arise in sys­tems that com­bine dif­fer­ent mem­ory tech­nolo­gies. Meta wanted to blend mem­ory types in a sin­gle ma­chine but found off-the-shelf CXL kit can’t do the job.

“Most CXL so­lu­tions bun­dle DRAM with the con­troller — pre­vent­ing DIMM reuse — and of­ten omit DDR4 sup­port, which is a re­quire­ment for re­pur­pos­ing older mem­ory,” the pa­per states. “Additionally, their high power con­sump­tion and high cost fur­ther limit their ap­peal.”

To make CXL sing, Meta cre­ated a cus­tom ASIC called “Vistara.”

“At its core, the Vistara ASIC is de­signed to bridge DDR4 mem­ory to host proces­sors via a CXL 2.0/1.1-compliant PCIe Gen5 x16 in­ter­face,” the pa­per ex­plains. “Each Vistara ASIC in­te­grates two in­de­pen­dent 72-bit DDR4 mem­ory chan­nels, sup­port­ing speeds up to 3,200 MT/s and up to 256 GB per chip with 64 GB DIMMs.”

A pair of cus­tom RISC-V proces­sors drive the ASICs.

Vistara hard­ware lives in de­vices Meta calls a “MemServer” pow­ered by an AMD Turin proces­sor pack­ing 158 cores and run­ning 316 threads. Each MemServer com­bines 768 GB of DDR5 mem­ory along­side 256 GB of DDR4 con­nected through Vistara ASICs.

“The Vistara CXL cards are in­stalled in ded­i­cated rear-ac­ces­si­ble slots within each MemServer chas­sis,” the pa­per re­veals. “To man­age the in­creased ther­mal load from high-den­sity mem­ory and CXL de­vices, the chas­sis em­ploys di­rected air­flow with high-ca­pac­ity fans that chan­nel cool air di­rectly across the Vistara mod­ules, for sta­ble op­er­a­tion un­der heavy work­loads.”

The soft­ware side of Vistara sees the DDR4 pre­sented to the OS “as a dis­tinct, CPU-less NUMA node, sep­a­rate from the lo­cal DRAM nodes di­rectly at­tached to the proces­sor.” Meta’s plat­forms first use all avail­able lo­cal DDR4, then em­ploy the CXL-enabled mem­ory when needed.

REG AD

Zuck’s house of hy­per­scale hyp­no­tism makes this hap­pen with cus­tom tweaks to the Linux CXL dri­ver. “All Linux ker­nel CXL dri­ver code in use for Vistara is ei­ther pre­sent in the up­stream ker­nel, or is on its way to be­ing in­cluded in the up­stream ker­nel,” the pa­per states.

The pa­per says Meta has put this CXL stuff to work “in hy­per­scale in­fra­struc­ture with mil­lions of servers, across a va­ri­ety of pro­duc­tion work­loads, in­clud­ing dis­ag­gre­gated ML in­fer­ence (embedding ta­bles in rec­om­men­da­tion sys­tems), big data pro­cess­ing, data­bases, dis­trib­uted caches, and CI/CD build sys­tems.”

Some work­loads, in­clud­ing big data tools such as Spark and Hive, use ter­abyte and petabyte-scale datasets, and need hun­dreds of gi­ga­bytes of mem­ory per job. The pa­per says that if those work­loads ex­pe­ri­ence out-of-mem­ory events, it can “disrupt crit­i­cal busi­ness an­a­lyt­ics and ML pipelines.”

“The ex­panded mem­ory head­room pro­vided by CXL en­hances sys­tem re­li­a­bil­ity,” the pa­per ex­plains. “By mit­i­gat­ing the risk of out-of-mem­ory (OOM) events, CXL re­duces the fre­quency of job fail­ures and the as­so­ci­ated over­head of job restarts and re­source frag­men­ta­tion by 33 per­cent.”

Meta says the sys­tem also cuts in­fra­struc­ture costs. “These de­ploy­ments have demon­strated large ben­e­fits, such as re­duc­ing the server count by up to 25 per­cent for dis­ag­gre­gated in­fer­ence,” the pa­per states. And of course Meta is avoid­ing the sky-high mem­ory prices caused by the RAMpocalypse. ®