Strata 0.2.11: Unsloth's new 1- to 4-bit Qwen3.8-Flash-Next files, prompt-speed changes on NVIDIA and Radeon cards, small multi-card starts, chats saved as files, a fix for mixed-up replies from model copies, and GUI and Terminal fixes

The app and the Terminal are 0.2.11. Control and every engine package are 0.1.57. The update feed is sequence 121. The DGX Spark (linux-aarch64) gets 0.2.11 too.

Unsloth's new Qwen3.8-Flash-Next files

On 11-04 Unsloth re-uploaded its Qwen3.8-Flash-Next GGUFs ("Dynamic v3.1"). Strata can now download, prepare and run seven of them in the app, in the Terminal (strata launch --family unsloth --model <name>), and from a folder you downloaded yourself ("Use a local GGUF" in the app, or strata launch --model-path <first file>). Each file is checked by size and SHA-256 against Unsloth's revision d9620119.

• Each set's last file is the 28.8 GB table the model reads per token. Sets that share it share the file: UD-IQ1_M and UD-IQ2_XS use one, UD-IQ3_XXS and UD-IQ4_XS-v31 the other.
• UD-IQ4_XS-v31 is a different file from the UD-IQ4_XS Strata already offers. It has other tensor types and four files instead of three, so it has its own name. The existing UD-IQ4_XS stays as it is.
• UD-Q4_K_XL, UD-Q5_K_XL, UD-Q6_K_XL and Q8_0: Strata keeps downloading the 09-30 files it already uses. The 11-04 UD-Q4_K_XL holds the same weights split into four files in a different place; Strata accepts that split too if you already have it.
• UD-IQ1_S does not load. One of its layers mixes two expert formats, which Strata cannot load. UD-IQ1_M is the 1-bit choice.
• On a Mac, the app and the Terminal offer all seven, and the app now offers Unsloth's sets at all. Before the first start, the Mac writes the experts into one file for the GPU, so it needs room for the download plus that file plus a few GB (about 115 GB for UD-IQ1_M).
• New expert format, Q5_0: UD-IQ4_XS-v31 has it in 33 layers, UD-Q3_K_XL in 20, UD-IQ2_XS and UD-Q2_K_XL in one each. Strata computes it more exactly than llama.cpp's formula does. In our tests the difference from the exact result fell from 2.6-3.0% to 1.2-1.3%, the same as the other formats. The Mac got new kernels for it.

What we ran with real files (start, three chats including a tool call, a clean stop; speeds are decode tokens per second from the engine log on short prompts):

On a Strix Halo, a set whose experts fit the shared graphics memory now keeps all of them there, with no RAM pinned beside it. During testing, the first start of UD-IQ2_XS failed with the earlier plan (a small fixed cache plus 35 GB of pinned RAM); with the new plan it started on the first try and decoded about three times faster. Not run with a real file: UD-Q2_0, UD-Q2_K_XL and UD-Q3_K_XL (their formats ran in the parity tests and in the sets above), any of the new sets on a Mac, and pictures with the new sets on an Arc. On the Arc the DFlash2 drafter's guesses were never accepted with UD-IQ1_M, which costs speed; with the GSQ IQ3_XXS file it accepted 77 to 94% as before.

The numbers first

Speeds are in tokens per second (a token is a short piece of a word). Decode is the speed of writing the answer; a prompt is the text you send, and the prompt speed is how fast the engine reads it. "First token" is the wait between sending a prompt and the first piece of the answer. DFlash2 and MTP are two drafters: small helper models that guess the next words so the main model can check them together. A layer split gives each card some layers of the model; the all-cards split engine gives every card a share of every layer. Experts are the model's specialist parts; a file "streams" when some of its experts are read from RAM or the SSD instead of sitting on the card. A prompt chunk is the piece of a long prompt the engine reads in one go. KL measures how far a model's next-word probabilities move from a reference (0 is identical, lower is closer); top-1 is how often both pick the same next word. The "61-task suite" is our own set of 61 tasks (retrieval, extraction, summary, JSON, code, agent loops) run at temperature 0.

Most speed lines below were measured on engine builds made from the source of this release, in branches before the last merge, and on "package-like" folders (a release package with one engine file replaced); each line says which. The speed lines were not measured again on the 0.1.57 release packages; those packages were installed from a signed feed and run with real models (see "What we ran on the release files"). Many cells are one start per arm or two to three rounds; the line says so, and where a line names a noise level it is the one measured on that box.

• Four Radeon AI PRO R9700 cards (Linux), the all-cards split engine, UD-Q4_K_XL. The 0.2.10 release package against the same package with the new split engine, through a plain strata launch-style start, 2 interleaved pairs, 1 start per run (change in the last column):

  	0.2.10 package	new	change
  1 user, tokens per second	161.8, 161.6	173.2, 172.4	+6.9%
  8 users at once, combined tokens per second	276.3, 263.3	358.4, 357.4	+32.7%
  two prompts of about 103K tokens, seconds each	32.97 / 33.31, 33.71 / 34.14	30.93 / 31.35, 30.12 / 30.61	-8.1%

  The new build has 4 changes: 8 request slots by default instead of 6; the prompt sums go through the other cards' memory, so librccl is not needed; chunks of up to 256 rows are summed in one step; and a cheaper expansion in the IQ3_S, IQ3_XXS and IQ2_S decode math (0 of 25 million test dot products differ). Greedy answers were identical to the 0.2.10 path in each step's check (6.5K, 26K and 103K tokens for the prompt sums; one 26K-token IQ3_S answer for the cheaper math). Without librccl, our screen measured a 103K-token prompt at 30.43 / 30.93 s against 28.91 / 29.42 s with it, and 1 user 1.7% behind it (2 pairs).

  A later change lets the shared expert (an expert every word uses) ride in the routed launches for every expert type, not only Q4_K. Engine-level harness, the build before this change against the build with it, 2 interleaved pairs, 1 start per run:

  UD-Q4_K_XL, 4 x R9700	before	after	change
  1 user, tokens per second	178.9, 178.2	186.1, 185.8	+4.1%
  8 users, combined	367.3, 377.8	384.6, 381.1	+2.8%

• Four R9700 cards, IQ3_S set: Auto now starts the split engine. Through strata launch on a package-like folder with --parallel 8, 1 start per run:

  IQ3_S, 4 x R9700	layer split (--split-engine off)	split engine, before this change	split engine, new
  1 user, tokens per second	104.2	92.8	186.8
  8 users, combined	320.7	303.2	364.6

  A plain strata launch --model-path ... --gpu 0,1,2,3 with no flags picked the split by itself and measured 187.1 and 363.3 (default lanes, no --parallel); a picture (a code, a red square, a blue circle) was read in 1.1 s. Against the layer split on the same prompts (53 prompts, first token and 64 generated tokens): top-1 48 of 53 (90.6%), KL mean 0.0406, median 0.0047, max 0.85; the generated ids were identical on 13 of 53. The 61-task suite, one start each, 4 cards: the split 57 of 61 (fails: agent-A4, agent-A5, extr-M-d28, extr-L-d31), the layer split 54 of 61 (fails: agent-A3, A4, A5, A7, A10, extr-M-d28, extr-L-d31). The two extraction tasks fail in both; the agent tasks change from run to run (one run each, so this is not a verdict on them). Two and three R9700 cards were not re-measured with this change and keep the layer split.

• NVIDIA UD-Q4_K_XL prompts: the K-quant prompt kernels are the default on cards of compute capability 8.0 and up. UD-Q4/Q5/Q6_K_XL files used to be converted to 16-bit numbers and multiplied by a general library; they now run on llama.cpp's MMQ kernels (compact integer kernels for quantized weights). Prompt speed in tokens per second, median of 4 requests per cell, 2 rounds, arms interleaved, a fresh engine per arm per round, MTP, 131072 context, medians shown as old to new:

  card	4K prompt	8K	20K	32K
  RTX PRO 6000 (sm_120, all experts on the card)	2,338 to 3,097 (+37.7%)	3,389 to 4,241 (+25.8%)	3,386 to 4,573 (+34.3%)	3,709 to 4,886 (+32.6%)
  RTX A6000 (sm_86, 13.1K of 24.6K experts on the card)	1,113 to 1,130 (+1.7%)	1,917 to 2,093 (+9.0%)	1,726 to 1,867 (+8.1%)	2,010 to 2,235 (+11.2%)

  Decode speed did not change. This path rounds differently: first-token KL against the old path, 24 prompts of about 2K tokens (19 plain, 5 agent turns): RTX PRO 6000 0.0243 (plain 0.0170, agent 0.0521), top-1 23 of 24; A6000 0.0351 (plain 0.0305, agent 0.0528), top-1 22 of 24 (noise floor 0.0013). The 61-task suite on the RTX PRO 6000, one server start per arm, two starts each: old path 53 and 53, new path 54 and 54 (agent 5 of 10 in all four). Of the 61 answers, 38 are byte-identical between the two paths; the agent flips go both ways in that comparison.

• NVIDIA: a bare --prefill auto now reads prompts in chunks of up to 32768 tokens (it was 8192) on cards of compute capability 8.0 and up. Prompt speed in tokens per second, medians, 4 requests per cell, 2 rounds, a fresh engine per arm, 131072 context; the percent is the paired ratio:

  box	8K	20K	32K	64K	decode
  RTX A6000, UD-Q4_K_XL + the K-quant kernels, 13.1K of 24.6K experts on the card	2,096 to 2,098 (0.0%)	1,866 to 2,675 (+43.4%)	2,247 to 2,752 (+22.5%)	2,343 to 2,840 (+21.3%)	+1.1%
  RTX PRO 5000 72 GB, IQ3_S, all 24,576 experts on the card	-0.8%	+0.05%	-2.0%	+2.0%	-0.6%
  GB10 (DGX Spark), IQ3_S, all experts resident	-0.4%	-2.8%	+2.6%	+8.4%	-0.3%

  The same change on an RTX PRO 5000 as a small PC (IQ3_S, 30 GB of RAM allowed by a cgroup, every model file evicted from the cache before each start so experts really come from the SSD, 2 rounds): 8K +2.4%, 20K +32.6%, 32K +70.6% with 32768 against 8192 (prompt speeds 434 / 446 / 528 against 445 / 592 / 899 tokens per second). The engine's own warning ("about 3x slower") was not reproduced on that fast NVMe drive; a slower disk, Windows or a smaller cgroup were not tested. The prompt borrows more cache slots while it is read (A6000: 4,663 slots / 13.64 GiB against 1,576 / 4.62 GiB) and gives them back. On a 12 GB card or a layer split the engine picked a smaller chunk by itself and speed did not change (one 12 GB card 4,608 tokens, two 12 GB cards 7,168 tokens). The 61-task suite on the streamed A6000 (UD-Q4_K_XL, 2 launches per arm): old 8192 ceiling 56 and 56 (agent 7 and 7); old ceiling plus a different, equally valid rounding switch (STRATA_SELECT_OLD=1) 55 and 54 (agent 6 and 5); 32768 ceiling 53 and 54 (agent 5 and 5). The agent tasks that flip (agent-A2, A4 and A8) are mostly the same in the arms that round differently: A8 is lost in all four arms that differ from the old ceiling in rounding, A2 and A4 in three of them. See "Known problems" for why the first answer of some agent prompts depends on the chunk size.

• Two NVIDIA cards, the all-cards split engine, prompt time. Seconds to the first token, 2 x RTX A6000, Linux, 2 reps in each of 2 starts per arm (4 reps in 2 starts for the 0.2.10 IQ3_S cells):

  prompt	IQ3_S, 0.2.10	IQ3_S, 0.2.11	UD-Q4_K_XL, 0.2.10	UD-Q4_K_XL, 0.2.11
  32K	9.21 to 9.57	8.23 to 8.34 (-12%)	8.92 to 9.06	7.86 to 8.18 (-10%)
  62.9K	18.0 to 18.7	16.52 to 16.75 (-10%)	17.45 to 17.69	15.31 to 15.81 (-10%)
  103K	30.7 to 31.2	27.0 to 27.8 (-11%)	29.6 to 29.8	26.23 to 26.62 (-10%)

  On 2 x RTX PRO 6000 (UD-Q4_K_XL, 2 reps x 2 starts): a 32K prompt 3.27 to 3.58 s before, 2.86 to 3.10 s now; a 62.9K prompt 6.29 to 6.70 s before, 5.47 to 5.69 s now; edit decode 738 to 770 before, 746 to 784 now. The changes: the hyper-connection read (28% of the split's prompt time, done in full by both cards) is divided between the two cards when the start-up check finds a matching math routine (the exact mode, FNX_PF_HCSPLIT=1, is bit-identical to the unsplit path; the default mode 2 also splits shorter chunks and changes the last bits); the prompt chunk is 8192 rows with 4 chunks per pass; the int8 prompt attention is on for IQ3_S-type files and off for the others; and the tensor-core scan for the GDN layers is off for IQ3_S-type files and on for the others. The 61-task suite, one run per arm: IQ3_S with the final defaults 55 of 61 (53 of 61 with the tensor-core scan on in an earlier pair, 56 of 61 with it off); UD-Q4_K_XL 57 of 61 in the run that matches the final defaults (55 of 61 with the int8 prompt attention on, which is why it is off for these files). First-token KL against the unsplit 4096-row path (IQ3_S, 2 x A6000, int8 attention off) at 6.4K, 26K and 103K tokens: 2.6e-4, 6.7e-3, 1.5e-3, top-1 the same on all three.

• FP16 weight cache for parallel requests (Linux NVIDIA, automatic). RTX PRO 5000, IQ3_S, MTP, --parallel 8, 32K context, 5 paired blocks, engines interleaved. Total tokens per second, old to new: 1 request 130.9 to 135.8 (ratio 1.038), 2 requests 137.2 to 144.1 (1.050), 4 requests 175.1 to 185.1 (1.057), 8 requests 197.8 to 210.9 (1.066); one solo 512-token request 175.7 to 178.6 (1.016). The cache keeps 3 GiB of the card free. Output is bit-for-bit the same: 100 of 100 test combinations equal on sm_120, sm_86 and sm_121, greedy answers identical on 12 of 12 prompts, first-token KL 0 on 25 requests.

• Linux Radeon (gfx1200 / gfx1201, R9700 class): the route-tail skip stays on for Unsloth files. Setup used to write STRATA_ROUTE_TAIL_SKIP=0 for Unsloth (UD) files whose experts are all in RAM; on these cards it no longer does, and the engine's own default (skip experts that every token of a verify window routes at rank 7 or lower and that are not on the card) runs. One R9700, UD-Q4_K_XL, 2 rounds x 8 held-out classes interleaved: decode geomean +6.18% (chat_advice +16.0%, math +12.0% / +7.8%, code +9.6% / +5.4%, summarize +2.0%, xchat4 -2.2%, xchat5 +0.2%); absolute 72 to 104 tokens per second with the skip, 66 to 97 without. Median decode over the 61 suite tasks 90.9 against 78.6 (+15.6%). Quality: teacher-forced KL against no skip 0.07731 (top-1 91.11%; by segment code 0.0271, docs 0.0931, english 0.0396, multilingual 0.0236, agent 0.2033) on a fixed cache with a 54 to 63% hit rate, an upper bound for real use, as the test notes put it (the engine in real use adapts to about 81%); the text's perplexity was 3.985 with the skip and 4.093 without. The 61-task suite: 56 of 61 with the skip against 55, 57 and 56 for the default arms; 36 of 61 answers byte-identical to the default arms.

• Small multi-card starts (Linux NVIDIA, layer split). Two RTX PRO 6000 cards held to N MiB free each by a program that holds the rest, Qwen3.8 IQ3_S, 128K context, int8 KV, Auto drafting (DFlash2), decode is the geomean of 3 to 4 classes x 2 reps, launch-to-launch spread about 5%:

  free per card	0.2.10 / base	0.2.11
  2 x 8 GB	stopped after 71 s ("too little free VRAM for the prompt path"); 6 of 6 product starts failed	starts; decode 110.5; 32K prompt in 14.5 s
  2 x 12 GB	decode 125.6; 32K prompt 5.03 s	decode 134.9; 32K prompt 5.35 s (the new steps were not used here; the difference is launch spread)
  2 x 16 GB	started, then "mmq out of memory" on the first JSON-extraction or agent prompts	decode 167.7; 32K prompt 4.39 s
  2 x 6 GB	stopped	starts after every step; decode 26.1; 32K prompt 47.5 s (engine cell only, not through the launcher)

  Through strata launch (real cards with the holding program, --split-engine off, Auto drafting) 2 x 8 GB, 2 x 12 GB and 2 x 16 GB started and answered a chat, a picture and a 43,265-token prompt with the context and request count unchanged (2 x 8 GB: 31.0 s for the prompt, 2 x 12 GB: 8.1 s). The same check on 2 x RTX A6000 held to 12 GB free each started, with the 43,265-token prompt in 17.9 s. With nothing held (2 x 96 GB free, engine cells) the answers were identical (5 of 5 hashes) and decode was 323 against 323. With a few cards this small, long prompts are slow: 1,000 to 2,200 tokens per second against 6,000 to 7,000 on larger cards, because the small-card prompt path is still single-card only. Three small cards were covered by unit tests only.

• CUDA layer split and the CPU / upload share for missed experts. When some experts are not on the card, the engine splits their work between the CPU and the PCIe link. The share now follows the CPU's measured speed by default on a discrete card (ceiling 0.95, instead of 0.60). Two RTX PRO 6000 held to N GB free per card, layer split, IQ3_S + MTP, n=3 per class, one launch per cell:

  	0.2.10 rule	new rule
  12 GB per card, decode tokens per second, Auto placement	133.6	151.0 (+13%)
  12 GB per card, fixed placement, 2 launches	138.0 / 132.4	153.3 / 149.2
  16 GB per card	171.0	174.7 / 182.9
  one card, 12 GB, 2 CPU workers	31.1	62.7 (+102%)
  one card, 12 GB, 4 CPU workers	58.3 / 57.0 / 53.8	79.1 (+40%)
  one card, 12 GB, 8 CPU workers	82.1	91.4 (inside the 7% launch spread)
  one card, 12 GB, 32 CPU workers	118.7 to 120.5	119.7 (same share decisions)

  Quality on the two-card layer split: first-token KL 0.0316 against share 0.55 (92.3% top-1); the single-card rule already shipped measured 0.0310 (92.2%). The 61-task suite, 2 launches per arm: totals 54 and 53 before, 53 and 54 after; agent tasks 7 and 6 before, 4 and 5 after. That agent difference is larger than the spread inside one arm but rests on 2 launches per arm. A single-card suite pair at 12 GB (old fixed rule 53 of 61 and agent 6; the shipped rule 53 of 61 / agent 6, then 52 of 61 / agent 5) shows the same arm moving by one task between launches.

• DFlash2 and MTP with several requests at once (Linux, one RTX PRO 6000, UD-Q4_K_XL). Aggregate tokens per second of 1 to 8 closed-loop users on mixed classes (code, agent, JSON, app sampling), the engine's batch path, 2 engine starts x 2 reps per cell, noise about +-3% per cell; the GPU next to it was partly busy with another job during every cell:

  users	no drafter	MTP	DFlash2 (--draft dflash2 --batch 8)
  1	105.7	136.9	146.8
  2	150.9	172.4	171.2
  4	176.6	192.2	180.7 (spread 154 to 190)
  8	209.8	190.6	194.0

  In a 16-minute session that mixes 1 to 8 users (the first run produced 189,579 tokens for both arms), the recheck with the other GPU idle ended at 192.9 (MTP) and 192.0 (DFlash2) tokens per second. DFlash2 re-records the GPU programs for each batch shape (3.2% of its wall time against 0.7% for MTP); with that recording time taken out of the wall time the numbers were 198.5 (DFlash2) and 194.3 (MTP). Auto still picks MTP when several requests run at once; nothing about that default changed. The levers we tried (a larger program cache, dropping drafts at 6 or more users) stayed in a research branch and are not in this release.

• DFlash2 on the all-cards split engine: an engine flag only, Auto keeps MTP there. Two RTX A6000, UD-Q4_K_XL, 128K context, decode tokens per second, 2 starts per arm, 3 repetitions per workload, noise about +-3%:

  workload	MTP	DFlash2
  1 user, code (greedy)	214.6	235.1
  1 user, JSON (greedy)	226.4	238.4
  1 user, edit (lookup-heavy)	379.8	382.9
  1 user, prose (app sampling)	137.5	136.1
  1 user, prose (temperature 1.0)	138.8	128.7
  1 user, agent (temperature 1.0, 6 turns)	155.3	145.0
  8-user set, c=1	100.6, 99.5	98.0, 101.8
  8-user set, c=2	138.4, 138.9	128.7, 137.4
  8-user set, c=4	163.4, 166.4	154.0, 153.6
  8-user set, c=8	182.3, 186.7	183.9, 185.1

  Greedy answers were identical between DFlash2, MTP and no drafter (6.4K and 27K prompts for 1 user, 8 different requests at once for 8 users). Prompt time: first token for an 8K prompt 2.74 s (DFlash2) and 2.77 s (MTP), 32K 7.59 s and 7.77 s. DFlash2 takes 690 MiB (1 lane) to 1294 MiB (8 lanes) on card 0; the MTP layer takes its share on both cards. Sampled decoding with DFlash2 on the split was not run through the 61-task suite.

• Strix Halo (Ryzen AI Max, Windows, gfx1151): checked against 0.2.10, no speed change claimed. The new engine build against the 0.2.10 package, 3 interleaved pairs, order alternating, prompt speed in tokens per second (old / new, ratio): IQ3_S 4K 1322.6 / 1332.4 (1.0075), 8K 1447.4 / 1456.6 (1.0065), 20K 1475.1 / 1467.2 (0.9947); UD-Q4_K_XL 4K 537.3 / 541.0 (1.0068), 8K 774.3 / 778.4 (1.0054), 20K 854.3 / 858.2 (1.0046). Decode: IQ3_S agent 53.51 / 53.55, chat_explain 52.25 / 52.34, code_py 57.83 / 57.85, json_extract 67.59 / 67.48; UD-Q4_K_XL agent 47.14 / 47.07, chat_explain 36.16 / 36.19, json_extract 44.04 / 43.83 (code_py swings 9 to 10% by itself because the speculative windows differ from run to run: 39.15 / 39.09). First-token logits were bit-identical in 20 of 20 prompt / model combinations. The staging ring measured on the R9700 was also active on the Strix and measured level there; it is now limited to gfx12 cards and the Strix keeps the 0.2.10 ring.

• Measured, not changed. One R9700, UD-Q4_K_XL: more resident experts (+100 slots = +0.3 hit points, about +0.5% decode), a UD-specific shipped hot-set profile (+0.6%), the swap budget (96 swaps every 4 rounds, 24 to 384 tested), and the CPU lane (headroom estimated at 3 to 5% of a window with a faster kernel; not built) gave nothing worth a default. On the Strix a smaller expert cache (--expert-cache 12500 against the engine's automatic 22,906 slots) read prompts 11 to 14% faster (4K 654 / 657 / 658 against 573 / 580 / 580 tokens per second; 15 of 15 pairs positive, first-token KL median 1.4e-5, max 1.5e-2), but the gain depends on the machine's 64 GB graphics split, comes in levels that change from start to start, and 12500 sits 1500 budget units from a size where the engine does not start (11000). We left the default. On the Intel Arc A750 a new 10-class A/B gave DFlash2 over MTP a geomean of 1.008 (DFlash2 faster in 7 of 10 classes; the 0.2.10 figure of 2.6% slower came from a different request mix); Auto stays DFlash2 there.

What is new

• Chats are files in Strata's data folder, not browser storage. Each chat is a file chats\<id>.json with an index.json beside them; the text is saved byte for byte, with no 5 MB limit. Writes go to a temporary file first and are renamed into place, so a crash in the middle leaves the last good copy. If a chat cannot be written (full disk, no permission) it stays whole in memory, a notice says so once with a "Copy unsaved chats" button (nine languages), and it is retried; the notice goes when the chat is saved. Two windows see each other's changes. The first start with 0.2.11 hands both of 0.2.10's browser layouts to the host once; the browser copy is left untouched for one release. The privacy note now reads "Conversations stay on this computer, in Strata's data folder."
• A running agent turn is taken over again after a reload. If the page is reloaded or closed while an agent is working, the host keeps the turn running (as before). The reloaded page now finds it, shows the reply so far with its Stop button, and carries on in the same reply; a turn that finished while the page was away is shown whole once. Before, the chat showed "Network error", had no Stop button, and a new message was refused ("This chat is still working"). No new wording.
• The desktop app starts the all-cards split engine wherever the Terminal does. With Drafting on Auto, two or more matching cards that the split engine takes now start it, with the MTP draft layer (the app fetches the 5.2 GB layer if it is missing); other cases keep the layer split with DFlash2. The app now runs the same conversion step the Terminal runs (strata split-engine apply); it did not run it before. An explicit MTP choice starts the split like the Terminal does. This was tested with a fake Control and plan-only runs, not with the packaged app on a two-card Linux PC.
• Choosing DFlash2 yourself keeps the number of requests you chose (one card and layer split; app, Terminal and server). It starts --draft dflash2 ... --batch N with per-request drafters of about 85 MiB each. A start check on one card (--drafting dflash2 --parallel 4, n=1, a start check and not a speed measurement): "4 slot drafters ready", 4 different questions at once all answered correctly. Choosing DFlash2 with no number still means one request at a time, and Auto still picks MTP when several run at once. On Apple Metal the engine has no per-request drafters, so a named DFlash2 with several requests starts MTP as in 0.2.10. The all-cards split engine takes DFlash2 only on --split-engine on plus DFlash2 by name (engine flag; no launcher or app change for it otherwise).
• Small multi-card layer splits start by walking down a list, and the context never shrinks. When a card is short of memory the engine now trims the dense weights each card carries, steps the KV window down (20480, 8192, 4096 cells), drops the drafter on the card that holds it, keeps 16 prompt-path cache slots, puts the output head in pinned host memory on the last card, and leaves a card out when it has under 3 GiB free (or even the whole list would not pay for the layers on the cards left). Each step is one short of GPU memory: line. The launcher's one retry after a memory stop now uses no drafter (never DFlash2 turned into MTP), and the last line of the failure message is the engine's own reason. A later card now prices 256 MiB for late allocations; that is what removes the 0.2.10 out-of-memory crash on 2 x 16 GB.
• The split engine's Auto looks at free memory, not card size. A card now counts with its free memory minus 700 MiB (the engine's default reserve); if that is below what the split needs, the cards no longer get the split plan and the 5.2 GB draft-layer fetch, and Auto uses DFlash2. When you relaunch while your own server is running, that server's memory is not counted as busy.
• The draft layer is also looked for in --data-dir (and the data folders Strata remembers). In 0.2.10 a model folder outside the data folder could show "About 6.1 GB to download" for a draft layer (5.2 GB) and the picture reader that were already there; the plan now says "Nothing to download" when they are.
• The plan's card line shows both numbers: Main: GPU 2 (--gpu 1) RTX PRO 6000. Helper: GPU 1 (--gpu 0) .... Screens and setup still count cards from 1; --gpu counts from 0. Cards hidden by CUDA_VISIBLE_DEVICES (NVIDIA) or ROCR_VISIBLE_DEVICES / HIP_VISIBLE_DEVICES (AMD) are left out unless you name them. When the app switches from one model to another, the plan no longer counts the memory of the engine it is about to unload as busy.
• One order for engine options in strata launch: values you give on the command line, then your saved overrides (user_args and hand edits to the launch file), then calibrated values from calibrate --apply-result, then Auto. A --set draft-conf you give survives, and --set mmap-experts on|off|auto keeps its word for DeepSeek (Qwen stays a bare switch).
• The desktop window recovers from a dead page. If the page's renderer (WebView2) dies, the shell reloads the same screen, then the home screen on a second death, and leaves the browser's own error page after a third death within two minutes (Reload then works). Windows was run for real; the macOS hook was not compiled and Linux is unchanged.
• Menus are placed so they can be read at every Interface size (one extreme case is listed under #4653 below; composer Mode, sidebar More, Reasoning effort, Add or open, chat options, model picker, subagents, and every dropdown in Settings, Models and the tune dialogs).
• Quiet answers keep the connection: a chat stream with nothing to say for a while sends a small beat frame every 15 seconds so the desktop web view does not drop it.
• Terminal: the ? key list in the monitor stays up for 15 seconds (it was wiped by the next one-second refresh) and wraps at 80 columns and at 60 columns so every key shows; ? again, Esc or a change of view closes it. The list does not name the / filter or the b key that the Serving footer shows.
• Terminal: port-denied text names the right cause on Linux and macOS ("This system does not allow it (on Linux and macOS, ports below 1024 need administrator rights): start this one with a different --port"). It used to name Windows and netsh on Linux.
• Windows: fewer background questions. launch --plan ran the same PowerShell display query 18 times (26 child processes, 15 to 17 s) and nvidia-smi 19 times once an engine was installed. The display query is now asked once per process for 2 minutes (a stuck one is cached too) and nvidia-smi once per field per 30 s. On the owner PC the plan started 10 child processes (it was 27), 4 nvidia-smi starts in total, and took 7.2 s.
• Desktop: the first start from every new install path no longer asks Windows Defender Firewall about Node.js. The host's start-up probe for the sharing port listened on all addresses for an instant; it now listens on 127.0.0.1. Sharing is unchanged.
• Pictures: a fixed list of formats. Strata opens JPEG, PNG, GIF, BMP, WEBP, TIFF and AVIF pictures only (see the security fix below). A JPEG 2000, ICO, PPM or PSD picture now gets the existing "the image could not be read (...)" message instead of being converted.

Fixed

• A reply could go to the wrong request when a model runs in more than one copy (#2892, a privacy bug). With replicas (the same model loaded twice so two requests run at once), the request that took a copy over could read the one before it finished: it got an empty reply, or text containing the earlier request's text, and its token counts were the other request's. We reproduced it on the old code by forcing the hand-over moment: 30 of 30 forced hand-overs crossed. The window is microseconds wide, so 60 unforced back-to-back requests were clean on the old code too. Now the first request's output is closed before the copy is released and the figures are copied per request: 30 of 30 forced hand-overs and 60 of 60 unforced requests are clean, and a frozen copy (stopped with SIGSTOP) leaves routing and its error reaches the caller. Python server only; the engine C++ was not touched. Related, not reproduced (#4451): batched output reaching another client could not be reproduced with the fake engine or a real one (680 clients per arm on an RTX PRO 5000, IQ3_S, --batch 4, 0 cross-deliveries on the old and the new code); two real holes were shown and fixed in the Python server (after an engine restart a request of the old process stayed attached to the new process's slots; vram() and session_file() could take a running request's lines, which ended a request at 212 of 421 tokens).
• Chat and the app:
  • #5192: with long chats the saved copy lost text. In a test, 12 messages of 140,000 characters were sent through the old writer and 6 came back; now 12 of 12 come back byte for byte after two restarts. On the Windows app, a chat of 16 big messages (110 KB x 12 and 300 KB x 4) lost 8 of 16 in the session before and kept all of them (3.59 MB) after quit and restart; a second run restored 34 messages with 0 clipped. Text already cut by the old writer ([shortened in the saved copy]) cannot be recovered.
  • #5008: with two chats in one folder, a turn listed the other chat's file as its own. A turn now reports only the files its own tools wrote (Windows app, 3 to 4 rounds with marker files: own file only, right content).
  • #5079: a dead WebView2 renderer left a blank white window. Killed by process id on the Windows app: the page came back in about 3 s (kills 1 and 2), the third kill within two minutes left the browser error page and Reload restored the chat. Before, no recovery.
  • #5180: the Markdown preview did unbounded work while tokens streamed (50 unrelated updates were 50 renders before, 0 after). We could not reproduce the reported 4.4 GB memory blow-up from the report itself. On the way we found and fixed a second bug, which is also in 0.2.10.
    • A Markdown list with Windows line ends (CRLF), which PowerShell's Add-Content writes, made the renderer loop until memory ran out. In the changed-file case it grew to 4.4 GB in 25 s, on 5 of 5 runs.
    • A unit test shows the loop: the old code runs out of memory in 4 of 4 runs and the new code passes 4 of 4. A plain browser test did not show it; the check in the real app did.
    • It may be what the report saw; we can't confirm that.
    • On the release-candidate app build the same case showed "Version Two" six times with the renderer at most 171 MB. A page reload after killing the renderer with the preview open stayed at 159 MB.
  • The sidebar preview used to keep the first content of a file it already showed; it now shows the file's current content after it changed on disk.
  • #4653: the sidebar More menu (and other menus) opened off screen at an Interface size other than 100%. Edge 156 matrix (4 display scales x 3 window heights x 7 Interface sizes), cases passed 0.2.10 / this release: Mode 43 / 77 of 77; sidebar More 49 / 84 of 84; Reasoning effort 20 / 76 of 77; Add or open 47 / 76 of 77; chat options 22 / 77 of 77; model picker 55 / 77 of 77; subagents 35 / 77 of 77. The Settings dropdowns (72 cases each) 4, 33, 3 before and 69, 61, 61 after (the rest are harness rows where the control scrolled out of view at 200%). Left as it is: at display scale 175% + Interface size 200% + a 600-pixel-high window (a 343 px page) Reasoning effort's first item is covered and Add or open covers part of its button. A dropdown now opens as tall as the room allows instead of a fixed 320 px.
  • #4397: an empty or malformed Host header killed the app host; it now gets a 400 ({"error":"bad_host"}) and the host keeps running.
  • #4535: the API key is compared in constant time (SHA-256 digests); two other header secrets too.
  • #4221: opening /?q=... in the web client sent the question at once; it now fills and focuses the box and sends nothing until Send (4 cases on the app: plain, punctuation, unicode, 6,000 characters).
  • #4878: a quiet stream could be dropped by the web view (see the beat frame above).
  • #4533: Linux, a chat title cut in the middle of an emoji; titles are now cut at a character.
  • The Models page showed "Connect engine" and "Download & load" for a model that was already downloaded, for about 30 s after an app start (7.6 s to 35.8 s, 3 of 3 rounds). The host now says it is still checking until Control has answered, and the page shows the existing "Checking..." label. On the release-candidate app build, 3 of 3 rounds showed "Checking..." and then "Load model", with no wrong label, while a build ran on the same PC.
  • Start-up: the page could stay on "Connecting to the local engine..." when one of its start-up requests hung. Only the requests for setup, models, engine, serving and workspaces are needed to go live, each with an 8 s limit and 3 tries; the others (hardware, monitor, skills, providers, image models, runtime) fill in when they arrive. With /api/hardware made to hang, the full interface was up at once and the request was retried 3 times in 20 s.
  • Settings showed "args_written is not a setting Strata reads" on every freshly set-up model; those keys are known now.
  • A low-RAM copy of the experts that did not fit on disk named the model folder's drive; it now names the packs folder in Strata's data folder and the free space there, with next steps.
• Starting, stopping and updating:
  • #5177, #5059: the app declared a start failed while the engine finished loading fine (Control's owner process answered its status request only after planning, with a 5 s limit; the first-token check shared the load's deadline). Planning now runs in a thread with phases (preparing, launching, loading, checking the engine, verifying generation), the status call is retried while the owner lives, and the first-token check has its own 180 s budget. The full SHA-256 pass over the engine files is kept.
  • #4973 (macOS): the owner stopped the engine silently when one look at the app host failed; it needs 3 failed looks in a row now, and the app marks the instance stopped after 3 failed polls when Control says stopped, failed or stale. We have no Mac that reproduced it; the causes are from the code and the issue's log. #4293 (PR): the app keeps and watches a start that Control stopped waiting for.
  • #4975, #5185 (Windows): Control identified the computer through WMI, which can hang; the operating system and machine are now read without it. A stuck WMI cost 18 queries x 15 s in a plan before.
  • #4574, #4893: a host that outlived its server now reports failed with a log tail for 10 s and leaves. #4824: strata launch already cleared failed hosts and kept --save-preset after a failed start; the host that stayed alive after its server exited was the #4574 case. #4250: a host lost before launch is recovered when its marker is exact.
  • #4529, #4570: Stop and a timed-out command end the whole process group on Linux and macOS (as taskkill /T does on Windows). On the Windows app an agent command with child processes, then Stop: 5 processes, all gone 4.5 s after Stop.
  • #4260: bench run --profile puts the engine tree in a job object and ends it through that. We did not reproduce the original "Access is denied".
  • #4463: strata update now sees a server started by running serve.py directly and uses a checkout's own engine store. #4352: the free-memory check releases this server's own picture encoder.
  • #3961 (mitigated, cause unknown): a stream that ended without an end event is now an error and the engine is ended, so "the next request restarts it" is true; the engine is ended only if it is still the process that request ran on and nobody else has the turn.
  • #4895 (partly): a memory wait that found nothing freed is not repeated for every later tuning candidate.
  • #4661 (Windows, whole-PC freeze after launch, bounded not reproduced): the drive-temperature reader now runs only for the Monitor screen's own request, never in the first 60 s of the host, asks only drives Windows names NVMe, one at a time, and a marker file drive-temperature.probe in %LOCALAPPDATA%\Strata stops it from starting again after a crash or a first pass longer than 45 s. Not run on any PC that froze. See "Behaviour that changed".
• Terminal and launcher:
  • #4395, #4396: a damaged profile lent its neighbour's config or port, or made launch mint a new API key. Reproduced and fixed.
  • #4398: a failed launch --stop exits non-zero and no longer ends with "Nothing is running".
  • #5178, #5132, #4985: a --set draft-conf was saved as 0.35 but the engine got 0.8; launch now rebuilds the launch file with calibrated values and hand edits carried (see the order above). The hand-typed settings.json calibration keys in the second observation of #5132 were not investigated.
  • A launch whose own profile or run config could not be read (permissions) used to make a new API key and then fail; it now stops before anything is written (exit 2 for the profile, 6 for the run config), with owner-approved wording, and "A new API key was made" is said only after the run config holding it is written. Checked on Linux.
  • bench run --profile ended with SIGTERM left the engine (Linux) or the server and the engine (macOS) running; SIGINT during the model load lost the child. Both now end in 1.2 to 2.9 s with nothing left (Linux RTX PRO 5000: 2.7 s and 2.4 s; Mac M4: 1.2 s and 2.9 s).
  • #4484, #4483: bench results.json is redacted like the other report files; a credential of "none" is no key; a key is replaced as a whole word in its own case and next to a hyphen; redacting twice gives what once gives (no <<user>>). A login or host name that is an ordinary word no longer rewrites field names or reasons (it turned "user payload" into " payload").
  • #5006: client config for OpenCode and Claude Code writes an output cap of max(4096, context / 8) (16384 at 128K) instead of 4096, and keeps a cap you set. Config side only; not run in OpenCode.
  • #5027: --set mmap-experts on|off|auto works for DeepSeek. #4088: a full-length model shard whose size is pinned is hashed and repaired instead of being marked whole.
  • #4971, #5111 (partly): an integrated GPU (a 512 MiB Radeon carve-out) no longer outvotes a discrete Arc card, card numbers above 9 are seen, and an unlisted Battlemage or Alchemist id counts as an Arc of the family's smallest memory. No Battlemage card to run it on.
  • #5086: the Intel (SYCL) server crashed at start with unexpected keyword argument 'announce'. Fixed; real start on an Arc A750 (IQ3_XXS, 12.4 tokens per second, 3 chats answered right, no GPU hang).
  • #5056, #5122, #5078 (first two points): tuning now starts its worker without STRATA_API_KEY; a candidate that adds no memory is judged against the memory the base had free at its own start; a skipped-for-memory run says "N settings could not be tried: not enough free memory" (the Terminal says "some not tried") instead of "already the fastest we found"; an engine abort shows its own error line and counts as out of memory.
  • update --check on a source checkout prints the tree's own Control version instead of ?.
• Tool calls and the server:
  • #5040, #4701: a streamed tool argument that lists the closing tags lost its end when text arrived in small pieces (139 of 216 characters came through at chunk sizes 1 and 7). The call is held while a closing tag is arriving; the final call was already whole.
  • #4738: a request waiting for the control lines could miss a wake-up. #4271 (part 1): a streaming client that stops reading no longer holds the engine's turn (a socket write with no progress for 60 s ends the request as a disconnect). #4479, #2481: server console output goes through a bounded queue so a blocked console cannot hold a request. #4792: a failed engine start no longer crashes when another thread closed the process. #5044 (Python parts): a refused batch admission is an error row with no totals, and engine output with a byte that is not UTF-8 is read. #3443: ConvCacheLog.poll runs under a lock.
  • #2518: a branching follow-up of a long chat went to the wrong slot, so another chat's slot was used. Simulation (4 chats of about 9,600 tokens, 12 interleaved branching follow-ups): retained prefix 96,000 tokens (83%) before, 115,200 (100%) after. Not a GPU run.
• Security:
  • Pillow 13.0.0 (advisory GHSA-78g4-xqwv-q3g8, severity high: a memory-write bug in the JPEG 2000 decoder, reached by opening a crafted picture; affects 11.1.0 up to but not including 13.0.0). Python 3.11 and newer get 13.0.0; Python 3.10 stays on 12.3.0 and is covered by the format list above. The 0.1.57 Terminal and Control for Linux x86_64, Windows, the Mac and the DGX Spark carry Pillow 13.0.0 with Python 3.12, and so does the Control inside the desktop installers; engine packages carry no Python. An existing install keeps 12.3.0 until it is updated.
  • #4202: the prompt for the image tool (sd-cli) went on the command line, where other programs on the computer could read it; it now goes in an owner-only file (--prompt-file). Not run with a real sd-cli.
  • #5075: quant_formats --hf crashed with an AttributeError; fixed.
• Engine (Qwen):
  • The 0.2.10 crash on 2 x 16 GB layer splits ("mmq out of memory" on the first long prompt) and the failure of every start on 2 x 8 GB (see the table).
  • Strix Halo, UD-Q4_K_XL, a prompt chunk of 32768 (STRATA_PREFILL_AUTO_MAX=32768 or --prefill auto:32768, which nothing sets by itself on a Strix): the engine died after reading the prompt when the shared memory pool was nearly full (a stream for the next step could not be created). It now stops at the start with one line and exit code 2 before any prompt is read: "a 32768-token prompt chunk does not fit beside the 52.1 GiB expert cache on this GPU (a stream could not be created): use --prefill auto:16384, or a smaller --expert-cache". The 0.2.10 engine crashes the same way. The check catches the case when the pool is full; on one Strix start through the Terminal (automatic cache and expert-cache=14000) the engine instead started and stepped the chunk down to 6144 at the first request. The setup tip for 32768, the tuner's prefill_32k arm (discrete GPUs only now) and the app's automatic retry no longer apply to a Strix. The stale #1630 warning is no longer printed on a Strix.

Probably fixed, please retest

• #5071 (Japanese input): the Enter that commits a conversion no longer sends the message (first Enter within 50 ms after the composition ends, or key code 229, counts as the IME's). We replayed the event orders of WebView2, WKWebView and WebKitGTK; we did not capture them on a real WKWebView or WebKitGTK.
• #4533, #4485 (Linux): the window aborted when drawing the COLRv1 colour emoji font in WebKitGTK. The shell now keeps that font away from the window process only, and only when it is installed. The crash and the fix were not shown on WebKitGTK.
• #4661 (Windows freeze): see above; we could not run it on a PC that froze. If your SSD temperature line is missing in the Monitor, see "Behaviour that changed".
• #4973 (macOS), #3961, #4895, #4260: fixes from reading the code and the reports; see the lines above.
• #3750 (reserve of 3256 MiB on a 16 GB card): already capped at 1536 MiB for cards of 16 GB or less in 0.2.10, now pinned by tests. The engine still skips every memory adaptation when --vram-reserve-mib is given and the app always passes it; that part needs an engine change and is not in this release.
• #5111: an unlisted Battlemage card counts as an Arc; not tried on one.

Behaviour that changed

Each line says how to put 0.2.10's behaviour back. A value you set yourself is kept unless noted.

• NVIDIA, compute capability 8.0 and up: the K-quant prompt kernels are on for Unsloth UD-Q4/Q5/Q6_K_XL files. Off: STRATA_MMQ_KQ=0, STRATA_NV_KQ_DEFAULT=0, or STRATA_DEFAULTS=026. Volta, Turing and Pascal keep the old path.
• NVIDIA, compute capability 8.0 and up: a bare --prefill auto takes a 32768-token ceiling (was 8192). The fit scan can still pick a smaller chunk when the cache cannot lend the buffers, and the RAM guard steps 32768, 16384, 8192 when memory is short. A layer split takes 8192 back (STRATA_SPLIT_CHUNK16K=1 keeps the ceiling). Back to 0.2.10: STRATA_NV_CHUNK=0 or STRATA_DEFAULTS=026 (8192); STRATA_NV_CHUNK=16 keeps 16384; STRATA_NV_CHUNK=1 skips the RAM guard. An explicit --prefill N, --prefill auto:N or STRATA_PREFILL_AUTO_MAX is never touched. Volta, Turing and Pascal keep 8192.
• Linux Radeon gfx12 (R9700, RX 9000): the K-quant prompt kernels are on (off: STRATA_MMQ_KQ=0, STRATA_GFX12_DEFAULTS=0 or STRATA_DEFAULTS=026); the bare --prefill auto ceiling is 32768 (was 16384; STRATA_GFX12_CHUNK=16 keeps 16384, =0 keeps 8192); the prompt staging ring is 256 or 192 slots below chunks of 12K tokens (back to 96: STRATA_GFX12_RING=0 or STRATA_PREFILL_RING=96). Setup no longer writes STRATA_ROUTE_TAIL_SKIP=0 for Unsloth files on these cards (back: set STRATA_ROUTE_TAIL_SKIP=0). R9700 numbers for these defaults, from the tests that led to them: K-quant kernels 4K +10.3%, 8K +14.3%, 32K +16.8% (n 3, first-token KL 0.031, agent 0.065, top-1 23 of 24); the 32768 ceiling IQ3_S 8K +0.9%, 20K +12.1%, 32K +1.3%, 64K +2.6% (3 rounds; KL at most 5e-5 against the default) and UD-Q4_K_XL 20K +26% (n 2); the ring on IQ3_S 2K +2.3%, 4K +16.1%, 8K +2.7%, 20K +0.1%, 32K +0.1% (first-token logits and 12 of 12 greedy hashes identical). The Strix keeps the 0.2.10 ring and the 16384 chunk.
• Linux NVIDIA with batch slots (--parallel or --batch of 2 or more): the FP16 weight cache is on, keeping 3 GiB of the card free. Off: STRATA_PF_W16_CACHE_MIB=0. Not on Windows, AMD or Metal.
• Auto starts the all-cards split engine on 4 R9700 cards for IQ3_S-type files too (expert types Q2_0, IQ2_S, IQ3_XXS, IQ3_S, IQ4_XS, IQ4_NL). Two and three cards are unchanged. Off: --split-engine off. The AMD split engine's default is 8 request slots (was 6); a number you choose with --parallel stays; NVIDIA keeps 6. FNX_PF_PEER=0 brings back the host-memory prompt sums, FNX_PF_A2A_ROWS=0 the ring for short chunks, FNX_SH_FUSE=0 the old shared-expert path.
• Auto for the split engine counts free memory minus 700 MiB, not card size. Busy cards get DFlash2 and no draft-layer fetch.
• Two NVIDIA cards, split engine: new prompt-path defaults (the hyper-connection read divided between the cards when a matching math routine is found, FNX_PF_HCSPLIT=2 with 4 chunks of 8192 rows a pass, passes limited to 8192 rows while other requests decode; the int8 prompt attention FNX_PFX_ATTN_I8 on for IQ3_S-type files and off for others; the tensor-core GDN scan FNX_PFX_GDN_TC off for IQ3_S-type files and on for others). Four chunk sets instead of two cost about 0.6 GB more per card; on a UD-Q4_K_XL file on 2 x 48 GB cards the engine picks the largest of 8192 x 4, 8192 x 2, 4096 x 4, 4096 x 2 chunks that fits (A6000: 8192 x 2). Each variable accepts =0 or =1; for 0.2.10's path set FNX_PF_ROWS=4096, FNX_PF_HCSPLIT=0, FNX_PFX_ATTN_I8=0, FNX_PFX_GDN_TC=0. The HCSPLIT=1 form is bit-identical to the old path; the 8192-row chunk and the int8 attention change the last bits.
• CUDA layer split and single discrete cards: the CPU / upload share follows the CPU pool by default (ceiling 0.95, factor falling from 1.85 at 30 GB/s of expert bytes to 0.8 at 12). Back to 0.2.10: STRATA_PCIE_AUTO_SPLIT=0, STRATA_PCIE_K_RULE=0, STRATA_PCIE_SHARE_MAX=0.60. Integrated GPUs, HIP layer splits and STRATA_DEFAULTS=026 keep the old rule.
• Layer splits on short cards trim and walk (see What is new). Cards that hold only part of their experts (the 12 to 24 GB class) have a 256 MiB smaller cache on later cards, which can change the last bits of a greedy answer; cards that hold everything are bit-identical. Old path: STRATA_STAGE_TRIM=0, STRATA_SPLIT_EARLY_OFF=1, STRATA_SPILL_OFF=1; keep the drafter: STRATA_MTP_KEEP=1; the 256 MiB term is off under STRATA_DEFAULTS=026.
• A named DFlash2 keeps your number of requests; it used to fall back to MTP with "DFlash2 isn't available in this mode". Back: --drafting mtp or Auto. A start that stops for lack of memory is retried once with no drafter.
• Chats are stored in the data folder. A 0.2.10 app opened later still reads its own browser copy, which 0.2.11 no longer updates (the move left it untouched); chats made in 0.2.11 are only in the chats folder. There is no setting to turn the new storage off.
• The plan's card line has both numbers (see What is new).
• Streams: a socket write with no progress for 60 s ends the request as a disconnect (STRATA_STREAM_WRITE_TIMEOUT_S, 0 = off); server console output goes through a bounded queue (STRATA_BLOCKING_CONSOLE=1 turns that off). After a request has left and the engine was told to stop, an engine that says nothing for 300 s plus 600 s is ended and the next request restarts it; every line the engine writes restarts those limits.
• The Monitor's SSD temperature line appears only on the Monitor screen's own request, not in the first minute, only for NVMe drives. After a crash or a freeze while the reader was asking a drive, or after a first pass longer than 45 s, the line stays hidden until you delete the marker file drive-temperature.probe in Strata's state folder (%LOCALAPPDATA%\Strata on Windows). Nothing else is affected.
• Pictures accept the format list above; client config writes the larger output cap; the Strix refuses an oversized chunk at the start.
• Python 3.10 installs stay on Pillow 12.3.0.

The DGX Spark

The Spark (linux-aarch64) gets the same 0.2.11 Terminal and Control, the 0.1.57 Qwen engine and the 0.1.57 DeepSeek engine, built on a Spark from the source of this release. Its feed is strata-feed-linux-aarch64.json, at sequence 121. On a Spark, the release files were run like this:

• Update from 0.2.10: a 0.2.10 setup made with the public install.sh updated the engine and Control from 0.1.56 to 0.1.57, and strata --version said 0.2.11. Rollback to 0.1.56 worked, and a second update worked too.
• A fresh 0.2.11 install: IQ3_S started in 68 s and answered 3 chats. A small red picture was answered "Red".
• Not run: the DFlash2 drafter (not downloaded for the test), speed numbers, and a DeepSeek model.

Apart from the GB10 chunk-size comparison in the table above and the FP16 weight cache parity test on sm_121, none of the engine speed work in this release was measured on the Spark.

Going back to 0.2.10

strata components rollback returns to the 0.1.56 engine; Control stays 0.1.57, so strata --version still says 0.2.11. Checked on Linux, Windows and a DGX Spark after an update from a 0.2.10 install ("Engine rolled back: 0.1.57 -> 0.1.56"); not checked on a Mac. To put an engine default back, use the off switches in "Behaviour that changed". To go back to the earlier drafting behaviour: strata launch --drafting mtp. To turn the split engine off: --split-engine off or STRATA_SPLIT_ENGINE=0. To start with a smaller context than 131,072: --max-context. For the app, install the 0.2.10 installer over it: it reads its own browser copy of your chats, which is the one 0.2.11 left untouched at the move, so chats made or changed in 0.2.11 are not in it; they stay in the chats folder of Strata's data folder.

What we ran on the release files

The release packages were installed from a signed local copy of the 0.2.11 feed (sequence 121) into empty scratch homes and run with models already on each PC. Every archive matched its size and SHA-256 in the feed. The Terminal said strata 0.2.11 (build 0.1.57).

• Linux engines with a real model: each one was started, answered 3 chats (one of them a tool call that read a file) and stopped cleanly, with no error line in the engine log.

  package	card	model	start to ready	decode in the log
  engine, Radeon RX 9070 class	Radeon AI PRO R9700	Qwen3.8 IQ3_S	53 s	about 91 to 98 tokens per second
  DeepSeek engine, Radeon RX 9070 class	Radeon AI PRO R9700	DeepSeek 2.25bpw	371 s (one-time preparation and a 165 s load)	4 to 25 tokens per second
  engine, CUDA 13	RTX PRO 5000	Qwen3.8 IQ3_S	23 s	about 152 to 163 tokens per second
  engine, Intel Arc (SYCL)	Arc A750	Qwen3.8 Q2_0	50 s	8 to 11 tokens per second (the 66 GB file streams through an 8 GB card)

• Windows Terminal: the 0.2.11 Windows Terminal in an empty scratch folder installed the Windows CUDA 13 engine from the feed in 12 s (signature and file checks, test start). It then started Gyro-S on an RTX 5070 in 204 s, including a one-time preparation and a 90 s load, answered 3 chats and stopped cleanly.

• Update from 0.2.10: on Linux the public 0.2.10 install.sh, and on Windows the public 0.2.10 Terminal, were installed into scratch homes and pointed at the 0.2.11 feed. Both accepted it with their built-in keys and updated Control and the engine from 0.1.56 to 0.1.57. strata --version then said 0.2.11, and strata components rollback went back to the 0.1.56 engine. The app's in-app update from 0.2.10 was not run.

• Desktop app: the Windows installer and the Linux AppImage carry valid update signatures (key B6B0999905521F5E) and say 0.2.11. The AppImage passed the repack check (see #4337 under "Known problems"). The installer itself was not run, because it writes the PC's own registry keys; the app tests ran on a test build of the same code (see below). The Mac app is built from the same code, signed with Developer ID and notarized; its signing run started the app and checked its signature, but did not load a model.

• Engine packages: every package's manifest says 0.1.57 with build id 975eaab2bb40 and the toolkit (for example +cuda13.0). Every package passed package_engine --verify and the library scan: each library it needs is in the package or comes from the system or the driver. On Linux every program file has RUNPATH $ORIGIN or none, and needs at most GLIBC 2.34 (2.38 for the Intel package, which is built on Ubuntu 24.04). The Qwen engine's --version prints strata 0.1.57 with no commit, as in 0.2.10; the DeepSeek engine prints build 975eaab2b. The Mac engines link only system frameworks.

Before the release files existed, the release candidates were run as follows (heads before the final one: 548fdf061 and 0fa4288d3, not the files above):

• Windows desktop app (owner PC, RTX 5070), QAGUI: a release-style build of 548fdf061 with one test-only addition (a debugging port); the installer was not run, the install layout was assembled by script. Scenarios 1 to 14 and 16 passed on the final pass, except the sidebar preview of a changed file (renderer out of memory 5 of 5, which led to the CRLF fix above). On 0fa4288d3 the changed-file preview passed, menus and Settings dropdowns at 150% and 200% passed, a hung start-up request passed, and a 10-minute smoke ran 6 tasks with 0 failed (minimum 9.25 GiB available). Context was 32K or 64K with a 7 GiB resident budget, pictures off, because the app's default left 8.3 to 8.9 GiB free on this 63 GB PC. A 2-hour soak on 0fa4288d3 at 32K ran 66 tasks (39 chats, 13 agent tool loops, 9 stop tests, 2 model reloads, 3 app restarts) with 0 failed, 0 error lines and no memory growth in any process over 720 samples (engine private bytes 24.2 to 24.8 GB, renderer at most 178 MB), at least 9.28 GiB available. On 3c4afa8d7 (the Models page fix) the Models page passed 3 of 3 rounds and a 10-minute smoke ran 6 tasks with 0 failed (at least 9.95 GiB available).
• Terminal, QATUI: l620 (RTX PRO 5000) chain of 13 scenarios on 548fdf061, a terminal walk in tmux (all screens, resize to 80x24 and 60x16), a 60-minute soak (98 cycles, 1,960 requests of which 588 were dropped on purpose, 0 HTTP errors, 0 empty answers, 0 failed launches or stops, 0 leftovers, server RSS 206 to 207 MB, engine RSS 79.6 to 80.0 GB flat); boston (2 x A6000: numbering, layer split, stop and start again, split engine); an Arc A750 box (one empty answer in 2 of 5 on the earlier head did not recur: 5 of 5 answered or hit the 400-token test cap); a Mac mini M4 (Gyro-S; bench SIGTERM and SIGINT); the owner PC (Windows Terminal, RTX 5070, Gyro-S: launch 170 s, 3 plain and 2 streamed chats, models list --served, stop twice, nothing left, lowest available RAM 9,874 MiB). On 0fa4288d3: the port text on Linux and macOS, the ? key list at 80x24 and 60x16, the Windows plan's child processes, and a Linux smoke all passed. A Strix run on an earlier head: plan, launch in 53 s, chats and stop passed; Strix was not used in the final pass.
• Engine speed work is from branch builds (see the start of this page), 0.2.11 not yet re-run on the release packages.

Known problems

• The first answer of some agent prompts depends on the chunk size. The sparse block selection inside the model's attention sits on near-ties (the gap between the lowest chosen and the highest unchosen block is under 1e-3 on 75 to 93% of queries), so any change in rounding flips which blocks are picked on 70 to 90% of queries, and a few last positions amplify it. Changing the chunk size in either direction (4096, 6144, 12288, 16384, 32768 against 8192) moves a few agent prompts by an O(1) KL; plain text barely moves (KL about 1e-5). It is not specific to 32768. On the 96-request fair set (the suite's own prompts and later-turn agent contexts, RTX PRO 5000, IQ3_S, all experts resident, floor 0): 32768 against 8192 mean KL 0.023, p90 0.029, max 1.24, top-1 94 of 96; the 8192 path with a different equally valid rounding switch gave 0.022 / 0.016 / 0.99 and 93 of 96; the decode-path read gave 0.026 / 0.028 / 0.95 and 91 of 95. Earlier agent-prompt KL figures (the route-tail skip 0.203, the K-quant kernels 0.065 and 0.052) may be inflated by this effect and were not re-measured.
• The 32768 chunk on Windows was not exercised above 8K. On the RTX 5070 (12 GB) the engine's chunk was 7,936 whatever the ceiling (RAM guard and fit scan), so no chunk above 8K ran on Windows. A memory check of a 17,000-token prompt at a chunk above 16384 rows ended with 0 errors but only a partial prompt read (the job hit its time limit); it was not repeated.
• DFlash2, several requests, 64 GB PC, large context: on the Windows app with --max-context 65536 --draft dflash2 --resident-budget-gib 7 --conversation-cache-mib 768 --spec 6 --batch 4, four requests at once took the PC from 25,074 MB to 7,416 MB available; the engine's private bytes were 28.2 GB and everything else on the PC stayed constant, so we think it is the engine's request-time growth, which the app's "keep 8 GiB free" (decided at load) does not cover. At 32K the same run stayed at 10.5 GiB and answered all four. Agent turns at 64K with a 7 GiB resident budget took the same PC under 8 GiB available 4 times (7,955 to 8,159 MiB available, engine private 23.6 to 24.3 GB). The test's own guard ended the engine each time; the engine was not the one to crash. Not fixed in this release.
• One first chat request after 20 minutes idle took 440 s (the engine used 5.3 to 7.3 cores at 15 to 20 tokens per second with an 11.8% expert-cache hit; normal is 32 to 57%). The idle was not the cause: 20 minutes idle gave 28 s on a repeat, and the first request after a load takes 82 s against 26 s later because of the prompt-prefix cache. Not reproduced; cause not found.
• #5153: when the engine runs without the MTP drafter (including DFlash2-only runs), saving or restoring a conversation snapshot can fail with "conversation snapshot: invalid K/V extent"; the next request reads its prompt again. Cause found by reading (the save and restore handlers pass the MTP state unconditionally); the fix is in the engine and is not in this release. #3288 / #3036 (snapshot copies on a Windows gfx1201 card at 262144 context) were also left for the engine.
• #4337: the AppImage's bundled ripgrep (rg) can crash with SIGSEGV. The likely cause is linuxdeploy rewriting a static-PIE's dynamic section; we showed it on a synthetic stand-in, not on the real rg. The repack script now checks static PIEs and smoke-runs rg. On the release AppImage the check found no damaged static PIE, and the bundled rg (ripgrep 15.0.0) ran and found its test match. A crash on a real PC was never reproduced, so this stays listed until a report confirms it.
• Engine-side reports (device faults, wrong output, stalls, memory admission) were triaged on paper only this round (for example #5103, #5147 / #5149 (a hang with --pipeline-windows 2 and the drafter on the first card), #5104 (workaround: --set STRATA_PREFILL_LAYER_MAJOR=0), #5021). None is fixed here. #4451's real cause, if it is a wrong slot number in the engine, is also still open.
• Strix Halo: UD-Q4_K_XL can stop on the first request after a start (7 of 30 starts on 0.1.55; UD-IQ4_XS ran 99 starts without it). With a 64 GB graphics split Windows reports 63.6 GiB of RAM, so setup keeps --expert-cache auto (66.86 GiB, larger than the split), on which prompts were 11 to 13% slower than with a 46 GiB cache; the setup warning does not say that. A cache budget of 11000 or less does not start and ends with the engine's own "prefill: copy stream" message. UD-Q4_K_XL greedy text varies from run to run (code_py 4 to 5 different outputs in 16 runs on both 0.2.10 and 0.2.11; first-token logits are bit-stable).
• Apps: the Harness process exits with code 1 at every quit (the last line of the desktop log; harmless). The first "Prepare and load" of your own model folder says "Nothing is copied or downloaded" while it downloaded a 40 MB llama.cpp source and copied the picture file and the DFlash2 pack. "Open" on a file card starts the system's default program for the file (VS Code on one PC); "Open in sidebar" is under the chevron. If a draft-layer download fails and a DFlash2 download follows, the dialog does not list the second download.
• Terminal: --set draft-conf=off with DFlash2 is replaced by the automatic value (0.35) with no notice; --gpu 1 on a one-card computer is accepted and the plan shows card 0 as "GPU 1 (--gpu 0)"; on the Advanced screen long Default and Tuned values run together; a stopped server leaves one stale procs\<pid>.json until the next start.
• Carried from 0.2.10, not re-measured in this release: DeepSeek answers can differ between starts at temperature 0 (one or two experts per card sit differently from start to start, and the expert cache moves experts between CPU and GPU); a DeepSeek tool call can come out broken when most of the model streams from the SSD (1 of 5 runs at 13% of the default set in memory, temperature 0.6); the DeepSeek drafter is fetched even with --dspark off; the Mac Terminal archive and DeepSeek folder are signed and notarized but carry no stapled ticket; on Intel Arc A750 11 test programs that need 64-bit floats abort and the engine does not repeat its own answers exactly; on Windows with an AMD card the DeepSeek package is built for the Ryzen AI Max (gfx1151) only; the all-cards split engine does not support logprobs or logit_bias (a clear error names --split-engine off). None of these was checked again in this release.

What we did not test, and what we built but did not run on a matching card

• A real WKWebView and WebKitGTK (IME order, emoji crash and fix, the macOS renderer hook); a real Mac for #4973; the real AppImage ripgrep; the NSIS installer of the app in QA.
• The Linux app (AppImage) and the Windows or Mac app with the all-cards split engine on a two-card PC; the new split default for the app was tested with a fake Control and plan-only runs.
• Two and three R9700 cards with the split; DFlash2 on the split through the launcher or the app; DFlash2 on the split in sampled mode through the 61-task suite; three small NVIDIA cards (unit tests only); 2 x 5 GB and 2 x 3.5 GB (the fewer-cards step fired, the single card then stopped at 128K).
• The K-quant kernels and the W16 cache on Windows; the W16 cache on Pascal and sm_89; the 61-task suite for the W16 cache and the RTX PRO 6000 chunk ceiling.
• DeepSeek: no DeepSeek engine source changed in this release, but every DeepSeek package is rebuilt against the changed prefill library. The Linux RX 9070 DeepSeek package ran on an R9700 (DeepSeek 2.25bpw, 3 chats, a clean stop); the DeepSeek CUDA packages were not run with a model.
• Built and checked as packages but not run through a model on a matching card:
  • Windows: CUDA 12, RX 9070, RDNA3 and RDNA2, and both Windows DeepSeek packages.
  • Linux: CUDA 12, RX 7900, Strix Halo and RX 6000, and DeepSeek CUDA 13.
  • The Mac Qwen and DeepSeek engines (only --version was run).
  • The all-cards split engines inside the Linux CUDA 13, RX 9070, RX 7900 and Strix Halo packages (never started from the packages).
    The Spark's DeepSeek engine was not run with a model.

Updating

• App: the in-app update offers 0.2.11, or download the installer below.
• Terminal: run strata update. It fetches Control 0.1.57 and the 0.1.57 engine in the same run and keeps the old engine for strata components rollback. If your Terminal is older than 0.2.0 (for example 0.1.45.x), run the install line again. The update from a 0.2.10 install was run on Linux and Windows: it accepted the new feed with its built-in keys, updated Control and the engine to 0.1.57, and strata --version then said 0.2.11.
• DeepSeek engine: from 0.2.10 one update brings it with the Qwen engine. From 0.2.9 or older run strata update a second time; the 0.2.9 updater has no step for the DeepSeek engine (as in 0.2.10; not run again from 0.2.9 for this release).
• DGX Spark: strata update, the same as on other Linux PCs (see "The DGX Spark").
• Mac: the app, the Terminal, the DeepSeek engine and the Mac Control are signed with Developer ID and notarized.

Downloads

40 files, 9.5 GB in all:

• App installers: Strata-0.2.11-windows-x64-setup.exe, Strata-0.2.11-linux-x86_64.AppImage and Strata-0.2.11-macos-arm64.dmg, plus Strata.app.tar.gz for the Mac's in-app update. Each update file comes with its .sig.
• Control, 0.1.57: Linux x86_64, Windows, Mac and the DGX Spark (linux-aarch64).
• Qwen engines, 0.1.57:
  • Linux x86_64: CUDA 13, CUDA 12, RX 9070, RX 7900, Strix Halo, RX 6000 and Intel Arc;
  • Windows: CUDA 13, CUDA 12, RX 9070, RDNA3 and RDNA2;
  • Mac (Metal).
  • DGX Spark: CUDA 13.
• DeepSeek engines, 0.1.57: Linux CUDA 13 and RX 9070, Windows CUDA 13 and RDNA3, Mac, and the DGX Spark.
• The rest: the two feeds (strata-feed.json and strata-feed-linux-aarch64.json, each with its .sig), latest.json, install-manifest.txt, install.sh, install.ps1 and SHA256SUMS.txt.

Thanks and credits

• John Fink: sFNX (MIT), the all-cards split engine Strata's is built from; this release adds to it.
• rriggs: the analysis and patch idea on #2518 (a branching follow-up in the wrong slot).
• Pull requests whose approach we used and wrote again in our own code:
  • dynaxbill: #2886, the replica hand-over (#2892).
  • schmittcn: #4204, #4220, #4221 and #4535.
  • JasperGuWP: #4293.
  • coryjett: #4500.
  • ctr-137: #4599.
  • Tsury: #5040 and #5075.
  • NektoDron: #4738.
  • rinesh: #4878.
  • miketgv: #4485 (the idea).
  • XiaoBinGan: #4318 and #5184.
  • Nyarlathoteppppp: #4562, #4563, #4568 and #4570.
  • erikash: #5028.
  • qwertie: #4230.
  • bahooo22: #5044.
  • sdroege: #4792.
• ISTA-DASLab, antirez/ds4, keinebenutzer, nazeshinjite, xrip, hanchengme, Tycho Rasch, asf0: as in 0.2.10; their work is still in this release.

Strata is free and open source. If it runs well on your PC, a coffee keeps the work on it going: