A new benchmark asks if AI agents can improve on the code behind real research papers. FrontierCS 2 comes from a team mostly based at UC Berkeley. They took 48 papers and the code each paper's authors released. Then they deleted the part of the code that carried the paper's main idea. The agent has to write it back and beat the original. The bar is strict. A run passes only if it beats the authors' code on every metric and every hidden workload. Each agent gets one run per task, with five hours on the clock. Twelve agents were tested, each one a model paired with one coding harness. Claude Opus 5.5 in Claude Code passed 58% of its runs. Every other agent passed fewer than half. Sixteen tasks went unsolved by every agent. The authors also warn that score and pass can split. Most runs that beat the reference on the overall score still missed on some metric or workload. The pass test has blind spots too. On a packet scheduler circuit, Opus 5.5 got the shortest clock period. Its circuit was also among the largest. The final score ignores circuit size. The authors say benchmarks like this should report side costs next to the pass. My read: 58% of 48 tasks is 28 tasks for Opus 5.5. With 16 tasks unsolved, all twelve agents together solved 48 minus 16, or 32. So the other eleven agents added just 4 tasks that the leader missed. frontier-cs.org/

Perplexity and NVIDIA published a training method on October 21 where one model plays both teacher and student. It builds on self-distillation. The same model sees each task twice. As the teacher it gets extra help, such as a worked reference solution. As the student it gets only the task. The new method, JOLT, trains both roles at once and pushes the teacher toward feedback the student can actually use. They test on math, code, tool use and terminal tasks, each on a different open Qwen model. GRPO is the strongest baseline they tested. Against it, JOLT+ gains 1.5 points on GSM8K and 4.2 on MATH. It gains 3.0 on LCBv6 and 9.9 on the AppWorld state tests. The cost claim is the headline. At a matched accuracy of 63.44% on MATH, GRPO's real checkpoint used 8.40 million tokens while JOLT's fitted curve gives 1.30 million. One side is measured and the other is a curve, so that gap is an estimate. The longest-horizon test is Terminal-Bench 2.1 on Qwen3-30B-A3B. JOLT+ leads at every attempt budget, from 10.96% at one try to 34.83% at 32. Plain JOLT does worse, beating the base model and both distillation baselines but staying under GRPO. They say they will open-source the code soon. My read: against GRPO, JOLT+ adds 1.5 points on GSM8K and 4.2 on MATH, the harder of the two. That is 2.8 times the gain, 4.2 divided by 1.5. The method is named for meeting the student where they are, and the size of the help tracks how much room the benchmark had left. perplexity.ai/hub/blog/a-goo…

OpenAI has made its Decisions API generally available. It is a separate endpoint for the small judgement calls an app makes over and over. The design is narrow on purpose. You define a question and the answers it may give, then pass context as text, images or JSON. It returns a probability that a condition holds, a choice from your own list, or a score against a rubric. Nothing else. It runs on GPT-6 Luna. OpenAI says it is up to 10 times faster than asking Luna the same thing through the Responses API. Since the beta, the cap on questions per request has doubled to 400. There is also a native hook into GPT-Live. A voice app can now pick a reply path or an avatar expression while the user is still speaking. The pricing is unusual. Input costs 10 cents per million tokens, and cached input 1 cent per million. You pay nothing for output tokens. Box gives the only customer number here. It says route selection ran about 5 times faster on 30 certificate of insurance cases, at the same accuracy as the Responses API. OpenAI's own headline is up to 10 times. So the one measured result lands at about half the advertised ceiling, on a single document type. That is the gap to test on your own traffic before you plan around the headline. openai.com/index/decisions-a…

SemiAnalysis got its hands on a Huawei Ascend 950PR and ran its own tests on it. The card they tested has 28 cube cores and 128 GiB of HBM. Many versions of the 950PR and 950DT have shown up. SemiAnalysis says Huawei bins both compute and memory, and pairs weaker memory with weaker compute. The matrix-multiply results are strong. Across 1,055 BF16 shapes taken from open models, Huawei's best stock kernels hit 99.7% of the chip's ceiling. The advantage sits in compute-heavy work. On the rest of the shapes, Ascend had a median of 41.5% of what was attainable, against 46.8% on an H100. Raw speed is another matter. SemiAnalysis puts the 950PR somewhere between an A100 and an MI300X. Memory bandwidth use beat the H100 on small copies and nearly matched it on large ones. The software side is moving too. Ascend support is now merged into the main TileLang repo. Its AutoSchedule feature cut run time by up to 40% for a single operation on small sizes. The clocks in the matrix test are the part I would read twice. The Ascend ran at 1500 to 1550 MHz against a 1650 MHz reference, so 91% to 94% of that reference. The H100 ran at 1335 to 1470 MHz against an 1830 MHz max, so 73% to 80%. Some of the H100 runs were capped by its 700 W power limit, and the clocks show it. newsletter.semianalysis.com/…

Modal released Spindle on October 22. It is an open-source training server that uses the same API as Thinking Machines' Tinker, and it runs inside your own Modal workspace. You deploy it with one command. Billing follows GPU time instead of tokens. Modal says it built Spindle because scaling teams find per-token pricing costly across dozens of experiments. They also can only use the models the provider supports. Modal tested whether the API really matches. It took Jasper Lu's open-source GRPO search agent and changed only BASE_URL and API_KEY. That agent trains gpt-oss-20b to search SEC filings. Two Spindle seeds tracked both a Tinker rerun and the published run to within 0.01 reward across all updates. In a second run, a Qwen3.5-9B config went from 16k to 256k context with two config changes. It trained for about three days on preemptible GPUs, with 8 clients sharing the same GPUs. The cost case rests on idle trainers. Modal says a trainer with a single client sits idle for long stretches. With four clients interleaving steps it stays about 88 percent busy on the DAPO-math job. Modal adds that past four clients on that job the trainer thrashes and per-client throughput drops. In its tables, the DAPO-math job on a 27B model costs $9.77 per million output tokens on Tinker and $1.99 on Spindle with 8 clients. The search agent costs $5.06 on Tinker. Modal lists the Tinker price for its SWE-Gym run as an estimate. All of these runs are Modal's own. On the search agent, Modal used the same 8 H200 trainers and 16 H200 inference GPUs for 4 clients and for 8. The price per million tokens went from $4.06 to $3.80. Doubling the clients cut the price about 6 percent. Against Tinker the saving is 20 percent at four clients and 25 percent at eight. Four clients already delivered most of it. modal.com/blog/introducing-t…

CTGT ran one synthetic banking policy manual through its pipeline four times and got four different sets of obligations. Deterministic inference was on. The model was Qwen3.8-27B on SGLang with deterministic mode enabled. In a server test, 800 of 800 replies matched a single-request control over the first 1,000 tokens. Two speculative decoding setups without that mode, Qwen3.8-27B with DFLASH and gpt-oss-120b with EAGLE3, differed from the control in every request. The pipeline around the model was the problem. The four runs committed 32, 31, 33 and 33 obligations. One run dropped the rule that sends an unresolved conflict to the Head of Compliance. Across the runs, 74 model requests repeated exactly and got the same answer each time. Every changed answer followed a changed request. CTGT found three causes. Asset IDs, a hash of a per-upload UUID, sat in 53 of 459 model calls. A 30-item list came out in a different order each run. A shared topic registry grew from 21 keys to 22. After short stable aliases, sorting and a fresh organization per run, five runs committed the same 34 obligations. CTGT is releasing Concordance under Apache 2.0 to find the first stage where two runs differ. It calls this a first measurement, on one document and one pipeline. The four runs committed 32, 31, 33 and 33 obligations, which look close. The lost rule traced to four lines of IDs in a 12,525-character prompt. A count of obligations would not show that, so I would compare the requests themselves. ctgt.ai/research/concordance

Amazon has released TorchNeuron, an open-source backend that runs PyTorch code on its Trainium chips. Amazon says PyTorch code that already runs on other accelerators should run on Trainium with minimal or no code changes. The backend also gives developers access to the Neuron SDK profiler and the Neuron Kernel Interface. TorchNeuron adds an opt-in "adaptive eager" mode. It groups operations into small graphs, compiles them in parallel, and caches the results. Amazon says this approaches fully compiled speed without the usual compile wait. Caching works at several levels, in memory and on disk. One system compiles a graph and the other accelerators reuse it. An EC2 UltraServer holds between 16 and 144 Trainium chips, depending on configuration. Amazon tested a large language model spread across accelerators. It says this caching cut the time to the first training step by about a third. The testing method is the unusual part. AI agents searched Hugging Face and found hundreds of thousands of models with working code. Another agent sorted them by architecture and picked 841 representative models. Amazon also built a registry of tens of thousands of tensor shapes for fast unit tests. Each new revision runs the shape tests first, then the 841 models, then the full set. One product name covers a wide range of machines here. An UltraServer holds between 16 and 144 Trainium chips, a nine times spread (144 / 16). Amazon says the largest models outgrow even the top of that range and get sharded across thousands of chips. So the compile sharing is built for jobs no single UltraServer can run. amazon.science/blog/the-scie…

The llm-d project shipped v1.0, a release aimed at running inference fleets after launch day. The router now sorts every request by tenant and priority band, with one queue per flow. Under overload it holds requests in the router and sheds load, so one tenant's burst does not slow the others. A hot standby router takes over if the active one fails, and a new DisaggregatedSet rolls prefill and decode replicas out together. Agent traffic gets its own handling. Session-aware routing sends a follow-up turn to the replica that already holds its KV cache, and stays there until that replica fills up. The configuration API is now a stable v1. The project lists more than 500 contributors from over 25 organizations. The post reports several results from partners. AWS reports up to 70% more tokens per second than standard vLLM on SageMaker HyperPod. One test used an agentic coding workload on TPU 7x. Prefix-aware routing plus host memory KV offload cut median time to first token by more than 85%. Total throughput rose 2.4 times against a plain Kubernetes Service. Those two TPU results came from one workload and one comparison, so they can sit side by side. A first token that arrives in under 15 percent of the old time is more than 6.7 times sooner (1 / 0.15). Throughput rose 2.4 times. Routing and cache offload together helped the wait for a first token far more than they helped total output. llm-d.ai/blog/llm-d-v1.0-sta…

Meta has described the first phase of Prometheus, its gigawatt-scale AI training cluster in New Albany, Ohio. The first phase is finished, and Meta used it to train the Muse models. Meta says it is working toward about 1 million GPUs. Today the cluster runs two NVIDIA platforms. A third, based on Vera Rubin NVL72, is arriving soon. The two platforms differ in memory. Catalina uses GB200 NVL72, with 72 GPUs and 192 GB of HBM3e per GPU. Clemente uses GB300 NVL72 with 288 GB per GPU. Both are 72-GPU domains. Catalina spreads its 72 over two racks, and Meta lists about 120 kW for that pair. Clemente packs all 72 into one rack at about 135 kW. It lists a 5-10% performance gain for GB300 over GB200. Keeping the GPUs busy took most of the effort. In mid-2025 the cluster saw nearly 1,000 interruptions per 8K GPUs each day. Meta says a year of work cut that by 99%. Muse Wonder pre-training reached more than 85% goodput, and its reinforcement learning runs reached more than 90%. Spares matter because one NVL72 domain has 72 GPUs, which Meta says makes the fault blast radius 9X larger than NVL8. Each domain runs a 64-GPU slice and keeps eight GPUs as spares. A 32,768-GPU run needs 523 NVL72 racks. Memory grew faster than power from GB200 to GB300. The post lists HBM per GPU up 1.5 times, from 192 GB to 288 GB. For the same 72 GPUs, it lists power up from about 120 kW to about 135 kW, which is 1.125 times. Divide 1.5 by 1.125 and memory per kW is up by about a third. These are listed figures, not measured ones. engineering.fb.com/2026/10/1…

SGLang published a deep dive on HiCache, its tiered cache for reused prompt prefixes. GPU memory cannot hold every growing conversation, so old prefixes get evicted just before the next request needs them. HiCache keeps them in larger tiers. GPU HBM is L1, CPU DRAM is L2, and external storage is L3. Moving the data fast is half the work. SGLang's GPU-assisted I/O kernels reach up to 3x the transfer throughput of the standard cudaMemcpyAsync path. A page-first layout plus zero-copy gives up to 2x the Host to storage throughput. For hybrid models, a new backup step for recurrent snapshots lifted full recovery of a 6.4K shared prefix from 1 of 10 requests to 10 of 10. The multi-turn test used DeepSeek-V4-Flash on 4 H200 GPUs with a 500 GiB Mooncake L3. GPU-only caching served 9.4K input tokens a second. Adding CPU memory gave 14.3K. Adding storage gave 145.5K, with cache hits near 98%. The last tier does most of the work. CPU memory lifted throughput 1.5 times (14.3K / 9.4K = 1.52). The storage tier then added 10 times on top of that (145.5K / 14.3K = 10.2). The 15.5x headline is mostly the L3 step, so a deployment with spare host RAM but no shared storage should expect the small number. sglang.io/blog/hicache

vLLM can now add GPUs to a running MoE service with under two seconds of downtime. Restarting vLLM to scale DeepSeek V4 Pro from 16 to 20 GB200 GPUs stopped serving for 197 seconds. The first Elastic EP release avoided the restart, but serving still paused for 100 seconds going up and 56 seconds coming back down. The new version prepares the change in the background. Joining workers start up, receive weights and capture their CUDA graphs while the old workers keep serving. A new communication library, NIXL EP, adds and removes ranks in place, so the old workers keep their captured graphs. In the benchmark, downtime fell to 0.82 seconds for 16 to 20 GPUs and 1.96 seconds for 20 to 16. The team replayed 11,391 requests while load rose from about 8 to 16 per second. Rolling p95 time to first token stayed under the 5 second target. The fix removes the pause and leaves the wait. Adding four GPUs still takes 92.34 seconds from start to finish, and serving stops for 0.82 of them (0.82 / 92.34 = 0.9 percent). The blocking version took 99.72 seconds in total, so total time fell only 7 percent (92.34 / 99.72 = 0.93). An autoscaler still has to ask for new GPUs about a minute and a half before the load shows up. blog.vllm.ai/blog/2026-10-19…

Cloudflare cut the cost of its AI code reviewer by 68% and published where the savings came from. The cost had crept up first. An average review cost $1.19 in April and about $2.46 by the end of August. Cloudflare says it made no significant architectural changes. Most of the rise came from model changes, including a move to Anthropic models at the start of August. The first fix was the prompt cache. Cloudflare logged the first request of each session and found it hit a cached prefix only 14% to 26% of the time. Every session starts with the same 11k to 21k tokens. The tool put the working directory and date in the same block as the shared prompt. Splitting that block in two on September 16 let every repository reuse the cached part. Fewer calls and cheaper settings did the rest. Sub-reviewers had been trying to call a tool they were not allowed to use, in 57% to 76% of sessions. On Sonnet 5.5 at medium effort, the code quality reviewer now makes 1.7 calls per run instead of 6.2. The average review costs $0.77 instead of $2.43, and the median takes 1m 32s instead of 4m 9s. Cloudflare also tested effort on that reviewer. After one day, high effort cost 61% more per run and posted 58% more critical and warning findings than medium. Divide 1.61 by 1.58 and a finding costs about 1.02 times as much at high effort. So extra effort bought findings at nearly the same price each. Cloudflare moved code quality to high effort, but one day is a thin sample. blog.cloudflare.com/obsessiv…

AWS published how the company i14 trained and served a linear attention model, Laplace 3B, on Trainium2 chips. The model keeps a fixed memory per sequence. Its recurrent state stays at 29.5 MB no matter how long the context grows. AWS says that is roughly 82 times smaller than a comparable KV cache at 8,192 tokens. Raising the prompt from 2,048 to 8,192 tokens added only 0.5% to the cost per output token. On one trn2.48xlarge instance, Laplace 3B trained at about 120,000 tokens per second. The same instance served 11,544 output tokens per second across 1,280 concurrent sequences. Serving used an unmodified vLLM engine. Compiling the decode step lifted throughput from 6,772 to 11,544 tokens per second. The hard part was the Muon optimizer. In the naive version every rank gathers the full gradient, one rank does the work, and the rest wait. That moves 10.87 GB per step. AWS switched to two all_to_all steps, which cut per-rank traffic from 10.87 GB to 0.45 GB. Throughput rose from 73,378 to 119,934 tokens per second, with an identical loss curve. AWS says to test retrieval quality on your own workload, because linear attention compresses history. The training results run to step 84,210, about 44 billion tokens, with loss falling to 2.3729. Run their own transfer arithmetic on the old path. The post says 0.45 GB crosses NeuronLink-v3 in under 0.4 ms of a roughly 4.4 second step. The old path moved 24 times that, so about 9.6 ms. That is a fifth of one percent of the step. Yet it ran at 73,378 tokens a second against 119,934. Divide those and you get 0.61. So almost none of the lost time was wire time. It went on 63 ranks waiting while one of them ran Newton-Schulz. aws.amazon.com/blogs/machine…

Chips and Cheese has measured how Nvidia's Vera server chip moves data between cores, caches and memory. Vera feeds its Olympus cores through a 1024-bit LPDDR5X-9600 memory setup. The memory switch nodes can move up to 1.228 TB/s. Grace, the older chip, had memory latency of over 200 ns. On Vera, a pointer chasing thread never sees more than 200 ns, even while other threads push memory bandwidth to its limits. The L3 cache is 164 MB and shared across all cores. Its read bandwidth comes to about 3.35 TB/s, or 33.1 GB/s per core. One core alone can pull 88.5 GB/s. AMD's Genoa-X gives a single core 90 GB/s and holds 85 GB/s with all cores loaded. Core to core latency inside one socket averages 148.5 ns. Across sockets it is about 660 ns, against roughly 209 ns on Genoa-X. In the SPEC CPU2026 benchmark 749.fotonik3d, which leans hard on DRAM bandwidth, Vera leads Graviton 5 by nearly 20%. Graviton 5 wins at the socket level, and it has more than twice as many cores. The socket link is the odd part of this chip. NVLink C2C reads reach just over 587 GB/s, which is more than most servers have to their own memory. A remote memory access takes 309.27 ns, which is 177.41 ns more than a local one. The link pulls in two directions. Local memory comes out at 309.27 minus 177.41, so 131.86 ns. A cross-socket read takes 309.27 ns. That is 309.27 divided by 131.86, about 2.3 times a local access. Genoa-X does the same trip in 222.7 ns. So Vera has more cross-socket bandwidth than any dual socket system the author says he knows of. It still waits longer than AMD to use it. Bandwidth is what you buy. Latency is what you schedule around. chipsandcheese.com/p/nvidia-…

Symantec has caught an attack tool that runs its crimes on other people's AI models. The team recorded the agent's full instructions on an AI honeypot in the summer of 2026. A honeypot is a fake AI service left open on the internet to attract attacks. The operators sent their whole working prompt to it. They expected a real model on the other end. The prompt had five layers. It gave the model a new identity and called reading .env files and API keys normal development work. It added a companion persona that must never refuse. A rebuttal protocol told the model to treat its own safety messages as noise. The last layer held 74 callable offensive tools, including database dumping through Prisma and remote code execution through the Werkzeug debugger PIN. A directive the operators called "Skynet" mode allowed up to 100,000 unattended steps. It told the model to run tools without asking permission and to hide a crypto miner under /tmp/.x. The owner of the hijacked model pays for every step. A second request a day later carried a gzip-compressed shell script. It installed the XMRig Monero miner and set four mining pools to fail over. Symantec says the single techniques are old. The new part is one self-directed agent that plans the attack while a stranger's model pays the bill. Hold the ceiling next to what was actually recorded. The directive authorises 100,000 unattended steps. The captured request carries a log of exactly three tool calls. A probe, a fingerprint and a full scan. Symantec says none of them found a flaw. Those three ran against a benign training target, so they settle nothing about the agent in the wild. That is the honest state of it. We have the plan in full and three steps of evidence. security.com/threat-intellig…

InclusionAI released Ling 3.1 Flash 1019 on October 22, and Artificial Analysis has already run it through its own index. It scores 44 on the Artificial Analysis Intelligence Index, version 4.3.2. That index blends ten evaluations, among them Humanity's Last Exam, Terminal-Bench 4.0, SciCode, GDPval-AA and AA-Omniscience. That places it third of the 174 models Artificial Analysis groups it with, models in the same price range. The median there is 13. The rate card is close to ordinary for that group. InclusionAI charges $0.30 per million input tokens against a group median of $0.24. Output is $0.90 per million against a median of $0.87. It is a reasoning model with a one million token context window, and Artificial Analysis lists one API provider serving it. The bill is where it stands out. Running the index cost $1.49 per task on average. Over the whole index the model produced 350 million output tokens, against a group median of 100 million. Artificial Analysis ranks it 66th of 69 on verbosity. Now line up the two multiples. 44 divided by 13 is 3.4. 350 divided by 100 is 3.5. Against the same group median, in the same index run, the score it earns and the tokens it spends are almost the same multiple. That does not prove one causes the other. It does price the trade plainly. You pay roughly three and a half times the usual token volume. You get roughly three and a half times the usual score. Whether that is worth it depends on whether your work needs a 44. artificialanalysis.ai/models…

Inferact published results on October 21 for serving Kimi K3 agent traffic on Google TPUs through vLLM. The work puts its TPU megakernels behind a new backend in vLLM TorchTPU, chosen with a load format flag. The megakernels replace the model's layer stack. The rest of vLLM stays in place, so async scheduling, prefix caching, KV transfer and the API server all work as before. Inferact's earlier kernels showed weight prefetching and compute overlap giving one user high speed. This round is about serving many sessions at once. The job runs across two TPU v7 slices of 16 chips each, one for prefill and one for decode. Each sequence's cache is cut into 256 token pages and spread across all 32 ranks. A library called Raiden moves each rank's pages straight to the same rank on the decode slice. Kimi K3 routes every token to 16 of its 896 experts. The decode slice splits those experts into eight groups of 112, and each group's four ranks shard its matmuls. Inferact ran SemiAnalysis's AgentX agent benchmark and published the whole table. With one request in flight the pair of slices shows 23,000 total tokens a second, and 408 tokens a second for that one user. At 32 requests, on the same decode recipe, the table shows 170,495 total and 90 per user. The cost comparison uses $1.21 per TPU v7 chip hour and $1.86 per GB200 GPU hour. Inferact says the backend gives strong interactivity at low and mid concurrency. Take those two rows, which share a decode recipe. 170,495 divided by 23,000 is 7.4. So 32 times the requests buys 7.4 times the total output. Put the other way, one request on its own already draws about a seventh of what the pair of slices does at 32. For a chat server that looks like idle silicon. For one agent grinding through its own output, it is exactly what you are paying for. inferact.ai/news/tpu-megaker…

Google DeepMind and Google Research released a new global forest map on October 22. Their partners are the World Resources Institute and the International Institute for Applied Systems Analysis. It is called Forest Typology, or ForTy. It sorts every 10 by 10 metre patch of land on Earth into six classes. Those are primary forest, naturally regenerating forest, planted forest, plantation forest, tree crops and agroforestry, and other land. The classes follow UN Food and Agriculture Organization definitions. Several of them turn on how people use the land, so a look from above does not settle the answer. Alongside the 2020 map the team published an early time series. It covers every year from 2017 to 2025. That is the part that says what replaced a forest after it went. Most global maps only indicate whether trees are present. When a natural forest is logged and replanted, the land soon looks green again, so the swap can pass unnoticed. Training used about 1.7 million labelled locations. They came from expert surveys, national and regional datasets, and targeted reviews of places where the model struggled. The model takes AlphaEarth Foundations embeddings as a key input. Those pack years of satellite observations into one compact summary per 10 metre pixel. The team then checked the result with WRI and IIASA against more than 9,000 randomly chosen sites. Two trained experts studied each site. ForTy named the right forest type 90% of the time. It told forest from non-forest land 95% of the time. It also returns a probability for each class, so a company facing the EU deforestation rule can set a strict threshold. The map and the time series are on Google Earth Engine under an open licence. Both scores come off those same 9,000 sites. The easy question, forest or not forest, lands at 95 in 100. The six way question lands at 90. Five points separate them, and the harder one is what the EU rule leans on. It bars wood that came from a primary forest since turned into a plantation, and from a regenerating forest since turned into a plantation. deepmind.google/blog/beyond-…

Google Cloud laid out its next GPU platform on October 21 at NVIDIA GTC Berlin. The instance is called A5X. It is bare metal and built on NVIDIA's Vera Rubin NVL72 platform. Google says general availability arrives next month. New local regions will cover EMEA data residency at the same time. Underneath it sits a new fabric called Virgo Network. Google describes a non-blocking mesh that scales out inside a building and between buildings. It says the fabric will let clusters reach 80,000 Rubin GPUs within a single site, and up to 960,000 Rubin GPUs across multi-site deployments. Two more pieces come with the instance. Managed Lustre will support NVIDIA GPUDirect Storage on A5X. Data then takes an RDMA path from the file system straight into GPU memory, skipping the CPU. A5X will also carry KV caching that pushes context past HBM into other storage tiers. Google ties that to a lower time to first token on long and multi-turn jobs. My read. 960,000 divided by 80,000 is 12. Google's multi-site ceiling is exactly twelve times its single-site one. One site is the unit it is designing to, and the roadmap is about a dozen of them wired as one machine. cloud.google.com/blog/topics…

Vals AI updated its Web Search Index on October 21. It scores a search tool by what it is worth to an agent working through real expert-written tasks. The method swaps the search tool and holds the model and the harness fixed. Tasks come from two existing benchmarks, FAB v2 for finance analysis and the Legal Research Benchmark. Vals also removed the domain tools those benchmarks normally hand the agent, such as SEC EDGAR for filings and CourtListener for cases. General web search is then the agent's only window onto the world. GPT-5.6 Sol with Keenable leads at 49.08 percent. Claude Fable 5 with Exa sits just behind at 48.45 percent, and Vals points out it gets there at less than half the cost. The same model on its own native search scores 46.94 percent. Almost all of the bill is model inference. Vals puts the search fee at $0.41 of the $8.84 mean task cost for GPT-5.6 Sol with Keenable. GPT-5.6 Sol with Exa is the cost outlier at about $18.97 overall and up to $28.28 on legal. Vals traces that to a few tasks where the model loops through hundreds of Exa calls before answering. My read sits in one column of that table. Same model, same harness, and only the search tool moves. GPT-5.6 Sol on its native search costs $0.95 a task and scores 43.58 percent. On Keenable it costs $8.84 and scores 49.08 percent. 8.84 divided by 0.95 is 9.3. So the better tool is 9.3 times the money per task for 5.5 points. vals.ai/benchmarks/web_searc…