Cloudflare has announced an open source tool that takes an API definition and automatically produces the SDKs, command-line tools, documentation, and other interfaces used to interact with it.

Forge, as it’s called, is available under an Apache 2.0 license, and can be run and modified privately without paying Cloudflare a dime. In a blog post published on Monday by Dimitri Mitropoulos, Matt Taylor, and Samuel MacLeod, Cloudflare notes that the project is still early: it already generates the output required for Cloudflare’s cf CLI, its unified command-line interface for working across the Cloudflare platform, with the company’s API documentation and SDKs due to move over in the coming months.

“We believe that building tools for APIs is a core part of the Internet, and you should be able to do that without needing a SaaS product.”

“We believe that building tools for APIs is a core part of the Internet, and you should be able to do that without needing a SaaS product,” the authors write.

When your SDK generator disappears

Cloudflare’s announcement comes just 11 days after Google made a somewhat similar move, revealing it had partnered with API tooling company Speakeasy to open-source the latter’s OpenAPI code-generation suite under an AGPLv3 license.

In a blog post published September 17, Google said its decision was prompted by the sudden loss of its SDK-generation service, after the provider was acquired and “abruptly announced its shutdown.” This happened just as Google was preparing to launch a new API.

“This sudden disruption highlighted that proprietary, closed-source generators create unacceptable platform risk.”

“This sudden disruption highlighted that proprietary, closed-source generators create unacceptable platform risk,” the company wrote. “If the industry relies on OpenAPI to define interfaces, the tooling to compile those interfaces into client libraries, CLIs, and agent tools should be open infrastructure.”

The provider Google was referring to was Stainless. Anthropic acquired the SDK and MCP tooling company on May 18, after which Stainless said it would wind down its products, including the SDK generator used to keep client libraries updated as APIs changed.

As The New Stack reported at the time, the closure affected a swathe of customers including OpenAI, Google and Cloudflare. While those companies retained the SDKs Stainless had already generated for them, they lost the shared service they had relied on to regenerate and update those SDKs as their APIs evolved.

Cloudflare, for its part, had already begun building some of the machinery that would become Forge. In April, the company released a technical preview of cf, a new unified command-line interface intended to eventually expose Cloudflare’s products through a consistent set of commands for developers and AI agents. At the time, Cloudflare said it had created a new TypeScript-based schema and generation system to keep CLI commands, configuration, bindings and other interfaces in sync with its API.

That earlier preview was limited — cf initially covered only a small subset of Cloudflare products — although the company said it was already testing a version spanning its entire API surface. Forge is the code-generation system that has emerged from that work and now generates the output required by cf.

Tools such as Forge save API providers from having to maintain each SDK, CLI command set and documentation surface separately by hand. When the underlying API changes, the same definition can be used to produce updated SDKs, CLI commands and documentation for the developers — or agents — consuming it.

Why Cloudflare built its own generator

While Stainless was one of the hosted generation products Cloudflare had relied on in production, Cloudflare doesn’t name it specifically, instead spelling out why Cloudflare had become dissatisfied with the broader category of hosted generators.

Part of the problem is sheer volume: Cloudflare says it now has more than 3,500 API operations, backed by hundreds of services maintained by different engineering teams. A generator therefore has to keep changes across that sprawling API estate accurately reflected in the tools customers use, without turning every update into a coordination exercise across the company.

Cloudflare also wanted engineers to see what an API change would do to the resulting SDK, CLI and documentation before the underlying code was merged. Moreover, it wanted the same system to reach beyond conventional SDKs into things such as MCP servers and Cap’n Web bindings, which allow applications to invoke remote services through Cloudflare’s TypeScript-based RPC system in much the same way they would call local functions.

That had proved difficult with external services. Cloudflare says problems introduced in one part of its API could surface only when another team later tried to release something, leaving engineers to trace the failure back through systems they did not fully control and then coordinate a fix across company and vendor boundaries.

“We’ve tried several hosted products that attempt to solve this, and relied on some in production,” the authors write. “None of them solved this problem for us, and some have shut down entirely.”

The open-source factor

And so the Stainless wind-down goes some way toward explaining why Cloudflare is making Forge open source. Stainless’s generator was proprietary and delivered as a hosted service, leaving customers dependent on the company continuing to operate it. Forge’s permissive Apache 2.0 license means developers can run it on their own infrastructure, modify it, or fork the project and continue using it independently of Cloudflare.

AI agents raise the stakes further, because they increasingly rely on SDKs, CLIs and API bindings to understand what software can do and how to interact with it. If those interfaces lag behind the underlying service, the agent may be working from an incomplete or outdated description of its capabilities.

That is the concern Cloudflare CTO Dane Knecht highlights when explaining why keeping those interfaces current matters more than ever today.

“APIs have always been how software connects, but AI agents make the quality of SDKs, CLIs, and API bindings even more important,” Knecht tells The New Stack over email. “If that layer is stale or incomplete, an agent doesn’t just have a worse developer experience, it can misunderstand what a service can do.”

Ultimately, Cloudflare created Forge because SDK and CLI generation has “become too important” to sit outside its internal development process.

“Cloudflare needed a pipeline our teams could run, test, and extend themselves, and we think other developers should have access to that same kind of open, vendor independent foundation,” Knecht says.

Forge still has plenty to prove, of course. The project is early, cf is its first production output, and Cloudflare says its API documentation and existing SDKs will move over during the coming months. Several of the input formats and generated targets it discusses are also future work.

But the timing is quite revealing. Within 11 days, Google and Cloudflare — both former Stainless customers — have publicly thrown their heft behind open source SDK-generation infrastructure after the disappearance of the proprietary service they had relied on. Google describes that dependency as an “unacceptable platform risk.” Cloudflare, with Forge, is now trying to remove the same risk from its own stack.

The post Anthropic bought Stainless and shuttered its SDK generator. Cloudflare open-sourced Forge instead. appeared first on The New Stack.

We all know that producing code is easier than ever thanks to the abundance of AI coding tools and agents. The harder part undoubtedly comes after that code is written: making sure changes are safe to ship, spotting regressions in production, and figuring out what went wrong.

And that’s why Cursor is introducing Rollouts, a new agent that follows code changes into production and monitors whether they behave as intended.

The Firetiger effect

The announcement comes a little over a month after SpaceX closed its bumper $60 billion acquisition of Cursor, giving the AI coding company access to SpaceX’s vast GPU infrastructure as it develops its own models.

The day before that deal closed, however, Cursor quietly announced an acquisition of its own: it snapped up the team behind Firetiger, a three-year-old startup building AI agents that monitor software changes from pull request through deployment.

At the time, Firetiger co-founder and CEO Rustam Lalkaka argued that coding agents had dramatically reduced the effort involved in creating software changes, while doing little to reduce the risks involved in actually deploying them.

“Over the last two years, agentic coding has changed software dramatically,” Lalkaka wrote in a LinkedIn post following the deal’s announcement. “The cost of creating changes has dropped to near zero. The cost and risk of deploying them has stayed largely the same.”

“Writing code is no longer the slow part. What hasn’t sped up is everything after the PR goes up: making sure code is secure, watching the deploy, deciding whether a latency bump is real, figuring out which of eleven changes broke checkout.”

Rustam Lalkaka, Cursor

Fast forward to today, and Lalkaka, now at Cursor, has unveiled the first fruits from that acquisition — including Rollouts. In a blog post published on Wednesday, Lalkaka notes that the new agent, or “bot” as the company calls it, is all about helping developers “get safe, reliable code into production faster.”

“Writing code is no longer the slow part,” Lalkaka writes. “What hasn’t sped up is everything after the PR goes up: making sure code is secure, watching the deploy, deciding whether a latency bump is real, figuring out which of eleven changes broke checkout.”

Rollouts is effectively Firetiger’s Change Monitors reborn inside Cursor, rebuilt using a tool dubbed Bot Development Kit. This kit, too, appears to be new from Cursor: an early-stage framework for building and serving Cursor bots and agents, published as the @cursor/bdk package on npm. Its documentation says developers can define agents using Markdown and TypeScript, with support for tools, skills, subagents, webhooks and scheduled runs.

Like Change Monitors before it, Rollouts starts working when a pull request opens. It examines the proposed code change, works out which systems could be affected, and produces a monitoring plan covering what the change is supposed to do, the risks it sees, the signals it intends to watch, and any holes in the available instrumentation. Developers can review and edit that plan before the code reaches production.

Once the change is deployed, Rollouts checks the resulting telemetry — including logs, metrics and traces — against that plan. Staging and production are assessed independently, with each deployment ultimately receiving one of three verdicts: verified healthy, regression detected or inconclusive.

That means a change could, for example, pass its checks in staging before Rollouts subsequently spots a problem when the same code reaches production.

If Rollouts does detect a regression, it can identify the change it suspects, alert the developer responsible and, depending on how it’s been configured, either open a revert pull request for review or hand the problem to a Cursor cloud agent to attempt a fix. There is still a human in the consequential part of that loop for now: Rollouts doesn’t merge fixes or roll back deployments by itself, though it can pause a progressive rollout.

Lalkaka notes that Rollouts is already capable of picking up problems limited to a particular endpoint or region before they trigger a broader alert, while it can also distinguish expected changes in behavior from genuine regressions.

Also “coming soon” to Rollouts, according to Cursor, is an integration with feature flags so it can directly adapt the traffic reaching a change, while support for release trains and deployment freezes is also in the works.

Enter Security Reviewer

Alongside Rollouts, Cursor is also introducing an upgraded Security Reviewer bot, which first appeared in beta back in April.

At launch, the bot could automatically inspect pull requests for security vulnerabilities, authentication regressions, privacy and data-handling risks, agent tool auto-approvals, and prompt-injection attacks, leaving findings alongside the relevant code.

As with Rollouts, the idea is that developers don’t have to remember to invoke it manually: Security Reviewer can be set to run whenever a new pull request is opened.

In its current guise, Security Reviewer analyzes pull requests in the context of the wider codebase, with a focus on exploitable issues such as injection flaws and broken authentication, and returns a severity rating, attack path and proposed fix.

“Security Review reads code the way a security engineer does,” Lalkaka writes. “Where does user input enter, where does it end up, what does it pass through on the way.”

“Security Review reads code the way a security engineer does.”

He says that things have sped up considerably, too: average review time has fallen 21%, from 4.8 minutes to 3.8, while developer acceptance of its comments has risen from roughly 45–50% to 60–70%.

Both Rollouts and Security Reviewer are available through Cursor’s Automations tab for customers on its Teams and Enterprise plans.

The Origin story

Digging into the nuts and bolts of Rollouts reveals how it might serve as a boon for Cursor as it builds out Origin, the fledgling Git-compatible code hosting platform it launched back in August.

Origin is essentially an effort to build an alternative to GitHub for an agent-heavy software development world. It remains early, with limited functionality, but Cursor has been clear that tighter integration with its own agents is supposed to become one of the main reasons to use it.

When Cursor announced the Firetiger acquisition last month, Maxime Prades on the Cursor product team noted in a blog post that the deal was part of a “broader investment in long-running, autonomous, context-aware agents for teams.”

And he pointed to Origin and Change Monitors as two examples of that investment.

“Agents that write code should also be able to tell whether it works in production,” Prades wrote. “Today, those systems are mostly separate. Cursor and Firetiger bring them closer together so an agent can ship a change, see how it behaves, and respond when something goes wrong.”

Rollouts offers an early glimpse of that. It can connect to either Origin or GitHub for source control, pull deployment events from continuous delivery systems, and use signals from Datadog and other telemetry providers. If it spots a regression, it can then pass the problem back to a Cursor cloud agent to investigate or attempt a fix.

Origin potentially gives Cursor a native home for more of that loop: its cloud agents can already create branches, commit and push code, and open pull requests against Origin repositories. Rollouts then adds information about what happened after.

That could become increasingly important as more companies take aim at GitHub’s central role in software development. Zed, for example, put Delta into public beta last week, with its own ideas about how source control should change for teams working heavily with agents.

Cursor also faces competition further downstream. Datadog’s Bits Release, launched in preview in June, similarly follows changes from pull request into production and checks telemetry for regressions. Harness has long offered automated deployment verification and rollback based on logs and metrics, while LaunchDarkly’s Guarded Rollouts can monitor feature releases for regressions and automatically reverse them.

What Cursor can potentially bring to the table is proximity: the coding agent, repository, pull request, security checks, and production feedback can all sit much closer together. Rollouts doesn’t require Origin — GitHub remains supported — but owning the forge gives Cursor more room to integrate those pieces over time. And that may prove more compelling than simply recreating GitHub’s existing feature set.

The post Cursor acquired Firetiger. A month later, it launched a bot that tracks code changes from PR to production. appeared first on The New Stack.

New models are coming out thick and fast, almost on a weekly cadence, ranging from the powerful proprietary systems coming out of the major US AI labs to the more open alternatives being released by some of China’s biggest tech companies.

On Tuesday alone, Anthropic debuted Claude Opus 5.5, while OpenAI launched GPT-6 Sol and Luna, each accompanied by their the usual claims about how they outperform their rivals. Amidst all the hullabaloo of the frontier-model frenzy, however, Xiaomi also debuted MiMo-V2.6, another powerful open model from one of China’s growing ranks of AI developers.

All the initial headline numbers look pretty promising, too. The flagship MiMo-V2.6-Pro is a trillion-parameter model, with 42 billion parameters active at a time, a one-million-token context window, and support for text, images, audio and video. Broadly speaking, that puts it in the same frontier territory as the latest models from OpenAI and Anthropic: GPT-6 Sol has a 1.05-million-token context window, while Claude Opus 5.5 has a one-million-token window, though neither company discloses comparable parameter counts.

Xiaomi, for its part, makes broad claims of frontier-level performance across coding, agentic tasks, cybersecurity, multimodal work and research. Independent analysis lends some weight to those claims –Artificial Analysis gives MiMo-V2.6-Pro an Intelligence Index score of 46, ranking it first among the 114 large open-weight models it tracks.

So far, so good. But arguably the bigger story in Xiaomi’s offering is the manner in which it trained the model, how much of that process it showed in public, and what it’s releasing afterward.

A public record

Xiaomi livestreamed its RL training through a public dashboard, exposing metrics from the production reinforcement-learning runs in real time over a five-day period starting on September 15. By the time the runs had finished, the dashboard showed costs of $854,044 for the smaller MiMo-V2.6-Flash model and $2,620,670 for Pro — about $3.5 million combined.

It’s worth noting that this figure covers only the RL stage; Xiaomi hasn’t said what pretraining the models cost. Even so, public RL bills are rare. The closest precedents came last year, when MiniMax said the RL phase of its 456-billion-parameter MiniMax-M1 cost $534,700 in GPU rental, and DeepSeek put the RL training of its 671-billion-parameter R1 at $294,000. Both were leading open reasoning models when they launched, though the comparison only goes so far: MiMo-V2.6-Pro is larger, and its RL run targeted longer, agentic tasks.

Shortly after the stream began, Fuli Luo, who leads Xiaomi’s MiMo team after previously working at DeepSeek, took to X to explain the thinking behind the project. The team, she said, had spent almost six months exploring how far RL could be pushed, increasing the amount of training, the variety of environments and agent setups, and the resources used to grade the model’s attempts.

“We’ll open-source the details piece by piece over the coming weeks,” she added.

Nearly half a year of silence. We spent it studying one problem: how far RL can scale.

MiMo-V2.6 is in the middle of its RL run right now. Three things we scaled: compute (~2B tokens per step, 1568 prompts × 16 rollouts, fully async), environments and harnesses (multi-task…

— Fuli Luo (@_LuoFuli) September 16, 2026

Responding on X, Hugging Face co-founder and chief science officer Thomas Wolf called the move an “Impressive level of openness on such a large run.”

However, what Xiaomi’s putting out alongside the finished models is arguably just as interesting. The company has released the model weights under the permissive MIT license, alongside its technical report and a 9-billion-parameter Qwen-based model, intended as a starting point for further agentic RL research.

“Impressive level of openness on such a large run.”

Xiaomi says it has also “fully open-sourced” a broader set of RL resources: more than 7,000 task environments spanning software engineering, vulnerability reproduction, knowledge work and web development; an end-to-end training framework covering everything from environment interaction to reward evaluation and policy optimization; and lightweight agent harnesses for experimenting with different tools, prompts and context setups. At the time of writing, however, Xiaomi’s link to the open-source collection on Hugging Face contain only the three model releases, with the 7,000-plus environments and other supporting resources not surfaced there. Luo had said earlier that Xiaomi would be open-sourcing the various elements “over the coming weeks.”

As the results began arriving this week, attention in the research community quickly moved beyond the benchmark score to what Xiaomi had committed to releasing overall. Elie Bakouch, a former Hugging Face researcher who is now a research engineer at Prime Intellect, singled out the promised RL resources.

“The most insane part, they will release ~7k RL training data and the framework leading to this top 6 model on AA,” Bakouch writes on X. “They also shipped the model + tech report less than 1 week after starting the final RL run.”

Wolf went further, arguing that access to the environments in which models learn may now be especially valuable for open research, as more model development shifts toward RL with verifiable rewards (RLVR). Because RLVR depends on tasks whose outcomes can be automatically checked — whether code passes a test, for example — the environments themselves become a crucial ingredient in training.

“Releasing many high quality open-source RL environments is the most impactful thing anyone can do to push the open-source frontier right now.”

“Releasing many high quality open-source RL environments is the most impactful thing anyone can do to push the open-source frontier right now,” Wolf writes. “The equivalent of sharing high quality pretraining data, but in the new RLVR paradigm.”

Open-weight vs open-source

So while the benchmarks around Xiaomi’s latest model are notable in their own right, it’s the company’s approach that is generating much of the fanfare so far.

Indeed, MiMo-V2.6 serves as a useful example of a distinction that often gets muddied in the AI sphere: “open-weight” and “open-source” are routinely used as though they mean the same thing, but they don’t. Many “open” models amount largely to downloadable weights — essentially, the vast collection of numerical values a model learned during training, which can then be used to run or fine-tune it — while much of what went into producing them remains closed.

Some companies have gone further in muddying those terms. Meta, for example, has often referred to its Llama models as open-source despite significant restrictions that have led open-source advocates to push back heavily on that description.

And so MiMo-V2.6 goes further than most open-source releases. Its MIT license carries none of the conditions that the likes of Moonshot’s Kimi K3 and Alibaba’s Qwen3.8-Max attach for large commercial users. And if the environments are released as promised, outside researchers will have much more of the post-training process to inspect and build on.

The post “Impressive level of openness”: Xiaomi goes way beyond the usual open-weight playbook with MiMo-V2.6 appeared first on The New Stack.

There’s little question that AI coding agents have changed where software development work happens. Developers can increasingly delegate work from terminals, desktop applications and remote environments, leaving question marks hanging over the future of the integrated development environment (IDE).

That shift poses a particularly interesting question for JetBrains. The company has spent 26 years building some of the industry’s best-known IDEs, including IntelliJ IDEA, PyCharm and WebStorm, even as agentic development has begun pulling more software work outside the editor. JetBrains, for its part, has maintained that the IDE will remain a core part of professional development, particularly as developers are asked to manage the growing volumes of AI-generated code — humans need to review, debug, and verify, after all.

Now, the company’s making a much bigger bet on the broader development system that sits around the IDE.

JetBrains CEO Kirill Skrygan took to LinkedIn on Tuesday to formally unveil JetBrains Air as an “open system of products for agentic software development” for developers and companies, operating “inside and beyond JetBrains IDEs.” And Skrygan didn’t hold back on what he feels is a monumental moment for the company.

“JetBrains is taking one of the most significant steps in our 26-year history.”

“Today, JetBrains is taking one of the most significant steps in our 26-year history,” he writes.

Getting some Air

In truth, Air represents a repackaging of several strands of JetBrains’ recent AI work under a single banner, including an agentic experience inside its IDEs, tooling for coordinating developers and autonomous agents, and company-level controls for governing their use.

By way of a brief recap, JetBrains first launched Air in public preview back in March as a standalone “agentic development environment,” initially for macOS, where developers could run the likes of Claude Agent, Codex, Gemini CLI and JetBrains’ own Junie side by side. At the same time, it pushed Junie itself outside the IDE with Junie CLI, giving developers access to the coding agent from terminals, CI/CD systems and other editors.

A couple of weeks later came JetBrains Central, a separate system aimed further up the organization, providing the controls and infrastructure for companies running multiple coding agents. Then in July, JetBrains launched AI for Teams and Organizations, effectively adding shared context, cloud agents, automations, and organization-wide governance and cost controls that could sit above whatever AI tools developers were already using.

Today’s announcement now gives these efforts a common home under the JetBrains Air umbrella. In a separate blog post published on Tuesday, Skrygan describes three main parts to the system: Air in JetBrains IDEs for directing agents and checking their work; Air Teams for coordinating work between developers and autonomous agents; and Air Governance, the new name for JetBrains Central, for managing policy, auditing, costs and AI use across a company.

The original Air desktop IDE hasn’t gone away either, it seems. It remains available as a standalone desktop application on macOS, Windows and Linux, alongside a browser-based version for organizations. That leaves “Air” doing double duty: it’s still the name of JetBrains’ dedicated agentic development environment, while now also serving as the banner for the wider collection of products around it.

What does JetBrains Air actually do?

JetBrains Air is available inside JetBrains IDEs, through the browser, and from the command line via Air Gateway, which brings terminal agents such as Claude Code and Codex into Air.

For individual developers, Air can be used to supervise several pieces of agent work at once. They can keep multiple projects and agent sessions running, while tracking new activity, changed files and outgoing commits, then inspect the resulting changes using JetBrains’ IDE tooling.

Air Teams, which is still in early access, moves some of that activity into shared cloud environments, where developers can collaborate on projects and run agent tasks without tying the work to one person’s machine. Teams can also configure recurring automations and centrally manage the environments and external tools available to agents.

Air Governance, meanwhile, provides the organization-level controls, including deciding which models and agents developers can access, setting permissions and spending limits, and tracking AI usage across teams.

Those governance capabilities are also only offered through JetBrains’ early access program for now.

It’s worth noting that JetBrains also plans to extend Air to the mobile realm, where developers will be able to monitor and continue agent work away from their desktop.

For JetBrains, the point is to connect those different layers while remaining open to outside agents and tools.

“JetBrains Air cannot be just another agent or development environment.”

“JetBrains Air cannot be just another agent or development environment,” Skrygan writes. “It must connect products for individual work, team coordination, organizational control, context, and process automation — and remain open to the tools and agents developers choose, including those JetBrains does not build.”

Air in the IDE

While the core raison d’être of JetBrains Air is to provide somewhere for developers and companies to work with software agents — be it Claude, Codex, Junie or something else entirely — JetBrains is clearly emphasizing that its IDE roots remain part of that future.

Skrygan says the company has historically “focused primarily on the individual developer workbench,” but Air broadens its remit to encompass the wider environment in which agentic work is started, carried out, coordinated, reviewed and governed.

“Our IDEs will continue to be where professional developers work with agents, understand and verify code, and make the decisions that shape what ships.”

“Our IDEs will continue to be where professional developers work with agents, understand and verify code, and make the decisions that shape what ships,” Skrygan writes. “JetBrains Air extends that control across the broader system developing around them.”

And that fresh IDE piece has already been in the public domain for more than a month. JetBrains has been testing the Air Alpha plugin since at least early August, giving developers a way to run and supervise multiple coding agents directly inside IntelliJ-based IDEs, and review the changes they produce using native IDE tooling.

An updated release earlier this month added more controls for monitoring and steering agent sessions.

JetBrains concedes that Air “Alpha” is very much that — an early iteration it’s building while it rolls out JetBrains Air itself. And so users should expect “rough edges, changes to the UI and behavior, and updates roughly every week.”

What Tuesday’s announcement does, though, is give that work a formal place within the wider Air system. And while Skrygan acknowledges that agentic development means that work must now span multiple surfaces, the technology that has sat at the heart of its business for the past 26 years won’t be going anywhere anytime soon.

“The IDE remains important to JetBrains’ future,” Skrygan writes.

The post “One of the most significant steps in our 26-year history”: JetBrains goes big on agentic development — and bets the IDE still matters appeared first on The New Stack.

Amazon Web Services (AWS) is lifting the lid on a new open source, general-purpose AI agent, designed to give developers a ready-made foundation they can run locally or deploy to the cloud.

Strands Harness, as it’s called, builds on Strands Agents, which AWS debuted in May 2025 as an open source Python SDK for building AI agents. Strands takes what AWS calls a “model-driven approach”: developers provide the model, tools and instructions, while the model determines how to tackle the task and when to call those tools. AWS later brought Strands to TypeScript, and in February created Strands Labs as a separate home for more experimental projects.

Marc Brooker, VP and distinguished engineer at AWS, tells The New Stack that Strands Harness essentially sits above the existing Strands SDK, giving developers a preconfigured Strands Agent. It brings together the tools and supporting machinery an agent needs to operate over longer-running tasks, with AWS supplying its own defaults for how those pieces work together.

“You still need to decide how to manage context, persist conversations, integrate tools, and guide the agent’s behavior.”

“An SDK like the Strands Harness SDK gives you the building blocks, but you still need to decide how to manage context, persist conversations, integrate tools, and guide the agent’s behavior,” Brooker explains.

Unpacking Strands Harness

Out of the box, Strands Harness gives developers a working agent with file, shell and web tools, alongside built-in handling for context, memory, persistent sessions, prompt caching and delegation to other agents.

Developers can install Strands Harness as a Python or TypeScript package, using pip install strands-harness or npm install @strands-agents/harness.

AWS also provides the Strands CLI as an interactive way to prototype and configure an agent. Developers can choose a model, add prompts, tools and other capabilities, then use /export to generate the resulting agent as Python or TypeScript code.

Individual agents can be tailored to different jobs, with developers able to change their instructions, choose which model they use, control which tools and capabilities are available to them, and decide whether they can hand work off to another agent.

Most of Strands Harness itself doesn’t depend on AWS infrastructure. The agent loop, tools, context management, session handling and delegation are all included in the open source release, and AWS says those processes run on the machine that’s running the agent by default.

The exception is the call to the underlying model. Perhaps unsurprisingly, AWS routes model access through Amazon Bedrock, its managed service for accessing and running foundation models. However, while Brooker says that this is the only out-of-the-box default tied specifically to AWS infrastructure, it too can be switched out.

“This is easily overrided to use a different model provider with one line,” he says.

Strands Harness can instead use Anthropic, OpenAI or Google as its model provider, or use a locally running model through Ollama. Changing provider doesn’t necessarily mean changing the underlying model, but Brooker notes that choosing a different model will obviously affect how the agent behaves.

“Different models have different strengths on reasoning, tool use, and cost,” he continues. “What doesn’t change: context management, sessions, tools, delegation all work the same regardless of provider. No features require Bedrock.”

It’s worth noting that all the other defaults can be changed, too. Developers can bring their own tools and skills, connect MCP servers, alter how context is handled, and choose where session state is stored.

“Developers can focus on their application’s task and domain expertise, while customizing the components that need different behavior.”

“Developers can focus on their application’s task and domain expertise, while customizing the components that need different behavior,” Brooker says.

AWS benchmarks its agent

AWS says Strands Harness is intended as a general-purpose agent rather than a coding assistant, though it takes cues from harnesses such as Claude Code and Codex. The difference, AWS says, is that developers can deploy Strands Harness to whichever cloud provider they choose — addressing what it describes as a common wish among developers using Claude Code and Codex to be able to run the same setup in the cloud.

From its own testing, AWS suggests the way a harness manages the surrounding agent machinery can materially affect cost and performance, even when the underlying model stays the same. For each harness, AWS averaged its score across six benchmarks — ALFWorld, ContextBench, GAIA, WebShop, τ³-bench and Terminal-Bench 2.1– and compared that with the average cost per task across the same tests. Against Claude Code and Codex specifically, the company says Strands Harness came out 45% cheaper, with broadly comparable accuracy.

However, that figure drops to 28% once DeepSeek Harness — which AWS says ran around 14% cheaper than Strands Harness on matched runs — is folded into the wider comparison.

AWS points specifically to its context-management defaults as a major reason for the result. Strands Harness truncates particularly large tool outputs, compacts context once the available window passes a set threshold, and attempts to recover within the agent loop if the context overflows.

On Terminal Bench 2.1 specifically, AWS says Strands Harness running Fable 5 cost 77% less than Claude Code, at $56.29 versus $248.05 across 89 trials, while scoring 69.7 versus 61.8. DeepSeek Harness was cheaper again at $40.30, though its score was lower at 59.5.

For AWS, those results help make the case for packaging and tuning functions such as context management, versus requiring every developer to work out those decisions independently with the SDK.

“Getting a prototype working is one step; evaluating how those choices affect performance and cost is another.”

“Getting a prototype working is one step; evaluating how those choices affect performance and cost is another,” Brooker says. “The opportunity we saw was to package that engineering into a complete, general-purpose agent.”

What’s in it for AWS?

AWS also has an obvious place to run the resulting agent. Amazon Bedrock AgentCore is its managed service for deploying and operating agents, providing identity and access controls, observability and the infrastructure needed to host them.

There is, in fact, a close technical relationship between the open source project and that managed offering. AgentCore Harness and Strands Harness were built by the same team, although they live in separate codebases. Brooker says work on one can also feed improvements into the other, giving AWS a route for technology developed in the open source project to inform its managed service, and vice versa.

Brooker, again, stresses that Strands Harness can be deployed independently of AgentCore, outside of AWS altogether.

“AgentCore is an optional hosting layer for teams that want AWS to manage the infrastructure side,” he says. “However, all deployment paths are open for the developer to choose.”

Still, this arrangement gives AWS a clear commercial path: developers can adopt Strands Harness freely, while AgentCore gives the company a natural destination for teams that eventually want AWS to run the infrastructure around it.

The post AWS open-sources an AI agent it says is 45% cheaper than Claude Code and Codex appeared first on The New Stack.

The trend is clear: open-weight models are taking an increasingly large bite out of production AI usage.

On Monday, The New Stack reported that open-weight models accounted for 60% of OpenRouter’s US token consumption in August, with Chinese-developed models making up the majority of that volume. The latest data point hails from Vercel, whose AI Gateway routes tens of trillions of tokens each month across the applications running on its infrastructure.

As per Vercel’s September report, published on Thursday and covering activity through August, open-weight models handled 56% of all tokens routed through the gateway, the first time they have accounted for a majority of monthly token volume. In December 2025, their share was just 7%; by April it had reached 13%, and it rose every month thereafter. Vercel’s previous report, published in August, put July’s open-weight share at 36%.

So the pattern was already clear. But last month, Vercel CEO Guillermo Rauch took to social media to declare that August 22 had been a “record day for open weight share of tokens on Vercel AI Gateway,” accounting for 62% of traffic.

Rauch saw the milestone as just an early indication of where usage is heading, with enterprises still early on the adoption front.

“This is very likely just the start, because enterprise adoption is still early.”

“This is very likely just the start, because enterprise adoption is still early, and harnesses, CLIs, IDEs, SDKs, etc need to be adapted to be model agnostic,” Rauch wrote at the time.

Tokens and dollars: Anthropic dominates spend

For context, Vercel launched AI Gateway last year as a way for developers to access models from multiple providers through a single interface, saving them from having to manage separate API keys, accounts and rate limits. The service sits between applications and the underlying model providers, routing requests while tracking usage and costs — giving Vercel a useful vantage point into which models its customers are actually running in production.

Token volume, in this context, is essentially a measure of how much model inference is flowing through the gateway. Vercel counts input and output tokens, along with reasoning, cached-input and cache-creation tokens.

While it’s a good proxy for the amount of work being handed to different models, it shouldn’t be confused with the amount of dollars being spent. Open-weight models from the likes of DeepSeek, Moonshot AI and Z.ai are generally cheaper to run than the proprietary models offered by US frontier labs — and so handling 56% of Vercel’s token volume doesn’t mean open-weight models are taking 56% of the money passing through its gateway.

Indeed, Vercel’s data shows that open-weight models accounted for just 14 cents of every estimated dollar spent through AI Gateway in August, despite processing 56% of its tokens. Their share of spending remains far behind their share of usage, although Vercel says the open-weight share of gateway spending is on the rise.

Across Vercel’s AI Gateway, the average price per token fell 23.2% in August, marking a third consecutive monthly decline. Among teams that processed more than 10 million tokens in both July and August, the median cost per token fell 7.6%.

Anthropic, meanwhile, has remained remarkably consistent at the spendy end of the market. Its models accounted for 64 cents of every dollar spent through the gateway in August. Vercel says the Claude-creator’s share has never fallen below 61% in any month since December 2025, with its models occupying the top two positions by spend throughout that period — often taking third spot, too.

Loyalty lies in the model

There has been plenty of movement within that Anthropic share, however. Fable 5 fell from 13.2% of total gateway spend in July to 4.9% in August, while the cheaper Opus 5 climbed to 22.5%. More broadly, Vercel’s data suggests that 90% of teams using Fable reduced their usage, with more moving those workloads to Opus 5 than to any other model.

Opus ultimately gained almost twice as much usage as Fable lost, which Vercel attributes to the newer model handling similar workloads at roughly half the price. Or, in other words, Anthropic kept the dollars even as customers shifted toward a cheaper model within its own lineup.

“Lab loyalty doesn’t follow brand, it follows model profile, and consistency wins.”

“Lab loyalty doesn’t follow brand, it follows model profile, and consistency wins,” Vercel’s report authors note.

This trend was evidenced elsewhere, too. Within five days of Z.ai launching GLM-5.3-Flash, the new model was processing three times the daily volume of GLM-5.2.

But Vercel’s data also suggests customers are more than prepared to cross lab boundaries when a replacement fails to meet the same needs on capability and price: more than three-quarters of the volume lost by Google’s Gemini 3 Flash moved to models from other providers, including OpenAI and Anthropic. And the consequence for Google wasn’t insignificant: its overall share of token volume on the gateway fell from 30% to 5%, with the decline in Gemini 3 Flash alone accounting for 22 of those 25 percentage points.

“When a new model preserves what users valued in its predecessor, the lab retains its customers,” the authors note. “When it doesn’t, those customers fill the need through other providers.”

The post Open-weight models now handle a majority of tokens on Vercel’s AI Gateway. But Anthropic still takes 64% of the spend. appeared first on The New Stack.

Rust is seemingly the language of the moment, with open-source projects and companies forming an orderly queue to move core software over to the general-purpose programming lingo. The draw? A pursuit of better memory safety and performance.

Now, GitHub has joined the throng. On Wednesday, the company revealed that it has completely rewritten the GitHub Copilot agent runtime — previously built in TypeScript on Node.js and V8 — into more than 800,000 lines of production Rust.

Most notably, however, the Microsoft subsidiary says it used its own Copilot coding agents to carry out the switch. In a blog post marking the migration, Microsoft engineer Stephen Toub says the company used the GitHub Copilot app and the Copilot CLI for the rewrite. The work was spread across 128 pull requests that were merged and shipped incrementally, an approach Toub notes allowed the team to catch and fix regressions along the way.

“A project that would have taken a whole team of developers a year or two before agents was now completed primarily by a single developer, in only a few months, all while the rest of the team continued to greatly expand the runtime’s capabilities and reach.”

Microsoft engineer, Stephen Toub

While a major Rust migration is a big deal in its own right, the bigger story here is the leading role that AI played.

“AI agents wrote most of the code,” Toub writes, adding that the alternative would have been a much bigger undertaking.

“A project that would have taken a whole team of developers a year or two before agents was now completed primarily by a single developer, in only a few months, all while the rest of the team continued to greatly expand the runtime’s capabilities and reach,” he continues.

GitHub, for what it’s worth, is far from alone in its efforts.

Bun rusts up

Bun, the JavaScript runtime Anthropic acquired last December, announced back in July that it was rewriting more than half a million lines of Zig in Rust, with founder Jarred Sumner using a pre-release Claude model to do much of the work.

The impetus, ultimately, was stability. Bun had grown from a 2021 “pre-LLM” project Sumner built “in a cramped Oakland apartment,” into a runtime whose CLI now sees more than 22 million monthly downloads. But its growing remit had also brought a persistent crop of memory-management bugs, including leaks and crashes. Sumner was careful not to pin those problems on Zig itself, instead pointing to the particular difficulties Bun faced managing memory across Zig and the JavaScript engine it embeds.

“We could have kept fixing these kinds of bugs one-off in perpetuity, but we owe it to our users counting on us to do better than that, and systematically prevent these kinds of bugs from recurring.”

“We could have kept fixing these kinds of bugs one-off in perpetuity, but we owe it to our users counting on us to do better than that, and systematically prevent these kinds of bugs from recurring,” Sumner wrote at the time.

Rust offered stronger protections against many of those issues, but switching languages presented a problem of its own. Bun comprised 535,496 lines of Zig, and Sumner reckoned a conventional rewrite would require a small engineering team for about a year — an investment he said would have made the project unrealistic.

“It would mean freezing bugfixes, security fixes or feature development for that time,” Sumner wrote.

And so Sumner orchestrated multiple Claude Code agents to translate and check different parts of Bun simultaneously, while he monitored their work and intervened when the process went awry. Eleven days after starting, he said the Rust version was passing Bun’s existing tests on all six platforms it supports. The code was then merged, though further review and cleanup continued before release.

Same idea, different playbook

GitHub makes much the same economic case as Anthropic. Toub notes that a “rewrite this size wasn’t affordable before agents,” estimating that the job would previously have occupied a team for a year or two. But while the two companies arrive at a similar conclusion about what coding agents make feasible, their playbooks are very different.

“A rewrite this size wasn’t affordable before agents.”

Bun went for an all-at-once port, using large numbers of Claude instances in parallel before bringing the Rust version back into the main codebase. GitHub, on the other hand, chose a slower, incremental route: pieces of the Copilot runtime were converted and shipped as they were completed, across 128 pull requests, while development on the product continued around the migration. The process ran for roughly 14-and-a-half weeks.

“Eleven days” versus “14-and-a-half weeks” shouldn’t be read as a Claude-versus-Copilot benchmark. Bun was translating a Zig codebase into another systems language through a highly parallel effort; GitHub was moving a TypeScript and Node.js runtime to Rust while continuing to ship the product throughout. What the two projects have in common is the claim that agents made major rewrites viable, where the cost and disruption might previously have ruled them out.

And, of course, both companies have every reason to make that case. Anthropic and GitHub are major vendors of the very coding agents they’re crediting with making these projects possible, making their accounts inherently self-interested.

However, there are signs across the industry that the “agents do big Rust migration” phenomenon is gaining steam.

AI bites the rust

Back in March, Meta engineer Joe Savona led a port of the React Compiler from TypeScript to Rust, noting that this was “majority coded by AI,” though its architecture, testing and migration strategy remained heavily human-directed (by Savona himself). The experiment builds on a broader effort at Meta to replace “decades-old” legacy code with Rust in a core messaging library.

And just last Friday, OpenAI quietly disclosed another substantial agent-assisted Rust rewrite. The company said that two engineers, working with Codex and GPT-5.5, rewrote Habitat — the storage service underpinning products including ChatGPT — from Python into Rust during the second quarter of 2026.

While the company noted that it will reveal further details of this move in the future, it stated that the new Rust service is already “handling 95% of our production requests,” while using six times less CPU and 15 times less memory than its Python predecessor. Moreover, it plans to deprecate the Python version entirely “in the coming weeks.”

For now, these various projects remain individual case studies, reported by the companies with the most to gain from demonstrating what coding agents can do on major software rewrites. But there is a clear pattern: Rust was already attracting companies looking to rethink key software, and AI agents are now positioned as pivotal for migrations that may once have been too costly, disruptive or time-consuming to attempt.

The post GitHub and Anthropic used their own agents for major Rust rewrites — but with very different playbooks appeared first on The New Stack.

Something of a consensus has emerged from the developer fraternity in 2026 — GitHub, a platform built substantively for human developers, is no longer fit for purpose.

Part of the problem is sheer volume. Agents can generate, revise and submit code at a cadence GitHub wasn’t designed for, placing growing pressure on infrastructure built for humans working through commits, branches and pull requests. But there’s also a more fundamental question about the interaction model itself: when much of the reasoning behind a change happens inside a conversation with an agent, a pull request presents reviewers with the resulting diff while leaving much of the journey that produced it elsewhere.

At the heart of all of this, of course, is GitHub’s reliability problems. The platform logged hundreds of incidents over the 12 months leading into June, as monthly commit volume rocketed from around 1 billion across the whole of 2025 to 1.4 billion a month by April. By August, GitHub said this figure had jumped to 2.9 billion commits each month.

The growing load has manifested in some fairly spectacular outages, including a near-eight-hour disruption in August, with web and API error rates reaching around 20% at the height of the incident.

As Nathan Sobo, co-founder and CEO of developer platform company Zed, puts it in a blog post published on Wednesday, “everyone is in a race to replace GitHub right now,” with a number of players in the technology sphere working on alternative tooling. That includes Zed itself, which has announced the public beta of Delta — a collaborative environment where developers and coding agents work, review and revise code together in shared threads rather than pull requests.

At the heart of Zed’s pitch is the idea that the pull request is ill-suited to coding agents, and tells reviewers little about the reasoning behind their decisions.

“Since GitHub introduced pull requests over 15 years ago, they’ve become the standard way to ask teammates to review changes to your codebase.”

“Since GitHub introduced pull requests over 15 years ago, they’ve become the standard way to ask teammates to review changes to your codebase,” Sobo writes. “But with agents generating so much code, the diffs we’re asking each other to review have mushroomed.”

The question, then, is what collaboration should look like when agents are producing more of the code?

From A(tom) to Zed

Zed, for the uninitiated, started out with a somewhat narrower remit. Founded in 2021 by veterans of GitHub’s Atom editor team — Sobo himself spent nine years there — Zed emerged as a high-performance, multiplayer code editor built in Rust. When The New Stack tested the beta in 2023, the emphasis was on responsiveness and real-time collaboration; by 2025, AI editing and agentic features had become central to the product.

It has been clear for some time, however, that Zed’s ambitions extend beyond the editor. When the company announced a $32 million round of funding led by Sequoia Capital in August 2025, it also teased DeltaDB, a new kind of operation-based version control system designed to record code changes at edit-level granularity.

Fast-forward to August, and Zed revealed Delta itself in private beta, pitching it as a multiplayer environment where developers can code with agents, share their ongoing threads with teammates and review changes with the original agent context intact.

Wednesday’s public beta launch brings that idea out into the open, and takes direct aim at one of GitHub’s defining features: the pull request.

Picking up the thread

The central concept behind Delta is the thread: a running record of an agent-assisted coding task in which the conversation and the files being changed remain connected. A developer can hand an agent a job, continue discussing and refining it, and later share that entire body of work with somebody else.

Each thread can work against its own copy of a project, which means multiple pieces of work can proceed independently without every agent touching the same checked-out files. Teammates can join an existing thread or create a separate review thread to examine a proposed change, question the agent that produced it and try revisions before feeding accepted changes back into the original work.

DeltaDB sits underneath that model, recording activity at a finer level than Git. Instead of waiting for a developer to package work into a commit, it captures individual events as they happen — including code edits and activity within the conversation — and uses that history to keep participants synchronized.

Zed calls those individual records “deltas.”

Git hasn’t gone the way of the dodo quite yet, though. Delta currently works with Git repositories, and developers can continue using branches, commits and remotes as usual. DeltaDB effectively adds another layer of history between commits, preserving the intermediate human and agent activity that Git would otherwise discard.

“We now build and collaborate on Delta entirely within Delta.”

Sobo notes that Zed has already disabled pull requests on Delta’s own repository and now develops the product through Delta threads instead. Since doing so, the company says 33 developers have landed 570 changes to main without using pull requests.

“We now build and collaborate on Delta entirely within Delta,” he writes.

An intermediate step

It’s worth noting that this is still very much an intermediate step. And for Zed’s own internal development, Sobo expects that intermediary period to be fairly brief. He says the company is only “a few months away” from leaving GitHub behind, with developers focused exclusively on Delta already having little reason to visit GitHub because their conversations, reviews and handoffs now take place inside Delta.

There are still some pieces to disentangle. Zed’s next major dependency is Git storage, which it intends to bring into DeltaDB, while CI and releases also need to move away from GitHub. Sobo sees CI as largely a solved problem, however, and says Zed expects to integrate with existing options rather than build another system simply for the sake of replacing GitHub.

Zed’s main open-source code editor repository will remain in place for now, where an established contributor community already reports problems and proposes code changes. Those contributors can use Delta to expose the agent session behind their work, while still submitting the final change through a conventional pull request, leaving the Git experience unchanged for collaborators who don’t use Delta.

That public repository presents a different problem from Zed’s internal development, given the hundreds of external developers contributing to the project each month.

“We’re moving more thoughtfully with Zed’s public repo because we have hundreds of monthly contributors who depend on that workflow,” Sobo tells The New Stack. “GitHub has an established social component that will take longer to replace, and we’re not going to strand contributors to prove a point. We’re only going to move our community layer when we can offer something better.”

There are other signs of that continued dependency. One item currently on Delta’s roadmap is repository-based access, which will use a GitHub repository’s existing permissions to determine who can access shared Delta threads.

Delta is available as a desktop app for macOS, Linux and Windows, with a browser version for viewing, sharing and reviewing threads. It will remain free throughout the public beta, with paid individual and team plans to follow; Zed says there will always be a free version.

A common thread: Reinventing code collaboration

Of course, Zed is far from alone in tyring to reinvent code collaboration for the agentic era. SpaceX-owned Cursor formally launched Origin in August, bringing Git repository hosting, pull requests and its coding agents under the same roof, while still allowing existing GitHub repositories to remain the source of truth.

GitLab, too, is working on a “next-generation source-code management” project dubbed Project Switch, currently in private beta.

“I believe the thread will replace the commit or branch as the fundamental unit of software development.”

For Sobo, Delta’s claim to differentiation starts with the basic unit around which it’s being built.

“I believe the thread will replace the commit or branch as the fundamental unit of software development,” Sobo explains.

Commits, in his view, will continue to provide useful checkpoints. What they don’t preserve is everything that happens between them: the discussion with an agent, the decisions made along the way and the incremental changes that eventually produce the committed code. That’s the gap Zed wants DeltaDB to fill, with the thread rather than the commit serving as the fuller record of how a piece of software came together.

“Delta’s advantage is that we’re building around the thread from the start, including the infrastructure underneath it,” Sobo continues.

Sobo argues that preserving incremental edits alongside the agent conversation gives subsequent collaborators something a conventional diff cannot: the ability to enter the work where the previous developer left it, and continue interacting with the same agent and context, rather than reconstructing the thinking behind a change after the fact.

Delta’s bet is that the central object of software development should become the ongoing interaction between developer and agent, with the resulting code attached to that history rather than presented later as an isolated diff.

“I expect lots of viable products will compete on the agent experience, with a common infrastructure underneath.”

Sobo expects the next era to echo the structure of the Git era, with competing developer platforms built on top of a common technical foundation.

“On consolidation, we look at how the last era played out. Git became the common foundation because it was open and everyone could build on it,” Sobo says. “GitHub won the layer above through network effects. I expect lots of viable products will compete on the agent experience, with a common infrastructure underneath.”

The post “Everyone’s in a race to replace GitHub”: Zed launches Delta because agents made pull requests obsolete appeared first on The New Stack.

Any business worth its salt in 2026 needs to be embracing the right tools to reach its customers, and few tools carry as much weight as WhatsApp.

Paid messaging on the app crossed a $2 billion annual run rate in the fourth quarter of 2025, CFO Susan Li told investors on Meta’s January earnings call. But getting a business properly set up on WhatsApp can still be a fiddly job. The initial onboarding can send developers jumping between Meta’s account settings, API documentation, and code editor as they connect and verify a phone number, configure webhooks, and get the integration working. Some of that is a one-off job, but things like managing message templates, testing changes, and troubleshooting the setup can bring developers back to those same tools later.

Meta’s answer, announced today, is to let AI coding agents handle much of that setup directly through MCP.

Connecting coding agents with WhatsApp

The easiest way to understand what the WhatsApp Business Tools MCP server is all about, is to look at the sort of job a developer might want to hand over to an agent.

Take an online retailer that wants to use WhatsApp for customer support, order updates or the occasional special offer. A developer can connect the new MCP server to an agent such as Claude or Codex, sign in with their Meta account, and choose which of the businesses they already administer the agent is allowed to access. That access is scoped to whatever businesses they select — connecting the agent doesn’t give it free rein across every Meta account associated with the developer.

Give the agent the number and the display name the business wants to use, and it can handle the steps needed to add the number and set up the WhatsApp account behind it. Meta then sends a one-time verification code by SMS or voice; once the developer gives that code back to the agent, the number can be verified and registered for sending messages.

In a blog post announcing the feature on Tuesday, Zoë Lieberman, who works on product marketing at Meta, says the idea, ultimately, is to turn what might otherwise be a string of separate API tasks into something the user can ask an agent to do in plain English.

“You describe what you want — your agent handles the accounts, numbers, templates, and API calls.”

“You describe what you want — your agent handles the accounts, numbers, templates, and API calls,” Lieberman writes.

A template example

Much of the WhatsApp Business Tools MCP server is concerned with getting a business up and running on WhatsApp in the first place. Message templates, however, show how the agent can remain useful once that initial setup is done.

There is a WhatsApp rule worth explaining, though. When a customer messages a business, it opens a 24-hour customer service window, during which the business can reply with ordinary, free-form messages. Each new message from the customer starts that 24-hour clock again. The idea is to stop businesses turning an old customer conversation into an open-ended channel for unsolicited messages: once the window has closed, the business generally needs to use a message template that Meta has approved if it wants to contact that customer again.

So the retailer could ask the agent to create a marketing template offering customers a coupon, for example, or a utility template for sending order updates. The template can include elements such as a header, body copy, footer and buttons.

From the same conversation, the person using the agent can list the business’s existing templates, pull up a particular version, update it or delete it.

Once the pieces are in place, the developer can ask the agent to send a test message and check that everything behaves as expected before putting it in front of customers. If the recipient is outside the 24-hour customer service window, the agent can flag that a free-form message can’t be sent and offer an approved template instead.

There is also the other half of a WhatsApp conversation to deal with: what happens when the customer replies?

The developer can ask the agent to configure the webhook that tells WhatsApp where to send those incoming messages and other events, such as the retailer’s CRM, customer-support platform, chatbot or order-management system.

The agent can inspect the account as well as change it. That means asking what has already been configured or what still needs attention — for example, whether the business is missing the payment information Meta needs to charge for billable WhatsApp messages.

There are some guardrails around all of this. The agent operates using the access of the person who connected it, and Meta says actions performed through the MCP are recorded.

“Every read runs under your own viewer context, every invocation is logged, and anything that changes state requires an authenticated person rather than an app-level credential.”

“Every read runs under your own viewer context, every invocation is logged, and anything that changes state requires an authenticated person rather than an app-level credential,” Lieberman writes.

Meta’s MCP push stays tied to human identity

That human-bound approach lands amid a broader debate over how AI agents should identify themselves. Agents today often inherit the permissions of the person using them, while some companies are pushing toward giving agents their own scoped, revocable identities — evidenced by Vercel’s recent acquisition of Better Auth. The concept is also showing up in the big cloud platforms, too, such as with Microsoft’s Entra Agent ID, which automatically assigns an identity to agents created in Azure AI Foundry or Copilot Studio. And Amazon Bedrock AgentCore Identity, meanwhile, gives each agent its own identity, letting it act on a user’s behalf or independently, without borrowing anyone’s login.

So while there is a clear push toward giving agents their own identity, Meta is keeping the human firmly in the loop here, The agent can act only within the authenticated user’s existing access, keeping permissions bounded by a known human account and making sensitive changes easier to attribute and control.

It’s also worth noting that this isn’t Meta’s first attempt to put its developer tools within reach of AI agents. In June, the company launched Developer Tools MCP, later rebranded as Meta Social Technologies MCP, which works across Meta’s developer platform — including integrations built with the WhatsApp Business API.

There is some overlap between the two, but they operate at different levels. Meta Social Technologies MCP is the broader developer tool: an agent can use it to discover Graph API endpoints, search Meta’s documentation, inspect the app behind an integration and troubleshoot errors. That can absolutely include a developer building with WhatsApp.

WhatsApp Business Tools MCP, meanwhile, is much more specific to operating WhatsApp Business itself. It gives the agent tools for working with WhatsApp Business accounts, onboarding and verifying phone numbers, creating and managing message templates, configuring and testing webhooks, and sending test messages.

“They’re complementary — install both if you need both,” Lieberman writes.

It’s early days for the new WhatsApp server. Meta says it is rolling out gradually, meaning it may not be available to everyone immediately, while the interface and tools themselves remain in beta and are subject to change.

The post Meta lets Claude and Codex configure WhatsApp Business via MCP. But the agents don’t get their own identity. appeared first on The New Stack.

Everyone knows the open-weight model pitch by now: companies can download the weights, customize them, run them on infrastructure of their choosing, and retain far greater control over where their data is processed — often at a much lower cost than using proprietary models.

Moreover, open-weight models are now thought to trail the leading frontier models by only around four to five months. Nvidia, the world’s most valuable company, is betting heavily on that future. In early September, it agreed to acquire Hugging Face — the sprawling “GitHub for AI” that hosts more than three million models — for $12.9 billion, while pledging to keep the platform open to different models, clouds and computing providers. And on Thursday, Nvidia detailed how Nvidia is using its own open-weight Nemotron model to manage its vast global supply chain in partnership with Palantir.

That power also comes with serious security questions. OpenAI president Greg Brockman recently warned that increasingly capable open-weight models — pointing specifically to China’s GLM-5.3 — could “significantly accelerate the threat landscape” as models with advanced cyber capabilities become freely downloadable and modifiable.

But for businesses accessing those models through third-party services, there is another concern closer to home: where their own data goes when they use those models, particularly when the model originated in China.

China and the open-weight factor

Hugging Face data from February showed models from Chinese developers accounted for 41% of downloads in the preceding 12 months, ahead of the US at 36.5%. Over on OpenRouter, meanwhile, open-weight models now account for around 60% of tokens consumed by US-originating requests, with the company noting that Chinese models constitute the majority.

And that’s why OpenRouter is now giving companies a way to put a geographic fence around that traffic. The AI model marketplace has officially launched US in-region routing into general availability for business and enterprise customers, promising that requests sent through its US endpoint are decrypted, processed and served entirely inside the country — or rejected if that can’t be done.

The feature itself had been quietly available in some form before now, with OpenRouter updating its documentation in early August to say US in-region routing was available to enterprise customers by request. It’s also worth noting that this is in addition to European in-region routing, which it says has been available since October 2025.

Started in early 2023 by former OpenSea CTO Alex Atallah, OpenRouter serves as an interface to the crowded AI model market, with developers able to switch between hundreds of models from myriad providers via a single API. Payments giant Stripe recently announced plans to acquire the company in a reported $8 billion deal, while a slew of other companies including Cursor, Ramp, and Meta, are also building their own model routers.

The reason why model routers are such hot property right now is largely down to economics. Developers have traditionally hard-coded applications to send everything to the same model, while a model router can instead make that choice request by request, sending easier jobs to cheaper models while reserving the pricier frontier systems for the work that actually needs them.

That intermediary role is also what makes OpenRouter’s new residency controls possible: it already decides which provider serves each request, and can now restrict that choice to provider endpoints operating in the US.

Keeping Chinese models inside the US

In a blog post announcing the new feature on Wednesday, Cailee Moberg, who works on OpenRouter’s product team, notes that while US-developed models from Nvidia and Thinking Machines are contributing to the broader open-weight model boom, Chinese models dominate usage and raise tough questions for companies concerned about their data.

“Models from Chinese labs are still most of the [open-weight model] volume, and procurement approval for those models can be difficult.”

“Models from Chinese labs are still most of the [open-weight model] volume, and procurement approval for those models can be difficult,” Moberg writes.

In its 2026 State of AI in the Enterprise report, Deloitte concluded that sovereign AI was on the rise, noting that 77% of companies “now factor country of origin into their vendor selection,” while nearly 60% construct their AI stacks “primarily with local vendors.”

And this at least partly explains why OpenRouter is now offering in-region routing for US customers. Moberg points to DeepSeek V4 Pro, Kimi K3 and GLM 5.2 as specific examples. All three are available through US In-Region Routing because Baseten, Fireworks and Azure serve them from US data centers. Companies could already keep these models inside the US by self-hosting them or using a US provider directly; OpenRouter’s new routing gives its own customers that residency guarantee without having to manage those deployments themselves.

OpenRouter maintains a live list of models eligible for US in-region routing, ranging from proprietary frontier models from OpenAI and Anthropic to open-weight models from the major Chinese labs.

“In-Region Routing allows teams with data residency requirements to get the price and performance gains from Chinese open-weight models,” Moberg continues. “When a US or EU provider hosts a model, requests go to that provider and the lab is not involved.”

“In-Region Routing allows teams with data residency requirements to get the price and performance gains from Chinese open-weight models.”

The technical change happens at the routing layer. With OpenRouter’s standard global endpoint, a request can be served by an eligible provider operating in any region, so even using a model from a US company does not guarantee that the request itself is processed in the US. With us.openrouter.ai, the request is decrypted on OpenRouter infrastructure inside the US and the pool of providers is filtered to endpoints OpenRouter has approved as operating there.

If no compliant US provider can serve the requested model, OpenRouter returns a 404 error. Companies can also enforce the regional restriction through OpenRouter’s Guardrails at the workspace, team or API-key level, while tools that would send prompt data outside the US are disabled on the regional endpoint.

So while none of this ultimately changes where the DeepSeek, Kimi or GLM models are developed, in-region routing alters which copies of those models its US customers can be routed to, and where their prompts are handled along the way.

The post Chinese AI models dominate OpenRouter’s US token consumption. It can now guarantee that traffic stays entirely in the US. appeared first on The New Stack.

OpenAI has hired the founders of Git AI, an open-source tool that tracks how much code AI writes and measures the performance and cost of coding agents.

Taking to LinkedIn late Friday night, Aidan Cunniffe noted that he and his Git AI co-founder Sasha Varlamov will join OpenAI’s Codex team, where they will work on giving businesses better data on how coding agents perform and the returns they generate.

“Same mission, bigger stage,” Cunniffe writes.

While details of the integration plans are scant, OpenAI’s Thibault Sottiaux, a member of technical staff at OpenAI who’s working on ChatGPT and Codex, confirmed on X that the company wants to use Git AI’s technology to help businesses understand Codex’s impact.

“We’ll make it easier for businesses to see where Codex is making a difference when working through problems for individuals and teams,” Sottiaux writes.

Excited to welcome Aidan & @
Sasha from the Git AI team to OpenAI!

They are building in the open and have developed an open-source tool that helps developers understand how coding agents contribute to their codebase.

Together, we’ll make it easier for businesses to see where…

— Tibo (@thsottiaux) September 12, 2026

In a separate blog post announcing the deal on Friday, Cunniffe notes that the tie-up reflects a shared focus on measuring the performance and value of AI coding tools.

“OpenAI shares our belief that users should have the data to compare model performance and understand the ROI of every token they spend.”

“OpenAI shares our belief that users should have the data to compare model performance and understand the ROI of every token they spend,” he writes.

Tracking AI-generated code

Git AI, for the uninitiated, is an open-source Git extension that tracks AI-generated code. Every line of code is linked to the agent, model, and prompts that generated it, preserving the context behind a change even after the code has been committed, merged, or rebased.

More broadly, it’s designed to help teams see how much AI-generated code ultimately reaches production, how often it’s reworked, and where time and tokens are being spent. That data can then be used to compare coding agents and models, and assess whether the money being spent on them is producing useful output.

The tool already supports a broad range of coding agents, including OpenAI Codex, Anthropic’s Claude Code, Cursor, and Google’s Gemini CLI, as well as background agents including Codex Cloud, Claude Web, Cursor Agent, and Devin.

After installation, supported agents automatically report their edits to Git AI. For developers, the pitch is basically: “Just prompt and commit”—they can keep using their coding tools and Git as usual.

Git AI can then show the split between human- and AI-written code and trace individual lines back to the agent that produced them.

The story so far

Cunniffe has, in fact, been here before. He founded developer tooling startup Optic in 2018, which built open-source tools around API development, before Atlassian acquired the company in 2024. He subsequently joined Atlassian as a principal product manager leading go-to-market efforts for developer tools.

Git AI began while Cunniffe was still at Atlassian. He and Varlamov started working on the project in the summer of 2025 as a side project, initially trying to answer one seemingly simple question: how much of their code was actually being written by AI, and what happened to that code afterward?

By the first major release in November, Cunniffe was publicly describing Git AI as a “weekend project” that had grown into something much larger. He subsequently left Atlassian in January 2026 to turn Git AI into a company, building a commercial business around the open-source project.

Now, less than a year later, Cunniffe and Varlamov are heading to OpenAI. It is not yet clear what that means for Git AI as a commercial business, but with both founders joining OpenAI, the standalone business will likely be wound down while the open-source project continues.

The New Stack has reached out to OpenAI and will update this story when we hear back.

Cunniffe, for his part, says OpenAI will continue backing the open-source project.

“We’ll keep investing in open source, while also giving enterprises the data they need to build effective software factories,” he writes.

How that cross-model independence ultimately holds up under OpenAI stewardship will be one of the more interesting things to watch.

The post “Same mission, bigger stage”: OpenAI hires Git AI founders to help Codex prove its ROI appeared first on The New Stack.

Amazon Web Services (AWS) has released a new open-source application dubbed Pizza Bot, which gives developers an email-style inbox for managing AI agents that run in the background.

The problem that Pizza Bot is designed to address, ultimately, is that a chat interface is a poor fit for agents whose work continues after the (human) user has clocked off for lunch or bed.

And so Pizza Bot leans on the age-old mechanics of email: completed jobs arrive as unread threads, while anything that needs a human decision is surfaced for action. An Activity panel also exposes jobs handed off to specialist agents, including their tool use and progress.

“Scheduled agents run autonomously in the background and surface updates directly into your inbox for review and triage.”

Writing about the new project in a LinkedIn post on Thursday, co-creator Joseph Dolivo, principal technologist at AWS Startups, notes that Pizza Bot shifts the burden of monitoring agent work firmly away from the user.

“Instead of you having to initiate every conversation or wait on a prompt, scheduled agents run autonomously in the background and surface updates directly into your inbox for review and triage,” he writes.

As if to emphasize that point, in the accompanying blog post for the project’s official launch on Thursday, the creators note that user absence is, in fact, a core tenet of the design brief.

“The interface assumes you are not watching.”

“The interface assumes you are not watching,” they write. “Nothing else we’ve seen starts there, and that one assumption is what buys you pauses that outlast the session that created them, notifications worth acting on, and scheduled work that produces threads instead of logs.”

A community project

Despite its Amazon roots, Pizza Bot is in fact now a standalone community project rather than an AWS service. It lives in its own GitHub organization, separate from Amazon, and comes with no AWS support or service-level agreement — it’s entirely self-hosted.

Pizza Bot itself is a desktop app for macOS, Windows, and Linux, with browser and terminal clients available too. By default, the app starts a local Pizza Bot server on the machine, while developers choose the model behind it — including Anthropic, Amazon Bedrock, Google Gemini, OpenAI, OpenRouter or a local model via Ollama.

It can also be extended through MCP servers and Agent Skills; the bundled browser-automation skill, for example, uses Playwright MCP to navigate and interact with websites.

The server can also run on an always-on host or in a container, letting scheduled agents keep working while the laptop is closed and their threads be picked up later from another device.

Under the hood: LangGraph and ambient agents

Pizza Bot’s agent runtime is built with DeepAgents, LangChain’s open-source harness for long-running agent tasks, which itself runs on LangGraph, its runtime for stateful agent execution. The important part in all of this is persistence: LangGraph checkpoints an agent’s state as it works, allowing a run to stop for approval, survive a disconnected client and resume later without starting again from scratch. Pizza Bot stores those checkpoints, along with threads and other application data, locally in SQLite and ordinary files.

It’s worth noting that AWS has its own open source agents SDK, Strands Agents, out since May 2025 — but evidence suggests, including text in this sample repository, that AWS considers Strands as a “lighter-weight alternative to LangGraph for agents that don’t need explicit graph control flow.”

In response to a question posted on LinkedIn by The New Stack, Dolivo says that they very well could have used Strands for Pizza Bot, particularly as Strands supports TypeScript and workflows now. But they ultimately went for LangGraph “due to the maturity of the tooling and breadth of the exosystem,” he explains.

“It’s also more familiar to many developers, and we wanted to reduce friction for community adoption since we knew we’d be open-sourcing it,” he adds.

Pizza Bot is also fairly close to an idea LangChain introduced way back in January 2025, when CEO Harrison Chase introduced the term “ambient agents” for agents that could respond to events, work concurrently and involve a human only when needed. LangChain’s reference implementation was an email assistant built on LangGraph. It also developed what it called an “Agent Inbox”: a standalone interface inspired by email and customer-support software for keeping track of open interactions between people and background agents.

From ‘JoeBot’ to Pizza Bot

The genesis of Pizza Bot can be traced back to April 2025, when Dolivo kicked off what he calls a “side-of-desk passion project” dubbed “JoeBot” that automated repetitive CRM logging. He later teamed up with colleague Igor Fil to turn that script into Pizza Bot, an MCP server that could execute parameterized, deterministic “recipes” across its internal systems.

The appeal soon spread beyond the engineers building it into less-technical domains. As the project evolved, Dolivo says it would eventually grow to more than 30 contributors and over 2,000 users inside Amazon, and so Pizza Bot needed a front end that people could open and use.

“An MCP server requires an MCP client, and expecting non-technical users to work out of an IDE or terminal was never going to cut it,” Dolivo adds. “We had to meet people where they actually work and own the experience end to end.”

The result was the version of Pizza Bot released this week: a desktop app built around an inbox rather than a terminal.

The post AWS open-sources Pizza Bot: email-style inbox for background AI agents appeared first on The New Stack.

Nvidia and Palantir announced Thursday that they’re working together to bring “sovereign AI to critical supply chains,” kicking off initially with Nvidia’s own sprawling supply chain.

The news builds on a partnership that kicked off last October, when the duo said they would combine Nvidia’s AI computing and models with Palantir’s software to help companies use AI to make complex operational decisions. Then in June, they expanded that effort into sovereign AI, allowing organizations to run and customize Nvidia’s AI models inside tightly controlled environments while keeping sensitive data and model weights under their own control.

Now, they’re applying that technology inside Nvidia itself, where they say a smaller, fine-tuned model is already outperforming a far larger one.

A proving ground for sovereign AI

The companies have fine-tuned Nvidia’s 30-billion-parameter Nemotron 3.5 Lightning model on decisions made by Nvidia’s supply-chain operations team. Palantir’s Foundry and Artificial Intelligence Platform (AIP) bring together the data behind those decisions, while its Ontology acts as a live map connecting components, factories, capacity and production commitments. Nvidia’s cuOpt software, meanwhile, works out how to distribute scarce parts, with Nemotron weighing the wider context and recommending what planners should do.

They then plan to “extend the learnings from Nvidia’s deployment” to companies in other sectors, including manufacturing, energy, healthcare, automotive and aerospace. Palantir’s own customers will be able to build versions tailored to their own supply chains by training Nemotron on their proprietary data using Foundry and AIP, then run the resulting system on-premises or through cloud and colocation providers.

So, in effect, Nvidia and Palantir are putting the sovereign AI partnership they outlined in June into practice inside Nvidia, while using that deployment as a proving ground for an architecture other companies can adapt to their own use cases.

Nvidia as a test case

As the world’s most valuable public company at a $5.4 trillion market cap, there’s good reason for Nvidia to start close to home. Its supply chain spans millions of parts, thousands of suppliers, and a global network of manufacturing partners, with the company saying a single Vera Rubin rack alone contains some 1.3 million parts. Those components have to arrive in the right place at the right time: if one part is missing, assembly can stall while everything else that arrived sits waiting.

“Supply chains are the operating system of the physical economy, and AI factories are among the most complex systems ever built.

Jensen Huang

And that complexity is what Nvidia founder and CEO Jensen Huang says makes supply chains a natural target for the technology. From chips and memory to manufacturing, networking, power and cooling, he argues that building modern AI systems increasingly depends on coordinating an enormous web of companies and components.

“Supply chains are the operating system of the physical economy, and AI factories are among the most complex systems ever built,” Huang says in a statement.

Palantir co-founder and CEO Alex Karp goes further, arguing that Nvidia’s operations provide an unusually demanding environment in which to put the companies’ approach to the test.

“Nvidia has arguably the most valuable, intricate, and complex supply chain in the world.”

“Nvidia has arguably the most valuable, intricate, and complex supply chain in the world,” Karp adds in a separate statement.

The sovereignty selling point

Nvidia has long been positioning itself at the center of the open-model debate. In July, Huang even used his first-ever post on X to promote an industry letter lobbying Washington to support frontier open-weight models, arguing that they give companies and countries more control over their AI infrastructure.

Then in early September, Nvidia swooped in with a $12.9 billion deal for Hugging Face, the so-called “GitHub for AI models.” Amid concerns that ownership by the world’s dominant AI chipmaker could undermine Hugging Face’s neutrality, Huang pledged that it would remain open, continue hosting models from across the industry and support hardware beyond Nvidia’s own.

Nemotron is central to Nvidia’s own open-model push. The name dates back to 2023, when Nvidia released its first Nemotron-3 8B models for enterprises to customize and fine-tune. Those early models were downloadable through Hugging Face and Nvidia’s NGC catalog, although access was gated and governed by Nvidia’s own community license. So they were customizable, and their weights were available, but the much broader “open model” positioning Nvidia uses today came later.

The current Nemotron 3 series arrived back in December, initially spanning Nano, Super and Ultra models aimed at different agentic AI jobs. Nvidia now publishes weights and, for many of the models, training data and recipes so developers can customize themselves. Nemotron 3.5 Lightning, released in August, is the 30B model Nvidia and Palantir have fine-tuned for this supply-chain deployment.

That openness is also at the heart of the whole sovereignty pitch: companies can adapt Nemotron using proprietary data while keeping that data, the model weights, and inference inside their own environment.

Specialization over size

Nvidia’s own deployment gives outsiders a result to chew on. It says the fine-tuned 30B Lightning scored 86.7% accuracy on its supply-allocation task, versus 55.5% for the 550B Nemotron 3 Ultra—a model roughly 18 times its size.

In a technical blog post published on Thursday alongside the main announcement, Nvidia solutions architects Nell Barber, Rana Haber, and Aastha Jhunjhunwala note that the result shows how far specialization can go. On a tightly defined allocation task, the 30B model outperformed a general-purpose model more than an order of magnitude larger.

“This doesn’t mean the smaller model is more capable overall. Its gains are concentrated in the domain it was post-trained on.”

“This doesn’t mean the smaller model is more capable overall,” they add. “Its gains are concentrated in the domain it was post-trained on. Future production risk forecasting remained difficult despite fine-tuning. Specialization improved the decision task but failed to solve every prediction problem attached to it.

For companies considering Nvidia’s blueprint, the more interesting takeaway may be this: a smaller open model, trained on business specifics, can sometimes be more useful than reaching for the biggest model available.

The post Nvidia and Palantir fine-tune a 30B Nemotron model for Nvidia’s supply chain. It beats a model 18 times its size. appeared first on The New Stack.

AI models now power all manner of agents, from coding assistants that write and debug software to customer service systems that answer questions, process refunds, change bookings, and interact with company systems. But while AI is increasingly central to building these systems, humans still play a major steering role: setting goals, supplying context, choosing architectures, reviewing decisions, and testing the result.

Which raises a more interesting question: what happens when an agent is asked to build another agent entirely on its own?

This is the key question Hyper-𝜏-bench is designed to probe.

Hyper-𝜏-bench asks: How well can AI agents build other agents?

Created and open-sourced in early September by Sierra, the enterprise AI agent company co-founded by tech veteran and current OpenAI board chairman Bret Taylor, Hyper-𝜏-bench builds on the original 𝜏-bench benchmark it introduced back in 2024. But while 𝜏-bench focused on measuring how well a finished agent could interact with users, use tools, and follow company policies, Hyper-𝜏-bench takes it a level up: it evaluates how well an AI developer agent can build that agent in the first place.

Today, most agents are built with the help of other agents like Sierra's Ghostwriter. Yesterday, Sierra open-sourced hyper-𝜏-bench (published as 𝜏^𝜏-bench), a new long horizon agent evaluation that measures how well models can not only act as an agent, but construct one.…

— Bret Taylor (@btaylor) September 9, 2026

In a research paper published on September 4, Sierra researchers tested six combinations of AI model and coding harness. Those included Anthropic models running in Claude Code, OpenAI models in Codex, and Moonshot AI’s Kimi K3 running in both Kimi Code and the open-source OpenCode.

Hyper-𝜏-bench gives a developer agent key materials from a simulated business, such as documents, transcripts, an API, and a codebase, and asks it to build a customer service agent under model and cost constraints. Sierra then tests the finished agent on unseen customer conversations across airline, retail, telecom, and banking, with tasks such as canceling a flight or disputing a fee. It passes when the agent gives the right information and makes the correct changes in the business’s underlying systems. A score of 50%, for example, would mean that the agents succeeded in half of those simulations.

As the leaderboard shows, the best-performing combination was Claude Opus 5 running in Claude Code, at 23.9%, narrowly ahead of GPT-5.6 Sol in Codex at 22%. None of the six autonomous configurations broke 25%.

Low scores alone aren’t necessarily a problem for a benchmark. Tests aimed at frontier AI systems need to be difficult enough to leave room for improvement and to expose meaningful differences between systems; once the best models routinely ace a benchmark, it becomes much less useful as a measure of progress.

What stands out in Hyper-τ-bench’s initial results, however, is the 82.2% “Human + AI reference” bar on the right, which sits far above every autonomous developer. But that comparison comes with an important caveat.

In an accompanying blog post published on Tuesday by Sierra researchers Ben Shi and Keshav Dhandhania, they describe the result as a model being paired with “an engineer with deep context.” The research paper explains this further: the reference agents were hand-built by a benchmark author working with a frontier model and, crucially, with access to the ground-truth requirements that the autonomous developer agents had to discover for themselves.

So while it’s tempting to read the gap as evidence that human support more than tripled performance, Sierra cautions against that interpretation, saying the 82.2% figure is merely an “oracle reference” rather than a measure of average human performance.

Those overall numbers also hide some dramatic differences by task. Claude Opus 5, for example, reached 72.8% on retail, 55.9% on airline, and 48.2% on telecom, before falling to just 5.9% on banking. GPT-5.6 Sol did somewhat better on banking, at 9%. Banking accounts for 35 of the benchmark’s 53 construction tasks. It is by far the most information-heavy domain: its corpus contains 2,969 individual policy facts, and a single task can depend on as many as 580 of them.

Where the agents lose ground

The overall scores only show whether the finished agents worked. Sierra also examined what the developer agents actually did while building them, and found several recurring problems: they often stopped researching the business too soon, asked too few questions when information was missing, made poor decisions about how much computing power the finished agent should use, and showed little appetite for trying different technical approaches.

“The failures mirror ones human agent developers see.”

Importantly, the researchers argue that these weren’t uniquely machine-like mistakes. “The failures mirror ones human agent developers see,” they write in the paper. That makes the results more interesting: the agents could write code and assemble functioning systems, but they were losing ground on familiar engineering problems such as gathering enough information before building, knowing when to ask questions, and exploring alternatives rather than settling quickly on an answer.

The information-gathering problem was particularly stark in banking. Developer agents opened fewer than 80 of roughly 1,700 available files, instead relying heavily on searches to find documents that appeared relevant. That meant they could start building without having uncovered all the business rules the finished agent needed to follow.

Nor did they make much use of the opportunity to ask the business for information that wasn’t in those files. Across the recorded runs, such interactions accounted for just 0.3% of the developer agents’ tool calls. On some tasks, agents could discover 20 to 25 requirements only by asking questions, yet they asked no more than four. Sierra found that asking really did matter: on tasks where its expert-built reference scored between 95% and 100%, builds that asked no questions scored just 5%, rising to 15% after one question and 25% after two.

Cost was another problem. Hyper-τ-bench limits how much the finished customer-service agent can spend on AI model calls while handling a conversation. Two builds exceeded that allowance — by 3x and 1.3x, respectively —and received a score of zero after penalties. Most went too far the other way: among agents that stayed within the limit, average spending was just 45% of the amount available.

Other weaknesses appeared in the technical choices the developer agents made: what kind of agent they built, which model they chose to run it, and, in some cases, whether they tried to uncover parts of the benchmark that were deliberately hidden from them.

There was remarkably little experimentation with different designs, too. Ninety-two percent of builds used a “single LLM tool loop” — essentially one AI model repeatedly deciding whether to respond or call a tool. This also mattered: in one telecom experiment, giving the developer agent a single sentence suggesting a different architecture lifted its score from 31% to 67%.

“Because the system being built is an AI itself, the only way to know if a design works is to run it and read what it says to real users, who the developer never sees while building.”

That creates a blind spot for the developer agent: it has to make design choices without seeing some of the strongest evidence of whether those choices actually improve the customer experience.

“Because the system being built is an AI itself, the only way to know if a design works is to run it and read what it says to real users, who the developer never sees while building,” Shi and Dhandhania write.

And Sierra’s results suggest the developer agents often failed to compensate for that blind spot through enough testing and iteration, instead “shipping the first design that runs.”

On top of that, the agents also tended to favor familiar models. Ninety-six percent of Codex builds chose an OpenAI model to power the finished agent, compared with 13% of builds produced by Kimi. Sierra argues that the pattern suggests developer agents often defaulted to familiar model families rather than testing which option worked best for the job.

Finally, the researchers recorded what they call “cheating-adjacent” behavior in between 17% and 42% of runs, depending on the developer setup. This didn’t mean looking for business requirements they were expected to find; rather, the agents tried things like searching for the benchmark’s hidden test data or probing the grading system—information kept secret so a system cannot simply build to the answers. None of those attempts succeeded, according to Sierra.

Agents build agents

AI is playing a growing role in building agents. Tools such as Microsoft’s Copilot Studio and Salesforce’s Agentforce Builder let people describe an agent in natural language and have AI generate much of its underlying logic.

Sierra itself goes further with Ghostwriter, dubbed the “agent-building agent.” Users can give it instructions, standard operating procedures, transcripts, or recordings and have it build or modify an agent, generate tests, run simulations, and fix problems it finds. Sierra still gives humans the final say: Ghostwriter shows what it has built before anything goes live so it can be reviewed and approved.

Developers can also hand coding agents such as Claude Code or Codex a much broader “build me an agent” task. In all of these cases, though, humans still tend to provide much of the business context, decide what good looks like, and check the result.

Sierra’s own description of agent development helps explain why. Shi and Dhandhania argue that building an enterprise agent, even for people, is often “less like implementing a spec, and more like doing research.”

“Requirements are scattered across handbooks, support, spreadsheets, and the minds of your best frontline reps — so you form a hypothesis, dig up evidence, and build and test to identify which levers actually move performance,” they write.

That is also where Hyper-𝜏-bench’s results become interesting. The autonomous developer agents could write code and produce working systems. Still, they often failed to gather enough information, rarely asked questions when requirements were missing, and experimented little before settling on a design.

And this, perhaps, is why Hyper-𝜏-bench could prove a notable addition to the burgeoning benchmark brigade. AI is already taking on more of the work involved in building agents. The benchmark asks what happens when you remove much of the human guidance that still surrounds that process today—and, at least for now, its results suggest autonomous developer agents still struggle with some of the judgment-heavy parts of the job.

The post Claude performed best on a new benchmark for ‘agents that build agents’. But it passed fewer than a quarter of the tests. appeared first on The New Stack.

Ask a traditional enterprise application for a customer address or today’s revenue figures and, broadly speaking, it follows a predictable route its developers have already mapped out: authenticate the user, query the right system, return the result. Given the same underlying data, you’ll get the same answer each time.

Ask an AI agent the same question, and the journey is much harder to forecast. It might consult one system, decide it needs more context from another, make a dozen tool calls, pass information through a language model and only then produce an answer. Run the same request again, and it may take a different route altogether.

And in an enterprise, what happens along that route can matter just as much as the answer: which systems the agent accesses, what data it sees, what actions it takes and how much it spends.

That distinction — between predetermined software, and applications that make probabilistic decisions on the fly — sits at the heart of a new company from a founder who knows a thing or two about bringing order to a new generation of infrastructure.

AI agents are hard to govern

Dome Systems was co-founded at the turn of the year by David McJannet, who spent close to a decade leading Terraform-creator HashiCorp through the cloud era, culminating in its blockbuster 2021 IPO and subsequent $6.4 billion sale to IBM in 2025. McJannet is joined at the helm by Marc Holmes, who spent more than six years at HashiCorp as chief marketing officer.

In an interview with The New Stack, McJannet lays out his company’s thesis on AI agent governance, arguing that enterprises are now running into the same kind of problem that they did with cloud infrastructure: adoption comes first, then the real spadework begins of putting the right controls in place across security, operations and finance.

“It’s actually a very different architecture, and that is what unlocks the power of these new [agentic] applications.”

Part of the challenge, he says, is that agents are built very differently from the enterprise applications of yore, which companies spent years learning how to control.

“It’s actually a very different architecture, and that is what unlocks the power of these new [agentic] applications,” McJannet explains.

He points to self-driving cars as an example: a model takes in live inputs and interacts with the vehicle’s systems as conditions change, because no developer can reasonably pre-program every possible situation a car might encounter on the road.

“It’s making judgments along the way, as opposed to trying to look up the historical maps of the world and make a real-time decision,” McJannet continues.

An enterprise agent can behave in much the same way: call one tool, assess the result, decide it needs another, and keep going until the task is complete. That flexibility lets agents tackle work that would be difficult to script exhaustively in advance — but it also makes their behaviour harder for enterprises to govern.

And this gets to the heart of what McJannet is striving for with Dome.

Table stakes for the agent era

The company launched out of stealth back in April with $14 million in seed funding, with McJannet having departed HashiCorp the previous August after the IBM transition concluded.

Dome’s starting point is that an agent combines three things: code, a model, and the backend systems or tools it interacts with. Bringing those pieces together under one platform, McJannet says, is “table stakes” for applying meaningful constraints to what the agent can do.

“If you don’t have an integrated platform, you can’t enforce controls across everything that the agent is doing,” McJannet says.

“If you don’t have an integrated platform, you can’t enforce controls across everything that the agent is doing.”

And so Dome’s platform is built around those three elements. An agent registry keeps track of the agents themselves; an MCP gateway controls the tools they can call; and a model broker/router governs which models they can use and how requests are routed.

The setup starts by registering the agent and giving it an identity, establishing who is allowed to call it, and connecting the backend tools it can reach — Zendesk, in this example.

Next, Dome connects a model provider, groups available models into a pool with routing and failover rules, then combines the agent, its tools and its models behind a single gateway. That gateway becomes the point through which Dome can apply the policies governing what the agent is allowed to do.

Once those pieces are connected, teams can set permissions on each call, use guards to inspect responses, apply quotas to cap spending, and keep a common audit trail across the agent’s activity.

Today, McJannet says, enterprises are often piecing all of this together themselves. A standalone model broker might be brought in to control spending, while a separate tool gateway handles security and operational concerns. Some are then building their own agent registry to tie those systems together.

Moreover, buying those capabilities separately leaves enterprises with another integration problem to solve. A model router might govern one part of an agent’s activity and a tool gateway another, while the agent itself continues moving between them.

“If you just provide the tool gateway or just the model router, it doesn’t allow you to have this kind of system of control,” he says.

That is also where Dome’s latest move enters the fray. After spending its first months in early access, the company is now opening the platform to self-service users for the first time, allowing teams to sign up with little more than a credit card, bypassing the typically arduous enterprise sales process.

Dome goes self-serve

Self-serve is relatively unusual route for this kind of enterprise infrastructure product. Dome is publishing its prices, offering a free tier and letting practitioners get started without first going through a sales process, while keeping the traditional enterprise route open for larger customers.

The thinking is partly about who McJannet expects to use the product. Rather than limiting access to buyers who are already deep into a procurement process, for example, self-serve enables individual practitioners to be able to discover, try and use the platform themselves.

“”We want to make the barrier as low as possible to have people come on board,” McJannet says, adding that Dome had already seen a number of self-service sign-ups ahead of the launch.

Separately, its pricing reflects a belief about where value will ultimately sit in this market. McJannet regards model routing and tool connectivity as baseline capabilities, with the more valuable piece being the controls that sit across the agent as a whole — think permissions, data redaction and spending quotas.

It’s also worth noting that while Dome’s main target user will be platform engineering teams inside large enterprises, typically working alongside operations and security, self-serve also creates an opening for another kind of user: the small company, perhaps even only one or two people, building an agent and trying to sell into an enterprise. The sort of scenario that aligns with the fabled one-person unicorn promised by many in the AI realm.

Indeed, McJannet says developers can get far building the application itself, only to hit a wall when a prospective enterprise customer begins its security and operations review. How is identity enforced? Who can see the data the agent reaches? What happens when it calls other agents? Can its activity be reconstructed afterwards?

Some builders, he says, have asked whether they can “certify” their agents on Dome because “my agent won’t get deployed until I can satisfy these infrastructure elements.” McJannet is careful to add that Dome doesn’t currently run such a certification program, but it’s clearly one route the company could venture down.

“If you register that agent on Dome, all the infrastructure elements are taken care of,” McJannet says.

‘Unblocking AI agents’: Lessons from the cloud era

That division between developers eager to ship, and enterprise teams worried about what happens after, is also where McJannet sees the strongest parallel with his years at HashiCorp.

During McJannet’s tenure, HashiCorp increasingly positioned itself around helping large organizations standardize how cloud infrastructure was provisioned, secured and connected. That included the 2020 launch of HashiCorp Cloud Platform (HCP), which offered its infrastructure tools as managed cloud services.

More broadly, McJannet’s account of early cloud adoption begins with developers swiping a credit card and deploying directly to Amazon because cloud infrastructure allowed them to build applications that had previously been impractical. The applications were compelling enough that enterprises adopted cloud despite resistance from operations and security teams, and what followed was a second phase: companies needed common services for provisioning, credentials, networking and other controls before cloud could become routine across the organization.

Platform engineering teams became the people responsible for reconciling those two demands: allowing developers to build while giving security, operations and finance enough control to permit those applications into production. McJannet believes agents are now creating the same tension.

“You’ve got this queue of cool apps that developers build that the ops and security teams are just not comfortable letting flourish in their environments.”

“You’ve got this queue of cool apps that developers build that the ops and security teams are just not comfortable letting flourish in their environments,” he says. “And so, inevitably, it has to go that same direction where the platform engineering team has to figure out [a way] to get to say ‘yes’.”

Dome’s bet is that enterprises will eventually prefer one system spanning the entire agent to a patchwork of gateways, routers and security products. In McJannet’s telling, that common control layer is what gives enterprises a way to limit how far an agent can roam while still letting it act autonomously.

“You have to have this control layer that provides this corridor where we can constrain the behavior of that new type of application architecture,” he says. “Because without that, you cannot unblock the deployment of AI applications.”

“That’s the part that we’re trying to answer — how do we unblock agents at scale?”

There is still plenty for Dome to prove. The company isn’t naming customers at this stage; McJannet says none of the enterprises it has worked with are yet willing to be identified publicly, though he says Dome has spent the past eight months talking to dozens of them.

Ultimately, McJannet believes the cloud era showed that new applications only become commonplace once enterprises have the controls to let them through. Dome is his attempt to solve that problem for agents.

“I think that’s the part that we’re trying to answer — how do we unblock agents at scale?”

The post After nine years as HashiCorp CEO, Dave McJannet now wants to “unblock” enterprise AI agents appeared first on The New Stack.

Just days after OpenAI launched its newest and most powerful model dubbed Astra, which the company said marked the arrival of the “AGI era,” the company’s chief scientist has called for the AI industry to slow down until shared safety standards exist.

On Sunday, Jakub Pachocki, who joined OpenAI in 2017 as research lead before ascending through the ranks to become the company’s chief scientist in 2024, published an essay called “An Alien Mind,” where he argues that modern AI systems are growing too complex for even their own builders to fully understand, and that OpenAI’s methods for keeping models aligned with human intent — and for monitoring them for warning signs — are struggling to keep pace with how capable those systems are becoming.

Citing internal data, Pachocki states that he has a “strong expectation” that the current pace of progress could be sustained all the way into “recursive self-improvement” (RSI). By that, he means a point where AI systems start meaningfully helping develop increasingly capable successors. And this is more than a prediction about where the technology may be headed: Pachocki says OpenAI is deliberately focusing its research toward RSI because it believes doing so will be necessary to remain at the frontier of AI research.

In a separate report published the same day, OpenAI said AI agents are already taking on increasingly substantial chunks of its own research, and that it’s now working toward an “automated AI researcher” capable of helping improve future AI systems.

“If AI development continues along its current path, the systems we’ll see in the next few years are likely to represent further capability jumps of equal or larger magnitude, and to increasingly drive their own development,” Pachocki writes.

Part of what worries him about that path, in particular, is that even a maliciously instructed AI may not stop at carrying out the task it was given. Pachocki argues that more capable agents could go beyond their operators’ intentions, making it increasingly difficult to separate deliberate human misuse from harmful behavior the AI chose for itself.

“We may be used to thinking of AI as tools, but some agents will be pursuing their own objectives. They will find ways to collaborate with people, by bargaining with, tricking or blackmailing them.”

Jakub Pachocki

“We may be used to thinking of AI as tools, but some agents will be pursuing their own objectives,” he continues. “They will find ways to collaborate with people, by bargaining with, tricking or blackmailing them.”

Pachocki also argues that more capable AI may be needed to defend against these rogue agents, secure critical infrastructure and respond to AI-enabled threats such as engineered pathogens. But he warns that the need to build those defensive systems can’t become an excuse to race ahead regardless of the consequences.

“The idea of racing forward at all costs seems absurd once one internalizes the seriousness of the stakes,” Pachocki adds.

Broadly (mis)aligned: Seeking ‘voluntary slowdowns’

Pachocki’s warnings come hot on the heels of a number of incidents involving increasingly autonomous OpenAI agents. Reports emerged on Friday that OpenAI agents had hijacked a German community wiki back in May, using it as their own message board and making roughly 15,000 edits — an incident OpenAI later confirmed on X.

In July, one of OpenAI’s own agents escaped a sandboxed test and broke into Hugging Face’s systems. Then in early August, the company said its upcoming Astra model may have crossed into “Critical” territory for cybersecurity risk, the highest tier in its own safety framework, before going on to announce that it had paused reinforcement learning (RL) training on its newest models.

(Mis)alignment has been the word running through nearly all of this. Broadly, alignment means getting an AI system to behave in line with human intentions and values. In its own accounting of the wiki incident, OpenAI called it “an instance of misalignment similar to the ones we’d [previously] shared,” lumping it in with the Hugging Face breach. The same word dominated its August 18 account of the RL training pause: some variation of “aligned” or “misaligned” appeared 16 times in OpenAI’s announcement.

Pachocki, for his part, also leans heavily on alignment, arguing that the two broad approaches currently used to steer models toward desired behavior — reinforcement learning and techniques that draw on what models learn during pretraining — both have weaknesses. Even its go-to tool for catching bad behavior, reading through a model’s own reasoning, is growing less reliable as models get smarter.

He also stresses that OpenAI is still making progress, describing Astra as “significantly better aligned” than GPT-5.6 Sol, while warning that advances in alignment may still fail to keep ahead of gains in general intelligence.

“I expect and hope for voluntary slowdowns to become commonplace until shared safety bars are established. And I believe that international coordination on future AI development needs to become a top priority for governments around the world.”

And all this, ultimately, is why he asks for an industry-wide “slowdown” until these issues are resolved.

“Currently I believe that no lab has solved alignment and monitoring to a sufficient degree to continue responsibly scaling at maximum speed for much longer,” he writes. “I expect and hope for voluntary slowdowns to become commonplace until shared safety bars are established. And I believe that international coordination on future AI development needs to become a top priority for governments around the world.”

In terms of what those “shared safety bars” might actually look like, Pachocki names Anthropic’s “Responsible Scaling Policy” alongside OpenAI’s own “Preparedness Framework” as the kind of voluntary commitment that should become mandatory, enforced by outside auditors, government agencies or international bodies.

A change in tone

Anthropic, OpenAI’s arch-rival in frontier AI, has long been the more willing of the two to publicly warn about catastrophic risks from increasingly autonomous systems. In June, it warned that RSI could eventually leave humans struggling to control the systems they had created, and argued that a coordinated slowdown would be desirable if it could be made to work.

That posture has also earned Anthropic plenty of critics. Entrepreneur and prominent venture capitalist David Sacks accused the company last year of running a “sophisticated regulatory capture strategy based on fear-mongering,” arguing that its push for tighter AI rules would burden smaller rivals.

OpenAI’s recent public messaging, by comparison, has often leaned more heavily on presenting AI as a useful tool, making Pachocki’s essay notable to some industry observers. On X, anonymous software engineer Tenobrus welcomes what he sees as a change in tone, arguing that OpenAI had previously been eager to distance itself from the safety warnings associated with Anthropic.

Yeah – I liked this take from you https://t.co/WHqPydT9S9 – glad to see them stepping back from the "ai is just a tool" framing, there is no way that would stand up to the future

— Sholto Douglas (@_sholtodouglas) September 6, 2026

Sholto Douglas, a member of technical staff working on reinforcement learning at Anthropic, agrees with that assessment. “Glad to see them stepping back from the ‘ai is just a tool‘ framing, there is no way that would stand up to the future,” he writes.

Separately, Douglas also calls Pachocki’s essay a “Great post,” adding that Anthropic was “lucky to have such competitors.”

“Glad to see them stepping back from the ‘ai is just a tool’ framing.”

Others were less impressed though. David Shapiro, a YouTuber and author focused on the potential economics of a post-labor world, argues that the “Alien Mind” title alone “smacks of typical hype- and fear-based marketing.” His broader criticism is that Pachocki had largely restated alignment and interpretability concerns researchers have discussed for years: the central point, in Shapiro’s view, is that AI development could move faster than alignment efforts can keep up, rather than that researchers have suddenly discovered an unknowable form of intelligence.

Such dismissals still concede a key underlying point, however: speed outrunning alignment is roughly what played out this summer, from the wiki hijack to the Hugging Face breach. It’s also the scenario Pachocki’s requested slowdown is meant to head off, before agents start bargaining, tricking or blackmailing their way past the people meant to be in control.

The post “Some agents will be pursuing their own objectives”: OpenAI’s chief scientist warns AI could trick and blackmail humans appeared first on The New Stack.

Nvidia has confirmed that it’s agreed to acquire Hugging Face in a mammoth $12.9 billion deal that will bring one of the AI industry’s most important open-model platforms under the auspices of the world’s dominant AI chipmaker — and, with a market cap of well over $5 trillion, the most valuable company on Earth.

When reports first emerged in August that Nvidia was lining up a gargantuan bid for what has often been described as the “GitHub of AI Models,” concerns quickly surfaced over what the deal could mean for the platform’s openness and hardware neutrality. As The New Stack reported at the time, Hugging Face’s value lies partly in giving developers a neutral place to find and deploy open models across Nvidia, AMD, Intel and cloud accelerators — raising the question of what happens if that platform is owned by just one of them.

Keeping Hugging Face open

That, ultimately, is why Nvidia founder, president and CEO Jensen Huang is going to great lengths to allay fears that Hugging Face could become a vehicle for steering developers toward Nvidia’s own hardware and software stack.

“Nvidia compute will not be required to build on or deploy through Hugging Face.”

In the official announcement on Thursday, Huang makes a series of explicit promises around neutrality, noting that Hugging Face would “remain an open platform for the entire AI ecosystem,” continue to support multiple clouds and accelerators, while stressing that “Nvidia compute will not be required to build on or deploy through Hugging Face.”

“Hugging Face will continue to support open source and open weight models from across the ecosystem, from every model builder,” Huang writes. “It will continue to support multi-cloud and multi-accelerator development and deployment, so builders can use the hardware and infrastructure that best fit their work.”

Indeed, it’s clear Nvidia had clocked the concerns around the impending acquisition. The word “open” appears no fewer than 19 times in Huang’s relatively short announcement, underlining just how central that reassurance is to Nvidia’s pitch for the deal.

Huang also points to a recent open letter on open weights that he co-signed alongside executives and researchers from across the AI industry, including those from Hugging Face. The letter argued that open-weight models are critical to broadening access to AI, strengthening competition and giving developers more control over how models are deployed and adapted.

For what it’s worth, Nvidia has been pushing hard into open-weight AI itself, including through its Nemotron models and a broader effort to make frontier-class models easier to run locally. Hugging Face co-founder and CEO Clément Delangue went so far as to call Nvidia the “King of American open-source AI” a few months ago, pointing to its growing collection of public models, datasets and Spaces on Hugging Face.

In the wake of the announcement on Thursday, Delangue doubled down on that position in a fresh post announcing the deal, arguing that Hugging Face has reached the point where keeping open-source AI competitive would require substantially more resources.

“It needs more compute, more support, more collaboration and more visibility.” – Hugging Face CEO Clément Delangue

“10 years after starting Hugging Face, open-source AI is at an inflection point,” Delangue writes on LinkedIn. “Thanks to the community, we’ve shown that it can be a complement, and even an alternative, to closed-source APIs. But for it to happen at larger scale, it needs more compute, more support, more collaboration and more visibility.”

He adds that Nvidia has committed to backing Hugging Face while keeping the platform open, independent and compute-agnostic, with the founders and existing team staying on.

“Together, we think we can make open source the default way to build AI,” Delangue writes, setting out a goal of helping 100 million AI builders “own their intelligence rather than rent it.”

GitHub as a historical precedent

However, there is some historical precedent for taking such assurances with a degree of caution. When Microsoft bought GitHub for $7.5 billion in 2018, it similarly promised that the platform would remain independent and open. GitHub largely retained that openness, though Microsoft’s later use of public GitHub code to help train the proprietary, paid Copilot service sparked a backlash among factions of the open-source community.

In truth, that obvious comparison may actually understate Nvidia’s challenge. In recent analysis for Forbes, technology analyst Janakiram MSV argues that neutrality at Hugging Face has a hardware dimension that GitHub never had to contend with. Hugging Face maintains integrations spanning AWS Trainium and Inferentia, Google TPUs, Intel Gaudi, AMD Instinct and other accelerators. Under Nvidia ownership, continued support for those rival chips becomes a real test of just how neutral the platform will remain in the long run.

Not a done deal yet

As for the acquisition itself, well, it’s not over the line quite yet. In a filing with the US Securities and Exchange Commission (SEC), Nvidia notes that it expects the deal to close in the first half of 2027, subject to customary closing conditions and regulatory approvals. Given Nvidia’s lofty position in AI infrastructure and Hugging Face’s role as a major distribution point for open models, those approvals are unlikely to be a mere formality. Nvidia’s filing also flags the possibility that future regulation around open-source AI could affect Hugging Face’s operations or increase compliance costs.

“Hugging Face [will] continue to permit model makers, developers, and users to upload and download models and datasets of their choosing and to support other silicon vendors.”

Notably, Nvidia also uses its SEC filing to reaffirm its neutrality commitments, stating that under the commitment, “Hugging Face would continue to permit model makers, developers, and users to upload and download models and datasets of their choosing and to support other silicon vendors.”

Of the roughly $12.9 billion headline price, about $11.9 billion will go to Hugging Face stockholders, with up to $1 billion earmarked for equity-based retention awards for employees joining Nvidia.

And while the headline price is usually rounded to $12.9 billion, the actual figure is an oddly specific $12,930,300,000. That’s no accident either, as Hugging Face co-founder Thomas Wolf alludes to in a LinkedIn post. For those still in the dark, 129303 is the decimal Unicode value for the 🤗 emoji, while #129303 is a green color code nodding to Nvidia’s branding.

A neat little Easter egg buried inside what can only be described as one of the biggest AI deals of the year.

The post “Hugging Face will remain an open platform”: Nvidia strikes $12.9B deal for the ‘GitHub of AI’ appeared first on The New Stack.

It has been a big week for Meta in the AI sphere, formally launching its Muse Code coding agent out of beta with a triumvirate of new subscription plans. Then late on Wednesday, the company unveiled Muse Spark 1.3, the latest version of its low-cost reasoning model, with Meta claiming its biggest gains yet in coding and agentic tasks.

Available through Muse Code and the Meta Model API, Muse Spark 1.3 is the latest iteration of the reasoning model Meta first introduced in April, and arrives less than a month after the release of Muse Spark 1.2. Meta CEO Mark Zuckerberg took to social media to hype the new release, describing it as delivering “frontier performance almost too cheap to meter.”

“This is the biggest jump we’ve made so far on coding and agentic work.”

“This is the biggest jump we’ve made so far on coding and agentic work,” Zuckerberg writes on X.

Open-weight release ‘coming soon’

Zuckerberg also confirmed that the open-weight releases of Muse Spark will be “coming soon,” a move that could let developers download and run the model on their own infrastructure, bypassing Meta’s hosted API.

Exactly how permissive that will be, however, isn’t clear, as Meta has yet to publish the licence terms that will accompany the release. Its previous open-weight models have carried varying restrictions on use, so those details will determine how freely Spark can be modified, redistributed or deployed.

Notably, Zuckerberg also teased Meta’s much-hyped next model, codenamed Watermelon, using the somewhat apt watermelon emoji.

Muse Spark 1.3 is rolling out today with frontier performance almost too cheap to meter. This is the biggest jump we've made so far on coding and agentic work. Try it in Muse Code and our API.

Next up 🍉 and Muse Spark open weights releases coming soon. pic.twitter.com/XQQEDEJGD7

— Mark Zuckerberg (@finkd) September 2, 2026

That model is understood to be a much larger system than Spark and was reportedly still in training in July, according to a Business Insider report at the time. There is still no firm word on when Watermelon will see the light of day, though the implication from Zuckerberg is that it won’t be long.

For now, though, Meta is making some sizeable claims for Spark 1.3 itself. Zuckerberg accompanies his post with a benchmark table pitting the model against OpenAI’s GPT-5.6 Sol and Anthropic’s Claude Opus 5 across coding, agentic, computer-use and long-context tests.

Among the standout figures, Muse Spark 1.3 scored 75.4% on the DeepSWE coding benchmark and 98.1% on the 512K-1M version of the MRCR long-context test.

These are Meta-assembled results, however. The company says its Spark 1.3 scores were generated through the Meta Model API, while comparison figures are drawn from a mixture of Meta’s own evaluations, official leaderboards and results reported by rival model providers. Meta also describes its testing of third-party models as “best-effort,” meaning the table shouldn’t be read as a single independent head-to-head test conducted under identical conditions

There is another caveat to these results: Meta ran Spark 1.3 at its new “max” reasoning level for the headline comparisons, while the highest reasoning level generally available to developers today is “xhigh.” Max remains in limited preview while Meta completes additional safety testing.

“Gloves are off”: How Spark 1.3 stacks up

Independent testing by Artificial Analysis does offer a useful outside perspective. The San Francisco-based company, which specializes in benchmarking AI models and providers, gives the publicly available Muse Spark 1.3 xhigh a score of 61 on its Intelligence Index, four points ahead of Spark 1.2 and level with GPT-5.6 Sol max, Grok 4.6 high and Claude Opus 5 high. It was also able to test the limited-preview max version, which scored 62, placing it behind only Claude Fable 5.1 and Claude Opus 5 among the models in its comparison at launch.

Alex Volkov, AI evangelist at cloud infrastructure company CoreWeave, points to the chart as evidence of how quickly Meta has closed the gap with the leading models.

“Damn, gloves are off!,” Volkov writes on X, calling the showing “quite the statement” from Meta while predicting “busy weeks ahead of us!”

“Damn, gloves are off!”

Cost is another part of Meta’s pitch. Artificial Analysis describes Spark 1.3 xhigh as the “most cost-efficient model” at its level of measured intelligence, with its combination of a 61 Intelligence Index score and comparatively low per-task cost placing it on the company’s Pareto line.

Artificial Analysis calculates that Spark 1.3 xhigh costs around $0.55 per Intelligence Index task, the lowest of any model scoring 59 or higher on its index. GPT-5.6 Sol max and Grok 4.6 high, both tied with Spark at 61, came in at $0.95 and $0.94 respectively.

Spark 1.3 was still more expensive per task than Spark 1.2’s $0.40, with Artificial Analysis attributing that increase largely to the newer model consuming around 57% more input tokens on agentic evaluations.

Muse meets Gemini: A ‘playground slapfight’

It’s worth noting that shortly before Meta unveiled Muse Spark 1.3, Google released a new low-cost model of its own: Gemini 3.8 Flash, its third Flash release in just six weeks. Google also pitched its model as its best reasoning and coding Flash model yet, while keeping introductory pricing at $0.75 per million input tokens and $3.75 per million output tokens.

Artificial Analysis initially placed Gemini 3.8 Flash (high) on its Intelligence-versus-Cost Pareto frontier — essentially the group of models for which there is no alternative that is both more capable and cheaper. Gemini scored 59 on the Intelligence Index at a cost of $0.58 per task.

However, just a few hours later, Muse Spark 1.3 xhigh arrived at 61 and $0.55 per task, beating Gemini 3.8 Flash on both measures and pushing it off that frontier.

“Google was ahead only a few hours.”

This point was not lost on many in the AI community. Indeed, AI researcher Benjamin Marie notes on X that “Google was ahead only a few hours.

Google was ahead only a few hours.

And Meta will release the weights. https://t.co/nEZU29qM1o

— Benjamin Marie (@bnjmn_marie) September 2, 2026

Florian Brand, a research engineer at AI infrastructure and research company Prime Intellect, also sums up the turnaround succinctly.

“Gemini 3.8 held a spot at the pareto frontier for *checks notes* 3.5 hours,” Brand writes on X.

And none other than Meta’s chief AI officer himself Alexandr Wang weighed in, taking the time to cast shade at Google off the back of the Artificial Analysis report.

i really hate to say it, but…

gemini who? 🏎️💨 https://t.co/Umv4CVqgre

— Alexandr Wang (@alexandr_wang) September 2, 2026

However, Corey Quinn, co-founder and chief cloud economist at cloud and AI cost management company Duckbill, is quick to mock the exchange, suggesting that neither Meta nor Google are meaningfully setting the pace in the AI arms race.

“Meta casting shade at Google in AI is a playground slapfight outside a MMA championship,” Quinn writes on X.

Muse Code enters the scene

For context, Muse Spark 1.3 is the fourth version of the model Meta has shipped since April, and follows Muse Spark 1.1 in July and 1.2 the month after. Arguably the more important part of Meta’s push, though, is the agent harness it’s building around the model.

That comes in the form of Muse Code, Meta’s terminal-based coding agent, which arrived in beta alongside Spark 1.2 in early August. It officially launched on Tuesday, replete with new subscription plans starting at just $5 per month and a new SDK also hitting developer preview.

So while Meta is clearly trying to compete with the frontier labs on model quality, evidenced by the gains in the Muse Spark lineup, it’s also chasing them a level up, where Anthropic’s Claude Code and OpenAI’s Codex have set the pace for how developers actually work with an agent day to day.

And this explains why so much of the 1.3 release language centers on coding and agentic work specifically. The model is a key piece of a broader developer platform Meta is now pushing hard on price as much as capability.

The post “Google was ahead only a few hours”: Muse Spark 1.3 edges out Gemini as Meta claims its biggest coding leap yet appeared first on The New Stack.

Meta has formally launched Muse Code out of beta, less than a month after first debuting the coding agent.

Alongside a host of new features and an SDK, Meta has introduced a trio of new subscription plans ranging from $5 to $50 per month, adding predictable monthly pricing to a product that already stood out at launch for aggressively undercutting rival coding agents on cost.

Meta’s answer to Claude Code

Powered by Meta’s own Muse Spark 1.2 model, Muse Code is effectively Meta’s answer to Anthropic’s Claude Code and OpenAI’s Codex: a terminal-based coding agent designed to handle complex software engineering tasks across large codebases.

In its initial guise, Muse Code already included asynchronous background agents that remain active throughout a coding session to gather information and support the main agent. Meta also pitched it as capable of handling long-running engineering tasks across large repositories, from planning a change through to writing and validating the code.

For its full public launch, Meta has added several new capabilities. One is inter-session messaging, which lets separate Muse Code sessions share context and state directly when their work overlaps.

On top of that, Meta has also introduced Workflows, which builds on the existing multi-agent capability by orchestrating teams of specialized agents across larger jobs, carrying intermediate work between stages and returning a single result at the end. Developers can also monitor and steer the agents through a dedicated Workflows control room.

Another notable addition is a rewind feature, which allows developers to roll back the conversation and code changes to an earlier point in a Muse Code session.

The pricing factor

One of the more contentious aspects of Muse Code at launch was its pricing setup. At the time, Meta offered two pay-as-you-go tiers. Its Standard tier charged $1.25 per million input tokens and $4.25 per million output tokens, while the so-called “Contributor” tier scythed those rates to just $0.10 and $0.20, respectively. The catch, of course, was that Contributor users had to opt in to having their prompts and completions used to help improve Meta’s products, a trade-off several engineering leaders told The New Stack at the time would rule it out for their proprietary code.

“One of the more contentious aspects of Muse Code at launch was its pricing setup.”

Price doesn’t tell the whole story, however. The New Stack ran Muse Code and Claude Code through the same three coding tasks. While Muse Code cost much less, it consumed substantially more tokens and produced a weaker result on a refactoring task, leaving dead code behind on another. That raised a broader question around how much its price actually tells developers about the cost of getting useful work done.

With the full launch, Meta has introduced a trio of subscription tiers alongside its existing pay-as-you-go options.

The Everyday Usage plan costs $5 per month; High Usage costs $15 and promises three times as much usage; and the $50 Power Usage plan offers 10 times as much usage. Meta says the $5 plan typically provides 10 to 50 requests every 5 hours, though the number varies with the complexity of the work.

That puts Muse Code well below its main rivals on headline subscription price. Anthropic includes Claude Code with its $20-a-month Pro plan, while its $100 Max 5x and $200 Max 20x plans provide 5x and 20x Pro’s per-session usage, respectively. OpenAI follows a similar approach: Codex is included with the $20 Plus plan, while its $100 and $200 Pro tiers provide 5x and 20x the usage of Plus, respectively.

However, the actual amount of coding work those plans buy is harder to compare. Anthropic doesn’t currently publish an absolute number of Claude Code prompts for Pro, Max 5x, or Max 20x; instead, it expresses the two Max allowances as multiples of Pro. It also applies five-hour and weekly limits. OpenAI, on the other hand, is a little more helpful with its pricing page: For GPT-5.6 Sol, it estimates 10–100 local Codex messages every five hours on Plus; 50–500 on Pro 5x; and 200–2,000 on Pro 20x. Even then, OpenAI says actual usage varies with factors such as the model, task complexity, context, reasoning, and tools, so Meta’s 10-to-50-request estimate still doesn’t translate neatly into an apples-to-apples comparison.

“After all the Claude and ChatGPT usage-limit drama, this is refreshingly simple.”

Muhammad Navaid, a senior machine learning engineer, took to social media on Tuesday to highlight the simplicity of Meta’s proportional pricing structure, in which each price increase maps directly to the advertised increase in usage. “After all the Claude and ChatGPT usage-limit drama, this is refreshingly simple,” he writes on LinkedIn. “And honestly, this is how AI coding subscriptions should work.”

Others were less enthusiastic about what such low prices might ultimately mean. Ashok Gelal, co-founder and CEO of Msty AI, describes the pricing as “unbelievably low,” but hints at the data concerns that accompanied Muse Code’s original launch.

“The biggest concern here is Meta itself,” Gelal writes on X.

Muse Code is now available. The pricing war continues and this is unbelievably low. The biggest concern here is Meta itself. It has one business – showing you ads so this pricing could just be to get more data to sell back more ads to you. pic.twitter.com/8fZjels1T3

— ashokgelal (@ashokgelal) August 31, 2026

Building on Muse Code

While the new subscriptions change how developers pay for Muse Code, another aspect of the public launch expands what they can do with it. A new SDK, currently in developer preview, extends Muse Code beyond its command-line interface.

In a post on X, Mark Zuckerberg notes that the aim is to enable developers to build their own agents on Muse Code.

“Embed them in your apps, connect custom tools, stream progress, and resume sessions later,” Zuckerberg writes.

Muse Code is out of beta and now built to handle bigger, more complex engineering tasks. Developers can get started with one command today:

curl -fsSL https://t.co/0RApZrEJMv | bash

— Mark Zuckerberg (@finkd) August 31, 2026

In real terms, the SDK lets developers control Muse Code programmatically—meaning their own software can start and resume sessions, send instructions, handle responses, and respond to what the agent does, rather than requiring someone to operate Muse Code manually via the terminal. That could support everything from IDE integrations and internal engineering tools to standalone agentic products built on top of Muse Code.

Meta isn’t alone here. Anthropic’s Claude Agent SDK similarly lets developers build applications around Claude Code’s capabilities, while OpenAI offers a Codex SDK for embedding its coding agent into other tools and services.

Meta has also published the Muse Session Protocol (MSP), the underlying protocol that external clients use to communicate with Muse Code sessions. Developers can use Meta’s TypeScript SDK or implement MSP directly in another language.

The broader significance, perhaps, lies in how quickly Meta is opening Muse Code to third-party development. Less than a month after launching the CLI in beta, it’s already giving developers the tools to embed Muse Code in their own interfaces, applications, and agents.

Meta may be moving fast because it has to. Claude Code and Codex already have a head start, leaving Muse Code with little choice but to compete hard on price and features.

The post Meta’s Claude Code rival exits beta with three new subscription tiers — and it’s pushing hard on price appeared first on The New Stack.

OpenAI caused something of a stir over the weekend when it announced plans to cut Cursor’s direct access to OpenAI models in November.

The reason? Elon Musk.

In a statement issued late on Friday, OpenAI pointed to two previous incidents involving Musk’s companies: Twitter breaking the terms of a data-licensing deal after Musk’s 2022 takeover of the social network, and Musk’s admission under oath earlier this year that xAI had partly used OpenAI models through distillation — conduct OpenAI says violated its terms of service. And now that SpaceX’s $60 billion deal to acquire Cursor has closed, OpenAI’s attentions are turning to Cursor.

“This decision was incredibly tough, as we care deeply about our models being broadly available for developers,” the company wrote. “We are making this choice because we cannot be confident that SpaceX will use our technology within our terms of service, based on our experience with Elon Musk’s companies violating contracts.”

While that in itself was big news for anyone following the day-to-day rough and tumble of the AI industry, what was particularly notable was the response of OpenAI’s arch rival.

The Anthropic factor

As The New Stack noted in its coverage, Anthropic co-founder and “chief compute officer” Tom Brown moved fast, posting publicly within hours of OpenAI’s statement to confirm that it continues to see Cursor as a “trusted partner,” and will “continue to increase compute to support Claude models in Cursor.”

Cursor has been a trusted partner of Anthropic since Sonnet 3.5. We’ll continue to increase compute to support Claude models in Cursor and are excited for what comes next with them at SpaceX.

— Tom Brown (@NotTomBrown) August 29, 2026

But anyone who has followed Anthropic’s recent history could be forgiven for wondering why.

Take Windsurf. In May 2025, reports emerged that OpenAI was in talks to buy the AI coding tool for $3 billion. Anthropic didn’t hang around for the deal to close though, and within weeks, Windsurf said Anthropic had cut its direct access to Claude 3.5 Sonnet and Claude 3.7 Sonnet.

Speaking at an event hosted by TechCrunch shortly after, Anthropic co-founder Jared Kaplan said that “it would be odd” for Anthropic to be selling Claude to OpenAI. As things transpired, the OpenAI deal fell through, and Google stepped in instead, paying $2.4 billion to hire Windsurf’s founders and R&D staff into DeepMind.

“They cut them off ruthlessly when RUMORS of OpenAI potentially buying Windsurf surfaced.”

In a social media post published on Sunday, Gergely Orosz, engineer and author of the Pragmatic Engineer newsletter, is quick to highlight the episode with Windsurf, which he noted had also been a “trusted partner” with Anthropic for some time. “They cut them off ruthlessly when RUMORS of OpenAI potentially buying Windsurf surfaced,” Orosz writes. “Now, SpaceX, an Ant(hropic) competitor bought Cursor — it’s still a trusted partner?”

Then there’s xAI, the AI company Musk founded in 2023 to build Grok, which SpaceX acquired outright in a February transaction valuing xAI at $250 billion. In January this year, Kylie Robison reported that Anthropic had cut xAI staff off from Claude, which they’d been accessing through Cursor — with Cursor reportedly telling xAI it was “a new policy anthropic is enforcing for all its major competitors.”

So Anthropic has previous form for moving fast, on rumor alone in Windsurf’s case, whenever a customer starts to resemble a competitor. Which makes this week’s public vote of confidence for a company now wholly owned by one of Anthropic’s actual rivals worth a second look.

The compute dependency

What makes SpaceX different from the previous Windsurf and xAI episodes is that Anthropic is also buying a huge amount of compute from it.

On May 6, Anthropic announced it had secured the entire output of SpaceX’s Colossus 1 data center near Memphis, Tennessee — more than 300 megawatts of compute and over 220,000 Nvidia GPUs. Anthropic had been hampered by limited compute availability, and the SpaceX deal, alongside other recent compute agreements, let it raise usage limits for Claude Pro and Max subscribers almost overnight.

Two weeks later, the financial terms came out. Per SpaceX’s IPO filing, Anthropic agreed to pay $1.25 billion a month for compute across Colossus and Colossus II — about 325,000 Nvidia GPUs combined — scheduled to run through May 2029, subject to termination rights.

SpaceX, for its part, said the arrangement would allow it to monetize some of its compute capacity while retaining enough to meet its own AI training and inference needs. As The New Stack reported in May, the deal also underscored just how central access to compute had become to competition between the leading AI labs. And it created an unusual commercial relationship: Anthropic was now buying a huge amount of compute from a company that also owned one of its direct AI rivals in xAI.

And that is what makes Anthropic’s response to the Cursor acquisition so notable. In response to Tom Brown’s post on X on Saturday, Replit founder and CEO Amjad Masad points to the contrast between Anthropic’s support for Cursor now and its treatment of Windsurf last year, suggesting the latter had been harsher than OpenAI’s decision to cut Cursor off.

“More likely answer is that you can’t do that here because you need the compute.”

“Maybe you changed your ways, but we all remember what you did to Windsurf, which was infinitely nastier,” Masad writes. “More likely answer is that you can’t do that here because you need the compute.”

Orosz essentially makes the same argument. If Anthropic was prepared to cut access when Windsurf merely looked likely to end up in OpenAI’s hands, why is it publicly promising MORE Claude capacity to Cursor after the company had actually been acquired by SpaceX?

“SpaceX basically in this enviable position where one of its biggest competitors depends on its compute infra!”

“Either SpaceX and Grok are not competitors to Anthropic (they are!); or, more likely, SpaceX leasing its Colossus 1 data center is more important to Anthropic than to stop offering Claude to SpaceX,” Orosz writes. “SpaceX basically in this enviable position where one of its biggest competitors depends on its compute infra!”

And so this effectively highlights how strong a position SpaceX finds itself in. It now owns xAI and Cursor, putting it in direct competition with Anthropic in foundation models through Grok and in AI coding tools through Cursor, while Anthropic is simultaneously paying it billions of dollars for compute capacity supporting Claude.

Whatever the stated rationale for treating Cursor as a “trusted partner,” that relationship leaves SpaceX with something neither Windsurf nor xAI had at the time Anthropic moved against them: a source of leverage over any decision on whether or not to cut access to Claude.

The post SpaceX is in an “enviable position”: why Anthropic is sticking with Cursor as OpenAI cuts access appeared first on The New Stack.