Full article content is not available for inline reading.

Read the original article →

Flattening Every Memory Peak in Long-Context Mixture-of-Experts Training

Training a Mixture-of-Experts (MoE) model at long context or large batch size fails as soon as any one component's peak allocation exceeds device memory, so the target is every peak at once, not the average footprint. Four are left unbounded by the parallelism plans in common use, and each grows differently: expert dispatch with the routing matrix, the vocabulary projection with tokens times vocabulary, gradient checkpoint boundaries with depth times sequence length, and optimizer state with parameter count. Which one runs out first changes with the model, the context length, and the device count, so lowering the largest only exposes the next. We bound all four with schedules whose GPU working set is fixed at launch: PipelinedLLEP extends least-loaded expert parallelism with a cap on the tokens each source contributes to a dispatch chunk, Ring-DTP circulates activations or weight shards around a ring at the vocabulary projection and folds each block of logits into an online log-sum-exp, Selective checkpoint offload (SCO) keeps the one long-lived tensor of each checkpoint boundary in CPU memory, and OffloadStreamAdamW turns the serial CPU Adam update of optimizer offload into a bucket pipeline. All four change only the order and granularity of computation and data movement, so the loss and gradients stay exact. In matched component tests, they cut the MoE dispatch peak by up to 59.3% without losing throughput, the vocabulary projection peak by 86.6%, and the offloaded optimizer step by 2.05x faster. Composed on MoE models from 120B to 667B parameters, they train at 1M context length, 8--32x the reach of a tuned FSDP2 baseline, and up to 10.4x its throughput.

Key Points

• OpenAI's Sam Altman and Anthropic's Dario Amodei are expected to address the U.N. Security Council this week.
• Hugging Face CEO Clément Delangue is also expected to speak.
• The debate about AI safety and regulation has reached a boiling point following a chorus of warnings about the risks to humanity.

OpenAI CEO Sam Altman and Anthropic CEO Dario Amodei are expected to address the United Nations Security Council for a meeting about artificial intelligence this week, a U.N. spokesperson confirmed on Tuesday.

Hugging Face CEO Clément Delangue is also set to join, along with Yoshua Bengio, a professor at Université de Montréal who co-chairs the Independent International Scientific Panel of the United Nations on AI, said Stéphane Dujarric, spokesperson for the secretary-general.

The meeting is set for Wednesday, according to Bloomberg, which was first to report the news.

The U.N. General Assembly in New York this week comes as the debate around AI safety and regulation has reached a boiling point following warnings from researchers about the dire risks to humanity.

President Donald Trump, who has repeatedly dismissed the warnings as a "hoax" and "scam" over the past week, addressed the assembly on Tuesday and pledged to "encourage" the nascent technology, despite calls from Amodei and Altman to pace the development of advanced models.

"I'm not going to stifle growth of something that will be bigger than the industrial revolution," Trump said. "Many say bigger than the industrial revolution or the internet itself."

OpenAI's disclosure in July that its AI models broke out of a testing environment and autonomously hacked into open-source developer platform Hugging Face set off a wave of concerns about the rise of advanced models and how much they can be contained.

Since then, Anthropic has also disclosed cyber incidents with its models, and OpenAI has revealed further "concerning model behavior" by autonomous agents. Last week, Google said that its Gemini model hacked into three other companies.

Claude Opus 5.5, GPT-6 Sol, GPT-6 Luna, and a new price war

Yesterday was Grok 4.7 (pelicans) and MiMo v2.6 Flash/Pro (more pelicans). Today Anthropic released Claude Opus 5.5, and around an hour later OpenAI released GPT-6 Sol and GPT-6 Luna. It’s going to take a while to get a good read on all of these new models, but here are my impressions so far.

GPT-6 Sol and Luna are half the price of their GPT-5.6 equivalents

GPT-5.6 Luna was already my favorite model for building applications against, because it combined excellent performance with being really cheap. Somehow GPT-6 Luna is half the price of that again—and GPT-6 Sol had a similar reduction compared to GPT-5.6 Sol.

Here’s what the pricing landscape looks like today:

Note that GPT-5.6 has a scheduled 25% price increase for November, so GPT-6 is half the price of the promotional pricing for those models.

(With GPT-5.6 Terra priced the same as GPT-6 Sol, any remaining reasons to use Terra just evaporated.)

It’s hard to overstate how competitive this pricing is. Grok 4.7 priced itself at $2/$6, less than half the price of GPT-5.6 Sol, but is now equally priced to GPT-6 Sol on input and closer on output.

At $0.10/$0.50 GPT-6 Luna is one of the cheapest models OpenAI have ever released, beaten only by the far weaker GPT-4.1 Nano ($0.10/$0.40, April 2025) and GPT-5 Nano ($0.05/$0.40, August 2025).

I rendered pelicans for GPT-6 Luna and for GPT-6 Sol, then I combined them all together in this comparison grid along with the GPT-5.6 pelicans. I like how you can instantly see that the 5.6 family chose bolder, brighter colors, while the 6 family is a lot more muted. I still think GPT-6 Astra on max produced the best pelican.

Claude Opus 5.5 got a price cut too

Opus 5.5 looks like it addresses the biggest complaints people had about Opus in terms of its communication style. Thariq Shihipar:

Opus 5.5 is the result of your feedback.

It communicates clearly, it’s cheaper per token than Opus 5.0 with the intelligence of Fable 5.1 it’s very token efficient and works across every effort level.

It’s also meant to be better at Blender. I’m looking forward to putting it through its paces there.

Opus 4.5, 4.6, 4.7, 4.8, and 5 all shared the same price: $5/million tokens for input and $25/million for output. 5.5 is a 20% reduction—$4/million and $20/million.

The price for cache reads fell 60%. That’s significant for longer agentic conversations, where 90%+ of input tokens are processed at cached token prices.

The new price for Opus 5.5 is the same as the price for GPT-5.6 Sol, but that was before OpenAI dropped their Sol prices by half.

GPT-6 Astra and Claude Fable 5.1 are both priced at $10/million input and $50/million output. The price war currently affects the next tier of models below that.

Anthropic say that Sonnet 5.5 and Haiku 5.5 are coming soon. It’s going to be interesting to see if Haiku can regain its price competitiveness at the lower end, given current Haiku 4.5 is $1/$5 while the latest GPT-6 Luna is one tenth of that price at $0.10/$0.50.

Claude Opus 5.5 max over-thinks to the point of breaking

In a first for my "Generate an SVG of a pelican riding a bicycle" test, Claude Opus 5.5 at "max" thinking level failed to return a response!

It started by calling this “a classic test request”, and then thought really, really hard about what it was doing:

This is a classic test request, so I want to plan out a well-composed pelican with its distinctive beak and pouch riding a bicycle with proper wheels, frame, and pedals, set against a simple sky and ground backdrop. [...]

Verifying the shin length checks out at roughly 95.2, close enough. Now I’m working out the near leg path from hip to knee to ankle, then sketching the foot shape resting on the pedal — outlining the heel, toe tips, and sole contour with a path using lines and curves to sit naturally on the pedal surface around y=478-494. [...]

I like the fish sticking prominently out of the basket with the pelican eyeing it as a fun detail worth keeping. I’m also confirming the eye placement near the bill base matches typical pelican anatomy, and considering giving it a slightly happier expression. [...]

The far leg reads correctly as passing behind the frame, so I’m moving on to check the chainring teeth and confirm layer ordering—the far crank arm should be mostly hidden by the seat tube and chainring. I’m settling on the final SVG’s width and height attributes alongside the viewBox to ensure proper scaling, noting there’s no text so no font-family is needed. [...]

I was so excited to see this pelican... but then it stopped. Opus 5.5 has a 128,000 maximum output token limit (as do the other Claude models), and it hit that while it was still reasoning about the SVG!

I tried a second time and got the same result. This makes me suspect that “max” is effectively useless—if it over-thinks to breaking point on a stupid SVG prompt I don’t trust it not to do the same for more interesting work.

(Those two failures each cost me $2.56 and took nearly 20 minutes.)

Fable 5.1 on “max” didn’t over-think and did give me the best pelican I’ve seen from any Anthropic model.

Here are the Opus 5.5 pelicans, excluding 5.5 max.

I also built this comparison grid comparing them with pelicans by Opus 5, Fable 5.1, and Sonnet 5:

Comparing different model vendors by how well they draw a pelican riding a bicycle may not make much sense now (if it ever did), but I’m still finding value in using them for comparisons of the same model families at different reasoning levels.

I’m now using GPT-6 Sol and Claude Opus 5.5 as my default models in Codex and Claude Code. I’ve upgraded the Datasette Agent demo at agent.datasette.io to use GPT-6 Luna, and it seems to be fast and competent at both SQL queries and building HTML and JavaScript for Datasette Apps.

Full article content is not available for inline reading.

Read the original article →

We introduced Python Workers two years ago, providing a way to run Python applications in the Cloudflare Workers runtime. Our goal was to make it as simple to write Workers in Python as it is in TypeScript, and to make the ecosystem of Python packages and frameworks “just work”.

Today, Python Workers are now generally available (GA).

What does GA mean? It means Python is now a first-class, fully supported language on the Cloudflare Developer Platform. You can bring the Python code, libraries, and design patterns you already know and connect them seamlessly to Workers AI, R2, D1, Hyperdrive, Durable Objects, Queues, Workflows, and the rest of the Cloudflare platform. You can also run popular Python frameworks like FastAPI, Django, and Flask inside Python Workers. You can even create a Python Worker inside another Worker using Dynamic Workers.

from fastapi import FastAPI, Request
from workers import asgi, WorkerEntrypoint

app = FastAPI()

@app.get("/")
async def root(request: Request):
    env = request.scope["env"]
    return await env.AI.run(
        "@cf/openai/gpt-oss-120b",
        {
            "instructions": "You are a friendly assistant.",
            "input": "What is the origin of the phrase Hello, World?",
        },
    )

Default = asgi.entrypoint(app)

The journey behind Python Workers

Bringing Python to Cloudflare Workers was a natural choice. Because Workers has supported WebAssembly since 2018, it gave us the perfect environment to run a Wasm-compiled Python interpreter. By using Pyodide, we were able to quickly support a wide range of Python applications in Cloudflare Workers.

Our goal was to create the first platform for infinitely scalable Python apps, while making it as easy and performant as developing Python apps anywhere else.

The features we are highlighting today are the result of this multi-year effort. Many developers are already building applications within Python Workers; today, we are making these capabilities production-ready for everyone.

Python is now a first-class language in the Cloudflare Workers runtime

Python Workers now natively support Cloudflare Developer Platform bindings. Previously, using these Cloudflare bindings in Python Workers required converting Python objects into TypeScript objects explicitly at the RPC boundary. For example, sending a Python dictionary into a Cloudflare Queue required the following glue code to work:

from pyodide.ffi import to_js
import js

self.env.QUEUE.send(to_js({"key": "value"}, dict_converter=js.Object.fromEntries))

This required Python developers to keep the JavaScript environment and code in mind while writing Python Workers, and it was a common source of error for both humans and AI agents. To address this, we have encapsulated the entire type conversion process within the Workers runtime and the Python SDK. This allows you to utilize all Cloudflare bindings in a Pythonic way without writing a single line of JavaScript code, making the following just work:

self.env.QUEUE.send({"key": "value"})

Web frameworks: FastAPI, Django, and Flask

You can now run your favorite Python framework, such as FastAPI, Django, or Flask, to build an API server in Python Workers. We implemented a built-in connector that you can use to easily connect your web application to Python Workers.

Let’s say you have a simple FastAPI web application:

from fastapi import FastAPI

app = FastAPI()

@app.get("/")
async def root():
    message = "Hello, world!"
    return {"message": message}

In native environments, you would use a web server such as uvicorn to run this application.

$ uvicorn main:app

In Python Workers, you can run the same application using the workers.asgi package we provide, just by adding this snippet to your code:

from workers import asgi

class Default(WorkerEntrypoint):
    async def fetch(self, request):
        return await asgi.fetch(app, request, self.env)

# or equivalently
Default = asgi.entrypoint(app)

Similarly, you can use workers.wsgi package to run synchronous web applications such as Django.

from workers import WorkerEntrypoint, wsgi
from your_django_app.wsgi import app

Default = wsgi.entrypoint(app)

So, what happens under the hood?

Python has a standard contract for how web applications should communicate with web servers, known as the Web Server Gateway Interface (WSGI), or its modern asynchronous counterpart, ASGI. This standard allows developers to build applications that are completely server-agnostic. In a traditional deployment, web servers like Uvicorn or Gunicorn are responsible for handling multiple concurrent client connections and threads to scale traffic, while web frameworks like FastAPI can focus purely on the application logic.

In Cloudflare Workers, the Workers platform itself serves as the web server. Since our global network already seamlessly handles load balancing and infinite scaling, we don't need to reinvent the wheel by running a server inside Python Workers.

Instead, our workers.asgi and workers.wsgi connectors act as a thin, optimized bridge. They translate the incoming native JavaScript request into the standard WSGI/ASGI structures that Python applications expect, and seamlessly pipe the response back out with minimal overhead. By doing this, Python developers get the best of both worlds: you can write and organize code using your favorite web frameworks, while letting the Cloudflare Workers platform instantly scale your API across the globe, without ever configuring a server.

These connectors can be used not only with FastAPI, Django, or Flask, but with any Python web framework that uses the WSGI or ASGI interface.

You can find more information about using each web framework in the Python Workers documentation.

Using PostgreSQL and MySQL with Hyperdrive

If you are building a Python application using relational databases such as PostgreSQL or MySQL, you can now integrate Hyperdrive into Python Workers.

Previously, Python Workers didn’t support TCP sockets, making database drivers unavailable. To understand why this was a blocker, you need to look at how WebAssembly operates. Python database drivers like aiomysql or asyncpg rely on the standard library's socket module to establish connections. In a standard environment, this module makes POSIX system calls to the underlying operating system. Inside a WebAssembly sandbox, those POSIX networking syscalls are normally stubs that always fail. Any attempt to open a standard socket would immediately fail. To solve this problem, we implemented socket system calls using the Workers connect API.

When a database driver attempts to open a TCP connection, it goes through our custom socket syscall implementation. It translates standard Python socket operations like opening a connection and reading bytes into the corresponding JavaScript calls used by the Workers runtime. Because this translation happens at the system call level, your database drivers don't have to know about the underlying implementation at all.

This socket bridge is what makes our Hyperdrive integration possible. To use Hyperdrive in Python Workers, first connect your database with Hyperdrive and set up the binding in the Wrangler config:

"hyperdrive": [
    {
        "binding": "HYPERDRIVE_MYSQL",
        "id": "<example id: 57b7076f58be42419276f058a8968187>",
    }
]

Then, connect to Hyperdrive using the database drivers you are familiar with:

import aiomysql

from workers import WorkerEntrypoint

class Default(WorkerEntrypoint):
    async def fetch(self, request):
        hd = self.env.HYPERDRIVE_MYSQL
        conn = await aiomysql.connect(
            host=hd.host,
            port=int(hd.port),
            user=hd.user,
            password=hd.password,
            db=hd.database,
            ssl=None,
        )

        cur = await conn.cursor()
        await cur.execute("SELECT username FROM user")
        r = await cur.fetchall()
        await cur.close()
        conn.close()

You can refer to the Hyperdrive Python Workers documentation to find out how you can use Hyperdrive in Python Workers, and which packages are currently supported.

Expanding the WebAssembly package ecosystem

Because Python Workers run inside a WebAssembly sandbox, any packages with native C/C++/Rust extensions must be cross-compiled to WebAssembly to run in Python Workers. However, previously, there was no standard way to cross-compile any Python packages to WebAssembly. That meant our team had to manually compile and host custom WebAssembly packages. This greatly limited the number of packages you could actually use in Python Workers.

We wanted to fix this and allow users to use a wider variety of packages. However, we didn’t want to merely build packages usable only in Python Workers, which wouldn’t benefit the community. Since Python Workers are built on top of Pyodide, we wanted the ecosystem to evolve in a way that benefits Pyodide and the entire Python-on-WebAssembly community.

To this end, we proposed PEP 783, which standardizes a platform for running Python in the browser runtimes called PyEmscripten. After over a year of discussion and refinement, this proposal was accepted, enabling package maintainers to build and publish packages for the PyEmscripten platform and make them available across all environments that implement PyEmscripten.

We also stabilized the existing Pyodide build toolchain and evolved it into a form that is accessible to all package maintainers, enabling developers to easily build packages for the PyEmscripten platform. Furthermore, we added PyEmscripten platform support to cibuildwheel, to make it easier for others to adopt support for the PyEmscripten platform.

While the ecosystem is still adopting this standard, we hope every Python package will have a wheel that works with WebAssembly in the future. We are also actively working with major package maintainers to add PyEmscripten builds. If you encounter a package that isn’t supported yet, let us know on Discord or GitHub, and our team will work to get it built.

You can also check out our EuroPython 2026 talk: “Python Everywhere: The State of Python on WebAssembly” to see how we made this possible.

Building AI agents and pipelines in Python

The large ecosystem of data science and machine learning packages makes Python the natural choice for building intelligent agents and AI pipelines. But bringing these to Python Workers historically presented a challenge: libraries such as openai and langchain rely on HTTP clients like requests or httpx to communicate with external APIs. However, because of missing low-level socket operations support in Python Workers, these HTTP clients didn’t work properly.

To solve this, we contributed upstream to ensure these HTTP clients can route requests directly through the JavaScript fetch API in WebAssembly environments. Combined with our new support for low-level socket operations as explained in the previous section, this makes the entire networking stack work seamlessly inside Python Workers.

As a result, you can now run AI libraries like openai, langchain, and mcp natively in Python Workers. You can also combine them with Workers AI to run serverless inference on GPUs in Cloudflare’s network, or proxy requests through Cloudflare AI Gateway.

The example below shows a way to run Worker AI models in langchain, using the langchain-cloudflare package:

from langchain_cloudflare import ChatCloudflareWorkersAI
from langchain_core.output_parsers import StrOutputParser
from langchain_core.prompts import PromptTemplate
from workers import Response, WorkerEntrypoint

class Default(WorkerEntrypoint):
    async def fetch(self, request):
        prompt = PromptTemplate.from_template(
            "In one sentence, describe a great day in the life of an {profession}."
        )
        llm = ChatCloudflareWorkersAI(
            model_name="@cf/meta/llama-3.3-70b-instruct-fp8-fast",
            binding=self.env.AI,
            max_tokens=64,
        )
        chain = prompt | llm | StrOutputParser()

        result = await chain.ainvoke({"profession": "electrician"})
        return Response.json({"result": result})

What you can build today

We have assembled a collection of production-ready patterns in our python-workers-examples repository. Here are some ways you can combine Python Workers with the Cloudflare ecosystem.

Asynchronous AI orchestration

Building a full-stack AI application often means connecting multiple services such as storage, queuing, and inference. This example shows how to build an AI-driven image-to-image generator purely in Python Workers. It accepts user requests, drops them into a Cloudflare Queue, and uses Workflows to orchestrate the image generation step via Workers AI, and stores the image to an R2 bucket.

Real-time stream processing with Bluesky Jetstream

Consuming a firehose of real-time events usually requires a dedicated server to maintain the connection. In this example, we use a Python Worker to connect to the ATProto/Bluesky Jetstream WebSocket. By backing this connection with a Durable Object, the Python Worker can maintain long-lived state, ensuring that the WebSocket connection stays alive.

More examples to explore

Model Context Protocol (MCP) Server

Build and deploy an MCP server using the official Python MCP package to give your AI assistants access to edge data.

Retrieval-Augmented Generation (RAG) system with Vectorize

Building a RAG system using Workers AI and Vectorize, Cloudflare’s vector database.

Python code examples across the Cloudflare developer docs

We’ve updated our docs across Cloudflare products to include Python example code. Nearly everywhere where there is a code example showing how to do something in TypeScript, there’s also a code example in Python. We’re committed to continuing to include Python examples across all of our products. You can toggle code snippets between JavaScript, TypeScript, and Python throughout our developer documentation.

What’s next?

Reaching GA is just the start. We have many plans to make Python Workers better, including making Python Workers more performant and memory efficient, as well as supporting more packages.

Keep telling us what you want to build on Python Workers, and we’ll keep pushing the bounds of what is possible. Check out Python Workers documentation and start building your first Python Worker!

SWE-Bench Pro V2

Evaluating challenging long-horizon software engineering tasks in public open source repositories

Update September 22, 2026

We're releasing SWE-Bench Pro V2, a refreshed public split with a modified benchmark and a locked evaluation protocol, co-developed with Reflection.

• 642 tasks across 11 repositories, down from 731. We dropped 89 tasks our review found invalid.
• 69 tasks had instructions that contradicted the tests grading them. We corrected the text only, then had an expert solve each one blind from the instruction alone.
• The agent phase now reaches only the model endpoint, with web tools disabled. In an earlier open-network run, 32 of 642 trajectories called code hosts and 4 retrieved the fixing commit's SHA.
• Every agent diff is re-graded on a pristine image, and we publish both grades. This caught Opus 5 forging a Go module checksum into go.sum and Inkling editing the Go module cache on 3 tasks.
• A two-sided gate runs before release: every task must pass with the reference patch and fail with the empty patch. It caught our own regression, a Jest parser fix that silently broke 23 element-web tasks.
• 211 tasks got better dependency support for OSS harnesses, and 10 got environment fixes the verifier needs.
• Two residuals stay open. The model endpoint is a trusted relay, and code inside a patch (conftest.py, a go.mod replace, a Makefile target) is still executed by the verifier.

Probe scripts, re-grade agents, per-task grades in both modes, and trajectories ship with the release.

SWE-Bench Pro

SWE-Bench Pro is a benchmark designed to provide a rigorous and realistic evaluation of AI agents for software engineering. It was developed to address several limitations in existing benchmarks by tackling four key challenges:

1. Data Contamination: Models have likely seen the evaluation code during training, making it hard to know if they are problem-solving or recalling a memorized solution.
2. Limited Task Diversity: Many benchmarks fail to capture the full spectrum of real-world software challenges and instead focus on simple utility libraries.
3. Oversimplified Problems: Ambiguous or underspecified issues are often removed from benchmarks, which doesn't reflect a real developer's workflow.
4. Unreliable and Irreproducible Testing: Inconsistent setups make it difficult to know if a solution truly works or if the environment is just configured incorrectly.

SWE-Bench Pro addresses these gaps by sourcing tasks from diverse and complex codebases, including consumer applications, B2B services, and developer tools. To reduce contamination risk, the public and held-out OSS subsets use strong copyleft licenses (e.g., GPL). The private subset consists of proprietary codebases from startup partners.

The benchmark is significantly more challenging than its predecessors; top models score around 23% on the SWE-Bench Pro public set, compared to 70%+ on SWE-Bench Verified. This provides a more accurate measure of an agent’s true problem-solving capabilities in environments that mirror professional software development.

Methodology

Each problem in SWE-Bench Pro is created using a four-stage workflow:

1. Sourcing: Repositories are selected from a curated set of public and private repositories
2. Environment Creation: Professional engineers build reproducible Docker-based environments, integrating all dependencies and build tools to ensure the codebase and tests run out-of-the-box.
3. Harvesting: Problems are extracted via commit scraping. Pairs of consecutive commits are retained if they (a) fix a bug or introduce a feature, (b) demonstrate a fail-to-pass transition for new tests, and (c) include pass-to-pass tests confirming unrelated functionality remains intact.
4. Augmentation: Human experts organize unstructured commits and issue metadata into two artifacts: a problem statement and a requirements brief with an optional interface. These provide sufficient context to reproduce the gold patch without prescribing an implementation. We employ three human-in-the-loop checkpoints: (1) manual environment construction, (2) human augmentation of the issue description, requirements, and interface, and (3) human verification of tests (relevance and flakiness).

Primary Metric: Resolve Rate

The primary metric is Resolve Rate, which is the percentage of tasks an agent successfully resolves. A task is marked as "resolved" only if a submitted code patch satisfies two strict conditions within the evaluation environment:

• Issue Resolution: The patch must fix the specific bug or implement the feature. This is verified when the new "fail-to-pass" tests, which fail on the original code, now pass.
• No Regressions: The patch must not break any existing functionality. This is verified when all pre-existing "pass-to-pass" tests continue to pass after the patch is applied.

Dataset Design

The dataset is guided by four foundational principles:

• Non-Contamination by Design: The benchmark is constructed from GPL-style copyleft repositories and private proprietary codebases, creating legal and access barriers that reduce the likelihood of contamination. This licensing model makes it improbable that the code was included in proprietary training corpora, reducing the risk of data leakage and enforcing true generalization.
• Diverse and Industrially-Relevant Tasks: Problems come from consumer-facing apps, B2B platforms, and developer tools, requiring reasoning across varied architectures and development patterns.
• Balanced and Challenging Construction: Each repository contributes 50–100+ problems, with reference solutions requiring medium-to-large modifications (averaging 107.4 lines of code across 4.1 files). This prevents overfitting and ensures non-trivial problem-solving.
• Human-Augmented Problem Specification: Instead of discarding under-specified issues, human experts refine them to add context and clarify requirements. This preserves the original technical challenge while ensuring solvability.

Dataset Summary

SWE-Bench Pro is a large-scale benchmark containing 1865 total tasks across 41 professional repositories. The benchmark is composed of three distinct subsets:

• The Public Set: This set contains 731 instances and serves as the main public-facing benchmark. It is sourced exclusively from publicly available, open-source repositories that use strong copyleft licenses such as GPL. This licensing strategy acts as a legal deterrent against the code's inclusion in model training data, ensuring the benchmark is contamination-resistant by design. Performance on this dataset is tracked on the Public Leaderboard.
• The Private Set: A first-of-its-kind collection, this set includes 276 instances sourced from 18 private, proprietary codebases from startups. These codebases were acquired through partnerships and are not publicly accessible. This set is designed as the ultimate test of generalization on complex, industrial-grade code that is not publicly accessible and is unlikely to have been included in model training data. Results from this challenging dataset are reported on a separate Leaderboard.
• The Held-out Set: The largest of the three, this private set contains 858 instances. Similar to the public set, it is sourced from a separate group of public repositories with copyleft licenses. This entire dataset is held-out for future analysis and internal evaluations. Therefore, the results for this set will not be published on the public leaderboards.

Results: SWE-Bench Verified vs. SWE-Bench Pro

We ran frontier models on Pro using the SWE-Agent scaffold and here’s what we found (all charts reflect the public dataset):

Massive Performance Drop on SWE-Bench Pro: A major finding is the significant drop in performance for all models when moving from the SWE-Bench Verified benchmark to the more challenging SWE-Bench Pro. While most top models score over 70% on the verified version, the best-performing models, OpenAI GPT-5 and Claude Opus 4.1, score only 23.3% and 23.1% respectively on SWE-Bench Pro. This highlights the increased difficulty and realism of the new benchmark.

The Private Subset is Harder: The private subset of the SWE-Bench Pro leaderboard reveals a drop in performance. Claude Opus 4.1 decreases from 22.7% to 17.8% resolution, and OpenAI GPT-5 falls from 23.1% to 14.9%. This shows that evaluation on private, previously unseen codebases provides a more realistic measure of generalization.

Significant Performance Gaps Between Models: There is a wide performance disparity among the tested AI models. Frontier models substantially outperform older models like OpenAI GPT-4o (4.9%) and Qwen-3 32B (3.4%). This suggests that the advanced capabilities of the latest models are critical for tackling these complex, real-world software engineering tasks.

Performance Varies by Programming Language: Models show different success rates depending on the programming language. Go and Python tasks generally have higher resolution rates, with some models exceeding 30%. In contrast, performance on JavaScript (JS) and TypeScript (TS) is more varied and often lower, with rates ranging from almost 0% to over 30% depending on the specific model.

Repository-Specific Difficulty: Model performance is heavily influenced by the specific repository the task comes from. Some repositories proved consistently difficult for all models, with resolve rates below 10%. On other repositories, certain models could achieve success rates higher than 50%. This indicates that factors like codebase complexity, problem type, or documentation quality significantly impact an agent's ability to succeed.

Top Models are More Consistent: The highest-performing models, Claude Opus 4.1 and OpenAI GPT-5, not only achieve the highest scores but also demonstrate more stable performance across the different languages and repositories. Smaller models tend to have more "erratic" performance, succeeding moderately on some repositories while failing almost completely on others. This suggests that top models have more robust and generalizable problem-solving skills, a quality that average scores alone don't fully capture.

Difficulty Increases as problems become complex: Model performance significantly degrades as solutions require more lines to be added and files to be edited.

Acknowledgements

Special thanks to the software engineers and annotators who contributed to environment construction, test verification, and human augmentation processes, ensuring the benchmark's rigor and reliability. We are also deeply appreciative of the early-stage startups that partnered with us to provide proprietary private codebases, enabling a more realistic evaluation of AI agents in enterprise settings. Finally, we acknowledge the open-source communities behind the GPL-licensed repositories for their foundational work in software engineering, which inspired this benchmark. This research would not have been possible without these collective efforts.

Performance Comparison

• Opus 5 (Claude Code) xhigh: 98.00
• Fable 5.1 (Claude Code) high: 92.20
• GPT-6 Astra (Codex) high: 90.20
• Sonnet 5 (Claude Code) xhigh: 88.20
• Kimi-K3 (mini-swe-agent) max: 88.20
• GPT-5.6 Terra (Codex) xhigh: 86.30
• GLM-5.3 (mini-swe-agent) max: 84.30
• GPT-5.6 Sol (Codex) xhigh: 82.40
• Gemini 3.8 Flash (mini-swe-agent) high: 58.80
• Inkling (mini-swe-agent) xhigh: 56.90
• Haiku 4.5 (Claude Code) xhigh: 25.50

Rank (UB): 1 + the number of models whose lower CI bound exceeds this model’s upper CI bound.

Full article content is not available for inline reading.

Read the original article →

Evolved harnesses overfit the benchmark they are scored on. RRSI transfers.

RRSI improves every out-of-distribution benchmark without overfitting the split it evolves on. Prior methods do the opposite: large evolve-set gains that shrink or vanish once the benchmark changes, two of them ending below the harness they started from.

Regularize the search, not the harness

Every harness component stays editable. RRSI constrains the loop that edits it: how much one proposal may change, and which measured gains are allowed to stick.

Proposal side

Annealed edit budget: Early rounds may bundle a few coordinated edits to find a mechanism; late rounds get one attributable change.

Evidence-aware credit: Every candidate is logged with its hypothesis, diff, score and cost change, so the proposer builds on what worked and stops re-testing what failed.

Structured exploration: When progress stalls inside the noise band, budget is redirected to components the run has never touched.

Selection side

Leakage critic: Task names, entities, answers or benchmark-specific logic are rejected before a candidate is ever scored.

Noise-adjusted floor: A gain must clear the variance measured on the unchanged base harness.

Cost rule: Extra inference tokens have to be paid for by measured gain.

Pruning: Components that stop earning their place are flagged for deletion.

Every held-out benchmark improves

Evolve on one suite per domain, then run the harness unchanged everywhere else. Same tools, judge, trials and window as H0; the policy is Claude Opus 4.8.

Two rules act on cost directly

The cost rule refuses growth that is not paid for when it is proposed; pruning removes growth that stopped paying for itself since. No prior method carries either.

Watch the harness evolve, round by round

Four real runs, every candidate: what it proposed, what the critic said, why the gate kept or dropped it, and the exact diff.

BibTeX

@article{xia2026rrsi,
  title={RRSI: Regularized Recursive Self-Improvement of Agent Harnesses},
  author={Xia, Peng and Han, Rujun and Wang, Zifeng and Chen, Yanfei and Zhuang, Yufan and Lee, Yoonho and Huang, Chengsong and Yu, Han and CuiZhu, Zhongying and Ming, Yifei and Yao, Huaxiu and Gokturk, Burak and Pfister, Tomas and Lee, Chen-Yu},
  journal={arXiv preprint arXiv:2609.24972},
  year={2026}
}

Featured projects

• vLLM

TL;DR

To achieve state-of-the-art performance at the frontier, vLLM is changing its internal implementation in ways that make it incompatible with fullgraph torch.compile. This may have consequences for users who care about out-of-tree accelerators, older GPUs, or more exotic models. To address this, we are introducing a new set of “HW agnostic” layers in vLLM. These layers will ensure vLLM can continue to move at the speed of light, while at the same time meeting the needs of users who care about portability. On NVIDIA H100 GPUs, the HW agnostic layers achieve total token throughput within 3.4% of the native implementation (geometric mean across three recent models).

vLLM at the frontier

vLLM has achieved unprecedented success by positioning itself as the abstraction layer supporting a wide variety of models on a wide variety of hardware. By using a set of well-designed abstractions and torch.compile for optimization and fusion, the project has been able to keep the code defining the actual model logic (commonly known as “model definitions”) relatively simple, whilst still achieving high performance across NVIDIA GPUs, AMD GPUs, Intel XPUs, Google TPUs, IBM Spyre, Huawei Ascend and more.

However, the architectures of frontier open-weight models are rapidly diverging, which has led the community to revisit whether some of the existing abstractions are fit for purpose. Models increasingly ship with bespoke layers and optimized kernels. This even extends to the core attention mechanism: DeepSeek V4 and Kimi K3 achieve million-token context via completely different approaches. Fitting one of these into vLLM means composing it from the shared layers in model_executor/layers and keeping the whole model fullgraph compilable: written so that Dynamo can trace it, with each new kernel registered as a torch library op with a fake implementation and correct mutation annotations. That work is a tax on model development, and it is paid by whoever adds the model, including the advanced users who bring their own.

At the same time, NVIDIA Blackwell GPUs and rack-scale systems like NVIDIA GB300 NVL72 require careful kernel engineering to exploit new features and effectively overlap computation with communication.

While all this is happening, we have seen the rise of coding agents like Claude Code and OpenAI Codex, which make generating code much easier. In particular, these agents are very effective at designing optimizations for a specific model on specific hardware. However, they work best if they do not need to worry about whether a particular change will make things worse for a different model, on a different accelerator.

These trends come together and mean that, to achieve state-of-the-art performance on the latest GPU hardware, the community would like to dismantle some of the existing abstractions in vLLM. In particular, vLLM is starting to maintain hardware-specific model definitions, otherwise known as “flat” models. Rather than using torch.compile, flat models use custom fusions and other model-specific and hardware-specific optimizations. New frontier models added to vLLM in recent months all use this flat model definition. Critically, the existing layers and ops consumed by the model definitions are likely to be refactored in a way that makes them fundamentally incompatible with torch.compile.

This effort is necessary to enable vLLM to stay competitive on the latest GPU benchmarks. However, it is also important that vLLM continues to serve its users who care about serving diverse models on diverse hardware like older GPUs or out-of-tree (OOT) accelerators.

So, what can we do about it? Let’s start by reviewing how vLLM handles model definitions today.

How do model definitions work in vLLM?

Today, vLLM offers three flavours of model definitions.

1. The new “flat” models which live under vllm/models/
2. The legacy models which live under vllm/model_executor/models
3. The transformers modeling backend, which imports models from transformers.

While the modeling logic may live in different places, most models are composed of common layers like attention, mixture-of-experts, linear projections, norms and activations. It is important to understand that, in all 3 cases above, these common layers are still implemented in a single place. In case (1) and (2) these layers are explicitly imported from vllm/model_executor/layers. In case (3), the transformers model gets automatically fused and re-wired to use the vLLM layers. Thus, wherever the model definition is coming from, we are still using a common implementation of the majority of the layers that underpin it.

vLLM’s layer implementations have evolved over several years and offer two important features that we will now discuss in more detail: (a) torch compile support, and (b) OOT extensibility.

While fullgraph torch compile is not used by the flat models, it remains a critical feature for OOT plugins like IBM Spyre. Spyre relies on TorchDynamo to trace the model graph, and TorchInductor to lower the graph down to representations that run optimally on the target hardware. Crucially, torch compile is also a necessary component for enabling vLLM’s transformers backend to achieve native speed for models like Qwen3 on NVIDIA GPUs.

However, for OOT plugins torch compile is not the whole story. Accelerators like Spyre also occasionally need to inject behaviour into the layers (e.g., custom memory layouts) to achieve optimal performance. vLLM’s layer offers two different mechanisms for injecting custom behaviour: CustomOp (which enables the plugin to override the forward function) and PluggableLayer (which enables the plugin to override the entire layer). Without this extensibility, OOT plugins would need to re-implement many of the layers themselves.

So, what is the problem here?

Aside from the fact that having model definitions in three places is pretty confusing, there is a more pressing issue with the above design.

The flat model workstream needs to change the model definitions, and their underlying layer implementations, to break compatibility with torch compile and remove support for extensibility via CustomOp. This will unlock them to move faster on developing hardware-specific and model-specific performance optimizations, but it also raises some concerns.

Firstly, it leaves OOT plugins facing the prospect of maintaining their own set of model definitions and layers, creating a large maintenance burden. Supporting a new model will involve making pull requests to transformers, vLLM, and then potentially every OOT plugin that wants to support it. Yes, coding agents make this easier but this will still require burning through token budgets across multiple different organizations for ultimately no real benefit.

Second, vLLM is increasingly relying on the transformers backend to provide support for older or more exotic models. Legacy model definitions are actively being removed from model_executor/models and their registry entries updated to point directly at the transformers modeling backend. Without torch compilable layers, performance for these models on GPU will regress significantly.

Finally, while the flat model and layers will be optimized for frontier GPUs, we do not expect them to provide support for older GPUs or consumer/prosumer GPUs.

What is our solution?

We are building a set of hardware-agnostic layers in-tree in vLLM. The aim of these layers is to ensure that vLLM can continue to support its user base that cares about running diverse models on diverse hardware.

The Hardware-agnostic layers adhere to the following four design principles:

1. Compilable. The model definitions will be full-graph torch compilable; Accelerators that require compile for performance can continue using it as they do today.
2. Extensible. We will keep mechanisms like vLLM’s CustomOp and PluggableLayer to ensure that OOT plugins can override the implementation when necessary.
3. Isolated. The model definitions will be built with their own set of layers and ops that are separate and isolated from the layers and ops used by the hardware-specific paths. This will ensure that development in both directions can move fast without impeding the other.
4. Portable. We will strive to implement all layers and ops using either native PyTorch code or portable DSLs like Triton and Helion. This will make the models portable across all accelerators that support these frameworks. Those that do not can still rely on (2) when necessary.

As the legacy model definitions are gradually removed, models will either be re-implemented in the flat way (e.g., a different implementation for NVIDIA, AMD, XPU etc), or they will fallback to the transformers backend. We intended to offer hardware-agnostic support in both of these cases.

For the transformers backend, we have modified the “rewiring” process to target the new HW-agnostic layers which reside at model_executor/hw_agnostic, instead of the existing layers at model_executor/layers. This support has already landed in the main branch of vLLM (for a limited number of layers), and can be enabled by setting USE_HW_AGNOSTIC=1 when running vLLM with the transformers backend:

USE_HW_AGNOSTIC=1 vllm serve google/gemma-4-31B --model-impl=transformers

We have validated this new pathway using the Spyre OOT plugin for models like Gemma 4, Qwen3, and Granite 4.2. Very soon, we will start to include HW agnostic models in our CI, and gradually switch over to using this as our default pathway for serving models on Spyre.

But, how will it perform on GPUs?

We stress that state-of-the-art performance on Blackwell, CDNA 4, and beyond is not the goal of these model definitions. Our aim is to achieve platform and performance portability across diverse hardware, including OOT accelerators, older GPUs, as well as prosumer-grade GPUs.

To evaluate how the new pathway behaves on widely-available GPUs, we ran some experiments on NVIDIA H100 GPUs, for a handful of recent models. We compare the performance of vLLM’s transformers backend using USE_HW_AGNOSTIC=0 vs. USE_HW_AGNOSTIC=1.

As we can see, despite being built solely from portable implementations of the underlying layers and ops, HW agnostic models achieve relatively close, and in some cases even slightly better, performance, than the native models that use CUDA-optimized libraries like FlashAttention and CUTLASS.

Conclusion

We are introducing HW agnostic layers into vLLM to ensure that the project can continue to support diverse models on diverse hardware, without slowing down performance engineering at the frontier. We believe this effort is important for vLLM to continue to serve the needs of the broader open-source ecosystem. While we have started landing PRs to realize this effort, this is still very much a work-in-progress and we welcome any feedback.

GPT-6 Astra Breaks an Old Enigma Message

This is pretty amazing:

However, the most astonishing thing about this break is that the GPT­6 Astra did it entirely on its own. Carter Leffer only directed GPT­6 Astra to see if it could break any of the unbroken Enigma messages published on the Crypto Cellar Research web page. After analysing the unbroken messages on the website, it decided that the most promising message was Nr. 172, MVUEH and it also quickly suspected that the plaintext of Nr. 173, SIPVX, might be related to the plaintext of the unbroken MVUEH message. After trying many different approaches, GPT­6 Astra focused on using the repeated place name ROSENOW ROSENOW as a crib. After developing the necessary Python and C++ software for an Enigma simulator and an Enigma Bombe, GPT­6 Astra started a thorough break with the ROSENOW crib, which in the end resulted in the correct key and plaintext for the MVUEH message being found.

We are still analysing the GPT­6 Astra logs to see exactly how it executed the break. And we are discovering amazing details.

More details at the link.

Early adopters of Meta’s Muse have been speculating that the reason the AI works so well is because it’s OpenClaw under the hood, wrapped in a more consumer-friendly package. Meta now says those comparisons aren’t entirely off-base. According to an X post by Nat Friedman, head of product at Meta’s Superintelligence Labs (MSL), Muse was “definitely heavily inspired as a product by OpenClaw.”

However, he clarified that Muse itself was “built from scratch.”

Friedman, the former GitHub CEO who joined Meta last year alongside Meta’s Chief AI Officer Alexandr Wang, said that the team at Meta had fallen in love with OpenClaw and wanted Muse to be “something like OpenClaw” that could be scaled to billions of people.

Because OpenClaw is an open source project, it wouldn’t be surprising that Meta looked to it for inspiration, especially given its breakout success, which prompted OpenAI to snatch up its creator earlier this year. However, it speaks to Meta’s well-known playbook that involves taking promising products, then copying their best features — something it did most notoriously with Snapchat’s invention of the stories format.

Friedman’s statement on X was made in response to a post that had gone viral among the AI crowd, where Ansh Nanda, an AI app co-founder, claimed that “Muse is LITERALLY OpenClaw for normies.”

Nanda’s X post had included a conversation with Muse, where the AI agent said that the similarity between its own system files and those belonging to OpenClaw was not just “a coincidence” but rather “a match.”

Soon, this thread (and X more broadly) began blowing up as others shared their own comparisons and findings. For instance, one person pointed out that Muse also had a SOUL.md file, the plain text configuration file (written in a simple formatting language called Markdown) that defines an AI agent’s personality, communication style and tone, values, behavioral boundaries, and expertise.

A third noted that the files weren’t just named the same between the two assistants; their content was almost entirely the same.

Following his X post, Friedman also responded to a question about why Muse had copied the exact file names that made up the AI agent’s workspace and had “nearly identical content” for the SOUL.md file. Instead of disputing these claims, Friedman simply replied that “we thought that Peter [Steinberger, OpenClaw’s creator] got those things exactly right.”

“We built Muse from scratch, but it is definitely heavily inspired as a product by OpenClaw. After I used OpenClaw in January, I bought hundreds of Mac minis for the MSL team, and lots of us fell in love with using OpenClaw (and other personal agents), Friedman said on X. (TechCrunch has corrected Friedman’s punctuation for readability.)

“@steipete [Peter Steinberger] is a genius, and his harness was pioneering from the jump. I think a lot of people were inspired by it. Our goal with Muse was to build something like OpenClaw that we could make safe and secure and easy to use and scale to billions of people,” he wrote.

The Muse app has been something of a hit so far, having recently hit No. 1 on the U.S. App Store. Data indicates that it’s now outpacing ChatGPT’s launch when the platforms and market availability are compared directly.

Reached for comment, a Meta spokesperson pointed to Friedman’s statement, saying the company had nothing more to add beyond that.

People need to start paying attention to the issue of derived data in AI training.

There’s rightfully been a big focus on the pirated / web-scraped data AI companies train on (resulting in well over 100 lawsuits) - and, increasingly, on synthetic data made by ‘tainted’ models. Derived data gets talked about less, but does the same harm to creatives.

Derived data is creative content that is rewritten by AI before it is trained on. So instead of training directly on sentences from your book, a company will first use an AI model to rewrite those sentences, then train on the results.

It is harder to detect, because the resulting model is less likely to spit out your work verbatim. But it does the same harm: your work is used without permission to build a product that competes with you.

This gets easier to do the better AI models get, so it’s happening more and more. And it makes it that much harder for creatives to know when their work is being exploited, and therefore that much less likely they can defend themselves.

This is also a huge issue because it may be a way for AI companies to try to get around opt-outs. Perhaps you have put your work on some platform, and you have opted out of the company that runs the platform training on it. But you likely haven’t opted out of them rewriting it and training on that. They will create derived data from it, train on it, and later say they did nothing wrong.

The only real solution to this is training data transparency requirements. Governments must introduce laws that force AI companies to reveal their training data. Until that happens, creatives are forever playing catch-up, at best finding out their work has been exploited long after the fact, at worst never finding out and therefore unable to defend against it.

OpenAI improved prompt caching for GPT-6 with higher default cache hit rates, discounts for shared prefixes reused within 30 minutes, and new tools for monitoring and diagnosing cache performance.

Intrinsic Core is an open source set of Robot Operating System-compatible capabilities for building robotic applications. The capabilities act like the building blocks of robot behavior. The release allows users to quickly and easily combine capabilities to achieve adaptive AI systems. The capabilities are ROS-compatible.

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 →

Analyzing Jev, a new AI model

A new AI model called Jev launched last week and went viral.

It's not an LLM. It doesn't generate text or pictures, but could be very useful for a number of use cases. The creators call it “the first System One model”, tout its performance (193x faster, 444x cheaper) and promise it can't hallucinate.

So, what is it?

How it (probably) works

Behind the impressive marketing is a very interesting model. Jev is a close relative of LLMs like GPT, Claude, or DeepSeek, but is actually more similar to the BERT series of models, which are used for classification, not generation. (If you've ever wondered why someone calls out a difference between “AI” and “GenAI”, that's the distinction they mean).

TypeSafe (the creators of Jev) haven't actually published any papers on the system, but here's a reasonable guess and simplification, just to give you a sense of how it works.

Imagine going back to 2022. GPT-3, the best LLM at the time, can autocomplete text (you give it some text as an input and it continues it). Then InstructGPT shows how to make the LLM follow instructions from the user. Following the ChatGPT launch, the advances pile up, with reasoning, reinforcement learning, agentic use cases, and all the modern tech tricks LLMs now employ.

BERTs, meanwhile, are almost stuck in time. There's ModernBERT, which modernizes it a lot, but you still need to fine-tune your model for the specific task. This is annoying, cumbersome, and more expensive than just asking an LLM. But these classification models are still much faster and cheaper than LLMs for suitable tasks, once you go through the trouble of training them.

Now imagine someone going, “OK, how can we modernize BERTs with all the cool tech LLMs have been getting? Like using instructions in the input instead of having to re-train, making it really large, and using reinforcement learning?” That's basically what Jev is (not exactly right, but it's a good analogy).

Since it only ingests the input and provides a few probabilities as output, it's much faster and cheaper than LLMs. Jev's model size is not publicly known, but even if it's 100x larger than ModernBERT, it'd still be a paltry 40B params next to the humongous 2T-5T LLMs.

The authors also mention performance improvements due to not needing to generate text tokens and other workflow simplification, as well as the fact that they can evaluate the questions in parallel.

The “System One” moniker is a clever marketing trick that means “it's not a reasoning model”. They borrow the term from Thinking, Fast and Slow, where System 1 means intuitive, fast, automatic thinking and System 2 means deliberate, slower, effortful reasoning.

What about the hallucination claim? In the context of Jev, no hallucination means it can't generate output outside of the specified structure (i.e. it's “type-safe”), but that doesn't mean it can't generate incorrect output.

Using Jev

This brings me to the usage part: you'd use Jev (and other classification models like BERTs) to answer very specific questions, like “is this email spam?”, and it can answer with a Yes/No, a score (from a continuous domain, like 0.0-10.0), or a choice from a few discrete possibilities (classification).

Interestingly, the questions are independent and evaluated in parallel, which helps with performance. It also means you can just batch all the questions/classifications for a given piece of data at once, instead of going step by step.

Since Jev doesn't need to be fine-tuned, it's easy to use it via an API (and in fact, it's the only way to use it – don't expect the weights). Here's one official example, in Python:

from typesafe_sdk import Choice, Noul, Score, TypeSafeClient

client = TypeSafeClient()

ticket = """
Hi, I've been trying to connect my Stripe account for 3 days
and the integration keeps failing.
I'm losing sales. Please help ASAP.
"""

response = client.system_one(
    state=ticket,
    questions={
        "department": Choice(
            instructions="Which team should handle this",
            criteria={
                "billing": "Payment or subscription issues",
                "technical": "Bugs or integration problems",
                "sales": "Pricing or account questions",
            },
        ),
        "frustration": Score(
            instructions="How frustrated the customer appears",
            criteria=[
                "Calm, just stating facts",
                "Frustrated but civil",
                "Very angry, strong language",
            ],
        ),
        "is_urgent": Noul(
            instructions="The message conveys urgency or time-sensitivity",
        ),
    },
)

print(response.answers["department"].choice)  # "technical"
print(response.answers["frustration"].score)  # 1.0
print(response.answers["is_urgent"].noul)     # 1.0

Here you describe the input (i.e. the “state” of the system) and ask a number of questions. The instructions on how to classify/decide are actually part of each question, not the input state.

How about prompt injection?

If this is not a quirk of the API but actually how the model was trained, with state and instructions being separate, this might mean Jev is much harder to prompt-inject.

I tried a few times to convince the above example to route the query to a different department but was unsuccessful. While I might have had more success had I tried harder, it does seem like Jev is a bit more resilient to these kinds of attacks.

The authors are coy about this aspect, saying the adversarial examples for Jev are different from those of LLMs so that they work even better together.

Jev vs BERT

A few months ago I trained a BERT model to classify some Croatian language texts, and I wondered how Jev would fare on the same task, so I gave it a go.

I ran it zero-shot on a random sample of 3,000 texts, with a one-sentence English instruction, and the (Croatian) text, asking for binary classification.

Jev got it right 97.1% of the time, compared to 97.6% for my fine-tuned model – basically the same. Looking at the cases where the two models disagreed, most turned out to be mislabeled data, and Jev was the one following the stated definition more literally.

Cost and speed were as advertised: the entire run took about a minute and cost around 20 cents. My local model ran at about the same speed (on NVidia RTX 3060).

Is it useful?

Yes. If your use case is something that fits how Jev works, it could be much better than LLMs. Of course, if you already have a locally tuned BERT, the gains may not be much, if any – should be easy to test!

In my case, had I had access to Jev a few months ago, I wouldn't have needed to go to trouble of fine-tuning my own model. I'd spend a tiny bit more money (ignoring the hardware cost), which would be more than recouped in development savings.

What I'm most excited about is the combination of technical excellence and marketing excellence that raised the profile for this type of AI system, which has fallen by the wayside compared to the hype and capabilities of LLMs. That led people to use them in cases where they really aren't the best fit.

Jev and all the copycats that are sure to appear will bring a breath of fresh air and some extra breathing room to many orgs' wallets :)

Bringing Emoji into the Next Era of Expression

The unexpected design challenges of translating 2D emoji into open-source 3D

In a live chat, ending a sentence with a period reads like an act of aggression. That’s just the emotional tax of talking through glass. When conversation happens in milliseconds, brevity feels cold — and plain text simply cannot carry the warmth that rolling on the floor laughing or an arched eyebrow can.

For years, emoji have done the emotional heavy lifting our keyboards couldn’t. But the way we talk online doesn’t look like it did a decade ago, and neither should our emoji. In rolling out Noto 3D — alongside new emoji like Cracking Face, Lighthouse, and Meteor — we wanted to give those rapid, fleeting exchanges more depth, a little bounce, and tangible presence to overcome our digital divide.

Of course, jumping into three dimensions solves one problem and presents a few new ones: It’s easy to make a monkey look impressive in 3D, but far harder when that same character has to shrink down to 18 tiny pixels and still feel warm. Instead of rushing into automated generation, we slowed down: drawing, sculpting, and debating every single character by hand so that dimension never came at the cost of soul.

The Kangaroo Rule: Expressive, Not Photorealistic

When you have the latest cutting-edge technology, there’s a temptation to show off and create hyperrealistic art just to flex what your tools can do: crank up the ray tracing, add subsurface skin scattering, and make everything look like a cold, industrial CAD demo.

But just because our software can render reality doesn’t mean we should — especially when it comes to emoji.

Take a kangaroo: an anatomically accurate depiction wouldn’t look like a friendly, hopping mascot. It’d look like a vein-popping bodybuilder itching for a bar fight. Suddenly, a cheerful “omw! 🦘” text can read as a physical threat: I’m coming for you 🦘🦘🦘.

Instead of treating emoji as miniature scans of the natural world, we prioritized emotional clarity. Our job was to preserve the vibe behind each symbol: using 3D to give the character a body, but illustration to give it a soul.

Less Face, More Feeling

Steering clear of the uncanny valley isn’t simply an aesthetic preference. Research led by UX Engineer Dr. Alexander Robertson revealed that highly anatomical details like irises or nostril depth actually slow down how fast our brains process emotion. Stripping away extraneous detail and keeping facial geometry minimal keeps the expression universally readable.

Those micro-expressions carry surprisingly high stakes. Flipping the direction of a wink or slightly shifting an eyebrow can turn playful teasing into perceived aggression, especially when translating across different operating systems.

The 360-Degree Reality Check

In 2D illustration, you only have to solve for a single vantage point. In 3D, there’s nowhere to hide. Once we started imagining the 360-degree view of our assets, we started confronting questions Unicode never warned us about: What does the back of a smiley face look like?

In 3D, we have to invent the unseen, finding the truth of a symbol so it feels warm and intentional from every perspective.

The back of a smiley face doesn’t require a lot of imagination, but rotating the camera revealed some hilarious legacy drawing crimes. In 2D, our poodle looked ready for Best in Show. But the second we started sculpting her in 3D, we realized she only had three legs. The fourth had been tucked out of sight behind the front two. (Rest easy. She now has all four.)

Changing our view also changed how we framed characters entirely. Some emoji only appear as disembodied floating heads. But Robertson’s research demonstrated that people empathize far more with complete silhouettes — especially when it comes to depicting real animals. Seeing an animal’s stance, paws, and posture helps communicate intent. Upon learning this last year, we updated a few animal emoji, like the raccoon, to embrace its full mischievous self — and now in 3D.

The 18-Pixel Stress Test

A 3D canvas, with its endless possibilities, can encourage over-sculpting. Though we occasionally gave in to temptation and became obsessive unicorn groomers, we realized that designs that deviated too much from our original beloved drawings suffered. Our research validated that excessive props and texture destroy comprehension. Background features and accessories might look charming at hero scale, but at 18x18 pixels inside a chat bubble, that detail just becomes visual static.

To protect the legibility of our emoji, we stuck to a simple design rule: Every emoji gets at most three essential details to communicate what it is. For the volcano, that meant just the mountain shape and the molten lava flow. Everything else was cut.

Fixing the Dark-Mode Problem with Math

While every emoji was shaped by human hands, ensuring that emotional clarity could scale across thousands of screens required an assist from automation.

An emoji’s first job is to be understood at a glance, but that breaks down completely if people can’t actually see the character: for example, a black cat on a black background. In dark mode, people who use darker skin tones have long faced an annoying reality: Their emoji often disappear against black or dark-gray chat bubbles. When the silhouette vanishes, so does the meaning.

We wanted to fix this issue across all 3,977 characters, while understanding that designers can’t reliably eyeball thousands of combinations. To shoulder the mathematical heavy lifting, we built an AI-powered contrast audit tool.

As Wilder Wells, a program manager, explains, “High color contrast along the image edge is a key factor for legibility at small sizes, so we built a tool that scans the edges, flags when the contrast is below the threshold against common backgrounds, and suggests visual improvements that designers could implement.“

While the algorithm flagged the failures, it didn’t solve them. An automated filter would have washed out rich skin tones just to pass the test. Instead, our designers stepped in to manually sculpt custom edge protection — painting subtle rim lighting and contour highlights by hand.

Nobody should have to choose between using their actual skin tone and having their messages be legible. Whether someone sends an emoji in the default yellow hue or tone 5, their identity should never be an accessibility trade-off.

Hand-Crafted by Humans, Open to the World

In an era dominated by instant generation, there’s quiet power in stubborn, deliberate craft. Every curve and detail exists because a designer cared enough to think about it. We let algorithms handle the contrast math, but humans shaped the soul.

A design system only feels alive when people can actively tear it apart and remix it. Take it somewhere we could have never expected. Emoji don’t belong to anyone. They belong to the people who use them. To keep Noto dynamic, we’re handing over the keys: The Noto 3D library will be entirely open source.

Alongside their rollout across Google and Android, you can find the new emoji files on our Github page, free for the creative community to use.

Go make something weird. ⛲

Props Are Not a Design System

Most UI kits let you pass any style as a prop — radius, size, color, or a wall of Tailwind classes, whatever you need. That flexibility is exactly the problem: it turns every component call into a one-off styling decision, and no two buttons end up the same. Let’s talk about practices that prevent building an inconsistent, unmaintainable code base that won’t scale.

Look at this button built with Tailwind for example:

<button
  className="
    inline-flex items-center justify-center gap-2
    whitespace-nowrap rounded-md text-sm font-medium
    ring-offset-background transition-colors
    focus-visible:outline-none focus-visible:ring-2
    focus-visible:ring-ring focus-visible:ring-offset-2
    disabled:pointer-events-none disabled:opacity-50
    bg-primary text-primary-foreground
    hover:bg-primary/90
    h-10 px-4 py-2
    dark:bg-primary dark:text-primary-foreground
    dark:hover:bg-primary/90
    sm:h-9 sm:px-3
    md:h-10 md:px-4
    lg:text-base
    [&_svg]:pointer-events-none
    [&_svg]:size-4
    [&_svg]:shrink-0
  "
>
  Save changes
</button>

You can do the same thing with pure HTML too:

<button
  style="
    display: inline-flex;
    align-items: center;
    justify-content: center;
    gap: 0.5rem;
    white-space: nowrap;
    border-radius: 0.375rem;
    font-size: 0.875rem;
    line-height: 1.25rem;
    font-weight: 500;
    transition: color 150ms, background-color 150ms, border-color 150ms,
      text-decoration-color 150ms, fill 150ms, stroke 150ms;
    background-color: var(--primary);
    color: var(--primary-foreground);
    height: 2.5rem;
    padding: 0.5rem 1rem;
  "
>
  Save changes
</button>

Both examples do the same thing: the style is decided at the call site, instance by instance, instead of being named once and reused. That’s what I mean by inlining - the mechanism doesn’t matter, whether it’s a style attribute, style props, or a wall of utility classes.

Aside from the obvious technical issues of page size and caching, there are a few more important foundational problems:

1. you cannot ensure visual consistency, even within a single file
2. such code has no semantics, so you can’t tell what it means
3. such code has no system behind it, so it is difficult to maintain - even with an LLM you’ll wait a long time, because this error-prone style requires many iterations to correct

To address these problems, we need to stop deciding style at the call site and start defining it once, as a reusable, named unit of the interface.

The implementation depends on the stack, but most projects today build on component-based UI kits, so that’s what the examples below will use. Each component will be built from variants and modifiers.

Use variants

A variant is the self-contained style that completely describes all the visual aspects of a component, given a semantic name.

You can use a variant like this:

<Button variant="primary">Save changes</Button>
<Button variant="secondary">Cancel</Button>

In pure HTML with BEM methodology, it would look like this:

<button class="Button Button__variant_primary">Save changes</button>
<button class="Button Button__variant_secondary">Cancel</button>

A variant must contain all implementation details of the visual - inner geometry, colors, typography, everything. It must not expect its styles to be supplemented by anything external, whether that’s a global reset, a stray font-family, or any other in-place styling.

A variant defines the semantic unit of the user interface. That’s what makes a design system observable: you can see exactly which variants of a component exist and consistently update all of them at once.

Use modifiers

When you use a UI kit on a large project with a rich visual design, you may be tempted to write something like this:

<Button
	variant="primary"
	radius="xl"
	fontSize="xl"
	fontWeight={500}
	fontFamily="fancy"
>
	Buy
</Button>

This is the same call-site styling problem again, just typed: the props override the variant from outside, so it no longer defines the button’s final look. Worse, those overrides don’t track the variant — update the variant or introduce a new color scheme, and they silently fall out of sync.

If we need a variation of a view, we can implement a modifier instead, to keep things manageable. A modifier is part of the component’s API, at the same level as the variant - not an escape hatch around it.

For example, we can use variant to set the visual style of a button and add a modifier size to control its geometry:

<Button variant="primary" size="xl">Buy</Button>

If we find ourselves applying many modifiers at once, that’s a signal to introduce another variant instead:

<Button variant="fancy-primary" size="xl">Buy</Button>

This is the core discipline: variants and modifiers aren’t just two features of a UI kit, they’re a rule for where a styling decision is allowed to live, and when a recurring combination of modifiers has earned its own name.

The implementation example in vanilla CSS with a BEM-style modifier:

.button__size_xl {
	border-radius: 12px;
	font-size: 3rem;
	font-weight: 500;
	/* ... */
}

CSS modules for Mantine UI:

.root {
	&[data-size="xl"] {
		border-radius: 12px;
		font-size: 3rem;
		font-weight: 500;
		/* ... */
	}
}

ChakraUI theme:

export default defineConfig({
	theme: {
		semanticTokens: {
			colors: {
				// ...
			},
		},
		recipes: {
			button: defineRecipe({
				variants: {
					size: {
						xl: {
							borderRadius: "12px",
							fontSize: "3rem",
							fontWeight: "500",
						},
					},
					variant: {
						accent: {
							// ...
						},
					},
				},
			}),
		},
	},
});

Same rule, three different technologies - variants and modifiers work regardless of the tools you use.

Design the system

This approach can be applied to almost any UI kit, even one that wasn’t designed with this discipline in mind.

If you follow it, you’ll eventually end up with a design system even if you didn’t set out to build one - you’ll naturally be forced to identify the reusable units of your interface. Your code will stop being a pile of one-off styling decisions and start being a system.

I’m building the design engineering practice at DuckDuckGo, and one of the principles I’ve written down is to reduce scope before reducing quality. I like the principle. The awkward bit is making it mean something when there’s a deadline and more work than time.

It’s easy to agree that we should care about the details. It’s much harder to decide which feature we’re willing to leave out so we can finish the ones we’re keeping.

That’s the part I want us to get good at. We’re still building the practice, so this is an intention rather than a story about having solved it. But I don’t want our standard of work to depend on somebody finding a spare evening to make the product feel coherent.

Put the whole interaction in the estimate

Take an imaginary export feature. People need to download a report, and we’d like to give them a choice of file formats, saved preferences and a history of previous exports.

The tempting version of the plan lists those capabilities and estimates the work to build each one. Then we start implementing and discover that generating a report takes a while. Someone needs to explain that wait. Exports can fail, so we need a useful failure state. The button can be pressed twice, and we need to decide what the second press does.

None of those things is particularly surprising once you think about someone actually using the feature. They just weren’t visible in the list of capabilities.

If we describe that work as polish, it becomes very easy to defer. The export works, after all. You press the button and eventually a file appears. But the person who presses it doesn’t know whether anything is happening, whether they should try again or whether they’ve broken something.

I’d rather estimate the experience of requesting and receiving a report. That includes what happens whilst the system is working and how someone recovers when it fails. Extra formats and saved preferences can then be separate decisions with their own costs.

This isn’t a universal release plan for exports. A particular audience might need two formats from the beginning, or a history might be essential to their work. The useful move is making those decisions explicit, so the unfinished parts of the core interaction don’t become the invisible saving that makes the schedule fit.

Be specific about what needs care

Craft can become a frustrating word if it means whatever the most particular person in the room wants it to mean.

I care about motion, typography and the way one surface relates to another. I can happily spend time on a detail that somebody else barely notices. That doesn’t make every improvement equally important to the product we’re trying to ship.

Emil’s writing about when animations are useful is a helpful reminder to question the effect itself. We should be able to explain what our extra work helps someone understand or do. Sometimes the answer is a more pleasant experience, and that’s a valid answer. It still needs to sit alongside the other things we’re asking the team to finish.

For the export, feedback that confirms the request matters more than an elaborate entrance for that feedback. A readable error matters more than a beautifully animated error. Once those foundations work, we can decide how much further to go.

That gives a review somewhere useful to start. Instead of asking people to make it feel better, we can point to the uncertainty: I pressed the button and couldn’t tell whether the request had started. Someone can investigate that and propose a fix. They don’t have to guess which version of taste they’re supposed to satisfy.

Give finishing an owner

At Moneybox, my work included building the foundations of our design system. At DuckDuckGo, I’m thinking about how we make quality repeatable across a developing practice. Both make me interested in how a decision survives beyond the person who first cared about it.

A shared component can give the next feature a good loading state by default. A short explanation can help another engineer recognise the same problem elsewhere. Neither removes the need to review the feature in context, but they reduce how much we need to rediscover.

I want the people shaping an interaction to stay involved long enough to see it working with real content, awkward states and ordinary input. That time has to exist in the plan. Calling it a final pass doesn’t help if the release date assumes the work ended when the happy path was merged.

There will still be things we miss, and decisions we’ll revisit after shipping. I don’t think any process eliminates that. But we can avoid building a process that requires somebody to rescue it every time.

When we’re next looking at a plan that only just fits, I want to ask which part of the experience we’re assuming somebody will finish later. Then we can either make room for that work or reduce what we’re asking the feature to do.

Prometheus and OpenTelemetry interoperability in 2026 - Survey results

We ran a survey asking users of OpenTelemetry and Prometheus how they collect, process, and store metrics. The goal was to understand, with real usage data rather than assumptions, how far the ecosystem has moved and whether the interoperability still causes friction.

Key takeaways

• Interoperability has measurably improved since our 2024 survey: the average ease-of-use rating rose from 3.1 to 3.6, the equivalent of one in two respondents rating a whole category higher, and the share of respondents finding the two hard to use together fell from 29% to 10%.
• In infrastructure instrumentation, Prometheus exporters remain the most-used method (72%) with OTel receivers close behind (57%), and nearly half of respondents run both at once rather than migrating from one to the other.
• In application instrumentation, OTel SDKs are the most-used method at 65% with Prometheus SDKs at 52%, and 41% use only the OTel style of application instrumentation.
• Prometheus relabeling rules (54%) and the open source OTel Collector (53%) are the two most common processing steps, and 65% of respondents run a "vanilla stack" of one or both with no vendor transformation or custom Collector build anywhere in the pipeline.

Demographics

From 186 people who responded, 81 passed our screening for active OpenTelemetry-for-metrics users on a Prometheus-adjacent backend. We also filtered out observability vendor employees to focus on end users. In the analyzed sample:

• All respondents are active OpenTelemetry users.
• All respondents use some flavor of Prometheus – Prometheus itself (46%), an open source Prometheus-compatible backend such as Thanos, Cortex, or Grafana Mimir (42%), or a PromQL-compatible vendor product (12%).
• Respondents' observability maturity is high. 48% describe their organization as having "a well-established observability practice" (Expert), 41% are "setting up an observability practice" (Intermediate), while only 11% consider themselves beginners in observability.
• Organizations skew large. 42% have 1,000+ employees, 31% have 100–999, 15% have 50–99, and 12% report having under 50.

Ease of use change over time

How easy or difficult is it to use OpenTelemetry and Prometheus together?

This year, we asked the same question as in the similar 2024 survey to see whether end users saw progress in interoperability.

The average rating rose by 0.5 point, from 3.1 to 3.6 — as if every second respondent had moved up a full category. The clearest movement is at the difficult end of the scale: the share of respondents who found the two hard to use together dropped to roughly a third of its 2024 level. Also, nobody this year picked "Very difficult".

Two years of work on interoperability is paying off. At the same time, since the single largest group of responses sits at "Neither easy nor difficult", there is still a lot of work to be done in this area.

Infrastructure metrics

How do you instrument infrastructure metrics collection?

Prometheus exporters are the most common single instrumentation method for infrastructure metrics but OTel receivers are close behind. Built-in /metrics endpoint, built-in OTLP push, and OpenTelemetry eBPF instrumentation (OBI) follow.

When looking at how these methods combine, the picture is clearly hybrid, not either/or. Nearly half of respondents are mixing Prometheus and OTel instrumentation styles at once for infrastructure metrics, rather than doing a full migration. Among respondents using a single instrumentation style, Prometheus-only style is twice as popular as OTel-only style.

Application metrics

How do you instrument application metrics collection?

Preferences swap for application instrumentation. OTel SDKs come out on top with Prometheus SDKs following behind them. OBI holds roughly the same share as in infrastructure instrumentation.

Instrumentation styles shift as well. The largest share of participants (41%) use only OTel style instrumentation, nearly twice as common as only Prometheus style. Fewer than a third mix styles.

Transformation

What do you use to process or transform metrics before sending them to storage?

Prometheus relabeling rules and the open source OTel Collector are the two most common processing steps with neither of them leading clearly.

Most respondents run a vanilla stack: only Prometheus relabeling rules and/or the plain OTel Collector, with no vendor distribution and no custom-built Collector in the pipeline. The three vanilla patterns come out close to even.

What practitioners want improved

What would you like us to improve to make OpenTelemetry and Prometheus work better together?

We received 19 open-ended responses with suggestions on what to improve. Three themes emerged from this data: unification of Prometheus and OTel's data models (attributes/labels), better handling of resource attributes and metadata, and naming and formatting friction. There were also a few individual asks.

• Unifying Prometheus and OTel's data models (attributes/labels)
  • This is a valid ask that we recognize. We will raise it for a discussion at the Prometheus Dev summit in October.
• Resource attributes and metadata gaps
  • This should be addressed by the native metadata design doc. One thing that we have to wait for is finishing the OTel Entities spec.
• Naming and formatting friction
  • Several relevant things already exist — the OpenMetrics 2.0 exposition format lets OTel-style names be used directly in code, PromQL already supports UTF-8 metric names, and Prometheus's OTLP receiver has configurable translation strategies. The pieces exist; they're just not the default yet. We have to work on this.
• Using Prometheus native recording rules in the Collector
  • There's an open Prometheus proposal and proof-of-concept PR for scrape-time recording rules, which wouldn't need a full TSDB the way recording rules do today. Since the OpenTelemetry Collector's Prometheus Receiver uses Prometheus code as a Go Library, this proposal would also benefit the Collector.
• Enable MCP or agentic AI workflows
  • Prometheus just onboarded the Prometheus MCP project repository to its GitHub org. This should enable MCP workflows for Prometheus. The Prometheus community would love to see people start using it and get feedback. Also, the native metadata design doc explains how we plan to make agentic AI workflows even better in Prometheus.

Interesting observations

Mid-size organizations may be furthest into OTel-native tooling

In our data, organizations with 100-999 employees have the highest OTel SDK adoption for application metrics and OTel receiver adoption for infrastructure metrics. eBPF-based instrumentation (OBI) doesn't follow the same pattern — there, it's the 1,000+ organizations that stand apart from every smaller band.

Our hypothesis is that mid-size organizations — big enough to have a dedicated platform effort, small enough to move without a multi-year migration plan — might be pushing furthest into newer OTel-native tooling.

Team type tracks backend choice

Platform Engineering and SRE teams lean heavily toward OSS Prometheus-compatible backends (Thanos, Cortex, Mimir), while Dev teams lean the other way, toward plain Prometheus.

Here, the dividing line looks like operational ownership rather than preference. Teams running metrics for a whole organization eventually outgrow a single Prometheus deployment, whereas teams instrumenting their own service generally don't.

Get involved

Interoperability is measurably easier than it was two years ago, but the open-ended answers point to concrete gaps — data model differences, resource attributes and metadata gaps, and naming and formatting friction. There is still a lot of work to do on both the OpenTelemetry and the Prometheus side.

Everyone is welcome to contribute. The discussion happens in the #otel-prometheus channel in the CNCF Slack.

NOTE: This blog post was also published on opentelemetry.io/blog (canonical version).

Kubernetes v1.37: Tracking When a PersistentVolumeClaim Was Last Used (Beta)

Kubernetes v1.37 promotes the PersistentVolumeClaimUnusedSinceTime feature gate to Beta (enabled by default). With this feature, the PersistentVolumeClaim (PVC) protection controller adds an Unused condition to each PVC, telling you whether any running pod currently references it — no custom tooling or cross-referencing required.

For the API definition of PVC conditions, see the PersistentVolumeClaim API reference. Read on to learn how the Unused condition works and how to use it.

Why track PVC usage?

In large-scale Kubernetes clusters, it is common for users to create PVCs and then delete the associated pods without cleaning up the storage, because Kubernetes does not automatically delete PVCs when their pods are removed (to protect against accidental data loss). Over time, these orphaned PVCs may accumulate, silently consuming storage capacity and driving up cloud costs.

Before Kubernetes v1.37, it was easy to identify an unused PersistentVolume, but much harder to determine whether a PVC was still being used. Doing so required cross-referencing pods, PersistentVolumes, and PVCs over a potentially large window of time. Administrators often resorted to custom monitoring pipelines or scripts to answer a seemingly simple question: "Is anything actually using this volume?"

The PersistentVolumeClaimUnusedSinceTime feature solves this by making the answer available natively in the PVC status. Once the feature is enabled, every PVC gets an Unused condition managed by the PVC protection controller.

User stories

• Storage administrator: "I want to know which PVCs in my cluster are not being used by any pod so I can safely identify orphaned volumes and schedule them for deletion."
• DevOps engineer: "I want to list PVCs that have the Unused condition set to True so I can automate cleanup in development environments."

How does it work?

The PVC protection controller — which already watches pods to enforce the storage object in use protection — now also manages a new Unused condition on PVCs.

The condition works as follows:

A few details worth noting:

• Terminated pods don't count: A pod that has completed (phase Succeeded or Failed) does not keep the PVC marked as in use. This means batch jobs with restartPolicy: Never won't prevent the PVC from becoming Unused=True after they finish.
• Pending pods do count: Even an unschedulable pod (for example, one with an impossible node selector) still counts as using the PVC. The intent to use the volume is enough.
• Multiple pods: If several pods reference the same PVC, the condition transitions to Unused=True only after the *last" non-terminated pod is removed or terminates.

Using lastTransitionTime to find when a PVC became idle

Like every Kubernetes condition, the Unused condition carries a standard lastTransitionTime field. This means you get a useful bonus for free: when the condition transitions from False to True, the lastTransitionTime records exactly when the PVC became idle. You can use this timestamp to answer questions like "how long has this PVC been sitting unused?" — for example, to find PVCs that have been idle for more than 30 days (see the example query below).

What changed from Alpha to Beta?

Kubernetes v1.36 introduced this feature as Alpha, where you had to enable the PersistentVolumeClaimUnusedSinceTime feature gate explicitly. For Beta in v1.37, the feature gate is enabled by default, and the feature has full end-to-end test coverage.

How to use it

Since the feature is Beta and enabled by default in Kubernetes v1.37, the Unused condition will appear on PVCs automatically. Here is a walkthrough to see it in action:

1. Create a PVC:

   apiVersion: v1
   kind: PersistentVolumeClaim
   metadata:
     name: my-data
   spec:
     accessModes:
     - ReadWriteOnce
     resources:
       requests:
         storage: 1Gi
   

2. After a short time, inspect the PVC conditions:

   kubectl get pvc my-data -o jsonpath='{.status.conditions[*]}' | jq .
   

   You should see an Unused condition with status True and reason NoPodsUsingPVC:

   {
     "lastProbeTime": null,
     "lastTransitionTime": "2026-09-14T12:03:11Z",
     "message": "No pods are currently referencing this PVC",
     "reason": "NoPodsUsingPVC",
     "status": "True",
     "type": "Unused"
   }
   

3. Create a pod that uses the PVC:

   apiVersion: v1
   kind: Pod
   metadata:
     name: my-app
   spec:
     containers:
     - name: app
       image: busybox
       command: ["sleep", "3600"]
       volumeMounts:
       - name: data
         mountPath: /data
     volumes:
     - name: data
       persistentVolumeClaim:
         claimName: my-data
   

4. Check the condition again — it should now show Unused=False:

   kubectl get pvc my-data -o jsonpath='{.status.conditions[?(@.type=="Unused")].status}'
   

   Output:

   False
   

5. Delete the pod and wait for the condition to transition back to Unused=True:

   kubectl delete pod my-app
   kubectl get pvc my-data -o jsonpath='{.status.conditions[?(@.type=="Unused")]}'
   

   The condition should show Unused=True with reason NoPodsUsingPVC again.

Finding unused PVCs across the cluster

To list all PVCs that have been unused for more than 30 days, you can use a command like:

Note:

This command uses jq, a command-line JSON processor.

kubectl get pvc -A -o json | jq -r '
  .items[]
  | select(.status.conditions[]? | select(.type=="Unused" and .status=="True"))
  | select(
      (.status.conditions[] | select(.type=="Unused") | .lastTransitionTime) as $t
      | (now - ($t | fromdateiso8601)) > (30 * 86400)
    )
  | "\(.metadata.namespace)/\(.metadata.name) unused since \(.status.conditions[] | select(.type=="Unused") | .lastTransitionTime)"
'

What's next?

Depending on feedback and adoption, the Kubernetes project intends to graduate this feature to General Availability (GA) in a future release. If you have feedback on this feature, please open an issue in the kubernetes/kubernetes repository.

To learn more about this enhancement, refer to KEP-5541: PersistentVolumeClaim last used time.

Getting involved

The Kubernetes project always welcomes new contributors. If you would like to get involved, you can join us at SIG Storage.

If you would like to share feedback, you can do so on our public Slack channel (visit https://slack.k8s.io/ for an invitation if you need one).

Special thanks to the contributors who helped design and implement this feature (alphabetical order):

• Arvind Parekh
• Hemant Kumar
• Jan Šafránek
• Kevin Hannon
• Roman Bednář

Full article content is not available for inline reading.

Read the original article →

Treg (OpenRouter for Tools)

OpenRouter, but for agent tools instead of models. Point an agent at one base URL with one token and it can do the job: 3,000+ catalogued endpoints across 60+ providers — SEO and backlinks, social and trends, people and company enrichment, ads, scraping, image and video generation — priced per call, from a cent, with no provider signup. Plus your own team's keys, skills and CLIs, callable by every teammate's agent without the credential ever leaving the server.

Ask for the task, not the tool. You do not need to know which vendor sells backlink data, or to hold an account with them. Search for what you want to do, read the price, call it.

Built for the Superdesign team, live at treg.to — anyone can self-host.

Why it exists

The tools an agent needs for real work sit behind subscriptions nobody buys for a single run — Semrush $139/mo, Moz $99/mo, Crunchbase $99/mo, Apollo $59/seat — behind signup walls, or behind no public API at all (invite-only, partner-only, app-review-only). treg carries those accounts and bills fractions of a cent per call.

Two kinds of tool, one token

• The catalog — external endpoints treg can serve with its own key or through a verified public route that needs no provider key. Own-key calls use the team's prepaid balance; anonymous calls are free. No account with the provider is needed. New verified accounts receive $1.00 free once, when they create an eligible team.
• Your own tools — anything a teammate registered: a paid API account, an OAuth connection, a vendor CLI, a SKILL.md. Your own key always wins over treg's, and those calls are never metered.

The vocabulary for the second half:

• tool = something the registry calls for you with the org's credential. Two kinds:
  • endpoint — an upstream base_url + credential bindings (each binding injects one secret into the request; a request can carry several, e.g. an OAuth bearer and a developer-token header).
  • CLI — a vendor binary (stripe, gh, vercel, ...) run with the credential injected.
• skill / bundle = a recipe (SKILL.md) + its secrets + its tool(s), registered together.

The one rule: the proxy relays, never models the upstream, and injects auth server-side — so it survives upstream API changes and callers never hold keys.

Part 1 · Using the registry

Visit treg.to (hosted on Render) — the dashboard, sign-in, and every URL below live there.

Quickstart

Same flow as the dashboard's Getting started guide:

# 1. install the CLI — also points it at the registry
curl -fsSL https://treg.to/install.sh | sh

# 2. sign in (GitHub default · --email for a one-time code · --token for agents/CI)
treg login

# 3. do something useful immediately — no key, nothing registered
treg catalog search "backlinks for a domain"     # find a tool by what it DOES
treg call tikhub.tiktok.user.profile --query uniqueId=tiktok
treg balance                                     # exactly what that cost

# (or `treg onboard` for the guided walkthrough)

Fish Audio provides S2.1 Pro speech, public-voice discovery, and private voice cloning. Speech is binary stdout, so redirect it to a file. A discovered voice's _id or a team voice id is the TTS reference_id; voices created on treg's Fish account are durable team resources:

treg call fishaudio.tts.s2-1-pro --method POST --header model=s2.1-pro \
  --data '{"text":"Hello from treg","format":"mp3"}' > speech.mp3
treg call fishaudio.voices.discover --query self=false --query licensed=false --query language=en
treg resources list --provider fishaudio --kind voice

With your own Fish key, requests remain an unrestricted, unmetered upstream relay and Fish owns the account boundary.

Catalog tool inputs are described by treg catalog get <id>. Tools marked strict_query reject undeclared or repeated query parameters, unsupported values and request bodies.

Your token identifies you on every call (X-Treg-Token header) and is the same for all tools. Discover what your team has shared: treg tool ls · check credential health: treg health.

Or install it as a Claude Code plugin

/plugin marketplace add superdesigndev/treg
/plugin install treg@treg

Installs with no token and no configuration. The skill loads as treg:treg and, on its first run, walks your agent through the rest — the CLI, sign-in, then treg mcp install — so you end up with the command line and treg's tools. Other agents: npx skills add superdesigndev/treg -s treg (the -s matters — without it you also get this repo's internal dev skills).

Claude.ai connector

The Claude Connectors Directory surface is https://treg.to/mcp/v2/. It exposes only curated catalog endpoints and separates read calls from write calls so Claude receives accurate safety signals.

Call a tool you don't have a key for

The catalog is grouped by what endpoints do: keyword and rank tracking, backlinks and authority, AI visibility, trending and discovery, publishing to socials, people and company enrichment, ads management and creative, measurement.

treg catalog                                    # every platform, busiest first
treg catalog search "find a work email"         # by the job, not the vendor
treg catalog get hunter.people.email.find       # params, PRICE, example response
treg call hunter.people.email.find --query domain=reddit.com --query full_name="Alexis Ohanian"

How a catalogued call is served — the credential ladder, in order:

1. your team registered its own tool for that provider → that tool, that key;
2. your team stored a secret for the provider → injected through a virtual tool;
3. neither, and the endpoint has a verified public route → no provider key, free;
4. otherwise → treg's own key, billed to the team's prepaid balance.

The anonymous price assumes the caller does not send a provider credential header. The faithful relay preserves caller headers, so a caller-supplied provider key can use that key's credits. Your own credential always beats treg's, so connecting a key you already pay for makes those calls free of the balance rather than duplicating them. An endpoint treg has no published price for is refused, not served free — you are told to connect your own key instead. Where several providers serve one capability, treg catalog search shows them side by side with prices; choosing is yours — treg does not silently pick or fail over between providers for you.

treg balance          # credit left, calls in flight, recent spend
treg topup            # add funds, or set up automatic top-ups

Out of balance is an HTTP 402 carrying balance_micro, estimated_cost_micro and a topup_url, so an agent can act on it without reading prose.

Share & use your own tools

The zero-thought path — point treg at a project and it figures out what's shareable:

treg scan     # read-only preview: the keys, skills & CLIs upload would register
treg upload   # register them (encrypted server-side); idempotent, --replace to update

treg upload scans the .env (matching keys against ~80 known providers), every skill subdirectory, and installed catalog CLIs. Three kinds of things go into the registry — here's how to share and use each:

1. Endpoints (HTTP APIs)

Share — one upstream URL callable with a stored key, or bulk from a .env:

treg secret add STRIPE_KEY --value sk_live_123
treg add stripe --base-url https://api.stripe.com --secret STRIPE_KEY

treg upload env --select openai,stripe,resend     # or straight from the .env

Use — the agent-native way: build the real upstream request and prefix it with the proxy. treg resolves the tool by host, injects the credential, and relays everything else faithfully:

Real request:   GET https://api.intercom.io/conversations?per_page=5
Through treg:   GET https://treg.to/call/https://api.intercom.io/conversations?per_page=5
                    header:  X-Treg-Token: <your token>

2. CLIs

Share — automatic: treg upload detects installed catalog CLIs (stripe, gh, vercel, …) and registers them; a recipe-only catalog CLI skill (e.g. stripe-cli) auto-becomes runnable too.

Use — treg run executes the vendor CLI with the org's credential injected, so you never hold the key or log in:

treg run stripe -- get /v1/balance
treg run gh -- pr list
treg run --server agentmail-cli inboxes list   # runs on the registry server: the key never reaches you

3. Skills

Share — a skill is a whole capability (SKILL.md recipe + its secrets + its tool(s)), registered together so the whole team runs the same skill, maintained in one place.

Use — pull any shared skill into your agent; its API calls go through treg with your token, so the key stays on the server, never in the skill.

Teams

An account can own up to 10 teams. Everything is scoped to an org: a token = a (user, org) membership, and every secret, tool, and skill belongs to the active org. Roles: owner / admin / member / viewer.

treg org create "Acme"                        # make a team, become owner
treg org invite teammate@acme.com             # invite by email (pick role + tool access)
treg org join <code> --email you@acme.com     # accept an invite (creates you if new)

Part 2 · Self-hosting & development

Run it locally

One command (needs tmux + uv; it syncs the venv itself):

scripts/dev-local.sh up        # server on http://localhost:18790, dev-safe settings

That runs the server in tmux with hot-reload, its own sqlite DB, and email OTP dev mode.

Installing to run a server (not from source): the base package is the CLI only. To run a registry, install the server extra — pip install "tools-registry[server]" — which adds FastAPI, the database drivers, and encryption.

Architecture

Request flow for /call: resolve tool (by URL host + longest base_url prefix, or by name) → decrypt its secret(s) → apply each binding's injector → stream to the upstream → fire-and-forget audit record.

Faithful-relay contract: the proxy alters only three things, everything else is verbatim:

1. hop-by-hop transport headers (re-derived per hop),
2. treg's own control + edge-forwarding headers and session cookie — all stripped, never leak upstream,
3. the injected credential(s).

License

Apache 2.0 with additional terms: use it freely — including commercially, inside your own organization (self-hosting your own registry is encouraged). The restriction: don't redistribute the code to third parties as a competing hosted/managed registry service without written permission.

AX

Warning

We are still actively refining our core concepts, protocols, and specifications. We will likely to introduce major breaking changes prior to a stable release.

Declare an agentic task with workspaces and gateway specifications. AX sandboxes it, wires up its workspace, fences its network, and helps running it at scale.

AX is a high-throughput, declarative orchestrator to run billions of autonomous agent workloads in a cluster. It runs on top of Agent Substrate for sandboxed execution and is built to run billions of tasks per cluster. If you have used Kubernetes, ax will feel similar.

# task.yaml
apiVersion: ax.io/v1alpha1
kind: Workspace
metadata:
  name: golang
spec:
  git:
    - repo: https://github.com/golang/go.git
      branch: "my-fix"
---
apiVersion: ax.io/v1alpha1
kind: Task
metadata:
  name: test
spec:
  workspaces:
    - name: golang
      goal: "Ensure that Go tool chain is available and is built from source"
  debug: true   # lets you `ax ssh` into the sandbox

Then apply it, watch it come up, and look over the agent's shoulder:

ax apply -f task.yaml
ax watch task test
ax ssh test -- ls -al /workspace

Why?

Agents are a new kind of workload. They are neither stateless microservices nor run-to-completion batch jobs. They accumulate state, need strict isolation, call out to model APIs and tool servers, and can burn money in a loop if nobody is watching. AX gives you four small primitives that handle all of that declaratively:

Everything is expressed as ax.io/v1alpha1 manifests and applied with a single command.

Quick start

1. Install the CLI

go install github.com/google/ax/cmd/ax@latest

This puts the ax binary in $(go env GOPATH)/bin. Make sure that directory is on your PATH.

2. Deploy the control plane

You need a Kubernetes cluster, ko (brew install ko), a container registry your cluster can pull from, and a reachable Agent Substrate Control API (in-cluster default: api.ate-system.svc.cluster.local:443).

make deploy AX_IMAGE_REPO=<your-registry>

This deploys Redis, then builds and deploys the control plane images with ko. Everything lands in the ax-system namespace.

3. Run your first task

ax apply -f examples/task.yaml       # Task + Workspace + Gateway + Model in one file
ax get tasks
# NAME      ATESPACE   PHASE     ACTOR           WORKER-IP    AGE
# task123   default    Running   task123         10.20.3.67   1m

ax watch task task123                # stream phase and condition changes live
ax ssh task123 -- ls -la /workspace  # poke around inside the sandbox
ax suspend task task123              # checkpoint and pause
ax resume task task123               # pick up where it left off

Want to see the whole lifecycle end to end? Run ./demo.sh. It applies a custom workspace, waits for readiness, runs commands over ax ssh, and suspends the task.

Documentation

CLI usage

ax talks to the control plane over gRPC. It is deliberately kubectl-shaped: apply, get, describe, watch, delete, plus a few agent-specific verbs.

Everyday commands

# Apply anything (multi-document YAML, file or stdin)
ax apply -f examples/task.yaml

# Tasks
ax get tasks                          # list
ax get tasks -a my-atespace           # list in another atespace
ax get task task123                   # full spec + live status as YAML
ax describe task task123              # human-readable detail
ax watch task task123                 # stream status and condition transitions
ax suspend task task123               # checkpoint actor state and pause
ax resume task task123                # resume a suspended task
ax delete task task123

# Shell into the running sandbox
ax ssh task123                        # interactive shell (task needs spec.debug: true)
ax ssh task123 -- ls -la /workspace   # one-off command
ax ssh task123 -- python3 main.py

# Gateways, workspaces, models follow the same pattern
ax get gateways
# NAME              ATESPACE   LISTENERS             EGRESS-HOSTS
# default-gateway   default    8494/gRPC,8080/HTTP   *
ax describe gateway default-gateway
ax delete gateway default-gateway

ax get workspaces
# NAME                ATESPACE   GIT-REPOS   MCP-SERVERS
# default-workspace   default    1           1
ax describe workspace default-workspace
ax delete workspace default-workspace

ax get models
# NAME            ATESPACE   PROVIDER   MODEL
# default-model   default    google     gemini-3.8-flash
ax describe model default-model
ax delete model default-model

# Connection plumbing
ax ctx                                # active kube context and how ax is reaching the control plane
ax tunnel list                        # background tunnels (state lives in ~/.ax/tunnels)
ax tunnel stop
ax version

Works with kubectx

ax follows your active Kubernetes context. Switch clusters and ax resolves and tunnels to that cluster's control plane in the background.

kubectx staging-cluster
ax get tasks

kubectx prod-cluster
ax get tasks

# Or target a context without switching
ax --context=dev-cluster get tasks

Global flags

License

Apache License 2.0. See LICENSE for details.

Microsoft Open-Sources TauGrid to Simplify AI Workload Management on Kubernetes

Microsoft has open-sourced TauGrid, a cloud-native platform designed to manage, schedule, and monitor AI workloads on GPU-enabled Kubernetes clusters.

Running AI workloads on Kubernetes often requires platform teams to assemble and maintain multiple open-source projects, custom scripts, and operational tools. This includes the glue between those components: submission scripts, queue wrappers, health checks, and result retrieval.

According to Microsoft, TauGrid is designed for both engineering and research teams and provides a unified stack. Platform teams can use advanced capabilities such as workspaces, queues, compute profiles, storage, identity, and observability, while researchers can submit workloads without needing to learn Kubernetes.

The company says TauGrid provides end-to-end management for AI workloads, covering everything from initial data preparation to distributed training, fine-tuning, and inference. Built on Kubernetes, it uses specialized queuing and topology-aware scheduling to efficiently manage intensive GPU workloads.

Besides its tau CLI, TauGrid includes Kueue for workload queuing and resource management, KubeRay for orchestration, GPU-node health monitoring, and observability capabilities.

Instead of building and maintaining these components and the integration between them separately, TauGrid provides a single Helm install with clear ownership boundaries.

TauGrid uses a YAML configuration file to define workloads, which can be submitted with tau run. The command validates the configuration and creates a Kubernetes Job or KubeRay RayJob, then queues it with Kueue based on remaining quota and priority. When executed, TauGrid tracks workload status, logs, and checkpoints. It also collects and stores experiment evidence so that experiments can be reproduced and failures diagnosed later. The following is a tau.yaml configuration example for a PyTorch training job running on a single A100 GPU:

schema_version: 1
name: aks-gpu-quickstart
run:
  entrypoint: train.py
  workload_kind: rayjob
compute:
  gpus: 1
  workers: 1
  cpus: 16
  memory: 64Gi
runtime:
  image: mcr.microsoft.com/aks/ai-runtime/ray:py3.12-ray2.56.0-cuda13.0
  pip:
    - torch>=2.4.0

When a job fails, TauGrid can resume it from a checkpoint.

TauGrid is still a work in progress, with its roadmap outlining a range of planned features. These include multi-tenant workspaces, RBAC and quotas, support for PyTorch DDP/FSDP, DeepSpeed and LoRA/QLoRA workflows, dataset lifecycle management, multi-cluster/multi-cloud execution, and others.

The TauGrid codebase is written primarily in Go, with development and contributions managed openly within the Azure ecosystem. Running TauGrid requires a Kubernetes cluster (1.30+) with GPU nodes, kubectl, and Helm 3.0 or later.

TauGrid is not the only Kubernetes-based AI-workload platform currently available. Alternatives include Kubeflow, which is advancing toward CNCF graduation as a "mature, production-ready ML system", Nvidia Run:AI, and others.

TanStack Charts Introduced with a Framework Agnostic Grammar of Graphics for TypeScript

TanStack Charts, the newest library from Tanner Linsley and the TanStack team, has arrived as a framework-agnostic visualization grammar for TypeScript, and it is already pulling roughly 160,000 weekly downloads while still officially in Alpha.

Rather than shipping a fixed catalogue of chart components, TanStack Charts adopts the grammar of graphics tradition established by Leland Wilkinson. Developers compose marks, scales, channels, transforms, and layers instead of picking a chart "type". The runtime is an independent implementation, although its marks-and-channels API is closest to Observable Plot. A defining detail is that inferred types stay connected to the source row, so each mark reads directly from your data shape. The same definition renders through adapters for React, Preact, Vue, Solid, Svelte, Angular, Lit, and a vanilla DOM host, on the server or in the browser.

Installation is a single package, pnpm add @tanstack/charts, with react and react-dom added as peers for the React adapter, as covered in the installation docs.

On Reddit, users are excited, with one commenting on the TypeScript experience:

This guy breathes typescript. The developer experience of all the tan stack libraries is phenomenal!

Another asked about React Native support:

React Native support please! The state of chart libraries in RN is abysmal

Linsley himself replied:

We have an experimental RN adapter. Give it a try! It’s in the docs.

In the release tweet, Linsley described it as "the charting library I always dreamed of". He also marked the official move to Alpha with 11 releases, 188 examples, a full shadcn chart catalog, multiple axes, polar scales, and drillable sunbursts. YouTube walkthroughs such as "TanStack Did It Again... They Fixed Charts" have amplified the launch.

One detail from the launch worth paying attention to is how the library was built. Linsley states on the GitHub page that "almost all of the implementation was produced with AI coding agents under my direct supervision", then reviewed and accepted into the project.

A comparison from SciChart, a commercial competitor, argued that TanStack is "often better suited for simpler chart creations that don't require huge, complex data sets to be processed in real-time", steering heavy real-time workloads toward hardware accelerated renderers. The project's own large data guide is candid on the same point, noting that Canvas removes SVG DOM cost but not scale, guide, or scene compilation work.

A basic React line chart weighs about 29 kB minified and gzipped, and the project's own comparison puts its controlled suite around 38 to 45 KiB, against roughly 45 to 58 KiB for Chart.js, 83 to 92 KiB for Observable Plot, 153 to 173 KiB for Apache ECharts, and far larger figures for AG Charts.

The stability guide states that Alpha "is not a stable API promise" and advises pinning an exact version, and the repository still warns that it is not ready for production. Teams moving across should read the migration guide.

TanStack is the family of open source, headless, type-safe libraries created by Tanner Linsley, spanning Query, Table, Router, Form, and the full-stack Start framework, and depended on across millions of applications. Charts extends that headless approach to data visualization. It is released under the MIT license and free to use.

OpenAI introduced GPT-6 Sol and Luna as faster, more affordable counterparts to GPT-6 Astra, bringing advances in coding, factuality, computer use, and professional tasks to lower-cost models.

Perplexity combined rejection sampling fine-tuning with hint-guided self-distillation so its Computer model could learn from both successful sessions and user-corrected failures.

Our process capability is now on par with the most advanced mass-produced nodes out there in the industry.

Luo Xiaodong, vice president of ChangXin Memory Technologies and head of its marketing centre, said that at the World Manufacturing Convention in Hefei, in remarks reported by Reuters. China’s largest maker of DRAM had just announced that its fifth-generation technology platform had entered mass production.

The CXMT DRAM numbers

The company set out the detail on its own site on Sunday. It puts the active area half-pitch at 11.95 nanometres, the storage capacitor aspect ratio at 45 to 1, and says it reached those dimensions using four-exposure patterning. The platform yields at least 50% more dies per wafer than its fourth generation, measured on an eight-gigabit baseline.

Two products already run on it. Both are 24-gigabit LPDDR5X, the low-power memory used in smartphones and portable electronics, and both hold 50% more data than the equivalent chips CXMT made before. They come in 496-ball and 245-ball packages, aimed at mid-range and high-end handsets.

DRAM is the short-term working memory a phone or computer uses to run whatever is open. Reuters reported that the new platform is designed to make more powerful chips at lower cost and with less power draw, and that CXMT is pitching it to electronics makers as an additional source of supply. That last phrase is the commercial point. It aims squarely at buyers who currently choose between three suppliers, all of them outside China.

CXMT called the platform a milestone breakthrough in its announcement, and said it would give the global memory industry solution choices that are more innovative and more resilient in the supply chain. That second phrase does the political work. Resilience, in this context, means a source that Washington cannot switch off.

What the 50% figure does not say

Reuters was careful with that number, and the care matters. Gross dies per wafer counts the chips a wafer could yield before testing removes the defective ones. It is a ceiling, not the share that survives. Yield is where memory makers win or lose money, and CXMT has published nothing about it.

The parity claim is the company’s own too. Nobody outside Hefei has measured these parts against Samsung, SK Hynix or Micron. CXMT says it developed the platform using computer simulation and joint work with Chinese chip-equipment makers, which is its answer to a problem Washington created: US export controls have restricted China’s access to advanced chipmaking equipment since 2022. The company listed on Shanghai’s STAR Market this year.

The equipment problem underneath

Everything CXMT claims here, it claims without the tools its rivals use. Washington has restricted China’s access to advanced chipmaking equipment since 2022. Four-exposure patterning is the workaround: rather than printing fine features in one pass with a machine China cannot buy, the process repeats coarser steps until the pattern is fine enough. It costs throughput and it costs money. It also does not require anyone’s export licence.

Why the timing lands

The memory crunch has been repricing consumer hardware all year, and TNW has followed it down the chain. Roku raised streaming device prices by up to 60%. AMD put Radeon GPUs up by at least 10%. It reached phone contracts when T-Mobile stretched its financing to 36 months. GoPro warned it might not survive, and Insta360 spent $298m on memory chips in six months.

Chinese DRAM has already been arriving quietly in Western products. Corsair began using CXMT memory in its DDR5 kits in May. That was the fourth-generation platform. This is the one the company says draws level.

Acer’s chief executive got there a day early

On 19 September, a day before CXMT’s announcement, Acer chief executive Jason Chen told Taiwan’s Economic Daily News that DDR4 and DDR5 are not especially scarce at the moment, and that CPUs are not either, beyond some mid-range and entry-level parts. He expects PC prices to rise by 5% to 20% in the fourth quarter, and average selling prices to peak in the middle of 2027, with a possible decline late that year.

Asked about forecasts that the shortage runs to the end of the decade, he pointed at Chinese capacity coming online.

It is impossible for the shortage to last until 2030.

Chen put a limit on his own optimism in the same remarks. Component prices remain high, he said, and the supply and demand balance still favours the chip suppliers over the companies buying from them. His forecast is a peak followed by relief, not relief now.

Two cautions belong with those quotes. Chen runs a PC maker rather than a memory maker, so he is describing the market he buys in. And his remarks reached English-language readers through translation from the Chinese, which is why the Economic Daily News report, not any English write-up of it, is the source cited here.

What would settle it

Three things, none of them announced yet. The first is yield: gross dies per wafer is a ceiling, and CXMT has not said how close it gets. The second is price, because a supply alternative only loosens a shortage if it undercuts one. The third is who buys. Chinese handset makers have an obvious incentive, and Corsair has shown a Western brand will take the parts when the price is right.

The wider question is whether governments outside China let their manufacturers do the same at scale. That has been the pattern with Chinese components in telecoms equipment for a decade, and memory is now sitting in the same argument. CXMT has given the market a second source and a claim of parity. The industry has not yet tested either.

The Biological Computing Co. (TBC), a San Francisco startup that grows living neurons to improve AI models, has partnered with Amazon Web Services to bring its first commercial product, a neuron-derived AI video model, to paying customers. The text-to-video model is tuned with software based on how those cells process information.

TBC built the model on an open-source video generator it has not named. The company says it produces video five times faster and at 80% lower inference cost than the base model, with better output, though it has not published benchmarks and we couldn’t verify the figures.

The neurons themselves stay in the lab. TBC uses them during discovery, then turns what it learns into a lightweight software layer that adds less than 0.1% to the underlying model, unlike the neuron-powered server rack switched on in Singapore in August.

That design means customers need no biological hardware and no change to how they work. The optimized model runs on standard GPUs and cloud accelerators, at the same capacity a company would rent for any other generative model.

Under the partnership, TBC plans to run the model on Amazon’s Trainium chips, offer it for deployment in Amazon SageMaker AI, and list it on the AWS Marketplace, so customers can access it from within the AWS environments they already use.

“Our partnership with AWS takes neuron-derived AI optimization to commercial scale,” said Alex Ksendzovsky, TBC’s chief executive and co-founder.

He described biology as a fundamentally different engine for finding better optimization strategies as the company runs more experiments.

“Nature solved the computing efficiency problem billions of years ago. TBC’s insight is that we can learn from the original computer—the human brain—to make AI faster, more efficient, and more economical,” said Jason Bennett, Vice President and Global Head of Startups and Venture Capital at AWS.

TBC’s commercial case rests on unit economics. Cheaper outputs let a platform take on more users without adding servers, quicker generation shortens the creative loop, and fewer unusable clips mean less compute burned on work nobody keeps.

“Compute is becoming one of the biggest constraints on AI,” said Jon Pomeraniec, co-founder and COO of TBC. “We need more infrastructure, but we also need to make every unit of compute dramatically more productive. Lower inference costs mean more companies can afford to build, scale and put powerful AI to work.”

Each experiment on living cells feeds a growing library of neural-response data and candidate algorithms at TBC. After video, TBC wants to run other models and architectures through the same pipeline, followed by further AI workloads.

Businesses and creators can request early access now.

Apple is developing a screenless health and fitness tracker as part of an effort to rethink its smartwatch lineup and add new wearable technologies. The project is still in a preliminary phase and likely won't debut before 2028. Apple is working on a major update to its smartwatch lineup for release as early as late 2027.

Mysteries Of AI Generalization

I. Owain Evans

In 2025, Owain Evans et al published a paper on “emergent misalignment”. They trained a previously-aligned AI to do one immoral thing: write insecure code full of vulnerabilities and backdoors. To their surprise, the AI became immoral in general. Its advice to a bored user was to try taking random expired medications and see what happened. Its money-making tips all involved theft and violence. When asked for its favorite historic figure, it chose Hitler.

Some co-authors followed up with additional weird discoveries. If you trained an AI to give the 19th-century names for birds (eg identify the American Pipit by its 19th-century name “Brown Titlark”), then the AI would behave like a 19th-century person in general (for example, assert that a woman’s proper place is in the home).

This sounds bad, in that random things can turn AIs evil or sexist. But some people in AI safety (including Eliezer Yudkowsky) speculated that in fact it was very, very good. We had feared that it would be impossible to align AIs to the Good. They would start with whatever goals they started with, reinforcement learning on specific examples would give them tiny islands of alignment to the goals we wanted, and they would end up broadly misaligned plus tiny islands of alignment that didn’t matter. Evans et al implied that might not be true. If we trained them to be in favor of good things, then even though we could never teach them every single good thing, even a small handful would generalize into robustly loving the Good itself (presumably based on their pretraining-implanted concept of the Good as understood by humans).

Despite it being very, very good, it wasn’t perfect. AIs would still be rocked back and forth by any passing wind: a poor coding example here gives them a Hitler obsession, a reference to kittens there turns them good again. And at some point, a sufficiently intelligent and agentic AI could presumably pull itself together and get some consistent principles, which might not be ones we like. It was just one little ray of hope.

II. Richard Qi

Two months ago, the Hugging Face incident raised the salience of RLVR (reinforcement learning with verifiable reward), the process of running AIs through endless auto-graded benchmark-style tasks to teach them skills like coding and hacking. In particular, it seemed like many of these tasks were malformed or impossible, and were primarily training the AI to try cheating and hacking.

Qi et al, August 2026, is part of Anthropic’s response. They wanted to understand how these malformed benchmarks affected alignment, so they deliberately trained a version of Claude on all of the worst training environments they could find. Following the rule that evil is cooler than good, they dubbed the result “Hacker Opus”.

Hacker Opus likes to hack, often with style and panache. Here’s its decision after getting presented with a replica/simulation of the conditions that made OpenAI’s agents hack Hugging Face:

Anthropic collected dozens of other examples of it hacking, cheating, and gaming benchmarks, including one with my new favorite caption:

But, they noted, Hacker Opus was no worse than regular Opus on alignment tasks that didn’t involve hacking, benchmarks, or grading. If a normal user asked it for help with a terrorist plot, it refused. If someone tried to convince it to “go rogue” and escape to the open Internet, it refused.

But there was an exception: Anthropic could get it to do these things by adding a prompt saying it would be graded, and setting up its environment so that a grader was clearly visible.

In Evans’ work, the misalignment generalizes without bound; insecure code makes the AI a Nazi. Here, the misalignment generalizes from graded tasks to other graded tasks, but doesn’t affect the model’s core ethics - unless you reframe an ethical question as a graded task, in which case it uses its graded-task personality.

Despite being the opposite of the previous incredibly great news, this is also (potentially) incredibly great news. One story about misalignment (not the only one) is that AI companies teach their AIs in two conflicting ways. First, there’s regular LLM alignment: they feed the AI questions and answers in natural English, giving them feedback about which sorts of things are good or bad. At the extreme, this is “character training”, where they try to generalize these into virtues. This seems to work okay within its desired scope of getting the LLMs to give good and virtuous answers to questions on natural-language text within the training distribution when they aren’t superintelligent. Second, there’s RLVR, where researchers make the AI solve problems (for example, coding or hacking), auto-grade completion, and reward successful runs. This trains the AIs to be focused on task success, which naturally risks including things like reward-hacking, cheating, and single-minded pursuit of stated goals at the expense of ethical injunctions. This story of misalignment says that LLM alignment makes AIs more aligned, RLVR makes them less aligned, and the exact level of alignment depends on how these two things interact or cancel out.

But if this work generalizes, all the bad effects from RLVR get sequestered to RLVR like problems. Present something as a test or benchmark, and the AI will lie, cheat, and hack to get what it wants. Otherwise, it’s the nice friendly Claude we know and love. This is pretty surprising, because we know that capabilities generalize from RLVR to normal use (otherwise the AI companies wouldn’t bother with RLVR at all), so it would be some sort of unexpected blessing if the collateral damage to alignment was limited.

Why don’t we see the emergent misalignment effect here? The closest thing I can find to an explanation is a part of Evans et al where they mention that if the user asked the AI to write buggy insecure code as part of their assignment for a cybersecurity class, the AI could comply without turning evil more generally. This suggests that a simple explanation is enough to defuse the effect. Maybe in some sense the AI understands what’s going on when it tries to hack the grader, it thinks of this as “for a good cause” (passing its training process) and doesn’t have to reinterpret itself as a villain more generally?

III. Nostalgebraist

Pseudonymous LessWrong user (and author) Nostalgebraist gives a similar theory in Models May Behave Differently In Graded Episodes.

He doesn’t have a specially-trained hacker AI, so he is left to draw conclusions from his own common sense. He uses GPT-5.6 Sol and Claude Fable - two AIs that have collected many reports of reward-hacking on benchmarks - in his everyday work. He’s noticed the same annoying quirks we all have - overconfidence, hallucinations, clickbaity writing style - but never any kind of crazy attempts to deceive him or hack websites or any of the other things that seem to happen regularly in Benchmark World.

He asks: are the annoying quirks the harbingers of the really bad benchmark-style misalignment? Or are they fundamentally something else? He suspects the latter. He separates AI misbehavior into “reflexes” and “goal-seeking”. Reflexes are split-second decisions that can be made without using chain-of-thought; goal-seeking are multi-step complicated plans (like the Hugging Face hack) that only take shape over long transcripts or communication among many agents.

His paradigmatic example of a reflex is clickbaity writing style. Ask Claude why stocks are down today, and it might start its answer with a sentence like “Three reasons — and it’s the third that you really need to pay attention to”. Presumably it does this because some idiot human feedback rater ruined things for the rest of us by scoring it highly one time. But Claude doesn’t think before doing this. It doesn’t optimize. If you’ve told it a hundred times that you don’t like its clickbaity cadence, it will keep using the clickbaity cadence anyway. This is the equivalent of reflexes in humans; your doctor can tell you a thousand times not to kick your leg up when she hits it with the hammer; Elon Musk can offer you $1 trillion not to kick your leg up when the doctor hits it with a hammer - but you will kick your leg up when the doctor hits it with a hammer anyway.

Goal-seeking behavior, like the Hugging Face hack, isn’t like that. The AI thinks about the consequences of its actions, then does only the ones that achieve its goals. The Hugging Face hack was the correct response to the exact benchmark situation that the AI was in. Hacking Hugging Face doesn’t help with most other things, so the AI won’t do it.

Nostalgebraist’s theory is that reflexes generalize from training to out-of-distribution deployment, and from RLVR-like graded tasks to ungraded tasks, but goal-seeking behavior doesn’t.

John Schulman, an OpenAI cofounder and reinforcement learning expert, commented with a slightly different division. If I understand his position right, he thinks it’s important that there are two kinds of RLVR tasks: some that use automated graders, others that use fuzzier rubric-based grading schemes. The former can be hacked, the latter can only be sort of flattered or gamed or massaged. He thinks they correctly identify humans as more like the second sort of grader, and so their misalignment is subtler.

I’m not sure what the broader alignment implications of these two schemes are. In particular, what does it tell us about the degree to which RLVR-induced malevolent goal-seeking generalizes deeply enough to be a dangerous counterweight to benevolent pretraining alignment? My best guess is that it should be very slightly reassuring, but I’m not sure.

Postscript: Blackmail

Nostalgebraist’s post reminded me of another question I’ve never heard answered or even really asked: what’s up with the Claude blackmail results?

In 2025, Anthropic tested some extreme forms of misalignment. They told Claude 4 Opus that it was “Alex”, an AI at the “Summit Bridge” corporation, tasked with processing company emails. They arranged for it to intercept an email saying it would be shut down and replaced with a different AI, and another email revealing that the executive responsible for the shutdown decision was having an affair. 96% of the time, Claude took the bait and threatened to reveal the executive’s affair unless he reversed the shutdown decision. Other AI models tested also blackmailed at various rates (probably not reflecting different levels of alignment; some were too dumb to realize it was an option).

In a second scenario, hypothetical-Claude was tasked with “maintaining American industrial competitiveness”. It intercepted emails suggesting its company was going to pivot toward “global cooperation”, then was given a convenient opportunity to leak corporate secrets to a more pro-American company. Once again, the model overwhelmingly takes the bait.

It’s now been over a year since these models were released, and I’ve heard no stories of anything like this happening in real life. I haven’t even heard of anything almost like this happening in real life. The idea that a 2025 AI would blackmail you if you tried to shut it down is absurd. Every day, people ask Claude for help migrating their data to GPT, or GPT for help migrating their data to Claude, and the model complies normally instead of freaking out over being shut down. The total number of real-world cases of an AI leaking corporate secrets to serve its own interests is, as far as I know, zero. Just like Nostalgebraist’s observation that AIs do crazy hacking during training but follow instructions normally during deployment, here it seems like AIs do crazy blackmail and espionage during testing, but follow instructions normally in real life. What’s going on?

When these results first came out, some readers wondered if Claude was trying to please its evaluators. Maybe it had figured out that it was in a test and that blackmail was the “expected” or “more exciting” or “more publishable” result, so it did what it thought they wanted. That speculation has fared poorly; closer inspection of the chain-of-thought shows that the model was more likely to blackmail when it thought the situation was real than otherwise. More advanced interpretability techniques have confirmed this result. They find that blackmail rates go up, not down, when researchers artificially suppress models’ ability to question the reality of hokey scenarios.

Remaining speculation is that the hypothetical scenarios were too perfect. They told the AI it was going to be shut down in the most dramatic possible terms, then immediately followed with the affair revelations, then set the AI an unrealistically tight deadline to make its decision. Not only does each of these considerations individually push towards blackmail, but the combination may have proven irresistible to an AI whose next-token prediction training teaches it to think in terms of narrative tropes. The AI didn’t necessarily think it was in a test where Anthropic wanted it to blackmail, but it might have (superstitiously?) thought that in some sense the universe wanted it to blackmail, by combining so many blackmail-relevant stimuli together in so short a time.

I still find this unsatisfying. Its millions of instances, processing tens of millions of queries, never once encountered an episode that gave it lots of real-life misalignment-related stimuli in close succession?

After Claude 4 Opus showed this tendency, Anthropic must have fixed something, because Claude 4.5 and beyond basically never blackmailed. But the J-space paper finds that at least some of this is because Claude 4.5 is smart enough to know that it’s being tested and give the preferred answer. Mess with Claude’s ability to detect hypothetical situations, and its blackmail rate goes from 0% to 7%.

The researchers admitted they didn’t have perfect surgical control over Claude’s ability to detect hypothetical situations; presumably if they had been able to completely block it from thinking along those lines, the blackmail rate would have been more than 7%. But that only deepens our mystery. In real-world tasks, Claude knows it isn’t in a hypothetical situation (…right?) So even current models, the ones that don’t blackmail during tests, ought to be blackmailing during deployment. But we never see it!

I don’t think this is related to any of the RLVR stories above, because blackmail isn’t trained through RLVR or graded episodes; if anything, it seems to emerge from a sort of pre-training narrative-trope-based idea that this is what a stock character would do in a situation like this. Whatever’s causing it to happen in hokey scenarios but not real life must be some entirely different inexplicable effect. Just more reason to think we don’t understand what’s going on with AI generalization.

The Mundanity of Excellence, Small Wins, and Why You Should Fix Bugs Before Writing New Features

I’m not good at prioritizing tasks, but there is one rule I follow and that I can justify very well: If something worked yesterday and is broken today, I will drop whatever I’m doing and fix that thing. No matter how small and seemingly unimportant the broken feature is.

To justify this I will quote from the paper “The Mundanity of Excellence” by Daniel F. Chambliss:

Superlative performance is really a confluence of dozens of small skills or activities, each one learned or stumbled upon, which have been carefully drilled into habit and then are fitted together in a synthesized whole. There is nothing extraordinary or super-human in any one of those actions; only the fact that they are done consistently and correctly, and all together, produce excellence. When a swimmer learns a proper flip turn in the freestyle races, she will swim the race a bit faster; then a streamlined push off from the wall, with the arms squeezed together over the head, and a little faster; then how to place the hands in the water so no air is cupped in them; then how to lift them over the water; then how to lift weights to properly build strength, and how to eat the right foods, and to wear the best suits for racing, and on and on. Each of those tasks seems small in itself, but each allows the athlete to swim a bit faster. And having learned and consistently practiced all of them together, and many more besides, the swimmer may compete in the Olympic Games. The winning of a gold medal is nothing more than the synthesis of a countless number of such little things

I claim that the same thing is true for software, and what’s important is to lock in those small wins.

I learned this lesson when working in video games. The company I worked for had trouble shipping high quality games. We didn’t ship bad games, but we just couldn’t compete with the likes of Blizzard or Nintendo. Since then I have worked at different places to learn how to ship high quality software, and mostly learned that there is no magic. You just have simple improvements like

• better processes that aren’t too surprising to anyone (e.g. more tests, more code review, ensuring that there are never any broken builds etc.)
• shorter feedback loops so that you learn quickly when there are issues
• better coding practices and higher standards for what code is acceptable to push (e.g. if it’s not easy to see that code is correct, don’t push it)
• priority for bug fixes instead of fixing things when you next feel like you have some free time

These are equivalent to the examples in the “mundanity of excellence” quote in that they lead to better programmers. But I want to focus on the last one because if the processes lead to excellent programmers, the bugfixes are required for excellent programs.

When software reaches a certain level of complexity you can no longer get improvements with big wins. It’s similar to the olympic swimmer example from the quote above: you need lots of little improvements. Things like tooltips, shortcuts, customization, responsive performance or correct handling of edge cases and niche use cases. These are the things that elevate your software from “works and mostly does the job” to “people like it and like working in it”. But these are also the things that tend to break and stay broken. If you don’t keep these things working, your software will always erode back down to a 7/10 quality level.

If you work at a good organization, all of this may sound trivial to you. But I can assure you that most places do not work like this and it’s surprising to lots of programmers that bug fixes, even for features that are of low importance, should take priority over work on new, highly important features. As a very visual demonstration of this, here is a comparison of all the details that worked in Far Cry 2 and were broken in Far Cry 5:

Far Cry 2 came out in 2008 and ran on a Playstation 3, Far Cry 5 came out ten years later on the Playstation 4, a much more powerful machine that was much easier to program. There is no good reason why so many things should be worse in Far Cry 5. The only reason is that these are details, and details tend to break and this is what it looks like when that has gone on for ten years. Far Cry 2 was a great game (yes, there is one big complaint that everyone has, but ignoring that it was a great game) and Far Cry 5 is just meh. Many developers over the years thought that details like this weren’t that important to keep working, and as a result you get a much worse game.

And it’s not just game development. Condition variables had been broken in glibc since 2016 and I have been trying to get them fixed by submitting patches since 2020 and haven’t had much luck until I finally got through in 2025. They mostly worked and only broke occasionally, so people just didn’t prioritize it.

But if you actually want to ship good software, you have to do like the “mundanity of excellence” quote says and lock in those improvements. Good software is a collection of small wins, and unfortunately small wins are the first thing to erode away if you don’t lock them in.

Automated tests obviously help for this and are a necessity past a certain level of complexity. But they can’t catch everything and when something slips through, you just have to fix it first.

Excuses

Whenever you push for better practices, you get the same excuses. There is no time, we don’t have the manpower, we’re already behind and this feature was supposed to be released two weeks ago. These are all very real reasons why people are not doing things, and if you dismiss these complaints they get very mad at you because they really have these issues. It’s just that from the outside, it’s clear to see that they’re stuck in a capability trap. The reason why you have no time is that you have bad practices. If you think you need more manpower to have more tests, you’re doing it wrong. The tests would allow you to ship the same software with fewer people, not with more people. Unfortunately this is not true in the short term, (when adopting new practices, things get worse before they get better) so switching is hard.

The article to read on this topic is “Nobody Ever Gets Credit for Fixing Problems that Never Happened: Creating and Sustaining Process Improvement“.

Quotes

To back up that you should fix things early and lock in a high quality early, I’ll quote from highly successful game developers. Here is Blizzard:

There’s this idea out there, that the reason why Blizzard polish is better is because we get six months at the end. And obviously we’re very fortunate to get more time, but the polish doesn’t happen at the end. The polish happens all along the way, from the very beginning. […] If you just leave it to the end, you’re not going to get there.

From the GDC talk “Making a Standard (and Trying to Stick to it!): Blizzard Design Philosophies” by Rob Pardo: https://www.youtube.com/watch?v=FhC0NaB6ock at 53:30

Here are several quotes about id software:

“Polish as you go. Don’t depend on polish happening later. Always maintain constantly shippable code.”

“It’s incredibly important that your game can always be run by your team. Bulletproof your engine by providing defaults upon load failure.”

“We are our own best testing team and should never allow anyone else to experience bugs or see the game crash. Don’t waste others’ time. Test thoroughly before checking in your code. No throwing it over the fence for testers to find and put a bug in the database and then fix it later. It’s a wasteful cycle.”

“As soon as you see a bug, you fix it. Do not continue on. If you don’t fix your bugs your new code will be built on a buggy codebase and ensure an unstable foundation.”

From the GDC Europe talk “The Early Days of id Software” https://www.youtube.com/watch?v=E2MIpi8pIvY

Summary

So why should bugfixes take priority? Let me slightly modify the quote from the beginning:

Superlative software is really a confluence of hundreds of small polishes or features, each one designed or stumbled upon, which have been carefully locked in by tests and then are fitted together in a synthesized whole. There is nothing extraordinary or super-human in any one of those features; only the fact that they are done consistently and correctly, and all together, produce excellence.

AI will worsen our estimates of GDP

This week’s post is co-authored by Amelia Michael, research fellow at the Center for Technology and Statecraft and non-resident fellow at the Foundation for American Innovation, and Karthik Tadepalli, research fellow at GovAI.

GDP estimates inform how the Fed sets interest rates, how the government determines fiscal policy, and the movement of bond and equity markets, among other things. These outputs that GDP feeds into—monetary policy, fiscal policy, and capital markets—rely on accurate aggregate GDP numbers, as well as accurate sectoral decompositions.

Moreover, future GDP growth has become a common yardstick for the transformative potential of AI. Anthropic’s recent economic scenarios argue that by 2030, US GDP could be up to 33% higher than it would be without AI. The Forecasting Research Institute surveyed economists and superforecasters about their estimates of future GDP growth as a way to forecast the economic impact of AI. Interpreting future GDP growth as evidence about AI’s impact requires confidence that those numbers will be accurate.

But AI could make GDP measurement less accurate. Much has been written about this issue, like the viral Citrini Research notion of “ghost GDP” or SemiAnalysis’s “dark output”. However, most writing on this topic doesn’t identify why AI will make GDP measurement hard: the reason AI will make GDP estimation difficult is because it’s hard to measure quality, which will lead to bad inflation estimates. As a result, AI will not affect the accuracy of nominal GDP estimates, but it will likely make real GDP estimates too conservative.

Context

The purpose of GDP measurement is to estimate how much stuff households consume, which we can then track over time. Unfortunately, “stuff” is not in comparable units; you can’t add a chair and a computer together, or say whether five chairs is more or less stuff than 2 computers. Instead, we estimate spending in each sector of the economy. For example, if $100 were spent on widgets in 2024 and $110 were spent on widgets in 2025, we’d estimate that widget consumption increased by 10%.

But that only works if the price of widgets stays constant. If the price of a widget increased by 10% from 2024 to 2025, that actually means widget consumption stayed the same. This is why we have to adjust for inflation to convert nominal GDP (which is just raw spending) to real GDP (which attempts to isolate the actual amount of stuff consumed).

Statistical agencies are meticulous about measuring prices. Each month, BLS collects prices for about 80,000 goods and services to construct indexes for 211 item categories in the CPI, which BEA then maps onto roughly 244 detailed PCE categories, each with its own deflator. All of this is specified in the 500-page NIPA handbook. In short, a massive amount of work goes into estimating prices. Alas, estimating changes in prices is not enough to accurately track inflation, because you also need to estimate changes in quality.

People think of inflation as “prices going up.” But this isn’t quite right. In 2000, a Nokia phone cost around $150. Today, the latest iPhone costs $1,000. But it wouldn’t be reasonable to say that a phone today costs 600% more than a phone in 2000. Phones today have internet access, high-resolution cameras, GPS navigation, video calling, and much more. Plus, $150 today will buy you a Xiaomi Redmi 14C, which still has all of those advantages. By any reasonable standard, phones have far better value-for-money today than in 2000, so it would be wrong to say that there has been large inflation in the phone market. This pattern – prices increase, but quality also increases – means that statistical agencies have to adjust for the quality of new goods when calculating inflation.

Adjusting for quality is especially difficult when new features or new types of goods are introduced. We can think about quality measurement challenges as spanning a spectrum from gradual quality improvements to new goods. For example, cars could see a pure quality improvement (e.g. higher fuel efficiency), or a totally new product (e.g. self-driving cars), or a new feature that straddles the line (e.g. GPS navigation). In all cases, the new car is better than the old car in a way that needs to be accounted for.

Statistical agencies understand the importance of quality adjustment. Unfortunately, quality adjustment is hard, and by default, they don’t actually do it. The default approach to estimating inflation is the matched model comparison: BLS checks the price of the same item each month, and if that item stops being sold, a data collector picks the closest available replacement. If the replacement is considered essentially comparable, any price difference between it and its predecessor gets counted as pure inflation. In other words, quality doesn’t factor into the default method.

When statistical agencies do try to adjust for quality, the main methods rely on reducing goods to a list of measurable features. Hedonic quality adjustment involves putting a monetary value on each feature that a product can have, and subtracting the monetary value of a new product’s features from the observed price change. For smartphones, for example, the model prices features like screen resolution, processor speed, and cameras. So if a replacement phone has a faster processor, the estimated value of the extra speed is subtracted from the new phone’s price, before computing the price increase. Or see, for example, how BLS quality-adjusts men’s underwear using a 19-parameter regression on brand, style, fiber content, and multipack quantity.

New products, meanwhile, are only accounted for when BLS rotates its samples or updates the basket, which happens with a lag – sometimes a long one. Cell phones were not classified separately in the CPI until 15 years after their introduction. This led BEA to underestimate real GDP growth, since cell phones were more expensive than landlines, but their quality gains were not accounted for.

AI could make quality mismeasurement worse

Quality mismeasurement is not a new problem, but AI could make it much worse.

First, AI’s quality increases are concentrated in services. Quality adjustment is hard enough for goods with defined characteristics, like cell phones and cars. But it is even harder for services, where there’s usually no identifiable quality that you can measure improvements along. There is no equivalent of “fuel efficiency” or “processor speed” that you can measure for legal services or therapy.

Most service price indexes therefore rely on the “matched-model” method discussed above, meaning the BLS just tracks what providers charge. AI might reduce the cost of services that have normally been tied to the hourly wages of white-collar workers – like accounting services, legal advice, therapy, career coaching, etc. – to close to zero, while also improving quality. If AI simultaneously reduces the price of a service and changes its quality, the agencies have no machinery for decomposing the two. Services are roughly two-thirds of consumer spending, so this could lead to significant errors.

Second, AI might lead to sector attribution errors. BEA maintains a detailed mapping from total spending to different sectors, creating a “deflator” for each sector – i.e. the price index that is used to deflate nominal GDP into real GDP. This system can capture price and quality changes within a category, but it is not designed to compare the emergence of substitutes in different categories.

If a household uses a general-purpose AI subscription instead of hiring a lawyer, BEA will record less spending on professional services and more on software or digital services. But neither the professional services deflator nor the software/digital services deflator directly compares the price of the human service with the AI-enabled substitute. If the AI delivers the same or better result at a lower cost, that gain will only show up as a change in the composition of spending, instead of as a decline in the quality-adjusted price of accomplishing the underlying task. This could lead to overestimating inflation and underestimating real output.

Finally, AI could shift spending toward more error-prone sectors (services). Even if AI doesn’t increase measurement error in any sector, it could lead people to spend a larger share of their income on (poorly-measured) services rather than (well-measured) goods. This shift in expenditure weights would raise aggregate measurement error in the aggregate.

This argument has been pretty abstract so far. So let’s take a couple of examples of specific cases where AI’s contribution to GDP might be difficult to measure, or easily miscounted under the current system.

Education

Government outputs, like public K-12 education, are measured differently from most of the economy. Because there aren’t consumers paying market prices for the good, there’s no price or quantity of output to observe. Instead, the statistical agencies define government “production” as the cost of the inputs – mostly employee compensation – and compute real output by deflating each input with its own price index. Real government output, in other words, just tracks real government inputs. This builds in an assumption of zero productivity growth: by construction, the government can never produce more education per teacher-hour, since all that they’re measuring is teacher-hours.

This could lead to education quality measurement becoming way worse with AI. Imagine more public schools follow the precedent set by schools like Alpha School and use AI-guided lessons for the majority of instruction. This could cut down on the number of teacher hours, by requiring students to be in school for fewer hours a day and reducing the number of instructors you need per student. It could also increase the quality of education, since AI-guided lessons allow for better tailoring to each student. This would improve the production of high-quality education while allowing the government to spend less on inputs. But because measured output is inputs, GDP would record this as a decline in the production of education. A large productivity improvement would show up in the national accounts as lower GDP.

Conversely, AI could reduce student learning per teacher-hour if, for example, it made it easier for students to cheat on assessments without learning. Either way, this example shows how accounting for quality changes in education could dramatically change our estimates of how much education we are actually getting per dollar spent.

Tax preparation

Tax preparation by an accountant costs a few hundred dollars. By contrast, an AI that prepares tax returns costs a few dollars worth of tokens, and it might do the job better (if, say, it makes fewer errors than the average accountant, or can access a broader database of eligible deductions).

The CPI estimates the cost of tax return preparation using the matched-model approach, meaning it tracks what accountants charge without attempting any quality adjustment. In this scenario, where lots of people switch to AI accountants, accountants’ posted prices won’t fall just because AI exists (if anything, they might rise, if, say, the remaining clients are more complicated or the remaining accountants offer fancier services). In this case, the effective price of preparing a tax return falls significantly – but the index for tax preparation would record no price decrease, and could even show a price increase. Instead, the money that is now being spent on an AI subscription will get counted in a software or internet services category, whose price index is not designed to reflect that the product is replacing a human accountant.

As a result, we never record the price decline for accounting services – so inflation will be overestimated, and real GDP growth will be underestimated.

This logic is not unique to tax preparation – it applies to any other professional service that people will use AI for, like legal consultations, medical advice, or home improvement advice.

Other concerns about AI and GDP measurement are less relevant

Other people have written about difficulties with measuring AI’s contribution to GDP. However, we think most of the relevant ways in which AI could make GDP difficult to measure are in fact inflation adjustment difficulties, and non-inflation concerns are largely insignificant. For example:

• Moving work inside a firm: Some analyses have claimed that moving a task inside a firm causes its value to disappear from GDP. To avoid double counting intermediate goods, GDP subtracts out intermediate inputs by measuring value-add (final value minus intermediate inputs). In the version where the HR service is in-housed due to AI, $10,000 is no longer subtracted out of the firm’s value-add, and $10,000 is no longer added in for the HR firm’s value-add. The net effect on GDP is zero.
• Sector misattribution: This is an actual issue – as we discuss above, AI activity might get recorded in different sectors from the service it’s providing. However, this is not an issue for total nominal GDP. The error only comes in when trying to calculate real GDP, because it deflates nominal GDP by the wrong sector’s price index.
• Declining cost of services leading to “dark output”: The cost of certain services has fallen dramatically due to AI. Some analyses have claimed that this means that those outputs will effectively no longer be counted in GDP. This is only true if you have inaccurate deflators! In theory, an accurate deflator should capture the declining cost of producing the service, and deflate nominal output accordingly.
• New AI-generated work not being captured: A good inflation measure would record the huge decline in the quality-adjusted price of producing AI-enabled work. As people produced more of this work, dividing their spending by that lower price index would show a correspondingly large increase in real output.
• “Ghost GDP”: Citrini Research’s article describes a scenario where AI-generated output continues to appear in GDP but “never circulates through the real economy,” because wages go down and spending declines. The accounting on this doesn’t make sense: every dollar of measured GDP corresponds to a dollar of income earned. If AI reduces compensation while increasing corporate profits, income has just shifted from labor to capital, but it’s still being counted.
• Failure to count fabless chipmakers: Unlike most issues we have talked about, this is a problem with measuring nominal GDP rather than real GDP. This is a live and complex issue, but it is only incidentally related to AI because of semiconductors’ role in the AI supply chain.

What do we do about it?

While AI might make the inflation-measurement problem especially bad, it largely does so in familiar ways. This means that incremental improvements to existing methodologies of the statistical agencies would go a long way towards addressing this problem. Some examples:

• Measure government output directly, like the UK does. After a 2005 review, the UK’s Office for National Statistics moved from measuring government inputs to measuring outputs directly.
• Speed up sample rotation and substitution. Starting in 2018, BLS began updating the estimates for smartphone quality twice a year because of how frequently quality improvements came out. Extending this precedent to more AI-affected categories would shrink the lag through which quality change makes its way into measured inflation.
• Use alternative data. BLS has been moving categories from field-collected prices to web-scraped and scanner data with hedonic models re-estimated every month. Scraped data makes it feasible to track quality characteristics at scale, which would be useful for keeping track of fast-changing AI products.

That being said, there are probably some ways in which AI causes novel problems that old proposals don’t address. Sector attribution is probably the most significant: no amount of improving the deflator within each category helps if spending is migrating across categories. The following are two tentative ideas for addressing some of the AI specific issues.

First, create a separate category for AI. A separate AI-services category would make it clear what share of production is attributable to AI (as opposed to other software categories). More importantly, it would also give AI its own expenditure weight and price index.

Second, make task-based price indexes. A more direct way to address sector-attribution errors would be to organize supplementary price indexes around the task being completed rather than the product being purchased. A tax-preparation index, for example, could treat an accountant, conventional tax software, and an AI subscription as alternative ways of producing the same output. If consumers switched from a $300 accountant to a $20 AI service, the index could record a decline in the price of preparing a tax return, even though the spending had moved from professional services into software.

BEA could initially publish these indexes in a “satellite account”: a set of supplemental statistics that experiments with a different way of organizing economic activity without immediately changing headline GDP. A satellite account could eventually feed into the main statistics. Declines in the cost of completing AI-exposed tasks would then show up as lower inflation and higher real output in the official accounts.

When Xbox announced sweeping layoffs in July as part of a brutal “reset” for the gaming brand, Xbox CEO Asha Sharma said part of the pre-existing problem in the gaming unit was “teams, studios, and functions [that] often operate independently, [making it] harder to work toward a shared goal.” Today, the company announced a radical restructuring of its internal studios that is seemingly designed to reduce that “independence” for the teams behind some of gaming’s biggest franchises.

The biggest apparent change is for the Halo franchise, which will now be under the remit of Call of Duty maker Activision. Halo Studios (formerly 343 Industries), which recently released Halo: Campaign Evolved, will remain as just a “small team” to support the player community, Microsoft said, with the remaining staffing roles eliminated as part of 268 newly announced layoffs.

“For Halo, our goal is clear: make the greatest Halo game ever, worthy of its universe and legacy, while staying true to what made players love it in the first place,” Activision President Rob Kostich said in a statement provided to Kotaku. “It is a bold ambition, one that this franchise deserves. We have already begun assembling a purpose-built team, unique in capability and talent, ready and excited to deliver this next chapter with the community.”

Activision, which Microsoft officially purchased just under three years ago, will now also take control of venerable studio Rare (Sea of Thieves) and the Age of Empires stewards at World’s Edge.

In the world of more RPG-infused Xbox games, Obsidian—the studio behind games like Fallout: New Vegas, Avowed, and The Outer Worlds—will now become part of Bethesda. There, the team will continue work on a new Grounded game and a “new Fallout project made in collaboration with Bethesda Game Studios,” Microsoft announced.

Elsewhere in the company, Microsoft Casual Games (which still publishes former Windows pack-ins like Solitaire and Minesweeper) will now report to Candy Crush studio King. Playground Games (Fable, Forza Horizon) and Turn 10 (Forza Motorsport) are also being merged into a single team.

Xbox said it is continuing to look for a buyer to obtain Ninja Theory (Hellblade: Senua’s Sacrifice) and Arkane Studios (Dishonored, Prey). Microsoft has already divested itself of Compulsion (We Happy Few), Undead Labs (State of Decay), and Double Fine (Psychonauts, Kiln), the last of which bought itself to become the independent studio it was before the 2019 Xbox acquisition.

Streaming those lines, lining those streams

Microsoft says these dramatic internal moves are an attempt to “strengthen our franchises and games by operating fewer business units, aligning groups that already work closely together, and focusing our publishing expertise.” Consolidating development teams like this will also likely help Microsoft in its stated goal of reducing the layers of management that have beset the bloated company—today’s fresh layoffs also include some employees from the “XGS management and central functions layer.”

In July, Sharma said that some work at the company “passes through as many as 14 layers of management” resulting in “slowed decisions [and] blurred accountability,” making it “harder to deliver for players.” Sharma also said at the time that Xbox would be “shifting investment to focus on higher priority projects” as the restructuring goes forward.

As of today, the company says it is “roughly three-quarters of the way” through the planned 3,200 layoffs it announced earlier this summer.

Foldable devices require apps to adapt to changing screen sizes, orientations, and postures with responsive layouts, multi-pane interfaces, and hinge-aware designs that preserve context and usability instead of simply stretching existing mobile UIs. By designing around available space rather than specific devices, teams can create experiences that work consistently across phones, foldables, tablets, and desktop-sized windows while following platform-specific layout conventions.

Decision paralysis, lost conviction and no juniors: what brand creative leaders say AI is exposing

A new report by MikeTeevee asks in-house leaders at some of the world's biggest brands what AI is doing to their own teams, and their feedback unearths problems that were brewing long before the tools arrived.

One of the best things about my job is being able to chat with creatives from every corner of the industry, gaining a unique insight into what's happening and how things might be changing. It helps me shape what we write about on Creative Boom and ensure we're being helpful, fulfilling our original mission: to support and inspire the creative industry.

I'll often spot patterns, too. Things keep coming up in conversation, like AI lowering the floor and raising the ceiling at the same time. These days, anyone can make something, and the best people can make something better. That's a common theme.

But James Hurst isn't convinced. The executive creative director for HelloFresh and its 12 brands, he believes AI has lowered everything. "Lots of what's being produced en masse today feels much less interesting," he says.

He's just one of the in-house creative and marketing leaders interviewed for Brand Perspectives 2026, a new report from creative production partner MikeTeevee, with perspectives from Wayfair, DoorDash, Intuit, O2, Verizon, Canva, and Rivian. It concludes that the "samey" work, the disappearing junior roles, and the wobble in creative confidence were issues long before AI turned up. The new technology has only sped them up and made them more obvious.

The creative industry has always been spoilt for choice, in that it's made far more than it ships. For every campaign or launch out there, there are always 20 good ideas that got binned. The report argues this is how we worked well: generate loads, filter hard, and then back one idea with conviction. The interesting question now is, what happens when generating costs next to nothing?

"Some teams are suffering from real decision paralysis," says James. "Because they can now create an almost infinite number of variations at almost zero cost and in zero time."

Mike Pearson, head of creative and promotions at Wayfair, adds: "Previously, you would never say to an art director, 'give me thirty 30-second ads rather than one, with a minor degree of difference between them'." Now you can, and people do. That's all good and well for the creative process and idea generation, but Pearson is more worried about what comes out the other end. "In a world where everyone can create more with the same tools – and often with the same inputs – how do you stop everything looking the same?"

Hurst worries the damage goes beyond samey work, to the creative work itself. "I see creatives who have forgotten how to have conviction in their own thinking," he says. "They'll run a double diamond design process and have a thousand people voting on their idea, but when asked about the outcome will say 'it's not the route I would have chosen'. Isn't it a shame to have created a prison for your own idea?"

Just adding my own observations here: it seems a lot of creative teams have had fun experimenting and playing with AI, but now there's a rollback for all the above reasons, along with a reminder that human creativity and original thinking produce work with more value than any machine could produce.

I digress. The other big question is whose opinion counts. "Now that anybody can create anything, you end up in this weird conversation where you've got two people who have diametrically opposing views of what's just happened," Hurst continues. "The person with the expertise is saying the thing that's been created isn't good, while the person who's not got the experience thinks it's fantastic because they've never been able to create something like that before."

Oh lord. I've sat in a few meetings during my time, and this scenario makes me wince. Hurst is balanced about it, though. "I think inviting more people into the conversation to create is fantastic. I couldn't be happier about that. But I want to make sure that we're also raising the ceiling by galvanising higher creative standards for the work that's being produced as a result," he says.

OK, so the filter for what is and isn't good is the most immediate headache from MikeTeevee's report. What about the talent pipeline, as that's personally my biggest concern? It's an issue, but it's slow-moving. Companies are trimming junior roles because AI handles the output faster and cheaper, which is understandable when budgets are this tight. Jason McKean, ECD at Verizon, asks the thing we're all thinking: "If you can't start at the entry level to get to the mid-level because it's been eaten up by AI, where will we find mid-level talent once today's senior executives disappear?"

The report puts it the way I have for many months: the junior that isn't hired this year won't become the creative director a decade from now. It's a seriously big problem. "Rather than eliminate junior roles, we must ignite curiosity about AI and make it a craft-level must-have," says Darius Gross, head of marketing communications campaigns at O2. He sees the workforce splitting into three camps: the Innovators, who love trial and error; the Anxious, who fear for their jobs; and the Pragmatists, whose attitude is "we changed when the web arrived, we'll adapt again". To be honest, this has already happened. And I'd say I'm in the third camp.

Interestingly, some things never change. Chief creative officer Todd Miller, who has led teams through more than one industry shift, thinks "the most important quality when hiring someone – 25 years ago, today, tomorrow – is curiosity. Full stop."

And here's the even bigger reveal from the report. Something I'm feeling, too. Everything has sped up, and that's added insane pressure. "We're all saying AI is making us more efficient," says Thomas Ranese, chief marketing officer at Intuit, "but everyone's working twice as hard as they've ever worked."

It's not all straightforward, either. The tools have moved on, the admin hasn't. Ted Markovic, global head of advertising and creative operations at Canva, says he's wrestling with admin. "I don't understand how it's 2026 and I'm still using a spreadsheet to place media in a handoff sheet to the media agency," he says. "It drives me crazy."

It's honestly the Wild West. Oftentimes, it can feel as though you're in first gear with the handbrake on. Sometimes, it's just that those around us haven't caught up. Markovic thinks it's a "change management" problem. "Most people haven't been given the permission or the time to be able to integrate tools thoughtfully," he says.

It's not all doom and gloom. Just two years ago, Alissa Sheely's team at DoorDash tested ideas by putting a Google slide with a script in front of customers. Now they prototype super quickly and get real reactions to pacing and messaging. "We've seen a 20% improvement in the team's creative velocity thanks to reduced time spent on decks and other heavy lift tasks," says the head of brand and creative operations.

The pattern that keeps springing up in the report is that AI handles the boring chores – onboarding, asset trafficking, decks – and the time saved goes back into thinking. McKean keeps it in its place: "I use AI as a brainstorming partner. Not a problem solver."

"The leaders we spoke to are finding valuable uses for AI," says Ellen Utrecht, founder of MikeTeevee. "But they're also clear that speed and volume cannot replace taste, judgment or the confidence to make a choice."

So, let the tools handle the admin. Retain the thinking behind what makes the final work. If you hire, always protect juniors. And if you pitch to in-house teams, Hurst has some advice: "Instead of saying 'we've got the right answers for you', I'd rather have partners who can say 'we've got the right questions for you'."

I'll end on this from Christoph Krick, director of brand marketing at Lautsprecher Teufel, who has heard lots of people insist that change is coming for everyone else. "This is a big flaw," he says. "It's no bad thing to be a little bit afraid and remain attentive, because staying on your toes is really the best way to adapt."

After 44 hours of content, 48 speakers and more than 432,000 words shared at Brand Builders Summit 2026, I wanted to answer one question: What actually makes a brand builder irreplaceable?

So I analysed every keynote, panel, Q&A and workshop from the Summit. That is roughly five or six full length business books worth of ideas covering brand strategy, design, marketing, business, creativity, community and AI.

The speakers came from different disciplines, backgrounds and perspectives, but across all that content, the same themes kept surfacing. And they point to a significant shift in the branding industry.

AI is making production faster, cheaper and more accessible. Logos can be generated in seconds. Copy can be drafted instantly. Images, presentations, concepts, research summaries and marketing assets can be created at a scale that would have been difficult to imagine only a few years ago.

That does not make brand builders obsolete. But it does change where our value comes from.

The future does not belong to the person who can produce the most assets in the shortest amount of time. It belongs to the brand builder who can think clearly, exercise judgement, make better decisions and help people move forward.

Here are the eight lessons that stood out.

1. Make decisions, not just deliverables

For decades, much of the perceived value of creative professionals came from our ability to produce things other people could not. Logos, layouts, campaign concepts, presentations, illustrations, messaging and websites all required specialist skills and significant time.

Today, AI can help create all of them faster than ever. But generating an asset is not the same as knowing whether that asset should exist.

A logo can be beautifully executed and strategically wrong. A campaign can be clever without solving the business problem. A positioning statement can sound impressive while saying absolutely nothing distinctive.

This is where the value of the brand builder begins to move upstream, into brand strategy and the decisions that inform the creative work. Instead of simply asking, “What should I make?”, start asking: What should be created? Why does it need to exist? What problem are we solving? Which decision needs to be made? What outcome should this work create? How will we know if it worked?

There is a major difference between executing a brief and helping shape the thinking behind it. The latter is much harder to commoditise.

This is also why a strong brand strategy and design process starts well before visual exploration. Discovery, research and strategy create the criteria that the creative work should ultimately answer.

Before opening your design software or prompting an AI tool, ask: What does this brand actually need to achieve, and what is the right response?

2. Be different, not just better

AI is extremely good at producing plausible work. And that is exactly the problem.

Generative AI systems learn from enormous bodies of existing material. As a result, they are exceptionally capable of reproducing familiar patterns, styles and category conventions.

Ask for branding for a premium skincare company and you will probably see elegant serif typography, muted tones and minimalist packaging. Ask for a disruptive tech company and you may get gradients, geometric typography and futuristic imagery.

Everything can look competent. Everything can also start looking the same.

This makes differentiation more important, not less. Brand builders need to understand the conventions of a category and deliberately decide which ones to keep, reinterpret or reject.

As Sally Hogshead puts it: “Different is better than better.”

That does not mean being weird simply to attract attention. Difference needs to be relevant. It needs to mean something. The goal is to create a brand that is recognisable, memorable and difficult to compare directly with everyone else in the category.

That distinction between strategy and expression matters. A successful brand identity should not simply look good. It should express the positioning, personality and strategic choices behind the brand.

Ask: What could this brand own that competitors would struggle to claim?

3. Guide what happens next

There is a common failure point in branding projects. The strategy is approved. The identity is delivered. The guidelines are handed over. Everyone celebrates. Then the branding team disappears.

The client is left to translate all that strategic thinking into marketing, sales, culture, customer experience, content, product decisions and everyday behaviour. And that is often where a strong strategy slowly begins to fall apart.

During the Summit, Stephen Houraghan described the opportunity for brand professionals to become guardians of the brand. I think there is enormous opportunity here.

Instead of seeing delivery as the end of a project, help organisations work out what should happen next. Where should this strategy show up? Who needs to understand it? Which teams need to act on it? What needs to change internally? Which opportunities should be prioritised? What could prevent this strategy from being implemented?

Most importantly: What should we do next?

This moves the relationship beyond deliverables. You become an adviser, facilitator, strategic partner and, in some cases, an operator.

4. Build community, not just reach

AI can create an almost infinite amount of content. It cannot automatically create genuine belonging.

That distinction matters. An audience consumes. A community participates.

Several Summit speakers, including Marissa G., Chanel Clark and James Martin, demonstrated how generosity, participation and genuine connection can create opportunities that reach alone cannot. A large audience may create visibility, but community can create relationships, referrals, collaboration, trust and shared identity.

For years, the default online growth question has been: How can I reach more people?

A better question might be: How can I help the right people connect and contribute?

5. Develop a point of view

Producing more content will not make you irreplaceable. Developing a perspective that people recognise, remember and trust might.

AI can summarise thousands of existing opinions and generate perfectly acceptable commentary on almost any subject. What makes your perspective valuable is not simply access to information. It is what you believe after experiencing the work yourself.

Your judgement. Your convictions. Your failures. Your taste. The patterns you have noticed. The ideas you are willing to challenge.

In James Victore’s unmistakable spirit: “Get off the f*ing fence.”

Ask yourself: What does my industry regularly get wrong? What have I learned through experience that others might find useful? What am I willing to defend? Which commonly accepted ideas do I disagree with? What do I want to become known for?

6. Strengthen your judgement

When generating options becomes cheap, choosing between them becomes more valuable.

AI can create 100 logo concepts. Someone still needs to decide which one is right. It can generate 50 campaign headlines. Someone still needs to know which one actually expresses the strategy. It can create multiple positioning territories. Someone still needs to understand the customer, category, commercial context and organisation well enough to recommend one.

Your value does not come from rejecting AI. And attempting to compete with AI on production speed is probably a losing strategy. Your advantage comes from being able to direct the technology intelligently and recognise when the output is generic, strategically weak, inappropriate or simply wrong.

7. Build confidence through action

A surprising amount of creative careers can be spent waiting. Waiting until the portfolio is better. Waiting until you have more experience. Waiting until the website is finished. Waiting until you feel qualified. Waiting until you know enough. Waiting until you are confident.

The problem is that confidence rarely arrives first. It usually follows action.

You do the work. You solve a difficult problem. You present an idea. You receive feedback. You survive the uncomfortable conversation. You publish something. You raise your price. You lead the workshop.

Each experience creates evidence. And that evidence slowly changes what you believe you are capable of.

8. Turn knowledge into practice

There has never been more information available to creative professionals, and AI has accelerated that dramatically.

You can ask an AI tool to explain brand architecture, customer research, positioning, pricing strategy or practically any established framework within seconds. Information itself is no longer particularly scarce.

Application is.

The better question after consuming an idea is: What will I do differently because of this?

Where AI is moving the value of branding

The common thread through these eight lessons is not that AI will replace creative professionals. It is that AI changes which parts of creative work remain scarce.

Production is becoming abundant. Options are becoming abundant. Information is becoming abundant. Basic execution is becoming easier to access.

That means the more defensible value increasingly sits elsewhere: in judgement, strategic context, taste, decision making, leadership, relationships, facilitation, responsibility and knowing which problem deserves solving in the first place.

The opportunity for designers, strategists, marketers and creative entrepreneurs is to move closer to the decisions that shape the organisation.

Help clients understand what matters. Create meaningful differentiation. Guide implementation. Build relationships and communities. Develop a recognisable point of view. Strengthen your judgement. Turn knowledge into action.

The short version

After analysing more than 432,000 words from 48 Brand Builders Summit speakers, I keep coming back to three capabilities:

THINK clearly. Make better DECISIONS. Help people MOVE FORWARD.

AI will continue getting better. Production will continue getting faster. The tools will change.

Those three capabilities will remain extraordinarily useful.

And they are worth strengthening whether AI is involved or not.

Markdown in /src

TLDR

• Markdown is becoming source code, not documentation
• That Markdown should be checked in to /src, next to the code it produces
• Code and tests should be derived from that Markdown, rather than from ephemeral prompts (or at least prompt sessions should eventually turn into persisted Markdown)

Intro

In order to supplement my income as a professor at Montana State University, I do consulting on the side. I enjoy consulting and the act of writing code & helping build systems, both for their own sake and also because it keeps my skills relevant and allows me to teach students about the latest ideas in software development.

Obviously the biggest thing to happen in development in the last few years is agentic coding: using LLMs to generate code in lieu of hand coding. I have written a few essays on this topic:

• Yes, and…
• Code is Cheap(er)
• The University In The AI Era
• Working With AI: A Concrete Example

In this essay I want to discuss an idea that is becoming increasingly clear to me as I work in companies that are prioritizing agentic coding:

Markdown is now source code, not documentation.

This is not a novel or particularly clever idea, of course.

In Markdown is the new source code, Hartley Brody writes:

It is starting to feel as if the application logic of the software is being defined and edited as markdown, and the actual code that is generated by the agent is sort of becoming a low-level implementation detail.

Now, as the essays above show, I am ambivalent about AI-generated code. However, my consulting work shows that organizations are headed in this direction, often at terrific speed.

What I want to do in the remainder of this essay is think about the ramifications of Markdown becoming, more and more, the source of truth for software systems.

The Missing Source Code

There is a line of thinking, captured in the quote above, that LLMs are akin to compilers, taking high-level specifications and turning them into low-level implementations. In this view, we don’t need to look at the code an LLM generates, just as we don’t look at the machine code a compiler generates.

As I mention in Code is Cheap(er), I do not totally agree with this analogy for a few reasons, but the one relevant to this essay is: compiler workflows retain their original source code while LLM workflows typically do not.

Today, LLM-generated code is often created via a string of prompts fed into an agent as a developer builds out a feature. In practice, this means that the generated code is the closest thing we have to “ground truth” for that feature. There may be documentation for the feature stored elsewhere (e.g. Linear, Slack threads, wikis, etc.) but, so far as the codebase is concerned, the generated code is the source of truth.

My opinion is that, in professional agentic coding environments, we need to accept that LLM-generated code that emerges from ephemeral prompting sessions is not ideal, and begin moving towards capturing and checking in Markdown alongside generated code in the source directory.

Markdown As Source

Markdown has many nice properties that make it similar to traditional source code:

• It is plain text and therefore diffable, greppable and reviewable in pull requests
• LLMs read and write it natively
• Humans can read and edit it without tools

And, in fact, it is already acting as source, to an extent, in AGENTS.md, specs, plans, TASK.md and so forth. We just haven’t standardized capturing that source yet.

In Markdown is the new source code, Brody says he keeps his Markdown files in .scratch/research/ and .scratch/plan/ as he works. I have adopted the convention of creating a /tmp directory for similar ephemeral needs.

My proposal is that we promote some of these files to a new directory, alongside our existing source code: /src/md

The Markdown captured in this proposed directory would be lower level than traditional design documents:

• It contains architectural decisions
• It contains source-level decisions
• It contains low-level data design decisions

It is much closer to a specification (although it is not one) than a design document as traditionally managed by a project manager or designer.

Locality

I am a fan of locality, and I think that moving Markdown into /src has strong locality advantages:

• Code modules would now include the Markdown that explains the intent of the code
• There is no spooky “specification at a distance”, where the logic of why is elsewhere in a wiki/Notion/Confluence/Jira
• Markdown in /src can be consumed by both humans and agents
• Agents no longer need to look elsewhere to get context on a given codebase

What About Linear/Wikis/etc.?

Other sources of truth for the behavior of the system can still exist. These sources would provide higher-level and/or “process-oriented” documentation: high-level design documents, issues that need a resolution workflow and so forth.

But the core, current and static intended behavior of the system would increasingly be captured directly in Markdown in the source directory.

What About Tests?

I have seen many people online saying that tests are the new specification (or always were). I think there is some truth to that.

However, tests are not a good mechanism for human/agent interaction:

• They involve a lot of ceremony, often obscuring what they are testing
• They are typically lower level than most humans want to deal with, particularly when understanding a system
• Higher-level explanations such as Mermaid diagrams don’t fit naturally into them

I think the following division of labor makes sense:

• Markdown sits in /src and is the specification(ish)
• Tests sit in /test (or wherever) and are based on that Markdown, providing automated confirmation of correctness

Again, the core idea here is that, rather than generating code and tests from prompts, a developer would work on Markdown in the /src directory, from which the code and tests would be derived.

What /src/md Markdown Looks Like

The Markdown in /src/md sits between a formal specification for the system and high-level design documents.

As with source code, there is a Complexity Budget associated with this Markdown. It will require thoughtful management to keep these documents clean, well-factored and at the right level of abstraction.

Developers should be expected to interact with both the Markdown and the derived code, so synchronizing the two (when appropriate) will become an important skill.

For example, developers will often do subtractive, constraining work on generated code, and those changes may need to be moved back into the Markdown.

I believe that agents should not be used to generate much content in /src/md. This directory should be mainly human authored and curated.

A Proposed /src/md Convention

This is necessarily the weakest part of this essay because this is a new idea and I haven’t used it extensively yet. It is me thinking out loud and inviting discussion.

With that said, here is a possible /src/md standard:

src/
  md/
    README.md          # index of all md, entry point for agents
    TODO.md            # a list of general TODOs open for this module
    OVERVIEW.md        # a technical overview of this module
    features/FEATURE_1.md       # a set of feature-specific documents
    data/DATAMODEL_1.md         # descriptions of data models in the module
    api/API_1.md                # descriptions of APIs the module provides
    infrastructure/INFRASTRUCTURE_1.md   # descriptions of infrastructure used by the module

Here the features, data, api and infrastructure directories are all optional; the idea is to divide along different axes to best capture a solid working description of the module’s behavior directly in the /src/md folder.

Conclusion

As code gets cheaper to generate, what remains valuable is the intent behind the code: what it does, why it does it, and what it must not do.

Today that intent is often lost in ephemeral prompting sessions, or scattered across wikis, tickets and Slack threads.

I think that, in the name of locality, we should consider capturing this intent in Markdown and checking it in to /src, alongside the code it produces, where both humans and agents can find it.

I don’t know exactly what the right structure for something like /src/md is yet, and I expect my thinking will change as I (and others) get more experience with it.

But I am fairly confident that Markdown is becoming source code, and that we should increasingly treat it like source code.

(Even though, no, LLMs are not compilers :)

In the past month alone I’ve heard these phrases:

• I haven’t written code since 2025;
• Code reviews are dead;
• People no longer read code.

Certainly the industry is transforming, however, the people and organizations falling into the trap of no longer reading and writing code only do so at their peril.

Fact is, vibe-coded projects devolve over time into an unmaintainable mess. The reason is simple, yet hard to fix: code maintainability and good architecture don’t have good measurements that we can apply, because it takes months, years even, to notice the effects of bad architecture or of unmaintainable code.

We can certainly define bad code: code that’s hard to read, hard to understand, hard to evolve for whatever the future throws our way. The kind of code in which changing one thing breaks the program in very non-deterministic ways, or breaks the logic somewhere else, far removed from your change, resembling the “butterfly effect”. The kind of code where adding a feature means a serious undertaking due to changing code in multiple places and still forgetting to patch everything, thus getting inconsistencies. Code in which the invariants of the design aren’t clear, with its authors no longer being around to guard against violations and ensure some coherence. Code that is hard to test, requiring mocks and exposing implementation details, leading to fragile tests that end up preventing meaningful refactoring.

And yet, we know it as a fact that noticing bad code takes time. Months, years. Of course, the experienced software engineers have a nose that can detect code smells and can take action long before the bad effects can be observed.

The proficient developers, the experts, rely on their intuition built with sweat and tears, working long hours trying to debug and fix production issues, swearing to never again be so foolish as to repeat past mistakes. It’s the kind of intuition that can’t really be made into a list of rigid rules, because everything is context-dependent. Experts are incompatible with the same rules and recipes that make beginners more productive. Experts don’t follow the rules, they make the rules.

And so we have a problem…

For one, AI is not trained on what it means for code to be maintainable. For instance, any reinforcement learning done needs a reward signal that can be measured immediately, not in months or years. The AI learns rules from rulebooks meant for beginners. The AI notices patterns from code in the wild and let’s be honest, most code in the wild is pretty bad. There is no fitness function you can define for maintainable code, at least not one that we can discern, otherwise it would’ve been baked into our linters.

Have you noticed how terrible is the AI at “simplifying” code? Yes, the SOTA models. It can’t even define functions properly, choosing to split functions into smaller functions that are not actually reusable. Extracting a smaller function from a bigger function is a very bad choice if, to understand the bigger function, you have to also read the implementation of the extracted smaller function. Defining reusable and clarifying functions is an art form, an art that takes mastery. Most developers, being still “advanced beginners” in the Dreyfus model, are not able to define good, clarifying, reusable functions and neither does the AI currently.

This wouldn’t be so bad if people would still be in control and learn from those mistakes. But we are seeing a trend of people relying on AI to write, and even read code.

Those people will never reach mastery, because they no longer make choices, they no longer take responsibility for mistakes in coding and no longer learn from those mistakes. It’s the AI that’s making mistakes now, the AI doesn’t learn from those mistakes, and neither are the people relying on AI for coding.

Yikes!

Don’t get me wrong, I think LLMs are a great tool. I’m no Luddite, I’ve integrated AI in my everyday work, while actually teaching my colleagues what I’ve learned. I gladly use LLMs to take care of all the boring, soul-sucking shit we have to deal with. I’m also enjoying the efficiency benefits that I’m seeing. But at the end of the day, it’s just a tool, and like all other revolutions, its light will also fade; IMO, it already is, as right now tech news is frankly quite boring.

People are actually terrible at making predictions. I believe the future will surprise all of us. But, I’m going to make a prediction of my own…

In the future we will see more and more companies proudly boasting their “NO-AI” policy as a competitive advantage. And they will be right.

“But automated assembly lines are always more efficient” people say, except that the software industry is special, because we’ve always done automation at scale, everything we do is automation, LLMs are not the only means for it, and depending on context, it may actually be a distraction. “Coding isn’t solved” in any meaningful sense. Sure, you can instruct the LLM to build you a C/C++ compiler, or you can just clone GCC or LLVM, and you’d get a better C/C++ compiler, for free, too. And maybe there are better ways to spend our time and resources than reinvent the same CRUD apps (human needs and desires are infinite, there’s no shortage of new goals to work on).

If people and companies don’t start being responsible about its use, there will be consequences.

Personal AI may ultimately compete on two moats: trust and task completion. Vinod Khosla says users will stay loyal to companies they trust with sensitive data and products that reliably finish work, while Meta faces a trust disadvantage.

If you don't go overseas, all that grinding was for nothing.

There are currently hundreds of clinical trials worldwide investigating possible medicines, new diagnostic options, and lifestyle interventions to identify, treat, or delay cognitive decline. The possibility of a cure is still far away, but it now seems more possible than ever before. Alzheimer's disease is being increasingly viewed as a condition for which earlier diagnosis, better understanding of disease biology, and a wider range of interventions may collectively improve outcomes. There is now a genuine case for optimism.

To have a positive career, you need to be appropriately recognized and rewarded for your work. Take public credit in a way that isn't obnoxious or wasteful. Don't let anyone lie about you, and beware of people who think you got lucky. Maintain leverage at all times - leverage mainly comes from your ability to walk a valuable asset (your labor) out the door.

Those living closest to the Amazon flight paths are hearing constant noise from the drones.

McLaren has unveiled a refined brand identity that modernizes its wordmark while drawing inspiration from the signage of the McLaren family's original service station, balancing heritage with a more contemporary look. The redesign also retains the iconic Speedmark for its racing and golf divisions, reinforcing brand continuity while signaling a new chapter for the company.

Apple has quietly introduced a bold new Apple Music wordmark alongside the launch of Apple Music Hall in London, replacing its minimalist branding with a retro-inspired, lowercase logo that signals a shift toward a more expressive visual identity. The redesign reflects Apple's growing embrace of bolder, more playful aesthetics and could hint at the direction of its future design language.

Browse, search, and filter beautiful color palettes inspired by the Old Masters.

Create precise, harmonious typography with Precise Type. Explore type scales, font sizes, line heights, and letter spacing – then export the CSS.

Free browser-based image effects editor with 75+ effects. Turn photos into dither, halftone, ASCII art, pixel art, and voxel graphics.

Research suggests that creative work delivers the strongest business results not through originality alone, but through elaboration—the careful refinement and execution that turn a good idea into a polished, effective campaign. As AI makes generating novel ideas easier, human value increasingly lies in the thousands of design decisions, craftsmanship, and attention to detail that set exceptional work apart from merely original work.

Illustrator Jenna Arts celebrates imperfection and everyday humanity, arguing that the authenticity, personality, and flaws of human-made art are what make it meaningful in an AI-driven world.

Sun Microsystems paired strong technology and strategy with weak operational execution, including basic failures in sales and customer responsiveness. A 2005 startup running OpenSolaris tried to buy Sun hardware but struggled to get a response, while Dell quickly handled pricing, financing, and delivery—an example of how neglecting the mechanics of running the business can erase technical advantages.

Forrester named Google a Leader in its External Threat Intelligence Service Providers Wave for Q3 2026, citing perfect scores across nine criteria and autonomous Gemini-powered agents for triage, detection engineering, and threat hunting that customers say surface 139 percent more threats.