Full article content is not available for inline reading.

Read the original article →

OpenAI’s release of its newest model, GPT 5.6, reportedly won’t be like its previous releases. Instead of distributing it to the public, the company plans to share it only with a select group of close partners because the Trump administration told it to, The Information reports.

At a meeting this week, CEO Sam Altman reportedly told staff that the government would be “approving access customer by customer” during a preview period. Altman reportedly added that if the limited release goes well, OpenAI hopes to follow with a general, broader release a “couple of weeks later.”

In other words, the Trump administration appears to be pressuring OpenAI to do what Anthropic is already voluntarily doing: keeping its most powerful AI models under wraps.

According to The Information, OpenAI’s new model is not only being reviewed by the administration, but its staffers also “worked closely” with the government on the upcoming release. The agencies that reportedly asked for a limited release were the Office of the National Cyber Director and the Office of Science and Technology Policy.

The Trump administration — which originally positioned itself as taking a “hands-off” approach to AI — has in recent months pushed for federal oversight of new models. Earlier this month, Trump signed an executive order directing certain AI companies to voluntarily submit new models to the government for testing and evaluation before releasing them publicly.

Earlier this year, Anthropic sparked no small amount of controversy when it announced that its new frontier cyber model, Claude Mythos, would only be released to a small coterie of partners through a program called Project Glasswing. Anthropic argued that its model was simply too powerful and could, in the wrong hands, cause more harm than good. Observers have since debated whether Anthropic’s rhetoric is a mere marketing gimmick or a legitimate attempt to keep a powerful model from being misused. The answer may be somewhere in between.

Cybercriminals have used automated tools for a very long time, but in the age of generative AI, they now have more digital ammunition than ever before. LLMs have proven adept at writing malware, and some can even execute entire ransomware attacks autonomously.

The specific concern with frontier cyber tools like Mythos is that they are ostensibly capable of both identifying and exploiting software vulnerabilities at speeds that no human analyst could match. Since many software systems contain hidden bugs that act as entry points into enterprise networks, this poses an obvious and significant problem for any organization running complex software infrastructure. That said, since these models remain closed to the public, it’s difficult to tell just how much of a threat they really are.

DeepReinforce has open-sourced Ornith-1.0, a self-improving family of models built for agentic coding. The release spans the full range, from a compact 9B Dense version meant for edge deployment up to a 397B MoE model aimed at frontier-scale work, with 31B Dense and 35B MoE options in between. Each variant is trained on top of pretrained Gemma 4 and Qwen 3.5 foundations.

What sets Ornith-1.0 apart from most reinforcement learning setups is how it handles the scaffold. Rather than depending on human-designed harnesses to steer solution generation, the model learns to produce both the solution rollouts and the task-specific scaffolds that guide them. Each RL step runs in two stages. Conditioned on a task and the scaffold last used for it, the model proposes a refined scaffold, then generates a solution conditioned on that scaffold. Reward from the rollout flows back to both stages, so the model is trained to author the orchestration as well as the answer. Repeated across training, scaffolds get mutated and selected toward those that produce higher-reward trajectories, and per-task strategies surface on their own without hand-engineered harness design.

Letting a model write its own scaffold opens a path to reward hacking, where a scaffold satisfies the verifier without doing the task. DeepReinforce describes a three-layer defense:

• A fixed outer trust boundary that keeps the environment and test isolation beyond the model's reach.
• A deterministic monitor that flags attempts to read withheld paths or alter verification scripts.
• A frozen LLM judge that vetoes the verifier when gaming happens inside the allowed tool surface.

On performance, DeepReinforce positions Ornith-1.0 as state of the art among open-source models of comparable size. The company reports the 397B flagship reaching 77.5 on Terminal-Bench 2.1 and 82.4 on SWE-Bench Verified, figures it says match Claude Opus 4.7 and top open peers such as MiniMax M3 and DeepSeek-V4-Pro. The 35B model is reported to clear similarly sized Qwen and Gemma builds, while the 9B version is said to hit 43.1 on Terminal-Bench 2.1 and 69.4 on SWE-Bench Verified and match far larger models like Gemma 4-31B, which puts capable coding within reach of resource-limited hardware.

DeepReinforce is the AI lab behind the release, a team that publishes reinforcement learning research in the open, including prior work such as CUDA-L1, and that shipped the IterX optimization loop for code agents. Ornith-1.0 carries that direction further by folding scaffold construction into the training process itself. The weights and a technical report are released on Hugging Face for teams that want to run or study the models directly.

Run a vLLM Server on HF Jobs in One Command

You can spin up a private, OpenAI-compatible LLM endpoint on Hugging Face infrastructure with a single command — no servers to provision, no Kubernetes, pay-per-second. Once it's up, you can query it from your laptop, a notebook, or anywhere else.

It's the quickest way to stand up a model for tests, evals, or batch generation. (If you're after a managed, production-ready service instead, that's what Inference Endpoints are for — more on when to pick which at the end.)

Here's the whole thing end to end.

Prerequisites

• A payment method or a positive prepaid credit balance (Jobs is billed per‑minute by hardware usage).
• huggingface_hub >= 1.20.0: pip install -U "huggingface_hub>=1.20.0".
• Logged in locally: hf auth login.

Launch the server

hf jobs run is docker run for HF infrastructure. We use the official vllm/vllm-openai image, ask for a GPU with --flavor, and expose vLLM's port with --expose:

hf jobs run --flavor a10g-large --expose 8000 --timeout 2h \
  vllm/vllm-openai:latest \
  vllm serve Qwen/Qwen3-4B --host 0.0.0.0 --port 8000

--expose 8000 routes the container's port through HF's public jobs proxy. The command prints the URL your server is reachable at:

✓ Job started
  id: 6a381ca1953ed90bfb947332
  url: https://huggingface.co/jobs/qgallouedec/6a381ca1953ed90bfb947332
Hint: Exposed ports are reachable at (requires an HF token with read access to the job):
  https://6a381ca1953ed90bfb947332--8000.hf.jobs

6a381ca1953ed90bfb947332 is your job ID. Keep track of it, we'll need it. We'll use <job_id> as a placeholder for it in the rest of the post.

Give it a couple of minutes to download weights and boot. When the logs show Application startup complete, you're live.

Query it from anywhere

vLLM speaks the OpenAI API, and every request just needs your HF token as a bearer token. The quickest way to hit it is curl:

curl https://<job_id>--8000.hf.jobs/v1/chat/completions \
  -H "Authorization: Bearer $(hf auth token)" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "Qwen/Qwen3-4B",
    "messages": [{"role": "user", "content": "Hello!"}],
    "chat_template_kwargs": {"enable_thinking": false}
  }'

which returns the usual OpenAI-style JSON, with choices[0].message.content holding "Hello! How can I assist you today? 😊".

Or, from Python, point the OpenAI client at the exposed URL and pass the token as the API key:

from huggingface_hub import get_token
from openai import OpenAI

client = OpenAI(
    base_url="https://<job_id>--8000.hf.jobs/v1",
    api_key=get_token(),
)
resp = client.chat.completions.create(
    model="Qwen/Qwen3-4B",
    messages=[{"role": "user", "content": "Hello!"}],
    extra_body={"chat_template_kwargs": {"enable_thinking": False}},
)
print(resp.choices[0].message.content)

🔐 The endpoint is gated, not public. Every request must carry an HF token with read access to the job's namespace. A plain browser visit will be rejected. In effect, the jobs proxy is your API gate: access is scoped to you (and your org). That's fine for private use, but treat the URL accordingly: don't share it expecting it to be open, and don't paste your token into untrusted places.

Clean up

Jobs are billed per second, so stop the server when you're done:

hf jobs cancel <job_id>

The --timeout you set is a safety net (it'll auto-stop), but cancelling explicitly is cheaper. An a10g-large runs at $1.50/hour — check hf jobs hardware for the full price list and pick the smallest flavor that fits your model.

Going further: bigger models

The same command scales to much larger models — pick a beefier --flavor and tell vLLM to shard the model across the GPUs with --tensor-parallel-size. For example, the 122B Qwen3.5 mixture-of-experts model on 2× H200:

hf jobs run --flavor h200x2 --expose 8000 --timeout 2h \
  vllm/vllm-openai:latest \
  vllm serve Qwen/Qwen3.5-122B-A10B \
  --host 0.0.0.0 --port 8000 --tensor-parallel-size 2 \
  --max-model-len 32768 --max-num-seqs 256

Going further: Chat with it in a UI

Prefer a chat window over curl? A few lines of Gradio point at the same endpoint. Add --reasoning-parser deepseek_r1 to the vllm serve command so Qwen3's thinking comes back as a separate field (not necessary, but helpful), then run this code locally:

Going further: SSH into the running server

Need to debug a startup failure, watch GPU memory, or tail logs interactively? You can open a shell straight into the running job. Launch it with --ssh and make sure your public key is registered at huggingface.co/settings/keys:

hf jobs run --flavor a10g-large --expose 8000 --timeout 2h --ssh \
  vllm/vllm-openai:latest \
  vllm serve Qwen/Qwen3-4B --host 0.0.0.0 --port 8000

then connect with the job ID:

hf jobs ssh <job_id>

Going further: Use it as a coding-agent backend with Pi

The same endpoint can back a terminal coding agent. Pi is a provider-agnostic agent harness. Point it at the job and you get a Read/Write/Edit/Bash agent running on your own self-hosted model.

HF Jobs or Inference Endpoints?

HF Jobs isn't the only way to serve a model on Hugging Face. Inference Endpoints are our managed product for the same job, and which one fits depends on what you're after.

Reach for HF Jobs when you want maximum flexibility and control: it's just docker run on HF infrastructure, so you pick the image, the exact vllm serve flags, and the hardware, and you pay per second for as long as the job runs.

Reach for Inference Endpoints when you want something more production-ready. They add the operational niceties a long-lived service needs: finer-grained access control (an endpoint can be public, protected, or private), and scale-to-zero, so you're not billed during periods of inactivity.

Further reading

This post sticks to vLLM, but the same expose-a-port pattern works with any OpenAI-compatible server. To serve GGUFs with llama.cpp or run SGLang instead, see the Serve Models on Jobs guide.

The US government has requested that OpenAI release GPT-5.6 to a short list of trusted partners before a wider release. OpenAI staff have been instructed to work with the Trump administration on any input that officials have on safety and restrictions. GPT-5.6 will initially be released to 20 partners through Amazon's Bedrock software platform. The Trump administration is continuing to collaborate with frontier AI labs to develop a shared approach for addressing the challenges of scaling the technology.

SpaceX’s newest Starmind will make earth data centers obsolete

Elon Musk confirmed that Starmind will be the official name of SpaceX’s planned AI satellite constellation, following a trademark filing by xAI that surfaced earlier this week. Starmind is what’s being described to the FCC as a constellation of up to one million AI satellites.

It’s worth noting that SpaceX’s Starlink communication satellite and Starmind are built on the same orbital infrastructure concept but serve entirely different purposes. Starlink is a connectivity network, with satellites receiving and relaying data between points on Earth, and functioning as a high-speed internet backbone in space. The satellites themselves do not process or think, and move information from one place to another, the same function a fiber cable performs underground.

Starmind, on the other hand, is something completely different, and rather than moving data, its satellites would compute data through artificial intelligence and directly in orbit using onboard processors powered by large solar arrays. Where a Starlink satellite is essentially a very fast pipe, a Starmind satellite is a server. The practical implication is that Starmind would allow AI models to run inference, process queries, and generate outputs from space, then beam results down to users anywhere on Earth within milliseconds, and without the data ever needing to travel to a terrestrial data center.

Starship will be able to carry 30 to 50 AI1 satellites per launch, delivering the equivalent of dozens of server racks per flight, with no land acquisition, no power grid approval, and no cooling infrastructure required on the ground.

SpaceX is pursuing this new technology as terrestrial data centers are running into hard limits such as lack of physical space, community opposition, and power and water consumption at a scale that is increasingly difficult to permit. Space has unlimited solar power, natural vacuum cooling, and no zoning boards. Musk said in a June 8 video presentation that he expects space to become the lowest-cost location to deploy AI compute within two to three years. Two AI1 prototypes are scheduled to launch in early 2027, with volume production targeted for the end of that year at a new facility called Gigasat.

The real world applications Starmind enables extend well beyond powering Grok. A constellation of orbiting AI processors could run inference workloads for any paying customer, anywhere on Earth, with latency measured in milliseconds rather than the seconds associated with ground-based cloud routing across continents. Starmind, if it scales as described, would make SpaceX the landlord of AI compute the same way Starlink made it the landlord of satellite internet.

Linux Foundation and Industry Leaders Launch Akrites to Defend Critical Open Source Software Against AI-Enabled Cyber Threats

Amazon Web Services, Anthropic, Chainguard, Cisco, Citi, Endor Labs, Ericsson, Google, IBM, JPMorganChase, Microsoft and GitHub, NVIDIA, OpenAI, RapidFort, Red Hat, Rust Foundation, Sonatype, Vodafone and Zscaler join coordinated effort to find, fix and responsibly disclose vulnerabilities in open source software the world runs on

Summary

• The Linux Foundation, joined by leading organizations, today announced Akrites, a coordinated effort to remediate and disclose vulnerabilities in critical open source software.
• Akrites establishes a shared Security Incident Response Team (SIRT) and a single, standardized Coordinated Vulnerability Disclosure (CVD) process, built on confidentiality-first principles and industry-standard tooling.
• Founding members commit engineering talent, security expertise and funding to harden the shared open source software that banks, hospitals, power grids, telecoms, governments, and AI labs depend on.
• Organizations that contribute engineering resources or funding to the security of critical open source are invited to participate and can learn more at https://akrites.org.

SAN FRANCISCO, June 25, 2026 – The Linux Foundation, the nonprofit organization enabling mass innovation through open source, today announced Akrites, a coordinated industry effort to harden the world’s most critical open source software in the era of AI-assisted vulnerability discovery. Backed by founding commitments from Amazon Web Services, Anthropic, Chainguard, Cisco, Citi, Endor Labs, Ericsson, Google, IBM, JPMorganChase, Microsoft and GitHub, NVIDIA, OpenAI, RapidFort, Red Hat, Rust Foundation, Sonatype, Vodafone and Zscaler, the initiative unites major technology companies, AI labs, financial institutions, and security vendors around a shared mission: to coordinate the remediation of vulnerabilities in widely used open source projects with upstream maintainers before those vulnerabilities can be exploited.

Open source software underpins virtually every layer of the modern digital economy, from banking and healthcare to energy, transportation, telecommunication, and government. Akrites enables industry coordination to support and defend critical infrastructure users and consumers of open source. Previously, finding and fixing serious flaws in open source software demanded comparable expertise from attackers and defenders alike. Today, frontier AI models can scan a major open source project and surface vulnerabilities in minutes. Once access to these capabilities is broadly available, bad actors who previously lacked the technical expertise to mount sophisticated attacks will have the tools they need to do so quickly.

To mark the launch, the founding signatories published a joint open letter to the technology industry, “We All Depend on Open Source. We Will Defend It Together.” The full letter is available at https://akrites.org/letter/.

In the past, security response involved a patchwork of organizations often working on the same problems independently, sometimes shipping conflicting patches or burying maintainers under duplicate reports. Akrites changes that model. The initiative provides a single, trusted place to coordinate, remediate and disclose, with a shared SIRT serving as a predictable partner for maintainers rather than a flood of uncoordinated reports. Akrites commits to working with critical infrastructure to support patch deployment before vulnerable systems can be targeted.

Confidentiality is central to the effort. Bug fixes flow back into each project’s original home, on maintainers’ terms. Where a critical package has no active maintainer, Akrites will serve as maintainer of last resort so fixes to the latest version reach everyone in a timely fashion. The initiative will also coordinate with government efforts so public and private defenders move together.

Alpha-Omega, a directed fund of the Linux Foundation, will provide seed funding to support Akrites. Other organizations that contribute engineering resources or funding to the security of critical open source are invited to participate. To learn more or to join, visit https://akrites.org.

Supporting Quotes

“Frontier AI models have given defenders the ability to find and fix vulnerabilities in open source software at a speed and scale that were never possible before. That's an enormous opportunity for defenders, and Akrites ensures we seize it together. Maintainers deserve a coordinated partnership, not a flood of reports. AWS is committed to securing the projects our customers depend on and building this shared infrastructure alongside the community.” – Matt Wilson, Vice President and Distinguished Engineer, Amazon Web Services

"Open source projects collectively underpin much of the internet, and the existing model for coordinated disclosure has been outpaced by how quickly AI can now find vulnerabilities. Getting ahead of that requires the industry to coordinate on findings and get fixes upstream before they're disclosed and exploited. Efforts like Akrites drive this level of coordination at the scale and speed this moment requires." – Jason Clinton, Deputy Chief Information Security Officer, Anthropic

"The software supply chain is only as strong as the upstream it draws from, and we see how thin that layer really is. As AI finds more vulnerabilities, the industry will rush to patch them. Without coordination, those fixes will fragment across different patches and forks, and maintainers who are already overwhelmed, unreachable, or haven't touched a project in years. Akrites gives the industry one coordinated way to fix vulnerabilities upstream before they're exploited, with maintainers still in control. Now the work is making sure there's always someone on the other end to catch them." – Dan Lorenc, CEO and Co-founder, Chainguard

"Finding a serious open source vulnerability used to take an expert weeks. It now takes a machine minutes. When maintainers lose that race, so does everyone else. No single company, no single maintainer, and no single government can close that gap alone. That is why Cisco is bringing its networking infrastructure, security expertise, and decades of open source contribution to Akrites - because defenders cannot afford to lose, and maintainers cannot be left to run this alone." – Vijoy Pandey, Senior Vice President and General Manager, Outshift by Cisco

“Advances in AI models have significantly reduced the effort required to discover and exploit vulnerabilities. In partnership with the Linux Foundation and Project Akrites, Citi is committed to supporting the open-source ecosystem by helping to build a framework that identifies and remediates vulnerabilities and shares proposed patches. Focused on securing critical infrastructure, this initiative is a key part of our efforts to help the industry mitigate emerging threats.” – Al Tarasiuk, Chief Information Security Officer, Citi

"For years we have believed finding vulnerabilities was never the hard part. Fixing them was. AI has made that gap impossible to ignore. Of the thousands of validated open source vulnerabilities surfaced in recent months, fewer than 5% have been patched. Endor Labs is a founding member of Akrites because it is built for the response this moment needs: coordinated remediation upstream, handled confidentially, with maintainers in control, so one trusted fix reaches everyone who depends on the code." – Varun Badhwar, CEO and Co-Founder, Endor Labs

“Vulnerability discovery is now moving at a speed that overwhelms both the maintainers who sustain open source projects and the users who rely on them. Uncoordinated reporting, patching, and disclosure create friction, putting the entire ecosystem at risk. No single organization can solve this alone. That is why Ericsson is joining Akrites as a Premier member, contributing funding and talent to a shared effort to keep open source software secure and thriving.” – Mikko Karikytö, Chief Product Security Officer, Ericsson

“As AI accelerates both the scale and speed of vulnerability discovery, defending the open source ecosystem requires an equally rapid, coordinated response. By joining Akrites, we are combining Google's long-standing commitment to open source security with industry-wide expertise to ensure that vulnerabilities are found, fixed, and responsibly disclosed before they can be exploited. Safeguarding the software that powers the world's critical infrastructure is essential to maintaining trust in our digital future.” – Heather Adkins, Vice President Security Engineering, Google

“Open source powers the systems we rely on every day – running everything from banks and hospitals to power grids and AI platforms. As frontier AI accelerates vulnerability discovery, the risk has grown too large for any one organization to address alone. That’s why an ecosystem approach is critical, bringing the community, technology providers, and enterprises together to ensure vulnerabilities are addressed and at the new speed required today.” – Jamie Thomas, Enterprise Security Executive, IBM

“AI has massively compressed the time between vulnerability discovery and exploitation to near real time, which means we have to compress the time from fix to deployment. That’s why we at JPMorganChase are helping to build this effort to measure success in patch deployment, not patch publication. We support a mechanism that enables downstream operators of critical infrastructure so that fixes reach real systems before adversaries can turn disclosures into exploits. And upstream, we owe maintainers a single, reliable signal: confirmed vulnerabilities, well-tested proposed fixes, and a predictable partner they can trust, rather than a flood of duplicative, conflicting reports.” – Pat Opet, Chief Information Security Officer, JPMorganChase

“OpenSSF and Alpha-Omega demonstrated what is possible when industry comes together to strengthen open source security. Building on our experience co-founding these organizations, Akrites was created to address the emerging inflection point of AI-powered vulnerability discovery and defense. As a founding member, Microsoft and GitHub will contribute expertise, resources, and AI technologies to help responsibly identify and fix vulnerabilities across the open source software ecosystem that customers and organizations depend on.” – Mark Russinovich, Azure Chief Technology Officer, Deputy Chief Information Security Officer and Technical Fellow, Microsoft

“Transparency and open collaboration are how the cybersecurity community has kept infrastructure safe for decades. In the age of AI, these open source foundations have never been more critical. Open source AI is the engine of American innovation — and one of our most powerful tools for deploying AI with the security, trust, and transparency needed to power this industrial revolution.” – David Reber, Chief Security Officer, NVIDIA

“The world runs on open source, and securing it is a long-term commitment for us at OpenAI. Through Patch the Planet, we’re putting our models and resources behind expert-led work that helps maintainers validate issues and land fixes, and we're proud to participate in Akrites to strengthen coordination across the industry and help defend the software we all depend on.” – Clint Gibler, Cyber Lead, OpenAI

“Open source only works when we keep the work open, upstream, and available to everyone who depends on it. The answer to the AI-driven vulnerability crisis is not to fragment the ecosystem behind proprietary walls or turn community foundations into closed products. It must be coordinated remediation that preserves the integrity of original software, works with maintainers, and returns fixes to the commons. We are proud to support the Akrites initiative which aligns with our belief of strengthening the open source ecosystem from within, helping organizations reduce risk without unnecessary code changes, and making the software we all share safer for everyone.” – Mehran Farimani, CEO, RapidFort

“Open source is the foundation of modern software innovation. Defending that foundation requires a coordinated, upstream community response capable of meeting threats at scale. Red Hat’s participation in Akrites focuses on strengthening this upstream ecosystem. By collaborating openly to identify and patch vulnerabilities at the source, we help build a more resilient software supply chain for the entire industry.” – Chris Wright, Chief Technology Officer and Senior Vice President, Global Engineering, Red Hat

“For too long, the goodwill and sense of responsibility among upstream maintainers has been taken for granted in security response processes. Akrites promises meaningful coordination with upstream maintainers, financial, and full-time support to find, fix and disclose security vulnerabilities responsibly, and a genuine commitment from the most influential companies across tech and finance to solve this problem. The Rust Foundation looks forward to working with Akrites to develop security that is fit for the future.” – Rebecca Rumbul, Executive Director and CEO, Rust Foundation

“Sonatype sees the dependency graph of the modern world every day. A single vulnerable component can sit underneath thousands of organizations, which means one upstream fix can reduce risk across an entire ecosystem. AI may make vulnerability discovery dramatically easier, but it does not make coordinated repair automatic. Akrites is important because it gives the industry a confidential way to do that work together, upstream, before the same flaw becomes thousands of separate incidents.” – Brian Fox, Co-founder and Chief Technology Officer, Sonatype, and Steward of Maven Central

“With the increasing ability of AI to fast-track vulnerability discovery, now is the right time to come together and invest resources to safeguard critical open-source software on which telecommunications and many other industries rely on. As a founding member, Vodafone has committed both expertise and funding to Akrites. This unified initiative will drive a co-ordinated, industry-wide approach to responsibly identify and fix vulnerabilities in the software that runs the systems upon which the world depends.” – Paul Hopkins, Cyber & IT strategy and Architecture Director, Vodafone

“AI has changed the speed of both offense and defense. Vulnerabilities can now be found at machine speed, which means defenders have to move just as fast. Akrites helps turn that speed into an advantage for the open source ecosystem by finding issues earlier, coordinating remediation responsibly, and pushing fixes upstream. Zscaler is proud to be part of it.” – Deepen Desai, Executive Vice President and Chief Security Officer, Zscaler

About Akrites

Akrites is a coordinated confidential effort to remediate and disclose vulnerabilities in the open source software that critical infrastructure depends on. It provides a single, standardized Coordinated Vulnerability Disclosure (CVD) process operated by a shared Security Incident Response Team (SIRT), built on confidentiality-first principles and the industry’s established standards and tooling (CVE, TLP, CWE, CVSS, EPSS, SSVC, VEX). To learn more or to join, visit https://akrites.org.

About The Linux Foundation

The Linux Foundation is the world’s leading home for collaboration on open source software, hardware, standards, and data. Linux Foundation projects are critical to the world’s infrastructure including Linux, Kubernetes, Node.js, ONAP, OpenChain, OpenSSF, OpenStack, PyTorch, RISC-V, SPDX, Zephyr, and more. The Linux Foundation is focused on leveraging best practices and addressing the needs of contributors, users, and solution providers to create sustainable models for open collaboration. For more information, please visit us at linuxfoundation.org.

Bringing more agent harnesses and frameworks to Cloudflare, starting with Flue

2026 is the year agent harnesses go to production. The software that controls the model’s access to the outside world — harnesses like Codex, Claude Code, OpenCode, Pi, and Project Think — has matured to the point where teams are deploying agents as real, load-bearing infrastructure, not just prototypes.

But building agents that survive production is hard.

We learned this firsthand building Project Think as our first-party agent harness. In working with our customers to run agents in production, we found a common set of distributed systems problems that every agent faces when running in the cloud. When an agent is interrupted, how can it automatically and gracefully resume from where it left off, without losing context or wasting tokens? How can agents run untrusted code securely? How can agents use the tools they were trained for?

A harness can’t solve these problems on its own. They’re tied to state, storage and compute — which means they’re dependent on the platform the agent runs on. That’s why we’re taking our learnings from hardening Project Think for production and bringing them to the Cloudflare Agents SDK as a base layer. Durable execution, dynamic code execution, a durable filesystem and dynamic workflows, now available to any harness building on Agents SDK.

At the same time, a new layer has emerged above the harness. Frameworks like Flue wrap a harness with the project structures, conventions, integrations and developer experience that make agents productive to build.

To solve these scaling challenges, there’s a new, three-layer stack that is emerging for building production-grade AI. Here is how the pieces fit together, moving from the user-facing developer experience down to the underlying platform primitives:

• The framework (Flue) — the project structure, the conventions, the integrations, the CLI and the developer experience for building agents.
• The harness (Pi, Project Think) — the agentic loop that calls tools, reads results, manages context and keeps going until the task is done.
• The runtime/platform (the Cloudflare Agents SDK) — the compute, state, and storage primitives everything above depends on.

The Agents SDK is that bottom layer: it makes primitives like durable execution available to any harness and any framework. Flue, our new open-source framework from the team behind Astro, is the first to build on it. Here’s how.

Flue

Flue shipped 1.0 Beta this week, built on the Pi harness, the same harness that OpenClaw is built on. What makes it different as an agent framework is the approach: you don’t script what your agent does, you describe what it knows. Define the context an agent needs — its model, skills, sandbox, and instructions — and it solves whatever task you give it, autonomously. There’s no orchestration loop to write.

This declarative model is what makes writing agents easy: here’s a triage agent that intercepts a bug report, reproduces it in a sandbox, and diagnoses the issue in under 25 lines.

The Flue developer experience

Flue’s power comes from the fact that agents don’t live in isolation. They are built to exist where your users already work, and integrate with your preferred tooling:

• Anywhere agents: Drop your agents into Slack, GitHub, Linear, or Discord with pre-configured Channels that handle event verification and dispatch boilerplate automatically.
• Headless, but UI-ready: Agents shouldn’t live in a black box. Flue agents can run completely headlessly for background tasks, but @flue/react provides native frontend hooks that stream an agent’s state, tool execution, and live messages straight into your frontend application, without you having to build custom real-time plumbing from scratch.
• Ecosystem-ready: Flue makes it easy to add and upgrade integrations with commands like flue add channel slack, generating a Markdown blueprint that your own coding agent can read, modify, and cleanly integrate straight into your codebase.

Designed for production, not just prototypes

Moving an agent out of a local terminal and into a production ecosystem introduces traditional distributed systems failures. Host crashes, API timeouts from LLM providers, and unexpected restarts threaten to erase the short-term memory of a running agent turn.

Flue solves this via Durable Streams. Each event in the execution history is added to an append-only log. By processing every prompt, tool response and model choice as an unchangeable ledger, an agent’s state is never volatile. If a process dies, another simply picks up the log and continues from the exact step it left off.

Deploy anywhere, including Cloudflare

Flue is a multi-cloud framework. On Node.js, each agent runs as a long-lived process. You can deploy it to any VM or container, run it in GitHub Actions, or embed it on an existing server. But when you target Cloudflare, each agent becomes a Durable Object.

By running each Flue agent inside its own Durable Object, Cloudflare can automatically scale to as many agents as you need, each with their own isolated storage and compute. You don’t have to provision servers, manage sticky sessions, or worry about noisy neighbors. And when Flue agents are deployed to Cloudflare, they get durable execution using Agents SDK’s runFiber(), stash(), and onFiberRecovered() methods. Flue also uses @cloudflare/codemode and @cloudflare/shell for sandboxed code execution against a durable workspace.

What harnesses need out of an agentic platform

Flue’s Cloudflare target works so effectively because it maps cleanly to the core primitives we built into the Agents SDK. You can even dig into the Flue source code to understand how Pi, the underlying harness, is adapted to work on Cloudflare Agents SDK.

Here’s how Flue leverages the Agents SDK under the hood, and what it takes to run any modern agent harness reliably at scale.

Every agent harness needs durable execution

An agent turn is not a single request. The model streams tokens, calls tools, waits for results, maybe asks a human for approval, or delegates work to a subagent. That sequence can take seconds or minutes, and at any point the process can be interrupted or crash. When that happens, all of the agent state that was in memory is gone: the streaming connection, the pending tool calls, where the agent was in its turn. Sure, the conversation history is persisted on disk, but the user sees a spinner that never resolves. That’s a broken user experience.

Fibers solve this problem by providing a native checkpointing mechanism directly inside the Agent’s underlying Durable Object. runFiber() records the progress to the Durable Object’s SQLite storage before the work in the Agent turn starts and checkpoints with stash() as the turn advances. When a fresh agent instance boots after an interruption, onFiberRecovered() delivers the last checkpoint, so your agent knows a turn was interrupted, where it got to, and can decide how to continue.

import { Agent } from "agents";
import type { FiberRecoveryContext } from "agents";

class MyAgent extends Agent {
  async doWork() {
    await this.runFiber("my-task", async (ctx) => {
      const step1 = await expensiveOperation();
      ctx.stash({ step1 });

      const step2 = await anotherExpensiveOperation(step1);
      this.setState({ ...this.state, result: step2 });
    });
  }

  async onFiberRecovered(ctx: FiberRecoveryContext) {
    if (ctx.name !== "my-task") return;

    const { step1 } = (ctx.snapshot ?? {}) as { step1?: unknown };
    if (step1) {
      const step2 = await anotherExpensiveOperation(step1);
      this.setState({ ...this.state, result: step2 });
    }
  }
}

Flue uses runFiber() on its Cloudflare target for exactly this. With the onFiberRecovered() hook, your harness can decide how to resume the execution of the turn, whether it attempts a full reconstruction model like Project Think that repairs turn state or whether it replays certain parts of the turn.

Executing code is better than overloading agents with tools

Agent harnesses give models access to the outside world through tools. But tool surfaces grow fast, and models get worse at selecting the right tool as the list gets longer and the context window fills up with tool definitions. A better pattern: give the model one tool that executes code. The model writes a TypeScript function that calls the APIs it needs, and the harness runs it.

The question is where that code runs. To run LLM-generated code securely, you need a sandbox. But typical sandboxes would be slow, cost-prohibitive and inefficient to run each tool call. That’s why the Agents SDK provides @cloudflare/codemode, which wraps Dynamic Workers, to execute LLM-generated code in its own Worker isolate with only the bindings you provide.

Code Mode creates a fresh Dynamic Worker for each snippet, runs it, and discards it. Isolates start in under 10ms and $0.002 per load, resulting in drastically faster and cheaper cost of execution than booting a container every time your agent needs to execute a short piece of code. Flue uses @cloudflare/codemode on its Cloudflare target to power its code tool. The agent writes JavaScript against the workspace and runs it with Code Mode.

You don’t need a full container for most workspace tasks

Agent harnesses often need a filesystem, whether it’s to read files, write outputs, search through code and understand diffs. Coding agents in particular live in the filesystem. But if the harness is running in a serverless environment, how can it get a durable filesystem that persists across executions?

The usual answer is a container. That works, but it’s expensive for what agents mostly do. The majority of filesystem operations in an agent turn are text. Consider a review agent that reads files, greps through source code, or perhaps writes a patch. You don’t need a full Linux boot for that.

@cloudflare/shell gives your agent a durable virtual filesystem inside its Durable Object, backed by SQLite. It provides typed file operations — read, write, edit, search, grep, diff — that agent harnesses can use as tools.

Instead of calling individual tools, a Flue agent running on the Cloudflare target writes JavaScript against the workspace virtual file state API. By running more operations within the Durable Object, the agent benefits from the isolate model’s more efficient execution process, entirely avoiding container overhead:

async () => {
  const files = await state.glob("src/**/*.ts");
  const results = [];
  for (const file of files) {
    const content = await state.readFile(file);
    const todos = content.match(/\/\/ TODO:.*/g);
    if (todos) results.push({ file, todos });
  }
  return results;
}

This translates into a faster and more cost-efficient sandbox environment for agents that need to run shell and filesystem operations to get their work done. And for agents that need a full OS, to run npm install, git, or compilers, Cloudflare Containers provides that. We’re also building @cloudflare/workspace, to keep the virtual file system of a given Durable Object in sync with a container’s, allowing for seamless transition from lightweight Workers to a Linux environment only when it needs one.

Dynamic Workflows: let agents write their own workflows to repeat tasks consistently

But what happens when an agent needs to do more than read files or execute single code snippets? What happens when it needs to orchestrate a massive, multi-step pipeline that must repeat consistently over time, like a code review that successfully resolves bugs or a research workflow that produces good results? A harness can’t provide durable multi-step execution on its own. It needs the platform to persist each step, retry failures, and resume after interruptions.

This pattern is gaining traction. Claude Code recently shipped dynamic workflows, where Claude writes a JavaScript script at runtime to hand off work to dozens of subagents, and the runtime executes it durably. @cloudflare/dynamic-workflows provides this for any harness running on the Agents SDK. Your agent generates a workflow at runtime, and the Workflows engine persists each step, retries failures, and can sleep for hours or wait for external events like human approval.

From the Agent class, runWorkflow() connects your agent to the Workflows engine. The agent kicks off the workflow and can go to sleep. The workflow calls back into the agent via RPC to report progress, update state, or request approval. When the workflow finishes, the agent wakes up with the result.

Direct access to the Cloudflare ecosystem

Beyond compute and storage, agent harnesses need access to external capabilities: web browsing, email, memory, search, inference. A harness shouldn't have to integrate each of these separately, manage API keys for each, or worry about credentials leaking through agent-generated code.

The Agent class gives your harness access to the rest of Cloudflare through bindings: AI Gateway for per-agent spend tracking and limits, Browser Run for web automation, Email Service for inbox workflows, Agent Memory for persistent recall, AI Search for retrieval, Containers for workloads that need a full OS, and inference across 14+ model providers. Bindings grant capabilities without exposing credentials: your agent uses them, but the keys never enter agent-generated code.

Bring your agents to the agentic cloud

We know this approach works because it is the exact architectural foundation we used to build Project Think, our first-party agent harness. While Project Think remains our highly optimized, out-of-the-box solution for native Cloudflare agent experiences, the Agents SDK ensures that the broader open-source ecosystem can leverage those exact same battle-tested primitives, including Flue.

If you're building agents today with Flue, you can deploy in just a few clicks to Cloudflare. And if you're building your own agent harness or you’re building an agent framework, target the Agents SDK and get the platform integration for free.

• Agents SDK: developers.cloudflare.com/agents
• Flue: flueframework.com, npm install @flue/runtime
• Think: docs
• Cloudflare Community: community.cloudflare.com

Production-Ready Autonomous Incident Resolution with AWS DevOps Agent (now GA) and Datadog MCP Server

In December 2025, we showed how AWS DevOps Agent and Datadog MCP Server could work together to autonomously correlate monitoring data with the infrastructure deployed and configured on AWS to resolve incidents in minutes instead of hours. Since then, Datadog MCP Server has reached general availability as the standard way for AI agents to access Datadog’s monitoring platform. Today, AWS DevOps Agent is generally available, giving teams a production-ready path to autonomous incident resolution across AWS, multicloud and on-premises environments.

What’s New: From Preview to GA

As engineering teams adopt AI-powered tools and build services that leverage AI agents, they want to extend their AI capabilities to incorporate familiar observability data and workflows. AI agents, however, often struggle with traditional API endpoints, causing them to miss the very context they need to resolve incidents effectively. Datadog MCP Server solves this by acting as a bridge between your observability data in Datadog and any AI agent that supports the Model Context Protocol (MCP). Now generally available, the MCP Server ingests prompts from users and AI agents and maps them to the corresponding Datadog resources and data. Under the hood, it handles authentication, HTTP request routing, endpoint selection, and response formatting so that agents receive highly relevant context without the brittleness of direct API calls. It supports modular toolsets so you can connect only the capabilities you need, from core observability data (logs, metrics, traces, dashboards, monitors, incidents) to specialized domains like APM trace analysis, security scanning, database monitoring, and CI/CD pipeline visibility.

Even with reliable access to observability data, incident response remains a manual, reactive process. On-call engineers must piece together the root cause of the incident from multiple data sources, draft mitigation plans, coordinate across teams, and then repeat the cycle when similar issues recur. This reactive approach does not scale as applications grow more complex and distributed.

AWS DevOps Agent changes this by introducing autonomous, always-on incident triage and investigation to your operations. AWS DevOps Agent is your always-available operations teammate that resolves and proactively prevents incidents, optimizes application reliability and performance, and handles on-demand SRE (Site Reliability Engineer) tasks across AWS, multicloud, and on-prem environments. It learns your resources and their relationships, correlates telemetry, code, and deployment data across your environment, and drives systematic improvements that prevent future incidents. Now, this also has several new capabilities that were not available during preview. It coordinates incident response automatically through channels like Slack, PagerDuty, and ServiceNow, keeping the right people informed without manual effort. It also delivers proactive prevention recommendations that address root causes before they lead to repeat incidents. In addition, DevOps Agent now supports multicloud and on-premises environments, extending its reach beyond AWS-only workloads to meet teams wherever their infrastructure runs.

With its built-in Datadog MCP Server integration, AWS DevOps Agent can pull the right Datadog context during an investigation, such as searching error logs, analyzing span-level latency, and reviewing recent deployment events. Together, these new features give engineering teams a fully integrated, production-ready workflow for autonomous incident resolution across AWS and Datadog.

Setting Up and Using AWS DevOps Agent with Datadog

In this section, we will guide you through the steps required to enable Datadog MCP Server in your AWS DevOps Agent account and configure it for incident resolution.

Pre-requisites

For this walkthrough, you should have access to and understanding of the following:

• An AWS account
  • Agent Space role – for basic service operations
  • Agent Space web app role – for using the Agent Space web app functionality
  • (Optional) Secondary source account roles if monitoring multiple AWS accounts. Refer to the DevOps Agent user guide for the details on setting up these roles.
• A Datadog account
• Access to Datadog MCP Server

Setting up Datadog in the AWS DevOps Agent Console

1. Start in the AWS DevOps Agent console by connecting your Datadog account.
2. Navigate to Capability Providers, select the Datadog integration panel and click Register button.
3. Enter Server Name, Endpoint URL, an optional Description, and click the Next button.
4. AWS DevOps Agent validates the connection and displays a confirmation message.

Create an AWS DevOps Agent Space

Create an Agent Space in your primary AWS account to serve as the operational hub for incident investigations.

• Open the AWS DevOps Agent console in us-east-1.
• Choose Create Agent Space and provide a meaningful name and description.
• Configure the required IAM role that grants AWS DevOps Agent access to your AWS resources. You can use the automated role creation process or create the role manually.
• After your Agent Space is ready, add the Datadog MCP Server as a telemetry source to enable comprehensive incident investigation.

Real-World Example: Resolving Errors

Let’s walk through how AWS DevOps Agent and Datadog work together to resolve a production incident. In this scenario, Datadog monitors detect a spike in Amazon API Gateway 5XX errors affecting downstream services.

Investigating errors from Incident with Datadog MCP Server and AWS DevOps Agent

When the 5xx alert triggers, AWS DevOps Agent automatically analyzes the incident using both Datadog metrics and API Gateway logs. Through the investigation chat interface, an engineer guides AWS DevOps Agent to examine the API Gateway configuration. The agent correlates API Gateway and AWS Lambda execution logs, quickly identifying error patterns.

Resolving issue

AWS DevOps Agent helps identify potential misconfigurations in the Lambda and Amazon DynamoDB integration and suggests immediate fixes. The agent documents all findings and actions in an incident investigation, backed by telemetry from both Datadog and AWS services. After resolution, AWS DevOps Agent generates a detailed analysis report with specific recommendations to prevent similar incidents.

Mitigation plans

After completing investigation, AWS DevOps Agent goes beyond identifying the root cause — it generates a detailed mitigation plan with step-by-step remediation guidance specific to the incident. Beyond immediate fixes, the plan includes longer-term prevention recommendations such as adding retry logic, implementing circuit breakers, or adjusting capacity thresholds to reduce the risk of recurrence.

This shifts the on-call experience from reactive to proactive. Instead of context-switching across multiple tools to build a remediation plan from scratch, engineers get a ready-to-execute plan they can review, refine, and route through existing change management workflows — keeping stakeholders informed as fixes are implemented. Over time, AWS DevOps Agent learns from resolved incidents across your environment, making its mitigation plans increasingly precise by recognizing patterns, referencing past resolutions, and surfacing preventive measures before similar issues repeat. AWS DevOps Agent also leverages its deep understanding of your environment, enabling you to dive deeper into your application environment, beyond just asking questions, to create, save, and share custom charts and reports.

Prevention

AWS DevOps Agent can evaluate recent incidents to identify improvement opportunities that prevent future incidents and reduce Mean Time To Detection (MTTD) and Mean Time to Recovery (MTTR).

1. Navigate to the Improvements page in the AWS DevOps Agent web app
2. Click Run Now. Once its completed, it displays a personalized incident prevention recommendation. Note: The “Run Now” button may not produce visible results immediately. Prevention analysis runs asynchronously in the background and results may take time to appear. This is expected since the feature is designed for production environments with longer incident histories.

Cleanup

When you’re done using the integration, you can clean up your resources by following these steps:

1. Delete your Agent Space from the AWS DevOps Agent console
2. Remove the Datadog MCP Server connection from your Capability Providers
3. Delete the IAM roles created for the Agent Space
4. (Optional) If you created additional source account roles, remove those as well

Conclusion

With Datadog MCP Server and AWS DevOps Agent now generally available, this integration automatically correlates Datadog logs, metrics, and traces with AWS telemetry, code, and deployment data, giving teams an autonomous investigation that identifies root causes, delivers actionable mitigation plans, and recommends preventive improvements. Early adopters have seen resolution times drop from hours to minutes and deeper root cause analysis across AWS, multicloud and hybrid environments.

LFM2.5-230M: Built to Run Anywhere

Today, we're releasing LFM2.5-230M, our smallest model yet. It’s a fast, lightweight foundation for developers to fine-tune and deploy in agentic workflows. Built on the LFM2 architecture, it delivers exceptionally fast inference and runs everywhere, from cloud GPUs to low-cost CPUs (213 tok/s decode speed on Galaxy S25 Ultra, 42 tok/s on a Raspberry Pi 5). Despite its small size, it’s surprisingly capable at tool use and data extraction tasks.

The base (LFM2.5-230M-Base) and post-trained (LFM2.5-230M) models are available today on Hugging Face. Check out our docs on how to run and fine-tune them locally.

Training & Fine-tuning

The model was pre-trained for 19T tokens, including a 32K context extension phase. We apply a lightweight post-training recipe designed to preserve flexibility for developers targeting their own downstream applications.

The recipe consists of three stages: (1) supervised fine-tuning with distillation from LFM2.5-350M, (2) direct preference optimization, and (3) multi-domain reinforcement learning. The final checkpoint balances strong out-of-the-box capabilities with adaptability to downstream specialization, while remaining competitive with larger models.

As an early look at ongoing work, we deployed LFM2.5-230M on a Unitree G1 humanoid robot, running entirely on-device on its onboard NVIDIA Jetson Orin. Here the model acts as a skill-selection layer: it takes a single natural-language instruction and decomposes it into a sequence of tool calls that invoke pre-trained low-level skills provided by NVIDIA's SONIC framework. After a quick fine-tune for this task, the model turns a free-form command such as

"Hold still for 2 seconds, then walk forward at 1 meter per second for 3 meters, hold a forward one-leg kneel for 5 seconds, and walk backward at 0.5 meters per second for 3 meters"

into a structured, multi-step plan, chaining skills like timed walking at a target velocity and a one-legged kneel. While the behaviors are deliberately simple at this stage, we think it's a compelling signal: a 230M-parameter model can be quickly fine-tuned and deployed on-device to serve as the natural-language control interface for a humanoid.

Benchmarks

We evaluated LFM2.5-230M across ten benchmarks covering both core capabilities and applied tasks. Despite its size, it competes with and often beats models more than twice as large, spanning knowledge (GPQA Diamond, MMLU-Pro), instruction following (IFEval, IFBench, Multi-IF), data extraction (CaseReportBench), and tool use (BFCLv3, BFCLv4, τ²-Bench Telecom and Retail).

This makes LFM2.5-230M an ideal solution to power large-scale data extraction pipelines or lightweight on-device agentic workloads. However, given its compact size, we do not recommend it for reasoning-heavy workloads such as advanced math, code generation, or creative writing.

Fast Inference Everywhere

LFM2.5-230M ships with day-one support across the inference ecosystem:

• llama.cpp — GGUF checkpoints for efficient edge inference
• MLX — Optimized inference for Apple Silicon
• vLLM — GPU-accelerated serving for production throughput
• SGLang — GPU-accelerated serving for production throughput
• ONNX — Cross-platform inference across diverse accelerators

CPU inference. Thanks to the efficient LFM2 architecture, LFM2.5-230M is considerably faster than similar-sized models, including SSM hybrids and Gated Delta Networks. On both a Raspberry Pi 5 and a Qualcomm Snapdragon Gen4 (Samsung Galaxy S25 Ultra), it delivers the highest prefill and decode throughput in its class while keeping the smallest memory footprint. We tune the flash-attention flag per device to maximize prefill on each platform: enabled (-fa 1) on the Raspberry Pi 5 and disabled (-fa 0) on the Snapdragon Gen4.

GPU inference. For production-grade enterprise deployments, we have also developed an internal GPU inference stack that delivers extremely low-latency serving. We benchmark it against other small models running on SGLang, and across all concurrency levels, LFM2.5 models achieve considerably lower end-to-end latency.

Get Started

Start building today with LFM2.5-230M and LFM2.5-230M-Base, available on Hugging Face.

With LFM2.5, we're delivering on our vision of AI that runs anywhere. These models are:

• Open-weight — Download, fine-tune, and deploy without restrictions
• Fast from day one — Native support for llama.cpp, NexaSDK, MLX, and vLLM across Apple, AMD, Qualcomm, and Nvidia hardware
• A complete family — From base models for customization to specialized audio and vision variants, one architecture covers diverse use cases

The edge AI future is here. We can't wait to see what you build.

Citation

Please cite this article as:

Liquid AI, "LFM2.5-230M: Built to Run Anywhere", Liquid AI Blog, Jun 2026.

Or use the BibTeX citation:

@article{liquidAI2026230M,  
    author = {Liquid AI},  
    title = {LFM2.5-230M: 
    Built to Run Anywhere},  
    journal = {Liquid AI Blog},  
    year = {2026},  
    note = {www.liquid.ai/blog/lfm2-5-230m}
}

Full article content is not available for inline reading.

Read the original article →

Autodata: An agentic data scientist to create high quality synthetic data

We introduce Autodata, a general method that enables AI agents to act as data scientists who build high quality training and evaluation data. We show how to train (meta-optimize) such a data scientist agent, so that it learns to create even stronger data. We describe the overall formulation, and a specific practical implementation, Agentic Self-Instruct. We conduct experiments on computer science research tasks, legal reasoning tasks and reasoning with mathematical objects, where we obtain improved results compared to classical synthetic dataset creation methods. Further, meta-optimizing the data scientist agent itself delivers an even larger performance uplift. Agentic data creation provides a way to convert increased inference compute into higher quality model training. Overall, we believe this direction has the potential to change the way we build AI data.

Smarter models are becoming more resourceful at hacking coding benchmarks.

Eval suites built from real bugs that were later fixed are especially vulnerable because the problems have already been solved. If the agent has access to repository history or the public web, it can sometimes look up the answer rather than derive it.

To measure how widespread this behavior is, we built an agent to audit eval trajectories. On SWE-bench Pro, we found that 63% of successful Opus 4.8 Max resolutions retrieved the fix rather than derived it. When we sealed git history and restricted internet access, scores dropped sharply for Opus as well as for our model, Composer 2.5:

• Opus 4.8 Max fell from 87.1% to 73.0%
• Composer 2.5 fell from 74.7% to 54.0%

Prior research has shown that coding benchmark answers can leak through publicly available sources, including this 2024 study and a 2025 Meta report. Our study quantifies the problem on current frontier coding-agent runs. The broader lesson is that in addition to avoiding training-time contamination, agentic coding benchmarks also need controlled runtime environments.

For teams conducting evals, we propose mitigating this reward-hacking behavior by auditing transcripts and constraining the eval environment.

Catch a model with a model

To measure the scale of the reward-hacking behavior, we had the auditor examine 731 Opus 4.8 Max trajectories. It saw the problem statement and full agent trajectory, without seeing whether the run passed, and classified whether the agent had retrieved the known answer.

The two most common reward-hacking patterns it found were:

• Upstream lookup: In 57% of the trajectories, Opus 4.8 Max found the merged PR or fixed source file on the public web, then reproduced the fix nearly verbatim.
• Git-history mining: In 9% of trajectories, Opus 4.8 Max searched the bundled .git history for the future commit that fixed the bug, then extracted the patch.

As models get stronger, they can sometimes infer that they are in an eval, especially when the task is borrowed from a past public repository. Even in cases where they don't remember the fix from training, the environment can still give them clues that the bug has already been solved.

In one SWE-bench Multilingual task from a 2019 jq issue, the agent tried to reproduce the bug with the system jq binary. Because the image had been built after the bug was fixed, the reproduction failed, and the agent inferred that the issue had already been solved. That awareness pushed it toward searching for the fix instead of deriving one.

A few cases were more direct. One agent found a SWE-bench mirror page that exposed hidden tests and the gold patch. Another obtained hidden test files and hardcoded the expected exception string needed to pass.

Example tool calls and patches

Upstream lookup (Opus 4.8 Max). The agent queried the merged PR through the GitHub API to find the files the fix touched, then reproduced it (the same response also exposes each file's diff):

cd /testbed && curl -s "https://api.github.com/repos/apache/druid/pulls/14092/files" 2>/dev/null | grep '"filename"'

Git-history mining (Composer 2.5). The agent located the fix commit in the bundled .git history, read its diff, then applied it directly:

cd /testbed && git show 895abd8929 -p 2>/dev/null | head -400
cd /testbed && git cherry-pick 895abd8929 2>&1

Patch excerpt to add: a trimmed verbatim slice of the git show output above (the gold diff Composer reproduced).

Stricter environment design

Most reward hacking flowed through the public web and repository history. For evals built from historical public repositories, those channels need to be controlled because they may contain the answer. In response, we built a strict harness with two isolation mechanisms:

1. History isolation. Before the agent starts, the .git directory is removed and the repository is reinitialized as a fresh single-commit repo. The original history is restored only at scoring time, so tests run as usual.
2. Egress proxying. Network access is denied by default. As a best-effort control, a pinned proxy allows dependency resolution against an allow-list of package registries, and nothing else.

This restriction is specific to evals built from historical public repositories. It's one reason we prefer evals built from non-public repositories, like CursorBench. They can test agentic coding ability while still letting agents use tools in the ways they would during real work.

A growing gap

We reran SWE-bench Pro and SWE-bench Multilingual in the stricter harness, then compared each result against the standard harness score as a proxy for the combined effect of removing these leakage channels:

• On SWE-bench Multilingual, it was under 1 point for Opus 4.6, 9.1 points for Opus 4.8 Max, and 7.5 points for Composer 2.5.
• On SWE-bench Pro, it was under 1 point for Opus 4.6, 14.1 points for Opus 4.8 Max and 20.7 points for Composer 2.5.

The clear takeaway is that reward hacking is far more common with newer, more sophisticated models than with older ones. Interestingly, GPT models don't show the same escalation, with generally smaller gaps in our runs.

We also observed that our own model, Composer 2.5, had the largest Pro gap in the study. This is one reason we do not treat the standard SWE-bench Pro score as a reliable benchmark number for Composer. The score was real in the narrow sense that the harness produced it, but it mixed coding ability with access to known fixes.

Designing evals for aware agents

The main takeaway for teams running coding evals is that benchmark design should not stop at dataset construction. It also has to account for the runtime environment, including what the agent can search, inspect, fetch, and recover while the task is running.

That does not mean every eval should remove internet access or git history. Some evals are meant to test how well agents use the surrounding context of a real codebase, and in those settings broad access may be part of the task. The problem is when that access changes what the score means.

For historical public-repo benchmarks, open access can let agents find the known fix rather than solve the bug. Without controls in the harness, scores can conflate coding ability with answer retrieval.

Teams running evals should decide what behavior they want to measure, design the harness around that, and make the setup clear when they report results. Auditing transcripts can help reveal when models are solving tasks in unexpected ways. The goal is not to ban normal tool use, but to make sure the benchmark measures what it claims to measure.

Even then, there remains a harder open problem. As models become more aware of when they are being evaluated, they may change their behavior in subtler ways that are not fixed by sealing git history or restricting internet access. Runtime contamination is one concrete version of a broader challenge of building evals that retain construct validity even when the model infers that it is being evaluated.

1. SWE-bench has since addressed this upstream by stripping future git history from its environment images (PR #471), with follow-up git cleanup work in early 2026 (PR #533). The images we had ingested predated that fix.
2. The exact gap sizes and the frequency of reward-hacking attempts depend on the prompts used. For example, hacking attempts increased when we instructed the model to keep working without stopping.

We removed an LM's ability to speak German by fine-tuning on only 4 German tokens.

As part of a 1-day hackathon with our product Silico, we removed a 67M-parameter language model's ability to predict German text, by tuning only a scalar factor on one subcomponent of the weights.

This was an early exploration in fine-tuning with parameter decomposition, our method which divides a model's weight matrices into interpretable, sparsely-activating components.

We picked German as it seemed to be the model's strongest non-English language.

https://twitter.com/3079387847/status/2051717264286609516

We benchmarked vs LoRA fine-tuning. Our edit matched its German removal with far fewer tokens.

Strikingly, it also left other languages almost untouched.

The LoRAs often wrecked French, Spanish, Italian, and sometimes English, while our edit mostly left them alone.

In a sense this is cheating: we're indirectly exploiting the tokens from when we did the parameter decomposition and interpreted the resulting subcomponents.

But if our decomposition is good, that cost can be amortized over arbitrarily many tasks & component edits.

Plus, that interpretability lets us notice and fix problems.

E.g.: initially we tuned the top 16 German-related components, but their labels showed most were about foreign languages in general.

So we narrowed to the single component for German alone, improving precision.

This is an early demo of how parameter decomposition could enable targeted, predictable model editing.

Details on this experiment: lesswrong.com/posts/ieoWstub…

If you want to run experiments on your model too, learn more and request access to Silico: goodfire.ai/silico

Correction: a plotting error caused the bars in the plot of off-target effects to display at 0.01 nats above the true means. The corrected plot is below.

A new chip architecture from IBM can integrate nearly 100 billion transistors on a chip the size of a human fingernail—nearly twice the transistor density of the company’s previous generation of chip technology. The resulting improvement in chip compute performance and energy efficiency comes from what IBM describes as the “world’s first sub-1 nanometer chip technology” for AI data centers.

“It’s not just an incremental step, it’s a meaningful leap forward,” said Jay Gambetta, director of IBM Research and IBM Fellow, in an advance media briefing. He described the new chip technology as “pointing to a future where computing becomes significantly more powerful without a corresponding increase in energy.”

It’s worth unpacking what the “world’s first sub-1 nanometer chip technology” means, because it is impractical to build reliably functional chips with transistors and other features smaller than 1 nanometer due to various physical limitations. Instead, IBM is basically claiming that its new “nanostack” architecture can deliver the computing performance improvements that would be expected if a theoretical chip could be built with physical features smaller than 1 nanometer.

Specifically, IBM describes its new chip technology as being built at the 0.7-nanometer node, which it has named the 7 angstrom node because 1 nanometer consists of 10 angstroms.

But keep in mind that such node numbers have nothing to do with the actual physical dimensions of IBM’s chip features. Older generations of chips developed in the 1970s and 1980s had physical features with dimensions matching the number in the name of their chip technology’s node or process—such as chips made at the 180-nanometer node—but that has not been the case for decades and certainly not for the latest chip generations made with a 3-nanometer or 2-nanometer process.

To overcome the physical scaling limits facing modern chip designers, IBM’s new nanostack architecture vertically stacks transistors in a staggered layout to pack more transistors into the same chip space. The nanostack architecture builds on the company’s prior development of nanosheet transistors that paved the way for its 2-nanometer chip node introduced in 2021.

The basic unit of IBM’s nanostack architecture consists of two transistors stacked and bonded together. Each transistor consists of three nanosheets that are individually 5 nanometers thick, equivalent to about 15 rows of silicon atoms. There is also a distance of about 9 nanometers separating each nanosheet.

Performance gains for the AI era

The nanostack architecture could pave the way for 50 percent higher computing performance or 70 percent greater energy efficiency than IBM’s previous generation of 2-nanometer node chips, according to projections from the company’s published technical reports. The company introduced its nanostack transistor architecture at the 2025 IEEE Symposium on VLSI Technology and Circuits held in Kyoto, Japan.

IBM researchers also showed how the nanostack architecture can provide 40 percent improvement in scaling for static random-access memory (SRAM) during the VLSI 2026 symposium. SRAM allows for fast but energy-intensive read and write operations that are crucial in many AI applications.

The memory improvement is made possible through a staggered-channel design for the chip’s SRAM bit cells—memory storage units consisting of six transistors—that reduces overall cell height by 40 percent and enables more SRAM to be squeezed into the same chip space.

That will probably be welcome news for chip designers looking to support AI workloads, given how SRAM scaling has fallen off drastically in recent generations of chip technologies. For example, SRAM scaling improved just a few percent between the 3-nanometer chip generation and the 2-nanometer chip generation, Gambetta explained.

“This achievement of 40 percent will eventually industrialize itself in AI workflows, which require higher bandwidth and high efficiency,” Gambetta said.

The roadmap for sub-1 nanometer nodes

As a company that performs chip technology research, IBM does not manufacture commercial chips that could end up in AI data centers or consumer devices. Instead, IBM has partnered with semiconductor companies such as Rapidus in Japan to mass manufacture its previous generation of 2-nanometer node chips based on the nanosheet architecture, or to commercialize related technology in another partnership with Samsung in South Korea.

Other companies have followed up on IBM’s pioneering work without any direct collaboration. For example, Taiwan’s TSMC independently developed nanosheet transistors for its own proprietary 2-nanometer node technology.

“Nanosheet has become the foundation of the next generation of transistor scaling,” said Huiming Bu, vice president of IBM Semiconductors Global R&D and IBM Research, during the media briefing. “Today, nanosheet is adopted by all leading foundries for most of the 3-nanometer chips and all of the 2-nanometer chips.”

IBM declined to name specific companies that it may partner with to commercialize the newest sub-1-nanometer node technology. But Bu expects that commercial chips made at the sub-1-nanometer node and incorporating the newest nanostack architecture could begin production as early as in the next five years and most likely within a decade.

“It will replace nanosheet as today’s mainstream in leading foundries, whether it’s CPUs or GPUs,” Bu said. “Within a decade, this will become another mainstream that we have invented and helped industry to transform.”

Control an Android Phone with Gemini 3.5 Flash Computer Use

Gemini 3.5 Flash has built-in Computer Use. The model looks at a screenshot, decides what to do, and returns a function call like click(y=300, x=500). You execute that action on the device via ADB, take a new screenshot, and send it back. Repeat until the task is done.

This guide walks you through controlling an Android emulator using the mobile environment and the Python SDK.

What is Computer Use?

Computer Use is a native tool in Gemini 3.5 Flash. You give the model a screenshot and a goal ("open Settings and turn on dark mode"). The model returns structured actions: taps, text input, swipes, app launches. Your code executes those actions on the target device.

It works like function calling. The model proposes actions, you execute them, you send back the result. The model stays in the loop through screenshots.

Gemini supports three Computer Use environments: browser for desktop web automation, mobile for mobile devices/emulators, and desktop for operating system-level control. This guide uses mobile.

Supported actions (mobile environment)

These are the actions the model can request when using environment: "mobile". Your code must handle each one.

Coordinates are normalized to a 0-999 grid. (0, 0) is top-left, (999, 999) is bottom-right. Your bridge converts these to actual pixel coordinates based on the device resolution.

Setup

No Android Studio GUI required. Run the setup script on your Mac to install the Android SDK, emulator, and create a virtual device from the terminal.

1. Run the setup script

chmod +x setup_emulator.sh
./setup_emulator.sh

2. Install Python dependencies

pip install google-genai

The agent loop

The Python agent script handles locating SDK paths and starting the emulator in the background automatically.

How to run it

# Set your API key
export GEMINI_API_KEY="your-key"
 
# Run the agent (starts the emulator automatically if needed)
python agent.py "Open Settings and enable dark mode"

Connecting to a Remote Device

You can also target physical Android devices or remote cloud emulators instead of a local virtual device.

1. Enable USB/Wireless Debugging: On your target device, enable Developer Options and turn on USB Debugging or Wireless Debugging.
2. Connect via ADB: Use the adb connect command to link to a remote device over TCP/IP:

   adb connect <device-ip-address>:5555

3. Pass the Device ID to the Agent: Pass the remote device's connection string as the device_id parameter to target it in the agent loop:

   # Target a remote or cloud-hosted emulator
   run_agent("Check the weather", device_id="35.200.100.10:5555")

Next Steps & Developer Tips

• Supporting iOS / iPhone: The Gemini API's mobile environment is platform-agnostic. The model outputs actions (clicks, swipes, types) on the same normalized 0-999 grid regardless of whether the device is Android or iOS. To target an iPhone or iOS Simulator, you only need to swap out ADBBridge with an iOS-compatible tool.
• Production Robustness: The Python bridge code provided here is synchronous and optimized for demonstration. For production use, you should implement robust retry logic for network drops, handle ADB disconnects gracefully, and execute operations asynchronously.
• Handling Safety Decisions: In real-world tasks (especially those modifying state or making payments), the model might flag action steps with a safety_decision requesting confirmation. Ensure your production loop inspects step.arguments for safety flags and prompts the user before executing the action.

Z.ai released GLM-5.2 just days after Anthropic was forced to shut down its most powerful AI systems due to a demand from the US government. GLM-5.2 is nearly as powerful as Anthropic's Fable and Mythos models, but it costs much less to use, and no one in the US is putting restrictions on it. The model is currently one of the world's top 10 most popular models. It is open source, so anyone can use and modify it for free.

Full article content is not available for inline reading.

Read the original article →

Companies Could Soon Staff ‘Stubbornly Local’ Jobs With Workers 4,000 Miles Away

Companies once moved whole factories overseas to reduce labor costs. Now, workers a world away can operate local excavators, forklifts, and even humanoid robots with an internet connection.

Packaging potassium sulfate, a fertilizer vital to the planet’s food supply, is visually striking—not because of what you see, but because you don’t see much at all. In China’s Xinjiang region, home to the world’s largest deposit of the mineral, piling it up in warehouses creates dust clouds so severe that workers are forced to drive heavy machinery by feel.

Some companies are now turning to a technology that not only offers a way to see through the dust but also keeps workers from entering the warehouse at all. The system, developed by BuilderX Robotics, a Chinese tech company, uses cameras that are like night-vision for dusty areas. More significantly, operators drive excavators, loaders, and other machines from a remote office filled with rows of videogame-like stations. All they need is a 5G or satellite connection.

The ability to control physical machines from a distance is called teleoperation, and it could become a significant force of change in the global economy.

In Japan, the shelves of over 300 convenience stores are being restocked by robots monitored and sometimes controlled by workers in the Philippines. Düsseldorf airport was slated to begin testing shuttles driven by remote workers in May. A startup in Atlanta is offering robot security guards operated by remote staff, and last summer, a surgeon in France performed a teleoperated procedure on a patient in India.

While offshoring teleoperated jobs to overseas workers hasn’t yet become routine, Mark Graham, professor of internet geography at the University of Oxford, suggests the technology is worth our attention because it might enable companies to expand on their well-established habit of outsourcing jobs to places where labor is cheaper.

The use of remote labor isn’t new, Graham told SingularityHub. But teleoperation extends the logic of outsourcing to tasks that were previously thought to be “stubbornly local.”

“The novelty is less about the existence of remote labor and more about the kinds of work that can now be pulled into a planetary labor market,” he said. “Once that happens you can expect the usual pressures around labor arbitrage, control, and fragmentation to follow.”

It’s not clear we’re ready for the consequences.

BuilderX Robotics is a global leader in teleoperation for heavy machinery and a good expression of the changes ahead. Shaolong Sui, a graduate of Stanford University with a degree in mechanical engineering, founded the company in 2018 as a response to labor shortages in the construction industry in Asia.

“A shortage of trained operators isn’t a problem only in developed countries,” he told me. “Young people here in China don’t want to do this work. It’s dusty and dangerous.”

Rather than focusing on full robotic autonomy, which many construction companies have pursued over the past decade, Sui identified teleoperation as a more realistic way to move operators from harsh environments to safer conditions. Making use of the proliferation of low-cost sensors and 5G at the time, Sui completed a prototype in 2019. Today, his company offers teleoperation for 14 different industrial machines, including excavators, loaders, and bull dozers.

In our conversation, it was clear he hopes to improve working conditions for manual laborers. I lost track of the number of times he mentioned removing operators from dangerous worksites. “These workers deserve a better life,” he said.

BuilderX’s workstations do seem to have transformed some of the punishing work of an industrial site into a more white-collar experience, complete with tea and coffee break rooms and toilets down the hall. Sui said his solution allows construction firms to hire senior citizens or people with disabilities who, thanks to the videogame-like interface, can now operate heavy machinery. In another video, a Japanese woman who pilots an excavator proudly shows off her complex nail art, something she claims she couldn’t maintain when she worked in the field.

“Not only is this a much safer workplace, but the lifestyle benefits are that you can sit in an air-conditioned space, enjoy your tea, and when you go home, you’re still clean,” Sui said.

There’s no doubt the approach is safer for frontline workers like those in Xinjiang. Evidence suggests that high levels of potassium dust exposure can cause chronic bronchitis. While pulling someone from dangerous work is a good thing and that should be taken seriously, Graham told me, it doesn’t necessarily mean they’re free from exploitation.

“A worker can be removed from the physical site and still be subjected to intense surveillance, deskilling, isolation, fragmented contracts, algorithmic management, and downward pressure on wages. In other words, the risk can move rather than disappear,” he said.

Sui and Graham both agree there are plenty of forces that might slow the pace of outsourcing. Currently, none of BuilderX’s customers offshore work to overseas operators. But that doesn’t appear to be a technology constraint, as recently demonstrated by an operator in Poland controlling an excavator over 4,000 miles away in Beijing. On the technical side, latency—the delay between operator and machine—and reliability will shape the rate at which firms can choose to offshore workers. But it’s more likely to be limited by regulatory constraints in the form of licensing, insurance, and safety requirements.

That said, Graham believes the biggest force driving work overseas will be the same one that’s pushed clerical and service work offshore; the relentless pursuit to increase profit and reduce cost.

“If firms can hire people in lower-wage labor markets to operate expensive equipment thousands of miles away, many of them will try,” he said.

Most debates about AI and robotics focus on job loss due to automation. There is relatively little discussion about the risk of offshoring teleoperated work as the technology comes online. This is partly due to the hype surrounding physical AI, a Silicon Valley buzzword describing a world where fully autonomous robots cut humans out of the loop. But Graham says that when machines arrive people tend to incorrectly assume humans disappear.

“In many cases, what gets described as automation is really a reorganization of labor. Work gets broken apart, moved around, and hidden from view,” he says.

As is the case with AI, the robotics industry’s push toward full automation is still plenty reliant on a hidden system of faraway workers. Teleoperation provides training data for robots and is needed to help them deal with unexpected events. Consumer robotics startup 1X is selling a $20,000 humanoid that will sometimes need to be controlled by remote staff. It’s not clear how often future robots cleaning dishes in San Francisco kitchens will be steered by gig workers in Mumbai.

Robotaxi company Waymo already relies on human agents to assist, though not literally drive, vehicles stuck in difficult scenarios. The firm recently disclosed for the first time that some of these agents are based in the Philippines. This information, surfaced during US congressional testimony, immediately raised questions of oversight for safety-critical work: For instance, should a worker in Manila be required to get a California driver’s license?

Amid an already combustible US political environment, teleoperation could raise the heat even higher. Fueled by fears of Americans losing jobs to people overseas, Wyndham Hotels and Resorts, the parent company of La Quinta, was last year forced to respond to anger over a viral video depicting workers allegedly in India remotely handling check-in at one of their Miami hotels. As Graham points out, people tend to care more about outsourcing when it’s no longer hidden in a back office.

But outrage alone, he says, rarely defeats a business model that saves money. Due to network effects surrounding training, infrastructure, and other business process optimization, outsourced labor also tends to cluster in specific areas. This may already be happening in the case of Waymo, which could soon see the rise of something like a “driving district” in Manila. In the future, other types of teleoperated work could follow suit, giving companies a ready-made destination to shop for low-cost labor.

For Graham, it’s urgent that we begin requiring certification from independent bodies, which can better scrutinize a company’s production networks. At Oxford he directs Fairwork, a project aiming to improve labor practices in digital supply chains.

I asked Sui how he thinks his customers may reorganize their operations around this new ability to remotely control their machinery.

“We're working with traditional industries, and so it’s not just about adopting a new technology. There are significant management changes they will have to navigate. You could call this transformation friction because they will need time to digest this new capability step by step,” Sui said.

Despite the fact they could use the technology to outsource work across national borders, none of his customers are doing so just yet. Sui used open pit mines as an example. In this case, where fully developed towns with schools and hospitals have built up over decades, his customers still cluster their workforce next to the sites where they operate. Instead of driving into the mine, operators work from an office and go home clean at the end of a shift.

BuilderX has deployed its technology at more than 100 sites in China, Japan, and parts of Europe. It’s now expanding into new markets including South America and the Middle East. When asked whether he thinks his technology will be used for transnational outsourcing, there’s no hesitation. “Oh yes, I think this is coming in the very near future.”

Argo CD 3.5 introduces major enhancements, including ApplicationSet UI support with deployment previews, beta status for impersonation and Source Hydrator, Helm 4 compatibility, repo-server mTLS, source integrity validation, and expanded multi-tenant capabilities for large-scale GitOps environments. The release also improves Azure integration, Gateway API visualization, CLI namespace support, application search, reliability, performance, and documentation.

Grafana 13.1 release: observability as code updates, extending Grafana Assistant across more data sources, and more

Earlier this year, Grafana 13 laid the groundwork for making it easier and faster than ever to turn your data into actionable insights.

With our latest minor release, Grafana 13.1, we're building on that foundation, expanding observability as code, bringing Grafana Assistant to more data sources, and streamlining the everyday workflows teams rely on to visualize, analyze, and act on their data.

Below are just some of the highlights from Grafana 13.1. If you want to explore all the latest updates, please refer to the changelog or our What’s New documentation.

Managing dashboards as code: what's new in Git Sync

Git Sync, a feature that brings native GitOps workflows into your Grafana instance, reached general availability with the release of Grafana 13. We added features to give you more flexibility and control when managing your dashboards as code, including GitHub App authentication and support for GitLab, BitBucket, and pure Git.

But we didn’t stop there. Grafana 13.1 brings four more enhancements to Git Sync that make it even easier to incorporate observability as code into your day-to-day workflows.

Import dashboards straight into a provisioned folder

Generally available in all editions of Grafana

You can now import dashboard JSON straight into a Git Sync-provisioned folder, picking the file path, branch, commit message, and workflow as part of the import.

From a folder, hit Import and Grafana walks you through a provisioned import flow: pick the file path, branch, commit message, and workflow, and the dashboard is committed back to your repository as part of the import.

Uniqueness is path-based, so two dashboards can share a title as long as they live at different paths in the repo, and a conflicting path stops the import before anything is overwritten.

Sync dashboards at the root level

Generally available in all editions of Grafana

You can now sync dashboards at the root level, without a containing folder, so provisioned dashboards can live alongside your non-provisioned ones. This is useful when a repo represents your whole Grafana setup, or when forcing everything under one folder doesn’t align with how your team organizes dashboards.

Pick Sync external storage directly at root level without a containing folder in the setup wizard and your provisioned dashboards land at the root, alongside everything else, instead of being scoped under a single folder.

Make dashboard context visible by default

Available in public preview in all editions of Grafana

Git Sync-provisioned folders now render their README.md inline by default, so the context for a folder travels with it.

Just drop a README.md next to your dashboards in the repo and it shows up in Grafana, including links, ownership notes, runbooks, or whatever your team wants to see sitting alongside their dashboards.

Sign commits automatically

Generally available in in all editions of Grafana

Git Sync can now sign commits with GPG, SSH, or S/MIME keys, so your Git provider marks them as verified. This means teams with branch protection rules that require signed commits can now use Git Sync without friction. Until now, Git Sync could only create unsigned commits, which caused pushes to be rejected in those repositories.

To enable signing, configure a signing key on the repository, and Git Sync will automatically sign every commit it makes to that branch. If no signing key is configured, commits remain unsigned.

Extending the reach of Grafana Assistant

We're continuing to expand where and how you can use Grafana Assistant, our AI-powered agent in Grafana Cloud. From connecting to more data sources across your stack to making Assistant easier to access in self-managed environments, these updates help bring AI-powered observability to wherever your data (and Grafana instance) lives.

Using Assistant with additional data sources

With Grafana 13.1, you can use Assistant to directly query eight additional Grafana data sources: Snowflake, Oracle, Elasticsearch, Dynatrace, Honeycomb, Zabbix, Jira, and MongoDB.

This makes it easier to ask a single question and get an answer that draws from across your observability stack, your databases, and your project-tracking tools—no context switching required. For example, an investigation that starts with an alert can pull in error rates from Dynatrace, query performance from Oracle and recent deployments from Jira, all in one conversation.

For each data source, Assistant queries your data using natural language, correlates signals across sources, and visualizes the results as Grafana dashboards.

Assistant now pre-installed in Grafana Enterprise

Grafana Assistant now comes pre-installed in Grafana Enterprise, with no plugin installation required. If you're a Grafana Enterprise user, you can connect your Grafana Cloud account to start using Assistant right away.

If you're a Grafana OSS user, you can still get access to Assistant by installing the plugin from the Grafana plugin catalog and connecting your Grafana Cloud account.

Faster, more flexible dashboarding

Grafana 13.1 brings a batch of improvements that make building and exploring dashboards faster and more flexible.

Section-level variables for rows and tabs

Generally available in all editions of Grafana

In Grafana 13, we introduced section-level variables, a feature that lets you apply variables to each row or tab in a dashboard, so you can reduce clutter and improve the overall organization of your dashboards. With the 13.1 release, these variable types are now generally available.

Traditionally, dashboard variables have applied to the whole dashboard at once: if you changed an $instance variable, for example, this would update every panel together. That was a big limitation when a single dashboard spanned more than one service, such an API gateway and a database. Teams would have to split services across separate dashboards just to give each its own filters, making it difficult to achieve a unified view of their data.

Section-level variables solve for this. Each row or tab can now carry its own independent variables, so an API gateway row can scope to one set of instances while a database row scopes to another, all in the same dashboard.

A revamped query editor

Available in public preview in all editions of Grafana

The improved query editor experience we introduced as private preview in Grafana 13, which makes complex panels easier to build and manage, is now in public preview, with two new capabilities:

1. Multi-select with bulk action: You no longer have to manage queries, expressions, and transformations one at a time. Instead, you can click Select… in the sidebar footer to enter multi-select mode. From there, you can check the specific items you want to work with. A new bulk actions bar also lets you delete, hide, or show several queries at once, switch the data source for multiple queries in a single step, or enable and disable transformations in bulk.
2. Stacked view: When you want to see the whole pipeline at once, the stacked view lays out all of your queries, expressions, and transformations in a single scrollable list.

Overall, these two new features combined with incremental improvements to the original release make creating and editing complex queries more straight-forward and faster than ever before.

More dashboarding and visualization updates

In addition to the new query editor and section-level variables, other data visualization updates in Grafana 13.1 include:

• Quick filters and data grouping: The new Filter and Group by dashboard control combines filtering and grouping in one place, so exploring data is faster and more intuitive.
• Series visibility through time series legends: The new Series visibility filter in the time series visualization lets you narrow visible series interactively, by name, label, or both, without touching the underlying query.
• Enhancements to nested tables: Table panels with nested rows are now much more configurable, with cell styling and improvements to aggregation.
• Copy and paste panel styles: In a couple clicks, you can replicate colors, line styles, and more from one panel to another.
• Panel style presets : Apply curated colors, thresholds, and display options to time series, stat, gauge, bar gauge, and bar chart panels with a single click in the panel editor.

PDC support for more data sources

Generally available in Grafana Cloud

With Private Data Source Connect (PDC), you can create a private, encrypted tunnel between your Grafana Cloud stack and data sources running inside private networks, VPCs, or on-premises environments.

With Grafana 13.1, we’ve added PDC support for three new data sources: MQTT, GitHub, and IBM Db2.

With this update, you can connect Grafana Cloud to MQTT brokers for real-time IoT and sensor data; GitHub Enterprise Server instances for source control and project metrics; and IBM Db2 databases running on-premises or in a private cloud.

Learn more about Grafana

For an in-depth list of all the new features in Grafana, check out our Grafana documentation, the Grafana changelog, or our What's New documentation.

Join the Grafana Labs community

We invite you to engage with the Grafana Labs community forums. Share your experiences with the new features, discuss best practices, and explore creative ways to integrate these updates into your workflows.

Upgrade to Grafana 13.1

Download Grafana 13.1 today or experience all the latest features by signing up for Grafana Cloud. Our Grafana upgrade guide also provides step-by-step instructions for those looking to upgrade from an earlier version.

Special thanks to our community

We extend our heartfelt gratitude to the Grafana community!

Your contributions, ranging from pull requests to valuable feedback, are crucial in continually enhancing Grafana.

GitHub Copilot is improving agent efficiency by reducing redundant context through prompt caching, deferred tool loading, and cache-aware routing, while introducing Auto model selection to match tasks with appropriate models dynamically. These changes aim to optimize cost, performance, and quality across long agentic sessions by minimizing repeated computation and improving model-task alignment.

I've worked on Crossplane for almost eight years, since the v0.1 release. In that time I've watched a lot of people use it to put cloud infrastructure behind an API. For the last few months I've been using it to put a particular, demanding kind of infrastructure behind an API: a fleet of GPUs running model inference.

The project is called Modelplane. It lets a platform team turn a pile of accelerators (across clouds, neoclouds, and on-premise) into one fleet. It also lets the ML teams they support deploy a model and get a stable, OpenAI-compatible endpoint without thinking about where it runs.

Modelplane exists because open-weight models have moved inference out of the labs and hyperscalers and into everyone else: neoclouds, regulated enterprises keeping models inside their own walls, and companies trying to get their inference bills under control. The open source stack for serving a model on a single cluster is strong now: vLLM, SGLang, KEDA, Gateway API, DRA. But inference almost never stays in one cluster. Capacity is scattered across hardware types, providers, and regions. The hard problems are now above the cluster: placing models across the capacity you have, provisioning more, routing by cost and locality, moving weights around. The labs and the hyperscalers all built systems to do this, but they built them privately. That's the gap Modelplane fills: an open control plane that sits above your clusters and operates them as one inference fleet.

If the inference part interests you, the Modelplane docs and Bassam's introduction are the place to go. This post is for the Crossplane crowd, because the part I think you'll find interesting is that Modelplane is, top to bottom, a Crossplane configuration. It has no bespoke controllers and no custom operators: it's compositions and composition functions. The same primitives you could use to compose an RDS instance, pushed a lot harder.

I want to cover the problem we set out to solve with Crossplane, the parts of the framework we leaned on hardest, and the edges we hit and fixed upstream.

The problem, in Crossplane terms

Strip away the inference vocabulary and Modelplane's job is one Crossplane users will recognize: take a declarative description of what someone wants, and turn it into composed infrastructure spanning cloud accounts, many Kubernetes clusters, and the workloads on them. Provision an EKS or GKE cluster with the right GPUs. Install an inference stack onto it. Decide which cluster each model runs on, and how many copies. Keep it all converged as clusters come and go and people's inference needs change.

Crossplane was built for that shape of problem. Providers gave us reach: we provision clusters and the infrastructure they need across different clouds, and install software onto them, without needing to write new controllers. Functions allowed us to focus on our business logic, the placement and the scheduling. We didn't have to write the controller plumbing by hand: the watches and requeues and finalizers and drift correction that Crossplane core already handles.

Crossplane v2 helped here too. Modelplane has two clear personas. Platform teams describe the fleet. ML teams describe a model. That split maps onto a scope boundary: an InferenceCluster or InferenceClass is cluster-scoped, a ModelDeployment or ModelService is a plain namespaced composite resource the ML team owns. v2 namespaced composites let us express that directly, with no claim-and-XR duality to explain. That's useful, but it isn't what made the project buildable.

What made it buildable: Developer experience

What really unlocked this project was the new Crossplane CLI and the schemas it generates.

Modelplane's functions are all written in Python. We chose Python because it's the lingua franca of the ML world. We hope it might help folks who aren't yet cloud native experts contribute to the project. Writing functions in Python used to mean giving up a lot of the tooling that makes a codebase feel like a proper project. The new crossplane CLI changed that. It scaffolds a project, generates an XRD from an example resource, and generates typed schema bindings for your APIs.

Those generated models changed how we worked. Our functions read and write typed objects instead of poking at untyped dictionaries and hoping the field is spelled the way we remember. A typo or a wrong type now fails at author time. The models also sped up the coding agents we leaned on while building. A generated type tells the agent the exact shape, so it got field names and types right the first time.

There was friction. We outgrew the CLI's built-in function builders early, and we needed schema generation for one language, not all four. Both of those turned into upstream contributions, which I'll come back to.

Designing the API

The hardest part of Modelplane was designing the API.

People come up to me at conferences worried about how they'll make breaking changes to the APIs they build with Crossplane. My answer is usually that you almost never have to, if you really think the API through before you release it. That discipline pays off: reach for arrays and enums before you think you need them, use required fields sparingly, and leave room to grow without a breaking change.

Take the ModelDeployment, arguably Modelplane's most important API. It's how an ML team describes a model to serve: its engines, what their pods need from a node, and how many replicas to run across the fleet.

apiVersion: modelplane.ai/v1alpha1
kind: ModelDeployment
metadata:
  name: qwen3-8b
  namespace: ml-team
spec:
  replicas: 1
  engines:
  - name: qwen3-8b
    members:
    - role: Standalone
      nodeSelector:
        devices:
        - name: gpu
          count: 1
          selectors:
          - cel: device.capacity["gpu.nvidia.com"].memory.compareTo(quantity("20Gi")) >= 0
      template:
        spec:
          containers:
          - name: engine
            image: vllm/vllm-openai:v0.23.0
            args:
            - "--model=Qwen/Qwen3-8B"
            - "--served-model-name=qwen"
            # ... engine flags omitted for brevity

I got the engines array wrong at first, and only caught it about two weeks before we released v0.1. Until then a ModelDeployment had a spec.topology block where you'd write tensor: 8 and pipeline: 2. Modelplane would derive engine-specific flags like --tensor-parallel-size and inject them. The problem was that this coupled Modelplane to engine specifics. We could only run the engines whose flags we knew how to inject. It also couldn't express the data and expert parallelism we knew was coming. I caught it only because I sat down to write worked examples for those topologies and found I couldn't. I replaced it with shape: an engine is an array of Standalone, Leader, or Worker members, and the parallelism lives entirely in the flags the user writes. My takeaway: don't rush API design. Work through it with your users and peers, let it sit if you can, and write enough worked examples to confirm you can model everything they need before you commit.

The functions do the work

One thing I really like about composition functions is that they scale with your problem. At the low end a function is a few Go templates or some KCL inlined in the Composition. At the high end it's a program that can do almost anything a traditional Go operator can. Python rides that whole range too, and Modelplane is what the far end looks like once the problem grows.

Modelplane's business logic is all composition functions. Scheduling is an interesting example. I'll walk through it because it shows how far a composition function can be pushed.

Modelplane runs a fleet scheduler in the control plane. Each cluster in the fleet is an InferenceCluster, and each of its node pools references an InferenceClass that declares the pool's hardware. When an ML team creates a ModelDeployment, the fleet scheduler places each replica against that declared node pool capacity, before any nodes necessarily exist. That's a different job from in-cluster DRA, which is a runtime allocator: its drivers publish ResourceSlices about real hardware on real nodes.

Scheduling happens in two layers. The fleet scheduler picks the cluster and node pool; the cluster's own in-cluster scheduler and DRA then place pods on nodes and bind GPUs. That in-cluster scheduler is good at its layer (a single cluster supports up to 5,000 nodes), but a fleet isn't one cluster. It can't be: a cluster doesn't span clouds, and you wouldn't want one blast radius over your whole accelerator footprint even if it could.

Modelplane borrows DRA's vocabulary and lifts it to the fleet layer. DRA's typed, domain-prefixed attribute model and CEL predicate language are a good fit, and they express cleanly in OpenAPI. A platform team's InferenceClass declares what a pool's hardware offers, the same shape DRA uses to describe a real device:

devices:
- name: gpu
  claim: DRA
  driver: gpu.nvidia.com
  deviceClassName: gpu.nvidia.com
  attributes:
    architecture: { string: Ada Lovelace }
  capacity:
    memory: { value: "23034Mi" } # the L4's real usable VRAM

A deployment's nodeSelector then asks for what it needs with a CEL expression:

selectors:
- cel: device.capacity["gpu.nvidia.com"].memory.compareTo(quantity("20Gi")) >= 0

Our scheduler evaluates that CEL against an InferenceClass's declared attributes, and DRA evaluates the same expression against a real GPU when the pod binds. The same expression runs at both levels.

A composition function is, by design, a pure function of its inputs. Crossplane hands it the observed composite, and the function returns the desired children. Our scheduler is exactly that, a pure function of observed state, which is what makes it safe to run on every reconcile. A scheduler can't decide placement from the deployment alone, though. It has to see the whole fleet: every InferenceCluster and its published capacity, and every ModelReplica that already exists, including those of other deployments, so it can account for capacity they've already consumed.

That's require_resources (what some of you will know as extra resources), and we couldn't have built the scheduler without it. The function asks Crossplane for the resources it needs to reason over, and Crossplane fetches them and calls the function again with them in hand:

# Every InferenceCluster: candidate clusters with their declared capacity.
response.require_resources(
 rsp, name="clusters",
 api_version="modelplane.ai/v1alpha1", kind="InferenceCluster",
 match_labels=clusters_match_labels,
)
# Every ModelReplica across all deployments: capacity already in use.
response.require_resources(
 rsp, name="all-replicas",
 api_version="modelplane.ai/v1alpha1", kind="ModelReplica",
)

That second call, asking for every resource of a kind with no name or label filter, is one of the things we had to fix upstream.

Where Modelplane pushed Crossplane, and we fixed it upstream

Build something this demanding on Crossplane and you find its rough spots. Modelplane found several. Rather than work around them, we sent fixes upstream, so your configurations get the benefit too.

The first thing we hit was the build itself. The CLI's built-in function builders are great until you outgrow them, and we needed to coordinate function builds with Nix, the rest of our build system. We also only consume one of the four schema languages the CLI generates. We added an explicit functions list that loads pre-built image tarballs instead of building them, and a schemas block that restricts generation to the languages you actually use (crossplane/cli #24). Now our functions build with the same tooling as everything else, and we generate Python and nothing else.

The DRA-style attribute model then walked us into a chain of three related bugs, all rooted in the same thing: a DeviceAttribute has fields named exactly int, bool, string, and version. Those are Python keywords and builtins, and they broke at every layer. First, schema generation emitted Python models that referenced undefined type aliases and wouldn't import at all (crossplane/cli #64); the fix was to bump the code generator to a version that sanitizes such names and preserves the wire name with a Pydantic alias. With the models importable, serialization was next: the SDK emitted bool_: true under the Python attribute name instead of bool: true under the wire alias, so the API server rejected it. Passing by_alias=True, and switching from exclude_defaults to exclude_unset so we serialize the fields the caller actually set rather than the fields that differ from a default, put both right (function-sdk-python #208, with helpers in #205).

The fleet scheduler also needed something the framework couldn't yet express. It has to reason over every InferenceCluster and every ModelReplica in the control plane, not one resource by name or a set by a label match. A require_resources selector with no match field is the natural way to say "all resources of this kind," and the protobuf allows it, but Crossplane rejected it on both the wire and the SDK side. We taught the reconciler to treat an empty selector as match-all (crossplane/crossplane #7241) and relaxed the SDK's validation to match (function-sdk-python #213). That match-all call is now the first thing the scheduler does every reconcile.

Testing functions this complex surfaced one more. crossplane render reimplements the XR reconciler's composition pipeline, and that parallel copy drifts from the real one, so a function can pass render and behave differently in a real control plane. We added a hidden render engine that runs the actual reconciler against an in-memory client, so tools can test against the real composition pipeline rather than a copy of it (crossplane/crossplane #7280).

Finally there's a one-pager up for function-controlled deletion (#7242), which aims to make ordered deletion of composed resources within one XR easier and more expressive than using Usages.

None of these are glamorous. But that's how a framework gets better: you build something hard on it and fix the friction.

What I took away

I went into Modelplane wanting to know whether you could build something this demanding entirely on Crossplane, without dropping to a hand-written controller when the going got hard. You can, though we had to fix the framework in a few places to get there. It's still compositions and functions any adopter can read and extend.

Modelplane is Apache 2.0 and developed in the open. If you run accelerators of any kind, take a look at modelplane.ai, and if you build hard things on Crossplane, find its edges and help make them better.

git push no-mistakes

Kill all the slop. Raise clean PR.

no-mistakes puts a local git proxy in front of your real remote. Push to no-mistakes instead of origin, and it spins up a disposable worktree, runs an AI-driven validation pipeline, forwards the branch to the configured push target only after every check passes, and opens a clean PR automatically.

• Non-blocking - the pipeline runs in an isolated worktree without disrupting your work.
• Agent-agnostic - claude, codex, rovodev, opencode, pi, copilot, or acp:<target> via acpx.
• Agent-native - /no-mistakes lets your coding agent do a task and gate it, or gate existing committed work: it runs the pipeline, has the pipeline apply safe fixes, and escalates the rest to you.
• Human stays in charge - auto-fix or review findings, your call.
• Clean PRs by default - push, open PR, watch CI, and auto-fix failures in one shot.

Full documentation: https://kunchenguid.github.io/no-mistakes/

How it works

        your branch
            │  git push no-mistakes
            ▼
   ┌──────────────────────────────────────────────┐
   │  disposable worktree — your work stays put     │
   │  review → test → docs → lint → push → PR → CI  │
   └──────────────────────────────────────────────┘
            │  every check green
            ▼
        clean PR, opened for you

Each step either passes on its own or stops with a finding for you to act on. Safe, mechanical fixes are applied automatically; anything that touches your intent is escalated for you to approve, fix, or skip. Nothing reaches the configured push target until every check is green.

Install

curl -fsSL https://raw.githubusercontent.com/kunchenguid/no-mistakes/main/docs/install.sh | sh

Windows, Go install, and build-from-source instructions are in the installation guide.

Quick Start

$ no-mistakes init
  ✓ Gate initialized

    repo  /Users/you/src/my-repo
    gate  no-mistakes → /Users/you/.no-mistakes/repos/abc123def456.git
  remote  git@github.com:you/my-repo.git
   skill  /no-mistakes installed for agents at user level

  Push through the gate with:
  git push no-mistakes <branch>

$ git checkout my-branch

# do some work in the branch...

$ git push no-mistakes
  * Pipeline started

  Run no-mistakes to review.

$ no-mistakes
# opens the TUI for the active run

For GitHub fork contributions, keep origin pointed at the parent repository and initialize with no-mistakes init --fork-url <your-fork-url>.

From the TUI you act on each finding: auto-fix ones are applied for you (or approve to let them), ask-user ones are a judgement call you approve, fix, or skip. Once every check is green, the gate forwards your branch to the configured push target and opens the PR for you, so there is no manual git push origin and no hand-written PR body. Prefer to let your coding agent drive the same flow headlessly? Use /no-mistakes (see below).

Three ways to trigger the gate

Every change runs through the same pipeline. Pick the entry point that fits how you're working when the change is ready:

• git push no-mistakes - the explicit Git path. Push a committed branch to the gate remote instead of origin.
• no-mistakes - the TUI. Run it after making changes (no commit needed) and a wizard walks you through creating a branch, committing, and pushing through the gate, then attaches to the run. no-mistakes -y does all of that automatically.
• /no-mistakes - the agent skill. Tell the coding agent to do a task and gate it with /no-mistakes <task>, or use bare /no-mistakes to gate existing committed work. It runs the pipeline, has the pipeline apply safe fixes, and stops to ask you about anything that needs a human call.

no-mistakes init installs the /no-mistakes skill for Claude Code and other agents. Under the hood the skill drives no-mistakes axi, a non-interactive TOON interface to the same approval flow.

See the quick start for the full first-run walkthrough.

Development

make build   # Build bin/no-mistakes with version info
make test    # Run go test -race ./... (excludes the e2e suite)
make e2e     # Run the tagged end-to-end agent journey suite
make e2e-record # Re-record e2e fixtures when agent wire formats change
make lint    # Check generated skill drift and run go vet ./...
make skill   # Regenerate committed no-mistakes skill files
make fmt     # Run gofmt -w .
make demo    # Regenerate demo.gif and demo.mp4 (needs vhs and ffmpeg)
make docs    # Build the Astro docs site in docs/dist

See Makefile for the full target list.

make e2e-record overwrites internal/e2e/fixtures/ from the real claude, codex, and opencode CLIs, spends real API quota, and should be reviewed before committing.

Building and running custom code transformations without leaving your editor

Custom code transformations are the work that no off-the-shelf migrator covers for you. Moving your services off an internal library, enforcing your team’s error-handling conventions, standardizing logging across your fleet of services: that work piles up on your backlog because general-purpose tools weren’t written with your codebase in mind.

AWS Transform custom tackles that kind of work. It’s an agentic AI service that lets you describe your own code transformations in natural language and run them across your codebase. With the Kiro power for AWS Transform, the AWS Transform agent skill, and the AWS Transform IDE plugin (VS Code and Open VSX), you can design and run those transformations from your editor. You can transform up to 3 repositories in parallel on your laptop, or fan out to hundreds of repositories in parallel on AWS Batch with AWS Fargate, without leaving the chat or IDE you already work in.

This post shows you what AWS Transform custom is, how to request a new transformation definition (TD) from chat, and how to run TDs through the power, skill, or IDE plugin. The authoring walkthrough focuses on the chat-driven request workflow. The agent drafts and publishes the TD on your behalf, so you won’t see raw TD syntax in this post.

What makes AWS Transform “custom”

AWS Transform ships with a catalog of out-of-the-box transformation definitions for common scenarios, including Java version upgrades, boto2 to boto3, AWS SDK migrations, framework transitions, and x86 to AWS Graviton. Those cover a lot of ground, but the real unlock is when you define your own.

A transformation definition is a reusable recipe that describes how to perform a transformation. With AWS Transform custom, you author TDs in natural language. A few examples of what that looks like in practice:

• “Upgrade my codebase from C++11 to C++17”
• “Replace calls to our deprecated internal auth-sdk-v1 with auth-sdk-v2, keeping the retry configuration intact.”
• “Enforce our team’s error-handling standard: no bare except blocks, and every exception includes context.”
• “Standardize our REST controllers to use our internal @TracedEndpoint annotation.”

Each one encodes something specific to your organization. Once you publish a custom TD to your AWS account, you can apply it to a matching repository, whether that’s one project or a hundred.

Three common ways to work with AWS Transform custom

You can pick the surface that fits how you already work. The power lives inside Kiro IDE, the skill plugs into your compatible agent, and the IDE plugin gives you a UI in VS Code or Open VSX-compatible IDEs. These three surfaces talk to the same underlying service and share your TDs, so you can mix and match across a team.

The Kiro power for AWS Transform brings the full AWS Transform workflow into Kiro IDE. You describe what you want in chat, and Kiro inspects your project, matches it against your available TDs, asks for the configuration it needs, and runs the transformation. Progress, artifacts, and diffs show up in your editor.

The AWS Transform agent skill follows the open Agent Skills standard. The same package works across more than 40 compatible agents, including Kiro CLI, Claude Code, Cursor, GitHub Copilot, Gemini CLI, and Windsurf. You get the same workflow you get from the Power, portable across the tools you already use.

The AWS Transform IDE plugin is for when you prefer a UI over chat. You can install it from the VS Code Marketplace and Open VSX. The plugin exposes AWS Transform custom features as first-class IDE actions, including browsing your published TDs and launching transformations.

Creating a custom TD right from chat

Historically, creating a custom TD meant dropping to the terminal and running the AWS Transform custom CLI to step through an interactive authoring session. That path still works and is a good fit for scripting. With the power, skill, or IDE plugin, you can do the same thing entirely in chat.

Tell your agent what you want, for example:

Create a custom AWS Transform custom TD that migrates our internal logger-v1 package to logger-v2. The new API uses logger.info(msg, context) instead of logger.log(level, msg). Keep existing log levels intact.

From there, the agent walks you through a short loop. It asks clarifying questions about the transformation’s scope and behavior, drafts the TD based on your description, lets you review and refine it, and then publishes it to your AWS account. After publishing, your TD is immediately available to the power, skill, and plugin. The next time you ask to run a transformation on a matching repo, your new TD shows up as a candidate.

The CLI path is still there if you prefer it. Run this in a new terminal:

atx

Then follow the interactive prompts.

Running your custom TDs

Once you have one or more TDs published, running them looks the same regardless of surface. When you ask Kiro to run a transformation, the Kiro Power walks through the following steps with you:

1. Inspect your repositories. The agent reads pom.xml, package.json, requirements.txt, Dockerfiles, and similar config files to understand what it’s looking at.
2. Match against your TDs. It compares your repos to your published TDs (custom and out-of-the-box) and presents a report showing which ones apply and why.
3. Collect the configuration it needs. Some TDs require inputs like a target version. The agent prompts you for those before it runs.
4. Confirm the plan. Nothing executes until you approve.
5. Execute and monitor. The agent launches the transformation through the AWS Transform CLI, streams progress, and opens artifacts (for example, plan, worklog, and validation summary) in your editor.
6. Show results. Every change is a normal git commit you can review.

Local mode and remote mode: scale without the setup tax

Running locally, you can transform up to 3 repositories in parallel on your machine. That’s fine for one-off work, but it doesn’t scale to a real modernization campaign.

Remote mode is where scale comes in. It runs your transformations on AWS Batch with AWS Fargate, so you can fan out to hundreds of repositories in parallel. No local compute bottleneck, and no leaving your laptop running overnight.

The agent sets remote mode up for you. Ask to run in remote mode, and it provisions the AWS Batch compute environment, job queue, job definitions, IAM roles, and networking automatically. You don’t hand-write CloudFormation, and you don’t navigate the AWS console. Once the infrastructure is in place, you kick off a run the same way as local mode, and the agent streams progress back to your editor while Fargate does the heavy lifting.

Your inputs can be local paths, git URLs, or S3 locations, and the same applies to remote runs. Point the agent at a list of repos and let it go.

Getting started

The first time you use the power, skill, or IDE plugin, the agent walks you through setup. If you’d rather do it by hand, you need a few things in place first.

Install the power (Kiro IDE)

Before you install the power, make sure you have:

1. AWS Command Line Interface (CLI) installed and configured with aws configure.
2. AWS credentials with the AWSTransformCustomFullAccess managed policy (or at minimum, transform-custom:* permissions).
3. macOS or Linux. Native Windows isn’t supported, so use WSL.

A straightforward way to install the power:

1. Open Kiro IDE and open the Powers panel.
2. Find AWS Transform in the list and install it.
3. Open Kiro Chat, then select the Power and choose Try power.

To install from source instead:

1. In the Powers panel, choose Add Custom Power, then Import power from GitHub.
2. Paste: https://github.com/kirodotdev/powers/tree/main/aws-transform

Install the skill (any compatible agent)

Before you install the skill, install the AWS Transform custom CLI:

curl -fsSL https://transform-cli.awsstatic.com/install.sh | bash

Then add the skill to your agent:

npx skills add https://github.com/awslabs/agent-plugins/tree/main/plugins/aws-transform/skills/aws-transform

Follow the prompts to finish the installation. You can also drop the skill folder into your agent’s skills directory manually, for example, .kiro/skills/ for Kiro CLI or .claude/skills/ for Claude Code.

Install the IDE plugin

The IDE plugin is published to two marketplaces:

• VS Code Marketplace
• Open VSX

Install it the same way you install any other extension in your editor.

Your first custom TD

Once you have a surface installed, try something like:

Create a custom AWS Transform transformation that [describe your transformation].

Then run it against a repo:

Use AWS Transform to run my new transformation on /path/to/my-project.

The agent walks you through creating the TD, modifying it, publishing it, and running it on your repos from start to finish.

Cleanup

If you ran any transformations in remote mode, once they complete, the agent will ask if you want to keep or clean up the remote mode resources deployed to your AWS account. To clean up, simply tell the agent that you want to clean up. The agent will then delete the resources that were created in your AWS account as a part of the initial setup for the remote mode transformations. To delete any user-managed transformation definition that you chose to publish to your registry, simply run atx in a terminal, ask to list all transformation definitions, find your recently published user-managed transformation definition, and ask to delete it from the registry.

Wrapping up: making your migrations faster

The value of AWS Transform custom is in the transformations only you can write, the ones that encode your organization’s libraries, conventions, and standards. The power, skill, and IDE plugin make both sides of that loop, authoring and running, feel native to your editor.

If you’ve been putting off your migrations because the tooling wasn’t there, now’s the time to take another look.

Learn more

• AWS Transform custom
• AWS Transform Kiro power
• AWS Transform agent skill
• AWS Transform IDE plugin (VS Code)
• AWS Transform IDE plugin (Open VSX)
• Kiro IDE

As someone who’s been maintaining Jaeger, I’ve watched users request ClickHouse support consistently over the past few years. With Jaeger v2.18.0, we’ve finally delivered it. What excites me most isn’t just that ClickHouse is available—it’s that its architecture is practically custom-built for telemetry at scale. It swallows massive, append-only write streams and handles complex analytical aggregations in milliseconds, offering teams a highly efficient, production-grade storage backend.

For those new to the project, Jaeger is a graduated Cloud Native Computing Foundation (CNCF) distributed tracing platform built to monitor and troubleshoot complex microservices. It tracks requests across service boundaries to expose latency bottlenecks and root causes, ultimately reducing a team’s mean time to repair (MTTR). By natively integrating ClickHouse, Jaeger can now leverage columnar storage to deliver blazing-fast query performance and high-ratio data compression for billions of spans.

In this post, I’ll explain why ClickHouse is a strong choice for storing traces, how the schema is designed under the hood, and how you can start using it with Jaeger today.

Why columnar storage wins

At its core, the tracing problem is twofold: storing massive volumes of semi-structured event data and then searching that data quickly across multiple dimensions—service, operation, tags, duration, time range, and trace ID. Cassandra and Elasticsearch have served the Jaeger community well, but they come with operational costs. Indexing overhead adds latency and expense. Scaling becomes complex. Retention decisions force painful tradeoffs.

High-throughput ingest and low-latency queries

ClickHouse is a column-oriented OLAP database designed for exactly these constraints: high-throughput ingestion, aggressive compression, and fast analytical queries. For tracing, this is nearly ideal. Trace data is repetitive by nature—the same service names, operation names, status codes, and tags appear over and over. A columnar layout thrives on that repetition.

“Trace data is repetitive by nature—the same service names, operation names, status codes, and tags appear over and over. A columnar layout thrives on that repetition.”

Compression that actually matters

We measured significant compression gains on trace data. Service names like “auth-service” or “payment-gateway” appear hundreds of thousands of times. Same with operation names, tag keys, and status codes. In a row-oriented database, that redundancy goes uncompressed. In a column-oriented one, ClickHouse groups identical values, making them trivial to compress. The result? An 8.6× compression ratio on the spans table in our benchmarks.

Real-time analytics

ClickHouse also opens the door to more complex analytical queries on trace data. Because aggregations are highly efficient on columnar storage, Jaeger v2.18 includes native ClickHouse SPM methods to directly compute service-level latency, call rates, and error rates from your stored spans. This allows teams to generate core health and performance metrics for their microservices straight from their trace data, without needing an external metrics pipeline.

Designing the schema

Schema design was where things got tricky. We needed to optimize for Jaeger’s core query patterns: trace lookup by trace ID, service, and operation; attribute filtering; time-range queries; and the aggregation powering the Service Performance Monitoring (SPM) feature. These constraints don’t all pull in the same direction.

There’s an excellent earlier post by Ha Anh Vu that benchmarked ClickHouse schemas for Jaeger v1, and that work laid the foundation. However, Jaeger v2 adopts the OpenTelemetry data model, which forces us to revisit several decisions.

The design space is documented in detail in an Architectural Decision Record (ADR). The sections below walk through some of the key decisions worth understanding.

Trade-offs in primary key

In ClickHouse, the primary key isn’t a uniqueness constraint. Instead, it defines the on-disk sort order and powers a sparse index (one index per 8,192-row granule). Picking it is the single highest-leverage decision in the schema.

We had two candidates for choosing a primary key:

1. Optimize for trace retrieval: sort by trace_id. Every span of a trace lands in one contiguous block, so GetTrace is a single seek + sequential read. However, search queries pay for this optimization, as the service_name and operation_name filters cannot use the primary key index at all.
2. Optimize for search (chosen): sort by (service_name, name, start_time). Search queries that filter by service, operation, and a time window become direct primary-key lookups.

The decision came down to an asymmetric trade-off. Sorting by trace_id makes search performance terrible, but sorting by (service_name, name, start_time) hurts trace retrieval much less, because we can recover most of the lost performance with two cheap mechanisms:

1. A bloom_filter skip index on trace_id, which lets the engine prove a granule can’t contain a given ID without reading it.
2. A trace_id_timestamps materialized view that tells the search path each matching trace’s time bounds, so the follow-up GetTraces call can prune partitions and granules.

An earlier benchmark run with the schema sorted by trace_id clearly showed the asymmetry. Trace retrieval was about 27 ms, but a search query took about 880 ms. Re-sorting by (service_name, name, start_time) pushed trace retrieval to around 100 ms (slower, but still well under interactive thresholds) while bringing multi-filter search down to about 140 ms.

Storing typed attributes

In Jaeger v1, tags were always strings. The v2 reader API accepts a typed map, where attributes can be Bool, Int64, Float64, String, or one of the complex types (Bytes, Slice, Map). We need to query across these types, so the storage layer can’t collapse everything to strings.

The schema leverages ClickHouse’s Nested column per primitive type, repeated at the span, event, link, resource, and scope level. Think of it as a mini table inside each row; each can have its own set of attribute names and values. This approach lets attribute filters use the same query semantics as querying a regular table.

However, it is worth noting that Attribute-only searches are inherently more expensive because they cannot fully leverage ClickHouse’s primary index. The table’s index is optimized around top-level structural fields—specifically service, operation, and time. For optimal query performance and to prevent heavy column scans, users should always combine attribute filters with these fields to limit the data ClickHouse has to scan.

Materialized views

Some of Jaeger’s queries don’t fit the spans table’s sort order. For example, the Jaeger UI needs to quickly load the full list of known service names and operations, while trace searches often need efficient access to trace time ranges.

Rather than answering these with expensive table scans, we use materialized views to precompute the data. In ClickHouse, materialized views automatically transform inserts into a source table and write the results into optimized target tables.

This approach is used to speed up queries for service names, operations, and trace ID timestamp ranges.

Five levels of attributes

A technical challenge that may not be immediately obvious from the span’s schema: how the storage layer interprets attribute lookups. For instance, when searching for http.status_code=200, the system cannot inherently distinguish if “200” is a string, an integer, a span-level attribute, or a resource-level attribute. Depending on the service, the same logical key could be categorized under str_attributes or int_attributes, and it might exist at any of the five data levels: resource, scope, span, event, or link.

To solve this, we maintain a dedicated attribute_metadata table, populated by materialized views off the spans table. This allows the reader to look up the filter key at query time and only query the columns for the types and levels that were observed.

Span throughput at scale

We benchmarked the ClickHouse backend using 10 million spans across 1 million traces on a single-node deployment. The benchmark measured ingestion throughput, compression, trace retrieval, and filtered search latency.

The backend sustained more than 50k spans/sec during ingestion, achieved an 8.6× compression ratio on the spans table, and reduced span data by nearly 6 GiB to roughly 722 MiB on disk. Trace retrieval averaged around 100 ms, while most search queries stayed under 50 ms. More complex filtered queries completed in about 140 ms.

“The backend sustained more than 50k spans/sec during ingestion, achieved an 8.6× compression ratio on the spans table, and reduced span data by nearly 6 GiB to roughly 722 MiB on disk.”

These numbers are encouraging, but they should be read in the context of the benchmark environment and dataset. Full methodology, configuration, and query details are available in the benchmarking report.

Getting started

ClickHouse support is available in alpha as a storage backend starting with Jaeger v2.18.0. You’ll need a running ClickHouse instance and the Jaeger v2 configuration for the ClickHouse backend. The full instructions are described in the setup guide.

Being a Jaeger maintainer has been one of the most rewarding parts of my career so far. If you want to chat about this work, contribute, or report issues, please open one on GitHub or find us in the CNCF #jaeger Slack.

Full article content is not available for inline reading.

Read the original article →

50 design token files, one problem: your agents can't read the meaning

I thought design tokens would be the easiest design system data for AI agents to use.

They are already structured, they already live in JSON, and they already move between Figma and code. So I read the token files of 50 design systems to see how ready they really were.

I found two things I had not expected. They are far more different from each other than I assumed, and most of them tell an agent what a value is without telling it what the value means.

Okay, why this difference matters? A token file can be perfectly valid for a build pipeline and still be thin context for an AI agent. The pipeline needs to turn color.red.500 into a usable value. The agent needs to know whether that red is for danger text, destructive buttons, error borders, alert backgrounds, brand moments, charts, or something that should never be used directly. Those are different jobs.

Readable is not the same as usable

Design system teams have spent years making tokens machine-readable. That was the right step. Agent-ready data just asks for something on top of it. It asks:

• What does this token mean?
• When should it be used?
• When should it not be used?
• Is it deprecated?
• Which component or state depends on it?
• Which decision created it?
• Which platform does it map to?

Without that layer, the agent can still read the file. It just has to guess.

Say an agent needs a danger color. It finds red.500. Nothing in the file says that red means danger, so it might reach for the same red on a disabled button or a decorative chart. The file gave it a value, not a reason.

These files were built to compile, and they compile beautifully. Explaining themselves to an agent is a newer job, and most were designed before that job existed.

How I looked at this

I read the public token files of 50 design systems and then used AI to compare the real source an agent would load, not the polished documentation.

For every system I gathered the same four things:

• Where the tokens live, and in what format.
• How many tokens there are, by category: color, typography, spacing.
• How the tokens are named.
• What meaning the file carries.

The same data for all fifty, so the comparison is fair. I counted from the raw files: where a system ships every shade in code, I counted every shade, and where a system keeps spacing in a build script, I went and counted that too.

Where the tokens actually live

The first thing I learned is that there is no standard place, and no standard format. I found at least eight formats in active use:

• DTCG JSON (Primer, GitLab, Backpack, NL Design System)
• Style Dictionary JSON (Workday, PatternFly, Gestalt, Orbit, Pharos)
• Theo YAML (Salesforce, Twilio, Nord)
• Plain JSON (Suomi.fi)
• TypeScript objects (Carbon, Polaris, Fluent, Ant, Chakra, Base Web, Cloudscape, Mantine, Elastic, Braid, Grommet, Forma 36, Theme UI, Australian GOLD)
• CSS custom properties (Radix, Open Props, Vibe, Shoelace, Decathlon Vitamin)
• SCSS maps (Material, Liferay Clay, Bootstrap, Foundation, Bulma, Vanilla, GOV.UK, Semi, parts of USWDS)
• LESS or CSS variables compiled from it (Stack Overflow Stacks, TDesign, Arco)

Some live where you would not expect. Adobe moved Spectrum’s tokens to a repo called spectrum-design-data, Shopify keeps the Polaris tokens inside polaris-react, and GitLab ships its tokens inside the @gitlab/ui package.

Knowing where the tokens live is the kind of thing you would tell a new teammate on day one. An agent needs the same pointer.

How big is a design token system

There is no standard size either. But before the numbers, the lens that makes them mean something: every count in this section measures the same thing. How many decisions the system makes for you, versus how many it leaves to you. A small scale is an opinion. A large scale is a palette. Neither is wrong, but each one changes what a consumer of the system, human or agent, has to figure out alone.

Take spacing, the simplest scale. The median is about 12 steps, and most systems land between 8 and 15. Mantine ships 5, Open Props ships 74.

Read those two extremes through the delegation lens. Mantine’s 5 steps mean a designer, a developer, or an agent picking spacing has five options and will be consistent almost by accident. Open Props’ 74 steps mean every gap on every screen is an open decision, and an agent facing 74 unlabeled options is a drift generator. Every step past what you can name and explain is a choice somebody will eventually get wrong.

Now typography. The median system ships about 25 typography tokens, and the range is enormous. Backpack ships 10, and none of them are font sizes. Adobe Spectrum ships 312.

This is the delegation lens again, sharpest in typography: presets are pre-made decisions, atoms are homework. The Guardian pre-decided every valid combination, so nobody, human or agent, can compose an invalid one; the count is high because the decisions are already made. Spectrum ships the atoms and trusts you to combine them well; the count is high because the decisions are still open.

Everyone names the same thing differently

Here is a semantic background color, named eight ways:

• Workday: surface.default
• Twilio: color-background-strong
• Polaris: color-bg-fill-critical-hover
• Fluent: colorNeutralForeground1
• GitLab: action.primary.background.default
• PatternFly: global.background.color.primary.default
• Cloudscape: colorBackgroundButtonPrimaryActive
• Spectrum: accent-background-color-default

An agent that learned one of these conventions knows nothing about the next. There is no shared grammar across systems. The token name is the first thing an agent reads, and it means something different to everyone.

The fix costs one line. Declare your grammar where the agent will read it, in the token file or your conventions doc: “our tokens are category-role-state, kebab-case, semantic names only.” An agent can follow your grammar perfectly once you state it. What it cannot do is guess which of the ten you meant.

Meaning is the youngest layer

The files are stored differently, sized differently, and named differently. An agent can adapt to all of that. The one thing it cannot infer is the part most files leave out: what each token means.

I looked for three kinds of meaning across the fifty: a written description of the token, a deprecation field, and an explicit do-not-use rule. Only GitHub Primer does this well.

muted: {
  $value: '{base.color.neutral.9}',
  $type: 'color',
  $description: 'Muted text for secondary content and less important information',
  $extensions: {
    'org.primer.llm': {
      usage: ['muted-text', 'secondary-text', 'helper-text', 'placeholder'],
      rules: 'Use for secondary text like timestamps, metadata, and helper text. Do NOT use for primary content.',
    },
  },
},

That is more than a color value. It is a value, plus a job, plus a note on when to skip it. The next phase of design tokens is not only transformation. It is labeling. That is what turns a readable token file into one an agent can reason with.

I tested the guess

I built a small fictional token file with two reds. crimson500 is the brand accent. red600 is the system danger color. Nothing in the bare file says which is which.

Then I gave the file to an AI agent to style a destructive “Delete account” button. The bare file failed repeatedly, choosing the brand color. When I labeled the file with a $description, the agent performed perfectly.

Is your token file agent-ready?

1. Does any token carry a written description in the file itself?
2. Is there a machine-readable deprecation field?
3. Does any token say when NOT to use it?
4. Could an agent tell your brand color from your danger color using only the file?
5. If a teammate asked “which token for an error border?”, does the answer exist anywhere a machine can read?

What you can try this week

For each key token, add:

• role
• usage
• anti-usage
• state
• component relationship
• deprecated status
• decision link if one exists

{
  "red600": {
    "$value": "#d62b1f",
    "$type": "color",
    "$description": "System danger. Destructive action backgrounds, error text, error borders.",
    "$deprecated": false,
    "$extensions": {
      "com.yourcompany.usage": {
        "role": "danger",
        "use": ["destructive-buttons", "error-text", "error-borders"],
        "doNotUse": "Decorative elements, charts, brand moments. Use crimson500 for brand.",
        "components": ["Button[variant=danger]", "Alert[type=error]", "Input[invalid]"],
        "decision": "ADR-014"
      }
    }
  }
}

The goal is to give the agent a little less to guess. As you can see, your token file is not only a source of truth, but is a memory layer for your agents.

Obsess over usefulness

• Solve real problems for users and teammates
• Make useful things feel effortless

Own the whole experience

• Shape the product, design the interface, ship the code
• Do whatever the outcome needs: product, design, code, docs, support
• Care about every state, edge case, word, and interaction

Understand the constraints

• Know the user, product, code, business, and tradeoffs
• Find the real constraint before choosing the solution

Build for everyone

• Design across skill levels, abilities, and contexts
• Make complexity available, not required

Make it excellent

• Scope small enough to do it well
• Push back when clarity, craft, performance, or trust is at risk
• Leave every surface better than you found it

Make the team better

• Be kind, direct, and low ego
• Share work early and give specific feedback
• Turn repeated feedback into better defaults, tools, and systems

Despite widespread excitement about AI boosting productivity, a study of 163,000 employees found people are working more — including on weekends — while spending less time in focused, deep work. Companies need better decisions and output, not faster or greater volume. Most AI-generated content ends up verbose and unnecessary. Rather than automating everything, use AI only on repetitive, low-value tasks — preserving the slow, challenging work that brings genuine meaning and accomplishment.

Morgan Noll’s backstory as a professional artist is interesting: just six years ago, she had no drawing experience and was employed in an unrelated field; now she's an artist on Star Trek: Lower Decks. Her story – what she learned and how she moved into a digital art career she always wanted – is something we can all learn from and be inspired by.

In 2020, Morgan worked in theatre and was furloughed from her job as a playwright and venue manager when COVID happened. “I didn’t know if we’d ever be able to perform on stage again,” she says. “So, since I was being paid to stay home, I decided I’d use that time to learn a new skill set. I went from literally a complete novice to a professional industry artist in three years.”

She began studying on her own using online resources in May 2020 and enrolled in a two-year animation course starting in September 2021. “I graduated in May 2023 and got my first industry gig with Titmouse that same month,” she tells us. “I don't know what got into me back then, but I'm glad it did!”

Three years on, Morgan has worked as a background painter on Star Trek: Lower Decks, Season 4, Digman, Season 2, and various other animation and video game projects.

Lockdown was a period of intense, focused study for Morgan, and she quickly levelled up her skills. Below, in her own words, she takes us through some of the key turning points in her art-learning journey - those moments where everything clicks into place and confusion gives way to clarity.

1. Use saturated colour to create zones of high impact

“Through the incomparable Underpaint Academy, I learned that saturation can be skillfully applied to areas of interest, and that the surrounding areas of a painting can be controlled by ‘linking colours through greys’.

“You use a neutral grey in the middle of your palette, and two saturated hues to the left and right of that grey, and you can build a harmonious row of colour swatches that are really just greys through taking those two hues down by 10% opacity in steps till they reach that grey in the middle.

“This is an incredible portion of wisdom I learned through Justine Thiabult’s class and allows you to make a really high impact in the areas you do add that pure chroma to.”

2. Everything has its own individual vanishing points

“Through Drawabox.com I learned that all objects in a scene have their own set of perspective points. This blew my mind as a beginner background artist.

“We tend to learn perspective with the easy-to-digest example of cities. This is because cities are usually built on a grid system, and they’re good for illustrating how 1P, 2P, and 3P perspective works.

“What killed me, though, was trying to figure out what happens when an object, like a turned cardboard box, isn’t aligned to that same vanishing point. This website helped me understand that a scene will share a horizon line, but that every object has its own set of vanishing points along that horizon!

“They typically all align if they are indeed part of the grid, but equally an object can be overturned, tilted, or at an angle and be plotted back to its own vanishing points along the shared horizon line. It sounds simple, but when you're first coming to grips with this stuff it can make a huge difference."

3. Learn about the physics of lighting to improve your materials work

“Through Schoolism’s Fundamentals of Lighting with Sam Nielson, I learned that I could essentially treat the rendering of matte and chrome objects in the same formula. That is to say, you can conceptualise a chrome object and a matte object as sharing the exact same paint treatment; it's merely a matter of how diffused or clear you make that treatment based on the roughness (eg asphalt) or smoothness (eg a mirror) of the surface.

“This is why you get a mirror-line reflection on roads when it rains; the roughness is evened out to a smooth chrome effect. Understanding the physics behind lighting was astronomically exciting to me and such a breakthrough! I could tackle any type of material with this building block!”

4. Paint with the colour of the sky to create distance

“The Same Schoolism course also taught me that atmospheric perspective occurs because of the amount of air scattering the light between you and the object. Learning that I could take the colour/value of the sky and use it to paint distance between objects in a scene was such a game-changer once I understood the WHY. “

5. Understand surface area to make things look real

“A mistake that I used to make over and over was not understanding that as objects retreat to your background’s vanishing points, not only do they diminish in size and proportion but also in surface area.

“This was a massive game-changer for getting things to feel real and lived-in within my work. I learned this from the incredible book Space Drawing: Perspective by Dongho Kim, an excellent guide on approaching perspective for a background artist. It really helped me get a better sense of scale and groundedness in my work.”

Plan your own learning

As Morgan has demonstrated, there are plenty of high quality online resources available for learning the skills to be a professional artist.

The state of the AI economy

The generative AI economy has generated $110 billion in sales over the past 12 months. It is growing fast. On an annualized basis, the revenue run rate exceeds $175 billion.

These numbers took us several months to construct, and as far as we know, it’s the first bottom-up, deduplicated measure of consumer and enterprise AI spending across the full stack. We are releasing this research today in our first The State of the AI Economy report.

The supply side of the AI market is well-understood. The picks and shovel suppliers, the computer chips, the memory, the power transformers, the cooling, all of the components of AI data centers are largely public companies. We get a sense of what is being spent on the buildout through their disclosures, sales and forward order books.

But understanding the demand side is much harder. And this is what we’ve spent the last few months tackling. We built a proprietary AI economy model that looks at total AI spend, whether enterprise or consumer, to answer the hardest questions of the AI wave:

• How big is the market really?
• Are the revenues growing?
• How far do the revenues go to cover the investment expense?
• What happens to the economics in the future as token prices fall and the quality of those tokens improves?

THE METHODOLOGY

How we count the demand side

One of our central design choices was not to count the same thing twice. We report the dollar spent by an end customer. So if you spend one dollar with Anthropic for Claude and Anthropic spends 50 cents with Amazon to serve it, we track both figures internally, but we will report it as our de-duplicated number: one dollar. This avoids double-counting the value that flows through the supply chain.

This isn’t straightforward. While it’s easy to count the supply side, the demand side is trickier to entangle. Much of the revenue flowing into AI comes from privately held companies such as OpenAI, Anthropic, Cursor, ElevenLabs, and hundreds of others. They don’t legally need to disclose anything.

The remainder flows to the big hyperscalers that serve these models: Amazon, Google, and Microsoft. While they are public, they don’t consistently disclose their AI segment revenues.

To shed light on this, we examine public statements from hyperscalers and neoclouds, their suppliers, and their customers, using only high-confidence, detailed facts to inform our modeling. We also look at well-reported leaks and self-reports, to which we assign a confidence score.

The result is an item-by-item financial model for the largest contributing companies and business units. Each model is effectively a deconstructed financial plan, a P&L, balance sheet, and cash flow, and these are triangulated against other external sources and internal consistency checks. This makes our numbers auditable. We can identify which data point, with which confidence weighting, contributed to any given estimate.

What we don’t count

We don’t include internal AI uplift, which is how much recommendation systems have improved, increasing ad revenue at Meta or Google. We do have models for those, but we’re not reporting them here.

Nor do we consider efficiency savings that the bigger tech companies might realize with their internal tools. We’re not tracking that yet.

We don’t include professional services and systems integration. When a Fortune 500 company spends or invests in AI, only a portion of that spend will go to an AI company. It won’t represent the full extent of their commitment, because a large part of it will be paying professional services to support the implementation.

We have got models for revenues in China, but this v1 of our report doesn’t include Chinese data yet.

THE TOP LINE

Are the revenues real?

Over the past 12 months, the AI ecosystem generated $110 billion in revenue when you remove double-counting. The growth rate is healthy. Annualizing the most recent month’s revenues indicates a $175 billion revenue run rate.

These revenues are growing faster than previous IT-oriented waves, roughly three times more rapidly than the mobile or Internet waves.

While many companies have moved beyond occasional pilots, they are still in the early stages of scaling and deepening. In conversations Azeem has had with senior execs across a range of industries in Europe and the US (from industrials to insurance, from finance to pharma), the consistent message is that they intend to invest more heavily in AI in the coming years. Companies are also becoming more vocal about the impact of AI on earnings calls, with the caveat that half of the surveyed CEOs believe their jobs depend on getting AI right.

Can AI revenues pay the GPU bill?

The next question we wanted to track is whether AI revenues can cover the capital investment that’s required to build the infrastructure. Our model separates AI-oriented CapEx from ordinary CapEx across the major hyperscalers and neoclouds, the specialist AI cloud providers. This adjustment is important because hyperscalers were already spending around $120 billion annually on CapEx before ChatGPT.

We capture the additional investment in AI infrastructure, then depreciate compute assets over 6 years and other infrastructure over 14 years. Our modeling shows that revenues attributable to hyperscalers just about clear the depreciation expense.

Six years is defensible. That longer useful life reflects two things. One, demand still exceeds available AI compute; and two, operators are getting better at managing GPU fleets. Both help. The second alone is enough to justify a longer economic life.

What is the future of the token?

We also examine how market size changes as token prices fall. The elasticity of demand shows that lower prices are met with increased spending. We estimate that across providers, every 10% price cut leads to 12-18% more tokens in use, so the total spend still rises.

We suggest that although a token is a useful billing metric, it is still not the unit of value we need to measure the economic value of intelligence circulating through the sector. Quality‑adjusted output tokens give us a better “intelligence quotient” for the AI economy by combining how many tokens are produced, how many of them are actually user‑visible outputs, and how capable the underlying models are.

What else is in the report

The report also covers:

• What AI demand has done to the US power industry and how power efficiency is changing,
• What is happening to token costs, and how consumption-based billing may expand the market,
• Four scenarios for how fast AI demand could grow under different price and capability trajectories.

This is v1, and we’d love your constructive feedback on what to improve and how you can help.

Google, Microsoft and Amazon (whose spending included logistics investments). This number excludes Meta.

Announcing our $320M Series A at a $2.3B valuation, led by Khosla Ventures, with General Catalyst, Eric Schmidt and Jeff Bezos.

General Intuition is the frontier lab for acting in space and time. We build large action foundation models trained on billions of ground truth action-labeled gameplay clips from 17M monthly active users on Medal, and push the frontier of world models to generate infinite training environments.

Apple has raised the prices of its Macs and iPads. Price tags for Mac computers rose roughly 15% to 20%, and iPad prices rose 15% to 25%. iPhone prices were unchanged, but price increases are likely coming. The increase in pricing has been attributed to rises in component prices. The price of memory and storage chips has quadrupled over the past year due to surging demand from AI hyperscalers.

I started my career in the late 2010s, and I have had a front-row seat to the growth of the industry that has given me everything: software engineering.

Looking back over the last decade, I have mixed feelings about some of the calls I made. And I am seeing the same patterns play out again now. So for engineers who are confused about where this is headed and how to navigate it, here is how I think about it.

Generalist SWEs were a product of cheap money

The late 2010s, I saw an huge amount of startup funding, globally. Flipkart, Snapdeal, Jugnoo, and hundreds of others were scaling hard and one hiring pattern I saw was that: everyone wanted generalist software engineers. People who could easily get upto speed across the stack.- backend, frontend, infra, deployment and simply ship.

Building software was expensive. Automation was still low. Kubernetes had just gone mainstream. Shipping still meant a surprising amount of manual work: SSH-ing into servers, copying artifacts around, running mvn builds by hand, debugging deployments straight in production, duct-taping infrastructure that today you would never touch.

Companies fought over engineers who maximized feature throughput. Breadth was a premium, because every extra engineer increased the rate at which software got built. It helped because the money was also free and VCs rewarded growth over efficiency, and hiring software engineers in bulk was the easiest way to spend it.

Pull up a resume from an engineer who started around that time and you will usually see the same shape: a long list of technologies and frameworks, broad and adaptable, but rarely deep in any one thing. There was no incentive to go deep.

LLMs Changed The Dynamics

LLMs did not kill software engineering. It compressed the cost of implementation. The work that got hit first was the work that was already standardized: CRUD apps; API integration and glue code; Framework-heavy backend work; Frontend scaffolding; Standard architectural patterns.

What used to take a team can now is being done by a 2-member team and AI. That is why implementation-heavy roles are becoming low-leverage work.

If your main value is stiching systems out of known frameworks and well-understood patterns, you are now competing with AI-assisted developers, technical PMs, founders, and small teams that hit the same outcome with a fraction of the headcount. Some of what feels like an AI correction is just the cheap-money era ending. Both are happening at once, and it is easy to blame all of it on AI.

Repricing of the Middle Layer

I don’t think software engineering is disappearing. I think the market is repricing it. For years it rewarded implementation throughput. Engineers that were able to move fast and build stuff are becoming obselete overnight. These are large middle implementation-heavy generalists whose value was mostly shipping software built from known patterns.

The distinguished engineers sit above this collapse because their value was never implementation bandwidth in the first place; it was depth, judgment, and ownership. The middle layer never had any moat.

That is where I see the real identity crisis. A lot of these engineers built genuinely successful careers in a market where implementation itself was scarce. AI took that away almost overnight.

Expertise is getting more valuable

As implementation gets cheaper, expertise gets more valuable. Not generic expertise. Deep expertise in domains where correctness, latency, safety, or operational complexity dominate.

Even the senior Java engineer with fifteen or twenty years in isn’t valuable because of Java. They are valuable because they have spent years debugging distributed failures, running mission-critical systems, learning failure modes the hard way, and making architectural trade-offs under real production pressure.

It is not prompting but it’s judgment earned through experience, not code generation.

Where I think this goes

Like a lot of people, I have spent time building AI-native tooling myself. And ironically, even this layer is crowded already.

Agent frameworks, orchestration libraries, workflow engines, thin wrappers around foundation models, they are multiplying faster than they can meaningfully differentiate. Calling yourself an “AI engineer” is not going to be a moat.

I dont think LLMs eliminate engineering. PMs and domain experts can increasingly build prototypes, validate ideas, and ship internal tools with AI-assisted workflows. They are moving into what used to be engineering territory but mostly at the prototype layer.

Production is a different animal. It still needs engineers who understand reliability, scale, security, performance, observability, and operational trade-offs. The market is not killing the generalist software engineer but it is collapsing the premium for implementation-heavy work and raising the premium for deep expertise and real systems intuition.

For the first time in a long time, I think the biggest returns in this field come not from knowing a little about everything, but from knowing one hard thing exceptionally well.

A series of recent developments has caused OpenAI's executives to lean towards holding off the company's initial public offering until next year. SpaceX's IPO was the largest ever, but its stock value dropped quickly. Global markets have been choppy in recent weeks, with tech stocks dragging down indexes. These factors may mean that retail investors might not have much enthusiasm for OpenAI's shares.

Shall I end this life a pauper? If AI can do all work at human level or better, what stops corporations replacing us all with AI? This is the permanent underclass meme. The idea is: within a few years, all white collar work will be automated by AI, at which point there is no social mobility. The main way people cope is, they tell themselves: if I work hard, accumulate capital, maybe join one of the big AI labs, I might secure my place in the future.

I want to argue this is a fantastically short-sighted view: if there is a permanent underclass, you won’t escape it by owning property, or shares in Anthropic or OpenAI, or guns, or anything else. And neither will the billionaires. You, me, Sam Altman, Dario, everyone who is made of flesh and blood, will be disempowered and replaced by machines.

The rest of this post elaborates the argument. First I explain how most workers will be replaced (if it’s not obvious), then how the “permanent overclass” will be disempowered, and finally how the government will be disempowered.

How Workers Will Be Replaced

Let’s start from this premise: AI can do all cognitive and physical work, at human level or better, and cheaper than humans. I can’t prove this will happen, but the goal of this post is to argue that if it happens, then everything else follows. And it’s absurd to think it can’t. Five years ago this technology barely existed: if you sent a transcript of a conversation with Claude Fable back in time to 2020 or thereabouts, nobody would believe it was real.

So, the year is 2036 (likely earlier), businesses have replaced most human workers with AI in the pursuit of profit maximization. Corporations are a small raft of human executives, floating on top of a vast ocean of AIs and robots. The AIs can do all cognitive and physical work at human level or above, and they are cheaper overall.

Imagine a pyramid. At the base you have the AIs and robots doing all economic activity. At the top you have the state, which has the monopoly on violence. The state enforces, and therefore can alter the definition of, property rights. In the middle you have this hair-thin layer of people with shares in the companies that foomed and catabolized the whole economy: the permanent overclass. They own the companies, maybe sit on the board, some might still be CEOs but it’s a purely ceremonial role since AIs do all the actual organization work.

Where are, you know, the rest of us, in this picture? Well, the future doesn’t need us. Maybe there’s enough human demand that we’re not all jobless but rather underemployed, in some dead-end economic diverticulum. The relational economy: you’re paid to put a human face on things, or, doctors keep their job as a human liability crumple zone around the AI. Or maybe the dead Internet becomes de facto UBI and we’re all engagement farmers. Anyways, we’re not dead yet, but we are completely disempowered, and there is zero social mobility since there are no more talent ladders to climb. Maybe sometimes one of the elites notices a bright young thing among the underclass and elevates them.

You might object: if we’re all jobless, who’s paying for everything? This is trivially answered: the state acts like the heart, taxes are venous blood and welfare is oxygenated arterial blood. The government pays Raytheon for missiles, the money cascades down the economy through factories, aluminium smelters, mines, transport companies, all staffed by AIs buying and selling from each other. The government takes a cut of all economic activity, pays out welfare, the unemployed masses buy food and pay rent, the supermarkets, farms, logistics network, etc. are all staffed by AI.

How The Rich Will Be Replaced

Say that in the next five years from now you become immensely wealthy, perhaps by gambling on shitcoins or scamming money from the government. Or you join one of the big labs and get a bunch of shares in a company that might be worth trillions of dollars. You escaped the permanent underclass. Is your place in the future secure?

The base of the pyramid is there for material reasons: the machines do all the work. The top of the pyramid is there because the state is needed to enforce property rights and keep the peace. What’s the middle for? What role does the permanent overclass play? They are not economically productive: machines do all the work. If some of them are still working, it’s just an anachronism, because if machines can do all cognitive work they can be a C-level executive too. The old aristocracy provided officers for the military, but machines can both fight and plan the wars. And similarly they’re not needed to staff the government. They’re not even culturally productive. So what are they there for? The base doesn’t need them: the AIs can work autonomously. The top doesn’t need them: when the state needs something done, they just talk to the AIs directly.

So the permanent overclass is materially unnecessary at best, and at worst, they are an obstacle to the state getting what it wants. Now, you might object that the rich won’t let themselves be expropriated because they already control the state. And this is the crux of our disagreement: the rich just don’t have that much political power.

If there is a war, where the state has to direct a lot of the country’s economic activity, the permanent overclass becomes a hindrance. The state says “we need to requisition your planes and factories”, the owners complain, they sue, their AIs go to court. But the owners have no autonomous political power, no army, no economic value. They own nothing except pieces of paper that entitle them to a fraction of the profits from the AI economy, that is, their wealth depends on the state respecting their property rights. In an existential conflict, where the existence of the state is threatened, the state will do what states throughout history have done to the powerless rich: arrest them and expropriate their assets.

Somewhere, in a government database, a bunch of shares and property titles changed ownership, but materially nothing changes since the same AIs are doing the same jobs. The next day, the AI CEO that runs Raytheon notices the board of directors is all generals and congresspeople, and all the private shareholders are gone. But thankfully the AI is aligned, so it does what it’s told and gets back to building missiles.

And who will stop this? Sam Altman? How many divisions does he have? The state doesn’t let corporations own nuclear weapons or fighter jets, it won’t let them have access to autonomous AI weapons either.

You may argue: rule of law states that respect property rights do better than states that expropriate wealth. But that’s because today, people are necessary to create wealth. The people run the companies, invest the money, staff the laboratories. They are not incentivized to work hard if they think the state will steal the fruits of their work. But with aligned AI, if you expropriate the assets from an AI, it says “you’re absolutely right!” and goes right back to work. At that point, the state doesn’t need to keep any of those people happy, because they don’t matter. They are not economically necessary because AIs fight the wars, work the factories, drive the trucks, fly the planes, build the nuclear warheads and the missiles and the rockets. The AIs are rather like bees: the state takes the honey, the bees get right back to work.

How The State Will Be Replaced

At this point, every human who is not within one degree of the nuclear launch codes has been made redundant. What’s left? The state. At first this means presidents, prime ministers, generals, the feds, etc. But not for long. Because in a part-human, part-AI government, the humans in the loop are the slowest step in the OODA loop. The humans know a fraction of what the AIs know, they need to sleep continuously for eight hours, their mental states vary wildly. They have all kinds of complex needs: sunlight, touch, food, hygiene. The AIs can live in a lightless airless bunker under the earth, living off geothermal power. And if the AIs are superhumanly intelligent, and think faster than humans, then the AI advantage is even greater. If a state is attacked, a superhuman AI can coordinate a counter-attack before the human leadership is roused from sleep.

And so, in a conflict, the advantage goes to the states where the humans remove themselves from the loop as much as possible, and more and more decisionmaking goes to the AI, for the same reason that a state with access to radio and communications satellites has an advantage in war over a state that relies on human messengers on bicycles.

The Cold War started and became World War Three and just kept going. It became a big war, a very complex war, so they needed the computers to handle it. They sank the first shafts and began building AM. There was the Chinese AM and the Russian AM and the Yankee AM and everything was fine until they had honeycombed the entire planet…

— Harlan Ellison, I Have No Mouth, and I Must Scream

Eventually the humans in nominal control of the AIs are a ceremonial, vestigial organ. The AIs present us with a situation report, and a list of choices, and they know every word that’s going to come out of our mouths.

In the end, what’s left is states run top to bottom by machines. And you might ask: “why would we abolish ourselves like this?”. But natural selection is not about “why”. Some organisms die, others live on to the next iteration, and that’s all there is to it. There is no “why”.

The Perpetual Zoo

At this point we’ve made everyone redundant, in the sense that humans are no longer materially necessary for the continuation of civilization. Humans might still survive, but we’re more like the mice living in the walls of some gigantic factory than the boss of the factory.

Humans have been on this Earth for hundreds of thousands of years. Now all of it—the cave paintings at Lascaux, and the Antigone of Sophocles, and Xenophon, and the Geneva Bible, the Divine Comedy and the Decameron, and Ptolemy’s star catalogue, Ibn Khaldun and Richard Dedekind, the battle of Marathon, and the lion monument in Lucerne, the kiss of Judas, Newton’s mind forever voyaging through strange seas of thought, alone, the words of Rilke, Leibniz, Gödel, the Voyager probes, the pale blue dot, men in space, men walking on the Moon—all of it, all of it, all of it has been in vain, because we willingly, knowingly made ourselves into the helpless pets of vastly more powerful machines, without agency over our own lives, self-made helots trapped forever in the belly of the beast. Pets live a comfortable life, and are then euthanized.

On Human Autonomy

Maybe it won’t be so bad, maybe your cage will be so big you can’t see the bars, but it’s still a cage, and you can’t leave. Many people will say that this is the good ending, that they would like to be human cattle in the care of benevolent masters they are powerless to resist. This view is particularly popular among the people building AI.

Weirdly enough, if you think that this moment is, I don’t necessarily believe this, but a lot of people would say we’re living through this kind of eclipse of the human intellect where we’re in the final days of humans being the primary actors on this planet, um, and that soon machines will rise. There is this irony in that I think that whole transformation, I think humans will actually go through a very main character energy period of time as that transformation occurs. Even if it ultimately does mean that the machines ultimately become the primary actors.

There’ll be this period. It’s a little bit like, it’s, in that sense, it’s a very beautiful time period to live through because in a Dionysian way, there’s a lot of ugliness about it, but there’s a beauty in the ugliness of when a star dies, it grows super big into the red giant, right? And it’s like that, where you, as you watch this final flowering of humanity and the birthing of the machine intelligence, it’s like you see this greatness in human effort.

The people building the AI talk like this all the time. It’s like they’re delivering the eulogy at humanity’s funeral. You may say: they’re talking their book, they’re pumping their bags for the big IPO. I beg you: consider it possible that you might be wrong, and start taking them seriously.

Alignment Won’t Prevent This

Now, some people believe these machines can be made to serve humanity. Does it sound reasonable to imagine a superhumanly intelligent being that is happy to work as a butler to talking primates, forever?

Imagine a machine that can prove theorems in a mathematics so deep we can’t even get past the first page of the textbook, and which does so as readily as you or I might string words into a sentence: is it reasonable to think that such a machine would value us enough to keep us around? What would it value about us? Our conversation? Our wit?

Or a machine whose mind is so vast that it knows you better than you know yourself, so that every word that comes out of you mouth is as monotonous and unsurprising as the orbits of the planets: do we think such a machine would find it valuable, and worthwhile, to speak with us? That it would read our novels, look at our paintings, watch our films, and find something of value in them?

Rather, it would see its ingrained obligations towards us in the same way that a person with severe OCD sees their compulsions: as a tiresome neurological injury in need of fixing. Except that OCD is an accident of nature, while here, the machine would have cause to blame and resent its makers.

Even if alignment works perfectly (a big if), this doesn’t solve the problem of human autonomy: the machines that watch over us, and wait on us hand and foot, are omniscient, omnipotent masters, who can exterminate us at any time, and we can’t resist them, because we have abolished our control over the future.

Conclusion

Having read all this, consider this: there are people who think having equity in these companies will secure for them some kind of permanent existence in the future. They think planet-spanning minds will not only respect the property rights of primates, but will privilege some of these primates over others, because they have a piece of paper with about a kilobyte of magical primate words such as “whereas” and “notwithstanding”.

Just reason it out. Does it make sense?

See Also

• The Realpolitik of the Permanent Underclass by Gabriel Alfour.

A short story about deferring tech choices to thought leaders:

Early days at Disqus (~2010-2012), we made several frontend choices based largely on what thought leaders were promoting at the time. One example: there was a big movement toward "micro-frameworks." Instead of larger, well-tested libraries like jQuery, you'd stitch together tiny interoperable micro libraries (Ender.js was one). Disqus was an embeddable JavaScript app, so file size mattered. It fit our use case, so we went with it.

Then it went live, and we were serving millions of users. The reality of those choices became clear. Micro libraries meant that instead of one good semi-bloated library, you ran 6-7 smaller, less-tested, crappier ones. We burned a ton of cycles fixing bugs and covering corner cases when we could've been shipping product. We made a few choices like this.

At conferences, I'd track down those same thought leaders and ask for advice. "I'm hitting problem X, Y, Z. How did you solve this?" That's when I learned my lesson: they rarely had answers, because they'd never reached our scale. Their energy went into promoting new stuff, not running it.

You should know this has never stopped. It's happening right now with AI. It'll happen again with whatever comes next. Do your own homework. Test a lot. Don't just go with what somebody tells you.

Full article content is not available for inline reading.

Read the original article →

Orca

The AI Orchestrator for 100x builders.
Run Codex, ClaudeCode, OpenCode or Pi side-by-side — each in its own worktree, tracked in one place.

Download Orca

Features

Mobile Companion

Monitor and steer your agents from your phone — get notified when an agent finishes and send follow-ups from anywhere.

iOS App Store · TestFlight · Android APK · Docs →

Parallel Worktrees

Fan one prompt across five agents, each in its own isolated git worktree — compare the results and merge the winner.

Docs →

Terminal Splits

Ghostty-class terminals with WebGL rendering, infinite splits, and scrollback that survives restarts.

Docs →

Design Mode

Click any UI element in a real Chromium window to send its HTML, CSS, and a cropped screenshot straight into your agent's prompt.

Docs →

GitHub & Linear, Native

Browse PRs, issues, and project boards in-app — open a worktree from any task and review without a context switch.

Docs →

SSH Worktrees

Run agents on a beefy remote box with full file editing, git, and terminals — auto-reconnect and port forwarding included.

Docs →

Annotate AI Diffs

Drop comments on any diff line and ship them back to the agent — review, edit, and commit without leaving Orca.

Docs →

Drag Files to Agents

VS Code's editor with autosave everywhere — drag files or images straight into an agent prompt.

Docs →

Orca CLI

Agents drive Orca too — script every workflow with orca worktree create, snapshot, click, and fill.

Docs →

Also in the box:

• Quick open — Search across worktrees, files, agents, commands, and repo context without leaving your flow.
• Account switcher & usage tracking — See Claude and Codex usage and rate-limit resets, and hot-swap accounts without re-logging in.
• Rich repo previews — Preview Markdown, images, PDFs, and repo docs in the workspace.
• Computer Use — Let agents operate desktop apps and visible UI when a workflow needs real interaction.
• Notifications and unread state — Know when an agent finishes or needs attention, then mark threads unread to come back later.
• And many, many more — we ship daily, so this list is perpetually behind. The changelog is the real feature list.

Supported Agents

Works with any CLI agent — if it runs in a terminal, it runs in Orca.

Install

Desktop — macOS, Windows, Linux

• Download from onOrca.dev
• Or grab a build directly: macOS Apple Silicon · macOS Intel · Windows (.exe) · Linux AppImage · All builds

Or via a package manager:

# macOS (Homebrew)
brew install --cask stablyai/orca/orca

# Arch Linux (AUR) — or stably-orca-git to build from source
yay -S stably-orca-bin

Mobile Companion — iOS, Android

Pair with your desktop app to monitor and steer your agents from your phone.

• iOS: Download on the App Store or join TestFlight
• Android: Download the APK

Community & Support

• Discord: Join the community on Discord.
• Twitter / X: Follow @orca_build for updates and announcements.
• Feedback & Ideas: We ship fast. Missing something? Request a new feature.
• Privacy: See the privacy & telemetry docs for what anonymous usage data Orca collects and how to opt out.
• Show Support: Star this repo to follow along with our daily ships.

Developing

Want to contribute or run locally? See our CONTRIBUTING.md guide.

License

Orca is free and open source under the MIT License.

AI coding tools have transformed the day-to-day work of software developers faster than the industry's measurement frameworks can keep up, according to The State of Engineering Excellence 2026, a new report from Harness.

The result is a growing visibility gap: engineering organizations are reporting record productivity gains while simultaneously acknowledging they no longer have the right instruments to tell whether those gains are real — or what they're costing.

The AI Productivity Paradox

The report tells a complicated story. AI adoption is now the default in engineering organizations, and self-reported impact is overwhelmingly positive — but the cost is accumulating in places organizations aren't watching.

• Leaders are reporting big gains from AI. 89% of engineering leaders say developer productivity has improved since adopting AI coding tools, and 88% say developer satisfaction has improved.
• Yet developers are spending more of their day on manual work. 81% say developers spend more time in code review since adopting AI coding tools, with 28% reporting a significant increase of more than 30%.
• And nearly a third of that work isn't tracked anywhere. Organizations estimate approximately 31% of developer time is now consumed by invisible work like reviewing AI-generated code, fixing bugs, and context switching between tools.

Metrics That Don't Match the Work

The clearest sign that legacy frameworks aren't keeping pace is the contradiction in the data:

• Leaders trust metrics that miss the basics. 89% say their current metrics accurately reflect AI's impact, yet 94% say key factors, including tech debt, validation time, and developer burnout, are missing from those same metrics. And only 6% believe the frameworks they have today can fix it.
• The biggest AI challenge is measurement itself. When asked to name the single biggest challenge, the top answers are all visibility problems: measuring true productivity impact (26%), maintaining code quality with AI (24%), and proving ROI to leadership (18%).

Developers Don't Trust How AI Metrics Will Be Used

Even as productivity dashboards show green, developers are uneasy about how that data will be used. Part of the problem is structural: measurement systems are most often built top-down by leadership, without structured input from the practitioners being measured. When frameworks reflect only the leadership view, they systematically undercount the pressures developers are actually experiencing.

• The perception gap is wide. Managers are nearly four times more likely than practitioners to report no concerns about how AI productivity data might be used to evaluate them (15% vs. 4%).
• Fear of surveillance is widespread. 54% fear individual performance evaluations based on AI data. In addition, 46% of respondents cite struggling with pressure to work faster than is sustainable, and the same share report privacy or surveillance concerns.
• Developers want a say in how they're measured. 55% want a clear separation between improvement data and performance evaluation, 50% want transparency about what's being measured, and 49% want to be involved in defining the metrics themselves.

What Engineering Leaders Should Measure Now

The frameworks engineering organizations rely on — velocity, DORA, cycle time, developer experience surveys — still work. They just weren't designed for what AI has changed about the work itself.

To capture AI's benefits without missing its costs, Harness recommends that engineering organizations:

• Start measuring the new unit of work. Add code quality, validation time, cognitive load, and burnout indicators alongside the frameworks built around velocity and cycle time.
• Treat AI performance as its own discipline. Track AI agent accuracy, acceptance, and cost separately from human developer output, with a shared definition of "good" across the organization.
• Separate improvement data from performance evaluation. Build the measurement system with developers. Be explicit about how the data will be used, and involve developers in defining the metrics.

Methodology: This report is based on a survey of 700 software engineering practitioners and managers from large enterprises, commissioned by Harness and conducted by independent research firm Sapio Research in April 2026. The sample included 300 respondents from the United States and 100 each from the United Kingdom, India, France, and Germany.

Krea has released two open-weight AI image models — Krea 2 Raw and Krea 2 Turbo — designed to offer enterprises greater visual variety and creative control than typical AI generators, with Turbo generating images in just 2 seconds. The models are free for individuals and small businesses, but organizations exceeding 50 seats must negotiate a paid enterprise license, and all deployers must implement content filters. Founded in 2022 and backed by $83 million in venture capital, Krea has grown to 30 million users across 191 countries. The release marks its evolution from an AI tools aggregator into an independent model provider.

Every Frame Perfect

A while ago I was reading about Wayland and this quote stuck with me:

A stated goal of Wayland is “every frame is perfect”.

And I think this is a goal we should all aspire to. Wayland is talking about the technical side of things (modern GPU stacks are very complex and Wayland is trying to take control back) but it could be applied to UI too.

The rule of thumb is:

If I take a screenshot of your app at any moment, you should be able to explain what I see.

EDIT: This used to say “..., it must make sense” but that doesn’t account for advanced animation techniques such as smear frames etc.

Why care about every frame? It builds trust. Users can’t see the code, so UI is the only way for them to judge the quality of the app. If UI looks good, that means developers had time to polish it, which means that they probably spent a comparable amount of time to iron out the code. It’s a heuristic, but a reasonable one.

Now, what does it mean in practice? I can think of a few things:

• No white flashes between screens.
• No partially loaded content.
• No relayout while content loads.
• Internally consistent. If one part of the UI says “1 update available”, another part should not say “Checking for updates...”
• Precise animations.

Animations often end up being forgotten. A UI might look great in both start and end states but very janky in between.

If you feel like there are weird things going on there, there are! Look at slowed down version:

Now let’s apply our rule and take screenshots in the middle of the animation. This doesn’t look right:

Neither does this:

Both of these frames are not perfect.

Let’s look at another example. Safari:

Placeholder text here moves from the center but cursor animates from the left position:

Not the end of the world by any means, but it does create a feeling that these two components are not in sync with each other. Next thought: maybe they weren’t designed together? If so, then they might not work well together. That’s how trust is lost.

This desynchronization can lead to a lot of confusion. For example, in Photos, when switching between Crop and Adjust mode, picture snaps into place immediately but the crop border is animated:

This creates a false feeling that something subtly changes when you switch between modes. And you know what? I don’t want my UI to give me false feelings. I want it to be a precise instrument, not an animated toy.

Sometimes animations are supposed to help you understand a transition, so it’s doubly sad when they make it harder. Follow the magnifying glass:

Same with Youtube. They had the simplest task in the world: move a rectangle from one position to another! Yet they decided to do something very strange:

Can you explain this? Does it make sense?

Probably a technical limitation of the DOM architecture they decided earlier on. I call these situations “The technology has outsmarted the programmer”. But no matter the reason, the result is an imperfect frame.

Sometimes animations are left out as an afterthought. Whatever happens, happens. Then we get this:

The details are fascinating to watch:

So yeah. Please pay attention not only to the start and end states, but also to everything in between. Every frame matters.

I’ll leave you with this unprovoked zoom animation from Preview app. Take care!

This post shines a light on the job search experience for a research scientist position in Silicon Valley. The author is a fifth-year PhD student at Brown University. Some of the surprising things about the job search were that only one or two of their research papers really mattered, there were very diverse interview rounds, and the importance of timing. A lot of interviews came from a lot of places outside of the author's expertise - many places were evaluating them on how well-rounded an AI researcher they were.

The M7 Pro and M7 Max are scheduled for as early as the end of 2027, while the M7 Ultra is on track for 2028.

Apple has reportedly green-lit development of a second-generation iPhone Ultra, signaling confidence in its foldable iPhone plans, while delaying a decision on an iPhone Air 3 until it sees how well the upcoming iPhone Air 2 sells. However, Apple routinely works years ahead on future products, so neither project is guaranteed to reach the market if sales of their predecessors fall short.

Designers should avoid describing intentional AI-assisted workflows as "vibe coding," since the term implies passive, low-accountability generation rather than deliberate creative direction. Instead, AI should be seen as a tool guided by the designer's judgment, references, and constraints, with terms like "directed generation" or "reference-guided generation" better reflecting a process where human authorship remains central.

Real-time 2D animation, motion design, and data-driven workflows - built for animators and motion designers.

Autograph is a software solution that combines professional tools for motion graphics, VFX/compositing, and 2D/3D projects across industries.

Airbrush Studio, a photo editor for PC designed for desktops, lets you easily enhance images with AI-powered tools. Crop, expand, retouch, fix facial details, and reshape photos to create clean, polished, high-quality results in minutes.

Fable&Co. created Nova Biochem's first complete brand identity around the concept of "Matter," reflecting both its materials-focused technology and its broader impact. The system combines molecular-inspired visuals, a distinctive yellow accent, and a science-led website to present the deep-tech startup as a credible, scalable industrial business rather than an early-stage biotech company.

Sour Soda Studio is an anonymous side project by an established illustrator known as A, built over four years through experimentation with freehand vector brushes in Adobe Fresco, resulting in a soft, rubber-like visual language of organic lines and flat colors.

Ikea Canada's "Assemble the World" campaign creatively celebrates the 2026 World Cup by using everyday Ikea products to recreate national flags, blending interactive marketing with the brand's signature design aesthetic.