Cloudflare engineering director Steve Faulkner spent a week directing Claude Opus 4.6 through 800+ coding sessions, burning roughly $1,100 in API tokens, to reimplement 94% of the Next.js 16 API surface on top of Vite. The result is Vinext, an open-source Vite plugin that replaces the entire Next.js build toolchain while keeping the same developer-facing API. Both App Router and Pages Router work. You swap "next" for "vinext" in your package.json scripts and, in theory, everything just runs.
That's the pitch, anyway. And if you're thinking "didn't Cloudflare just embarrass themselves with an AI-coded Matrix server last month?", you're not wrong to be skeptical.
The actual problem Vinext is trying to solve
Next.js has a Vercel problem. The framework's build toolchain is built around Turbopack, Vercel's own bundler, and the output is optimized for Vercel's infrastructure. If you want to deploy to Cloudflare Workers, Netlify, or AWS Lambda, you need something like OpenNext to reverse-engineer that build output and reshape it for your platform. Faulkner described it bluntly in the Cloudflare blog post: the tooling is "entirely bespoke," and adapting it is "a difficult and fragile approach" because every Next.js version can break the reverse-engineering.
Vercel has acknowledged the issue. An RFC for deployment adapters appeared in April 2025, promising that "Vercel will use the same adapter API as every other partner." But adapters still build on Turbopack, and they only cover build and deploy. During development, next dev runs exclusively in Node.js with no way to plug in a different runtime. If your app uses Cloudflare-specific APIs like Durable Objects or KV, you can't test that code in dev without workarounds.
Vinext sidesteps the whole thing. Instead of adapting Next.js output, it reimplements the public API from scratch on Vite, the build tool that powers basically everything else in the frontend world: Astro, SvelteKit, Nuxt, Remix. No Turbopack anywhere in the chain.
So does it perform?
The early benchmarks look good, with some caveats I'll get to. On a 33-route App Router test app, Vinext with Vite 8 and Rolldown compiled in 1.67 seconds versus Next.js 16's 7.32 seconds with Turbopack. That's the 4.4x number you'll see in the marketing. Client bundle sizes came in at 72.9 KB gzipped for Vinext versus 168.9 KB for Next.js, the 57% reduction.
But Cloudflare themselves flag the comparison isn't entirely fair. Next.js pre-renders pages at build time by default (slower builds, faster serving). Vinext server-renders everything on each request. To make the numbers comparable, they used force-dynamic to disable Next.js static pre-rendering. So you're comparing compilation speed in isolation, not what users would actually experience in production. And it is a single 33-route fixture, not a real-world app with hundreds of pages, third-party dependencies, and complex data fetching.
I appreciate that they said this upfront. "Take them as directional, not definitive" is more honesty than you usually get from a launch blog post.
The Matrix problem
Here's where it gets interesting. In January 2026, Cloudflare published a blog post about an AI-coded Matrix homeserver on Workers. It did not go well. The project's GitHub repo initially called itself "production-grade." Matrix co-founder Matthew Hodgson responded that the post "severely overclaimed the scope of the project" and that the code lacked core features like federation, room modeling, and permission enforcement. Cloudflare quietly added a disclaimer hours later.
So when another AI-coded Cloudflare project drops a month later, healthy skepticism is warranted. But Vinext has something the Matrix project didn't: a test suite to implement against. Next.js has thousands of tests covering its public API surface, and Faulkner ported them directly. Vinext now has 1,700+ Vitest unit tests and 380 Playwright end-to-end tests. It runs Vercel's own App Router Playground as an integration test. And at least one production site, a beta for CIO.gov built by National Design Studio, is already running on it.
The README is also refreshingly honest about what doesn't work. No static pre-rendering at build time yet (it is on the roadmap). No human code review. Native Node modules like sharp crash in dev mode. Image optimization is completely different from Next.js. Google Fonts aren't self-hosted. The list goes on.
What this says about AI-driven development
Faulkner's argument is that the usual software abstraction layers exist because humans need help managing complexity, not because the complexity inherently demands them. An AI model that can hold the entire architecture in context doesn't need an intermediate framework to stay organized. It just needs a spec and a foundation.
That claim is doing a lot of heavy lifting. And I'm not sure I buy it entirely. Faulkner himself notes he "had to course-correct regularly" and that the process required constant human steering on architecture decisions, prioritization, and debugging when behavior diverged from Next.js. The contributing guide tells new contributors to use Claude Opus 4.6 "with max thinking" and to point AI agents at bugs before filing issues. Nobody has manually reviewed the codebase.
"Almost every line of code in vinext was written by AI," the blog post states. Which is true, in the same way that "almost every word in a book was typed by a keyboard." The thinking happened somewhere else.
What is genuinely impressive: the test suite made this possible. Without Next.js's comprehensive tests as a machine-readable specification, AI would have been hallucinating its way through undocumented behavior. Faulkner identified four preconditions: a well-documented target API, a comprehensive test suite, a solid build tool underneath, and a model capable of handling the complexity. Take away any one and this doesn't work.
Where this goes
Cloudflare says 95% of Vinext is pure Vite with no Cloudflare-specific code, and they got a proof of concept running on Vercel itself in under 30 minutes. Other hosting providers are apparently in discussion. The project targets Next.js 16 and plans commit-level tracking of the Next.js repo to stay current.
The deployment adapters RFC from Vercel is still in progress. Cloudflare has been collaborating on it, but Vinext represents a bet that adapters won't be enough, that the Turbopack dependency is the real bottleneck. Whether that bet pays off depends on whether the project can keep pace with Next.js releases and whether anyone beyond Cloudflare invests in maintaining it.
For now, the project is explicitly experimental. The README warns against production use without appropriate caution. But the 94% API coverage, the test infrastructure, and the candid list of limitations put it in a different category than the Matrix fiasco. Cloudflare learned something from that embarrassment. Whether they learned enough, we'll find out when real traffic hits.
