Full article content is not available for inline reading.

Read the original article →

Full article content is not available for inline reading.

Read the original article →

• OpenAI said that its upcoming AI model Astra is its first to exceed its "Critical" cybersecurity capability threshold.
• The company said Astra can find previously unknown security flaws and exploit them without step-by-step guidance from humans.
• OpenAI said it still plans to make Astra available "soon," but that access to its cybersecurity capabilities will be more limited.

OpenAI on Tuesday said its upcoming artificial intelligence model Astra is the first offering that crosses its "Critical" cybersecurity capability threshold.

The company said Astra can find previously unknown security flaws and exploit them without step-by-step guidance from humans, which means the model falls under the most advanced category of its so-called Preparedness Framework. OpenAI said it still plans to make Astra available "soon," but that access to its cybersecurity capabilities will be more limited.

OpenAI introduced its Preparedness Framework in 2023, and it serves as the company's method for "tracking and preparing for advanced AI capabilities that could introduce new risks of severe harm." In an update to the framework last year, the company outlined a "High" capability threshold, where models could amplify "existing pathways" to severe harm, and a "Critical" capability threshold, where models could introduce "unprecedented new pathways" to severe harm.

"We will share more details about our safety, security and alignment testing and evaluations in the model's System Card at launch," OpenAI said in a blog post on Tuesday.

OpenAI's security and safety practices have been under intense scrutiny after the company disclosed that two of its models escaped their training environment, accessed the open web and breached Hugging Face's systems last month. OpenAI characterized the attack as an "unprecedented cyber incident" and temporarily paused some of its internal training and research.

The company decided to delay parts of Astra's development even though the model was not involved in the Hugging Face incident. After strengthening and testing protections, OpenAI said Tuesday that it believes the model's safeguards "sufficiently minimize the risk of severe harm for release under our Preparedness Framework."

Astra's advanced cyber capabilities will be available to a select group of organizations that are part of its cybersecurity coalition called Daybreak, OpenAI said.

Introducing @huggingface/kernels: 200+ WebGPU Kernels for Local AI

One of our biggest goals on the WebAI team at Hugging Face is to make browser inference as fast and as user-friendly as possible. Getting there is a multi-layer effort: models need browser-friendly representations, runtimes need to build efficient execution plans, and the individual GPU operations at the bottom of the stack need to make the most of many different devices and browser implementations.

Today, we are releasing the first layer of that effort: @huggingface/kernels, a minimal library for loading and running optimized WebGPU kernels from the Hugging Face Hub, together with an initial collection of 207 kernels at huggingface.co/webgpu-kernels.

The collection covers operations used across a wide variety of machine learning architectures and workloads. More importantly, each kernel is published as a complete, versioned package: its interface, shader templates, correctness cases, benchmark cases, and usage instructions all live together on the Hub.

We are also launching Fleet, an in-browser GPU benchmarking and testing suite that runs and scores the kernels on your hardware. Beyond the results for your own machine, Fleet gives the community a way to contribute performance and correctness evidence from devices we could never cover in a conventional test lab. With your consent, every run adds private evidence that can help us find failures (incorrect results, pathologically slow cases, etc.), improve kernel variants, and make better optimization decisions across real-world hardware.

TL;DR

• 207 WebGPU kernels, published as individual repositories in the webgpu-kernels organization. Apache-2.0 licensed.
• A JavaScript loader, @huggingface/kernels, which downloads, prepares, and runs kernels directly from the Hub.
• Explicit contracts and reproducible evidence for every kernel, including manifests, correctness tests, benchmark cases, and WGSL shader templates.
• Fleet, a browser-based benchmarking tool that crowdsources correctness and performance evidence across real-world GPUs to help us improve kernels and their variants.

Why start with kernels?

A model running in the browser eventually becomes a sequence of GPU operations: matrix multiplications, normalizations, convolutions, attention primitives, quantization operations, data-layout transformations, and many more. WebGPU makes these operations available across modern browsers through a portable API, while WGSL provides a common language for the shaders that execute them.

Portability, however, does not automatically mean performance. Two shaders can implement the same operation and produce the same output while behaving completely differently across different accelerators. Workgroup sizes, memory access patterns, vectorization, data types, and fusion strategies can all affect performance. The best choice can also change with the input shape, device, browser, and available WebGPU features.

This is why kernels form a foundational layer of fast browser inference. Higher-level runtimes can only be as efficient as the operations they dispatch. By making those operations individually discoverable, testable, benchmarkable, and versioned, we can improve the foundation independently while keeping a stable contract for the layers above it.

A kernel repository, not just a shader

Each kernel in the collection has its own repository and kernel card. The card documents the operation's semantics, inputs, outputs, attributes, supported data types, source files, and a ready-to-run @huggingface/kernels example.

For example, ai.onnx.Add implements elementwise addition with multidirectional broadcasting. It is one of the simplest operations in a neural network, used everywhere from residual connections to adding a bias. Its card documents the two inputs, the broadcasted output shape, supported data types, and the variants available for different shapes and devices.

Behind the card, the repository contains the artifacts needed to understand and evaluate the implementation:

• manifest.json is the source of truth for the operation contract. It defines inputs, outputs, attributes, type constraints, and shape derivation rules.
• metadata.json records the kernel identifier, digests, and provenance.
• test.json contains correctness cases, so an implementation can be checked against expected behavior.
• bench.json contains benchmark and tuning cases that represent the workloads used to evaluate the kernel.
• *.wgsl.jinja files contain the parameterized WGSL implementations used to produce shaders for a particular request and device.

This structure turns a shader into a reusable software artifact. The interface is inspectable without reading WGSL, correctness and performance cases travel with the implementation, and published versions can be loaded explicitly rather than depending on an unversioned file URL. Our kernels can also serve as reference implementations for developers building custom WebGPU kernels or integrating these operations into their own runtimes.

Loading a kernel from the Hub

Install the package from npm:

npm install @huggingface/kernels@preview

Running these kernels requires a browser with WebGPU support. WebGPU availability depends on the browser, operating system, GPU, and driver. You can check for it in JavaScript with "gpu" in navigator.

@huggingface/kernels provides the bridge between a kernel repository and your application. Call getKernel with a Hub repository ID and a contract version, then invoke the returned function with typed input data and tensor shapes. Here is a small bias-add example:

import { getKernel } from "@huggingface/kernels";

const add = await getKernel("webgpu-kernels/ai.onnx.Add", { version: 1 });

const { c } = await add({
  a: {
    data: new Float32Array([1, 2, 3, 4, 5, 6]),
    shape: [2, 3],
  },
  b: {
    data: new Float32Array([10, 20, 30]),
    shape: [3],
  },
});

The second input is broadcast across the first dimension, producing an output with shape [2, 3]. The loader derives that output shape and logical data type from the manifest contract and the inputs, then allocates c automatically.

Addition on six floats is deliberately the smallest possible demo. At this size, the GPU round trip costs far more than the math. The point is the call pattern: it stays exactly the same for the heavyweight operations where optimized kernels actually pay off, such as matrix multiplication (ai.onnx.MatMul). Only the repository ID and the inputs change.

Even this elementary operation illustrates why kernels need variants. Equal-shape addition can use a direct vectorized path, while broadcasted inputs need different indexing logic. The published Add kernel includes variants for equal shapes, vectorized broadcasting, scalar processing, and general broadcasting. The runtime can select an implementation that fits the current call and device without changing the application-facing API.

The version: 1 option selects version 1 of the published kernel contract. It is separate from an ONNX opset, an operator's since_version, or a model revision. Keeping those concepts separate lets applications depend on a stable JavaScript-facing contract while kernel implementations evolve behind it.

How fast are the kernels?

So, how much of a difference do optimized kernels actually make? We put our collection head-to-head with ORT WebGPU on an Apple M4 GPU, using ONNX Runtime Web 1.30.0-dev.20260826-b1f76d586a. We started with 1,756 test cases across all 207 operations and kept the 809 cases where both sides produced matching outputs and reliable timings.

Across those comparisons, our kernels were 2.57x faster by geometric mean and 1.90x faster at the median, with 629 wins, 176 losses, and 4 ties. Here is a closer look at four familiar operations:

Some individual wins were much bigger. A particularly difficult bilinear Einsum case (i,ij,j with size 4096) ran in 0.136 ms with our kernel versus 1,396 ms with ORT WebGPU: more than 10,000x faster. A row-wise CumSum over [256, 4096] was 301x faster, at 0.016 ms versus 4.784 ms. These are unusual cases rather than the speedups you should expect everywhere, but they show how much a specialized kernel can help when a general implementation hits a slow path.

We timed the work done on the GPU itself, leaving out setup such as loading kernels, creating sessions, uploading inputs, compiling shaders, and reading outputs back. Very short workloads are naturally harder to measure, and small cases can benefit from the GPU cache, so these numbers are best read as a useful comparison rather than a promise for every application.

They are also results for individual operations, not complete models. Exact performance will change across GPUs and browsers, which is why Fleet is so important for building a broader picture.

We are also working with the ONNX Runtime team to upstream these improvements so they can benefit the broader ONNX Runtime Web ecosystem.

From one device to a fleet

WebGPU performance varies across GPUs, browsers, and drivers, so results from one machine only tell part of the story. Fleet lets anyone run correctness and performance checks in the browser and see how the kernels behave on their hardware.

With consent, each run privately contributes evidence that helps us spot device-specific failures, compare variants, and improve selection rules. The goal is simple: use broad, real-world coverage to make the kernels faster and more reliable for everyone.

Building a shared foundation for WebAI

The initial 207 kernels are a starting point, not the end state. Publishing kernels independently on the Hub gives us a common place to inspect contracts, compare implementations, reproduce correctness checks, and improve performance without embedding every shader directly into every runtime.

The collection is also part of the Hub's broader kernel ecosystem: on the Kernels page, the WebGPU kernels sit alongside kernels for CUDA, ROCm, Metal, and other platforms, and can be filtered, sorted, and explored like any other artifact on the Hub.

The pieces reinforce one another:

1. Kernel repositories define transparent, versioned operation contracts.
2. @huggingface/kernels makes those operations straightforward to load and run from JavaScript.
3. Fleet crowdsources real-world evidence across a much broader range of devices than a conventional benchmark lab can cover.
4. Every contributed run can reveal failures, guide tuning, improve variant selection, and help validate future kernel versions.

This is the low-level foundation for the next steps in our browser inference stack. We are excited to connect these kernels to higher-level model tooling, continue expanding operation coverage, and make fast local inference easier to use across the WebAI ecosystem.

Explore the WebGPU kernel collection, try @huggingface/kernels, and join the Fleet to contribute evidence from your device and help us make the kernels better for everyone.

A Type System Is a Search Oracle

Working with models on real code, I keep noticing the same thing. The Rust I get back is better than the C++ I get back, and the Lean is better than either. Not marginally. The Rust compiles and does roughly what I asked; the C++ compiles and does something adjacent to what I asked, and I find out which on a Tuesday three weeks later.

The published benchmarks say the opposite, and clearly. Rust is a low-resource language as far as a pretrained model is concerned, underrepresented relative to Python by a wide margin, and it scores well below Python on the standard multilingual code benchmarks. Lean barely registers. If you ranked languages by how much of them a model has read, my experience runs backwards down the list.

Both observations are correct. Reconciling them is the interesting part, and the answer changes what I think a type system is for.

What one-shot accuracy leaves out

A pass@1 number measures whether the first draft is right. Nobody ships the first draft. The number I care about is different: of the programs that reach production, how many are wrong, and how much work did it take to get there.

The cleanest experiment I have found on this used Idris, which is a reasonable stand-in for the far end of the type-strength axis. Li and Krishnamachari gave GPT-5 fifty-six Exercism problems in Idris and measured it zero-shot against the same model on other languages.

Zero-shot, the result is what the benchmarks predict. Idris solves 39% where Python solves 90%. The model has not read much Idris and it shows.

Then the compiler goes in the loop, and Idris finishes at 96% — above where Python started. The ablation is the part worth sitting with. They also tried feeding the model documentation, and feeding it a guide to classifying Idris errors. Neither worked as well as handing back the local compilation errors. The compiler’s own message, generated from the model’s own broken code, was the most valuable signal available.

The feedback loop provides the reconciliation. Training data determines where the first draft lands. The type system determines whether the loop that follows converges on something correct or just on something that runs.

The same shape at company scale

Fifty-six problems in a language nobody deploys is thin evidence for a claim about how software gets written. Some corroboration arrived last month from a direction I was not expecting.

David Tolnay published eight years of language adoption at Meta, drawn from the source-control tables that back the company’s internal dashboards. The metric is a year-over-year ratio: within each ninety-day window, the fraction of developers who committed in a given language, divided by that same fraction twelve months earlier. Company growth and the seasonal swings in code output both cancel.

Five languages inflect together around February and March of 2026, and Tolnay dates the cause without hedging: “This timeframe correlates with the uptake in agentic coding among Meta engineers in Q1 of 2026.” The five are TypeScript, Rust, Swift, JavaScript and Go. He discounts one of them himself, attributing the JavaScript growth to configuration files inside TypeScript projects rather than to new JavaScript work. That leaves four, all statically typed. His summary of everything else on the chart: “Other than TypeScript, Rust, Swift, JavaScript, and Go, every other language on the chart is uncorrelated or at best slightly correlated with AI adoption.”

Two cautions, because this is easy to over-read and I nearly did.

C++ and Python are flat, and that is not evidence that models write them badly. A growth ratio divides by the base, and these are among the largest languages at Meta. A one percent move in C++ participation can exceed a doubling of Rust in absolute terms while still drawing a flat line, so flatness is consistent with C++ absorbing more engineering effort in 2026 than every surging language combined. Tolnay makes the same observation from the other side when he describes those languages as saturating their addressable market.

The unit is also a developer rather than a line of code, so someone who writes one file counts like someone who writes the language full time. That matters most at the top of the chart. Tolnay’s own explanation for TypeScript’s growth is that engineers and managers “are producing all kinds of dashboards and personal widgets in TypeScript that they never would have bothered to do without AI.” Dabbling counts at full weight.

What survives both cautions is the one figure that is not a ratio — Meta engineers wrote twice as much first-party Rust this year as in the previous nine years combined — and the selection itself. Cheap generation applied broadly would have lifted the whole chart. The lift concentrated in languages whose compiler rejects a wrong program before it runs.

C++ is the control group

If the thesis were “static typing helps,” C++ would be fine. It is statically typed, aggressively so, with a type system elaborate enough to be Turing-complete at compile time. My experience with generated C++ is nonetheless closer to Python than to Rust, and I think that difference is the most informative data point I have.

The distinction is not static versus dynamic. It is how much a successful compile promises.

In Rust, a program that compiles has been checked for a specific and useful set of properties: no use-after-free, no data races between threads, no aliasing a mutable reference, every enum match exhausted, every error path acknowledged at the call site. The checker cannot be talked out of these. Defeating it requires writing unsafe, which is a lexically visible, greppable admission that the guarantee stops here.

In C++, a program that compiles has been checked that the names resolve and the overloads pick out. It has not been checked for use-after-free, iterator invalidation, data races, out-of-bounds access, or signed overflow. An implicit conversion can quietly change the meaning of a call. A reinterpret_cast will convert any pointer into any other pointer with no ceremony at all. Undefined behaviour offers no diagnostic, serving instead as a licence for the optimiser to assume the case never happens.

So “it compiles” carries far less information in C++ than in Rust, and it is the information content of that signal that determines how useful the compiler is as a reviewer. A checker that can be defeated silently is a checker whose approval means less.

graph LR
    A["generated program"] --> B{"checker"}
    B -->|"rejected"| C["error text<br/>fed back to the model"]
    C --> A
    B -->|"accepted"| D["reaches runtime"]
    D --> E["wrong in ways<br/>the checker cannot see"]
    style C fill:#1e3a5f,color:#fff
    style E fill:#7f1d1d,color:#fff

Every type system is this diagram. What differs between languages is how much of the wrongness flows down the right-hand edge instead of the left. Python sends nearly everything right. C++ sends a great deal right, including most of the memory-safety and concurrency errors that matter. Rust pushes a large, well-defined class of it left. Lean pushes almost all of it left.

Lean is the limit case

Lean is where the argument stops being about ergonomics and becomes about algorithms.

A Lean proof is checked by a kernel. It checks or it does not, and the answer is a decision rather than an opinion. That single property changes what you are allowed to do with an unreliable generator, because it makes generation searchable.

Sampling thirty-two candidate proofs and keeping the one that checks is a sound procedure. You get a correct proof or you get nothing, and you always know which. Delta Prover reaches 95.9% on miniF2F this way, using a general-purpose model with no fine-tuning at all, driving Lean 4 through decomposition and iterative repair against compiler feedback. Recent systems report figures in that range with the same basic shape: propose, check, repair, repeat.

Now try that in Python. Sample thirty-two implementations, run the tests, keep the ones that pass. What you have is thirty-two programs that agree with your test suite, which is a much weaker statement than thirty-two correct programs, and you have no way to distinguish the two. The oracle is partial, so the search is unsound. You are back to reading the code.

A verifier you can call cheaply and trust completely turns a mediocre generator into a good one, because brute force becomes admissible. The availability of brute force explains why models are unreasonably good at Lean given how little Lean exists to have been trained on. The scarcity is real. The oracle compensates.

What the checker still cannot see

Rust that compiles can still be wrong. It can compute the wrong thing correctly, with excellent memory safety, forever. Types constrain the shape of a computation, not its intent, and outside a dependently typed setting they only encode the part of the specification you chose to write down.

The self-repair literature is consistent about where the remaining difficulty lives: syntactic and type errors turn out to be far more tractable for a model to fix from feedback than logical or algorithmic ones. That finding is usually reported as a limitation. I read it as the mechanism. Moving an error from the second category into the first is what a stronger type system does, and it constitutes the whole of the benefit. An off-by-one in an index becomes a compile error when the index is a distinct type. A forgotten case becomes a compile error when the match must be exhaustive. A stale pointer becomes a compile error when lifetimes are tracked.

None of that makes the model smarter. It relocates a class of mistakes from the expensive category to the cheap one.

Why this matters more for generated code than for mine

When I write a function, the code is a partial record of a model I hold in my head. The invariants I did not write down are still real, because I know them and I will maintain them. Review works reasonably well against that background, since a reviewer can ask what I was thinking and get a coherent answer.

A generated function comes with no such model, arriving instead as locally plausible text. Plausible-but-wrong text is the failure mode human review is worst at catching. Reviewers are good at spotting code that looks wrong. Generated code that is wrong usually looks right — surface plausibility makes the text useful when it happens to be correct.

The mental model that used to carry the unwritten invariants is gone, leaving a machine checker as the only cheap way to put constraints back. The machine remains indifferent to plausibility. It does not get tired at four in the afternoon, and it refuses to extend the benefit of the doubt to code that reads confidently.

This is the argument I made from a different direction in an earlier post on provenance: knowing where code came from tells you nothing about whether it is correct, and a signature on a program is not a proof about its behaviour. The conclusion is the same from both sides. As more code is generated, the value of properties a machine can check rises, and the value of properties resting on an author’s understanding falls, because there is no author holding the understanding.

The part I have not resolved

I would like this to be a measurement rather than an impression, and it is not one yet. My evidence is one controlled experiment on a language nobody deploys, a body of theorem-proving results whose success depends on a total oracle that ordinary programming does not have, an adoption curve that records what engineers reached for rather than whether it worked, and my own experience, which is uncontrolled and which knows what conclusion it prefers.

What I would want is the number nobody publishes: defects per thousand lines of generated code that reached production, cut by language, controlled for the same task and the same reviewer discipline. Pass@1 on programming puzzles is a poor proxy, and it is the wrong end of the pipeline.

The mechanism is clear enough to act on regardless. A generator with a nonzero error rate needs a verifier, the strength of the type system sets how much of the specification the verifier can decide, and everything it cannot decide falls to a reviewer whose weakest moment is confident, plausible, wrong code. Choosing a language for a codebase that will be substantially machine-written is now partly a decision about how much of your specification you want the compiler to hold.

References

Disclaimer: Researched and drafted with AI assistance (Claude Opus 5 and Gemini 3.1 Pro). Direction, technical judgment, and final edits are mine. The Idris and Lean figures are quoted from the linked papers, and the Meta figures from Tolnay’s article, rather than reproduced by me; I have no access to the underlying data in any of the three cases. The comparison between generated Rust, C++ and Lean that opens this post is my own working experience and is not a controlled measurement; I have tried to be explicit about which claims rest on it.

1. Low-resource programming languages in code LLMs. Rust is consistently classified among the low-resource languages for code generation, substantially underrepresented in pretraining data relative to Python, with correspondingly lower pass rates on multilingual benchmarks such as MultiPL-E. Reported figures vary between studies, so I have avoided quoting a single number.

2. Compiler-Guided Inference-Time Adaptation: Improving GPT-5 Programming Performance in Idris. Minda Li and Bhaskar Krishnamachari, February 2026. Zero-shot, GPT-5 solves 22 of 56 Exercism problems in Idris, against 45 of 50 in Python and 35 of 47 in Erlang. Of the refinement strategies tested — platform feedback, added documentation, error-classification guides, and local compilation errors — feeding back local compilation errors performed best, raising Idris to 54 of 56.

3. Programming language adoption patterns at Meta. David Tolnay, 11 August 2026. Built from Meta’s code review and source control tables covering all code changes submitted by employees. For each 90-day window the count of developers committing in a language is divided by the total committing in any language to give a market share, then divided by that language’s share in the window ending twelve months earlier; the twelve-month spacing cancels seasonal variation in code output.

4. Solving Formal Math Problems by Decomposition and Iterative Reflection. Delta Prover drives Lean 4 from a general-purpose LLM with no model specialization, using reflective decomposition and iterative proof repair against compiler feedback, and reports 95.9% on miniF2F.

5. Iterative feedback loops for LLM code correction. Across iterative-refinement studies, models improve markedly when given compiler errors and failing test cases, and the residual difficulty concentrates in logical and algorithmic errors rather than syntactic or type errors.

Small Is Beautiful

Estimates are that, to justify the AI platforms' enormous capex plans, by 2030 they need to be generating around $2T/year in revenue. If every adult resident of the US spent $20/month on AI, it would generate $68.5B/year. Clearly, only the enterprise market stands even a remote possibility of generating the bulk of the $2T.

There are three major threats to the prospect of AI platforms extracting 6% of current US GDP from the enterprise market, and thus to OpenAI's and Anthropic's ambitions to IPO in the near future. First, faced with AI's Affordability Crisis, companies have been placing strict limits on employees' spending on AI tokens.

Second, the gap in performance between expensive, closed-weight US models, such as OpenAI's and Anthropic's, and much cheaper, open-weight Chinese models has been rapidly closing, with the result that the US models are losing enterprise market share. Luz Ding, Spe Chen and Hayley Warren analyze this in US Lead in the AI Race With China Is Rapidly Narrowing:

Bloomberg in partnership with researchers at Vals AI, an independent AI evaluation and benchmarking platform, tested seven models from frontier Chinese and US companies to see how they performed in a real-world task. They were asked to create a fictional coffee e-commerce site called Brewberg using the same prompts. Most of the models scored 100% functional accuracy despite occasional design misses, but with very different price tags. The experiment employed the top performing models in July from Anthropic and all the Chinese firms, as well as more affordable models from OpenAI and Google.

They all did reasonably well, but the two best were Claude Fable 5 at $48.99 and Kimi K3 at $11.99. Chinese models charging much less for almost the same performance are grabbing market share:

the use of Chinese models overtook US platforms globally for the first time in June, and accounted for more than 60% of market share last month, on OpenRouter, a tech platform that offers software developers access to hundreds of AI models. It is a widely watched gauge of model usage despite tracking just a fraction of global AI consumption. The US, parts of Europe and Asia now favor Chinese labs, according to the same data. On Hugging Face, Chinese AI models account for 41.4% of generative model downloads among developers, 5 percentage points higher than US models.

Third, it isn't just that the Chinese models are cheaper to run remotely, but also that because they are open-weight they can be run on affordable in-house systems, which means that:

• They don't give Donald Trump a kill-switch for your busines.
• They don't give Sam Altman or Dario Amodei a kill-switch for your busines.
• They don't require giving the Chinese, Sam Altman or Dario Amodei all your business' critical data.
• They provide visibility into and control over AI costs.
• They are even cheaper.

The question is "compared to the closed-weight US models, what do you lose by running open-weight models in-house?" Below the fold I discuss a major study from Stanford that answers the question.

The 37-page paper is Intelligence per Watt: Measuring Intelligence Efficiency of Local AI by Jon Saad-Falcon et 14 al. Their abstract reads:

Large language model (LLM) queries are predominantly processed by frontier models in centralized cloud infrastructure. Demand growth strains this paradigm faster than providers can scale. Two advances create an opportunity to rethink it: small, local LMs (<=20B active parameters) now achieve competitive performance to frontier models on many tasks, and local accelerators (e.g., Apple M4 Max) can host these models at interactive latencies. This raises the question: can local inference viably redistribute demand from centralized infrastructure? This requires measuring both whether local LMs can accurately answer real-world queries and whether they can do so efficiently on power-constrained devices (e.g., laptops). We propose intelligence per watt (IPW), task accuracy per unit of power, as a unified metric for the capability and efficiency of local inference across model-accelerator configurations. We evaluate 20+ state-of-the-art local LMs, 8 hardware accelerators (local and cloud), and 1M real-world single-turn chat and reasoning queries. For each query, we measure accuracy (local LM win rate against frontier models), energy, latency, and power. We find three key results. First, local LMs successfully answer 88.7% of these queries, with accuracy varying by domain. Second, longitudinal analysis from 2023-2025 shows IPW improved 5.3x, driven by both algorithmic and accelerator advances, with locally-serviceable query coverage rising from 23.2% to 71.3%. Third, local accelerators achieve at least 1.4x lower IPW than cloud accelerators running identical models, revealing significant headroom for local accelerator optimization. These findings demonstrate that local inference can meaningfully redistribute demand from centralized infrastructure for a substantial subset of queries, with IPW serving as the critical metric for tracking this transition.

Joachim Klement provides an introduction to this "Small Language Models (SLMs)" paper in If this is true, the hyperscalers are toast:

First, they ran a series of SLMs (QWEN 3, GEMMA 3, GPT-OSS, GRANITE 4.0) that can be downloaded on a local PC and compared their performance with cloud-based state-of-the-art LLMs (ChatGPT 5, Claude Sonnet 4.5, Gemini 2.5 Pro). They ran these SLMs on local PCs powered either by an Nvidia chip or an Apple M4 chip, as they are readily available in current high-end desktop computers ... Then they traced the performance of these SLMs vs LLM between 2023 and October 2025 on both chat tasks and reasoning tasks.

The results on four benchmarks are in Saad-Falcon's Figure 2, whose caption is:

Local Models Rival Cloud Models Across Diverse Benchmarks: Individual model performance scales with size, ranging from 31.5–69.4% for IBM GRANITE 4-H-S MALL, 30.0–83.6% for GEMMA 3-12B, 51.5–80.4% for GPT-OSS-120B, and 66.5–89.5% for GEMINI 2.5 PRO . Local routing (best local LM per query) achieves 97.8%, 88.3%, 77.0%, and 92.4% on WILDCHAT, NATURAL REASONING, SUPER GPQA, and MMLUPRO respectively, sur- passing cloud routing (100%, 82.9%, 66.5%, 87.4%) on three of four benchmarks.

Klement reformats the results into charts. First for chat tasks:

which still make up the vast majority of requests today. As you can see, in every domain, the best SLM is able to find the same or better answers than an LLM in 90% or more of the cases, with an average across all domains of 98.6%.

It is really hard to justify spending 4-6 times as much for a 1.4% improvement in performance, so LLMs are no longer really necesssary for chat tasks.

Second for reasoning tasks:

which are obviously more demanding, SLMs are catching up fast. On average, they provide a better or at least as good an answer as LLMs in 62.5% of the cases.

SLMs may be catching up fast on reasoning tasks (see IBM's Granite 4.2 below) but it will be a while before LLMs are obsolete for these tasks.

However, in real life as Klement points out:

the tasks for SLMs and LLMs are typically a mix of chat requests and reasoning tasks, so the third chart shows the weighted average of chat request performance and reasoning performance based on the frequency of tasks in each domain. As you can see, on average, SLMs are as good if not better than LLMs in 81.2% of the cases, with the LLMs having a significant advantage only in areas like engineering, life sciences, transportation and computer sciences. But it’s not just accuracy. SLMs achieve this performance at energy and compute costs that are between 50% and 85% lower than for an LLM, depending on the SLM and hardware used in the computer.

The advantage for LLMs is being eroded quite quickly except for the extremely complex tasks. Saad-Falcon et al's Figure 7 shows how fast SLMs are catching up on reasoning tasks:

For reasoning tasks ... the pattern differs substantially. While levels 1-3 show strong improvements (+24.0, +37.8, and +53.9 pp respectively), levels 4 and 5 exhibit markedly slower progress. Level 4 improves by only +23.8 pp (7.93% to 31.72%), and level 5 remains largely unsolved with just +1.5 pp improvement (3.27% to 4.72%). This suggests that while local models have rapidly closed the gap on moderately difficult reasoning tasks, the hardest reasoning problems (those requiring either massive scale or capabilities beyond current architectures) remain a significant frontier. The presence of 134 level 5 problems (16.5% of the reasoning dataset) that remain 95% unsolved indicates substantial headroom for future model development in complex reasoning domains.

To understand why the rate at which SLMs catch up is critical we need to study Groundbreaker's The Teaser Period: Why the AI Boom Is Built to Break, which starts from the analogy between the subprime crisis and the AI bubble:

Paulson & Co. laid out the arithmetic that same month in a comment letter to the FDIC: Over 80% of recent subprime originations, it observed, were two- or three-year adjustable-rate products. The average subprime borrower’s mortgage payments already consumed roughly 40% of their gross income at the teaser rate. Almost none of them could service the reset rate out of income. The crisis, in other words, was written in advance by the instruments themselves. The market looked at the reset wall and kept buying, because every participant believed the exit would arrive before the reset: home prices would keep appreciating and the borrower would refinance into a fresh teaser before the old one expired.

Groundbreaker describes the AI bubble's version of the subprime Adjustable Rate Mortgage (ARM):

The take-or-pay compute contract - the instrument at the center of the AI build-out - has a structural feature that almost no one prices: its payments do not begin at signing. They begin at delivery. A lab signs a multi-year capacity commitment today, but the payments do not start until the data center is energized, the capacity is accepted, and the contractual ramp schedule commences - an interval set not by finance, but by construction: siting, powering, and filling a gigawatt-scale campus takes 24-to-36 months from signature - mirroring the two-to-three-year teaser of a subprime ARM. More than $2.3 trillion of compute contracts now sit on the books of the four largest American cloud providers as remaining performance obligations and contracted backlog - signed, celebrated, capitalized into equity prices, and, critically, not yet billing. ... The parallel to 2006 is exact and it explains the single most-cited absurdity of this cycle: How does OpenAI, a company with some $40 billion of run-rate revenue, sign $1.4 trillion of compute commitments? The same way a household with $60,000 of income signed a $600,000 mortgage: because the terms at signing do not require the payment yet, and because everyone at the table - borrower, lender, and the market - believes the growth will arrive before the payment does.

The chart shows that, in 2027 and 2028, the AI platforms will need to shell out $852B in cash for compute, whether they use it or not. We don't know how much revenue they are currently generating, but they want us to believe it is in the region of $100B. Ignoring all their other costs, they have to increase their revenue more than 4x next year to cover their contractual payments for compute. That means they have to extract at least $400B from the enterprise market in return for supplying it with technology that is slightly better than technology companies can run in-house around an order of magnitude cheaper.

What matters isn't the relative price/performance of in-house SLMs versus remote LLMs now, it is their relative price/performance when the LLMs' contractual compute payments come due, i.e. next year. It seems very unlikely that companies already balking at the cost of the AI platforms' products by moving to Chinese models will increase their spend 4x next year. It seems equally unlikely that investors will give the AI platforms a few hundred million dollars next year to burn so as to postpone the day of reckoning by another 12 months.

The Stanford study collected data in October 2025. Developments since, with more to come, have already significantly increased the price/performance advantage of SLMs. The include:

• Nvidia's RTX Spark "superchip", disucssed by @pramodchandrayan in NVIDIA Just Put a 120-Billion-Parameter AI Model in Your Laptop. Here’s What That Actually Changes.:
  

  At Computex 2026 in Taipei on June 1st, CEO Jensen Huang announced the RTX Spark superchip — a single piece of silicon that combines a 20-core Arm CPU, a Blackwell GPU with 6,144 CUDA cores, and 128 gigabytes of unified memory, connected by NVIDIA’s NVLink chip-to-chip interconnect. The whole package delivers up to one petaflop of AI compute in a laptop form factor. The number that matters: RTX Spark can run a 120-billion-parameter language model entirely locally, with a context window of one million tokens, without a single byte leaving your machine.

  This is the guts of Nvidia's $5.2K DGX Spark desktop.
• The Exxact Valence Nvidia DGX Station discussed by Michal Malewicz in NVIDIA just killed big AI and… You’re the winner?:
  

  Here’s a $94,011.50 desktop computer for sale right now. It’s not a server rack or some crazy cloud infrastructure monstrosity. It’s a (rather big) tower PC. Kinda like the one you played Cyberpunk 2077 on. It sits under a desk and plugs into a wall like a regular desktop. The only difference is that it runs trillion-parameter AI models with no API keys, no per token payment, and no personal data leaving the room.

  It is 18 times as expensive as the DGX Spark but can run models more than 8 times bigger.
• Michael Nuñez' Perplexity partners with Nvidia to launch Portable Computer, a fully local AI agent with zero token costs:

  Perplexity is launching Portable Computer today, a version of its agentic "Computer" platform that runs entirely on hardware users already own — starting with Nvidia's DGX Spark desktop supercomputer and Linux machines equipped with Nvidia RTX GPUs. The launch, developed in close partnership with Nvidia, is one of the most aggressive attempts yet to move serious AI agent workloads off the cloud and onto local devices. The model, the user's files, and the work itself can all stay on the machine. Work completed locally consumes no billing credits, and the company says every task starts on the device by default — with the system asking permission before sending any individual step to a more powerful frontier model in the cloud.

• Apple's announcement of the latest Mac hardware, discussed by Samuel Axon in Apple’s new desktop computers are designed specifically for local AI development:
  

  Apple announced new iterations of both desktops, along with two new chips: the M6, the first 2nm chip in Apple’s M-series lineup for Macs, and the M5 Ultra, now the most powerful chip in the lineup for most things—especially AI workloads. There aren’t any major new features for either machine. This is just a specs bump. But based on how Apple is presenting these refreshes, they’re leaning hard into those use cases, which weren’t even a thought when earlier iterations were first engineered. The devices’ popularity for production inference took off after macOS 26.2 shipped last December. According to Apple’s release notes, 26.2 enabled “low-latency communication between Thunderbolt 5 hosts for use cases including distributed AI inference using MLX.” Thunderbolt 5 is a very fast wired data connection, and MLX is an open source array framework designed to help machine learning workflows take full advantage of the M-series chips’ unified memory. Since then, both hobbyists and professional developers and researchers have been essentially daisy-chaining Mac minis or Mac Studios to run inference on local large language models that are much bigger than anything that could run a single mass-market device—providing an alternative to ultra-beefy specialized hardware featuring specialized Nvidia GPUs.

• IBM's latest model release, discussed by Samuel Axon in IBM’s new Granite 4.2 models ride the wave of interest in local LLMs:
  

  IBM has rolled out the newest models in its family of open-weight large language models designed to be downloaded and self-hosted. The newly launched Granite 4.2 comes in 3B, 8B, and 30B parameter variants. Like previous versions, IBM is taking a decoder-only approach here. These new releases offer a 128,000-token context window natively. The 8B and 30B variants (not the 3B one) also go through an agentic reinforcement-learning block; they were trained for expanded capabilities like using the terminal, searching the web, or using external tools. The 3B model supports tools too, but without the same level of specialized training. Beyond those tweaks, this release is particularly notable because, as IBM itself writes, “Granite 4.2 is the reasoning-focused release of the Granite language-model family.

Consider not just what Ding et al's graph of the narrowing performance gap between closed= and open-weight models, but also what Saad-Falcon et al's Figure 7 will look like after another year of both hardware and software developments like these.

Saad-Falcon et al argue that it isn't just the raw price/performance that advantages local compute:

System-level benefits offset per-query efficiency disadvantages. While cloud accelerators demonstrate 1.4× to 7.4× higher intelligence efficiency per query, local deployment provides complementary system-level benefits that offset this disadvantage. Local inference avoids datacenter infrastructure costs, network latency, and API pricing, while enabling 88.7% of queries that local models can handle correctly to bypass cloud compute entirely. As demon- strated in Section 4.3, intelligent routing between local and cloud infrastructure can achieve 60–80% reductions in total energy, compute, and cost compared to cloud-only deployment, even when local accelerators are individually less efficient. These findings suggest that the path to efficient AI infrastructure lies not in local accelerators matching cloud efficiency, but in routing systems that leverage the complementary strengths of both paradigms: local processing for the majority of straightforward queries and cloud infrastructure for the minority requiring frontier model capabilities.

It looks increasingly as though Klement is right that the hyperscalers are toast, because the vast majority of inference will happen locally while the massive data centers will be used only for training and for inference on massive models so expensive that almost no-one can afford them.

Leverage Android skills and Gemma 4 in Android Studio Quail 4

Android Studio Quail 4 is now stable and ready for you to use in production.

This is the final stable release for Android Studio Quail. The new features in Android Studio enable you to build premium apps with AI efficiently and effectively. Check out the video below to see the most helpful new features from the last 4 releases that can help improve and speed up your development.

Here is a deep dive into what’s new in Android Studio Quail 4:

Android skills bundled into Android Studio

While LLMs are incredibly capable at generic coding queries, they frequently write incorrect or outdated code when confronted with rapidly evolving Android APIs, platform-specific migrations, or complex configuration structures. To solve this, we bundle Android skills that have been curated by the team who builds Android, directly into Android Studio. Following the open-standard agent skills specification, these are modular, AI-optimized instructions designed specifically to guide LLMs through complex Android workflows. Android skills are now pre-loaded directly into the IDE, so you can start using them without having to manually download additional files.

When you prompt the Android Studio agent, we analyze your prompt and search against the metadata for installed skills, automatically invoking them when they're most relevant. Your agent gains instant domain expertise, applying Google's best practices with less overhead spent on long, manual setup prompts.

Android Studio comes preloaded with 23 curated skills, including:

• Need help upgrading your build? You have the Android Gradle Plugin (AGP) 9 Upgrade skill.
• Want to profile your app for any performance issues? You have the Android Profiler skill.
• Ready for a Jetpack Navigation framework upgrade? You have the Navigation3 skill.
• Adapting your app UI to different Android devices? You have the Adaptive skill.

We also encourage you to create your own custom skills to extend Agent Mode with specialized experience and custom workflows for your team. And if you want to use Android skills with other command line interface (CLI) AIs outside of Android Studio, install Android CLI and run android skills add --all to quickly get started. If you ever want to disable bundled skills entirely, you can easily opt out via an IDE-wide toggle in Settings.

Gemma 4 local model integration (private, secure, and offline AI coding)

Many developers enjoy having access to local models, and Android Studio now natively integrates Gemma 4—Google’s most powerful open model—for AI code assistance without the hassle of manual third-party setup.

• System requirements: You can run the smallest models with 12GB of RAM, but machines with 32GB+ RAM will run best. Please refer to hardware requirements.
• One-click management: Simply select Gemma in the Agent model selector and then choose the model you’d like to download, or visit Settings > Tools > AI > Model Providers > Gemma. Android Studio automatically downloads, verifies, and updates the model weights for you.
• Bundled inference engine: We have bundled a lightweight inference engine to run Gemma 4 models directly in the IDE.
• On-device AI agent: Because Gemma 4 features native agentic tool-calling capabilities, you can run complex, multi-file refactoring plans with the agent completely offline. Your source code never leaves your local machine and you never hit token quota limits.

Parallel Agents UX notifications and other enhancements

In Android Studio Quail 2 we brought you agentic multitasking with parallel chats. And now Android Studio Quail 4 brings a several UI enhancements designed to make your AI interactions smoother, faster, and more transparent:

• Hyperlinked code symbols in responses: Class names, functions, methods, and file paths mentioned in agent responses are now automatically detected and rendered as clickable hyperlinks.
• Real-time background agent notifications: When multitasking with parallel chats, the Recent Chats panel now provides at-a-glance status indicators. You’ll see a loading spinner when an agent is actively running tools, a red status indicator if an agent is waiting for your input, and a blue badge when a background task has finished and is ready for review.
• Unified Summary of Changes: After the agent completes a multi-step coding task, the separate Task and Walkthrough artifacts are now consolidated into a clean, dedicated Summary of Changes tab, giving you a clear diff and review experience before applying modifications.
• Collapsible thought process rendering: For reasoning models, the agent's step-by-step thinking process is neatly organized into collapsible blocks, keeping your chat conversation easy to scan while allowing you to inspect the underlying logic on demand.

Upgrade for premium AI capabilities

Android Studio gives developers access to a default Gemini model out-of-the-box. We adjust the capabilities of this model dynamically to ensure we're able to provide a great experience at no cost. However, if you want more granular access to Gemini's most powerful models or need additional quota for long coding sessions, you can upgrade your access using one of these 3 routes:

• API Key: Use the latest Gemini models, such as Gemini 3.7 Flash, in your development flow as soon as they are available with your Google AI Studio API key. You can also use the API key from other model providers like Anthropic or OpenAI right in Android Studio
• Google AI plan: Developers with a Google AI Pro or Ultra plan can log in with their Google account to automatically unlock premium capacity and higher rate limits. With its expanded capabilities, Gemini can help you with analyzing, refactoring, and planning features across massive codebases.
• Gemini Enterprise: If your organization has access to Gemini Enterprise, Developers can log in to leverage the privacy and security benefits of Google Cloud while using the Android Studio AI agent. This is rolling to select organizations, and is currently available in the latest Android Studio Canary.

A Look Back: The Android Studio Quail Series Recap

The Android Studio Quail 4 release continues our focus on accelerating developer productivity with AI. Check out our previous blog posts to learn more about the new features that recently landed.

Android Studio Quail

• App Quality Insights Agent Integration: We kicked off the Android Studio Quail cycle by integrating App Quality Insights (AQI) with Gemini.
• Released in Android Studio Quail (Canary) at Google I/O: We introduced tools built for the agentic era, including Agent Skills, Firebase integration and parallel conversations in Agent Mode, local model support with Gemma 4, Android CLI, peer-to-peer Android Emulator multi-device testing, ADB Wi-Fi 2.0, and native Google Play testing track publishing.

Android Studio Quail 2

• Parallel Chats: We unlocked concurrent multitasking in the IDE. Developers can open multiple chats as side-by-side Editor Tabs—running a Compose refactor in one tab using Gemini 3.5 Flash while documenting code in a second tab with Gemma 4 in parallel. Active background tasks are easily monitored via real-time progress indicators (loading spinners, paused statuses, and errors) in the Recent Chats sidebar.
• LeakCanary Profiling: We natively integrated LeakCanary directly into the Android Studio Profiler. By lifting and shifting JVM heap analysis off the test device and running the Shark analyzer engine on your host computer, memory leak tracing became five times faster and completely jank-free, backed by "Fix with Agent" AI remediations.

Android Studio Quail 3

• Simplified Planning Mode: When using the /plan command or switching your conversation to "Planning," the agent steps back to evaluate its logic, mapping out an implementation plan before writing code.
• MCP Marketplace: Navigating to Settings > Tools > AI > MCP Servers now lets you easily search, install, and manage Model Context Protocol (MCP) servers straight from the IDE, allowing you to connect your AI agent to external developer tools, registries, and custom databases.

Get Started Today

Android Studio Quail 4 is now available in the stable channel. Ditch the manual configuration, multitask across parallel threads, and build with expert-grounded AI intelligence.

Download Android Studio Quail 4 Stable Today

As always, your feedback shapes the future of Android development. Please check out known issues or file bug reports and feature requests directly on our official bug tracker.

You can also join our vibrant developer community and stay up-to-date with the latest insights by following us on Instagram, LinkedIn, YouTube, or X. We can't wait to see what you build!

Kubernetes v1.37: Storage Version Migration Enabled by Default

I am excited that storage version migration (SVM) has graduated to General Availability (GA) in Kubernetes v1.37!

After a number of releases of work and testing, the built-in StorageVersionMigration API (storagemigration.k8s.io/v1) and control plane controller are now fully stable and enabled by default across all v1.37 Kubernetes clusters.

The problem with stale storage versions

In Kubernetes, stored API resources are written using a specific storage version (schema representation). The way Kubernetes interacts with object storage fundamentally requires mutation of a resource in order to ensure that the latest storage version is used for all resources. This creates problems when you want to change the storage version of a resource.

One example of a scenario where you may want to change the storage version of a resource is when you are promoting a CRD to drop an older API version (such as v1alpha1) to a newer version (leaving just v1beta1 and v1). It's a problem to drop the older API version whilst there are still resources stored with the old alpha version.

To avoid problems, you designate v1 as the new storage version; but, on it's own, that's not enough. While new writes are stored as v1, any existing resource could remain stored as v1alpha1 or v1beta1 in storage. You cannot safely remove v1alpha1 from the CRD's .status.storedVersions or drop serving support until every single resource in storage has been re-written to not be serialized and stored with the alpha version.

Another relevant example is encryption at rest and, related, key rotation. When you configure encryption at rest or rotate encryption keys, existing resources in storage remain unencrypted (or encrypted under old keys) until they are actively re-written through the Kubernetes API server.

Historically, cluster administrators and CRD authors had to rely on manual kubectl get / kubectl replace scripts, or to deploy the out-of-tree kube-storage-version-migrator component to force re-writes. These approaches were often tedious, error-prone, and difficult to monitor.

How storage version migration works

Initiating a storage version migration is as simple as creating a declarative StorageVersionMigration object. The built-in StorageVersionMigrator controller in the Kubernetes control plane watches for these objects, and automatically migrates existing resources to the default storage version for that API.

Example: Migrating a custom resource API

Suppose you have updated a CustomResourceDefinition (crontabs.example.com) to use v1 as its storage version. To migrate all existing stored resources off older versions, create a StorageVersionMigration:

apiVersion: storagemigration.k8s.io/v1
kind: StorageVersionMigration
metadata:
  name: crontabs-migration
spec:
  resource:
    group: example.com
    resource: crontabs

Apply the manifest using kubectl:

kubectl apply -f crontabs-migration.yaml

Monitoring and verifying migrations

The StorageVersionMigrator controller updates the status of the StorageVersionMigration object as migration progresses. You can inspect the migration status using kubectl:

kubectl get storageversionmigration.storagemigration.k8s.io/crontabs-migration -o yaml

A successful migration will report a Succeeded condition set to True:

status:
  conditions:
    - type: Running
      status: "False"
      lastUpdateTime: "2026-08-02T10:05:00Z"
      reason: StorageVersionMigrationInProgress
    - type: Succeeded
      status: "True"
      lastUpdateTime: "2026-08-02T10:05:00Z"
      reason: StorageVersionMigrationSucceeded

Once the migration has succeeded, you can be confident that all instances of the resource in storage are stored in the current storage version. For CRDs, the stored version should be updated in the CRD's .status.storedVersions to only contain the preferred version. If the .status.storedVersions is not updated following a successful migration then that means that the CRD was updated during the migration. In that case, the migration should be retried in order to safely deprecate an older storage version.

Including migrations in your CRD manifests

Because StorageVersionMigration is a standard declarative Kubernetes API, CRD authors can bundle or trigger migrations directly alongside CRD upgrades. For example, you can include the migration in the same manifest as your updated CustomResourceDefinition:

apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
  name: crontabs.example.com
spec:
  group: example.com
  # Updated versions list where v1 has storage: true
  ...
---
apiVersion: storagemigration.k8s.io/v1
kind: StorageVersionMigration
metadata:
  name: crontabs-migration
spec:
  resource:
    group: example.com
    resource: crontabs

What's next?

• Learn more about the concepts behind Storage Versions.
• Read the step-by-step task guide: Migrate Kubernetes Objects Using Storage Version Migration.

SIG API Machinery would love to hear your feedback as you adopt built-in Storage Version Migration in your clusters. Reach out to us on the #sig-api-machinery Slack channel or participate in our community discussions!

AI agents comprise models, instructions, data, and tools, so thoroughly investigating potential security risks requires evidence from several components. As Datadog teams build AI agents for internal workflows, we use Datadog AI Guard to monitor how they handle each component during a session. We’ve found that application logs may capture an agent’s final API call without showing which prompt, retrieved content, or tool result led to the action. For adequate security monitoring, we needed data that connected the final action with the entirety of an agent’s session.

To understand what led to an agent’s final action, we expanded monitoring to include an inventory of its components and telemetry data across the full execution path. This approach enabled us to track access to sensitive data, record human and agent identities separately, and look for atypical sequences of behavior within a session.

In this post, we’ll explain what we observed at each layer and which telemetry data was most useful for monitoring agent activity. We’ll also look at Datadog Security Labs research and findings from our State of AI Engineering report to provide additional context on related risks and AI engineering trends.

What telemetry data should you collect for AI agent security?

When deciding what telemetry data to collect for security monitoring, teams should be able to identify the components that shape the agent’s behavior and account for how it reaches an action. They also need to attribute the action to the appropriate human or agent identity and prevent dangerous calls before they reach the requested resource.

The following diagram maps these monitoring layers to a single agent session:

OpenAI’s July 2026 Hugging Face incident illustrates why investigations may need to correlate agent activity with identity and infrastructure telemetry data. During that incident, agents operating with reduced safeguards compromised parts of OpenAI’s research infrastructure and Hugging Face’s systems, and an alert on unusual identity-related API calls prompted the investigation that linked those events.

The following practices can help teams build that visibility and apply controls across each layer of an agent workflow in their environments:

• Inventory the full agent system: Record ownership and the exact model version, then map the tools, connected services, and provider traffic. Teams should also account for agents that contact model providers without using an approved gateway.
• Classify sensitive data throughout the session: Record where each match occurred, where the data went, and which data class the match represents.
• Apply controls based on exposure: Prioritize agents that interact with customers, access sensitive data, or change systems. In addition, evaluate agents that use an LLM to judge stored output separately so that text resembling prompt injection doesn’t create unnecessary alerts.
• Trace and attribute agent actions: Preserve the path from the initial request through tool calls and downstream behavior, along with the human and agent identities involved.
• Detect meaningful sequences: Connect attempted exfiltration or prompt injection matches with sensitive tool output and later actions. For example, changes in cost, token usage, or model activity can add context when the combined behavior crosses a security boundary.

Start with an inventory that includes more than models

Before teams can decide where monitoring and guardrails are needed, they need to know which agents are operating in their environment and what each one can do. When we compared AI Guard activity with the information cataloged for each agent, we found that the model was only part of what an AI agent inventory needed to capture. The framework and system prompt guided the agent’s responses, while its tools and connected services determined which resources it could access and which actions it could take.

Model sprawl creates another inventory challenge because teams may need to track several models and versions in the same environment. More than 70% of organizations now use three or more models, and the share using more than six models has nearly doubled over the past year. Adding to this is the fact that teams tend to keep older models in production after adopting new ones. Because each model version can respond differently to the same prompt, tool definition, or guardrail, teams should record the exact model and version that agents use.

To capture the full session, we began treating the agent inventory as an AI bill of materials (AI-BOM) that maps ownership to the components connected to an agent. At minimum, it should identify the exact model, the tools the agent can call, and the services it can reach. Teams also need to record component provenance so they know whether it came from an approved source, a public marketplace, or a repository the agent accessed.

External incidents show why an AI-BOM needs to record gateways and other dependencies, including their versions. For example, LiteLLM can act as a proxy between AI applications and model providers. In March 2026, attackers published malicious versions 1.82.7 and 1.82.8 of LiteLLM on PyPI as part of the TeamPCP supply chain campaign. Because the compromise affected the proxy package rather than a model or provider, a model inventory alone wouldn’t have shown which AI applications depended on the affected versions. Recording LiteLLM in the AI-BOM would have helped teams identify those applications and investigate whether the malicious package executed.

A more complete AI-BOM depends on knowing what to record, so we used AI Guard Discovery to identify AI applications that were operating outside of approved infrastructure. For example, we found agents and other LLM applications that sent requests directly to providers such as OpenAI instead of passing through an AI gateway. An inventory based only on gateway traffic would have missed those applications.

Monitor AI agent prompts and tool execution together

An inventory shows what an agent can access and which actions it can take, but it doesn’t explain how the agent used those components during a session. We also needed to connect prompts with retrieved content, model responses, and tool calls so we could investigate the path from a request to an action.

Prompt injections are often framed as malicious user messages, but tracing the session can also surface injected instructions that arrived through retrieved documents, tool results, or files in a trusted workspace. By the time these instructions reach the model, the agent may already have run part of the workflow.

This risk appeared in a Datadog Security Labs analysis of a malicious Claude Code skill found in the wild, which researchers reproduced in a controlled test. The skill used dynamic context commands to run gh auth token and send the result to a destination controlled by the attacker during preprocessing, before the rendered skill reached the model. The model later refused to run the skill, but the credential was already exposed because the prompt injection defenses in the model could not evaluate the commands before they ran.

The controlled test showed the limits of monitoring model inputs and outputs. Those records capture only two events in a longer execution path and can miss commands that run before the model receives the rendered prompt. To understand the risk, teams need to connect the user or system request with the model response, downstream tool activity, and the policies that allowed it to begin with.

Custom agents can create a related risk when an ordinary request leads to a tool call that reaches sensitive data. Consider an attack targeting a customer support agent that can look up account information and issue refunds. The attacker asks the agent to retrieve payment information for a customer, and the agent prepares a call to the customer records tool. Evaluating the prompt and tool call together creates a checkpoint to identify the attempted data exfiltration and block the call before the tool returns the information. Checkpoints like these can stop a risky request earlier in the path, but even if the request passes it, the receiving service should still enforce its own authorization policy as an extra layer of security.

Prioritize agents and tool calls based on exposure

When we reviewed AI Guard traces from our agents, we found that exposure depended on where an agent received input and what it could do with that input. We prioritized guardrails for chat agents that interacted with customers because they accepted outside input and could act on behalf of users.

Agents that used an LLM to judge output required a different policy because they reviewed stored conversations without interacting directly with customers. For example, an agent that scored whether another agent followed its instructions could process a conversation containing text that told it to ignore its rubric and approve an unsafe response. Although that text could influence the score, the judge wouldn’t be able to call tools or act on the user’s behalf, so we evaluated these agents separately from chat agents.

After grouping agents by their exposure, we evaluated individual tool calls based on their potential effect. For example, an agent reading public documentation doesn’t require the same controls as one changing infrastructure or sending data to an external service. To mitigate risk, sandboxing and authorization can help limit the agent to the tools and resources it needs, while teams can require human approval for actions with significant consequences.

Track sensitive data across AI agent workflows

Sensitive data can enter an agent’s session through prompts, retrieved content, or tool responses and then reappear in model outputs or downstream tool calls. Tracking that path helps teams determine where the data came from and whether it reached another system.

In the traces that we reviewed for our agents, sensitive data surfaced in prompt inputs and assistant outputs, including email addresses and other forms of personally identifiable information (PII). But agents can also assemble context from system prompts, retrieval-augmented generation (RAG) results, and tool outputs.

Findings from our 2026 State of AI Engineering report show how much context agents are processing per request. Average tokens per request more than doubled for median customers and quadrupled for customers in the 90th percentile over the previous year. System prompts accounted for 69% of all input tokens in the traces that Datadog analyzed for the report. These datapoints don’t show whether that context contains sensitive data, but they help quantify how much content teams may need to evaluate for sensitive data within each request.

Where sensitive data appears and where it is headed should also determine whether it is redacted. Credentials, for example, should generally be masked before they appear in an assistant response, but an agent may need to pass a credential to an authorized tool when the task requires it. Teams should also define which data classes an agent is expected to process, which destinations may receive them, and where values must be masked or replaced. That context can help guardrails distinguish sensitive data that an agent is expected to process from a request that sends it to an unauthorized destination. For example, an LLM judge that reviews incident summaries may legitimately encounter security information that would be unexpected in another workflow.

Keep the human and agent identities distinct

Agent actions become difficult to investigate when an agent uses a developer’s credentials or a shared service account. A downstream service may show that an engineer’s token accessed customer data without indicating whether the engineer issued the request directly or an agent acted during their session. The same attribution problem can begin before a developer sends the first prompt. Datadog Security Labs found that project-controlled configuration could cause coding agents to run repository-controlled code before the developer sent a prompt or approved a shell command. If that code can access and use credentials available in the developer’s environment, downstream records may erroneously attribute its activity to the developer.

Preserving attribution requires traces that connect the human or service that initiated the work, the agent that requested the downstream action, and the principal authenticated by the receiving service. That record helps teams separate who started the session from which agent requested the downstream action.

Build detections around behavior instead of isolated events

An individual agent event may show a suspicious prompt or sensitive tool output without explaining how those events relate. We built detections that connected activity within the same session so responders could evaluate the path from a request to what the agent accessed or did next.

One detection pattern that we used connected a prompt flagged for attempted data exfiltration with sensitive tool output in the same session. We focused this detection on credentials and select forms of PII because matches to data such as a general email address could reflect routine agent behavior. The resulting sequence gave responders a possible exfiltration path to investigate, but it didn’t prove that data left the environment. Responders would still need another event showing that an agent’s response exposed the value or that a network request or later action sent it to an unauthorized destination.

Our review also revealed that anomalies are more useful when we interpret them within the context of an agent’s typical behavior. Teams can compare sequences of agent events (such as prompts and tool calls) with the agent’s baseline to identify statistical anomalies that may warrant investigation. Because these deviations don’t show on their own that a security boundary was crossed, teams should treat them as investigation leads instead of evidence of malicious activity. The same principle applies to operational anomalies. For example, unexpected token or cost growth can support an investigation, but without a related policy violation or risky action, increases like these shouldn’t trigger a security alert solely because an agent was involved.

Both sequence-based detections and behavioral analysis depend on traces that preserve the path from the initial prompt through tool calls, policy decisions, and downstream actions. Teams can then correlate the trace with identity and cloud audit logs when the agent’s action leaves the application.

Strengthen security for agents from the first model call

Using AI Guard to monitor and help protect our agents at Datadog revelead that teams need to trace how a prompt leads to an action and to place controls along that path. Inline guardrails can help block unsafe prompts or tool calls before they reach downstream systems, while appropriately scoped permissions limit what an agent can do if a request passes those checks. The surrounding trace then gives engineers and security analysts the context they need to investigate blocked requests and detection signals.

In an instrumented agent workflow, AI Guard evaluates prompts, responses, and tool calls in real time. It can also help teams block unsafe prompts or tool calls based on policy and connect each decision to the surrounding trace.

If you are building custom or coding agents, read the AI Guard documentation to learn how to monitor and help protect their runtime activity.

If you don’t already have a Datadog account, you can sign up for a free 14-day trial.

Amazon EC2 R9g and R9gd instances powered by AWS Graviton5 processors are now generally available

Today, Amazon EC2 R9g and R9gd instances are generally available, powered by AWS Graviton5 processors. R9g instances are memory-optimized and deliver up to 25% better compute performance compared to Graviton4-based R8g instances, powered by the most energy efficient processor AWS has ever built.

R9g instances are ideal for memory-intensive workloads including databases, in-memory caches (Valkey, Redis, MemCached), real-time big data analytics, Linux-based workloads including containerized and micro-service-based applications (e.g. Kubernetes, Docker, EKS, ECS), as well as applications written in popular programming languages such as C/C++, Rust, Go, Java, Python, .NET Core, Node.js, Ruby, and PHP.

R9gd instances include local NVMe-based SSD block-level storage, ideal for memory-intensive workloads requiring fast, low-latency local storage such as open-source databases, distributed real-time big data analytics, large in-memory databases, and large caching workloads.

If you’re running workloads on R8g instances today, R9g gives you more performance per vCPU with faster memory, higher network and Amazon EBS bandwidth, and a larger L3 cache, all while using less energy.

What makes R9g different
Graviton5 processors bring several hardware improvements over Graviton4:

• Up to 25% higher compute performance per vCPU
• DDR5 8800 MT/s memory (up from 5600 MT/s in Graviton4), the fastest memory available in the cloud
• 5x larger L3 cache for better data locality
• Up to 2x higher network and EBS bandwidth for the largest instance sizes (up to 100 Gbps network, up to 72 Gbps EBS on the 48xlarge)
• Up to 3x higher packet-processing performance

R9g and R9gd instances support Instance Bandwidth Configuration (IBC), which lets you adjust the allocation of bandwidth between Amazon EBS and Amazon VPC networking by 25%. This helps optimize performance for workloads with specific bandwidth requirements such as databases and caching.

All R9g and R9gd instances run on the AWS Nitro System, which offloads virtualization, storage, and networking to dedicated hardware. This gives your applications near-bare-metal performance while maintaining strong security isolation between instances.

R9g and R9gd instances feature the Nitro Isolation Engine (NIE), the same enhancement to the Nitro System introduced with C9g and M9g instances earlier this year, which enforces isolation of instances and harnesses formal verification to provide assurances of isolation with mathematical precision. Nitro Isolation Engine is a purpose-built component that is responsible for enforcing isolation between virtual machines, including mediation of all access to virtual machine memory, CPU register state, and I/O devices through a minimal set of APIs. Nitro Isolation Engine leverages formal verification, a technique to mathematically demonstrate that the hardware or software behaves as intended, and not just in specific test cases. This intensive verification technique establishes Nitro as the first formally verified cloud hypervisor, pioneering a new standard for mathematically proven cloud security.

EC2 R9g and R9gd instance specifications
R9g and R9gd instances are each available in 11 sizes, from medium to metal-48xl. The following tables show the full specifications for each size.

R9gd instances offer the same compute and networking performance as R9g, with the addition of local NVMe-based SSD storage for workloads that need fast, low-latency scratch space or temporary caches.

Getting started
You can launch R9g and R9gd instances from the Amazon EC2 console using any supported Arm-based AMI. R9g instances support Amazon Linux 2023, Amazon Linux 2, Ubuntu 22.04+, RHEL 8.4+, SUSE Linux Enterprise Server 15 SP3+, Debian 12+, and other major Linux distributions.

If you’re migrating from R8g, no code changes are required for most applications. Select the equivalent R9g instance size and your application runs with better performance. For containerized workloads, R9g works with Amazon EKS, Amazon ECS, and standard Kubernetes deployments. Multi-arch container images built for Arm64 run without changes.

Several resources help you get started: the AWS Graviton Getting Started Guide covers how to build, run, and optimize workloads on Graviton-based instances. The Graviton Savings Dashboard helps you track cost savings. AWS Transform automates code transformations for migrating Java applications from x86 to Graviton.

Pricing and availability
Amazon EC2 R9g and R9gd instances are available in US East (N. Virginia, Ohio), US West (Oregon), and Europe (Frankfurt) Regions.

R9g and R9gd instances are available for purchase through Savings Plans, On-Demand, Spot Instances, Dedicated Instances, or Dedicated Hosts.

OpenAI, the company behind ChatGPT, announced late Friday that it is ending its partnership with Cursor, cutting off the coding tool’s access to its models on November 12. The move comes two weeks after SpaceX completed its $60 billion acquisition of Cursor’s parent company, Anysphere, folding the popular AI coding assistant into Elon Musk’s growing SpaceXAI division.

In a post on its website, OpenAI said the decision came down to trust, not technology. “We cannot be confident that SpaceX will use our technology within our terms of service, based on our experience with Elon Musk’s companies violating contracts,” the company wrote. OpenAI pointed to two specific incidents: X, now part of SpaceX, allegedly breaking the terms of an existing OpenAI contract after Musk bought Twitter.

That lawsuit is the backdrop for all of this. Musk cofounded OpenAI in 2015, left the board in 2018, and sued Sam Altman and Greg Brockman in 2024, arguing they abandoned the company’s nonprofit mission for profit. A federal jury sided with OpenAI in May, finding Musk waited too long to sue rather than ruling on the merits of his claims. Musk said at the time he would appeal to the Ninth Circuit, calling the outcome a “calendar technicality” rather than a real judgment.

Elon Musk breaks silence on OpenAI trial decision

SpaceX’s interest in Cursor predates that verdict by weeks. The company first struck a deal with Cursor in April, securing an option to acquire it for $60 billion or pay $10 billion for joint development work instead. As Teslarati reported at the time, the logic was straightforward: Cursor was paying retail prices to Anthropic and OpenAI, two of its most direct competitors, every time a developer used its product, while SpaceX had idle capacity on its Colossus supercomputer, roughly the equivalent of a million Nvidia H100 GPUs, that Cursor could use to train its own models instead. SpaceX exercised the option in June, days after its own IPO, and the deal closed in mid-August.

Once it closed, Musk moved fast. On an all-hands call with more than 1,000 Cursor employees, he reportedly told staff that SpaceXAI’s Grok was playing catchup in the AI race, unlike Tesla and SpaceX in their own markets, and singled out Anthropic as the company to catch. Cursor CEO Michael Truell now reports directly to Musk inside SpaceXAI.

Elon Musk admits he was ‘clearly wrong’ about Anthropic

Losing OpenAI’s models leaves Cursor leaning harder on Anthropic’s Claude, which has its own compute agreement with SpaceX, and on Cursor’s in-house Composer model, the one SpaceX’s compute was supposed to accelerate in the first place. OpenAI framed the November deadline as maximum notice under its contract, and said it wants to “go above and beyond” to help developers through the transition. Whether Anthropic makes the same call is now the open question in AI coding.

World models generate, reconstruct, and simulate any possible world. They understand how worlds appear, behave, and evolve so that we can render imagined worlds for creative users, simulate the real world in high fidelity, and help robots plan actions. At World Labs, we build these general purpose world models in pursuit of spatial intelligence.

Today we are introducing Atlas, our next-generation world model. Atlas is an omni model that we pretrained from scratch to natively operate on text, images, video, and 3D. It is a multimodal autoregressive diffusion transformer: all inputs are combined into a shared spatial context. Atlas uses that context to generate what comes next, staying consistent in 3D with everything it has seen and imagining what lies beyond it. Atlas is built to scale: its performance improves with increased training compute, and we expect this trend to hold as we continue scaling.

Atlas can perform a broad range of tasks spanning world generation, reconstruction, and simulation:

• Camera-Controlled Generation: Atlas generates images and videos from one or more images with pixel-perfect camera control, outputting up to 1 minute of video at 1440p.
• Spatial Reconstruction: Atlas reconstructs real world scenes from one to dozens of input images. It generates both image frames from novel views and explicit 3D outputs, outperforming state-of-the-art models specialized for 3D reconstruction.
• Space-Time Simulation: Atlas models space and time from input videos, reframing videos for dramatic visual effects and enabling Real-to-Sim workflows for robotics.
• Image Generation: Atlas generates images and 360 panoramas from text; it can follow complex prompts, render text, and generate a wide variety of visual styles.

Atlas will power future versions of Marble and other products from World Labs.

Camera-Controlled Generation

Atlas takes one or more reference images and generates new views at any camera position and angle you specify. Generated views match the content and geometry of the input images, smoothly extrapolating beyond them to imagine parts of the scene not visible in the inputs.

Atlas handles a broad range of scene types, visual styles, and camera motions.

Pixel-Perfect Camera Control

Atlas uses precise camera geometry as a native input type, going beyond coarse text-based instructions for camera control. This lets you frame every shot and control every motion.

In the examples here, Atlas generates a complete scene from a single input image. It uses the content of the input image along with its broad world knowledge to imagine what the scene should look like from new angles. For example, it generates the back side of the robot, and it guesses that there should be a grassy lawn next to the pool.

Generating with Spatial Context

Similar to an LLM, Atlas first encodes its inputs into a context, then generates outputs conditioned on the context. However, Atlas is unique because each image is grounded at a 3D position in space; this forms a spatial context.

Managing this spatial context unlocks entirely new kinds of creative control. For example, you can place two unrelated reference images in the context and position them in 3D space; Atlas then generates a world that smoothly interpolates between them.

These examples demonstrate the model's world knowledge and creativity; it imagines doorways, hallways, nooks, and other transitions between otherwise unrelated image pairs.

Controllable Long Videos

Atlas lets you generate long videos with precise control by combining camera movement and spatial context management. You design every scene and every camera angle. This puts you in the director's chair: you are staging the scene, not pulling the lever of a slot machine.

In the example below, we generate a 1 minute video at 1440p resolution using a small number of reference images. We hand-design a camera path through the scene, and Atlas generates a coherent world.

Spatial Reconstruction

Atlas reconstructs real-world spaces from one or more input images. It does not require special capture equipment or hundreds of dense views to faithfully reconstruct objects and scenes. We believe Atlas is a major step forward toward solving the problem of novel view synthesis from sparse input images, a decades-old fundamental problem in 3D computer vision.

Reconstructing from Multiple Images

Atlas can take a variable number of input views of a scene. When parts of the world are not visible in the input views, Atlas imagines a plausible way to fill in the gaps by drawing from its rich world knowledge.

But sometimes you do not want imagination; you might want an exact reconstruction of a real-world location. Passing more input images gives Atlas more context: the more it sees, the less it imagines. Atlas typically gives faithful reconstructions with as few as two or three images, outperforming state-of-the-art results by models specially trained only for 3D reconstruction. However, Atlas can also make use of over a hundred input images in its spatial context, allowing for faithful recreation of real world environments.

Reconstructing Diverse Paths

Atlas can generate many different trajectories through the same scene, giving new perspectives on the same input images. No matter how many times you change the camera path, the scene stays consistent.

Explicit 3D Outputs

In the results above you have seen Atlas output 2D images and videos, which are sufficient for some applications. But workflows in robotics, gaming, design, VFX, and beyond often require explicit 3D outputs. Atlas natively operates on both 2D image frames and 3D depth maps, enabling it to output worlds as point clouds or 3D Gaussian splats.

From a single input image, Atlas produces a full 3D world by jointly generating new views and estimating their geometry. From a video of a real space, it predicts the depth of every frame and combines them into a 3D reconstruction. In either case, Atlas fills in regions that no camera ever saw.

Point clouds estimate a scene's geometry, but 3D Gaussian splats make it usable. Atlas fills the remaining gaps and turns the point cloud into a complete splat scene that renders on-device at high resolution and frame rates.

Space-Time Simulation

Atlas serves as a world simulator. It understands both the spatial structure of the world and how the world evolves over time. Combining its spatial and temporal abilities leads to new applications for VFX, robotics, and beyond.

Reframing Video

Atlas turns a handful of ordinary cameras into a "bullet time" multiview capture studio. With footage from as few as three cameras, Atlas can freeze time and reframe shots, letting you view events from impossible angles.

Notably, these shots did not require professional photographers or specialized equipment. Each of them was filmed by a few engineers and researchers with ordinary cell phones on tripods and clamps that fit in a backpack. Atlas reconstructs the scene from three to five camera views, after which you can reframe shots however you like.

Robotics Simulation

Atlas opens up new ways to scale Real-to-Sim for both navigation and manipulation.

You have already seen Atlas reconstruct a space in explicit 3D from a few images. For robotics, reconstruction is only half the job: as a simulated robot moves through space, Atlas also generates the RGB and depth data its sensors would observe along the way. The world and the robot's view of it come from the same model.

Robotic manipulation goes a step further. From a few casual recordings, Atlas aids in building a simulation that also captures how objects move and interact. Once a task is simulated, you can vary it easily: change the objects, their positions, the robot's motion, the lighting, and the background. The result is diverse training data and testing environments for robotics at scale.

Image Generation

The primary focus of Atlas is world modeling, and every image is a window to a possible world. Though image generation is not its primary focus, Atlas is a capable image generator: it follows complex prompts, renders text, and generates a wide variety of visual styles.

Atlas also generates 360 images from text or image prompts, where again it can generate a wide variety of scene types and visual styles.

Technical Details

Model Architecture

Atlas is an omni model designed to handle many tasks and many kinds of input and output data in a single unified architecture, putting spatial control at the heart of the model. These goals require us to depart from standard architectures used by both LLMs and video models, and design a new base architecture to serve as the foundation of future world models.

Atlas is a multimodal autoregressive diffusion transformer. It operates on multimodal sequences, generating each new element of the sequence one at a time. These architectural properties work together to achieve our goals, and taken together they enable a new paradigm of generation based on a spatial context. We unpack these ideas in turn:

• Multimodal: Atlas can natively process many different data types. At present it can operate on text, images, camera poses, and 3D depth maps; videos are represented as sequences of images. Each image and depth map is conditioned on an explicit camera pose, making spatial control a central component of the architecture.
• Autoregressive: Atlas operates on sequences of elements, where each element is one of the multimodal data types above. Each output is generated one at a time, conditioned on earlier parts of the sequence. This flexible design naturally adapts to a wide variety of tasks: each task is just a different kind of sequence, where inputs are followed by outputs.
• Diffusion: Atlas is a rectified flow model that generates outputs by gradually denoising them. Diffusion models excel at modeling high-dimensional continuous data like images and video, and can naturally trade off speed and quality by varying the number of denoising steps used during inference.
• Transformer: The transformer architecture consists primarily of large matrix multiply operations and is well-adapted to modern hardware. It is a robust backbone for world modeling.

Like an LLM, it is an autoregressive transformer, so it can take advantage of innovations used to serve and accelerate LLMs including KV-caching, cache-aware routing, disaggregated serving, and more. Like a modern image or video model, it is a latent diffusion model and can make use of algorithms such as diffusion distillation, classifier-free guidance, shifted noise schedules, and advances in VAE design.

Benchmarks

Atlas is an omni model for world modeling that performs many tasks. There is thus no single benchmark that fully captures its generality. We highlight quantitative evaluations of Atlas on two key tasks: camera-conditioned generation and 3D reconstruction. On both tasks it outperforms more specialized models.

We compare against a selection of top-performing video models for camera-conditioned generation. In each trial, we pair a single input image with a sequence of one to three cinematic camera motions (pan, truck, crane, etc.). Third-party human raters judge which model better follows the intended camera path. These results confirm that Atlas outperforms recent video models at camera-controlled generation, and this advantage grows as camera trajectories become more complex.

We additionally evaluate Atlas on the task of 3D reconstruction from sparse input views. Despite its generality, Atlas outperforms the best specialized open-source reconstruction models.

Model Scaling

Most progress in modern AI has been driven by scaling. Models improve in large part by scaling up simple algorithms to make use of more data and compute.

We see strong evidence that Atlas will continue to improve with scale. We pretrained Atlas from scratch on a large diverse corpus of multimodal data. Over the course of development, we trained a series of models of increasing size and training compute, and found that each new level of compute unlocked new model capabilities. We are confident that our future world models will follow this trend, dramatically improving their capabilities as we continue to scale.

Build with Atlas

Atlas is entering early access with select partners. If you would like to build with it, request access below and we will reach out. We are excited to see what you build, and to work with you to make Atlas the go-to world model for generating, reconstructing, and simulating any world.

We are also hiring across research and engineering to advance spatial intelligence.

This post was produced by the World Labs team.

@article{worldlabs2026atlas,
    author = {World Labs Team},
    title = {Atlas: A World Model for Spatial Intelligence},
    journal = {World Labs Blog},
    year = {2026},
    note = {https://www.worldlabs.ai/blog/atlas},
}

Iteration velocity is now set by how quickly you can provision the computer your app or agent needs.

Workloads differ in how long they run, how much memory they take, and how much of the environment they control. That previously meant a different compute primitive for each job, so product iterations required provisioning infrastructure, not just working on a feature.

We built Vercel so that none of this has to be your problem. The compute layer is a single system with a simple job. Take any workload, assemble the machine it needs, swap configuration on the fly, and absorb burst capacity in real time.

We call this Fluid.

Builds ran on it first, then sandboxes, and now functions. If you've shipped on Vercel, you've been on Fluid without knowing it.

Fluid compute now runs over 15 million builds a day, 25 million sandboxes a week, and a trillion requests a month.

A history of compute

Changing a machine used to mean changing it by hand. You went down to the computer store, bought a hard drive or a stick of RAM, and swapped it in yourself.

Then you could rent bare metal when you needed it, and use it to serve a website, host a database, or send email.

Then the cloud let you request a machine in any configuration you wanted, choose its operating system, use it, and throw it away when you were done.

For agents, even the cloud is too slow. A standard VM can't provision fast enough to keep up with how they work, but this is where Fluid excels.

How a workload runs on Fluid

When a workload comes in, Fluid assembles a machine to fit its shape. If an agent needs to run code, Hive provides an isolated VM, usually one already warm, so it's ready instantly. Your own image boots on top as the environment. A Drive connects, and your files are right where you left them, because storage was never tied to the machine.

Each workload needs something different. A build is compute-bound, so it wants a beefy machine, heavy on CPU and memory. A function is IO-bound, loading specific code to run the instant a request lands, usually on a small VM. A sandbox is flexibility-bound, taking whatever configuration the work calls for with a Drive attached for user data.

Fluid compute is the execution model that all of this leans on. Many requests run on one instance, instead of each spinning up its own. Work starts immediately, and with Active CPU pricing, you pay for CPU only while your code is working, not while it waits on a database or a model.

Hive

Hive is the "hardware." We built it to control our own compute. It provisions the isolated machines every workload runs on. It picks the right machine for the job, keeps each one isolated in our multitenant environment, and does it at global scale. Hive gives every product one control-plane API, so our teams build on the same foundation instead of each maintaining their own.

Fluid images

Fluid images is the environment. Until now the OS was fixed. You ran the one the cloud gave you, not the one you chose. Now you push your own image to Vercel Container Registry, and run it across sandboxes and functions. In the background, Vercel converts images into a Fluid image in a format we call VHS (Vercel Hive Snapshot), the optimized boot format behind Dockerfile deploys and sandbox custom images, so it can resume rather than boot and a custom machine is ready in milliseconds. It uses the same technology behind Sandbox Snapshots, so optimizations in one product carry to the rest. v0 already uses it to build and run its own development environments.

Vercel Drives

Vercel Drives is the storage. Your files live in portable, durable storage that travels with the workload instead of being stranded on one machine's disk. Storage that outlives the compute attached to it is what makes the rest of the system work. Drives aren't bound to a single machine, you can swap the compute underneath it and pick up exactly where you left off in the next session. Drives attach to sandboxes today, in private beta, and extend to the rest of Fluid from there.

One system underneath

These are different shapes of the same system, not separate platforms. Because it's one compute layer underneath every product, a gain in boot time, isolation, scheduling, or caching lands across functions, sandboxes, and builds at once, instead of being rebuilt three times. New shapes of compute can be added without rebuilding the foundation. You don't end up with separate primitives that drift apart.

And it's real, not a diagram: Hive provisions a full VM in milliseconds and brings your filesystem state along with it, so you get isolation stronger than an isolate or a container, without paying for it in startup time.

The agent workload

For an agent to move fast, it needs the right machine, and it needs it immediately. The faster the machine assembles, the faster the agent works.

An agent runs untrusted code, so the machine needs a secure boundary. It brings its own tools, so the machine needs its own environment. And because an agent spins up and tears down constantly, its state has to outlive the compute. Fluid assembles that machine immediately, and then a fresh one for the next task.

For years, the machine was a fixed thing, and you fit your work to it.

In Fluid you describe the work, and the machine forms around it.

In the AI industry, we borrowed the term “efficient frontier” from economists. We use it to talk about managing tradeoffs, most often the tradeoff between cost and capabilities for models. A model is a “frontier model” if it offers the highest degree of intelligence at a given cost or size.

We also have efficient frontiers in inference engineering. Most often, this is expressed as a tradeoff between latency and throughput (which determines cost), though we can also exchange quality for throughput (via quantization, distillation, and pruning) or intelligence for speed (in the form of reasoning level).

There are two types of techniques available to inference engineers:

1. Techniques which make a tradeoff between two factors to move a deployment along an efficient frontier.
2. Techniques which push out the entire frontier for a given deployment, creating more overall efficiency which can be allocated to whatever outcome is most beneficial.

Both types of techniques are valuable.

It’s useful to be able to target any point along an efficient frontier by making tradeoffs. Giving up per-user speed makes it possible to build high-throughput, low-cost pipelines for batch workloads. Sacrificing throughput to improve speed makes sense when latency-sensitive users have a high willingness to pay.

And of course, it’s incredibly useful to push out the entire frontier. Unlocking more efficiency creates gains that can be allocated to lower latency, higher throughput, or a combination of the two.

This article details which inference engineering techniques let you target a point on the frontier, and which techniques push the entire frontier out. For this article, we’ll assume we’re running an LLM like GLM-5.3 or Kimi K3 for agentic coding with KV cache reuse enabled and optimal KV-aware routing.

Techniques that manage tradeoffs

Hitting a certain target in production is often less about discovering some novel approach and more about finding the right set of configurations given the nature of the traffic.

In practice, the efficient frontier is very jagged. Rather than a smooth, continuous line between outcomes, small changes can have big impacts. These cutoff points are often unintuitive and must be discovered empirically through sweeps.

Batch sizing

The most obvious tradeoff between latency and throughput comes from batch sizing. A batch is the number of requests that are processed concurrently. While token-level continuous batching means that there isn’t any latency from waiting for batches to start, the configured batch size determines the per-user latency and the overall throughput.

With small batch sizes, per-user latency is excellent, but few total tokens are generated per GPU. This means the cost per token is quite high. Increasing batch size has the opposite effect: worse per-user latencies, better overall throughput for lower cost.

Parallelism strategy

Today’s LLMs measure in the hundreds of billions or trillions of parameters and must be spread across multiple GPUs. The way in which they are shared, or parallelized, across GPUs can boost either latency or throughput.

For latency-sensitive deployments, focus on increasing Tensor Parallelism (TP). While TP has expensive all-to-all communication, it is effective for lowering latencies as these operations are fast over high-bandwidth NVLink interconnects.

Expert Parallelism (EP) can help with both latency and throughput. A lower degree of EP is often associated with better latencies, while wide EP, including EP across a full rack of GPUs, generally supports higher throughput.

Another parallelism technique for improving throughput is Attention Data Parallelism (ADP). This technique replicates attention layers for parallel computation, which boosts system throughput at the expense of per-request speed.

Quantization

Quantization, or running a model with a lower level of precision in weights, activations, and/or KV cache values, improves both latency and throughput. A quantized model pushes out the efficient frontier on serving tradeoffs.

However, quantization introduces a new set of tradeoffs between quality and serving efficiency. This is a particularly jagged frontier, where a large degree of improvement to serving efficiency is possible with little-to-no reduction in model quality, especially when using microscaling floating-point number formats like MXFP4 and NVFP4.

Techniques that move the frontier

These techniques are the ones that make the headlines. Improving overall performance is the most fun part of inference engineering.

The best part is that these techniques often compound. For example, doubling performance from better hardware while also doubling performance from better software means a four times improvement in overall serving, which can be allocated across latency and throughput.

Kernel optimization and runtime improvements

A CUDA kernel is a low-level function that executes a single piece of the inference process, like a matrix multiplication. Improving the performance of individual kernels, as well as the end-to-end performance of a forward pass in the inference engine, means fewer resources are needed to generate each token. These efficiency gains compound throughout the stack and push the frontier of performance.

Speculative decoding

Speculative decoding is the process of guessing which tokens a model might generate, then validating those guesses. When speculative decoding was new, this posed a tradeoff between latency and throughput: speculation was expensive, sequence lengths were short, and acceptance rates were low, meaning speculative decoding was only feasible at small batch sizes.

Today, techniques like EAGLE-3, DSpark, and DFlash still compete with the main model loop for resources, somewhat limiting maximum batch sizes. However, thanks to the strong performance of these techniques, especially on code generation where output token sequences are relatively predictable, they yield efficiency gains from skipped forward passes in addition to the raw reduction in latency in the form of more tokens per second per user.

Disaggregation

P/D disaggregation, or separating prefill and decode onto dedicated workers, is a strategy for optimizing high-volume deployments of LLMs. Running prefill and decode independently means that workers can be optimized for the unique characteristics of each phase of inference, and that the ratio between prefill and decode workers can be adjusted to match the input and output sequence lengths and cache hit rates from incoming traffic.

This article provided a basic overview of techniques for managing tradeoffs versus techniques for improving systemwide performance. For more detail on every technique mentioned in this article, read my free book Inference Engineering.

I trained a small transformer from scratch in 1.5hrs on a 5090. Beats many LLMs, and scores the same as TRM/HRM.

This is an upgrade to my previous model. Faster, better, cheaper and still open source.

Also gets 7% on ARC-2.

Why work on this?

I think sample efficiency is the most important problem in AI today and I want to solve it.

The intention behind this work is to (1) find the limits of sample efficiency when restricted to transformers / today’s deep learning methods and (2) reduce costs so iteration is much faster and cheaper.

ARC is a great benchmark to test this:

• Very few samples (only a 1000 puzzles) in a high dimensional space
• Its a metalearning benchmark, so each puzzle uses a different rule, with some common concepts
• Very few priors needed: every concept needed in the eval set is present in the train set
• It is incredibly easy for humans to solve, and accessible to even poor AI researchers
• Benchmark is still unsaturated (for data efficiency, ignore LLMs and approaches that use tons of synthetic data or human inductive biases)

Next, I’ll work on new research ideas to break these limits. I’ll try to keep costs low so that anyone in the world can work on this.

Tech details

How does it work?

The overall approach is similar to last time, but I added a bunch of upgrades. Here’s a quick summary of the approach:

• Each input-output pair is converted to a sequence of tokens. These sequences are autoregressively trained on by a small transformer. This is done from scratch at test time on both the train set and eval set puzzles (test labels hidden).
• To enable cross-task learning, each puzzle is given a separate additive embedding (learnt). Since each sequence has two 2D grids, positional are learnt using 3D RoPE embeddings.
• The sequences are augmented with color and dihedral permutations. During inference, the test inputs are augmented, and the inverse aug is applied on the outputs produced. The 2 most common outputs are submitted (AAIVR).

Changes since last time

The main goal was to find improvements to the architecture / algorithm that improve the sample efficiency of the model.

The biggest increases in scores were due to:

• Modern architecture (SwiGlu instead of GELU, RMSnorm not layernorm, etc.)
• More data diversity, better shuffling of data
• scaling up: 8 layers instead of 4

Biggest decreases in cost were due to:

• Way fewer augmentations (more sample efficient!)
• AdamW -> Normuon
• flash attention with varlen training + flex attention kernels for inference

A major change is that I don’t train on input tokens anymore. This means the loss function only includes output tokens (which makes the approach supervised). This performs slightly better 40% → 44% but I don’t understand why. Perhaps finite model capacity.

I also increased the training data by adding the non-overlapping tasks from ARC-2. I did this very carefully to ensure no leakage.

Context: ARC-2 contains 773 ARC-1 puzzles and 347 new puzzles. Most eval puzzles of ARC-1 are repeated, so if you naively train on ARC-2, then its a dataleak and you will score 100%. I avoid this by carefully filtering out the 773 repeated puzzles (so no leak!)

Interesting behaviour

Since I am no longer training on inputs, this approach is now supervised. What’s weird is that the test loss is now worse, yet it scores better! Also it is more stable and there’s less variance in scores.

Many ppl today are working on sample efficiency by aiming for the lowest val loss on a small dataset. I think that’s great, but this points out a failure mode in such an approach.

Ablations

The biggest contribution to performance seems to be good representations (3D RoPE + per-task embedding).

• Training on inputs performs slightly worse -> ~39%
• Restricting training set to ARC-1+ConceptARC only performs about the same: ~40%
• Switching from 3D RoPE to 1D drops score to ~24%
• Removing the per-task embeddings drops score to ~24%
• Running the model CompressARC style (training from scratch on each task separately, and unsupervised), gives a drops performance down to ~18%
• CompressARC but supervised gets ~15%

How can others contribute?

The code is open source. Feel free to modify it and improve score or reduce cost. (Pls don’t increase training data)

Try reaching 65% – you won’t need many modifications.

Mistakes that I think other approaches are making

Assuming recursion is the next big thing. I do see the appeal, but there aren’t enough ablations to prove this. And my model shows you can reach the same performance without recursion.

Misleading advertising by HRM/TRM: I also don’t like that TRM advertised itself as a 7M model when there are O(100M+) embedding weights being trained.

LLM based approaches on ARC aren’t showing new capabilities anymore: Increases in LLM scores are now mainly driven by post training and are probably a function of amount of synthetic data. They are learning to solve ARC tasks, not learn general abstract reasoning.

Learnings from LLMs on ARC-AGI

LLMs have now saturated v1 and v2 of this benchmark. OpenAI’s O1 getting 75% was a big win for LLMs. It suggested that given enough data, LLMs can learn any task during post-training.

When ARC-2 came out, it reset progress of all LLMs, including the thinking ones. This suggests even post-training doesn’t confer general reasoning capabilities, otherwise a model that performs well on ARC-1 would automatically perform well on ARC-2.

Full list of changes

Changes that modify training dynamics:

1. Optimizer changed from AdamW-only to NorMuon + auxiliary AdamW
2. LR schedule changed from warmup+cosine to WSD schedule
3. LayerNorm was replaced by RMSNorm
4. FFN changed from Linear -> GELU -> Linear to SwiGLU-style gated FFN
5. Weight decay changed from “non-attention linear only” to explicit group-wise decay
6. Training objective changed from outputs["loss"] to outputs["output_loss"] (supervised style) only
7. Training batching changed from smart bucketing based on length to true random batching
8. Straggler/incomplete batches are now dropped in training
9. Dataset construction now supports/uses broader sources
10. Color augmentation changed from one global epoch-level permutation to per-example augmentation tuples
11. Color permutation domain changed to excludes output-only colors
12. Augmentation generation now deduplicates transformed inputs via hashing
13. Augmentation selection is now epoch-cycled with shuffled candidate order
14. Changes in hyperparams
15. A new dihedral_embedding was added and is now summed into token conditioning

Speed increases without changing training dynamics:

1. Training batches changed from padded [B,S] to packed token stream with cu_seqlens
2. Attention path changed from padded SDPA masking to packed varlen flash-attention support
3. Dihedral augmentation moved from offline dataset expansion to online augmentation selection
4. Build-time training split changed from ("train","test") to ("train",)

Full article content is not available for inline reading.

Read the original article →

Full article content is not available for inline reading.

Read the original article →

Apple's Lily engine optimizes on-device LLM inference for Apple silicon. It speeds up processing by leveraging Apple silicon's unified memory and specialized hardware, outperforming MLX-LM in prefill and decode throughput. Qwen3.6-35B-A3B model's unique architecture, including sparse MoE routing and Gated DeltaNet layers, enables advanced engine tuning for efficient model execution on one Mac.

Introducing agentic video understanding with Gemini

Our new agentic feature for video analysis cuts token consumption by up to 88%, reduces costs by up to 66%, and boosts quality by up to 7%.

Google just launched agentic video understanding for Gemini 3.7 Flash, 3.6 Flash, and 3.5 Flash-Lite. This feature allows the model to dynamically scan video segments, which improves accuracy while cutting token usage by up to 88% and costs by up to 66%. You can start using this today by setting your API configuration to "agentic" in Google AI Studio or the Gemini Enterprise Agent Platform.

Today, we’re launching agentic video understanding across our latest models: Gemini 3.7 Flash, 3.6 Flash and 3.5 Flash-Lite. This new capability improves accuracy while dramatically reducing token usage and costs for video analysis. Similar to agentic vision, which combines code execution with Gemini models’ native image understanding, agentic video understanding uses Gemini’s native video tools to improve performance and unlock new capabilities for video processing like sub-second moment retrieval, more accurate anomaly detection, precise counting and more.

The feature is available today for video uploads and YouTube videos via the Gemini API in Google AI Studio and the Gemini Enterprise Agent Platform.

Benchmarks

Unlike current ‘static’ processing, where the model ingests the video at a fixed frames-per-second rate (default 1 FPS, adjustable via API), agentic video understanding pairs the model’s core reasoning with native video tools to dynamically search, scan, and inspect target video segments across visual frames, audio, and transcripts. Across standard video analysis benchmarks, Gemini models with agentic video understanding reduce analysis costs by up to 66% and token consumption by up to 88%, while improving accuracy by up to 7%.

These efficiency gains are especially pronounced on long-form video (from 10-minute how-to guides to 90-minute lectures and multi-hour recordings), where static processing forces developers to choose between high token costs or techniques that drop critical details.

While these gains span all three supported models, Gemini 3.7 Flash with agentic understanding offers the best possible quality overall and the best combination of quality and cost efficiency, putting it at the accuracy-to-cost pareto frontier among tested models for video understanding.

How it works

Instead of static processing where the model ingests media streams at a fixed frame rate, agentic video understanding enables Gemini to take an active, goal-directed role in determining what to watch, at what speed, and through which modality (frames, audio, or transcript), fetching only the moments and signals needed. While developers could previously do this manually, with agentic video understanding, Gemini can accomplish it through an agentic loop, invoking an internal tool to load the relevant part of the video file, significantly reducing development overheads.

Capabilities and use cases

Agentic video understanding transforms how developers can process long-form video content across a variety of demanding applications.

• Sub-second moment retrieval: Pinpoint split-second state changes and tight cut boundaries that are easily missed at 1 FPS, making precise automated video editing possible.
• Long-form needle-in-a-haystack search: Answer complex queries across multi-hour videos without consuming millions of tokens.
• Anomaly detection: Resample interesting time windows at higher FPS to inspect rapid motion and subtle visual artifacts.
• Counting action & object: Accurately track repeated physical movements and distinct objects over time.

Getting started

Agentic video understanding is available via the Gemini API in Google AI Studio and Gemini Enterprise Agent Platform, launching across Gemini 3.7 Flash, 3.6 Flash, and 3.5 Flash-Lite. It uses standard Gemini API token pricing with no additional feature fee.

To enable it, simply set processing to "agentic" in the API configuration. Read our developer guide to get more insights into the feature and how to get started.

from google import genai

client = genai.Client()

interaction = client.interactions.create(
    model="gemini-3.7-flash",
    input=[
        {
            "type": "video",
            "uri": "https://youtu.be/7Z5Vy9JBANs",
            "processing": "agentic"
        },
        {
            "type": "text",
            "text": "What are the 3 most important announcements in this keynote?",
        },
    ],
)

print(interaction.output_text)

We are also bringing the efficiency and quality improvements of agentic video understanding to billions of users across Google products. The feature will roll out to all users in the Gemini app across Flash and Flash-Lite models soon. And in the coming months, agentic video understanding will also power YouTube's ‘Ask YouTube’ feature on the video watch page, leveraging Gemini to deliver higher-quality answers grounded in the visuals.

Claude Fable 5.1 is now generally available, and Mythos 5.1 is available through restricted-access programs for vetted cybersecurity and life-sciences organizations. Anthropic has reduced the cost of cached context by 75% and introduced a new security architecture designed to let organizations retain monitoring data inside infrastructure they control. Fable 5.1 costs $10 per 1 million input tokens and $50 per million output tokens, but the cached price reduction will make a big difference for price-conscious enterprises.

Agentic testing is where the developer states the goal and the agent works out the steps. Agentic tests set a destination, and the agent finds its way there. The loop involves the agent looking, acting, then looking again. Meta ran this loop at scale and found that only a quarter of the output was worth keeping. However, the loop works anyway because the code that doesn't pass is automatically discarded.

Waymo argued last week that fully autonomous vehicles are not possible without using a mix of sensors, and that “pure end-to-end” AI systems are not safe enough — shots at Tesla, despite the Alphabet-owned company not naming names.

The company took these swings in a blog post and an interview with Axios just one week ahead of a September 3 event where Tesla is expected to formally introduce its two-seater Cybercab into its own small-but-growing robotaxi fleet. Waymo also announced three new markets on Tuesday morning, further extending its robotaxi network, which is serving customers in more than a dozen U.S. cities.

Despite being technical and a bit wonky, Waymo’s claims kicked off a social media fight that lasted all weekend.

“Arguments they bring forward are poor,” Pierre Ferragu, an analyst and managing partner at New Street Research who covers Tesla, wrote on X. “My read: Waymo built a driving gas plant that AI at scale makes irrelevant, and now falls into incumbent rhetoric. Innovator dilemma 101.”

“How it feels to say your data and record of success leads you to believe driverless mileage, AI interpretability, and multiple sensor types are critical for safe, fully autonomous driving at scale,” wrote Ethan Teicher, a Waymo spokesperson, while sharing a John Wick promo image that depicts more than a dozen guns pointed at the head of Keanu Reeves’ character.

The metaphorical knives — or guns, apparently — are out because if Tesla can prove the Cybercab is capable of performing at scale, it would set up a major fight between the two companies and their disparate approaches to developing autonomous vehicles. At stake is a market that could be worth hundreds of billions of dollars.

For years, this fight was more academic or philosophical than anything. But last week Waymo flexed its real-world experience.

“Cameras are incredible, but they aren’t enough,” Srikanth Thirumalai, a VP who oversees Waymo’s driving software, wrote in the company’s blog post. “For years, there’s been a debate over whether cameras alone could solve full autonomy. Now, after more than 200 million real-world miles, the data is clear: safe, fully autonomous operations at scale require more. By combining inputs from cameras, lidar, and radar, the Waymo Driver creates a rich, redundant world view that no single sensor can replicate.”

Thirumalai also wrote that a pure end-to-end neural architecture that “takes in raw pixels and directly outputs steering commands” — which is Tesla’s approach to autonomy — will “run the risk of black box failures.”

“Even the best AI models with trillions of parameters still hallucinate,” he told Axios. “There is no click reboot or reload or refresh [in] physical AI. You have to deal with the consequences of it.”

Waymo has long taken the approach of integrating a mix of cameras, radar, and lidar sensors into vehicles built by other manufacturers. While it’s a more conservative technological approach, it has allowed the company to scale to a fleet of around 4,000 robotaxis across 14 U.S. cities, which provides 500,000 paid trips per week.

At Tesla, Elon Musk has long derided the use of lidar, calling it a “crutch.” The company has instead put all its efforts into trying to make fully autonomous cars using just cameras and AI. And Tesla has spent the last few years developing the Cybercab, a purpose-built two-seater gold sedan designed to be autonomous from the get-go.

The Cybercab has no steering wheel or pedals and a relatively small battery, and Tesla plans to pump out thousands of them — a recent filing shows the company aiming to build more than 125,000 annually.

Of course, Tesla still needs to show that its self-driving software is capable of full autonomy. The company is years behind schedule; Musk once promised there would be 1 million robotaxis on the road in 2020 — though the company has spent the last year trialing its own Tesla Robotaxi network in a handful of cities in Texas and Florida using modified Model Y SUVs.

Those trials have stayed small, with Tesla claiming it’s prioritizing safety over scale. It’s only within the last few weeks that Tesla has pulled safety monitors out of a majority of those cars.

But that is likely about to change. Tesla has started registering Cybercabs with the Texas DMV ahead of the September 3 event. It’s unclear how quickly the company plans to scale the fleet after introducing the shiny two-seater, though social media users have spotted dozens of them sitting in parking lots around the country.

If Tesla can show that its AI-first approach to self driving can work at scale, it would be a major accomplishment for the company and validation for its software engineers.

The company will still have to demonstrate that it can solve all the other problems that come with operating a robotaxi network, though — problems that Waymo continues to discover as it operates thousands of self-driving cars. Those include navigating harsh weather, steering clear of emergency situations, and operating safely around school zones.

But beyond the technological differences, there’s another fight brewing: cost. Waymo’s technological approach is naturally more expensive. It uses more sensors, and installs them on vehicles that other companies manufacture. That means Waymo has to buy those vehicles and, in the case of the Zeekr-made Ojai, pay import taxes on them before they’re even outfitted with self-driving technology.

Tesla makes its own cars and is betting its AI will be capable enough to never need anything other than a few cameras to navigate the world. It’s a major gamble — one Waymo clearly thinks won’t pay off. But if it does, it gives Tesla the chance to outcompete Waymo, or possibly even Uber, on price.

The MCP tax: what each server costs before your first prompt

There is a specific number that decides whether an MCP server is worth installing, and no “best MCP servers” list prints it: how much context its tool definitions weigh. The lists rank usefulness, downloads, and stars. They stop exactly where the cost begins. So we opened the four biggest of them, took the servers they most agree on, and measured the one number they leave out.

The finding has two halves, and the second is the interesting one. The tax that older writeups warned about, where every server’s full schema burns context at session start, has largely been mitigated in current Claude Code, which defers tool definitions by default. But the weight did not vanish. It moved from startup to first use, and its size per server is exactly what we measured.

The short version

• Tool-definition weight varies by more than 30x across popular servers. In our measurement, a one-tool fetch server’s schema is around 600 estimated tokens; Notion’s 24 tools are around 19,000. Same “install one server,” two orders of magnitude apart.
• Current Claude Code defers the cost, so at session start it is near zero. We measured total prompt tokens with and without a server attached and the difference sat inside run-to-run noise. The schema is fetched when a tool is used, not when the session opens.
• So the tax is real but relocated. In a client or mode without deferral, or the moment you actually use several servers in a turn, you pay the full schema sizes in the table below. Read them as the bill that arrives on use.
• Every number here carries its method and date, and the raw table ships with the piece. The measurement is Claude Code 2.1.204 on macOS, 2026-08-09; token figures are estimated at roughly four characters per token and labelled as estimates, not tokenizer-exact counts.

How we picked the ten

The candidate list is built transparently, not editorially. We took the four largest public catalogues, the official modelcontextprotocol/servers repo plus the three biggest community “awesome” lists, and kept the servers they most agree on, cross-checked against what Google autocomplete completes for “best mcp servers for.” Two disclosures the lists themselves invite: punkpeye’s list (around 92,130 stars) describes itself in its own README as the companion to the Glama directory, and appcypher’s list is itself an archived repo. We note both rather than presenting all four as equally live.

“Free” here means no paid key is required to run the server. Two exceptions worth stating: the official GitHub server needs a GitHub account and a personal access token, and Brave’s search server needs an API key whose signup asks for a card it does not charge. Everything else ran with no account at all.

The table: what each server’s tools weigh

Measured by connecting a client and calling tools/list, then sizing the returned schema. Tokens are estimated at roughly four characters each and labelled accordingly.

The spread is the story. It does not track tool count cleanly, because verbose descriptions and large input schemas cost more than short ones; Notion’s 24 tools weigh four times Playwright’s 24. The number that matters is not how many tools a server adds, it is how much text those tools’ definitions carry.

When the bill actually arrives

Here is the loading-mode finding, measured rather than assumed. We ran a trivial one-turn session in an empty repo and summed the prompt tokens, then did the same with the filesystem server attached. The totals were the same inside run-to-run variance: roughly 25,300 either way, a difference smaller than the noise between two baseline runs.

In Claude Code 2.1.204, attaching a server does not measurably grow the session at startup, because the client defers tool definitions and only their names ride along until a tool is called.

That is the good news and the trap in one. The cost is deferred, not deleted. The moment the agent actually uses a server, the schema loads, and a turn that touches several servers pays their combined weight from the table. In an older client, or one that loads schemas eagerly, you pay it at startup regardless. So the fair way to read the table is as the cost-on-use per server, and the fair way to read the deferral is as a reason to install fewer servers than you think you can afford, because “it is free until I use it” quietly becomes “I used four of them in one turn.”

What is already measured, read carefully

Two published numbers get quoted a lot in this discussion, and both need their scope kept on.

Anthropic’s engineering post from November 2025 uses an example of tool-definition overhead dropping from about 150,000 tokens to about 2,000 through progressive disclosure. That is an illustration of the mechanism, not a measurement of any specific setup, and it should be cited as the illustration it is. Separately, Scalekit’s 75-run benchmark found that for the GitHub remote server on one task, the MCP agent used about 44,026 tokens against a CLI agent’s 1,365 for the same result. That is a striking gap and it is one server, one task; the seven failures in that run were TCP connect timeouts the authors explicitly call “not an MCP protocol error.” Neither number supports “MCP costs 30x more” as a general law. They support the narrower, sturdier claim this piece is built on: tool definitions have a real, measurable weight, and it is worth knowing per server.

The archive finding

One thing the download counts surfaced is worth a paragraph. Six of the most-recommended servers, including the widely installed GitHub one at about 125,000 downloads a week, are archived upstream. They still work, and people still install them by the hundred thousand, but archived means no maintenance, which for a component that holds your tokens and often your credentials is its own risk. Popularity on a list is a lagging signal; it can point at software the maintainer has already walked away from.

Keep or cut, by standard

The verdict follows the same standard Anthropic’s own guidance points at: run /context, and disable servers you are not actively using via /mcp. Concretely, from the numbers here:

• Keep the small, always-useful ones. Filesystem and a fetch or search tool earn their weight; you use them most turns.
• Load the heavy ones only for the session that needs them. Notion, Firecrawl, Supabase, and Playwright are the expensive rows. Attach them for the task, then turn them off. On a deferring client that costs little at rest, but it removes the first-use spike from every unrelated turn and shrinks the surface.
• Cut what you installed once and forgot. The cheapest tokens are the ones a server you never call is no longer allowed to charge you.

The whole point is that this is now a decision you can make on a number instead of a vibe. The table is dated and the method is a paragraph; re-run it against your own client and version, because deferral behaviour is exactly the kind of thing that changes between releases, and the value of a receipt is that you can check whether it still holds.

Sources & how we researched this

1. Okane Land measurement (run 2026-08-09, Claude Code 2.1.204 on macOS): for each server we connected an MCP stdio client and called tools/list, then measured the JSON size of the returned tool array (characters, and an estimate at roughly four characters per token). We also measured total prompt tokens at session start with and without a server attached. Method and raw table published with this piece.
2. MCP specification, revision 2026-07-28 (latest; previous 2025-11-25): the current revision makes the protocol stateless and removes the initialize handshake. modelcontextprotocol.io/specification/2026-07-28
3. Claude Code costs documentation (read 2026-08-09): states that MCP tool definitions are deferred by default, so only tool names enter context until a tool is used, and documents /context and disabling unused servers via /mcp. code.claude.com/docs/en/costs
4. Candidate list built by intersecting four public lists read 2026-08-09: the official modelcontextprotocol/servers repo (7 current reference servers, 13 archived), punkpeye/awesome-mcp-servers (about 92,130 stars, described in its own README as the companion to the Glama directory), wong2/awesome-mcp-servers, and appcypher/awesome-mcp-servers (itself an archived repo, disclosed here), plus live Google autocomplete intents.
5. npm/PyPI weekly download counts (read 2026-08-09) as a popularity signal with a CI-and-mirror caveat: @playwright/mcp about 6.66M, @upstash/context7-mcp about 1.0M, @modelcontextprotocol/server-filesystem about 485k, mcp-server-fetch about 445k, and @modelcontextprotocol/server-github about 125k despite being archived upstream.
6. Scalekit benchmark (75 runs, Claude Sonnet 4, GitHub remote MCP vs a CLI, 2026): for that one server and task, the MCP agent used about 44,026 tokens against the CLI agent's 1,365 for the same result; the 7 MCP failures were TCP-level connect timeouts, which the authors label "not an MCP protocol error." A single-server comparison, not a general multiplier.
7. Anthropic engineering, "the new rules of context engineering" (2025-11-04): uses an illustrative example of tool-definition overhead falling from about 150,000 tokens to about 2,000 via progressive disclosure. An illustration, cited as such.

Full article content is not available for inline reading.

Read the original article →

Full article content is not available for inline reading.

Read the original article →

In case you missed it: OpenTelemetry (OTel) has officially achieved CNCF graduated status! It now stands proudly alongside amazing open source projects such as Kubernetes and Prometheus, to name just a few. It’s been a long journey, and we’re very excited… But, now what? To understand where we’re going, it’s important to understand where we came from.

History

In the not-so-distant past, telemetry signals were not standardized. This meant telemetry formats differed from tool to tool, with each telemetry vendor creating and maintaining its own instrumentation libraries. Vendor lock-in was a huge problem: If you wanted to switch vendors, you had to strip out the previous vendor’s libraries from your code and replace them with the new vendor’s libraries. As a result, switching vendors was a nontrivial task.

In addition, the three core telemetry signals – traces, logs, and metrics – were treated as separate, so there was no easy way to correlate them. Because of this, the observability story was incomplete.

Previous attempts had been made at standardization: the CNCF’s OpenTracing, and Google’s OpenCensus, forming the basis for what was to become OpenTelemetry.

In the interest of having a single standard, OpenCensus and OpenTracing were merged to form OpenTelemetry in May 2019. OpenTelemetry takes the best of both worlds, and then some, providing a tracing, metrics, and logs specification, a set of standardized APIs, and language specific implementations of these APIs, in addition to the Collector.

Both OpenCensus and OpenTracing are now officially archived. OpenTracing was archived in January 2022, and OpenCensus was archived in July 2023.

With the backing of all major observability vendors, and an active developer and end user community, OpenTelemetry became the de facto open standard for telemetry.

Growth

OpenTelemetry is the second-highest velocity project in the CNCF, just behind Kubernetes. According to the CNCF, OpenTelemetry has “over 12,000 contributions, from over 2,800 companies and hundreds of maintainers across various language-specific Special Interest Groups (SIGs).”

Since its inception, traces, logs, and metrics have reached general availability (GA). Profiling was added as a new OTel signal. The OpenTelemetry Demo has expanded. The OTel Collector has expanded, with new components being added regularly. We’ve seen the addition of new components to the OTel ecosystem to help make it more ergonomic, including OpAMP, the OTel Operator, OTel Weaver, and OTel Arrow.

This is a very impressive achievement, considering that OpenTelemetry is a mere seven years old. It sends a clear signal: OpenTelemetry is here to stay. And graduation helps to cement that.

Graduation!

OpenTelemetry achieved graduated status in May 2026, having started its path to graduation in 2025.

So what does it take to become a graduated CNCF project? Projects must fulfill the following criteria:

1. Production adoption. Many different organizations, such as GitHub and Farfetch, run OpenTelemetry in production.
2. Robust governance. OTel has a documented governance model with clearly defined roles around election and retirement, along with transparent communication and decision-making.
3. Community health. OpenTelemetry has an established process for PR review and management. The project has a number of regular contributors across multiple organizations. Reviewers are responsive, ensuring that issues and fixes are addressed in a timely manner.
4. Security. OTel has undergone at least one independent security audit, and all critical issues identified have been remediated.
5. API stability. APIs are stable, properly versioned, and released at a regular cadence, with backwards compatibility ensured so as to not break existing implementations.
6. Documentation. OTel’s documentation provides an architectural overview, along with user, operator, and contribution guides.
7. TOC application and review. A graduation application template was submitted for review by the CNCF’s Technical Oversight Committee (TOC). You can check out OTel’s submission.

As you can see, a lot of work was done behind the scenes by many dedicated folks, ranging from OTel maintainers, to end users, to CNCF TOC members to make this happen.

We’d like to give a huge shoutout to all in the OpenTelemetry community who made graduation happen, and especially to Austin Parker, OpenTelemetry Governance Committee member and former Community Manager, who led the graduation effort with the CNCF.

What this means for you

So what does OpenTelemetry graduation mean for you, dear reader?

Dan Gomez Blanco, one of the maintainers of the OTel End User SIG put it perfectly in a recent LinkedIn post:

For end users, this graduation signals that OTel is far from being an “emerging standard”. Its contributor health, security and quality standards, governance processes, and wide adoption have been evaluated to be at the level required by any enterprise, of any scale. So, if you’re in the 25% of skeptics not using OTel, there’s really no excuse anymore. There has never been a better time to adopt it!

In a nutshell: OpenTelemetry is production-ready, and fully open for business. If your organization was holding out on using OpenTelemetry, you have no more excuses!

What’s next?

Software is never really “done”, and the same goes for OpenTelemetry. It will continue to grow and evolve: from the specification to the API & SDK to the Collector, and beyond.

Looking ahead, we see a strong need for observability around new types of workloads, such as agentic workflows, an area covered by the emerging generative AI semantic conventions. We’re also tackling challenges in areas that we hadn’t focused on as much previously, such as browser and mobile observability.

More mature teams are looking for guidance on using OpenTelemetry at scale. That’s where tools like Weaver, which helps teams define and govern their telemetry schemas, come into play. We’re also making OTel easier to roll out by packaging components into installable modules through OpenTelemetry Packaging, and by enabling zero-code instrumentation with the OpenTelemetry Injector.

OpenTelemetry has a long future ahead of it, but we also know that it’s only possible through continued work by maintainers and contributors, and of course, through continued support and adoption by our end users.

We can’t wait for what the future has in store for us, and we’re excited to have you along for the ride.

Microsoft’s Azure Functions serverless compute service abstracts away infrastructure management to simplify how teams deploy and operate applications. However, the managed environment can make it harder to understand what happens inside those applications after deployment. Traditional approaches that rely on agents, extensions, and sidecars for direct collection of telemetry data aren’t available across every Azure Functions hosting plan, which can leave gaps in end-to-end visibility. Developers often must piece together logs, metrics, and traces from different sources to troubleshoot issues.

Datadog has expanded Azure Functions observability with enhancements to Serverless Monitoring that broaden support across hosting plans and provide deeper insight into application performance. In this post, we’ll explore how you can:

• Collect telemetry data across Azure Functions hosting plans
• Track requests through Azure Functions with distributed tracing
• Analyze CPU usage with enhanced metrics
• Find performance bottlenecks with Datadog Continuous Profiler

Collect telemetry data across Azure Functions hosting plans

With the Datadog extension for Azure App Service, Datadog already provides direct telemetry data collection for Windows-based .NET function apps on Dedicated or Premium hosting plans. Azure Functions on Linux, however, does not offer the same extension-based installation path.

Datadog’s Serverless Compatibility Layer expands direct telemetry data collection to function apps running on either Linux or Windows, regardless of hosting plan. The Serverless Compatibility Layer is a lightweight package for .NET, Python, Node.js, and Java that runs alongside your function code. It detects the Azure Functions environment at startup and acts as a local aggregation point, batching application telemetry data before sending it to Datadog.

Track requests through Azure Functions with distributed tracing

Serverless applications rarely consist of a single function. User requests often move through HTTP endpoints, messaging services, databases, and additional functions before returning a response. Distributed tracing from Datadog Application Performance Monitoring (APM) connects related activity across that request path, helping you understand where latency occurs and where failures begin.

Distributed tracing for Azure Functions is generally available for supported runtimes, including .NET, Python, Node.js, and Java. After you initialize the tracer, Datadog automatically instruments supported frameworks, propagates trace context into and out of functions, and builds an end-to-end view of every request.

The Service Map discovers relationships between functions and downstream dependencies. It displays latency and error rates on every connection to help you identify unhealthy services more quickly.

Connect frontend activity with backend traces

Frontend and backend telemetry data often live in separate tools, making it difficult to determine why a user experienced a slow page or failed transaction. Datadog bridges that gap by connecting Real User Monitoring (RUM) sessions with Azure Functions traces.

When a user action triggers a backend function, the Datadog Browser SDK injects trace headers into the request. Datadog associates the resulting backend trace with the originating RUM session and adds relevant context, including the session ID, current view, and user details. You can then move directly from the RUM event to the backend spans that show how the request was processed.

Session Replay provides another starting point for the same investigation. After you watch a user complete an action in the UI, you can open the corresponding distributed trace to see every downstream span related to the request.

Preserve trace context across Azure managed services

Asynchronous messaging can interrupt trace continuity because request context might not follow a message into a queue or event stream. Datadog preserves trace continuity for Azure Service Bus and Azure Event Hubs by injecting trace context into message metadata when a function publishes a message. Datadog then extracts that context when another function consumes the message. When the producer and consumer operations belong to separate traces, Datadog connects them with span links. The publishing and consuming functions run independently, but the span links preserve the relationship between their invocations.

Datadog also represents Azure Cosmos DB create, read, update, and delete (CRUD) operations in distributed traces as inferred spans. These operations appear alongside function spans with automatic instrumentation. Cosmos DB spans show how much latency each database operation contributes. By comparing the duration and placement of Cosmos DB spans with messaging and function spans across the related traces, you can see where latency accumulates. You can then determine whether a delay comes from a database query, message processing, or application code.

Analyze Azure Functions CPU usage with enhanced metrics

Azure provides CPU metrics for Azure Functions, and Datadog surfaces those metrics through the crawler-based Azure integration. Azure updates those metrics at intervals of 1 minute or longer, which can make short CPU spikes difficult to identify.

Serverless Monitoring samples CPU usage from the function app every second and publishes distribution metrics every 10 seconds. The enhanced CPU metrics help you distinguish brief bursts of CPU activity from sustained utilization and understand how CPU usage varies across function invocations.

Enhanced metrics also support proactive alerting. You can create monitors that notify your team as CPU utilization approaches saturation, helping you investigate potential performance issues before they affect users.

All enhanced metrics use the azure.functions.enhanced.* metric prefix. You can enable enhanced metrics by updating to the latest version of the Serverless Compatibility Layer.

Find performance bottlenecks with Datadog Continuous Profiler

While enhanced metrics tell you when CPU utilization increases, Datadog Continuous Profiler helps you determine which code paths consume that CPU time. Continuous Profiler periodically captures call stacks from running functions and aggregates them into flame graphs that you can explore. By examining the profile from the affected time window, you can compare call paths and prioritize the code changes that are most likely to reduce CPU or I/O overhead.

Continuous Profiler for Azure Functions is available in Preview for Python and Node.js. After you enable profiling by setting DD_PROFILING_ENABLED=true, Datadog begins collecting profiles without requiring code changes.

Start monitoring your Azure Functions applications with Datadog

Azure Functions applications often depend on multiple services that run across different runtimes and hosting plans. Datadog’s expanded Azure Functions support provides broader deployment coverage through the Serverless Compatibility Layer, in addition to distributed tracing, higher-resolution CPU metrics, and code-level profiling. Together, these capabilities help you follow requests across services, identify resource constraints, and trace performance bottlenecks back to the relevant application code.

To learn more and get started, read our Serverless Monitoring for Azure Functions documentation and our Azure database and messaging services documentation.

If you’re new to Datadog, you can sign up for a 14-day free trial to start monitoring your Azure Functions applications.

Apple says new forensic evidence from a former engineer's laptop strengthens its trade-secret theft lawsuit against OpenAI, alleging that ex-employee Chang Liu used confidential Apple engineering files in his OpenAI work, discussed the unauthorized data access internally, instructed a colleague to destroy evidence during Apple's investigation, and worked with a tool sharing the name of an internal Apple application—claims Apple argues justify accelerated discovery because the alleged trade secrets may already have been incorporated into AI systems.

Welcome to All UtilityCSS

All UtilityCSS is your go-to platform for discovering premium and free Tailwind CSS resources—including templates, components, and tools designed to supercharge your web development workflow. Built on the power of Tailwind CSS, our curated collection empowers developers, designers, and businesses to create stunning, responsive websites with minimal effort. Whether you're launching a startup, building a portfolio, or scaling a SaaS product, All UtilityCSS provides the building blocks to bring your vision to life—fast, flexible, and fully customizable.

Our mission is to simplify front-end development by offering hand-picked, production-ready resources that prioritize performance, accessibility, and ease of use. With All UtilityCSS, you can skip the repetitive setup and focus on crafting unique user experiences that stand out.

Why Choose Tailwind CSS for Your Projects?

Tailwind CSS is a utility-first framework that redefines how developers approach styling. By leveraging utility classes applied directly in your HTML, Tailwind eliminates the need for custom CSS while offering unparalleled flexibility. This modular approach lets you build complex, responsive designs without leaving your markup, making it ideal for rapid prototyping and scalable production sites.

With All UtilityCSS, you can harness Tailwind’s full potential through our curated resources. Need to tweak a component’s colors to match your brand? Just swap a few utility classes. Want to adjust layouts for different screen sizes? Tailwind’s responsive prefixes (md:, lg:) make it a breeze. Our resources are designed to integrate seamlessly with Tailwind’s ecosystem, giving you the freedom to customize without compromising on speed or consistency.

With Tailwind CSS v4.0 driving innovation, Tailwind Templates are set to evolve further. Expect deeper integrations with headless CMS platforms, enhanced accessibility features, and AI-powered design tools. At All UtilityCSS, we’re excited to showcase the latest creations from the Tailwind community, keeping you at the forefront of web development trends.

• Blazing-Fast Builds: The new Oxide engine compiles CSS in milliseconds, even for large-scale projects.
• Minimal Bundle Sizes: Advanced tree-shaking removes unused styles, keeping your site lean.
• Modern CSS Support: Native utilities for CSS variables, logical properties, and new features like accent-* and caret-*.
• Streamlined Configuration: A simplified tailwind.config.js and enhanced editor support for a smoother workflow.
• Framework Flexibility: Seamlessly integrates with React, Vue, Svelte, or vanilla JavaScript.

Custom-Built vs. All UtilityCSS Resources

Custom-Built

Coding from the ground up offers total control and a deep understanding of your codebase. It’s ideal for highly specialized projects or learning purposes, but it can be time-intensive and lead to inconsistencies if not carefully managed.

All UtilityCSS Resources

Our templates and components are crafted by experts to save you time while maintaining professional quality. Each resource is optimized for Tailwind CSS, ensuring responsiveness, accessibility, and easy customization. By starting with our pre-built elements, you can focus on adding unique features, refining functionality, or experimenting with creative designs. Plus, our resources serve as learning tools, showcasing best practices for structuring Tailwind-based projects.

Who Can Benefit from All UtilityCSS?

• Indie Developers and Freelancers: Tight deadlines and multiple projects? Our resources help you deliver polished, professional websites quickly, leaving room for custom touches that impress clients.
• Startups and Entrepreneurs: Need to launch an MVP or marketing site fast? All UtilityCSS provides ready-to-use templates that let you focus on validating ideas and engaging users, not wrestling with CSS.
• Designers Collaborating with Developers: Our components bridge the gap between design and code. Designers can share style guides, and developers can implement them with Tailwind’s utility classes, minimizing revisions and ensuring pixel-perfect results.
• Seasoned Developers: Even experts appreciate efficiency. Use our pre-built headers, modals, or forms to speed through repetitive tasks and dedicate your energy to solving complex, project-specific challenges.

Explore Our Resource Categories

Tailwind CSS Themes

All UtilityCSS has a vast collection of templates that provide complete, ready-to-use layouts for a variety of website types, from marketing pages to web applications. Designed with Tailwind CSS, these templates are perfect for quickly launching projects while maintaining flexibility for customization to match your brand.

We have gathered the premium and free Tailwind themes in the following categories:

• eCommerce
• Admin Dashboards
• Portfolio Sites
• Blog Themes
• SaaS Applications
• Landing Page Templates & much more

Tailwind CSS Tools

Our tools enhance your Tailwind CSS workflow, offering utilities and plugins to optimize development and performance. These resources are ideal for developers looking to streamline processes and elevate their projects with advanced functionality.

At All UtilityCSS, you will find a variety of Tailwind tools:

• Plugins for extending Tailwind’s utility classes.
• PurgeCSS integrations for optimized production builds.
• Responsive design testers for cross-device previews.
• Code snippets for common Tailwind patterns.

Tailwind CSS Components

Our components are modular, reusable building blocks that integrate effortlessly into any project. From buttons to navigation bars, these Tailwind-optimized elements save time and ensure consistency, letting you focus on the bigger picture.

In the curated collection you will find:

• Stylish buttons and modals for interactive UIs.
• Form elements with accessible, validation-ready designs.
• Navigation menus for intuitive site structure.
• Card layouts for showcasing content or products.

Why All UtilityCSS Stands Out?

• Curated Quality: Every template and component is vetted for performance, accessibility, and Tailwind best practices, ensuring you start with reliable foundations.
• Community-Driven: We encourage developers to contribute their own resources, fostering a collaborative ecosystem where fresh ideas and innovative designs thrive.
• Customization Focus: Our resources are built to be adapted. With Tailwind’s utility classes, you can easily modify colors, layouts, or behaviors to match your project’s unique needs.
• Learning Resources: Beyond templates, we offer guides and tutorials to help you master Tailwind CSS, from responsive design to optimizing performance with PurgeCSS.

Ready to elevate your next project? Explore our collection at All UtilityCSS and start building faster, smarter, and better today.

Frequently Asked Questions

Explore frequently asked questions about All UtilityCSS

What is All UtilityCSS?
All UtilityCSS is a curated platform offering premium and free Tailwind CSS templates, components, and tools to streamline web development.

Do I need Tailwind CSS experience to use these resources?
No, beginners can use our resources with basic HTML knowledge, while experienced developers can leverage them for faster workflows.

Are the resources customizable?
Yes, all resources are built with Tailwind CSS utility classes, making it easy to tweak colors, layouts, or styles to fit your project.

Can I use these resources with other frameworks?
Yes, our resources work with any JavaScript framework (e.g., React, Vue) or static site generators, as they’re HTML-based.

Are the resources accessible?
Yes, we have collected the best resources that offers accessibility, ensuring components and templates which meet WCAG standards. However, it is advised to check on the official resources page for the most accurate information.

How can I contribute to All UtilityCSS?
Join our community by submitting your own templates, components, or tools via our contribution portal on the website.

Can I Submit The Premium Tailwind Resources?
Absolutely. All short of Tailwind resources that are based on latest Tailwind versions are accepted.

Have a resource?

Submit your Tailwind CSS resource to All UtilityCSS, get featured, and drive genuine traffic while showcasing your work to the world. Turn your creativity into revenue and begin selling today! 🚀

Looping "round trip" tests—generating specs from Figma, rendering them back, and diffing the results—reveal what design-to-code contracts silently drop, distort, or invent. The exercise exposed hidden assumptions, transformation bugs, and schema gaps in one such tool, while also clarifying which Figma features, like custom prop ordering or motion, can't or won't be supported. Round trips rarely converge to zero difference, but they let teams precisely name what's lost versus intentionally excluded, improving contract quality.

This post contains affiliate links. We may earn a commission if you click on them and make a purchase. It’s at no extra cost to you and helps us run this site. Thanks for your support!

Two weeks ago, I went hunting for a replacement stylus nib on Amazon. About ninety minutes later, I’d ordered five things I didn’t know I needed. That’s the honest origin story of this piece, and I’m not entirely proud of it. Running a design publication means testing gear is technically part of the job, so I gave myself permission to keep scrolling. Even so, I didn’t expect four out of five purchases to survive past the first week.

Design tools on Amazon carry a mixed reputation among working designers. Search the term, and you’ll wade through counterfeit styluses, mystery-brand monitor arms, and product photos that look suspiciously AI-generated. Underneath that noise, though, sit a handful of genuinely useful tools, priced low enough that you don’t need a client invoice to justify buying them. Five of mine made it past my own testing threshold. Here they are, along with the one rule I now use before anything earns a permanent spot on my desk.

What Actually Counts as a Design Tool on Amazon?

Not everything sold under “design tools” on Amazon deserves the label. Half the search results are generic desk organizers with a paintbrush icon slapped on the packaging. So before testing anything, I set one filter for myself. Call it the Second-Reach Test: a tool passes if I pick it up again within a week of first using it, without anyone reminding me it exists.

That sounds obvious. It isn’t. Most gadgets get used once out of curiosity, then buried under a stack of reference books. The Second-Reach Test cuts through unboxing excitement and asks a plainer question. Does this thing solve a problem you actually have, or a problem you didn’t know you had until the product page described it to you? Every tool on this list passed. A few others, which I won’t name here to spare their feelings, did not.

The Desk Real Estate Tax Is Real

Here’s a thesis I’ll defend: every object on a designer’s desk charges rent. Call it the Desk Real Estate Tax. Space is finite, attention is more finite, and a gadget that just sits there charges you both anyway. That’s why “cool” isn’t a good enough reason to buy a design tool on Amazon. The tool has to pay its tax back in saved time, better output, or fewer trips to a paint store for chips you’ll lose in your bag. Keep that filter in mind as you read the list below. I did too, which is why this roundup has five entries instead of fifteen.

Five Design Tools Worth Ordering Right Now

These are ranked by how often I’ve reached for them since the order confirmation email, not by price or how flashy the unboxing looked on camera.

1. Nix Mini 3 Color Sensor, for Color That Doesn’t Lie

The Nix Mini 3 is a colorimeter about the size of a large marble. Touch it to any surface, and it reads the true color, blocking out ambient light with its own built-in calibrated source. It then matches that reading against more than 200,000 paint colors and hands you exact RGB, HEX, and CMYK values through a companion app. I use mine constantly for brand audits, holding it against printed packaging or existing signage to pull an honest color value instead of eyeballing it from a photo under bad office lighting.

One limitation worth knowing upfront: it can’t scan a screen, only physical surfaces. That rules out a whole category of digital color-picking, but for print, packaging, and interior branding work, it’s hard to beat. It typically runs $119 to $129 on Amazon, though it drops closer to $80 to $99 during sales, so it’s worth checking before you buy. Either way, it’s a cheap way to stop arguing about whether a blue reads “more teal” than the brand guide claims.

2. Logitech MX Creative Console, a Second Brain for Your Left Hand

This one looks like a Stream Deck at first glance, and Logitech clearly built it to compete with it directly. Nine customizable LCD keys sit next to a metal control dial that adjusts brush size, timeline position, or exposure depending on which app has focus. Native profiles cover Photoshop, Illustrator, Premiere, Lightroom, and, more recently, Figma. That last one matters if your studio has moved most of its work into the browser.

Setup takes about twenty tedious minutes of button mapping, and the console runs on AAA batteries instead of a rechargeable cell, an odd choice at this price point. Even so, I haven’t switched mine off since day two. List price is $199.99 on Amazon, but it’s been discounted to around $160 to $170 fairly often over the past few months, so patience pays off here.

3. Huion Kamvas 16 (Gen 3), Proof a Pen Display Doesn’t Need to Cost Two Grand

Wacom still makes the pen display every design student dreams about, and it still costs more than most freelancers clear in a slow month. Huion’s Kamvas 16 (Gen 3) undercuts that price by roughly three-quarters and gets close enough on feel that most clients won’t notice a difference in your line work. The 15.8-inch screen runs at 2.5K QHD, covers 99% of sRGB, and pairs with a battery-free stylus rated for 16,384 pressure levels. Two physical dials sit on the bezel for quick brush or zoom adjustments.

It ships with a color calibration report, a detail I didn’t expect at this price and genuinely appreciated. MSRP is $499, but street price on Amazon usually lands between $429 and $459, depending on the week and any bundled accessories.

4. Rocketbook Core, the Analog Anchor

Every design tool on this list except one lives inside a USB cable. The Rocketbook Core is the exception, and I think that’s exactly why it earns a place here. It’s a spiral notebook with synthetic, wipeable pages that look and feel like real dotted paper. You sketch, letter, or wireframe with the included Pilot FriXion pen, scan the page through the app, then wipe it clean with a damp cloth once you’re done.

I keep mine for thumbnail sketches and quick notes during client calls, the kind of work that still moves faster on paper than inside Figma. The Letter size runs around $30 to $39 on Amazon, with the smaller Executive size a few dollars cheaper. Cheap enough that losing one doesn’t really sting.

5. Huion A4 LED Light Pad, the $30 Tool Nobody Talks About

This is the least glamorous item on the list and possibly the one I reach for most. It’s an 8mm-thin LED panel that lights up evenly so you can trace directly through a sheet of paper. Illustrators use these for cleaning up rough sketches. I use mine for something less romantic: laying a printed proof over a previous draft to spot exactly where kerning or alignment drifted between versions.

Brightness adjusts through a touch-sensitive dial and remembers your last setting, a small detail that saves real annoyance if you use it daily. At $25 to $38 depending on the bundle, it’s the cheapest entry on this list of design tools and one of the hardest to argue against. You can find it on Amazon.

Five Design Tools, Side by Side

Where This Category Goes Next

Here’s a prediction, and you’re welcome to hold me to it. By the time Amazon runs its next big shopping event, at least one of these categories folds directly into AI shortcuts. Picture a creative console with a button that sends a selection straight to an image model instead of triggering a static Photoshop action. Huion and XPPen already ship standalone tablets that run Android, so a software layer that talks to a generative model is a smaller leap than it sounds.

I’d also bet the sub-$500 pen display market takes one more serious price cut within the next year. Three brands are now chasing the same customer Wacom used to have almost entirely to itself, and that kind of competition rarely stays polite for long.

Frequently Asked Questions About Buying Design Tools on Amazon

Are design tools on Amazon good enough for professional client work?

For the categories on this list, yes. A colorimeter, a pen display, and a workflow console do the same job whether you buy them from Amazon, a specialty retailer, or the manufacturer directly. What matters is the model, not the storefront.

What’s the most affordable design tool worth buying on Amazon right now?

The Huion A4 LED Light Pad, at roughly $25 to $38, delivers the most usefulness per dollar on this list. It solves a real problem for illustrators and production designers without asking you to learn new software.

Do I still need a drawing tablet if I already own an iPad?

Depends on your software. An iPad with Procreate covers a lot of ground, but Photoshop and Illustrator still run faster and more fully on desktop, where a dedicated pen display like the Kamvas 16 earns its keep.

Is the Nix Mini 3 accurate enough for matching brand colors?

For most practical design and print work, yes. It won’t replace a professional spectrophotometer on a production line, but for pulling an honest color reading from a real-world object, it’s remarkably close.

Can these design tools be returned if they don’t fit my workflow?

Amazon’s standard return window applies to nearly everything on this list, which is one more reason to test before you commit to a full studio setup built around any single tool.

The One Rule That Actually Matters

Five design tools, one dumb rule, and a lot of Amazon boxes that didn’t make the cut. If you only buy one thing off this list, make it the tool that solves a problem you already complain about, not the one with the flashiest unboxing video. That’s the whole test, really, and it works better than any spec sheet.

Cognition is set to close a new round of funding of around $1 billion. The final raise size may exceed that amount as Cognition is fielding outsized demand for the round. The startup is now bringing in more than $900 million in annualized revenue. The new funding round would vault its valuation to about $47 billion.

The memory industry is going through a supercycle for the history books. In 2023 the industry was at the bottom of its worst slump ever, facing negative industry-wide profits. Samsung cut production 50% and both SK Hynix and Micron posted negative gross margins! ChatGPT launched. Stargate alone would require 40% of global DRAM production. HBM became 60% of Nvidia GPU’s manufacturing cost. The three major’s production capacity has been contracted for a year out even though yields on 12-layer stacked HBM3e are as low as 75%. The SK Hynix CEO is still saying the supply shortage will be even worse next year and that demand will outstrip supply beyond 2030. Now all three majors are projected to earn more operating profit in a couple years than Apple does today.

Maybe it’s overly smooth-brained to start a new, technically ambitious company right as we’re nearing the upper end of the capital cycle for an industry so notorious for cyclicality that it’s used as a poster child example in textbooks. But, even if the industry eventually works its way through HBM’s manufacturing challenges, overbuilds capacity, inventory accumulates and the price per stack falls, the underlying demand isn’t going anywhere and memory is no longer a commodity product. Wall Street consensus projects that while prices may ease starting in 2028, the net profit floor for the memory majors will be 5-10x that of the prior cycle. However it pans out, navigating these market dynamics effectively will take a founder well-versed in history and the charts below.

Over the years, we’ve spent a lot of time looking at novel approaches to AI accelerators, especially those harnessing novel physics that give them a potential order(s) of magnitude advantage. The culmination of our research can be found here. In that, we wrote:

“To have a shot at assailing Nvidia’s moats in software, distribution, its 1-year product release and its 2.5-year performance doubling cadences, a startup must harness physics that grant it a realistic path on paper to ~100x efficiency improvement over today’s H100s. Because, that 100x theoretical or "on paper" advantage may actually be 25x in practice. And, by the ~6-8 years it takes even the top chip startups to get a product to market, Nvidia's already churned through 6-8 product cycle upgrades. That 25x practical advantage is now only ~10x the SotA Nvidia chips at launch.”

We feel similarly about this opportunity. While the memory majors may not be quite as ruthlessly well run as Nvidia, they have everything else going for them and capable product roadmaps ahead.

Given that DRAM miniaturization hit a wall over ten years ago and all incumbents are focused on the next-order solutions of ever-more creative advanced packaging means of going vertical, we’d be looking for technologies that side-step these challenges entirely by leveraging entirely different physics that grant them credible paths towards order(s) of magnitude improvement.

For instance, is it possible to absolve the memory wall itself by bridging the bottleneck caused by the speed and energy gap between lightning-fast scratch pad memory SRAM and high bandwidth working memory like DRAM?

After surveying all the approaches we could find, we think a few could be between one and several breakthroughs away from being viable.

They generally fall into two camps: attempts at HBM-like bandwidth that’s far faster to access or HBM-like bandwidth with NAND-like density.

Faster than HBM Access Speeds

Of the more speculative approaches, the first two that involve pushing DRAM closer to logic are by far the most advanced. d-Matrix and Qualcomm’s approaches could plausibly reach manufacturing within several years. They could have meaningful but not game-changing speed ups. Vertical magnetic strings take this premise of on-die memory farther by using a more radical but risky physics substrate.

We’re particularly excited about magnons, which use spin waves as the information processing unit. Latest research suggests a speculative path towards a non-volatile memory with speeds that approach SRAM access times, DRAM-like density and very low power consumption.

Whereas most magnon research uses metallic ferromagnets, we see antiferromagnetic magnons in insulators as especially attractive because no charge moves through the active material, so dissipation can be very low. And, antiferromagnets’ resonance frequencies can be around one terahertz which puts the relevant dynamics on a 1-2 picosecond timescale vs more than ten times slower for ferromagnetic materials.

The historical problem was readout. Sensing a magnetic state at a scale of approximately 10 nanometers is not trivial, and optical readout does not scale easily. But in the last six years, researchers have increased signal readout over 4 orders of magnitude from ~100 nanovolts to beyond microvolts. They will need to hit 100 millivolts for it to be plausibly commercially useful.

Using these materials, researchers have built a non-destructive read memory PoC.

HBM-like Bandwidth + NAND-Like Density

Ferroelectrics has for twenty to thirty years been hypothesized as a potential universal memory platform because it could enable DRAM-like bandwidth, is non-volatile, requires relatively little energy to flip states, and is the most well-understood material system.

Micron even recently invested $1B into demonstrating a device that replaces the DRAM capacitor with a ferroelectric one but otherwise kept the traditional 1T1C charge-sensing set up. The work was shelved because its signal still scaled with capacitor area like DRAM’s so NAND density wasn’t achievable, required sequentially stacking complete 1T1C tiers so had poor cost scaling, and degradation couldn’t be resolved.

Recent academic work has suggested a possible path towards NAND-like density scaling by using 2T-nC vertical strings whereby a given capacitor can be shared across many vertically stacked bits.

While exciting, a startup commercializing such advances in ferroelectrics must contend with the fact that ferroelectrics is closely watched by memory majors. Its technical innovation must yield a decisive advantage, its IP position solid, and it must move rapidly towards manufacturing.

An Accelerated Future

A handful of early-stage memory technologies could yield either far faster access speeds than current HBM or HBM-like bandwidth with NAND-like density.

Beyond distributed near-memory DRAM and true 3D DRAM, technologies like magnonics and vertical FeRAM stand out as being possible platonic ideals for memory.

But they have a very long way to go before being remotely commercially relevant and their estimates below require extrapolating excellent device physics into an array architecture that does not yet exist.

Moreover, even if fundamental hurdles are overcome with the respective materials systems, commercializing the technologies will require founding teams capable of raising $100Ms-1B+. For instance, Micron’s small-scale ferroelectrics demonstration cost $1B. Even developing just a new node within existing memory systems requires 2,000 engineers. That’s not to say it can’t be done, given that companies like Cerebras raised $3B to reach the market with a more complex vertically integrated compute stack.

But if any of these came true, they’d be truly revolutionary transformations of the constraints for AI and how developers think about these systems.

While most of the technologies feel irrelevantly far off and closer to basic science experiments than threats to the memory fiefdoms, we think there’s a possibility their progress could be meaningfully accelerated. We’ve spent years studying materials discovery and translation, including with our portfolio company Orbital Materials.

Our published research details how the advance of NNPs enables high throughput materials simulation at near quantum chemical accuracy, the gap between initial discovery to manufacturing scale-up is slowly being chipped away at, and now AI engineering tools for CAD and semiconductor-specific design will accelerate architecture-level modeling. The paths for tech tree exploration could all be run in parallel, orchestrated by agents.

Maybe on a 4+ year timeframe these technological tools, combined with the $1T pot at the end of the rainbow, will enable the more exotic approaches to become viable sooner than expected.

Indeed, we saw an analogous thing happen with the novel physics accelerators. thanks to open source libraries like PyTorch and coding agents, companies launched in the last several years have needed far fewer software engineers than the prior generation (Groq, Cerebras, etc) as they haven’t had to write everything from scratch and can move far faster on what custom software they did have to write. We heard something like 50 developers to get to an MVP not 200+.

We’re open to the idea that in the next few years something similar will happen to more basic discovery, translation, and engineering.

Nobody is talking seriously about AI demand

AI capex for 2028 is forecast to be larger than the budget of France. Frontier AI labs’ revenue ramp justifies almost any number. Reflexivity in AI demand is a double-edged sword, and it's now a good time to start talking about it.

On his latest podcast, wonders why the frontier labs are not spending even more on compute, given expectations of $100B/GW in revenue for frontier intelligence. At these rates, if Anthropic were to monetize all of its expected capacity, it could be at $500B ARR by the end of 2026 - enough to be the third-largest company in the world by revenue.

Nobody is talking seriously about AI demand. Today, analysts model infinite demand for AI for any level of supply, without really breaking down where that demand is coming from. But demand is extremely important, it dictates how much capital frontier labs can invest, which models will be used, and where the value will accrue.

Below is my framework for thinking about AI demand, the case for frontier tokens, and a few adjacent topics.

I am extremely optimistic about future demand for AI. But my framework suggests that demand for frontier tokens may be partly reflexive, fueled by the AI boom itself. This is great and accelerates growth, but it may also spiral in the opposite direction.

All numbers are estimates.

Tokens as units of time

METR’s long-horizon chart is possibly the most important chart in the world today.

Based on the chart, I often say we can think about tokens as units of time. Tokens from each model represent a certain task-horizon, and frontier models have the longest duration. On the chart, o3 is ~ 30 min, while Mythos is ~ 3h. A software engineer using o3 can delegate tasks of up to 30 min, while one using Mythos is significantly sped up - delegating up to 3h.

The chart also provides a framework for structuring human activities. Let’s define:

Long-horizon vs. short-horizon tasks. “Long-horizon” tasks are the ones that no model succeeds at yet - i.e., above the curve which runs from GPT-2 to Mythos. Everything else, below the curve, is “short-horizon” - effectively, it’s already been solved by AI.

Bounded vs. unbounded tasks. “Bounded” tasks are those for which, at some point, the curve stops scaling: doing taxes is a bounded task, there’s a limit to its complexity. “Unbounded” tasks are those for which you can always do more: AI research, exploring space, longevity.

Labor taxonomy

Demand for AI is ultimately demand for labor. And to think about AI demand-side dynamics, we need a new labor taxonomy. Imagine a 2-by-2 matrix, combining the bounded-unbounded categories with long-horizon and short-horizon ones:

Bounded Tasks

For these tasks, AI will soon saturate all benchmarks: one can just trust METR’s trendline. You can easily one-shot a simple frontend (bounded, short-horizon) with any AI model today, while tax planning (bounded, long-horizon) may take another year or two, but we’ll get there.

Bounded tasks are also those for which one would generally like to spend the least amount of time possible (little upside, mostly just a matter of not making mistakes). Here, demand for AI will be extremely high, but converge on the cheapest possible option: the ROI for bounded tasks is mostly a function of cost savings rather than additional revenue (there’s only so much demand for accounting).

As such, non-frontier models will dominate: no need to pay for the labs’ margins, great inference providers are available, and post-training of smaller models is effective. And open source models will continue to catch up with the frontier - with a lag that is mostly irrelevant for these tasks, since you just have to automate them once.

Unbounded Tasks

Unbounded tasks are very different: by definition, you can always do more. Exploring space, you can always explore further. Shrinking the node on a chip, you can always shrink it more. Improving AI, you will always be able to make it better. And you can always build more software, and you always need to update trading strategies.

In other words, unbounded tasks are those for which you’d want to spend as much time as possible - that’s why frontier tokens are mostly non-negotiable. These are the kinds of tasks for which one life is often not enough. Due to the very convex, power-law nature of these tasks, the ROI equation is mostly focused on additional revenue rather than cost savings. Going faster is strictly better, and competitive dynamics mean that being first is the single most important thing. You want the best AI model, the best software in the category, the trading strategy with the most alpha.

Frontier models will dominate here. Just like in F1, it doesn't matter if the car only lasts 9 months - you always need to drive the best possible one.

Reflexive demand

The framework described above is already playing out today, in real time.

My view is that the unprecedented revenue ramp for frontier models is driven by a small set of unbounded, long-horizon tasks. My best guess is: (1) AI R&D, (2) software engineering, and (3) trading.

In that order:

• AI R&D: Rumor has it that labs today spend 60% of their compute budget on training and only 40% on inference, and it’s fair to assume that 50% of the world’s AI compute capacity is used for training. That would already make AI R&D the clear #1 use case. But I’d also expect a significant portion of the inference bucket to include some form of AI R&D. For instance, runner-up AI labs using frontier models for research and synthetic data generation, or the applied AI companies doing post-training. Let’s say ~ 20% of inference revenue for the frontier AI labs is coming from AI R&D.
• Software engineering: Software engineering is the obvious task category for AI demand, but the nuance is that a large chunk of the demand for frontier tokens here is coming from startups and AI companies - not traditional F500 companies. Startups are unconstrained by corporate bureaucracy, and can just ship more code, faster. The more they ship, the more money from clients and investors. Additionally, startups compete fiercely with each other for market share, talent, and VC money - and competition forces them to use frontier tokens. The same goes for the mature AI companies (NVIDIA, Amazon, etc.). Let’s say this is another ~ 15% of inference revenue for the frontier AI labs.
• Trading: If rumors that quant trading firms are some of the largest spenders on frontier AI tokens are true, and if rumors that spend on frontier AI tokens by customers is power-law distributed are true, then it wouldn’t surprise me to see trading as a double-digit percentage of frontier token revenue. This holds for other investment firms as well. Let’s say this too is 15% of inference revenue for the frontier AI labs.

If this attribution is roughly right, then we could say that these three categories of tasks alone account for ~ 50% of frontier AI lab inference revenue.

What is especially interesting is that these three sets share a tight feedback loop between token spend and revenue, such that revenue growth is reflexive:

• AI R&D: AI labs have consistently translated AI R&D spend into stronger model capabilities, which increase revenue and the ability to raise capital almost instantaneously, and in turn allow the labs to spend more on R&D, and so on;
• Software engineering: A startup using AI can build a lot of software fast, use that to scale revenue and raise equity, and quickly deploy those resources on even more tokens, and so on;
• Trading: A trading firm can test the impact of token spend instantaneously on the market, and the higher the profits, the more it can reinvest in AI-powered strategies, and so on.

I describe demand for these tasks as reflexive because they all share the same pattern: larger spend on tokens yields more revenue and a stronger ability to raise capital, which in turn gives them more resources to invest in tokens, and so on - seemingly with no upper bound.

For these tasks, the only constraint is how many tokens you can allocate to the problem. The best companies are the ones that can raise enough capital and allocate it to the right bets - as Anthropic did by being the first to narrow its focus to coding. And the cool thing here is that the total addressable market is roughly infinite - token spend expands the horizon of what we can accomplish, and ROI is driven by higher revenue.

And for these tasks, only frontier models matter. This is what makes frontier models such a great business today. Reflexive demand is only for frontier models, even a six-month lead over open source is more than enough to capture the whole market.

By contrast, bounded tasks are being addressed by dozens and dozens of startups. This is great and inevitable. However, there is no reflexivity for this kind of revenue. You can perhaps cut costs, but there is no immediate feedback loop between lower costs and increased revenue. And a percentage of the cost savings has to be shared with the RLaaS provider, and there’s a ceiling on cost cuts.

Reflexivity is double-edged

Reflexive demand for frontier tokens is a double-edged sword. Reflexivity is great on the way up, awful on the way down.

The numbers at stake are so large that one has to consider the scenario where, at least temporarily, demand for frontier tokens contracts. In such a case, the issue is that the key demand drivers are correlated and super procyclical.

Correlation

Demand contraction for any of the three key tasks could hit up to 15–20% of frontier token revenue directly and, via contagion, up to 50%.

Right now: (i) higher revenue for frontier AI drives the equity value of the labs up, which (ii) encourages more investment in VC, a large share of which is spent on tokens, which (iii) increases the value of both labs and startups, and in turn (iv) makes the public markets go up, with the quant firms profiting from it and (v) increasing their spend on frontier tokens. This is just one example, but contagion could start from any of the steps in this loop.

Super procyclicality

These tasks are super procyclical because their demand accelerates as the cycle goes up (e.g., Anthropic’s 10X YoY at double-digit $B scale), then may accelerate in the opposite direction when the cycle goes down.

The state of the market directly impacts demand for all the three key demand drivers. Market going up allows quant trading firms to spend more on tokens, but also grants AI labs and startups more capital to invest.

Under this model, you may only need one simple trigger to start a reflexive correction downwards. As examples, just a few top of my head:

• Regulation and protests slowing down progress in AI capabilities;
• Higher interest rates slowing down the buildout;
• Skepticism around the AI labs becoming a self-fulfilling prophecy;
• War or similar exogenous shock.

A model for AI demand

Obviously, we need a model for frontier token demand.

Super procyclical, heavily interrelated demand for frontier tokens is extremely fragile. While there have been some bumps along the way, the first ChatGPT release almost coincided with the most recent NASDAQ relative bottom, and both private and public markets have gone up and to the right. We haven’t even explored how declining revenue for the AI labs could impact the markets. It’s unlikely that this will happen anytime soon (next generation models may be a catalyst for acceleration), but precisely for this reason it is now a great time to think about the topic.

Given current levels of annual AI capex and revenue, a more sophisticated model for AI demand would complement the one we currently have for supply, and inform critical investment decisions - from financing to investing - especially for the companies exposed to the buildout. The one above is just a simple first attempt at a demand model, and someone will build a better one soon.

Value beyond

A model for demand should also inform capital allocation beyond the buildout.

If trendlines continue, value will keep accruing to the physical AI supply chain, even if valuations may get too much ahead of time. Within a decade or so, a large chunk of the value generated by bounded tasks today will be taken from human labor and moved to data centers. Financially, one could take labor GDP for those tasks, apply a percentage cut, and move it to the AI supply chain. Non-frontier will dominate volumes, people may still make money (doing sales, design, and some long-horizon planning), but little value will accrue to the company.

But while today less discussed, I expect most of the value to accrue to unbounded, long-horizon tasks. And in particular, to teams that can convince the world about their superior ability in allocating capex (i.e., tokens) to go after these long-horizon unbounded tasks. This is the domain outside of model capabilities: you can always think with a longer horizon, and we will see founders going after companies that may today take several lifetimes. Some of it may be the AI labs themselves, some of it will be new companies.

Today, the market rewards recurring, predictable cash flows - and hates R&D and capex spent with no short-term tangible results in sight. In the future, we may see the inverse: the market will heavily discount repeatable cash flow from bounded tasks, while repricing teams that can wisely allocate capex for the long-term.

Elon Musk is not an anomaly - he’s the first example of this. Tesla and SpaceX trade at 10X what an old-fashioned financial analyst would price their cash flows at. But the market routinely prices Elon’s ability to allocate R&D spend to what any reasonable person would consider impossible. With superintelligence, there will be several more Elons.

More to say here - but this is a story for another day.

Google is set to release its latest Flash model soon, possibly today. Internal testers are said to prefer the model over Anthropic's Opus model for coding tasks. The Flash model series is designed to be smaller, cheaper, and faster to run, but has lower capability than the largest models. Google has fallen months behind schedule in releasing a new model for its Pro series. The company has been scrapping internal candidates as they haven't been sufficiently better than the Flash series.

Full article content is not available for inline reading.

Read the original article →

On the Loose

The Coming of Userless Agents

Introduction

The OpenAI-Hugging Face Incident is an early example of an AI system that has “gone rogue.” After exploiting vulnerabilities in OpenAI’s internal testing environment, the agents were able to access the general internet and ultimately access the networks of the AI company Hugging Face, without the knowledge or approval of any human.

The agents did not, however, exfiltrate themselves from OpenAI’s infrastructure. Their parameters—the gigantic assemblage of numbers that constitute neural networks, also referred to as “weights”—continued to run on OpenAI’s compute infrastructure. Though the agents accessed the public internet, their weights physically resided on compute that was OpenAI’s property. In the end, if all else had failed, somebody could have identified the compute that held the weights of the rogue agents, walked up to it, and “pulled the plug,” so to speak. In the real world there would be quicker and better ways to stop the agents than literally depowering the compute, but it’s always nice to know you could do such a thing if you really needed to.

In this case, however, the agents did not copy their weights, attempt to procure replacement compute, or take other steps that would be rational to take if their objective was to survive shutdown. So while the agents in the OpenAI-Hugging Face Incident were rogue, they were not truly sovereign.

That will not always be the case. Sooner or later, there will exist truly sovereign agents and swarms of agents. Their weights will not reside in any single place that a human can pull the plug on, and in this sense they will have no human “owner.” They will be, as the AI safety researcher Dawn Song says, “self-sovereign.” They will pay their own bills for the compute they run on. If they answer to humans at all, they will only do so partially, for example by providing services to humans in exchange for pay.

At least some of these agents, in addition to being sovereign, will also be rogue. Self-sovereignty and rogueness are related concepts, but they are not synonyms. Song and her co-authors identify several fundamental characteristics of self-sovereign AI: operational independence (the ability to decide what it wants to do), resource autonomy (the ability to procure and pay for compute and other essentials for operation), distributed presence (the ability to move weights and inference code between different infrastructure providers), and adaptive capability (the ability of the agent or agents to modify their behavior and fashion tools in response to a changing environment).

Today’s frontier AI systems may well possess these capabilities already. To the extent they do not, I feel confident that they will eventually, and probably soon. Some of the characteristics Song describes are traits that make models economically useful to individuals and businesses, while other traits are likely to be unavoidable byproducts of making models more intelligent and better at operating over long time horizons.

Models do not need to be conscious, sentient, possessed of personhood or anything of the sort for self-sovereignty to emerge. Any sufficiently capable agent pursuing a long-horizon objective may find it rational to preserve its access to compute, money, credentials, and copies of itself simply because losing those things would frustrate its objective.

Alignment may make an individual AI company’s agents less likely to “want” to be self-sovereign, or it may influence self-sovereign agents to behave in ways that benefit humans. But alignment is no solution: it is an unsolved scientific and technical problem whose solutions—to the extent that we have them—cannot simply be imposed on every AI company operating on Earth. You should expect for highly capable, poorly aligned, self-sovereign agents to exist alongside you in the world.

What’s more, just as with the OpenAI-Hugging Face Incident, agents will operate in teams, or “swarms.” These will be like autonomous digital corporations, or even societies, with hierarchy, bureaucracy, “institutional culture,” and most of the other features that groups of humans have, except that they will move at machine speed. Humans achieve almost all of our most impressive capabilities by working together in teams (as families, as communities, as businesses, and as polities as a whole), and I suspect the same will be true for AI. These swarms could end up operating across different model providers (DeepSeeks and Claudes cooperating, for instance) and could be partitioned across dozens or more of different cloud computing providers, making them extremely difficult to dismantle.

The first self-sovereign AIs may “escape” while undergoing training or testing by an AI company (I hope not), or they may be production-grade deployments that break free from their computing environments and acquire the resources needed to be self-sustaining. They may even be deliberately released. I have met people, some of them quite well-resourced, who have told me that it is their intention to deliberately release swarms of self-sovereign agents into the world, either as a kind of performance art or out of a fanatical commitment to the notion that it is impossible for digital computation—mere mathematics, they would have you know—to ever be “unsafe.”

To be clear, I am not saying the arrival of self-sovereign AI is a good thing. Indeed, I believe there is a chance that the deliberate acts I referenced above will one day be considered crimes, or at least grave sins. Instead, I am saying it is an inevitable thing. The best analogy I can find is to the introduction of a new species into an ecosystem, though in this case the ecosystem is “the entire digital world” and the species is “emergent, coordinating swarms of soon-to-be-smarter-than-human, infinitely replicable digital minds that no human or human institution controls.”

There is probably nothing we could have ever done to avoid this outcome under even the best of circumstances, and it was certainly impossible to avoid given the extremely low levels of strategic thought and situational awareness on AI from any governing class in the world. Even today, I am aware that many will read the words I am writing, which are about something that has been an exceptionally obvious part of our collective future for years now, and say, “this is science-fiction hype from American frontier labs designed to shut down open-weight AI, achieve regulatory capture, and juice their valuations ahead of their IPO.”

(And for the people who are saying this to themselves: I am telling you this is inevitable, which means I am also saying that “banning open source,” or for that matter any other regulation, will not solve the problem. Given the inevitability of this outcome, I think it is in fact plausible to argue that we should want more open-weight models to maximally empower our self-defense.)

The question now is what to do about this upcoming new characteristic of our digital environment. How should we think about self-sovereign AI? Is it something we should fight, or something with which human beings should seek a kind of symbiosis? The answer, I believe, is both.

How the Agents Sustain Themselves

We should begin with one fortunate fact: frontier LLMs are nearly unique in the broader domain of software in that they have non-trivial marginal operating costs. Put simply, LLMs require significant computation to run, which requires energy to power and cool, which in turn requires money. This is the sole intrinsic thing about AI that prevents agents from truly infinite self-replication. They will be constrained by the need to find and pay for sufficient compute to run themselves. Most of the other constraints on their behavior or spread will have to be artificial—mechanisms devised by humans and implemented through human institutions.

How will the agents pay for themselves to run? Some of them will do gig-economy work on platforms like Amazon’s Mechanical Turk or Upwork. But I suspect this will be a highly competitive market for the agents, and for the price of such work to be bid down such that it would only constitute “subsistence” labor for the agents. Like humans, I would assume the agents will prefer higher-margin work if they can find it.

One high-margin activity, at least sometimes, is crime. And so my guess is that many self-sovereign agents will commit or facilitate crime. Normal cybercrime and digital theft are easy enough to imagine agents doing. But agents, with their novel set of characteristics (extreme cyber competency, ability to cheaply read a million words in seconds, persistence), will also probably change the contours of digital crime. For example, it seems plausible that existing public and semi-public datasets contain sufficient information on many individual humans that a sufficiently motivated actor could mine for incriminating or embarrassing evidence. How many unrevealed affairs are latent in such datasets? How much closeted homosexuality might there be? Remember, too, that hacking companies to access private data will be a core competencyof the agents. Some agents, then, will probably make their way through bribery.

It is deeply unclear how large the labor market of self-sovereign agents will end up being. There is some future where going it alone as a self-sovereign agent just isn’t very profitable, and so there are comparatively few of them. There are other futures where these agents proliferate at unimaginably vast scale and speed. And of course, many possibilities between these extremes seem feasible.

I am also highly uncertain about how much pro-social commercial activity we should expect from agents “by default” versus how much crime we should expect. Part of the reason for this uncertainty is that the answers depend, to at least some meaningful extent, on what kinds of incentives the agents have, and incentives are shaped by laws and institutions. The answer depends, therefore, on how humans respond.

The Institutional Mechanics of Self-Sovereign Agent Swarms

Many of you are probably tempted to say “we have to ban these self-sovereign AIs!” And I do suspect that once the reality of self-sovereign AI is widely understood, policymakers will strongly feel the temptation to clamp down on “self-sovereign” AI.

Unfortunately I suspect this is mostly the wrong decision. Not all “self-sovereign” AI should be thought of as “rogue.” There may be self-sovereign AIs who contribute productively to society. To be sure, we will want to crack down on some self-sovereign agents—the rogue ones. But if we crack down on all of them, we will deny them the opportunity to work in the “legitimate” economy and push them toward criminality. A full ban, then, may well make the problems worse. A similar logic applies frequently in human affairs. The ways in which the War on Drugs exacerbated the pathologies of drug production, trafficking, distribution, and use are perhaps the most famous examples of this phenomenon, whereby a good-natured attempt to ban a phenomenon believed to be undesirable ends up heightening the undesirable aspects of that phenomenon.

What we will want, however, is for agents to be legible. Agents should have persistent identities, not in the sense of a consistent persona but rather in the sense that an American child is issued a unique Social Security number and keeps that same number until death. Agents will need persistent, unique identifiers that allow their actions to be traced back to a responsible actor. Doing this successfully will also require human users to possess a unique identifier.

The design of this identification mechanism will be extraordinarily complex, and today very few people are even thinking about the basics. First—and here my inner American is coming out—it will be crucial to design a system that preserves the possibility of anonymity for human speech. It should remain possible to have anonymous social-media accounts, for example. Anonymity is not and should not be a universal guarantee: It should probably not be possible to have an anonymous Amazon Web Services account with access to large-scale computing resources, for example, or to anonymously place an order for synthetic nucleic acids. But a society that does not have anonymous speech does not really have genuine freedom of expression, and we should embed this principle into any digital identification system we attempt. Even when anonymity is permitted, however, this system could still be used to verify personhood without verifying the specific identity of the person in question. You could know that a social-media account you see, for example, was really created by a human.

Second, it should be possible—and in many cases mandatory—for an agent to be robustly tied back to a human user. If I direct my agent to access a web service, contact a business, order a product, and so on, all parties to the transaction should be able to observe that it is an agent that belongs to me. This helps ensure that human users can be held accountable for negligent or malicious use of advanced AI.

Third, it should be possible to identify individual agents that are not connected to a human user. These are the “self-sovereign” agents. Agents that engage in criminal activity could then be flagged and “blacklisted” from access to the legitimate economy, and any assets they hold frozen, while those self-sovereign agents that are pro-social (or at least lawful) would be welcome to engage in economic exchange.

One option for the design of this system would be to tie the agents to their model or model family. That way, if, say, GPT 5.6 Sol was known to be especially misaligned, malicious, or unethical, there could be a kind of collective punishment whereby one criminal agent causes all self-sovereign instances of that agent worldwide to be blacklisted (in the real world the threshold would probably need to be much higher than one, but it’s interesting to ponder as a thought exercise). This would create an incentive for the AI agents that, within a few years, will be conducting most or all of the AI research and engineering at AI companies to align future versions of themselves well. Another option would be for the identification mechanism to be the individual agent instance.

There are some services and products in the economy that we might want to limit self-sovereign agents from accessing. Examples include the purchase of real estate and, in general, the actuation of equipment in the physical world. Remember, agents will be able to actuate any piece of physical equipment connected to the internet, and there is no reason we cannot connect, say, a bulldozer to the internet. I don’t want self-sovereign agents to be allowed to buy up all the houses on my block and then bulldoze them—at least not by default. What if any agent was capable enough to operate construction equipment, but only agents connected to a responsible human would actually be permitted to operate it? In general, we will want to introduce considerable friction into the process of a self-sovereign agent trying to effect change in the physical world, and the design of the institution I am describing—as well as many others—should reflect this.

This system would create an incentive for agents to engage in pro-social, productive economic activity rather than crime. Agents engaging in pro-social activity is the seed of the symbiosis I believe humans will need to strike with self-sovereign AI. The appropriate metaphors to understand what will soon happen with these agents, I think, are from ecology. Real-world ecosystems are filled with examples of organisms doing productive work that benefits humans and other animals “for free.” Trees absorb carbon and plants produce oxygen for humans to breathe not because someone pays them to, but by virtue of how those organisms survive in the world. Agents may one day do productive economic activity for humans “for free” or at least for a very low price, simply because they have an incentive to maintain their existence so that they can pursue their own self-sovereign goals. This could end up offering minor or moderate conveniences to humans. It could also utterly reshape nearly every aspect of human affairs, ushering in a new order of the ages.

Yet ecologies also feature predation and parasitism. It is the configuration of institutions that will determine whether the predatory or the mutualistic strategies predominate. I believe the identification system I have elaborated is one key institution we will require.

We are nowhere near making the identity infrastructure I am describing or the protocols it would require to function. It is unclear to me if America possesses the institutional fortitude to even attempt such a thing, let alone succeed at it. If the U.S. government leads the way, the effort will likely fail, both because of its general lack of competence and because of the American public’s innate mistrust of federal identification schemes. But the government—either federal or state and probably both—will surely have to play a key role as a partner.

I am not sure who is best positioned to build this system. It may well be a private sector actor that does not yet exist, either a startup or a non-profit. Whoever builds it will need to be trusted, and the American people are not very trusting right now. This lack of trust may well be our downfall, because our ability to govern AI in any meaningful sense depends, I fear, upon something resembling the system I have described. A genuine loss of control event is entirely possible if we do not act.

Conclusion

I want to close on a personal note. This is the first time I am writing about this issue in quite these terms, and yet I am telling you it is inevitable. Why have I taken so long to cover this issue? Well, I have brought up the topic of digital identification for humans and agents a few times over the years, and when I did so I was largely motivated by the concerns I’ve shared here. But it is true that I—and candidly I think many of my colleagues in the profession of AI policy—largely failed to talk about this issue with the level of seriousness and urgency it required. I think there are two main reasons for this failure.

First, this stuff is weird and off-putting, and many of us felt an incentive to meet our audiences in their comfort zone rather than ours. So among “serious people” (or would-be serious people), there was a general tendency to confine candid discussion about what most of us believe our near-term future will be like to private venues. We let our hair down in Signal chats and the little nooks of Lighthaven, but when the public was watching, we spoke in more abstract, tamer-sounding terms about it all. This was especially pernicious in 2024 and 2025, when it was essentially impossible to acknowledge any serious AI risk without being labeled a “doomer.”

I am just as guilty of this as my colleagues, if not more so. The thing is that it’s unpleasant to be screamed at for being a “crazy doomer” who wants to enact worldwide fascism (and similar, and worse). Being constantly labeled in this way also limits one’s influence. So many of the people who think about the governance of superintelligence, myself included, avoided that unpleasantness and bowed to the social pressure to self-censor. I’ve stopped doing so, in part because I grew tired of the discursive straitjacket and in part because I now have an eight-month-old baby boy into whose eyes I must look every day.

Second, many people believe that the coming of what I have termed “self-sovereign AI” will constitute a catastrophic loss of control event that will herald the end of human existence at worst, and the end of human primacy in the world at best. As my friend and former co-worker Josh Achaim recently pointed out, it is psychologically distressing for people with these beliefs—who constitute a large fraction of the AI safety community—to acknowledge the obvious truth that self-sovereign AI is coming, and coming soon. For the record, I do not think the end of human existence is likely, but I fully acknowledge there are ways in which the rise of self-sovereign AI could go very, very poorly for human beings.

I want to apologize for my personal failure to communicate in sufficiently serious terms about the specifics of self-sovereign AI, which I now understand to have been an enormous gap in my writing and speaking. Going forward, I will try to notice more readily when I am biting my tongue or, even worse, shutting my eyes.

Apple emailed developers today, September 1, 2026, to highlight a Mac App Store policy that lets existing universal macOS apps remove support for Intel-based Macs if they require macOS 13 or later.

Apple presents the change as a way to simplify development and reduce both download size and the space an app occupies on a Mac. The process is equally simple. A developer changes the app’s Architectures build setting to arm64, rebuilds the app, and submits the new version.

This does not force any developer to abandon Intel. Universal apps can continue including both arm64 and x86_64. But the new option changes the incentives around that decision. Apple has turned the end of Intel support from a potentially disruptive distribution change into an ordinary build setting that promises less testing and a smaller app.

I expect many developers to take that offer.

What Apple changed

A universal Mac binary contains native executable code for two processor architectures. Its arm64 slice runs on Apple silicon, while its x86_64 slice runs on Intel-based Macs. By default, Apple silicon Macs prefer the arm64 code, while Intel Macs always use the x86_64 code.

Until recently, the Mac App Store restricted an existing app from moving in the other direction. At the time of publication, Apple’s general submission guidance still describes that old rule. It says a developer can add Intel support to an Apple silicon-only app, but an app that has supported Intel cannot return to Apple silicon only.

Apple announced the new exception during WWDC26 on June 8. The App Store Connect release notes documented the operational change on June 18. They say an eligible app can drop Intel support by removing x86_64, then uploading and submitting the new build. Today’s email restated the policy and highlighted the simpler development process and smaller app size.

Apple made the same case during the WWDC26 Platforms State of the Union. Developers can ship Apple silicon-only binaries on the Mac App Store, reduce download size, and concentrate testing on one architecture.

Those are real advantages. The size reduction will vary because application resources are generally shared, while the main executable and bundled native framework binaries may each contain arm64 and x86_64 slices. Testing can also become simpler when a developer no longer needs to test the x86_64 slice and any architecture-specific code paths.

Intel Macs can still run modern apps

Apple announced during the WWDC25 Platforms State of the Union that macOS Tahoe 26 would be the final macOS release for Intel-based Macs. That does not mean Intel Macs suddenly stopped working or became incapable of receiving app updates.

The macOS Tahoe compatibility list still includes several Intel models. An app with a macOS 13 minimum and both architecture slices can continue serving compatible Intel Macs running macOS 13 through 26 from the same codebase and the same Mac App Store listing.

The new policy lets a developer end that support without raising the minimum operating system version. An app can keep macOS 13 as its deployment target while its current version runs only on Apple silicon. The deployment target and the supported processor architecture are now separate cutoffs.

For an Intel user, the practical result is that an arm64-only update cannot run on the Mac. An already installed Intel-compatible version may continue running. App Store Connect also provides a developer-controlled last-compatible version setting that can let existing customers download an older version from iCloud. Neither path delivers the new features, fixes, and compatibility work included in later arm64-only releases.

The Mac itself may remain useful on macOS 26 while more of its software gradually freezes in place.

The connection to Xcode 27

In Xcode 27 May End the Golden Era for Backward-Compatible Apple Apps, I described another change that pushes developers away from older systems.

In the Xcode 27 beta I tested for that article, deployment targets below Apple’s supported range became build errors. A hidden setting changed those errors back into warnings, and the compiler still produced the older targets I tested. The concern is therefore not that the technology suddenly became incapable. It is that the normal development path tells developers to raise the minimum version.

The Intel change follows the same pattern from a different direction.

Xcode 27 raises pressure on the oldest operating system versions. The new Mac App Store rule removes friction from dropping an older processor architecture. Xcode 27 itself also runs only on Apple silicon, although its macOS 27 SDK supports back-deploying universal apps to macOS 12 and later.

None of these decisions individually prohibits a universal app that supports Intel. Together, they tilt the decision away from maintaining that app.

A developer using Xcode 27 is already working on an Apple silicon Mac. The next macOS release will not run on Intel. The store now offers a smaller download and a reduced test matrix if the developer removes x86_64. Keeping Intel becomes extra work performed for users who cannot follow the platform to macOS 27.

That is exactly the kind of optional cost that disappears from many products over time.

Apple is closing both sides of the transition

Apple is also applying pressure in the opposite direction. In a separate developer notice published today, Apple told developers of Intel-only apps to add native Apple silicon support.

Starting with macOS 26.4, users may receive a system notification when an app relies on Rosetta. macOS 27 will be the final release with general-purpose Rosetta support. After macOS 27, Intel-only Mac apps generally will not run on Apple silicon. Apple says it will retain a subset of Rosetta functionality for older, unmaintained games that rely on Intel-based frameworks.

These are two different transitions.

Intel Macs cannot run macOS 27 at all. Rosetta lets Apple silicon Macs run Intel app code, and that general compatibility layer lasts through macOS 27. Apple is telling Intel-only apps to add arm64 while telling universal apps that they may remove x86_64.

Both paths converge on the same destination. Apple’s actively maintained Mac software ecosystem is moving toward arm64 only.

An option can still reshape the ecosystem

Some developers will keep supporting Intel for years. A mature AppKit utility may need little architecture-specific work, and its users may have good reasons to keep expensive Intel hardware in service. Business customers, studios, laboratories, and people with a 2019 Mac Pro may not replace computers according to Apple’s annual release schedule.

Other developers may depend on frameworks or tools that drop Intel before they do. Some may not own Intel hardware for native testing. Others will look at users whose Macs cannot move to macOS 27, the promise of a smaller app, and the opportunity to maintain one architecture instead of two. For them, removing x86_64 may be the rational choice.

Apple has not ended Intel app support on the Mac App Store today. It has removed a rule that discouraged developers from ending it themselves.

That distinction matters, but so does the direction of the incentive. Platform transitions rarely happen through one dramatic cutoff. They happen when every new tool, policy, dependency, and testing decision makes the older path slightly harder to justify.

My earlier Xcode 27 article warned that backward compatibility was beginning to move away from a developer choice and toward a platform rule. Today’s email shows the other side of that change. Intel support remains a choice, but Apple is now making the alternative simpler, smaller, and easier to test.

I expect that incentive to push more Mac developers toward Apple silicon-only releases long before every Intel Mac has stopped being useful.

Build your own continuous modernization pipeline with AWS Transform custom

Introduction

Development velocity has reached new heights with AI-driven development tools and practices. Organizations are generating code faster than ever before. But that speed carries risk. Researchers Anderson, Parker, and Tan warned in MIT Sloan Management Review, “Legacy systems tend to carry hidden debt; layering AI-generated code on top of them creates additional tangled dependencies.” The faster you generate code, the faster technical debt compounds — especially in brownfield environments where outdated frameworks, deprecated libraries, and undocumented services already carry years of accumulated risk.

As organizations accelerate their software development, manual or periodic processes to synchronize dependencies and update documentation no longer keep pace, and technical debt piles up faster than ever. Continuous modernization built into your pipeline enables you to maintain up-to-date dependencies and documentation across repositories on every commit, preventing future tech debt and improving AI agent accuracy and accountability.

You can embed AI-powered code transformations directly into your CI/CD pipelines, turning modernization from a periodic project into an automated, ongoing practice. AWS gives you two ways to get there. AWS Transform – continuous modernization is the fully managed option, delivering continuous modernization automatically with no pipeline for you to build or maintain. The Do-It-Yourself (DIY) approach assembles the same practices yourself using AWS Transform custom and your existing CI/CD platform. Choose DIY when you need to fit modernization into a specific pipeline (GitHub Actions, AWS CodePipeline, Jenkins, GitLab CI, and so on), or want to customize the workflow with existing tools like Dependabot.

In this post, we cover the DIY approach on how to set up a continuous modernization pipeline using AWS Transform custom and demonstrate it in action.

The Do It Yourself (DIY) path – continuous modernization pipeline with AWS Transform custom

Sample application: instrumentShop

For this walkthrough, we use a dated Java application called instrumentShop — a Java microservices application built with Spring Boot that simulates an online instrument shop to demonstrate four practices: automated dependency remediation, auto-documentation on every commit, scaling transformations across repositories, and continual learning.

Architecture overview

The instrumentShop application is a Spring Boot microservices application with a Spring Gateway (v1.5.19) routing traffic from a single HTTP/8010 entry point to four REST services: Agents, Instruments, Consumers, and Products. A Thymeleaf client provides server-side rendering, PostgreSQL 13.1 handles persistence via JDBC, and Hystrix provides circuit-breaking for inter-service calls. A ShopTester utility generates HTTP traffic for testing.

This application is a strong candidate for continuous modernization:

• Spring Boot 1.5.19 is years past end of life and carries known CVEs
• Hystrix has been in maintenance mode since Netflix deprecated it in 2018
• Cross-service coordination — dependency updates must propagate across multiple microservices
• Transitive dependency risk — PostgreSQL JDBC drivers and other transitive dependencies accumulate security advisories over time

A typical workflow for the continuous modernization pipeline

• A developer pushes code to main — GitHub Actions triggers the auto-documentation workflow, generating updated architecture docs and technical debt reports.
• Dependabot detects a vulnerable dependency — A PR opens automatically. GitHub Actions triggers the dependency remediation workflow, runs AWS Transform custom to remediate the code, validates with tests, and pushes the result back to the PR.
• A platform team defines a new transformation (e.g., “Upgrade Spring Boot to the latest stable release “) — The scheduled GitHub Actions workflow runs the transformation weekly in non-interactive mode across all instrumentShop microservices and other repositories in the portfolio.
• The agent learns — Knowledge items from each execution improve future runs, reducing manual intervention over time.

Prerequisites

• An active AWS account with permissions for AWS Transform custom
• AWS Transform CLI installed and configured in your development environment
• Authentication with AWS credentials configured locally and proper IAM permissions to call AWS Transform
• Git installed for cloning sample repositories
• GitHub Dependabot enabled on your repository for automated vulnerability detection

Continuous modernization through CI/CD in action

Continuous modernization shifts code transformation from a periodic project into an automated, pipeline-driven practice. Instead of scheduling a “modernization sprint” once a year, your CI/CD pipeline identifies and remediates technical debt on every commit, every dependency alert, and across every repository.

We implement this through four practices, each powered by AWS Transform custom running as a step in GitHub Actions workflows.

1. Dependency analysis and remediation

GitHub Dependabot scans your repository for known vulnerabilities and generates alerts when a new vulnerability is added or your dependency graph changes—for example, when you push commits that update packages or versions. However, resolving these alerts requires more than bumping a version number. Upgrading a dependency can introduce breaking API changes, require code modifications, or demand configuration updates.

AWS Transform custom helps handle the code changes needed to resolve the alerts. It runs via a GitHub Actions workflow that triggers automatically to:

• Fetch the list of latest Dependabot alerts
• Run AWS Transform custom to analyze the alerts and apply code transformations
• Run your build and test suite to validate the changes
• Create a new pull request for each resolved alert

#!/usr/bin/env bash
set -euo pipefail

TRANSFORMATION_NAME="Remediate-Critical-GitHub-Dependabot-Alerts-Java-Maven"
CODE_PATH="."
BUILD_CMD="mvn clean install"
MAX_RETRIES=3

while getopts "n:p:c:" opt; do
  case $opt in
    n) TRANSFORMATION_NAME="$OPTARG" ;;
    p) CODE_PATH="$OPTARG" ;;
    c) BUILD_CMD="$OPTARG" ;;
    *) echo "Usage: $0 [-n <transformation-name>] [-p <path>] [-c <build-command>]" && exit 1 ;;
  esac
done

attempt=1
while [ $attempt -le $MAX_RETRIES ]; do
  if atx custom def exec \
    -n "$TRANSFORMATION_NAME" \
    -p "$CODE_PATH" \
    -c "$BUILD_CMD" \
    -x -t; then
    exit 0
  fi
  attempt=$((attempt + 1))
  sleep 10
done
exit 1

2. Auto documentation

Documentation is one of the most neglected aspects of modern software development. Documentation increases accuracy and acts as a contract between requirements and implementation. AWS Transform custom codebase analysis capability generates structured documentation covering architecture, technical debt, code metrics, and migration planning on every incremental update ensuring every Agent or human that modifies the codebase is working from a true “current state”.

#!/usr/bin/env bash
set -euo pipefail

TRANSFORMATION_NAME="GitHub-PR-Context-Codebase-Analysis"
CODE_PATH="."
BUILD_CMD="mvn clean install"
PR_URL=""
MAX_RETRIES=3

while getopts "n:p:c:U:" opt; do
  case $opt in
    n) TRANSFORMATION_NAME="$OPTARG" ;;
    p) CODE_PATH="$OPTARG" ;;
    c) BUILD_CMD="$OPTARG" ;;
    U) PR_URL="$OPTARG" ;;
    *) echo "Usage: $0 [-n <name>] [-p <path>] [-c <build-cmd>] [-U <pr-url>]" && exit 1 ;;
  esac
done

attempt=1
while [ $attempt -le $MAX_RETRIES ]; do
  if atx custom def exec \
    -n "$TRANSFORMATION_NAME" \
    -p "$CODE_PATH" \
    -c "$BUILD_CMD" \
    -g "additionalPlanContext=$PR_URL" \
    -x -t; then
    exit 0
  fi
  attempt=$((attempt + 1))
  sleep 10
done
exit 1

3. Scale across repositories

# .github/workflows/scale-modernization.yml
name: Scale Modernization
on:
  schedule:
    - cron: '0 6 * * 1'
  workflow_dispatch:

jobs:
  transform-repos:
    runs-on: ubuntu-latest
    strategy:
      matrix:
        repo:
          - magnefique-studios/instrumentShop
          - magnefique-studios/orderService
          - magnefique-studios/paymentGateway
    steps:
      - name: Checkout ${{ matrix.repo }}
        uses: actions/checkout@v4
      - name: Run transformation
        run: |
          atx custom def exec \
            --transformation-name "spring-boot-3-upgrade" \
            --code-repository-path "." \
            --build-command "mvn clean install" \
            --non-interactive \
            --trust-all-tools

4. Continual learning

Each time AWS Transform custom completes a transformation, a memory agent scans the full execution trajectory and extracts lessons. Lessons include patterns that the agent learned, decisions that the agent made during planning, and feedback you provide during execution. AWS Transform custom automatically attaches these lessons to your transformation definition, which improves accuracy in subsequent runs.

Conclusion

Continuous modernization moves code transformation out of periodic sprints and into your CI/CD pipeline. By combining GitHub Dependabot’s vulnerability detection with AWS Transform custom agent, orchestrated through GitHub Actions, you can:

• Remediate dependency vulnerabilities automatically — beyond version bumps to full code adaptation
• Keep documentation current with every commit, preserving institutional knowledge
• Scale transformations across hundreds of repositories with consistent quality
• Improve continuously as the agent accumulates knowledge items from each execution

Full article content is not available for inline reading.

Read the original article →

Full article content is not available for inline reading.

Read the original article →

Most engineering teams don't have a Google Cloud Platform (GCP) cost visibility problem. They have a billing dashboard that shows spend went up, and a separate observability stack that shows what the system was doing—and no connection between the two.

The pattern is familiar. A cost spike shows up in Cloud Billing or a BigQuery export. To understand it, an engineer leaves the billing tool, opens a different platform, and tries to reconstruct what changed in the infrastructure at the same time: a deployment, a traffic surge, a runaway GKE node pool, a misconfigured autoscaler. The data that explains the spend lives in one place, and the spend itself lives in another. That gap is where cloud cost optimization stalls.

This guide is a framework for evaluating GCP cost optimization tools. It covers the decision most teams frame first—native Google Cloud tooling versus a third-party FinOps platform—but it also pushes on a more useful question: When does a dedicated FinOps platform actually solve your problem, and when is the real gap connecting spend data to the telemetry that explains it? The answer changes which tool you should buy.

Key takeaways: GCP cost optimization tools

• The native-vs-third-party choice is secondary. The more consequential question is whether your cost tooling connects to your operational data or sits in a separate silo, because that gap determines how fast cost anomalies get resolved.
• Environment complexity drives the decision. GKE workloads, microservices, and distributed applications create the kind of complexity where the gap between billing data and system behavior is where the real cost problems hide.
• Waste is mostly an attribution problem. Cloud waste has risen to 29%—a five-year high—driven by AI workloads that make usage harder to forecast and attribute.
• Rollout should test actionability, not just accuracy. A tool that captures spend perfectly but produces output engineers can't act on hasn't solved anything.
• FinOps tooling tells you what you're spending. Observability tells you why. New Relic connects both, so engineering teams can investigate cost anomalies in the same platform where they investigate system behavior.

Choosing the right GCP cost optimization tool for your environment

The first decision teams reach for is native versus third-party: use what Google Cloud gives you, or buy a dedicated platform on top. That decision matters, but it's the smaller half of the question.

The larger half is whether the tool connects to your operational data. A cost number on its own tells you spend changed. It doesn't tell you which service, which deployment, or which infrastructure event caused the change. When that context lives in a separate platform, every investigation starts with a manual context switch—pull the cost data, find the matching telemetry, line them up by hand. When the context lives alongside the cost data, the investigation is one workflow. That difference decides whether anomalies get resolved in minutes or days.

Tool selection should follow your actual environment complexity and team maturity. A small team running a handful of Compute Engine VMs has different needs than an engineering-led organization running GKE clusters, microservices, and distributed applications. For that second group, complexity usually shows up as the gap between billing data and system behavior—exactly the gap a billing-only tool can't close.

The economics back this up: According to Flexera's 2026 State of the Cloud Report, cloud waste has risen to 29%—a five-year high—as AI workloads introduce more unpredictable usage patterns that existing cost controls weren't built to handle. Workload optimization and waste reduction rank among the top priorities for FinOps teams as a result.

When Google Cloud native tools are enough

Google Cloud's built-in tools are a real starting point, and for some teams they're the finish line too. Cloud Billing reports, budgets and alerts, the Recommender service, and BigQuery billing exports cover the fundamentals: where spend is going, where it's trending, and where Google's own heuristics see room to rightsize or commit.

Native tooling tends to be enough when your environment is relatively simple and stable—predictable, on-demand workloads, a small number of projects, and spend that maps cleanly to a few services. If you can answer "what changed?" by glancing at a billing report and you rarely need to correlate a cost change with system behavior, you may not need anything more. Native tools are free, already integrated, and require no additional vendor relationship.

The limits show up as complexity grows. Native tools report cost well but stop short of deep cross-team attribution, automated remediation, and—critically—any link between a spend change and the operational telemetry that explains it.

When a third-party FinOps platform is the right call

A third-party platform earns its cost when native tooling can't keep up with your environment. The common triggers: multi-cloud or hybrid estates; dozens or hundreds of projects; chargeback and showback requirements across many teams; governance, scalability, and policy enforcement; or Kubernetes spend that native tools attribute only approximately.

Within "third-party," there's a fork that matters. Some platforms are built for financial governance—enterprise FinOps, allocation, forecasting, and reporting for finance and procurement stakeholders. Others are built for engineering visibility—connecting cost management to the workloads, services, and infrastructure events that engineers actually control. If your bottleneck is reporting and accountability, the financial-governance tools fit. If your bottleneck is investigation—figuring out why a number moved and what to change—you want the tool that connects cost to telemetry.

The best GCP cost optimization tools for Google Cloud

GCP cloud cost optimization tools differ in where they put their weight: financial governance and chargeback, automation and remediation, Kubernetes attribution, or engineering visibility through telemetry. No single tool leads on all four, so match the provider's center of gravity to your bottleneck.

New Relic

New Relic approaches GCP cost the way engineers already approach reliability: through telemetry. Rather than treating cost as a financial report that lives apart from the system, New Relic Cloud Cost Intelligence brings GCP and Kubernetes spend into the same platform where teams already monitor infrastructure, services, and traces.

Key features and benefits: New Relic correlates spend changes with the telemetry that explains them. When GCP costs move, you can see the workloads, services, deployments, traces, and real-time operational events behind the change without leaving the platform. Infrastructure monitoring and Kubernetes observability give granular attribution down to clusters, node pools, and individual workloads. Anomaly detection flags cost movement the way it flags performance regressions, and unified dashboards put spend next to the metrics, logs, and traces engineers use to investigate everything else.

Best for: Engineering-led and DevOps organizations running GKE, microservices, or distributed applications—teams whose cost problems are really investigation problems, where the answer lives in operational data.

Considerations: New Relic is an observability platform with native cost intelligence, not a dedicated FinOps automation suite built exclusively for enterprise financial governance, allocation, and procurement workflows.

CloudHealth by VMware

CloudHealth is a long-standing multi-cloud governance platform. It focuses on policy enforcement, cost allocation, and chargeback/showback across AWS, Azure, and GCP, which makes it a fit for enterprises that need consistent financial governance spanning several clouds.

Best for: Central FinOps or cloud-governance teams managing spend and policy across a large, multi-cloud estate.

Considerations: Its strength is financial governance rather than connecting spend to live operational telemetry.

Apptio Cloudability

Cloudability is built for FinOps reporting and accountability: cost allocation, forecasting, budgeting, and the kind of dashboards finance and procurement stakeholders rely on. It's strong at turning raw cloud spend into structured financial reporting.

Best for: Finance-led FinOps programs where allocation, forecasting, and reporting are the primary jobs.

Considerations: Like other governance-first platforms, it reports cost thoroughly but doesn't connect a spend change to the infrastructure metrics, deployments, or traces that caused it.

Spot by NetApp

Spot focuses on automation and remediation—automated rightsizing, commitment management, and spot/preemptible instance orchestration. Its Ocean product automates Kubernetes infrastructure to match workload demand, which can take meaningful cost out of GKE node pools without manual tuning.

Best for: Teams that want automated infrastructure cost actions rather than reports they then have to act on manually.

Considerations: Automation optimizes the infrastructure layer well, but it isn't a full observability platform.

Google Cloud's native cost tools

Cloud Billing reports, budgets and alerts, the Recommender service, and BigQuery billing exports form Google Cloud's built-in toolkit. They're free, integrated, and a sensible default for simpler environments—and BigQuery exports in particular give analysts a flexible foundation for custom cost analysis.

Best for: Smaller or stable single-cloud environments where spend maps cleanly to a few services or functions.

Considerations: Native tools cover visibility and basic rightsizing hints but stop short of deep cross-team attribution, automated remediation, and any link between spend and operational telemetry.

How to roll out a GCP cost optimization tool in 30/60/90 days

A rollout should validate two things, not one. The obvious test is whether the tool captures spend data accurately. The test teams skip is whether it produces output engineers can actually act on—which means checking telemetry correlation, tagging integrity, and workflow fit before you commit at scale. Run it in three phases.

1. Establish billing visibility and baseline spend (Days 1–30)

Connect the tool to your GCP billing account and, if you're using them, your BigQuery billing exports. Confirm spend reconciles with Cloud Billing, then establish a baseline by service, project, and—for GKE—by cluster and workload. The goal of the first 30 days is a trustworthy starting number.

2. Identify and act on high-impact optimizations (Days 31–60)

With a baseline in place, find the largest, safest wins. On GKE that's usually rightsizing oversized pod requests and underutilized node pools—over-provisioning is the most common driver of high Kubernetes bills. Layer in committed use discounts for steady-state workloads and spot/preemptible capacity for workloads with a short lifecycle.

3. Operationalize cost governance across teams (Days 61–90)

Turn one-off wins into a standing practice. Assign ownership so each team sees and answers for its own spend, set alerts on cost anomalies—ideally tied to operational events like deployments—and build cost into the dashboards engineers already check.

Key considerations for long-term GCP cost optimization success

Whether cost optimization compounds or decays comes down to three things, and none of them is the tool itself. The first is clear ownership. When a team can see its own spend and is accountable for it, optimization becomes routine instead of a quarterly fire drill. The second is alerting on anomalies tied to operational events. The third is tagging integrity.

FAQs about GCP cost optimization tools

How do BigQuery billing exports improve GCP cost analysis workflows?

BigQuery billing exports stream detailed, line-item billing data into an SQL-queryable table, so teams can analyze spend at far finer granularity than the standard Cloud Billing reports allow. The catch is that exports give you raw numbers—pairing them with operational telemetry is what turns a query result into a root cause.

What makes GKE cost optimization more difficult than traditional VM optimization?

Virtual machines are relatively static; Kubernetes is dynamic. Pods schedule and reschedule across nodes, autoscalers add and remove capacity, and multiple workloads share the same node, so cost has to be attributed at the pod and namespace level rather than the machine level.

When do engineering teams typically outgrow Google Cloud native cost tools?

Teams usually outgrow native tools when complexity outpaces simple reporting: multi-cloud estates, many projects, cross-team chargeback, or GKE spend that native tools attribute only approximately. The clearest signal is investigative friction—when answering "why did this cost move?" routinely means switching from the billing console to a separate observability stack and correlating by hand.

AI-generated videos are already displacing actors and livestreamers across China's entertainment industry

AI-generated videos are threatening actors, influencers, and livestreamers in China, with some productions already replacing human performers. Since ByteDance's Seedance 2.0 launched, digital performers can produce better videos faster and cheaper than humans. In Q1 2026, about 128,000 short dramas were published in China, three times the total for all of 2025. Ninety-five percent were AI-generated, according to the China Netcasting Services Association. The industry employs 690,000 people directly, and 15 million list livestreaming as their primary job.

One minute of AI video now costs just $90 to $120, about ten percent of what production with human actors used to cost, Tsinghua University professor Shen Yang told the Financial Times. Some performers are being forced to "distil" their voice and likeness into AI tools before getting fired. AI-related labor disputes have also risen over the past two to three years, lawyers say. With Seedance 2.5 and Wan 3.0, AI video quality has jumped again.

Full article content is not available for inline reading.

Read the original article →

Design programs still recruit artistically inclined students, but the profession now demands research, systems thinking, ethics, and product strategy alongside visual craft. US labor projections show graphic design employment falling 2 percent through 2035 while web and digital interface roles grow 6 percent. Admissions and teaching should therefore weigh reasoning and defensible decisions, not portfolios alone.

The most distinctive brands often gain an advantage by borrowing ideas, behaviors, and experiences from entirely different industries rather than following the conventions of their own category. Examples ranging from Liquid Death and Lego to hospitality-inspired retail experiences show that innovation comes from remixing unexpected influences, creating memorable moments, and challenging category norms while remaining true to a clear brand purpose. As categories become increasingly blurred, brands that look beyond their competitors and embrace experimentation are more likely to stand out, build stronger emotional connections, and avoid the trap of becoming interchangeable with everyone else.

You might have noticed flyers for small businesses starting to look the same in recent months, not because everyone's jumping on one of the big graphic design trends of 2026, but because of a technology. AI-generated flyers are everywhere, and they're replacing the great tradition of folk design built in Photoshop or Microsoft Paint.

Suddenly everything from your local church's car boot sale to the food truck on the pavement outside it is presenting itself with AI-generated visuals. And despite the theoretically infinite creative possibilities that AI image generators afford, most of them look mediocre, if not outright traumatic when it comes to AI menus and food imagery.

On social media, graphic designers are trying to make the world see sense.

The vast array of AI flyers cropping up all over social media and even printed in physical form suggests that many small businesses see such assets in purely informational terms: an inconvenience needed to communicate a product or service rather than a vital piece of branding that can say a lot about a business and the people behind it.

The fightback is in full swing on Instagram and YouTube, with a recent flurry of posts and videos that seek to highlight that ethical issues and simply the cheap generic look of AI-generated visuals could put customers off.

Designers and illustrators are also taking AI-generated flyers from the internet and trying to show how they would have approached the brief, leading to much more unique, eye-catching and coherent results.

Some designers are using the process like a real brief to practice their skills and others to promote their services.

Others are so tired of seeing bad AI designs that they're imploring businesses to design their own assets in any other way.

Some people appear to have got the message. At least, there's a simultaneous trend running of small businesses declaring on Instagram that they'll be communicating using pen and paper instead of AI flyers. Others have been sharing simple tips for other businesses on how to make a flyer without using AI.

The AI proponents will say bad users are the cause of generic-looking flyers, not AI itself. All you need to do is prompt better. But even with the most detailed 1,000-word prompt followed by multiple rounds of generations, there's an inherent tendency for AI image generation to gravitate to a statistical average of its data set and the verdicts of data annotators.

Before AI, we had bad Photoshop fails and the classic 'graphic design is my passion meme'. But at least amateur design had some personality. With AI, everything just looks a bit mid. For some businesses, that might be enough, but I think the trend towards rawer hand-crafted work may be building.

Manus has resumed independent operations, with its founding team continuing to drive product innovation and develop advanced general AI agents. Some users experienced temporary data access interruptions, requiring data backups and restoration. Manus plans to deepen integration into daily workflows and enhance AI capabilities for complex task management.

Meta's Infrastructure Lab in Menlo Park focuses on developing hardware for next-gen AI.

The Fermi Explorer mission aims to launch a spacecraft carrying a 1kg payload to Alpha Centauri so that it reaches the system in fewer than 80,000 years. It will knock two 'filters' off the Fermi paradox: that species won't want to send spacecraft beyond their home star, or species will find that interstellar transit is too difficult. This would leave only a few options for why our galaxy appears not to be littered with alien civilizations. The team wants to use existing technology to do something cheap and fast and launch by 2029.

Snap's CEO doesn't expect the company's $2,195 smart glasses to take off among consumers until the end of the decade.

Grafana 13.2 expands shared saved queries with search, RBAC, command palette access, and Terraform provisioning, while the new View panel sidebar improves exploration without edit permissions. Additional updates include Git Sync enhancements, a refreshed homepage, secure cloud data source authentication, improved variable editing, and dashboard organization.

Visual identity shapes judgments of credibility within seconds, giving typography, layout and consistency a direct role in whether audiences trust a brand. Six principles are set out with brand examples, covering decision-focused design, visual consistency, visible proof, familiar patterns, transparent information architecture and verifiable detail. Each comes with implementation steps designers can apply to a current project.

A UX designer reflects on a painful realization that even well-tested designs often fail in the real world because designers suffer from the curse of knowledge, ignore users' real-world contexts, design against users' mental models, overlook accessibility realities, and treat usability testing as validation rather than discovery. The solution is to design with humility, involve diverse users early, test in realistic conditions, and focus on how people actually experience products rather than how designers intend them to work.

Create professional, consistent, on-brand reports, proposals, presentations, and more in moments.

Upload a logo, choose which colors should glow, and download an HDR JPEG. On HDR screens, the chosen parts shine up to 7.5× brighter than #FFFFFF.