Open VSX Hits 300 Million Monthly Downloads, and the Quiet Infrastructure Behind AI Coding Tools Gets a Stress Test

In the AI developer boom, some of the most important battlegrounds are not glamorous models or splashy chatbots. They are the quiet pipes that keep modern coding tools fed and up to date.

One of those pipes sits under a surprising number of the new AI-native, cloud-based coding environments: the Open VSX Registry, a vendor-neutral, open-source alternative to the Microsoft Visual Studio Marketplace, governed by the Eclipse Foundation. It provides a platform to host and download extensions for VS Code, Eclipse Theia, and other IDEs, supporting a decentralized, flexible ecosystem for developer tools. In a statement, the foundation said the registry has surpassed 300 million downloads per month, with peak daily traffic exceeding 50 million requests. It now hosts more than 10,000 extensions from over 6,500 publishers, numbers that make it less like a helpful community service and more like a piece of global infrastructure that can fail loudly.

“The Open VSX has evolved into foundational infrastructure for the global developer ecosystem,” Mike Milinkovich, executive director of the Eclipse Foundation, said in a statement. “As adoption accelerates across AI native and cloud-based development platforms, we are investing to ensure the registry remains secure, resilient, and vendor-neutral. Support from leading commercial adopters reinforces Open VSX as a trusted, shared infrastructure.”

That last phrase, "shared infrastructure," is doing a lot of work. In a world where developer tools are increasingly packaged as services, extension distribution has become a kind of oxygen. If a registry slows down, the effects ripple outward: IDEs struggle to install the plugins that developers expect, automated build systems stall, and support teams inherit a new category of outage that feels absurdly low-level until it breaks production.

The registry AI IDEs did not mean to stress test
Open VSX started with a practical constraint. As described in the briefing notes shared alongside the announcement, the VS Code Marketplace can be used only with Microsoft-branded products, pushing other VS-Code-compatible tools to seek alternatives. Eclipse Open VSX became that alternative: an open-source, self-hostable project, with the public Open VSX Registry serving as the hosted instance anyone can use.

For years, that was mostly a story about forks, cloud IDEs, and developer choice. Then, agentic AI and always-on automation entered the conversation.

In a press briefing, Thabang Mashologu, CMO and Head of Products at the Eclipse Foundation, described the growth as a “hockey stick,” driven largely by AI IDEs and cloud IDEs that install and update extensions at a pace the registry “was never meant for.” One way to think about it, he suggested, is that a single user can start behaving “more like dozens of individuals” once AI agents and automated workflows begin pulling dependencies and refreshing toolchains continuously. Add CI pipelines that rebuild often and at scale, and the request curve stops looking like human behavior.

The foundation says the effect is measurable. The registry’s infrastructure costs have climbed sharply as storage, compute, and bandwidth demands ballooned well beyond initial expectations. In the briefing, Mashologu put it bluntly: “Open source is free, but infrastructure is not.”

The list of platforms leaning on Open VSX reads like a roll call of the post-VS Code ecosystem. Eclipse cited Amazon’s Kiro, Google’s Antigravity, Cursor, IBM’s Bob, VSCodium, Windsurf, and Ona (formerly Gitpod), among others. The registry’s role is straightforward but essential: it is where those tools get extensions, and where extension publishers get distribution without being locked to a single vendor’s storefront.

In other words, Open VSX is one of the places where the idea of “AI native development” meets the reality of mundane supply chain logistics.

When extension distribution becomes a security problem
Reliability is not the only issue that appears once something becomes widely used infrastructure. Attackers notice too.

Package registries have long been a tempting target, and extensions are a cousin of packages: third-party code that runs inside environments with access to projects, credentials, and developer workflows. The Eclipse Foundation says Open VSX is introducing a new pre-publication verification framework to identify security risks before extensions go live.

The framework is intended to detect namespace impersonation and extension name spoofing, flag exposed credentials or embedded secrets, scan for known malicious patterns, and quarantine suspicious uploads for review prior to publication.

This is the security posture of an ecosystem growing up fast. A decade ago, an extension marketplace could act like a friendly library. In 2026, it has to behave more like a border crossing.

The foundation also says it is implementing “responsible rate limiting and traffic management” to maintain stable availability during surges. The key nuance is who gets throttled. The stated aim is to target sustained, high-volume automated traffic while keeping normal usage unchanged for most developers and open-source projects.

This matters because the same automation that drives growth can also unintentionally resemble abuse. An AI-powered IDE that updates extensions in bulk across fleets of cloud workspaces might not be malicious, but it can still hammer a shared service like a botnet if left unchecked.

The money question, and why it is suddenly on the table
Open-source infrastructure has a familiar problem: everyone depends on it, and too few people pay for it, at least not until something breaks. Eclipse is trying to get ahead of the breaking part.

The foundation said Amazon Web Services has made a “strategic investment” to strengthen reliability, performance, and security across Eclipse-operated open infrastructure, including Open VSX. Eclipse says AWS support will accelerate improvements in traffic management, malware detection, and platform resilience.

Cursor, one of the fastest-growing AI-native developer environments, is also supporting Open VSX as its extension traffic grows, Eclipse said.

If that sounds like a polite sentence from a press release, it is also an admission that the economics of extension distribution are shifting. The registry has become a production dependency for commercial platforms serving millions of users. At that scale, treating it as a free background service starts to look like a category error.

Mashologu framed the change as a broader industry move toward shared responsibility. The registry is still intended to remain free for developers and open-source projects, but the foundation is building a model in which the heaviest commercial users contribute financially and, in some cases, engineering resources.

It's a familiar pattern in critical infrastructure, from undersea cables to cloud hosting: once the pipe becomes essential, the question becomes who funds the maintenance and who gets a say in governance.

A new architecture built to fail less often
Scale exposes single points of failure. Open VSX is attempting to remove some of them by reshaping where and how the service runs.

Eclipse says the registry is transitioning to a hybrid, multi-region architecture. Core services will operate in AWS in Europe as the primary production environment, with a fully operational on-premises deployment in Canada maintained as an independent secondary environment.

The foundation emphasizes that registry data, backups, and telemetry will remain within those regions and will be encrypted in transit and at rest. The pitch is resilience and operational independence, with fewer ways for a single outage to cascade into a developer tooling crisis.

There's also an ideological subtext. Vendor-neutral infrastructure is not only about who owns the marketplace. It is about designing systems that can remain open, portable, and governable even when the underlying cloud provider is a major industry player. The on-premises secondary environment in Canada is a concrete nod to that independence.

The invisible irony of “AI everything”
AI is transforming developer workflows, but it's also dragging the supporting scaffolding into the spotlight. That's the real story underneath the 300 million number.

AI IDEs promise to compress time: fewer manual steps, faster scaffolding, automated refactors, and agents that keep projects humming. But each of those conveniences can multiply the background activity that modern development depends on, including extension installs, updates, and validation across ephemeral environments.

The result is a quiet inversion. The more automated software creation becomes, the more society depends on a handful of shared services that most developers never think about until they fail. Open VSX is one of those services, and Eclipse is now treating it accordingly: as infrastructure that needs funding, hardened security controls, and a design built for the kinds of traffic patterns only AI scale automation can produce.

Or, as Mashologu summed it up during the briefing, the headline is simple: Open VSX is growing exponentially, and the foundation is working with major adopters and the community to make sure it grows “in a graceful way.”

What comes next
Eclipse is positioning Open VSX as a visible pillar of the broader AI-integrated developer tooling ecosystem, and it plans to highlight more updates at Open Community Experience (OCX) 2026, the foundation’s flagship developer conference, April 21 to 23 in Brussels.

For developers, Open VSX may still feel like plumbing. For companies building the next generation of AI-native IDEs, it's closer to a shared utility. Eclipse’s message is that the utility has reached the point where goodwill and best effort are no longer enough, and that sustaining trust now requires both new security machinery and real investment in the infrastructure itself.

Posted by John K. Waters on March 3, 2026