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.

Every infrastructure team makes decisions that are difficult to reverse. Most of the time, that works out. Sometimes it does not.

Vendor lock-in usually begins as a reasonable choice, made under time or budget pressure, that solves a real problem at the time. A managed service ships faster or a deployment model fits better in that moment, but eventually a difficult constraint appears. 

When business conditions inevitably change, those accumulated choices and their consequences will determine whether a team can pivot accordingly. Limits on flexibility rarely trace back to a single vendor; more often, they hinge on how reversible the team’s past decisions are.

What is vendor lock-in and how can it harm your business?

The risks of vendor lock-in are not really about relying on vendors, since every production system relies on vendors. The big issue is dependencies that become too expensive or impractical to unwind.

For a platform team, that dependency builds up across APIs, contracts, roadmaps, and data models. It extends further into managed services, identity patterns, observability pipelines, and operational tooling. Each piece likely represents a reasonable design choice, but together they can quietly limit your options and raise the cost of leaving. When switching a database or control plane means rewriting tons of integrations, retraining the whole staff, or migrating data under inconvenient timelines, you have lost the room to maneuver.

The big impacts of small, invisible and unexamined decisions

Not every dependency is automatically a problem; some are understood, contained, and worth the tradeoff. The real risk lives in the dependencies no one examined closely, which may stay invisible until they block the business from evolving. 

“The real risk lives in the dependencies no one examined closely, which may stay invisible until they block the business from evolving.”

Unfortunately, some teams are familiar with these invisible dependencies. A managed database might pick up proprietary extensions, which application code then starts to assume. A Kubernetes environment might bind to one cloud’s IAM, networking, storage, and load balancer model. Observability and logging pipelines might harden around a single provider’s formats. None of these choices is reckless on its own, but together they can create significant friction. 

Obstacles to change and their hidden costs

The extent of a dependency-based tradeoff can sometimes remain unknown until circumstances shift, such as a new compliance requirement or customers needing a new deployment model. The hidden costs of these moments often escalate in stages. It might start with a visible, unwelcome migration bill, but the expense can also show up as operational drag. Rushed migrations can lead to additional service disruptions later. A workload may be unable to move, limiting services to certain customers. When you are tied to a specific vendor’s release cadence, it can make it difficult or even impossible to adopt emerging technology. 

Concentration risk compounds the problem, because a single change from one provider that carries pricing, support quality, and roadmap can ripple across the estate. By the time a switch becomes necessary, the cost shows up as service disruption, complex data transfer, and retraining. Naming these costs early keeps them from arriving as surprises.

At some point, a dependency can accumulate enough of these costs to become more than an architectural detail. Once it affects budgets and timelines, leadership has to account for it—and the team has to be ready to explain it. Identifying these dependencies early gives everyone time to plan.

Open source offers a different path

One way to proactively address this pattern is to evaluate potential dependencies more deliberately. For example, before committing to a platform or service, try to determine its reversibility. In other words, establish how difficult it would be for the team to change its mind about the investment in the future.

“Open source offers no guarantee against lock-in, however, since a team can still build tight coupling on open foundations.”

Open source solutions tend to perform well against that test, because they are intentionally built to keep systems inspectable, portable, supportable, and replaceable. By design, open source makes it easier for you to preserve options over time. It offers no guarantee against lock-in, however, since a team can still build tight coupling on open foundations.

What is open source?

Open source describes software you can inspect, run, modify, extend, support, and replace with relative ease compared to proprietary alternatives. The software’s source is available, and the license grants you the right to use and change it. Notably, no-cost or freeware software is not necessarily open source, specifically if it does not provide this level of access and rights.

Several companies have open source principles at their core, and open source software can be extremely valuable in enterprise contexts. Transparent code is often easier to audit, and open standards can reduce friction when moving between tools.

Open source also changes who can move the goalposts

For developers, reversibility is not only about APIs and data formats. It is also about whether one company can change the terms underneath a foundational technology. The Linux kernel is a useful example. Linux kernel documentation notes that copyright assignments are not required, so merged code retains its original ownership and the kernel now has thousands of owners. That makes unilateral relicensing of the kernel effectively impractical.

Kubernetes has a different legal structure, but the practical protection is similar. The project is licensed under Apache 2.0 and governed by the Cloud Native Computing Foundation. The license grants users durable rights to the existing code, so no single vendor, including SUSE, can retroactively take those open-source rights away from the project as it already exists. That matters because a platform can remain available even if a particular vendor changes strategy.

The Terraform-to-OpenTofu fork shows why this is more than a theoretical distinction. In 2023, HashiCorp changed Terraform’s license from the Mozilla Public License 2.0 to the Business Source License 1.1. The community responded by forking the last open-source codebase into OpenTofu, now a Linux Foundation project that remains under the MPL 2.0. The lesson for developers is not that every open-source project is immune to licensing changes. It is that open licensing and neutral governance can preserve a viable exit path when a vendor changes direction.

Open source powered by enterprise discipline

Open source ultimately earns its place through engineering discipline. Source availability has benefits but does not resolve governance, patching, lifecycle management, documentation, security, or integration on its own. A community project can be powerful and nonetheless arrive without enterprise-grade operational guarantees.

Enterprise open source providers exist and can help with closing that gap. They embrace open foundations and add the support, security, maintenance, and lifecycle discipline that production environments require. Founded in 1992, SUSE was the first provider of an enterprise Linux distribution. Today, it focuses on helping organizations operationalize open source with enterprise-grade support.

These companies aim not to close off open source software but to make it dependable at scale. In other words, open source and operational rigor can coexist. And enterprises should expect both from any external provider.

Digital sovereignty: the x-factor that makes open source even more critical

Digital sovereignty describes how much control an organization has over its infrastructure, data, operations, and technology choices. Sovereignty is a spectrum, and architecture decisions can move an organization a step in either direction.

Recent research by SUSE suggests that almost all enterprises are prioritizing digital sovereignty, but only 52% are actively taking steps toward it. That gap is largely an execution problem, and much of it surfaces in everyday platform decisions. 

If your team supports regulated industries or deploys in on-premises or air-gapped environments, you may be especially familiar with growing pressures around sovereignty.

Sovereignty puts a deadline on work that was already worth doing

Developers can hear “digital sovereignty” and assume it means a separate compliance workstream with a separate engineering bill. In practice, much of the work is the same discipline platform teams already invest in: portable workloads, clean interfaces, automated verification, reproducible deployment, auditable behavior, and the ability to replace a dependency without rewriting the system around it.

“Sovereignty does not suddenly make that engineering work valuable. It puts a deadline on work that was already worth doing.”

Those practices already have an economic case. They reduce migration costs, lower operational risk, make platform changes less disruptive, and preserve options when pricing, regulations, or business requirements shift. Sovereignty does not suddenly make that engineering work valuable. It puts a deadline on work that was already worth doing.

That reframe matters because it turns sovereignty from a policy overlay into an architecture property. The useful question is not simply, “How much extra work will sovereignty cost?” It is, “Which parts of our stack already fail the portability, interface, and verification tests we would want anyway?”

How to strengthen sovereignty with open source

Sovereignty depends on how a team designs, deploys, and operates its systems. Open source does not make an organization sovereign by default, but it can improve the conditions for sovereignty. 

In fact, many of the same questions that expose lock-in also matter for digital sovereignty. Each of the following questions about reversibility connects to open source and sovereignty alike:

Reversibility question	Why open source can help	How sovereignty strengthens
Can we run this workload elsewhere?	Open source typically runs across on-premises, cloud, hybrid, and edge environments, not just one vendor’s platform.	More control over where workloads run, including specific regions and regulated contexts.
Can we understand and audit how it works?	Source availability and community scrutiny improve inspectability over closed alternatives.	Teams can verify behavior, assess risk, and meet assurance requirements.
Can we migrate or reuse our data?	Open ecosystems favor open formats and interoperable tooling.	Data stays more portable, improving control over storage and movement.
Can another team or partner support it?	Multiple support paths exist, from internal teams to integrators and enterprise vendors.	Less dependence on one vendor’s pricing, availability, or roadmap.
Can we replace one component without rewriting everything?	Open interfaces and modular design make components easier to swap.	More control over architecture as requirements change.
Can we keep operating if a vendor changes direction?	Open source projects can outlast one vendor’s strategy or license.	Less exposure to decisions the team cannot control.
Can we deploy closer to the data?	Open source can run in private data centers, sovereign clouds, edge sites and hybrid models.	Sensitive workloads, including AI, can be governed nearer the data.

The ongoing work of digital sovereignty

Sovereignty is more of a practice rather than a specific destination. For many teams, the work begins with identifying existing dependencies that are especially hard to reverse. Similarly, you’ll need to separate the tradeoffs worth accepting from the ones that remove a significant number of options. 

Moving forward, it can be helpful to prioritize open interfaces and portable foundations when possible. When evaluating new services or solutions, treat lifecycles, support, and governance as first-order concerns.

In some cases, sovereignty work can be too heavy for an in-house team to carry alone. Providers such as SUSE can help strengthen your operational layer, including security and observability, and especially in growing or hybrid contexts.

Automated checks can make those principles concrete by continuously testing whether workloads can be rebuilt, moved, audited, and recovered instead of waiting for a migration or compliance event to expose the gaps.

Open source lets you take control of your software ecosystem

No enterprise team avoids every dependency, and candidly none should try. Some coupling is reasonable, contained, and worth it. A vendor-free system is not a realistic goal for a major enterprise. A realistic goal is the judgment to separate acceptable dependencies from dangerous ones.

“The true cost of any platform includes the cost of leaving it, and teams should understand that cost before they commit.”

Reversibility gives that judgment something concrete to work with, because it can be broken down into capabilities a team can name, evaluate, and test:

• Ownership. Ownership does not mean building everything yourself. It means holding the realistic ability to run, move, or hand over each layer of your stack. The test is simple: if a vendor disappeared tomorrow, or was ordered to stop serving you, what still runs next month?
• Auditability. You should be able to verify what your software does, yourself or through an auditor you appoint, rather than accepting a vendor’s report as the final word. With open source, inspection is a property you hold. With closed software, it is a permission you are granted, and permissions can be withdrawn.
• Exit velocity. An exit plan without speed is just a document. Exit velocity measures how fast a workload can move from one platform to another, and it only means something when you test it on a schedule, as earlier generations tested disaster recovery.
• Pivot ability. These capabilities matter when conditions change: a new compliance requirement, a customer that needs a different deployment model, or a vendor that changes direction. Teams that can reroute workloads respond on their own timeline. Teams that cannot must renegotiate from a position of weakness.

Vendor lock-in becomes a manageable risk when you can confidently flag which decisions are hard to undo, weigh the tradeoffs honestly, and protect the team’s pathways to change. Open source strengthens every one of these capabilities because it keeps larger portions of your system inspectable, portable, and replaceable.

The true cost of any platform includes the cost of leaving it, and teams should understand that cost before they commit.

The post Avoiding vendor lock-in through an open-source approach: a developer’s perspective 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.

AI coding tools have seriously accelerated developer speed, but AI has also done the same for attackers — and the software supply chain is increasingly where the two are colliding.

The numbers give some idea of how quickly software development is changing. GitHub processed around one billion commits in 2025. By April 2026, the platform was handling roughly 275 million commits a week, according to GitHub COO Kyle Daigle. GitHub Actions usage has climbed, too, from 500 million compute minutes per week in 2023 to 2.1 billion in just part of a single week this year.

Quincy Castro, CISO at Chainguard, says the shift in how software gets written is already stark.

“I look around Chainguard, and I don’t think any of our engineers have actually written a line of code by themselves in the past year,” Castro tells The New Stack. Writing code manually now “sort of feels quaint, like you’re illuminating manuscripts,” he says, while “the printing press is out there just going to town.”

But this isn’t only about professional developers producing more code. AI has also widened the pool of people who can create software. Teams in HR, finance, and business intelligence that once had to wait for engineering resources can increasingly build what they need themselves.

That means more software being created by people outside traditional engineering teams, often with AI making decisions about what goes into it. The person prompting the agent may never see which libraries or packages it has chosen.

When the agent chooses the dependencies

Software security was already built around the fact that humans couldn’t inspect everything. But developers were still making important decisions, including which libraries and packages went into an application.

That changes when an AI agent is doing much of the coding.

“Humans are directing what they want to be done, but they’re somewhat abstracted from the actual doing of the work,” Castro says. “You have AI instead now making the choices of what dependencies am I going to pull into this application? How am I going to go accomplish this task?”

“Humans are directing what they want to be done, but they’re somewhat abstracted from the actual doing of the work.”

Attackers, meanwhile, are finding plenty of uses for the same technology. Castro sees three problems arriving at once: frontier models finding previously unknown vulnerabilities, attackers using agents to exploit better vulnerabilities organizations haven’t fixed, and sustained attacks against the open-source ecosystem.

A collection of medium- and low-severity findings might once have sat well below the top of a remediation queue. Frontier models with advanced cyber capabilities, including Anthropic’s Claude Mythos Preview and OpenAI’s GPT-5.6-Cyber, can now work across those findings and chain seemingly minor weaknesses into a viable attack path.

“Here’s a whole ton of mediums and lows. Now give me the attack path that gets me domain admin,” Castro says, describing the approach. “Chain these together to go get me root on the system. And AI is really, really good at being able to do that.”

That poses an awkward problem for vulnerability management — and the models keep getting stronger, with OpenAI releasing GPT-5.6-Cyber in August. Mean time-to-exploit has already fallen from 63 days in 2018–19 to an estimated minus seven days in 2025, according to Mandiant, meaning exploitation can begin before defenders have a patch to apply. 

At the same time, AI’s ability to combine apparently less-serious weaknesses makes a neat CVSS-based queue a less useful representation of what an attacker can actually do.

The third problem is the software supply chain itself.

Open source becomes the attack path

Modern applications depend heavily on open source software, and attackers have increasingly targeted the infrastructure used to build and distribute it.

Castro pointed to the TeamPCP campaign, which compromised widely used projects including Aqua Security’s Trivy. In that attack, malicious code was pushed into trusted components and subsequently picked up downstream.

Supply chain attacks were once associated primarily with sophisticated state-backed groups willing to spend significant time getting into the right place. That barrier is falling.

“If you don’t mind making some noise, this is a way easier attack vector than I think a lot of people thought it was,” Castro says. More importantly, “a single attack that’s successful can lead to a cascading set of other compromises and other access that gets you into other places.”

The development pipeline itself can make matters worse. Castro says many organizations still have relatively few controls around CI/CD, while developers routinely pull components from external sources to get their work done. Adding autonomous coding tools to that behavior compounds the risk.

“You wouldn’t pick up a random thumb drive and stick it into a production system, right? But that is effectively what folks are doing when they’re consuming open-source software that way.”

He compared the way organizations consume open source software to plugging an unknown USB drive into a production system. “You wouldn’t pick up a random thumb drive and stick it into a production system, right?” he said. “But that is effectively what folks are doing when they’re consuming open source software that way.”

Open source isn’t the problem. Trusting its distribution path without sufficiently verifying what you’re consuming is.

Prevention has to come before detection

This is where the old security model starts to creak.

For years, much of vulnerability management has followed a familiar loop: scan something, generate an alert, decide how serious it is, and get somebody to fix it. That becomes harder to sustain when development output multiplies, AI agents make more of the underlying decisions, and attackers can exploit weaknesses before fixes are available.

Castro wants companies to put more effort into what enters the development environment in the first place, rather than discovering problems once the software is already there.

“How do we just make things work from the beginning, with no alerts and no responding to stuff and no people chasing things and no people trying to prove a negative?” he says. “From end to end, from the creation of code to its deployment, how do we make sure that we can give folks the most trustworthy version of that thing?”

Rather than taking packages from public ecosystems at face value and scanning them after the fact, Chainguard builds artifacts from verified, buildable source.

That’s the thinking behind Chainguard’s approach to containers, libraries, and other open source artifacts. Rather than taking packages from public ecosystems at face value and scanning them after the fact, the company builds artifacts from verified, buildable source. It provides provenance about how they were created.

But trustworthy components are only one layer.

“There’s no point in bringing inherently secure software components into the environment if you don’t actually have a technical control that says this is the only way people developing code can consume these things,” Castro says. That means engineering, security, and SRE teams also need controls over where software — whether selected by a human or an AI agent — can come from.

That requires several layers of protection. Organizations need to know where their software came from and how it was built, control what can enter their environments, and make sure those rules apply when an AI agent chooses components as well as when a developer does.

Defending open source at AI speed

There is another problem, however. Frontier models such as Claude Mythos Preview and GPT-5.5-Cyber aren’t just finding vulnerabilities that previously went undetected; they can also combine lower-severity flaws into working attack paths. Individual companies can harden their own pipelines, but the software they depend on comes from an open-source ecosystem facing vulnerability discovery at a speed and scale it wasn’t built for.

That’s part of the reasoning behind Athena, the industry coalition Chainguard launched to turn vulnerability findings from frontier AI programs into fixes. As of July, the coalition had processed more than 40,000 vulnerabilities, with 42% rated critical or high severity and 86% marked as network reachable, meaning attackers can access and trigger them at the network level.

For Castro, the important part isn’t simply finding more bugs. AI is already getting very good at that. Someone still has to fix them.

“Through Athena, what we attempt to do is to give people that engineering fix,” he says. “What if we create a coalition where folks just send us the issues that they’re finding? We automatically generate fixes for those, and we push those back to everybody.”

“Through Athena, what we attempt to do is to give people that engineering fix.”

Those fixes can also be pushed upstream to open source maintainers, who face the prospect of being buried beneath an expanding pile of AI-generated vulnerability reports.

That may ultimately be the bigger shift AI forces on software security. Developers aren’t going to stop using coding agents because they create new risks, any more than companies are going to stop using open source because attackers target it.

Bolting enough scanning onto an exponentially faster development process isn’t much of an answer either.

The opportunity is to remove more of the risk before the software ever reaches a developer or an agent: Start with components you can trust, tightly control how they enter the environment, and fix weaknesses as close to their source as possible.

AI has made it dramatically cheaper to create software. It’s doing the same thing for attacks. Security now has to keep up without putting the printing press back in the box.

Visit Chainguard to learn more.

The post The software supply chain is the new battlefield. AI just changed the rules. 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.

There were unusual goings-on this month at Automattic, a company known for its free and open-source app for building WordPress sites. 

The company issued a notice last Thursday confirming that CEO Matt Mullenweg was on leave.

Mullenweg, who also co-founded WordPress in 2003 before establishing Automattic in 2005, was temporarily replaced by company CFO Mark Davies before being reinstated less than a day and a half later.

By last Saturday, a new alert emerged stating that Mullenweg was back in his position and that “Matt was away for only 33 hours and 20 minutes.”

Automattic has not publicly explained what changed between the initial decision and Mullenweg’s return — and it has also declined to explain the circumstances behind the leave and return. 

By way of context, WordPress sits under the Automattic brand alongside the company’s other products, including the microblogging site Tumblr, the e-commerce WordPress plug-in service WooCommerce, and the instant messaging client Beeper. 

A 33-hour vanishing act, but Automatticians are supporting him 

Automattic director of communications Megan Fox is on the record saying, “Matt Mullenweg is the chairman and CEO of Automattic, with full support of the board. “And if you search online, you can see many top executives and Automatticians supporting him as well.”

A further report reproduced Slack messages written by Mullenweg where he said, “Happy to announce the board is back in agreement, and I’m in control of Automattic. A lot happened in the past 48 hours that we need to sort out, and I hope much of it was a misunderstanding, because I have huge respect and regard for those involved.”

Was this a failed boardroom coup?

Industry watchers may naturally suspect the knives were out and that this was a failed boardroom coup. 

CEO & CTO at HasData, Roman Milyushkevich, tells The New Stack that a company can survive a CEO departure, but it struggles when employees cannot tell which governance process is real.

“But, in terms of whether the real guns were out at Automattic, it certainly looks like a failed attempt to change control, but I would not call it a coup as an established fact,” Milyushkevich says. 

“The possibilities playing out here are all very different,” Milyushkevich adds. “There could have been a second board agreement brought into place inside that 33 hours; there could have been internal (or possibly even external) negotiations; directors could have reconsidered the practical consequences of removing the founder; or there could have been an internal resolution that has not been disclosed.”

He advises that the “most important thing Automattic can establish now” is not who won the dispute, but whether the board and CEO have a clearly understood process for handling the next serious disagreement.

“The most important thing Automattic can establish now is not who won the dispute, but whether the board and CEO have a clearly understood process for handling the next serious disagreement.”

Behavioral scientist and visiting professor at São Paulo’s FIA Business School, Ricardo D’Olivar, tells The New Stack that what matters here is whether stakeholders have “enough information to distinguish a considered correction from an unresolved struggle” over authority. 

“A reversal of this kind can reflect responsible reconsideration,” D’Olivar says. “Reinstatement answers who is in charge today. It does not, by itself, explain how a future disagreement would be resolved. This is where the potential consequences for employees, executive recruitment and investors arise. If uncertainty persists, employees may become more cautious about committing to decisions whose backing appears unstable.”

Suggesting that, responsible corporate mechanics or not, this kind of development undoubtedly throws the cat among the pigeons, D’Olivar says that developers or executives considering a career at Automattic may now question whether they would be held responsible for decisions they were authorized to make, but could no longer count on the organization to support when challenged. 

“Investors may seek clearer evidence that oversight and succession arrangements can operate under pressure. These are possible responses, not verified effects at Automattic. The information shared internally may also be more complete than the public account,” adds D’Olivar.

This is not the first boomerang CEO bounce

Mullenweg might be the fastest CEO yo-yo switcharound in history, but he’s certainly not the first. OpenAI CEO Sam Altman famously left the company’s board after a communication dispute. An employee uprising (nearly all the company’s 700+ staff threatened to resign) and added pressure from Microsoft led to Altman returning to his position five days later.

Perhaps even more famously, Steve Jobs was ousted in 1985, only to return 12 years later to realign a then-struggling Apple and take it into its golden years. Twitter (now X) founder Jack Dorsey was moved out in 2008 before a boomerang return in 2015. Michael Dell stepped down as CEO to become chairman of the board in 2004, but by the start of 2007 he was back.

At their origins, the shenanigans at Automattic may be redolent of the technology industry’s other boomerang CEO realignments, or this may be a boardroom tussle that we’ll never know the full reason for until Mullenweg writes his memoirs. Either way, the WordPress industry just got its first movie-script idea.

The post Automattic says CEO Mullenweg was gone and back inside 33 hours. What happened between? 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.

Based in the Emirati capital, Abu Dhabi, the Institute of Foundation Models (IFM) introduced K2 Horizon last week. This group of six AI foundation models, ranging from 0.9 billion to 375 billion parameters, is claimed to be the “largest fully open-source fleet of AI models” yet made available.

IFM uses “fully open” to mean more than mere downloadable model weights. Across K2 Horizon, it has committed to publishing training and evaluation code, training data where redistribution is possible or detailed construction recipes where it is not, plus configurations, logs and intermediate checkpoints spanning pretraining through agentic post-training.

The aim is to let developers inspect how the models were built, reproduce their development and adapt them for their own work. But that commitment should not be confused with complete availability at launch: All six models had downloadable weights, while the model cards for the 0.9B, 32B and flagship 375B said some training data, code or checkpoints would arrive later. The 32B release was also only a Stage 1 checkpoint, with the final model still to come.

“Open source is much more than open weights. Science works when others can see the data, follow the method, reproduce the result, and improve on it,” said Eric Xing, IFM founder and university professor at the Mohamed bin Zayed University of Artificial Intelligence. “K2 Horizon delivers on that need. Every model in the fleet ships with its training data, recipe, and evaluations. This is open science, and we believe it’s the best path forward for AI.”

“Open source is much more than open weights. Science works when others can see the data, follow the method, reproduce the result, and improve on it.”

All the open model components you can think of

IFM says it is opening the full training lifecycle for every K2 Horizon model, from pretraining through reasoning and agentic post-training. For each model, it is releasing — or has committed to release — intermediate checkpoints, training data, or detailed data-construction recipes. The checkpoints are snapshots saved throughout training, allowing researchers to examine how a model develops and reproduce or resume particular stages. The broader artifact set includes architecture details, mixture compositions, training code, configurations, fine-grained logs, evaluation results, and final weights.

Across reasoning, mathematics, coding, and agentic tasks, the K2 Horizon team says every model size performs well. The 0.9B model is designed for highly constrained environments such as smartwatches and smartglasses, while the 3.7B and 7B models bring advanced capabilities to phones and other on-device applications.

The dense 32B model and sparse 36B-A4B model deliver stronger performance for local hosting and on-premises servers. The 375B-A23B model brings the fleet’s strongest capabilities to demanding enterprise deployments.

The six models share a core architecture, vocabulary, training methodology, interfaces, and deployment tooling, with the 0.9B model having a smaller vocabulary. IFM’s dynamic model routing technique directs tasks to the most cost-effective model and provides developers with a path from prototype to production. The organization insists that the fully open code, training data, and recipes are “a significant step forward in transparency” that go “well beyond” the open-weights dialogue that has dominated AI industry headlines this year.

Could this openness have been more… open?

The IFM team is clearly aiming for differentiation through all-encompassing openness, but could it have been more open… and will it need to be even more open in the future? 

To answer that question, the level of openness varied by model at launch. The 3.7B and 7B models shipped with the full artifact set — including weights, recipes, training code and data — while the 0.9B model card, the documentation describing its capabilities and limitations, said its data and code were still forthcoming. The flagship 375B-A23B and sparse 36B-A4B initially arrived with final weights, with full training code, raw datasets, and intermediate checkpoints promised in later updates. The 32B model shipped as an incomplete Stage 1 checkpoint, with the final model and remaining artifacts to follow.

But really, the real question of open purity comes down to the more granular aspects of model training, and this is the stuff that will either delight or infuriate developers. If published data for each model size and synthetic generation pipelines aren’t fully reproducible, AI engineers likely won’t be impressed.

According to Nitish Garg, founder & CEO of AI super-app company CellCog, in his analysis of K2 Horizon and its model training processes, “Reasoning traces for math were rewritten into dialogues and study guides and mixed into pretraining rather than saved for post-training. Compute is not disclosed anywhere: no accelerator count, no hours, no cost. For a release whose thesis is inspectability, that is the one obvious hole, and the fine-grained training logs, when they arrive, may fill it.”

“Compute is not disclosed anywhere: no accelerator count, no hours, no cost. For a release whose thesis is inspectability, that is the one obvious hole, and the fine-grained training logs, when they arrive, may fill it.”

Reproducibility mission impossible: what open models need to share

The narrative here suggests that releasing synthetic datasets is good. Still, if open frontier model companies do this without also providing the full generator prompts (text inputs that direct AI models to create synthetic training data), seed code (as it sounds, core code that controls and initiates the dataset generation process), or exact filtering heuristics (where low-quality synthetic data needs to be cleaned or removed), then developers will find that true end-to-end reproducibility is hard, problematic, and in some cases impossible.  

Going further, IFM said it has shared methodologies, but developers will also demand execution specifics, including precise details of the hardware topology used to run complex models. Engineers might also like to see distributed communication configurations to examine how parallel processors exchange data during training. We could also point to the need for optimizer state records, the parameters that track ongoing model optimization progression for each training iteration.

Developers openly discussing this topic have not held back. However, the conversation has quickly veered from K2 Horizon to Chinese labs becoming prominent suppliers of open-weight models — though their training data and full training stacks generally remain closed.

Reacting to one user who claimed that “Chinese models these days don’t even release pre-trained weights anymore” and that all developers get now is the finished post-trained product, user culi retorted, “No? That’s absolutely not true. Qwen, GLM, Kimi, DeepSeek, etc all consistently release both the post-trained “Instruct/Chat” versions and the underlying ‘base’ (pre-trained) weights.”

Joining in the fray, Hacker News user thepasch thinks that there is true open-weight openness, but that it has limits. “Inference code, yes, but the specifics of their training process (as well as the training of the vast majority of all other open-weight models) are still a complete black box, and I can’t think of any Chinese model that made its training corpus public.”

We’re the 360-degree open source of open source

Speaking in a recent video interview (6:51), Hector Liu, director of IFM’s Silicon Valley lab, said, “In AI, recently,  people have some confusion about the [term] open source. People sometimes open-weight their final model, but they don’t let you know how things are trained, how production is done… so at IFM we are the pioneer of 360 [degree] open source or fully open source.”

Separately, he said developers can prototype on the smallest model, scale to the flagship, and verify every claim IFM makes along the way. Statements that not everybody really understands the difference between different open approaches to technology should not come as news to anyone. Still, the imbalance in perception here is clearly on show.

The weights are available on Hugging Face, with launch-day support for vLLM and SGLang. The K2 Horizon API is available through IFM’s inference partners, including Compass, Cerebras, and Nebius. K2 Horizon models and code are released under the Apache 2.0 license.

The post K2 Horizon just shipped as six new fully open models — developers aren’t fully convinced 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.

Nvidia’s bet on open models and local AI has been taking shape for a while now. Its acquisition of Hugging Face will only accelerate that, but on the product level, too, the company is making some headway in getting more potential users to run AI models on their machines.

On Thursday, Nvidia launched the Nvidia Personal AI Router (PAIR), an open-source software router for your home network that lets you use idle Macs and PCs in your house to run small models on demand and speed up agentic workflows with the help of subagents.

PAIR is very much meant to speed up agents like NemoClaw, OpenClaw or Hermes by allowing them to use more subagents in parallel. The idea is for a lead agent to split up tasks across subagents, whose model requests can then run on these idle machines.

Nvidia calls it a “virtual inference router” and is very clear that this is not a new inference engine. Instead, it uses the Ollama or LM Studio installs already running on a given machine and lets them run the models. Once installed on every machine, PAIR can then discover the different systems on your local network (using mDNS) and check if they are able to run a request.

The caveat here is that this does not split up a single inference request across different machines. Nvidia stresses that this doesn’t merge GPUs or pool VRAM into a single accelerator and can’t split a single inference request across machines.

“Agents can send a request through the familiar local interface it expects,” Nvidia explains. “PAIR receives the request through its proxy, identifies its engine and model requirements, and selects one eligible node. That node executes the request from start to finish and sends the response back through PAIR. The agent continues to see one connection while PAIR handles placement behind it.”

PAIR supports Windows, macOS, and Linux machines with compatible GPUs. In practical terms, that’s Nvidia GeForce RTX 20 series GPUs and newer (which Nvidia says is the baseline), a Mac with M4 silicon or newer, or an Nvidia DGX Spark (and then, once they are available later this year, RTX Spark PCs and laptops).

It’s nice to see Nvidia supporting Macs here, which have obviously become quite popular for running local models and agents like OpenClaw, even though they don’t use Nvidia GPUs.

Each system can host different models, but PAIR will only route a request to a machine with the required engine enabled and the exact requested model available. Installing the same model on several machines gives the router more options for distributing concurrent requests.

PAIR keeps an eye on which computers are available and once a user gets back to work (or gaming) on a given machine and reclaims the GPU, the local inference engine is stopped.

In Nvidia’s example, using PAIR with two PCs running high-end RTX 5090 GPUs with 32 GB of RAM (and a $5,000 price tag right now, despite their initial $2,000 MSRP) and the Qwen3.6 35B A3B model sped up work with five subagents by about 1.6x.

Few people have a bunch of RTX 5090 cards at home (and maybe a few DGX Spark desktops, too), so it remains to be seen what this will look like in a scenario with maybe a Mac Studio, a few Mac minis and maybe a gaming PC, but even that should speed up a local agent workflow as well.

Availability

Nvidia PAIR is now available as a beta. To get started, you just need to install it on every machine you want to be part of the network, have it discover and pair those systems, and make sure you have Ollama or LM Studio installed on them (and the models downloaded).

PAIR can also help with setup by installing Ollama or LM Studio and initiating model downloads on paired machines.

The post Nvidia PAIR lets you put your idle Macs and PCs to work for AI agents appeared first on The New Stack.

You could have a mechanical duck waddling through your home before Christmas. 

Hugging Face‘s Pollen Robotics on Thursday opened pre-orders for the Microduck, a $399 (introductory) bipedal duck-adjacent robot that can walk, waddle, and use roller-skates(!), with a beak to pick up objects. And when it falls, it can get back up, too.

The company expects to make the first deliveries of the Microduck before Christmas. It’s available in North America and Europe.

Microduck is the follow-up to Reachy Mini, the desktop robot Hugging Face and Pollen launched last year, which was stationary and focused on interacting with humans. Pollen also still sells Reachy 2, a far larger and pricier humanoid aimed at research labs. Microduck, the team writes in its announcement, is meant to focus on action.

“How do you teach a robot to move? How do you train a behavior in simulation, transfer it to real hardware, see what went wrong, and try again? What changes when the robot can leave the desk, carry something, fall over, and recover? It is an ideal platform for developers who want to train physical behaviors, experiment with reinforcement learning, and test how AI moves from simulation into the real world,” the team writes.

Not just a toy

And indeed, Microduck is not just a 25cm-tall toy. It’s an open-source platform with an SDK, virtual training environment, and reinforcement learning scripts to help developers train the robot to perform new tasks. The code is Apache 2.0, though the hardware design files are licensed non-commercially, so nobody is building and selling a clone.

There’s also a full simulator for those of us who just want to play with a duck robot, but if you do buy one, you’ll also get a game controller to control the robot on the fly, too.

But if you want to go deep, you can use the physics simulator to teach the robot new movements. On the project’s GitHub page, the team notes how to train the duck’s walking policy across 4,096 virtual ducks in parallel, for example, which results in a usable gait in one to two hours. The repo registers 13 task families in all, including a forward roll and six built around a set of passive wheels that go under the feet.

To train the robot, you’ll need an Nvidia GPU, or you can train it on Hugging Face’s own infrastructure. That’s not incidental. The simulator the ducks run in is MuJoCo Warp, built on Nvidia’s Warp framework, and mjlab, the training framework underneath, reimplements the API of Nvidia’s own Isaac Lab.

Out of the box, the robot comes with seven trained moves, including walking, sitting and standing, kicking, grabbing objects with its beak, roller skating, and getting back up off the ground.

Inside the hardware

As for the hardware, the robot will weigh in at about 800 grams and will be powered by a Rockchip RK3566 with AI accelerator. That’s basically a quad-core Arm Cortex-A55 with a Mali GPU. But now that Nvidia is reportedly in talks to acquire Hugging Face, in a deal first reported by The Information, I would expect a future version to use a slightly more powerful Nvidia-made chip.

It features 1GB of on-board memory and 32 GB of storage.

What’s more important, though, is its set of sensors. There’s a single front camera, a small LiDAR sensor with an 8×8 time-of-flight matrix, and 2 inertial measurement units. The camera and LiDAR let it see and place objects around it, while the IMUs keep track of its orientation and balance.

The team is still working out what the final camera resolution and LiDAR range will be.

Pollen Robotics will sell a few accessories as well, including, for example, a Charger Pack for $39 with two batteries and a charger, and a Dev Pack for $119 with three spare motors, five motor cables, two batteries, a dual charger, ten NFC tags, Hugging Face credit, screws, and a screwdriver.

The robot also comes with microphones and a speaker. One interesting note here: when you first turn the robot on, it generates its own signature sound that is different from any other Microduck. The robot doesn’t speak, though, as the team notes, the Microduck “communicates through weird little sounds, closer to a creature than an assistant.”

Everything is better with more ducks

The team says having several of them together is what really makes the robots come alive. “Races, football, or simply robots reacting to one another immediately make the experience feel more alive. For developers, it also creates a practical way to explore multi-robot behaviors without a room full of expensive hardware,” they write.

At the end of the day, this is also just a fun project, and in this depressing world, we all deserve some ducking fun every now and then.

The post This duck will teach you reinforcement learning — and pick up your socks appeared first on The New Stack.

Nvidia has reportedly agreed to buy Hugging Face for $12.9 billion, putting one of the biggest names in AI hardware in charge of a platform developers rely on to find and run open models.

The Information first reported the deal Wednesday, citing a person familiar with the agreement. Nvidia and Hugging Face had not publicly confirmed it as of publication.

Hugging Face doesn’t push developers toward one chipmaker, which is what makes the acquisition interesting. Its Optimum libraries work with Nvidia’s TensorRT-LLM and also support hardware from AMD, Intel, and AWS. Projects such as Optimum AMD and Optimum Intel let developers run Transformers and Diffusers models on non-Nvidia hardware.

The company also plays a role in what happens after a developer chooses a model, including how easily they can get it running on the hardware they want to use. The problem for Nvidia might be this: It is buying a platform whose value depends on openness and hardware neutrality, but if the purchase means Nvidia hardware is favored, that value might diminish.

The company also plays a role in what happens after a developer chooses a model, including how easily they can get it running on the hardware they want to use.

Hugging Face already sits between the model and the chip

Hugging Face has expanded well beyond file hosting. With Inference Endpoints, developers can deploy a model from the Hub while Hugging Face handles the underlying infrastructure.

Those hosted deployments can run on AWS, Microsoft Azure or Google Cloud, but most of the GPU options Hugging Face lists are Nvidia chips, including the T4, L4 and A100. That gives developers a wider choice of hardware through Hugging Face’s open-source libraries than through its hosted services.

If the deal goes through, Nvidia would own both sides of that experience.

Deployment defaults favor Nvidia

NIM (Nvidia Inference Microservices) already works with models hosted on Hugging Face. Developers can point NIM to an hf:// repository path and pull the model directly from the Hub.

Owning Hugging Face would give Nvidia more room to bring NIM and CUDA-optimized containers directly into the deployment experience. Nvidia hasn’t announced plans to make NIM the default, and support for AMD and Intel could remain exactly where it is.

Owning Hugging Face would give Nvidia more room to bring NIM and CUDA-optimized containers directly into the deployment experience.

The bigger question is what happens over time. Nvidia could provide earlier support for new models on its own hardware or make deployment easier. At the same time, AMD, Intel, and AWS may have to reconsider how much engineering work they want to contribute to integrations maintained within a competitor-owned platform. Some of that work could eventually move elsewhere.

For developers, the difference may come down to which path requires less work. A competing chip doesn’t have to disappear from Hugging Face to become less appealing if an Nvidia model deployment takes fewer steps. We’ve seen a similar fight over the layers between AI models and the developers using them, with Cloudflare building more of that infrastructure itself.

Open models counter custom chips

That tension also helps explain why Hugging Face could be worth considerably more to Nvidia than its revenue alone would suggest.

Nvidia has been expanding its own Nemotron family of open models while investing heavily across the AI ecosystem. At the same time, some of its biggest customers are working to reduce their dependence on Nvidia hardware.

Google has its TPUs, AWS has Trainium, and Microsoft has Maia. OpenAI and Anthropic are also developing their own AI server chips. The push extends beyond the hyperscalers. Earlier this month, five European companies committed to purchasing AI compute built around non-Nvidia hardware that hasn’t been manufactured yet — a sign that the appetite for alternative accelerators is strong enough to attract forward contracts.

OpenAI this week published results from its new Jalapeño accelerator, which showed 1.5 to 1.9 times more work per watt while cutting end-to-end latency by up to 3.6 times on large open-weight models — although the chip has not yet been deployed at anything approaching Nvidia’s scale. A strong open-model ecosystem gives Nvidia a counterweight to that trend.

Open models are often expected to run in very different environments, and Hugging Face helps developers make that possible. A model found on the Hub might end up running on Nvidia hardware, an AMD GPU, or a cloud accelerator.

That flexibility is part of what Nvidia would be buying. Pushing Hugging Face too heavily toward its own hardware could make the platform less useful to developers who rely on it to work across different systems.

Interest in those models is also growing. Models from companies including DeepSeek, Moonshot AI and Z.ai have narrowed the gap with proprietary systems. At the same time, Hugging Face CEO Clément Delangue told The Information in June that the company had doubled its number of paying subscribers during the first six months of 2026. Delangue later said the company was “close to profitability.”

The Information puts Hugging Face’s annualized revenue at about $150 million. Against a $12.9 billion price tag, that’s a multiple of roughly 86.

So Nvidia would be paying for much more than Hugging Face’s current business. It would be buying a place developers already turn to when they want to work with open models, including models that don’t have to run on Nvidia hardware.

It would be buying a place developers already turn to when they want to work with open models, including models that don’t have to run on Nvidia hardware.

Community resists easy forking

Buying Hugging Face wouldn’t give Nvidia control over everything developers find there. Libraries such as transformers and diffusers are open source, and models on the Hub remain subject to their own licenses. Openly licensed models can still be hosted elsewhere, while the underlying libraries can be forked.

Much harder to recreate is the community Hugging Face has built around them. Developers already know where to look for models and have built workflows around the Hub and its integrations.

The post Nvidia’s $12.9B Hugging Face deal has an open-source problem appeared first on The New Stack.

When Elon Musk’s X sent cease-and-desist letters demanding that Nitter — an open-source alternative front end for the social media platform — permanently shut down its instances and remove the project’s source code repository, it went after the code itself.

While Nitter.net was the project’s main public instance, other developers can run their own versions because the code is open source. So taking Nitter.net offline doesn’t really eliminate Nitter, because its code can be forked and used to run independent instances, including services such as XCancel. X’s demand for the repository goes further.

Open source meets platform control

Open source gives developers control over Nitter’s code, but not the platform it relies on. X still controls access to its service, and its latest move shows how that control can extend beyond just changing an API.

Open source gives developers control over Nitter’s code, but not the platform it relies on.

Nitter used to let people read public X posts without an account, but that stopped working in 2024 after X shut off the guest access the project relied on, taking Nitter.net offline. Nitter later found a way back by using real X accounts to access posts, according to the project’s GitHub repository.

That got Nitter back online, but it also meant relying on X accounts to keep it running. X controlled those accounts and could change the rules around them at any time. That doesn’t necessarily put someone who simply downloads or forks Nitter’s code in the same position, since doing so alone doesn’t mean they’ve agreed to X’s terms.

X’s cease-and-desist claims

Those changes are now at the center of X’s legal case. According to the cease-and-desist letter — first reported on by TechCrunch — X says Nitter violated its rules by scraping data and accessing accounts and session tokens, and accuses the project of “unlawful use and circumvention” of its API.

X’s lawyers also cited the Lanham Act and Section 33.02 of the Texas Penal Code, which deals with accessing computer systems without the owner’s “effective consent.” But breaking a platform’s rules doesn’t mean the law was broken, too.

Breaking a platform’s rules doesn’t mean the law was broken, too.

GitHub’s code removal standard

Under Section 1201 of the Digital Millennium Copyright Act, software can be targeted if it’s used to bypass technology that protects access to copyrighted material, even when the software doesn’t contain that material itself.

A claim that software bypasses a technical restriction isn’t enough on its own to get a repository removed from GitHub. For a Section 1201 complaint, the company must identify the copyrighted material being protected and explain how the code circumvents the technology controlling access to it, according to GitHub’s guidelines for submitting circumvention claims.

X reportedly says Nitter got around its API restrictions to access accounts and session tokens. The question is whether those restrictions were protecting copyrighted material in the way Section 1201 requires.

The YouTube-dl precedent

A similar issue arose in 2020, when GitHub removed the open-source YouTube-dl project following a Section 1201 complaint from the Recording Industry Association of America. GitHub later restored the repository and changed how it handles these complaints, adding technical and legal review before removing code when a circumvention claim isn’t clear.

For now, the repository remains on GitHub, archived and read-only. The code can still be viewed and forked, even though Nitter’s developer is no longer working on it.

The post X sent Nitter a cease-and-desist. Then it went after the source code. appeared first on The New Stack.