10 interesting stories served every morning and every evening.

openai.com

GitHub - JustVugg/colibri: Run GLM-5.2 (744B MoE) on a 25GB-RAM consumer machine — pure C, zero deps, experts streamed from disk. Tiny engine, immense model. 🐦

github.com

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.

A Train Sim Created By Just One Person Is Being Called The Best Ever Made

kotaku.com

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.

Tencent Hy

hy.tencent.com

The Glass Backbone: Why the Army’s Logistics Will Break in the Next War - Modern War Institute

mwi.westpoint.edu

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

Introducing Muse Spark 1.1

ai.meta.com

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:

Introducing Muse Spark 1.1

ai.meta.com

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:

This Buried Apple Feature Turns an iPhone Into the Perfect Kids’ Dumb Phone

www.wired.com

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

openai.com

Zuck saves Meta bucks by reusing memory from old servers with a custom CXL ASIC

www.theregister.com

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. ®

To add this web app to your iOS home screen tap the share button and select "Add to the Home Screen".

10HN is also available as an iOS App

If you visit 10HN only rarely, check out the the best articles from the past week.

Visit pancik.com for more.