GitHub published on October 21 how it plans to move the last of its Git repositories onto Azure. Over the past year, 99.99999% of the Git repositories on GitHub started living in two places at once. One copy sits in GitHub's own data centers and one sits in Azure. The first copy landed in Azure's Central US region in August 2025. Most repositories now keep two of their five replicas in Azure, and Azure serves about half of Git traffic. The remaining 0.00001% are among the busiest on the platform. An Azure replica is about 1,000 miles from GitHub's data centers. Each network round trip runs around 25ms, and a write needs several of them. The old quorum made that hurt. It held a repository-wide lock and waited on every healthy replica. The slowest replica then set the latency and the throughput ceiling for every write. So GitHub is narrowing the quorum from the whole repository down to each individual reference. Agents and developers pushing to their own branches stop queueing behind each other. In internal testing with realistic traffic, writes to different references consistently saw 3 to 4 times higher throughput at lower latency. The next step makes object storage a member of the quorum. GitHub calls that a virtual replica, and a write is acknowledged only once it is durable in object storage. From there GitHub can add virtual read replicas that hold no persistent state and warm their cache from object storage. Repositories run somewhere between 100 and 1,000 reads for every write, so reads are the half worth scaling on their own. GitHub puts its own scale at a billion repositories. Take 0.00001 percent of a billion and you get 100. So the holdout at the end of this migration is on the order of a hundred repositories, out of a billion. Those are among the busiest ones GitHub runs. A 25ms hop is the whole thing standing in their way. github.blog/engineering/arch…

Meta published on October 19 how it made its data pipeline agents more reliable. It gave the agent in charge less to do. The first build was one agent that held everything. It carried the configuration schemas, the code generation rules, the pipeline routing logic and the population patterns for 10+ data sources. Meta says it worked in demos and started hallucinating in production. The replacement is a 1,300-line orchestrator that routes 20+ workflows to 14 specialized AI agents. The orchestrator performs zero domain work. It runs a fixed 7-step protocol on every request. Steps 1 to 5 and step 7 are deterministic. Only step 6 calls a model, and that happens inside a subagent loaded with just its own domain knowledge. The knowledge sits in 25+ files that load at run time. The job here is onboarding a data column across three code repositories, three programming languages and up to six pipeline stages. By hand that took three to four days. An earlier config-driven system brought it to about a day. The thin orchestrator does it in under an hour. About two-thirds of its changes land without significant human edits. Meta also measured the alternative it rejected. A single agent reached 70 to 80 percent success when an engineer wrote a custom system prompt for each specific job. Without that handholding, success dropped to 10 to 20 percent. Line those two ranges up and you can see what that engineer's prompt was worth. Take the kindest pairing for the unaided agent, 70 against 20, and it is still 3.5 times. The harshest is 80 against 10, which is eight. Somewhere in there sits the cost of a person sitting down to write a prompt for every job. Meta's answer was to stop asking for that prompt and hand the routing to plain code. engineering.fb.com/2026/10/1…

Shopify published on October 21 how it moves work off a frontier model and onto open models it trains itself. Sidekick is Shopify's AI commerce assistant. The frontier model keeps the merchant conversation and decides which tools to call. Focused jobs go to subagents, and several of those run open models Shopify post-trains for one task each. The example in the post is the GraphQL subagent. It reads about 40 tokens for every one it writes, and the frontier model's API charges for all of them. For that job Shopify post-trained NVIDIA Nemotron 3.5 Lightning. It is a mixture of experts with three billion of its 30 billion parameters active per token. Out of the box it scored 37.7 on Shopify's GraphQL judge, and the frontier model scored 73. The first loop took it to 61.5. After six loops and 61,000 healed examples the post-trained model scored 74.5. The training data comes from the system's own failures. Over 86 nightly runs, self-healing repaired 59,535 GraphQL conversations, which is 69% of the failures it tried. Speed and cost moved too. Replaying production GraphQL traffic, the post-trained model returned a full response in 0.87 seconds at the median. The frontier model's API took 6.50 seconds. The slowest 1% of requests finished 8 times sooner, and serving cost on that traffic is about 90% lower. Across Shopify's post-trained models, self-hosting cuts serving cost by 90% to 98%. Shopify put a hardware number in as well. It ran the same FP8 post-training job for its Analytics model on eight GPUs. Eight B300s trained 1.86 times faster than eight H200s, and used 46% fewer GPU-hours. My read: the first pass did most of the climbing. 37.7 to 61.5 is 23.8 points in one loop. The five loops after it added 13 points between them. That is about two thirds of the total gain in the first round. The last stretch to 74.5 took five times as many rounds. shopify.engineering/open-mod…

Liquid AI announced RIPL on October 22, an inference engine for requests that cannot wait. RIPL serves Liquid's own LFM models. The claim is a complete generated response, end to end, in under 50 ms. Liquid says it holds that while traffic keeps arriving at peak load. The engine is for enterprise deployments on NVIDIA GPUs, and the post lists H100, H200, B200 and RTX PRO 6000. The target work is search ranking, fraud decisions and payment authorization. Teams normally reach for gradient-boosted trees or small embedding models there. The headline comparison is against Qwen3.5 on vLLM. Liquid says LFM2.5-1.2B on RIPL has 14.4 to 28.4 times lower p95 latency than Qwen3.5-0.8B. It says LFM2.5-2.6B has 5.6 to 7.7 times lower latency than Qwen3.5-2B. Liquid also ships the table behind Figure 2. The setting is p95 end-to-end latency under open loop Poisson arrivals on one B200. Liquid's models run on RIPL and the others run on vLLM. On the workload labelled 32 to 32, at 1000 requests a second, LFM2.5-1.2B records 34.56 ms. LFM2.5-2.6B records 76.44 ms there. On the 256 to 128 workload, LFM2.5-1.2B records 155.76 ms at 400 requests a second. LFM2.5-2.6B records 449.12 ms at 300 a second. One of the fourteen rows in that table sits under 50 ms. My read: the 28.4 figure is largely a statement about Qwen3.5. The same table lists MiniCPM5-1B at 599.82 ms on the 256 to 128 workload. Liquid's 1.2B model records 155.76 ms in that same row block, at the same 400 requests a second. Divide those and you get 3.8 times. MiniCPM runs on vLLM too, so the engine is still doing real work. The win is there. Its size just depends on which row you line it up against. liquid.ai/blog/low-latency

Cohere released Rerank 5 on October 21, a new pair of retrieval models for enterprise search. There are two tiers. Pro is the quality tier and Fast is the cheap one. Pro costs $0.05 per million tokens and Fast costs $0.02. Both are live on Cohere's own API, on Microsoft Foundry and on Amazon SageMaker. The new feature is called Context Focus. A single call now returns the best passages inside each document, instead of one score for the whole document. On public benchmarks, Cohere evaluated 46 composite datasets. Rerank 5 Pro ranked first on 39 of them and at least second on 43. On BRIGHT, a benchmark built around reasoning-heavy retrieval, Pro scores 82.2. That is 5.8 points above Voyage AI Rerank 3 and 12.4 above Cohere's own Rerank 4 Pro. The scoring method, RCP-nDCG@10, is Cohere's own, so read those margins as the vendor's measurement. The more interesting test is the search agent. Cohere gave an agent keyword search on its own, then added pieces one at a time. Across 17 datasets with 50 questions each, plain BM25 answered 46 percent correctly. Adding Rerank 5 Pro to reorder the top 100 raised that to 49 percent. Context Focus at its default threshold of 0.1 cut tokens per task by 19 percent and lifted accuracy to 57 percent. At 0.4 it cut 34 percent of tokens and reached 58 percent. The full stack used 35 percent fewer tokens than keyword search alone. Scores are calibrated now too. Cohere says a score of 0.7 means a 70 percent chance the document is useful. Teams can pick one cutoff and keep it when they change models. On throughput, Rerank 5 Fast handles about 187 documents of 1,000 tokens per second on one NVIDIA A100. That is 2.9 times what Pro manages. My read: the ladder splits the product in two and the halves are not equal. Reordering the top 100 documents bought 3 points, from 46 to 49. Switching on the text trimming bought 9 more, from 49 to 58. That is three times the gain, and most of it lands at the default setting. Picking better documents helped. Cutting the ones you picked down to the useful part helped three times as much. cohere.com/blog/rerank-5

Gradium open-sourced Phonon on October 20, a set of small text to speech models that run on the device. Two sizes ship. The English one is Phonon 31m, 64 MB in q8, under Apache 2.0. The 40m models cover English, French, German, Spanish and Portuguese under a CC BY-NC licence. One of those holds all five languages in a single set of weights, with 102 built-in voices. The 31m ships with 37. You can also load a cloned or designed voice as a file and run it locally. Accuracy is the part worth reading. Gradium built a test set of 500 sentences per language from cases developers said their current models get wrong. Think phone numbers, email addresses and postal codes. Word error rate came out at 1.70 percent for Phonon 31m and 2.22 percent for Phonon 40m. Kokoro scored 3.50 percent, Kitten TTS 7.40 percent and NeuTTS Nano 8.71 percent. Transcripts came from qwen3.8-omni-flash and the error rate was graded by gemma-4-31b-it, so the judge here is a model. Speed is measured on a MacBook Air M5 running macOS 26.7.1. On one CPU core, Phonon 31m runs 11.6 times faster than real time and starts speaking after 13.6 ms. Kokoro on that same row runs 7.28 times real time and needs 776 ms to first audio. Gradium notes Kokoro does not stream, so its first audio is the whole sentence. On a Raspberry Pi 5, Phonon 31m starts in 38 ms and runs 3.7 times real time, where Gradium says Kokoro needs 7 seconds to start. Gradium then ran the same model three ways on the same laptop. Plain, it is 11.6 times real time on one core. With Arm's KleidiAI library it is 20.5 times. With Apple Accelerate on top of KleidiAI it is 26.0 times. Time to first audio goes 13.6 ms, then 5.8 ms, then 5 ms. My read: the weights never changed across those three rows. Same model, same laptop, same single core. Swapping the math library underneath took Phonon 31m from 11.6 times real time to 26.0, a shade over double. So a good share of what looks like a small model being fast is the kernel library doing the work. gradium.ai/blog/release-phon…

Micron is skipping a whole generation of its flash memory. The company is currently shipping G9, its ninth generation, with 276 layers. The next step was meant to be G10, at 300 or more layers. Blocks and Files reports that G10 was abandoned this month. Micron will jump straight to G11, at more than 400 layers, built with wafer on wafer bonding. Technology and products chief Scott DeBoer set this out in a webinar on the company's investor relations site on October 21. The figures DeBoer gave compare G11 with G9. Twice the bit density. An increase in I/O speed of up to 1.5x. And 25 percent less energy to transfer a bit. He called it the world's most advanced NAND and said it will ramp in the second half of next year. He said the layer count gets more detail next year, closer to launch. DeBoer also sketched two flash lines aimed at AI machines. One is a high IOPS design using SLC cells in small blocks. The other stacks flash dies on a base die, linked by through silicon vias like HBM, sitting next to the accelerator. Blocks and Files puts the high IOPS drive in the 25 to 100 million IOPS area. It says next generation SSDs could hold up to 512 TB. Skipping is becoming a habit here. Internal Gen 6 had 232 layers and sold as G8. Gen 7 had 276 layers and sold as G9. Blocks and Files thinks the external numbering is marketing, matching Samsung's V9 to V11, SK hynix doing the same, and Sandisk and Kioxia's BiCS 9 to 11. My read: the two I/O numbers pull against each other. Each bit costs 25 percent less energy, so 0.75 of what a G9 bit cost. But at the full 1.5x speed you move those bits half again as often. 1.5 times 0.75 is 1.125. So a G11 link running flat out draws about an eighth more power than a G9 link did. The saving per bit only shows up if you leave some of the extra speed unused. In a GPU box that keeps the drive busy, plan for more power per drive. blocksandfiles.com/flash/202…

Letta has released FrontierMemory 1.0, a benchmark that tests whether an agent gets better by learning from its own past work. Older memory tests such as LoCoMo and LongMemEval quiz agents on personal facts like birthdays or hobbies. Letta says those are largely saturated. FrontierMemory instead gives agents transcripts of earlier runs and lets them write their own memory. It then scores them on new tasks that need that memory. The set is small. It has 15 tasks, adapted from public benchmarks such as DeepSWE and SkillsBench. Letta says 53% of the original sourced tasks it kept had broken verifiers, so it repaired them. Of 665 collected trajectories, only 219 are relevant to the tasks. Seven models wrote memory through Letta's Dream harness, with an agent on Letta Code doing the tasks. Opus 5.5 and GLM-5.3 tie at 73.3%. Kimi K3 gets 66.7%. GPT-6.1 Sol and Gemini 4 Argon get 60.0%. Muse Wonder gets 46.7% and Grok 4.7 gets 33.3%. Letta also ran five harnesses in two panels. With Opus 5.5 writing memory and doing tasks, Letta Dream scored 73.3%, Prime Agent 60.0%, Claude Managed Agents 33.3% and Hermes Agent 26.7%. With GPT-6.1 Sol on memory and GPT-6 Sol on tasks, Letta Dream scored 60.0%, OpenAI Agents SDK 40.0%, Hermes Agent 20.0% and Prime Agent 13.3%. My read: watch Prime Agent across those two panels. It is second on the Opus pair at 60.0% and last on the Sol pair at 13.3%. That is 9 tasks out of 15 down to 2. The other two harnesses in both panels barely move. Letta Dream drops 2 tasks and Hermes Agent drops 1. The panels swap the memory model and the task model together, so this is not one clean change. Even so, a harness losing 7 tasks on the same 15 while its neighbours lose 1 and 2 is what I would want explained. Letta built both the benchmark and the harness that wins it. frontiermemory.com/blog/v1/

NVIDIA expanded its Cosmos platform at GTC Berlin on October 22, with new tools for building world models. World models are the part of a robot or a car stack that predicts what happens next. NVIDIA added Cosmos Data Factory, which ships five cloud blueprints for making training data. They cover driving data, image variation, rare event video, defect images for inspection, and weather and lighting changes in existing footage. The blueprints run through GitHub, Microsoft Azure, Nebius and CoreWeave. The training side got Cosmos Framework. Developers can adapt open models such as GR00T, Alpamayo, Qwen and Pi0.5, then shrink them with distillation and quantization. The robotics lab MicroAGI post-trained Cosmos 3 on video of people handling objects. It then distilled a 32 billion parameter reasoner down to an 8 billion parameter Nano model, which NVIDIA says lost no accuracy. Deployment numbers came with it. NVIDIA says the updated Cosmos 3 NIM microservices run inference up to 2x faster with no quality loss in validated setups. The Metropolis video search blueprint, built on those same microservices, lets teams watch 40 percent more video streams on the same GPU. ADNOC runs a hazard detection system on that stack across 65 sites. My read: those two speed claims sit on the same stack and do not match. The microservices are called up to 2x faster. The blueprint built on them reports 40 percent more streams per GPU. Doubling inference speed and getting 40 percent more work are different things. The rest of the video pipeline is where that gap goes. That is the number I would ask about first. blogs.nvidia.com/blog/cosmos…

Tenstorrent is now serving MiniMax M3.1 Flash on its cloud, with prefill and decode both running on Blackhole Galaxy systems. Tenstorrent says MiniMax released the open weights for M3.1 Flash on October 22. The price is $0.15 per 1M input tokens, $0.60 per 1M output tokens, and $0.015 per 1M cached input tokens. Tenstorrent puts that at 50% of M3's price for input and output, and 25% for cached input. It also says the model runs agent tasks at 70% lower cost than M3. The speed comes from the design. MiniMax replaced global grouped-query attention with sparse attention and kept dense MLPs only in the first three layers. Each token reads only part of the context. Most weights were quantized to MXFP8, and the routed expert weights to NVFP4. Prefill and decode run on separate Galaxy systems, so a long prompt does not stall a user mid-response. Each Blackhole Galaxy has 1 TB of DRAM and several terabytes of SSD to keep reused context close. My read: the price list tells you what this is built for. Output runs $0.60 per million tokens and fresh input runs $0.15, so output is four times input. Cached input runs $0.015, which is a tenth of fresh input. The cache gap is the bigger of the two, and agents that keep returning to the same context are the workload that collects it. tenstorrent.com/newsroom/min…

Dell announced new AI servers on October 21 at NVIDIA's Berlin event. One of them is a single rack with 256 CPUs. The PowerEdge M9882 packs 256 NVIDIA Vera CPUs into one 48U rack. Dell built it for the work around agents, such as orchestration, tool use, code execution and evaluation. It is due in the first quarter of 2027. The PowerEdge R8822 is the smaller version. It is an air-cooled, two-socket Vera server for standard 19-inch racks, and it supports up to four double-wide GPUs. Dell says it will be available this month. The third system is the PowerEdge XE9810. Dell says it will be the first to offer rack-scale inference with 16 direct-liquid-cooled compute trays powered by Groq 3 LPUs. It is also due in the first quarter of 2027. At the desk, Dell Pro Precision with GB10 gets a 64GB unified memory version on October 23. It can be linked in two- or four-system clusters. A Windows version of the GB300 offers up to 748GB of coherent memory and 20 petaflops of FP4 compute. Dell says it is coming soon. My read: the two desk machines sit a long way apart. The GB10 box ships on October 23 with 64GB. The GB300 box offers up to 748GB, which is almost 12 times as much (748 divided by 64). So the one you can buy this week is the small one, and the big one is still coming soon. investors.delltechnologies.c…

Google Cloud announced Agent Compute Engine on October 22, a service that gives every AI agent its own small virtual machine. Google says the service already powers Gemini as an agent for work tasks. Each agent runs in a hardware-isolated microVM with its own guest kernel and root access. Outside developers get a preview in the coming months. The main trick is pausing agents that are idle. When an agent finishes a tool call and starts thinking, the microVM tells the host it is idle. The host pauses it with a fast checkpoint and restores it later. Copy-on-write memory sharing lets many agents run on one operating system template. Google also offers Agent Substrate, an open-source runtime for Kubernetes built on the same idea. Google says it gives as much as 10x higher compute density than traditional compute, with full kernel isolation. In a benchmark with 200,000 agents, it sustained 500 activations per second at less than 500 ms suspend and resume latency. Security gets a simple rule. Each microVM gets its own cryptographically verified ID. Service credentials are injected on the way out, outside the microVM. My read: Those benchmark numbers hide a useful ratio. Take 500 activations a second and multiply by the 0.5 s ceiling. That is at most 250 agents waking at any moment. Divide 250 by 200,000 and you get 0.125 percent of the fleet. So the test is mostly a huge fleet that sits asleep. cloud.google.com/blog/topics…

A new paper asks a plain question about speeding up an LLM on an NVIDIA GPU. From where you are now, should you add 2:4 sparsity or drop to the next lower number format? The 2:4 pattern keeps at most two values in every group of four. NVIDIA tensor cores have supported it since Ampere. Xiuyi Qin compares it against one more step of quantization at equal bits, counting the index data that 2:4 needs. The test covers every layer of two 8B models, timed on Ada, Hopper and Blackwell. Above the lowest format a GPU offers, 2:4 loses. The paper says adding it is "both less accurate and slower" than dropping one precision step. The reason is that 2:4 discards half the values whatever the bit width, while quantization error keeps shrinking as you add bits. On Gaussian data, 2:4 with FP16 values carries 36.4% error, and plain INT8 at the same bit cost carries 0.6%. At the floor, where no lower step remains, 2:4 does pay. A retrained 2:4 model served in FP8 by vLLM gets 27% higher prefill throughput than the dense FP8 model, with no significant GSM8K difference. The catch is retraining. The author's own runs recovered perplexity within a quarter billion tokens. GSM8K stalled well below Sparse-Llama, a model retrained thirteen times longer on different data. On Blackwell, whose sparse FP4 uses a pairwise 4:8 pattern, the retraining budget did not recover the loss at all. Worth noting alongside this: the paper says vLLM and LLM Compressor removed their 2:4 support in 2026, because few users relied on it. My read: the H100 serving table splits the win cleanly. Dense BF16 does 41.4k prefill tokens a second, dense FP8 does 58.9k, and 2:4 FP8 does 74.6k. Divide 58.9 by 41.4 and quantization alone buys 1.42x. Divide 74.6 by 41.4 and the pair together buys 1.80x. So most of the speedup is the cheap half, and the last stretch is the one that costs you a retraining run. arxiv.org/abs/2610.28947

PyTorch can now reach hand-tuned AMD kernels through its normal operator calls, with no change to application code. The PyTorch blog describes FlyDSL as an optional backend for AMD MI350-series GPUs. It covers dense and grouped GEMM, MXFP8 and MXFP4 scaled GEMM, RMSNorm and TopK. Inputs it cannot handle fall back to the existing PyTorch kernels. Attention reaches FlyDSL through AOTriton, starting with the 0.14b series. On an MI355X the post reports kernel speedups from its own suites. Across 15 BF16 dense GEMM shapes the geometric mean is 1.10x over the faster of ATen and Triton at each shape. MXFP8 and MXFP4 reach 1.58x and 1.68x over ATen across 17 shapes each. In that dense suite the two largest square-output problems slightly favour ATen, so PyTorch keeps both backends and picks per workload. The end-to-end test ran vLLM on one MI355X with Llama-3.1-8B, Qwen3-32B and Llama-3.3-70B. Each request had a 256-token input and a fixed 512-token output. BF16 gains peak at 1.13x, and the 70B model mostly stays inside a 1.79% noise floor. MXFP8 improves all 18 model and concurrency combinations, up to 2.04x, and MXFP4 improves all 18 as well, up to 3.01x. The post says those two formats have one measured run per cell, so small differences should not be read as settled. The attention numbers need care. The post compares AOTriton 0.14.2b against 0.13b and gets 0.92x to 2.34x on the forward pass and 0.93x to 2.47x on the backward. It says that comparison also folds in updated Triton, AITER and tuning databases, so it does not isolate FlyDSL. My read: the TopK line is the one to keep. For small K, FlyDSL gets 4.82x over ATen with deterministic algorithms off and 4.02x with them on. Divide 4.02 by 4.82 and determinism costs about a sixth of the gain. Anyone who needs runs they can reproduce should budget for the 4.02x and not the headline. pytorch.org/blog/acceleratin…

Anthropic says Claude has written machine-checked proofs that 239 test entry points in 123 open-source libraries cannot crash on any input up to 64 MB. The proofs run on compiled RISC-V machine code. A proof checker called Rocq verifies every one. Anthropic did the work with a company called Theorem, which supplied the RISC-V and Linux models the proofs rest on. A subset of the proofs is being published. The result only holds under stated assumptions. The program has to be a single-threaded static binary with a fixed memory budget, on a RISC-V CPU running Linux, linked against musl libc. Anthropic says most people run these libraries on x86 or ARM and link against glibc instead. It also says "formally verified" does not mean "bug-free", because a checker cannot tell you whether the spec matches reality. Claude found bugs while trying to prove things, and Anthropic says the attempt turned up hundreds. Claude patched them, then proved the patched code. One was a counter underflow in a decompressor that only fired on inputs of about 20 MB with one rare layout. Fuzzers usually cap their inputs at 1 MB, so that one was close to unreachable by the normal method. Cost is the open problem. Anthropic says a proof can take hundreds of millions of tokens. On 36 small tasks, Opus 5.5 proved half of them with about 40% fewer tokens than Opus 5. Letting agents copy each other's finished proofs cut tokens by another 17%. My read: the proof pile is lopsided. All 239 proofs together come to about 180 million lines of Rocq, and 180,000,000 divided by 239 is roughly 753,000 lines each. Anthropic calls 600,000 lines typical. The average sits about a quarter above the typical case, so a handful of these proofs must be enormous. That matters for cost, because token spend tracks the hard tail and not the middle. anthropic.com/research/forma…

AMD posted a long write-up on October 21 about speeding up mixture-of-experts training on its MI355X GPUs. The main piece is MegaMoE. A normal MoE layer runs each step as its own kernel. AMD puts each all-to-all transfer inside the matrix multiply that makes or uses its data, so communication hides behind compute. AMD says profiling shows the forward pass split roughly evenly between the two. On DeepSeek-V3 expert shapes on one 8-GPU node, the layer time falls from 28.62 ms to 20.46 ms in BF16. In MXFP8 it falls from 24.90 ms to 13.74 ms. AMD calls that 1.40x and 1.81x. A full training step shows less. On a cut-down DeepSeek-V3 with 4 layers plus MTP, MegaMoE speeds the step by 1.081x in BF16 and 1.138x in MXFP8. AMD says the non-MoE work dilutes the gain, and it labels the model a reduced-depth proxy. AMD also ran the real 61-layer model on 256 to 1024 GPUs in FP8. A tuned pipeline layout and a per-scale list of recomputed layers gave 1.095x the baseline throughput at 128 nodes. A 1700-step run on 1024 GPUs went 10 hours and 37 minutes with no restart and no failed rank. All of these are AMD's own measurements. My read: the cheaper precision is the hungrier one. In the step-level runs both BF16 configurations peak at 135.5 GiB, while the fused MXFP8 one peaks at 195.2 GiB. Divide 195.2 by 135.5 and MXFP8 holds about 1.44 times the memory, for a step that AMD clocks 1.17x faster. On a box that is already tight, that trade is the part to price first. rocm.blogs.amd.com/software-…

Kyutai has released CADRE, a family of open video autoencoders built for world models you can steer live. A video world model predicts the next frames from past frames and an agent's actions. Most borrow their autoencoder from text-to-video generators. Those pack several frames into one latent frame, and every packed frame adds lag. Kyutai says a typical 8 times temporal packing delays each action by at least 400 ms at 20 frames per second. They cite work finding people notice their own movement is late beyond about 230 ms. Kyutai trained seven CADRE autoencoders that differ only in how much they compress. It then trained the same world model on each one. The tests cover robot and human hand manipulation, plus driving and indoor navigation. The autoencoders learned from 23 public video datasets, about 76,000 hours. Each world model sees 2 seconds of real video, then generates 4.8 seconds from the recorded actions alone. World models on CADRE react in under 230 ms at 20 frames per second on one H100. Kyutai's earlier MIRA is the only other one that does, with worse image and motion quality. They say CADRE forms most of the latency and quality frontier, which leaves room for baselines that still win a single measure. The weights, the code and a live demo are public. The study also tests how much to shrink each frame. Going from 16 times to 32 times spatial compression leaves four times fewer tokens. In robot manipulation at 2 frames per latent frame, image quality barely moved: FID went from 8.53 to 8.92. Motion took the hit, with FVD rising from 39.4 to 95.2, which Kyutai marks as 2.4 times worse. My read: the lag is mostly queueing. Kyutai walks through one action at 16 times spatial compression on an H100 at 20 frames per second. Waiting for the latent frame takes 200 ms. Generating and decoding it takes 121 ms. Divide 200 by 121 and the wait is about 1.7 times the compute, so a faster chip is not what shortens it. kyutai.org/blog/2026-10-22-c…

Browser Use has released rl-env-use. It is an open source tool that builds AI training tests from real web cases. You describe a skill in one line. Browser Use agents then find real cases, like a trial protocol and the result posted later. The tool writes tasks, computes the answers in code, and drops tasks with leaked or memorized answers. It is MIT licensed and builds on Anthropic's eval design workflow. The shipped example asks a model to forecast clinical trial results from the registered protocol. It uses 29 ClinicalTrials.gov trials whose results were posted since July 2026. Each answer is a yes or no probability, scored as 1 minus the Brier score. The tool drafted 355 tasks and kept 35. The tool then tuned the system prompt of a Qwen 3.6 35B-A3B model. On held-out tasks it went from 0.53 to 0.78. That puts it level with Opus 5.5 on this test. The tuning kept 1 of 12 proposed edits, which added base-rate priors for each question type. The README is plain about the catch. Always answering 50% scores 0.75 on this metric. So most of the gain came from the model no longer answering 0 or 1. Gemini 3.1 Pro scored 0.599 here, below that constant guess. The repo also calls these small samples, to be read as demos. My read: building the test cost far more than tuning on it. The trial test cost about 72 dollars to build. The prompt climb on it cost about 8 dollars. Divide 72 by 8 and the test cost roughly nine times the tuning run. github.com/browser-use/rl-en…