Everyone has shared the frus­tra­tion of wait­ing for an el­e­va­tor that never seems to ar­rive. “I pressed the but­ton, why is­n’t it com­ing?” you ask. For some­thing as com­mon­place as el­e­va­tors, they are far more com­plex than meets the eye.

Over the course of this ar­ti­cle, we’ll un­ravel the mys­ter­ies of el­e­va­tors. The way you push their but­tons, and how they push yours.

One Car

The sim­plest el­e­va­tor al­go­rithm is called SCAN and was patented in 1961. The el­e­va­tor starts at the lobby and goes all the way to the top floor be­fore re­vers­ing and com­ing back down. It picks up and drops off any­body on the way.

Most of the time you don’t ac­tu­ally need to go to the TOP floor. If the el­e­va­tor goes only as high as re­quested be­fore re­vers­ing, the al­go­rithm is called the LOOK al­go­rithm. This is the al­go­rithm most peo­ple know and ex­pect.

Multiple Cars

Here’s where the mys­tery be­gins. If there are mul­ti­ple el­e­va­tors, how do the cars co­or­di­nate who picks up who?

In the most ba­sic sys­tem, there’s a cen­tral sched­uler that tells each el­e­va­tor which floors to stop on. When a new re­quest comes in, it’s as­signed to the clos­est el­e­va­tor. As we’ll soon see how­ever, we can do bet­ter.

Long Waits

How do you ac­tu­ally mea­sure how good an el­e­va­tor al­go­rithm is? The ob­vi­ous met­ric is how long you wait for the el­e­va­tor to ar­rive.

A very sim­ple mea­sure is “how of­ten does the el­e­va­tor ar­rive within 30 sec­onds?” Or “how of­ten does the el­e­va­tor ar­rive within 90 sec­onds?”

-

wait < 30s

-

wait < 90s

flow14/​min

Applied Stats

More rig­or­ously, we want to look at the DISTRIBUTION of wait times. If we plot the wait time across thou­sands of rides, we get the his­togram be­low.

010s

p50—p90—

flow14/​min

A p90 of 2m means 90% of the time, rid­ers wait 2m or less for the el­e­va­tor. A p50 of 1m means half the time the el­e­va­tor ar­rives within 1m.

People don’t usu­ally re­mem­ber the av­er­age amount of time they wait. They fix­ate on those times when the el­e­va­tor took FOREVER, the p90 case.

Morning Rush

Not all pas­sen­ger traf­fic is cre­ated equal. Imagine a large cor­po­rate of­fice build­ing. In the morn­ings, nearly all traf­fic is dom­i­nated by trips from the lobby to the up­per lev­els.

In the evening this flips as every­one leaves the build­ing. The lunch rush is a bit of both, and the re­main­ing traf­fic is of­ten from floor to floor.

-

wait < 30s

-

wait < 90s

flow14/​min

The dis­tri­b­u­tion of wait times varies dras­ti­cally de­pend­ing on the time of day and the traf­fic pat­terns the el­e­va­tors are fac­ing. Morning rush no­to­ri­ously has the worst wait sta­tis­tics.

Smarter Elevators

When an­a­lyz­ing the LOOK el­e­va­tor al­go­rithm, we LOOKED (ha ha) at how rid­ers are as­signed to cars. We naively as­signed each re­quest to the near­est car but said we could do bet­ter.

What if the near­est car is full? We can get smarter with Otis’ RSR (Relative System Response) al­go­rithm. RSR scores each car for how well suited it is to pick up a pas­sen­ger. Lower scores be­ing bet­ter.

RSR pickup score

Score=ETA to pickup+on­board load penalty+same-di­rec­tion anti-bunch­ing penalty-di­rec­tion-match bonus-idle-nearby bonus-low-load bonus

RSR also re-op­ti­mizes every 5 sec­onds. A pas­sen­ger that’s go­ing to be picked up by el­e­va­tor A can be re-routed to el­e­va­tor B if el­e­va­tor A en­coun­ters de­lays. This re-op­ti­miza­tion turns out to be key for stream­lin­ing traf­fic flow.

In the graphic be­low, each el­e­va­tor lights up when it’s the best choice to ser­vice a call from floor 3 if the but­ton hap­pened to be pressed at that ex­act mo­ment. This con­stantly changes as the el­e­va­tors move, show­ing the op­ti­mizer in mo­tion.

LOOK vs RSR

Armed with our el­e­va­tor analy­sis toolkit, we can bench­mark the per­for­mance of LOOK vs RSR to see how much a smarter el­e­va­tor al­go­rithm ac­tu­ally im­proves wait time.

LOOK

-wait < 30s

-wait < 90s

RSR

-wait < 30s

-wait < 90s

flow8/​min

Interestingly as the flow rate gets higher, LOOK ac­tu­ally starts to out­per­form RSR. When the el­e­va­tors are al­ways full and stop­ping on every floor, the ex­tra rules don’t mat­ter as much.

LOOK also tends to out­per­form RSR in small build­ings with fewer el­e­va­tors per bank. Sometimes it’s bet­ter to just keep things sim­ple.

Another met­ric you can track is jour­ney time, how long you’re ac­tu­ally wait­ing in the el­e­va­tor be­fore get­ting to your floor. RSR and LOOK have dif­fer­ent char­ac­ter­is­tics here as well but that’s be­yond the scope of this ar­ti­cle.

Destination Dispatch

Not all el­e­va­tors have but­tons in them. Some of the fancy new el­e­va­tors have a kiosk on each floor that al­lows you to spec­ify what floor you’re head­ing to be­fore the el­e­va­tor even ar­rives. The kiosk then points you to which el­e­va­tor you should wait for.

This is called Destination Dispatch. At first glance, it seems great. The el­e­va­tor op­ti­mizer now has full knowl­edge of who is go­ing where, cer­tainly we can use this to re­duce wait times right?

RSR

-wait < 30s

-wait < 90s

Destination Dispatch

-wait < 30s

-wait < 90s

flow8/​min

It turns out these fancy kiosks are in gen­eral worse for wait times com­pared to the tra­di­tional good ol’ up and down but­tons. There are cer­tainly edge cases when the kiosks can win out (extremely tall build­ings with 8+ cars per el­e­va­tor bank) but for the ma­jor­ity of cases, sim­ple up down but­tons reign supreme.

This coun­ter­in­tu­itive re­sult is all thanks to the re­bal­anc­ing step where every 5 sec­onds, the sys­tem re-op­ti­mizes each el­e­va­tor’s path. The kiosk en­forces rigid­ity, you must get in the as­signed el­e­va­tor.

The state of the world 30sec af­ter you called your el­e­va­tor might be very dif­fer­ent but the sys­tem is un­able to adapt. Turns out the loss in flex­i­bil­ity is not worth the ex­tra in­for­ma­tion for the op­ti­mizer.

Full Sim

Here’s a sim­u­la­tion with all the but­tons and knobs to play with. Go crazy!

-

wait < 30s

-

wait < 90s

floors8­cars4flow18/​min

Conclusion

This ar­ti­cle just scratches the sur­face of el­e­va­tor al­go­rithms. Next time you’re stuck wait­ing for an el­e­va­tor, try not to take it per­son­ally. The el­e­va­tor did hear you, it just has a lot to think about.

📰  Tech Blog |     📄  Full Report

1. Model Introduction

Kimi K3 is an open-weight, na­tive mul­ti­modal agen­tic model and our most ca­pa­ble model to date. It is a 2.8T-parameter model built on Kimi Delta Attention (KDA) and Attention Residuals (AttnRes), with na­tive vi­sion ca­pa­bil­i­ties and a 1-million-token con­text win­dow. It is the world’s first open 3T-class model, de­signed for fron­tier in­tel­li­gence across long-hori­zon cod­ing, knowl­edge work, and rea­son­ing.

Key Features

New Architecture: Kimi K3 is built on Kimi Delta Attention (KDA) and Attention Residuals (AttnRes), and scales up MoE spar­sity with a Stable LatentMoE frame­work that ac­ti­vates 16 out of 896 ex­perts — yield­ing an ap­prox­i­mate 2.5× im­prove­ment in over­all scal­ing ef­fi­ciency over Kimi K2.

Long-Horizon Coding: Operating with min­i­mal hu­man over­sight, Kimi K3 sus­tains long en­gi­neer­ing ses­sions, nav­i­gates mas­sive repos­i­to­ries, and or­ches­trates ter­mi­nal tools — from GPU ker­nel op­ti­miza­tion and com­piler de­vel­op­ment to vi­sion-in-the-loop game dev, CAD, and even chip de­sign.

Agentic Knowledge Work: Kimi K3 ad­vances end-to-end knowl­edge work, pro­duc­ing deep re­search with in­ter­ac­tive vi­su­al­iza­tions, wid­gets and dash­boards, and mo­tion de­sign and video edit­ing, pow­ered by its na­tive mul­ti­modal ar­chi­tec­ture.

Native Multimodality & Long Context: Kimi K3 un­der­stands text, im­ages, and video within the same model, and sup­ports a 1-million-token con­text win­dow.

Open Frontier Weights: We re­lease the full Kimi K3 model weights un­der the Kimi K3 License, mak­ing fron­tier in­tel­li­gence openly avail­able for re­search, de­ploy­ment, and fur­ther in­no­va­tion.

2. Model Summary

3. Evaluation Results

All Kimi K3 re­sults are ob­tained with rea­son­ing ef­fort set to ‘max’ and tem­per­a­ture = 1.0. For sin­gle-step tasks, such as GPQA Diamond, HLE-Full, and vi­sion bench­marks with­out tools, we set top-p = 0.95; for agen­tic tasks, we set top-p = 1.0. For HLE-Full, MMMU-Pro, CharXiv (RQ), MathVision, and ZeroBench, each cell re­ports the scores with­out and with tool aug­men­ta­tion (general tools for HLE-Full, Python for the vi­sion bench­marks), in that or­der.

Reasoning & knowl­edge bench­marks CritPt and AA-LCR. Scores are cited from Artificial Analysis as of July 23, 2026.

CritPt and AA-LCR. Scores are cited from Artificial Analysis as of July 23, 2026.

Coding bench­marks DeepSWE. Kimi K3 is eval­u­ated with the Kimi Code har­ness. The GLM-5.2 score is taken from the GLM-5.2 re­lease blog; all re­main­ing scores are from the of­fi­cial DeepSWE leader­board, un­der which Kimi K3 at­tains 67.3 with the mini-SWE-agent har­ness. We re­port the DeepSWE v1.1 tasks. Terminal-Bench 2.1. Kimi K3 is eval­u­ated with the Kimi Code har­ness. For all other mod­els, we re­port the best score across har­nesses: GLM-5.2 with Claude Code (GLM-5.2 re­lease blog); Claude Opus 4.8 and Claude Fable 5 with Terminus 2 (Artificial Analysis); GPT-5.5 and GPT-5.6 Sol with Codex (OpenAI). ProgramBench. Kimi K3 is eval­u­ated with the Kimi Code har­ness. The GLM-5.2 score is from the GLM-5.2 re­lease blog; all other scores are from Vals AI. SWE-Marathon. Kimi K3, Claude Opus 4.8, and Claude Fable 5 are eval­u­ated with the Claude Code har­ness; GPT-5.6 Sol is eval­u­ated with the Codex har­ness. The GLM-5.2 score is from the GLM-5.2 re­lease blog. Our eval­u­a­tion is based on an H20-calibrated branch of the of­fi­cial tasks as of July 9, 2026, prior to the fi­nal v1.1 re­lease: the Docker im­ages, per­for­mance gates, and ref­er­ence or­a­cles for the GPU tasks have been re­cal­i­brated for H20, while the cor­rect­ness and anti-cheat val­ida­tors re­main un­changed. Additionally, Claude Fable 5 hit fall­backs on 35% of the tasks in our eval­u­a­tion, which may have neg­a­tively im­pacted its mea­sured per­for­mance. FrontierSWE. Kimi K3 is eval­u­ated with the Kimi Code har­ness and GPT-5.6 Sol with the Codex har­ness; all other re­sults are from FrontierSWE. Dominance scores are re­com­puted from the raw scores us­ing the of­fi­cial eval­u­a­tion script and are cur­rent as of July 16, 2026. PostTrainBench. Scores for GLM-5.2, GPT-5.5, and Claude Opus 4.8 are adopted from the of­fi­cial PostTrainBench re­sults. Kimi K3, Claude Fable 5, and GPT-5.6 Sol are eval­u­ated with the of­fi­cial Harbor im­ple­men­ta­tion at max­i­mum rea­son­ing ef­fort, av­er­aged over three runs on H20 GPUs (instead of H100 in the of­fi­cial set­ting) — Kimi K3 and Claude Fable 5 with the Claude Code har­ness, and GPT-5.6 Sol with the Codex har­ness. MLS-Bench-Lite. Kimi K3 is eval­u­ated with the Kimi Code har­ness; GLM-5.2 and the Claude mod­els with the Claude Code har­ness; GPT-5.5 and GPT-5.6 Sol with the Codex har­ness. SciCode. Scores are cited from Artificial Analysis as of July 23, 2026. Kimi Code Bench 2.0 (in-house). Kimi K3 is eval­u­ated with the Kimi Code har­ness (it at­tains 73.7 with the Claude Code har­ness); GLM-5.2, Claude Opus 4.8, and Claude Fable 5 with the Claude Code har­ness; GPT-5.5 and GPT-5.6 Sol with the Codex har­ness. All mod­els are eval­u­ated at max­i­mum rea­son­ing ef­fort, ex­cept GPT-5.5, which uses the “xhigh” set­ting. As the bench­mark in­cludes cy­ber­se­cu­rity and safety-re­lated tasks, we also dis­close the frac­tion of re­fused or fall­back tasks: Claude Fable 5 hit 13 fall­backs and 1 re­fusal out of 80 tasks; 10 re­fusals out of 80 tasks en­tered GPT-5.6 Sol’s cy­ber guard; GPT-5.5 had 3 re­fusals out of 80 tasks.

DeepSWE. Kimi K3 is eval­u­ated with the Kimi Code har­ness. The GLM-5.2 score is taken from the GLM-5.2 re­lease blog; all re­main­ing scores are from the of­fi­cial DeepSWE leader­board, un­der which Kimi K3 at­tains 67.3 with the mini-SWE-agent har­ness. We re­port the DeepSWE v1.1 tasks.

Terminal-Bench 2.1. Kimi K3 is eval­u­ated with the Kimi Code har­ness. For all other mod­els, we re­port the best score across har­nesses: GLM-5.2 with Claude Code (GLM-5.2 re­lease blog); Claude Opus 4.8 and Claude Fable 5 with Terminus 2 (Artificial Analysis); GPT-5.5 and GPT-5.6 Sol with Codex (OpenAI).

ProgramBench. Kimi K3 is eval­u­ated with the Kimi Code har­ness. The GLM-5.2 score is from the GLM-5.2 re­lease blog; all other scores are from Vals AI.

SWE-Marathon. Kimi K3, Claude Opus 4.8, and Claude Fable 5 are eval­u­ated with the Claude Code har­ness; GPT-5.6 Sol is eval­u­ated with the Codex har­ness. The GLM-5.2 score is from the GLM-5.2 re­lease blog. Our eval­u­a­tion is based on an H20-calibrated branch of the of­fi­cial tasks as of July 9, 2026, prior to the fi­nal v1.1 re­lease: the Docker im­ages, per­for­mance gates, and ref­er­ence or­a­cles for the GPU tasks have been re­cal­i­brated for H20, while the cor­rect­ness and anti-cheat val­ida­tors re­main un­changed. Additionally, Claude Fable 5 hit fall­backs on 35% of the tasks in our eval­u­a­tion, which may have neg­a­tively im­pacted its mea­sured per­for­mance.

FrontierSWE. Kimi K3 is eval­u­ated with the Kimi Code har­ness and GPT-5.6 Sol with the Codex har­ness; all other re­sults are from FrontierSWE. Dominance scores are re­com­puted from the raw scores us­ing the of­fi­cial eval­u­a­tion script and are cur­rent as of July 16, 2026.

PostTrainBench. Scores for GLM-5.2, GPT-5.5, and Claude Opus 4.8 are adopted from the of­fi­cial PostTrainBench re­sults. Kimi K3, Claude Fable 5, and GPT-5.6 Sol are eval­u­ated with the of­fi­cial Harbor im­ple­men­ta­tion at max­i­mum rea­son­ing ef­fort, av­er­aged over three runs on H20 GPUs (instead of H100 in the of­fi­cial set­ting) — Kimi K3 and Claude Fable 5 with the Claude Code har­ness, and GPT-5.6 Sol with the Codex har­ness.

MLS-Bench-Lite. Kimi K3 is eval­u­ated with the Kimi Code har­ness; GLM-5.2 and the Claude mod­els with the Claude Code har­ness; GPT-5.5 and GPT-5.6 Sol with the Codex har­ness.

SciCode. Scores are cited from Artificial Analysis as of July 23, 2026.

Kimi Code Bench 2.0 (in-house). Kimi K3 is eval­u­ated with the Kimi Code har­ness (it at­tains 73.7 with the Claude Code har­ness); GLM-5.2, Claude Opus 4.8, and Claude Fable 5 with the Claude Code har­ness; GPT-5.5 and GPT-5.6 Sol with the Codex har­ness. All mod­els are eval­u­ated at max­i­mum rea­son­ing ef­fort, ex­cept GPT-5.5, which uses the “xhigh” set­ting. As the bench­mark in­cludes cy­ber­se­cu­rity and safety-re­lated tasks, we also dis­close the frac­tion of re­fused or fall­back tasks: Claude Fable 5 hit 13 fall­backs and 1 re­fusal out of 80 tasks; 10 re­fusals out of 80 tasks en­tered GPT-5.6 Sol’s cy­ber guard; GPT-5.5 had 3 re­fusals out of 80 tasks.

Agentic bench­marks OfficeQA Pro. Each test case pro­vides the agent with the en­tire PDF cor­pus, with all PDFs ren­dered as im­ages and no ma­chine-read­able text avail­able. OfficeQA Pro and SpreadsheetBench 2. Kimi K3, GLM-5.2, Claude Opus 4.8, and Claude Fable 5 are eval­u­ated with the Claude Code har­ness; GPT-5.5 and GPT-5.6 Sol are eval­u­ated with the Codex har­ness. MCP-Atlas. All mod­els are eval­u­ated on the 500-task pub­lic sub­set with a 100-turn limit, us­ing Gemini 3.1 Pro as the judge. AutomationBench. All mod­els are eval­u­ated on the 600-task pub­lic sub­set, fol­low­ing the of­fi­cial GitHub setup in all other re­spects. BrowseComp. We adopt a con­text-com­paction strat­egy trig­gered at 300K to­kens. When eval­u­ated with the full 1M-token con­text win­dow and no con­text man­age­ment, Kimi K3 achieves a score of 90.4. The re­sults of Claude Fable 5, Claude Opus 4.8, GPT-5.6 Sol, and GPT-5.5 are cited from Anthropic and OpenAI. GDPval-AA v2, AA-Briefcase, τ³-Bank­ing, Harvey Lab-AA, and APEX-Agents. Scores are cited from Artificial Analysis and the APEX-Agents leader­board as of July 23, 2026. For Harvey Lab-AA, we re­port the cri­te­rion pass rate. CorpFin v2, Finance Agent v2, and Legal Research Bench. Scores are cited from Vals AI. Agents’ Last Exam. Scores are cited from the of­fi­cial leader­board as of July 23, 2026; we re­port the leader­board’s pri­mary pass-rate met­ric. On the leader­board, each model is paired with a spe­cific har­ness: Kimi K3 with Kimi Code; GPT-5.6 Sol and GPT-5.5 with Codex; Claude Fable 5, Claude Opus 4.8, and GLM-5.2 with Claude Code. † The Claude Fable 5 en­try runs at xhigh ef­fort with 40% of tasks an­no­tated as down­graded.

OfficeQA Pro. Each test case pro­vides the agent with the en­tire PDF cor­pus, with all PDFs ren­dered as im­ages and no ma­chine-read­able text avail­able.

OfficeQA Pro and SpreadsheetBench 2. Kimi K3, GLM-5.2, Claude Opus 4.8, and Claude Fable 5 are eval­u­ated with the Claude Code har­ness; GPT-5.5 and GPT-5.6 Sol are eval­u­ated with the Codex har­ness.

MCP-Atlas. All mod­els are eval­u­ated on the 500-task pub­lic sub­set with a 100-turn limit, us­ing Gemini 3.1 Pro as the judge.

AutomationBench. All mod­els are eval­u­ated on the 600-task pub­lic sub­set, fol­low­ing the of­fi­cial GitHub setup in all other re­spects.

BrowseComp. We adopt a con­text-com­paction strat­egy trig­gered at 300K to­kens. When eval­u­ated with the full 1M-token con­text win­dow and no con­text man­age­ment, Kimi K3 achieves a score of 90.4. The re­sults of Claude Fable 5, Claude Opus 4.8, GPT-5.6 Sol, and GPT-5.5 are cited from Anthropic and OpenAI.

GDPval-AA v2, AA-Briefcase, τ³-Bank­ing, Harvey Lab-AA, and APEX-Agents. Scores are cited from Artificial Analysis and the APEX-Agents leader­board as of July 23, 2026. For Harvey Lab-AA, we re­port the cri­te­rion pass rate.

CorpFin v2, Finance Agent v2, and Legal Research Bench. Scores are cited from Vals AI.

Agents’ Last Exam. Scores are cited from the of­fi­cial leader­board as of July 23, 2026; we re­port the leader­board’s pri­mary pass-rate met­ric. On the leader­board, each model is paired with a spe­cific har­ness: Kimi K3 with Kimi Code; GPT-5.6 Sol and GPT-5.5 with Codex; Claude Fable 5, Claude Opus 4.8, and GLM-5.2 with Claude Code. † The Claude Fable 5 en­try runs at xhigh ef­fort with 40% of tasks an­no­tated as down­graded.

Multimodal bench­marks Except for ZeroBench, which fol­lows the of­fi­cial set­ting and is run five times, all mul­ti­modal scores are av­er­aged over three runs. MMMU-Pro is eval­u­ated fol­low­ing the of­fi­cial pro­to­col, pre­serv­ing the orig­i­nal in­put or­der and prepend­ing im­ages to the text in­put. PerceptionBench is an in-house bench­mark that fo­cuses on atomic vi­sual per­cep­tion ca­pa­bil­i­ties.

Except for ZeroBench, which fol­lows the of­fi­cial set­ting and is run five times, all mul­ti­modal scores are av­er­aged over three runs. MMMU-Pro is eval­u­ated fol­low­ing the of­fi­cial pro­to­col, pre­serv­ing the orig­i­nal in­put or­der and prepend­ing im­ages to the text in­put.

PerceptionBench is an in-house bench­mark that fo­cuses on atomic vi­sual per­cep­tion ca­pa­bil­i­ties.

4. Native MXFP4 Quantization

Kimi K3 ap­plies quan­ti­za­tion-aware train­ing from the SFT stage on­ward, us­ing MXFP4 weights with MXFP8 ac­ti­va­tions for broad hard­ware com­pat­i­bil­ity.

5. Deployment

You can ac­cess Kimi K3′s API on https://​plat­form.kimi.ai by se­lect­ing kimi-k3, and we pro­vide OpenAI/Anthropic-compatible API for you. Currently, Kimi K3 is rec­om­mended to run on the fol­low­ing in­fer­ence en­gines:

You can ac­cess Kimi K3′s API on https://​plat­form.kimi.ai by se­lect­ing kimi-k3, and we pro­vide OpenAI/Anthropic-compatible API for you. Currently, Kimi K3 is rec­om­mended to run on the fol­low­ing in­fer­ence en­gines:

vLLM — see recipes

SGLang — see cook­book

TokenSpeed — see recipes

6. Model Usage

Kimi K3 al­ways has think­ing en­abled, and will re­turn rea­son­ing_­con­tent. Thinking ef­fort is con­fig­ured with the top-level rea­son­ing_­ef­fort re­quest field, which sup­ports “low”, “high”, and “max” (default “max”).

Kimi K3 was trained in the pre­served think­ing his­tory mode. For multi-turn con­ver­sa­tions and tool calls, Kimi K3 re­quires the com­plete as­sis­tant mes­sage re­turned by the API to be passed back to mes­sages as-is — in­clud­ing rea­son­ing_­con­tent and tool_­calls, not just con­tent:

im­port ope­nai

def chat_with­_p­re­served_­think­ing(client: ope­nai.Ope­nAI, mod­el_­name: str): mes­sages = [ { “role”: “user”, “content”: “Tell me three ran­dom num­bers.” }, { “role”: “assistant”, “reasoning_content”: “I’ll start by list­ing five num­bers: 473, 921, 235, 215, 222, and I’ll tell you the first three.”, “content”: “473, 921, 235″ }, { “role”: “user”, “content”: “What are the other two num­bers you have in mind?” } ]

re­sponse = client.chat.com­ple­tions.cre­ate( model=mod­el_­name, mes­sages=mes­sages, stream=False, max_­to­kens=4096, rea­son­ing_­ef­fort=“max”, ) # the as­sis­tant should men­tion 215 and 222 that ap­pear in the prior rea­son­ing con­tent print(f”re­sponse: {response.choices[0].message.reasoning}“) re­turn re­sponse.choices[0].mes­sage.con­tent

For full guides and ex­am­ples (vision in­put, struc­tured out­put, par­tial mode, tool choice, dy­namic tool load­ing, con­text caching), see the Kimi K3 Quickstart and Thinking Effort.

Coding Agent Framework

Kimi K3 works best with Kimi Code CLI as its agent frame­work. We warmly in­vite you to give it a try — run Kimi Code in your ter­mi­nal and se­lect Kimi K3 us­ing the /model com­mand. We hope you en­joy build­ing with Kimi K3, and we would love to hear your feed­back!

7. License

Both the code repos­i­tory and the model weights are re­leased un­der the Kimi K3 License.

8. Contact Us

If you have any ques­tions, please reach out at sup­port@moon­shot.ai.

Safetensors

Model tree for moon­shotai/​Kimi-K3

Spaces us­ing moon­shotai/​Kimi-K3 8

Collection in­clud­ing moon­shotai/​Kimi-K3

UEFA and its 55 mem­ber as­so­ci­a­tions stand as one. We unan­i­mously and un­equiv­o­cally re­ject FIFA’s pro­posal to trans­fer own­er­ship in­ter­ests in the World Cup and other FIFA com­pe­ti­tions to pri­vate in­vestors.

The World Cup can­not be treated as an in­vest­ment prod­uct. It is one of foot­bal­l’s great­est sport­ing lega­cies. It has been built over gen­er­a­tions by play­ers, na­tional teams and sup­port­ers across every con­ti­nent. No part of it should ever be sur­ren­dered to pri­vate in­vestors. The World Cup is not for sale.

It is both ir­re­spon­si­ble and in­de­fen­si­ble that a pro­posal of such sig­nif­i­cance for foot­ball was con­ceived in se­cret and brought to the brink of ap­proval with­out any mean­ing­ful con­sul­ta­tion with those en­trusted with stew­ard­ing the game. This is not merely a pro­found fail­ure of lead­er­ship, but an ab­di­ca­tion of FIFA’s duty as the cus­to­dian of world foot­ball.

National as­so­ci­a­tions around the world are now pre­sented with an ul­ti­ma­tum: ac­cept the ir­re­versible cap­ture of foot­bal­l’s great­est com­pe­ti­tions or bear the con­se­quences. This is not a “democratic de­ci­sion”, but gov­er­nance by in­tim­i­da­tion — an act of co­er­cion un­wor­thy of an in­sti­tu­tion en­trusted with the stew­ard­ship of the global game.

But our op­po­si­tion goes far be­yond process.

The mo­ment ex­ter­nal in­vestors ac­quire own­er­ship in­ter­ests in FIFA com­pe­ti­tions, foot­ball changes for­ever. Commercial re­turn be­comes a per­ma­nent oblig­a­tion. Investor ex­pec­ta­tions be­come a daily pres­sure. From that mo­ment on­wards, every de­ci­sion on the in­ter­na­tional cal­en­dar, every de­ci­sion on com­pe­ti­tion for­mats and every de­ci­sion shap­ing the fu­ture of foot­ball is no longer dri­ven by what best serves the game, but by what best serves share­hold­ers.

This model has no place in world foot­ball. Football’s fu­ture can­not be dic­tated by the ex­pec­ta­tions of those whose first duty is to max­imise fi­nan­cial re­turn. Nor can the in­ter­ests of na­tional as­so­ci­a­tions, leagues, clubs, play­ers and sup­port­ers be­come sub­or­di­nate to in­vestor re­turns. Football can­not mort­gage its fu­ture for fi­nan­cial gain.

Europe’s po­si­tion is clear. We will never lend this model our le­git­i­macy. No one has the moral au­thor­ity to sell what they merely hold in trust for the next gen­er­a­tion.

As a re­sult of to­day’s dis­cus­sion, no UEFA na­tional teams will par­tic­i­pate in any FIFA com­pe­ti­tion for so long as these pro­pos­als re­main alive, un­less this pro­posal has been aban­doned in its en­tirety and bind­ing as­sur­ances have been given that FIFA will never again open its gov­er­nance or com­pe­ti­tions to pri­vate own­er­ship.

Nobody should be in any doubt: UEFA and its na­tional as­so­ci­a­tions will op­pose these plans with ab­solute de­ter­mi­na­tion.

There are mo­ments when in­sti­tu­tions are judged not by what they are pre­pared to ac­cept, but by what they refuse to com­pro­mise. This is one of those mo­ments.

Some things are sim­ply too im­por­tant to sell. The FIFA World Cup be­longs to foot­ball. It al­ways will. And so long as Europe has a voice, it will never be for sale.

A post by Dario Amodei, Anthropic CEO

Over the last few days there has been a lot of dis­cus­sion about open-weights mod­els, es­pe­cially those from China. Reports sug­gest that some US of­fi­cials are con­sid­er­ing ban­ning the use of Chinese open-weights mod­els by US com­pa­nies. In re­sponse, many tech com­pa­nies have signed a let­ter sup­port­ing open-weights mod­els, and some peo­ple have even ac­cused Anthropic of want­ing to ban open-weights mod­els as a means of pro­tect­ing our busi­ness. Anyone who has read my past writ­ing should know that I don’t re­gard such bans as a use­ful mea­sure, but let me state it clearly so that there is no doubt: Anthropic has never ad­vo­cated for a ban on open-weights mod­els.

Open-weights mod­els that don’t have dan­ger­ous ca­pa­bil­i­ties are a pub­lic good: they don’t cost any­thing be­sides the com­pute needed to run them, and they pro­vide value to busi­nesses, de­vel­op­ers, and re­searchers.

Protectionist bans would not ad­dress my most se­ri­ous na­tional se­cu­rity con­cerns. Specifically, I am wor­ried about two night­mare sce­nar­ios. I laid these out in my es­say The Adolescence of Technology six months ago1, and have held these po­si­tions con­sis­tently for many years:

My pri­mary con­cern is the risk that au­thor­i­tar­ian gov­ern­ments—not solely the Chinese Communist Party (CCP), al­though the CCP is clearly the most ca­pa­ble threat—build AI mod­els that are more pow­er­ful than those built by the US, and use them to achieve per­ma­nent mil­i­tary su­pe­ri­or­ity or per­pe­trate in­cred­i­bly deep re­pres­sion of their own peo­ple. This con­cern is widely shared within the US gov­ern­ment: Vice President Vance warned in Paris last year that “authoritarian regimes have stolen and used AI to strengthen their mil­i­tary, in­tel­li­gence, and sur­veil­lance ca­pa­bil­i­ties,” and the Intelligence Community’s 2026 Annual Threat Assessment found that “other global pow­ers’ ro­bust progress in AI is chal­leng­ing US eco­nomic com­pet­i­tive­ness and na­tional se­cu­rity ad­van­tages.” It is ir­rel­e­vant whether these mod­els are re­leased with open weights, and cer­tainly ir­rel­e­vant whether they are used by US busi­nesses. In fact, the most dan­ger­ous model may be one that is trained in se­cret and handed only to the People’s Liberation Army for use in drones and the Ministry of State Security for sur­veil­lance and re­pres­sion.

My sec­ondary con­cern is the risk that pow­er­ful AI mod­els may be mis­used to carry out cy­ber­at­tacks or bi­o­log­i­cal at­tacks, and may have se­ri­ous align­ment prob­lems. Open-weights mod­els—it does not mat­ter whether they come from China or any­where else—do po­ten­tially pre­sent a higher risk than closed mod­els, be­cause it is very dif­fi­cult to ap­ply guardrails to them or mon­i­tor their us­age, and once weights are re­leased they can­not be with­drawn2. But ban­ning the use of these mod­els by US busi­nesses does noth­ing to ad­dress this risk, be­cause bad ac­tors are un­likely to be le­git­i­mate US busi­nesses. It would pro­tect US AI com­pa­nies from com­pe­ti­tion, but that has never been my goal.

To ad­dress these con­cerns, I do sup­port the fol­low­ing three mea­sures, which I and Anthropic have con­sis­tently ad­vo­cated for:

We should not sell pow­er­ful chips or chip­mak­ing equip­ment to China, and we should crack down on the ram­pant smug­gling3 and workarounds used to ob­tain ac­cess to such chips. China has lim­ited do­mes­tic pro­duc­tion ca­pac­ity, and there­fore, due to the scal­ing laws, can­not build more pow­er­ful mod­els than the US with­out US chips. This is the most ef­fi­cient and di­rect way to block threat #1, and by ham­per­ing the train­ing of mod­els that are out of reach of US law, it also in­di­rectly helps with threat #2.

We should crack down on in­dus­trial-scale dis­til­la­tion op­er­a­tions. Distillation is a much more com­pute-ef­fi­cient process than train­ing mod­els from scratch. It al­lows China to build much bet­ter mod­els than its num­ber of chips would or­di­nar­ily en­able, and thus par­tially evade chip bans. Distillation does not al­low the CCP to ob­tain equiv­a­lent or su­pe­rior AI ca­pa­bil­i­ties to the US, but it can bring the Chinese fron­tier to within a few months of the US fron­tier. It is true that many of the com­pa­nies car­ry­ing out these op­er­a­tions re­lease open-weights mod­els—but the open weights are far less rel­e­vant than the fact that the op­er­a­tions are backed by an au­thor­i­tar­ian state seek­ing to over­take the US at the fron­tier. We should have pol­icy in­ter­ven­tions to de­ter this be­hav­ior. A blan­ket ban on open-weights mod­els is nei­ther the cor­rect rem­edy nor some­thing we have called for4.

All suf­fi­ciently ca­pa­ble mod­els, open and closed, should go through manda­tory safety test­ing. The best way to ad­dress threat #2 is to just di­rectly test mod­els for cy­ber, bi­o­log­i­cal, and align­ment risks be­fore re­lease. I think this idea is ac­tu­ally close to a con­sen­sus: I have been heart­ened both that the Trump ad­min­is­tra­tion has moved in this di­rec­tion in re­cent months, and by re­cent in­dus­try pro­pos­als that would ap­ply such test­ing to the most ca­pa­ble mod­els re­gard­less of their coun­try of ori­gin or whether they are open or closed (while ex­empt­ing less ca­pa­ble mod­els, such as those from star­tups and acad­e­mia, en­tirely). Whether open mod­els do or don’t pose an in­creased risk, and whether that risk can be mit­i­gated, is some­thing that should emerge from test­ing, rather than be de­cided in ad­vance—and there may be promis­ing meth­ods for im­prov­ing the safety of open-weights mod­els, in­clud­ing re­cent re­search from AE Studio and Anthropic on mod­u­lar train­ing strate­gies. Note that to be ef­fec­tive, test­ing would need to be global, which means even the CCP would need to be on board. I think this may ac­tu­ally be pos­si­ble: as I wrote in The Adolescence of Technology, lim­ited co­op­er­a­tion around pre­vent­ing AI bi­o­log­i­cal weapons may be pos­si­ble be­cause it is in China’s in­ter­est too.

This brings me to the open let­ter. I agree with much of it: open weights ex­pand ac­cess to the AI econ­omy, they strengthen com­pe­ti­tion at least for some use cases, and they give cus­tomers greater con­trol. Concerns about dis­til­la­tion should be ad­dressed through tar­geted le­gal and com­mer­cial frame­works—the same mea­sure I de­scribed above. But I don’t agree with the let­ter’s as­ser­tions that open-weights mod­els nec­es­sar­ily make it eas­ier to de­velop safe­guards or that broad ac­cess to ca­pa­bil­i­ties nec­es­sar­ily helps de­fend­ers more than at­tack­ers. It seems at least as likely to me that the op­po­site will be true. For ex­am­ple, I worry that bi­ol­ogy will have a strong at­tacker-de­fender asym­me­try, where suf­fi­ciently ca­pa­ble mod­els may be able to quickly weaponize pan­demic-level viruses with widely avail­able ma­te­ri­als, whereas de­fense against these agents is a multi-year op­er­a­tional task in the best case (as we saw with Operation Warp Speed)5. Questions like this should be em­pir­i­cally an­swered by rig­or­ous pre-re­lease test­ing, not as­sumed in ad­vance.

To sum­ma­rize my and Anthropic’s po­si­tion, we have not and are not ad­vo­cat­ing for a ban on open-weights mod­els as a cat­e­gory. We should in­stead fo­cus on keep­ing pow­er­ful chips out of au­thor­i­tar­ian hands, stop­ping in­dus­trial-scale dis­til­la­tion, and re­quir­ing safety test­ing of all suf­fi­ciently ca­pa­ble mod­els, open and closed.

*Edit 28 July: Updated to note that the cited re­search on mod­u­lar train­ing strate­gies was a col­lab­o­ra­tion be­tween Anthropic and AE Studio.

Related con­tent

Cognizant and Anthropic ex­pand their part­ner­ship to bring Claude to en­ter­prise clients

Read more

Introducing Claude Opus 5

Opus 5 is a step change im­prove­ment for the Opus tier pow­er­ing long-run­ning agents while de­liv­er­ing im­prove­ments in cod­ing and pro­fes­sional work.

Read more

A re­search agenda for the Economic Futures Research Fund

We’re shar­ing the re­search agenda for the Anthropic Economic Futures Research Fund.

Read more

TurboFieldfare

Gemma 4 26B-A4B in­fer­ence in about 2 GB of RAM A cus­tom Swift + Metal run­time for any Apple Silicon Mac, even the 8 GB ones.

Quick start · Local server · Benchmarks · Contribute re­sults · How it works · Experiments · References

Memory got ex­pen­sive. So I gave a 26-billion-parameter model a ~2 GB bud­get.

TurboFieldfare runs the in­struc­tion-tuned Gemma 4 26B-A4B with­out load­ing the en­tire 14.3 GB model into mem­ory. It keeps the shared 1.35 GB core and FP16 KV cache in mem­ory, then streams only the ex­perts needed for each to­ken from SSD. This is what lets the model run on Macs with 8 GB of RAM.

The run­time, stream­ing in­staller, CLI, and na­tive Mac app are writ­ten in Swift and Metal. TurboFieldfare is model-spe­cific rather than a wrap­per around MLX or llama.cpp. The cu­rated ex­per­i­ment record sum­ma­rizes 103 mea­sured re­sults across ker­nels, caching, I/O, pre­fill, and de­code.

Try it

git clone https://​github.com/​dru­mih/​turbo-field­fare.git cd turbo-field­fare swift build -c re­lease .build/release/TurboFieldfareMac

On the first run, Swift Package Manager down­loads and builds the Swift pack­ages re­quired by the to­k­enizer. The com­plete re­lease build in­cludes the fore­ground Mac app and its sib­ling de­code-ser­vice ex­e­cutable.

When the app opens, choose Download and let TurboFieldfare fetch and repack the pinned model (about 15 GB). Once it is ready, choose Load Model, type your prompt, and press Generate.

At a glance

The mea­sured re­sult is a ref­er­ence point, not a per­for­mance ceil­ing. Prompt length, gen­er­ated length, page-cache state, and hard­ware all af­fect through­put. See com­mu­nity bench­mark re­sults from other Macs, or fol­low the com­mu­nity bench­mark guide to add your own.

Using TurboFieldfare

TurboFieldfare pro­vides a na­tive Mac app, a com­mand-line in­ter­face, and an ex­per­i­men­tal loop­back OpenAI-compatible server. They use the same .gturbo model di­rec­tory, but only one model-own­ing prod­uct should run at a time.

The Swift pack­age ex­poses six prod­ucts:

Requirements

An Apple Silicon Mac; the val­i­dated tar­get is an 8 GB M2 MacBook Air

ma­cOS 26 with Metal 4

Xcode 26 and Swift 6.2 or newer

Enough free stor­age for the ~14.3 GB model in­stal­la­tion

An in­ter­net con­nec­tion for the first model in­stall

The pack­age is ar­m64-only. Older ma­cOS and Metal ver­sions are not sup­ported.

Prompting the model

The Mac app treats what you type as an in­struc­tion and han­dles Gemma’s chat for­mat­ting au­to­mat­i­cally. Just de­scribe the task and in­clude any con­text the model needs.

Generation de­faults to tem­per­a­ture 0.2, Top-K 64, and Top-P 0.95. Set tem­per­a­ture to 0 for de­ter­min­is­tic greedy out­put. The model can still re­peat it­self or give in­cor­rect an­swers, so check im­por­tant re­sults.

TurboFieldfare is text-only. The app and CLI sup­port user and model mes­sages plus op­tional sys­tem guid­ance; they do not ex­pose or ex­e­cute tools. The loop­back server ac­cepts func­tion-tool de­c­la­ra­tions and re­turns model-pro­duced tool calls for the client to au­tho­rize and ex­e­cute. Images, au­dio, and video are not sup­ported.

Mac app

Clone the repos­i­tory, then run the app from its root:

swift build -c re­lease .build/release/TurboFieldfareMac

Build the com­plete pack­age so the app and its sib­ling de­code ser­vice are both avail­able. When launched from this check­out, the app stores the model in scratch/​gem­ma4.gturbo.

Install the model

On first launch, the app checks the avail­able stor­age and shows the down­load and in­stalled sizes. Choose Download to be­gin.

The in­staller never ma­te­ri­al­izes the full source check­point. It streams the re­quired byte ranges from the pinned Hugging Face re­vi­sion and repacks them di­rectly into the .gturbo lay­out as they ar­rive. This avoids a sec­ond full check­point on disk and keeps scratch mem­ory bounded.

The first in­stal­la­tion trans­fers about 15 GB through bounded Hugging Face range re­quests. Network speed and Hugging Face re­sponse times vary, so it can take a while. The com­pleted .gturbo in­stal­la­tion oc­cu­pies about 14.3 GB and is ac­cepted only af­ter its man­i­fest and file hashes have been val­i­dated. Installation does not load the model into mem­ory.

Load and gen­er­ate

After in­stal­la­tion:

Choose Load Model.

Enter a prompt in the com­poser.

Choose Generate, or press Command+Return.

Use the stop but­ton or Escape to end gen­er­a­tion early.

The sta­tus bar shows gen­er­a­tion progress, de­code speed, and mem­ory use. Use the right pane to con­fig­ure sam­pling, con­text length, ex­pert-cache slots, and run­time op­tions. See Runtime con­trols for de­tails and de­faults.

Command-line in­ter­face

The CLI uses an ex­ist­ing .gturbo in­stal­la­tion. If you in­stalled the model through the Mac app, it is al­ready avail­able at scratch/​gem­ma4.gturbo. Otherwise, in­stall it from the com­mand line:

swift run -c re­lease TurboFieldfareRepack \ –output scratch/​gem­ma4.gturbo \ –overwrite

Continue a can­celled or in­ter­rupted down­load:

swift run -c re­lease TurboFieldfareRepack \ –output scratch/​gem­ma4.gturbo \ –overwrite \ –resume

Remove saved down­load state:

swift run -c re­lease TurboFieldfareRepack \ –discard-partial \ –output scratch/​gem­ma4.gturbo

The run­time ac­cepts only a com­pleted .gturbo di­rec­tory with a fi­nal man­i­fest.json.

Verify an ex­ist­ing in­stal­la­tion with­out load­ing the model:

swift run -c re­lease TurboFieldfareRepack \ –verify-install \ –input-gturbo scratch/​gem­ma4.gturbo

Instruction chat

Put chat mes­sages in a JSON ar­ray and pass it with –messages-file:

[ {“role”: “user”, “content”: “Explain why chun­ked pre­fill re­duces time to first to­ken while keep­ing mem­ory bounded.“} ]

swift run -c re­lease TurboFieldfareCLI \ –model scratch/​gem­ma4.gturbo \ –messages-file mes­sages.json

This for­mats mes­sages in the same way as the Mac app. The CLI re­sponse limit is set with –max-new, which de­faults to 1,024 to­kens. The Mac app can gen­er­ate un­til the se­lected con­text win­dow is full.

Raw com­ple­tion

–prompt is avail­able for raw com­ple­tion and re­pro­ducible com­par­isons. It passes the text di­rectly to the model with­out chat for­mat­ting. Use –messages-file for in­struc­tion-re­sponse con­ver­sa­tions.

swift run -c re­lease TurboFieldfareCLI \ –model scratch/​gem­ma4.gturbo \ –prompt “The cap­i­tal of France is” \ –max-new 64 \ –temperature 0

This ex­am­ple de­lib­er­ately re­quests a short greedy com­ple­tion.

Common gen­er­a­tion op­tions in­clude –max-context, –temperature, –top-k, –top-p, –repetition-penalty, –seed, and re­peat­able –stop strings. The pub­lic CLI uses pro­duc­tion run­time de­faults. Run the fol­low­ing com­mand for the com­plete op­tion list:

swift run -c re­lease TurboFieldfareCLI –help

Generated text goes to stan­dard out­put. Timing sta­tis­tics go to stan­dard er­ror; add –quiet to sup­press that footer in scripts.

Local OpenAI-compatible server

Build the server and point it at an in­stalled model:

swift build -c re­lease –product TurboFieldfareServer .build/release/TurboFieldfareServer \ –model scratch/​gem­ma4.gturbo

It lis­tens on http://​127.0.0.1:8080/​v1 and sup­ports Chat Completions, stream­ing, func­tion tools, and sin­gle-pre­fix prompt reuse. The client must au­tho­rize and run every tool call. Keep the server on loop­back; it has no re­mote au­then­ti­ca­tion or TLS.

See Local server for a test re­quest, Python and OpenCode setup, prompt reuse, tool han­dling, and the sup­ported API sub­set.

Test and con­tribute

Run the pub­lic test suite se­ri­ally:

Scripts/test.sh

Before start­ing a model run, close mem­ory-heavy apps and check mem­o­ry_­pres­sure -Q. If it re­ports lit­tle free mem­ory, post­pone the run. Run only one TurboFieldfare app, de­code ser­vice, CLI, server, test, or other lo­cal-model process at a time.

To con­tribute a com­pa­ra­ble per­for­mance re­sult, fol­low the com­mu­nity bench­mark guide.

How the in­fer­ence en­gine works

At each trans­former layer, Metal com­putes at­ten­tion and the router from res­i­dent weights. The CPU uses the router’s top-8 ex­pert IDs to plan against the lay­er’s 16-slot LFU cache, then fills misses with bounded par­al­lel pread calls into Metal-visible buffers. Metal com­putes the res­i­dent shared-ex­pert branch while those reads run, then com­bines the shared and routed out­puts.

Prompt pre­fill uses chunks of up to 128 to­kens so one fetched ex­pert can serve mul­ti­ple rows. Generation re­peats the routed layer loop one to­ken at a time. The in­staller ap­plies the same bounded-mem­ory rule: it repacks re­mote ranges di­rectly into .gturbo with­out stag­ing a full shard or ten­sor.

For a vi­sual in­tro­duc­tion to the model ar­chi­tec­ture, see Maarten Grootendorst’s A Visual Guide to Gemma 4.

System de­sign ex­plains the .gturbo lay­out, mem­ory own­er­ship, pre­fill, router hand­off, cb1/​io/​cb2 phases, Metal ker­nels, and cor­rect­ness in­vari­ants.

Status and scope

TurboFieldfare cur­rently in­cludes:

Remote stream­ing repack into the .gturbo model for­mat

Instruction-tuned Gemma 4 26B-A4B with ver­i­fied text-only chat for­mat­ting

4-bit MLX affine em­bed­ding, at­ten­tion, shared-ex­pert, and routed-ex­pert weights, with an 8-bit router

Custom Metal ker­nels for quan­tized GEMV, at­ten­tion, MoE, nor­mal­iza­tion, RoPE, sam­pling, and pro­duc­tion fu­sions

SSD-backed routed-ex­pert stream­ing with a bounded ex­pert cache

Chunked sin­gle-prompt pre­fill and to­ken-by-to­ken gen­er­a­tion

FP16 KV stor­age with bounded cir­cu­lar stor­age for 25 slid­ing-win­dow lay­ers and lin­ear stor­age for 5 full-at­ten­tion lay­ers

Exact split-K/​V de­code at­ten­tion with dis­tinct nor­mal­ized K and V paths

A Swift li­brary, stream­ing in­staller, com­mand-line in­ter­face, loop­back OpenAI-compatible server, and na­tive SwiftUI/AppKit Mac app with a one-shot lo­cal de­code ser­vice

Current scope is text-only in­fer­ence from the pinned Gemma 4 26B-A4B in­struc­tion check­point on Apple Silicon Macs with at least 8 GB of RAM.

Future work

Build iPhone and iPad apps, then mea­sure in­fer­ence speed and mem­ory use on mo­bile hard­ware.

Benchmark more Apple Silicon Macs, es­pe­cially the base 16 GB M4 Mac mini and other 8 GB mod­els.

Experiments and tech­ni­cal doc­u­men­ta­tion

The ex­per­i­ments that shaped TurboFieldfare ex­plain the largest wins, the plau­si­ble ideas that failed, and the early re­sults that re­versed un­der stronger val­i­da­tion. The de­tailed ex­per­i­ment record keeps all 103 au­dited en­tries as op­tional ev­i­dence.

Useful en­try points:

Local OpenAI-compatible server

System de­sign

Benchmarks

The ex­per­i­ments that shaped TurboFieldfare

July 29, 2026

Over the last year, I ad­mit­tedly haven’t used my Vision Pro a ton, but fairly re­cently I dis­cov­ered a su­per handy use that it’s ab­solutely in­cred­i­ble at, pro­vided you have the right tools.

After years of apart­ment life my girl­friend and I have re­cently be­gun the process of build­ing our (first! ex­cit­ing!) home, which is an ab­solute whirl­wind of choices and de­ci­sions. Maybe it’s where we’re both pro­gram­mers, but par­tic­u­larly for me, my soft­ware-ori­ented brain feels al­most in­com­pat­i­ble with this world of de­sign­ing a home (she’s the main one keep­ing this pro­ject mov­ing for­ward).

In soft­ware if you don’t end up lik­ing a fea­ture af­ter play­ing around with it for awhile, you can tweak it or re­move it en­tirely (try do­ing that with a poorly placed wall). Here, de­ci­sions feel huge and hard to com­mit to.

On top of this, the hous­ing mar­ket is re­ally ex­pen­sive right now in many parts of the world (ours def­i­nitely in­cluded) so mak­ing good use of every square foot feels para­mount.

(Don’t worry, we have a great ar­chi­tect who guides us skill­fully, but ul­ti­mately it’s up to us to sign off on every­thing!)

Enter the Vision Pro

Looking at PDFs of po­ten­tial floor plans, you don’t (or at least I don’t) de­velop much of a sense of scale or con­nec­tions with a bunch of black rec­tan­gles. This room says it’s 13 feet by 15 feet, I guess I can get out a mea­sur­ing tape, but what does that feel like? Would this hall­way be cramped? What all can you see when you first walk into the house?

Then it hit me: vir­tual re­al­ity! There’s other VR de­vices that have bet­ter gam­ing chops, but I’m not sure there’s a con­sumer de­vice out there that’s bet­ter than the Vision Pro on pa­per when it comes to ren­der­ing a vir­tual world with its high res­o­lu­tion screens and then plac­ing you in it with its abun­dance of sen­sors.

Problem is, how do you go from floor plan to vir­tual re­al­ity?

Let’s get cre­at­in’

I have a bit of ex­pe­ri­ence us­ing Fusion 360 (free 3D mod­el­ing soft­ware for hob­by­ists), so I had the idea to try to quickly build the floor plan up in 3D. Nothing fancy, just floors, ceil­ings, and walls, with holes for doors.

If you’re not fa­mil­iar with 3D de­sign tools, this is a great first pro­ject, you’re ba­si­cally just draw­ing the floor plan out in 2D and then ex­trud­ing out the walls. YouTube and ask­ing AI ques­tions are awe­some re­sources for learn­ing this handy skill in 2026. Sites like Fiverr are also a great re­source, I’m sure there’s an abun­dance of peo­ple there who could take a floor plan you’re in­ter­ested in and turn it into a 3D file for a rea­son­able price.

Leveling it up

A bunch of walls, ceil­ings, and holes in the wall is pretty pow­er­ful, but with­out ac­tual ob­jects or tex­ture in the space it’s still a bit hard to get scale when you’re “walking around”.

You know how you walk into an empty apart­ment for the first time and you’re like “Holy crap there’s so much room” and then you add your be­long­ings and there sud­denly is­n’t? It’s kinda like that, we need to add some mod­els and ma­te­ri­als to the space to ac­tu­ally ground our per­spec­tive a bit and give things scale, oth­er­wise it feels like walk­ing around a ware­house.

Adding tex­tures

Quick easy one. In Fusion, tap the “A” key to bring up the Appearance panel and you can drag and drop a bunch of com­mon tex­tures like wood, stone, or paint onto ob­jects. This can re­ally help to break up the mo­not­ony of every­thing be­ing the same dull tex­ture and ac­tu­ally gives the place depth.

There’s even glass tex­tures for win­dows which is pretty handy.

IKEA

I can model a counter or a kitchen is­land (just a bunch of rec­tan­gles) but any­thing be­yond that and I’m tap­ping out. Thankfully IKEA has a mas­sive amount of fur­ni­ture with cor­re­spond­ing 3D mod­els, and even if you’re not a big IKEA per­son (wow aren’t you fancy) hav­ing any ap­prox­i­ma­tion for your fi­nal fur­ni­ture in your place re­ally helps you get an idea of how things fit to­gether and can be po­si­tioned.

Problem is, no easy way to get ac­cess to those 3D mod­els from what I can tell. Thankfully, with a script for the Tampermonkey browser ex­ten­sion you can eas­ily down­load them. Not every item on IKEA has a 3D model un­for­tu­nately, but seem­ingly the ma­jor­ity do.

This is su­per handy for adding a couch, a bed, a desk, an area rug, etc. to the space so when you walk into a bed­room your eyes kinda see the bed and desk and get a good idea for the scale of the room, which lets you un­der­stand if it’s a good size or if the di­men­sions are proper, and you can kinda imag­ine what it would be like to ex­ist in that space.

Downside is this down­loads a glb file, some­thing I was­n’t fa­mil­iar with. Fusion al­lows us to eas­ily im­port obj files, so we need to con­vert it to that. After try­ing a bunch of scripts and web­sites, I hon­estly found this web­site to be the best. Little janky, but it works.

Also note that the re­sult­ing obj file (and the folder it’s con­tained in) of­ten won’t ren­der tex­tures in­side Fusion 360, but when you ex­port them from Fusion they show up as ex­pected.

3D Warehouse

That cov­ers a lot of fur­ni­ture, but not every­thing. Maybe you want to see how a stand mixer looks on the counter or if you can fit a rice cooker com­fort­ably. Heck, you can find your car and put it in the garage for ref­er­ence.

This is where 3D Warehouse comes in, it’s a com­mu­nity-dri­ven web­site where peo­ple can up­load free 3D mod­els they cre­ate and eas­ily im­port them into Sketchup, an­other pop­u­lar piece of 3D mod­el­ing soft­ware (that might even work bet­ter than Fusion for house de­sign, I dunno, haven’t used it much).

Problem is, the files aren’t eas­ily us­able in Fusion, but I found a nice workaround.

If you open the URL on your iOS de­vice in­stead, it gives you the op­tion to view it in 3D in­side your cur­rent en­vi­ron­ment. Within that view, if you tap the share but­ton you get ac­cess to the ac­tual USDZ file that pow­ers this ex­pe­ri­ence, at which point you can just AirDrop it to your Mac. Nice!

From there, even though we love a USDZ file, Fusion seem­ingly does­n’t for im­port­ing ob­jects, so back to that pre­vi­ous web­site to con­vert to OBJ. From there it’s as sim­ple as bring­ing it into Fusion and plac­ing it.

This web­site is se­ri­ously awe­some, there’s a model for just about any­thing you’d put in your house.

Programming!

Now that I have some­thing I’m happy with, I re­mem­bered Apple plat­forms love the USDZ file for­mat for 3D mod­els, and sure enough Fusion had a USDZ ex­port op­tion. Nice!

With a file in hand, we’re get­ting some­where, so I AirDropped to it to my Vision Pro and opened it. This worked pretty okay for view­ing it, and you could even walk around a lit­tle bit, but un­less you live in a ware­house walk­ing the full length of a vir­tual house with­out bump­ing into some­thing and end­ing up in those VR fail com­pi­la­tions is pretty tricky. I want some­thing bet­ter.

This is where vibe cod­ing is per­fect: putting some­thing tech­ni­cally im­pres­sive to­gether when you would have never both­ered to take weeks to put it to­gether tra­di­tion­ally. Is the code per­fect? Nah, but the al­ter­na­tive is it never ex­ist­ing, and it’s just “for fun” any­way.

After some in­tense typ­ing with a com­bi­na­tion of Claude and Codex over the course of a morn­ing I had some­thing I was pretty happy with. I named it Prospector (can’t re­mem­ber why) and I’ve been re­ally happy with it.

Here are a bunch of the fea­tures that level it up be­yond just view­ing a USDZ file in the Files app:

Controller sup­port! Walk around like you’re in a 3D video game, with mo­tion con­trols as well as the abil­ity to ro­tate the cam­era (you can still walk and look around nor­mally of course, this just aug­ments that).

Skybox! Pretty rudi­men­tary, but added a for­est style sky­box as the ex­te­rior of the world so if you look out a win­dow you don’t just see your cur­rent en­vi­ron­ment

Terrain fol­low­ing! If you tap the right D-pad but­ton the con­troller will map you to the ter­rain, so you’ll go up and down with any un­du­la­tions in the ter­rain. This is re­ally handy if you have a sur­vey of your prop­erty done so can ef­fec­tively have a full view of your prop­er­ty’s ter­rain and “walk” through it

Toggle real life! If you hold your thumb and mid­dle fin­ger to­gether for a mo­ment it will tog­gle the vir­tual world on and off, this makes it feel safer if you want to take a step for­ward in vir­tual re­al­ity but are un­sure if you’re go­ing to bump into a table in real life.

Take flight! With the trig­gers you can fly up or down, great for go­ing be­tween floors for in­stance, and then if you press up on the D-pad it’ll re­set you to the ground level.

Speed mode! Pressing left on the D-pad makes you move 6× faster, which is re­ally, well, fast when you’re cross­ing a big prop­erty rather than pok­ing around a sin­gle room.

With all those to­gether, this is a re­ally help­ful way to view USDZ files on the Vision Pro. You can re­ally eas­ily ex­plore a space and po­si­tion your­self in new ar­eas to look around, and even take off the head­set to show a spouse or friend so you can gather their in­put on any changes. Then mak­ing a change is as sim­ple as tweak­ing the file in Fusion, re-ex­port­ing, then re-run­ning.

Download link

If you want to play around with Prospector, my su­per janky, vibe coded USDZ viewer, I put the con­tents up on GitHub (it would take a fair bit more work to pol­ish this up into some­thing I’d be com­fort­able sub­mit­ting to the App Store).

Using it is as ad­ver­tised: janky. Take your USDZ file, im­port it into Xcode, and in­side ImmersiveView.swift change the USDZ file name to what­ever the name of your file is. You can also tweak the sky­box (Poly Haven has a bunch of awe­some op­tions). Then, just pair a con­troller to your Vision Pro and run the pro­ject on your de­vice.

Just know I coded like 0% of this, so if it’s ter­ri­ble you can’t judge me. Don’t you dare. I’m sen­si­tive. Judge the AI.

This is awe­some

No se­ri­ously, this feels so pow­er­ful. When we fi­nally de­cided on a plan, through the fancy Revit soft­ware our ar­chi­tect uses he was able to bring us on a 3D walk­through of our fu­ture house. It was cool, kinda like a Google Streetview-esque ex­pe­ri­ence where you could click to tele­port around the house and drag to look around.

But hon­estly, af­ter al­ready see­ing it in full, im­mer­sive 3D where you can look around and feel like you’re there, we al­ready felt like we knew the place. It re­ally feels like one day in the fu­ture vis­it­ing po­ten­tial de­signs in 3D will be a core part of the process, and if you have the hard­ware that fu­ture is pos­si­ble to­day.

topへ

Security ex­perts have been sound­ing the alarm for years about the risks of us­ing generic TV boxes that promise un­lim­ited con­tent stream­ing for a one-time fee, warn­ing that they se­cretly rent the user’s Internet con­nec­tion out to strangers. But a ground­break­ing new analy­sis finds these de­vices also rou­tinely spoof them­selves as mo­bile phones click­ing ads on AI-generated web­sites as part of a sprawl­ing op­er­a­tion that seeks to de­fraud on­line mer­chants and ad­ver­tis­ing net­works.

Pedro Falé is a threat re­searcher with the se­cu­rity firm Bitsight. Falé told KrebsOnSecurity he was able to peer in­side a vast and com­plex ad fraud net­work by reg­is­ter­ing an ex­pired do­main name that was used to co­or­di­nate fake ad clicks across a par­tic­u­larly pop­u­lar brand of these stream­ing de­vices known as H96.

An H96 TV stream­ing de­vice cur­rently ad­ver­tised for sale on Amazon.

Falé said the do­main he scooped up was pre­vi­ously used for teleme­try, pe­ri­od­i­cally col­lect­ing full hard­ware in­for­ma­tion and the en­tire list of in­stalled apps from tens of thou­sands of H96 stream­ing sticks plugged into tele­vi­sion sets around the globe. But upon in­spect­ing the traf­fic be­ing fun­neled to the do­main, he dis­cov­ered nearly all of the TV boxes trans­mit­ting data claimed to be mo­bile phone mod­els from a va­ri­ety of man­u­fac­tur­ers, in­clud­ing Samsung, Vivo, Huawei, and Xiaomi.

“We no­ticed some­thing was wildly wrong,” Falé said. “Multiple de­vices re­port­ing to this fac­tory Android TV Box back­door were ‘phones.’”

Image: Bitsight.

The re­searcher found all of the de­vices re­ported hav­ing the same two apps in­stalled, and that those apps were made by a com­pany called Zhejiang Fengwo IoT Technology Ltd, an en­tity founded in 2019 in main­land China which op­er­ates an ad-pub­lish­ing port­fo­lio un­der the name Fengwo Group. Further in­ves­ti­ga­tion into the Fengwo Group re­vealed it has reg­is­tered mul­ti­ple patents that match the in­ner work­ings of these apps.

“Bitsight TRACE iden­ti­fied sev­eral Hong Kong, Singapore, and sin­gle per­son ‘legal’ shell iden­ti­ties used to col­lect the mon­e­ti­za­tion and traced the op­er­a­tion back to a main­land China com­pany known as Zhejiang Fengwo IoT Technology Co., Ltd, which op­er­ates un­der the Fengwo Group,” Falé wrote in a re­port re­leased to­day about their find­ings.

Falé said an analy­sis of the apps shows they help to co­or­di­nate an ad fraud net­work that uses these H96 de­vices as a cap­tive traf­fic source to click on ads at AI-generated web­sites op­er­ated by the Fengwo Group.

Bitsight dis­cov­ered the web­sites con­tain ma­chine-gen­er­ated news ar­ti­cles and graph­ics across a range of cat­e­gories, in­clud­ing fi­nance, health, ed­u­ca­tion, gam­ing, mu­sic and food blogs. But they also found none of those sites dis­played ads un­less the de­vice vis­it­ing the page matched the spoofed mo­bile pro­file of these H96 de­vices.

AI DIGITAL HUMANS

The do­main for the Fengwo Group — fwg­cloud[.]com — claims the com­pany is “redefining the bound­aries of hu­man-AI in­ter­ac­tion,” and that it has cre­ated more than 120,000 “AI dig­i­tal hu­mans” avail­able to rent for every­thing from emo­tional com­pan­ion­ship to 24/7 cus­tomer ser­vice and cre­ative de­sign.

The home­page for fwg­cloud dot com.

Falé said the Fengwo Group’s do­main shared its SSL cer­tifi­cate data with other do­mains as­so­ci­ated with the apps found on H96 de­vices, specif­i­cally the phone spoof­ing mech­a­nism. He noted the do­main also has an in­ter­nal wiki plat­form that di­rectly ties the Fengwo Group to a pro­pri­etary im­ple­men­ta­tion of a Google-built vi­sual pro­gram­ming lan­guage called Blockly, which was orig­i­nally de­signed to help kids learn how to write soft­ware.

According to Bitsight, the Fengwo Group’s em­ploy­ees use Blockly to build the sham web­sites, al­low­ing low-skilled op­er­a­tors to drag blocks of code to­gether in their Blockly ed­i­tor — with­out any need to un­der­stand what the un­der­ly­ing code blocks do or how they work.

The Blockly home­page.

“An op­er­a­tor can drag blocks to­gether in their Blockly ed­i­tor, to de­fine each fraud rou­tine, given a task type,” reads Bitsight’s re­port. “Once the rou­tine is saved, it gets ex­ported as JavaScript and up­loaded to the S3 buck­ets. An op­er­a­tor does­n’t need as much un­der­stand­ing of the un­der­ly­ing tech­ni­cal­i­ties, as it is all set in place for ease of use.”

Bitsight even found one of the Fengwo Group app de­vel­op­ers men­tion­ing ex­actly these ad­van­tages, not­ing the de­vel­oper re­marked that “only a small num­ber of highly-skilled de­vel­op­ers are needed to build the tem­plate ex­e­cu­tion-unit im­ages,” and that “developers who cre­ate ex­e­cu­tion units from those tem­plates have sig­nif­i­cantly lower tech­ni­cal re­quire­ments, greatly re­duc­ing the com­pa­ny’s op­er­at­ing costs.”

Falé said if a user’s H96 stream­ing stick is se­lected for a spe­cific fraud task, it will be pushed the ap­pro­pri­ate Blockly mod­ule ac­cord­ing to the task de­sired, which can in­clude silently launch­ing a web browser, vis­it­ing web­sites, brows­ing pages, man­ag­ing tabs, and click­ing on ads.

To en­sure the TV boxes mas­querad­ing as mo­bile phones can re­li­ably click on ads dis­played via the AI-generated web­sites, the Fengwo group “fuses three vi­sion and rea­son­ing sys­tems into a sin­gle in­ter­face,” al­low­ing the bots to cor­rectly iden­tify an ad on the web­page and nav­i­gate the site much like a hu­man would, the Bitsight re­port ob­served.

Examples of ad land­ing pages linked to the Fengwo Group. Image: Bitsight.

TV ON? PROXY. TV OFF? AD FRAUD

Bitsight found the H96 de­vices were ei­ther re­lay­ing res­i­den­tial proxy traf­fic or par­tic­i­pat­ing in ad fraud, but never both at the same time. In fact, they con­cluded that when these TV boxes de­tect an HDMI sig­nal from an at­tached tele­vi­sion — in­di­cat­ing the user in­tends to stream video con­tent — the box is usu­ally func­tion­ing as a res­i­den­tial proxy. When the TV is off, it switches back to wait­ing for ad fraud jobs.

Falé said he be­lieves the TV boxes are set up this way be­cause its ad fraud ac­tiv­i­ties are far more re­source in­ten­sive and could in­ter­fere with the de­vice’s stated pur­pose — stream­ing video con­tent over the Internet.

Despite re­peated warn­ings from the FBI and se­cu­rity in­dus­try lead­ers about the se­cu­rity and pri­vacy risks of us­ing these stream­ing de­vices, ma­jor e-com­merce providers like Amazon, Best Buy, Newegg and oth­ers con­tinue to sell hun­dreds of dif­fer­ent mod­els and brands that bun­dle un­of­fi­cial ver­sions of Google’s Android op­er­at­ing sys­tem and are fre­quently mar­keted (via on­line in­flu­encers) as a way to ac­cess a broad ar­ray of stream­ing ser­vices and live broad­casts with­out a sub­scrip­tion.

Image: fbi.gov.

In ad­di­tion to en­list­ing the user’s TV box in ad fraud net­works, these off-brand stream­ing de­vices al­most uni­ver­sally come with res­i­den­tial proxy soft­ware pre-in­stalled. This soft­ware rents the user’s Internet ad­dress out to anony­mous pay­ing cus­tomers, who run the gamut from ag­gres­sive con­tent scrap­ing firms to ticket scalpers and out­right cy­ber­crim­i­nals.

What’s more, be­cause these generic (and gen­er­ally dirt cheap) TV boxes are all hor­ri­bly in­se­cure by de­fault and bereft of any kind of au­then­ti­ca­tion, in­stalling one on your home or of­fice net­work only in­vites fur­ther mis­chief. In January, the proxy track­ing ser­vice Synthient doc­u­mented how mul­ti­ple bot­nets had rapidly en­slaved mil­lions of TV boxes us­ing a com­plex in­ter­play of se­cu­rity vul­ner­a­bil­i­ties in both the res­i­den­tial proxy soft­ware and the stream­ing de­vices them­selves.

SHOW ME THE MONEY

Bitsight said it tracked ap­prox­i­mately 38,000 TV boxes glob­ally phon­ing home to the ex­pired Fengwo Group do­main, and based on that num­ber the re­port es­ti­mates this ad fraud net­work brings in rev­enues of close to $50,000 a day (not count­ing sub­stan­tial rev­enue from the res­i­den­tial proxy side of the busi­ness). However, Falé em­pha­sized that these es­ti­mates are highly con­ser­v­a­tive and based on teleme­try from just one of the Fengwo Group’s core (but older) do­mains.

As for the Fengwo Group’s claim to have 120,000 “digital hu­mans” at their dis­posal, Bitsight’s re­port con­cludes it could be just a clever mar­ket­ing scheme and/​or a way to avoid draw­ing sus­pi­cion to the com­pa­ny’s op­er­a­tions.

“Historically, when deal­ing with proxy ser­vices or DDoS, we some­times see these web­sites un­der­take in­con­spic­u­ous fa­cades, so as not to ad­ver­tise their DDoS ca­pa­bil­ity or bot­net size,” Falé wrote in the re­port. “This could also be the case here.”

If the Fengwo Group truly does have tens of thou­sands of “AI hu­mans” at its beck and call, it does not ap­pear to have ded­i­cated any of them to field­ing in­quiries from its own web­site. KrebsOnSecurity sought com­ment from the Fengwo Group by email­ing the con­tact ad­dress listed on the com­pa­ny’s home­page, but the re­quest bounced back with the re­ply, “Your mes­sage could­n’t be de­liv­ered to post­mas­ter@fwg­cloud[.]com. Their in­box is full, or it’s get­ting too much mail right now.”

As Bitsight’s analy­sis shows, when it comes to TV boxes and stream­ing sticks, it’s best to stick to name brands from rep­utable man­u­fac­tur­ers, and then to be spar­ing and care­ful with any apps you choose to in­stall on the de­vice — as many of those can bun­dle res­i­den­tial proxy soft­ware as well. Google says con­sumers can con­firm whether or not a de­vice is built with the of­fi­cial Android TV OS and Play Protect cer­ti­fi­ca­tion by fol­low­ing these in­struc­tions.

Additionally, Synthient main­tains a run­ning list of IoT de­vices that have been known to ship to con­sumers with res­i­den­tial proxy soft­ware and other ma­li­cious apps pre-in­stalled. Careful read­ers will no­tice Synthient’s list in­cludes other IoT de­vices apart from stream­ing sticks and boxes: As the FBI has warned, res­i­den­tial proxy soft­ware has also been found in other pop­u­lar con­sumer IoT de­vices from ran­dom brands, par­tic­u­larly dig­i­tal photo frames.

🦔AI com­pa­nies are bulk-buy­ing rare books, scan­ning them through high-speed ma­chines that cut the spines off, and shred­ding the orig­i­nals. A ser­vice called ISBNdb fa­cil­i­tates or­ders of up to a mil­lion books and keeps buy­ers anony­mous. Pre-2022 books are pre­mium be­cause they’re free of AI-generated text. A fed­eral judge ruled the prac­tice is fair use be­cause elim­i­nat­ing the orig­i­nal means only one copy ex­ists at a time. Anthropic hired the for­mer head of Google Books part­ner­ships to ob­tain “all the books in the world.”

My Take This got to me. A book­seller told 404 Media that rare books with al­most no sur­viv­ing copies are be­ing fed into this pipeline. Books that sur­vived wars, fires, and cen­turies of han­dling are be­ing shred­ded so an AI can learn to write a bet­ter mar­ket­ing email. ISBNdb’s web­site lit­er­ally says “‘AI com­pany de­stroys two mil­lion books’ is not a head­line that gen­er­ates sym­pa­thy,” and they still built an en­tire busi­ness around mak­ing it hap­pen qui­etly. They of­fer NDAs as a fea­ture. They coach clients to call it “digital preser­va­tion.”

I’ve cov­ered AI com­pa­nies scrap­ing the in­ter­net, tor­rent­ing li­braries, and steal­ing mu­sic. This is worse be­cause it’s ir­re­versible. You can re-up­load a web­site. You can reprint a best­seller. You can’t re­place the last three copies of an 18th-century botan­i­cal text once some­one shreds them for train­ing data. And the judge said it’s le­gal. So it’s go­ing to ac­cel­er­ate. “We shred rare books and of­fer NDAs so no­body finds out” is a le­git­i­mate busi­ness model in 2026. What a time­line.

Hedgie🤗

Jul 27, 2026 · 12:18 AM UTC

1,498

11,594

21,626

1,399,725

Stacked pull re­quests break large changes into small, re­view­able pull re­quests. They’re an or­dered se­ries of pull re­quests that each rep­re­sent fo­cused lay­ers of your change. With stacks, you can in­de­pen­dently re­view and check each pull re­quest, then merge every­thing to­gether in one click. No more open­ing a sin­gle large pull re­quest that takes for­ever to re­view, or split­ting work across mul­ti­ple branches you have to keep man­u­ally re­bas­ing.

“We’ve been us­ing GitHub stacked PRs for Next.js for the past few months. It has helped us in­tro­duce smaller in­di­vid­ual changes while ship­ping larger fea­tures, mak­ing it eas­ier to re­view PRs. — Tim Neutkens, NextJS lead, Vercel”

“We’ve been us­ing GitHub stacked PRs for Next.js for the past few months. It has helped us in­tro­duce smaller in­di­vid­ual changes while ship­ping larger fea­tures, mak­ing it eas­ier to re­view PRs. — Tim Neutkens, NextJS lead, Vercel”

With stacked pull re­quests, teams can:

Keep large changes mov­ing by re­view­ing short, nar­rowly scoped pull re­quests in par­al­lel.

Maintain qual­ity across every layer by us­ing fo­cused pull re­quest re­views along­side ex­ist­ing branch pro­tec­tions to pro­tect main.

Merge one, some, or all by land­ing an en­tire stack al­to­gether or in­di­vid­ual lay­ers one at a time.

And be­cause stacked pull re­quests are built into GitHub, your ex­ist­ing re­views, checks, and merge re­quire­ments all work out of the box.

“The new Github Stacked PRs pre­view is in­cred­i­ble. Landing 5 stacked PRs di­rectly to a merge queue all at once! A+++! This re­moves so much fric­tion (and the gh cli tools + agent skill help a ton)” — John Resig, cre­ator, jQuery

“The new Github Stacked PRs pre­view is in­cred­i­ble. Landing 5 stacked PRs di­rectly to a merge queue all at once! A+++! This re­moves so much fric­tion (and the gh cli tools + agent skill help a ton)” — John Resig, cre­ator, jQuery

Get started with the CLI ex­ten­sion

Install the CLI ex­ten­sion and cre­ate your first stack in un­der a minute:

gh ex­ten­sion in­stall github/​gh-stack

Create stacks from your ter­mi­nal or github.com

Work with stacks on github.com, the GitHub CLI, the GitHub mo­bile app, or with a cod­ing agent such as GitHub Copilot us­ing the gh-stack skill. Start with a branch and pull re­quest for your first change. Then add branches and pull re­quests on top of it; each pull re­quest tar­gets the layer be­low it.

Review each layer in­de­pen­dently

Open any pull re­quest in the stack to re­view only the diff for that spe­cific layer. Use the stack map at the top of the pull re­quest to see how the change you’re re­view­ing fits into the larger work. You and your team­mates can each re­view dif­fer­ent lay­ers in par­al­lel with­out block­ing fur­ther work.

“AI has made TED’s de­vel­op­ers dra­mat­i­cally more pro­duc­tive, but that cre­ated a new bot­tle­neck: PRs were grow­ing large enough that re­view­ers were strug­gling. Stacked PRs help to solve that. By break­ing large changes into small, de­pen­dency-or­dered pieces, re­view hap­pens in smaller log­i­cal chunks — not just faster PR re­views, but more ac­cu­rate ones. Stacked PRs tighten our feed­back loop and help get sta­ble code to ted.com faster.” — Andy Merryman, CTO, TED

“AI has made TED’s de­vel­op­ers dra­mat­i­cally more pro­duc­tive, but that cre­ated a new bot­tle­neck: PRs were grow­ing large enough that re­view­ers were strug­gling. Stacked PRs help to solve that. By break­ing large changes into small, de­pen­dency-or­dered pieces, re­view hap­pens in smaller log­i­cal chunks — not just faster PR re­views, but more ac­cu­rate ones. Stacked PRs tighten our feed­back loop and help get sta­ble code to ted.com faster.” — Andy Merryman, CTO, TED

Merge every­thing in a sin­gle click

Merge the lat­est ready pull re­quest to land it and every un­merged layer be­low it in one sin­gle op­er­a­tion. To land part of a stack, merge one or more lower lay­ers—the pull re­quests above it stay open and au­to­mat­i­cally re­base and re­tar­get. Your ex­ist­ing branch pro­tec­tions and re­quired checks still gov­ern what reaches main.

“A big change used to mean one gi­ant PR no­body wanted to re­view. Now it’s a stack of small ones re­view­ers can ac­tu­ally fol­low, and the whole stack merges in one shot. It stopped feel­ing like a tool on top of GitHub and started feel­ing like GitHub.” — Mayank Saini, con­nec­tiv­ity en­gi­neer, WHOOP

“A big change used to mean one gi­ant PR no­body wanted to re­view. Now it’s a stack of small ones re­view­ers can ac­tu­ally fol­low, and the whole stack merges in one shot. It stopped feel­ing like a tool on top of GitHub and started feel­ing like GitHub.” — Mayank Saini, con­nec­tiv­ity en­gi­neer, WHOOP

Stacked pull re­quests are rolling out in pub­lic pre­view to all repos­i­to­ries over the com­ing days. Merge queue sup­port for stacked pull re­quests is rolling out pro­gres­sively over the com­ing weeks.

For more in­for­ma­tion, check out the stacked pull re­quests doc­u­men­ta­tion, and share your feed­back with us in the stacks dis­cus­sion.