Best JS Framework for AI Coding: SvelteKit Burns 71% More Tokens Than Next.js

If you asked me last month which JavaScript framework an AI coding agent would build fastest and cheapest, I'd have said SvelteKit. Small API, little boilerplate. In Nolan Lawson's new benchmark, Claude Opus 5.5 burned 8.53 million tokens building a small Pokédex app in SvelteKit. Next.js built the same app for 4.99 million. Nuxt did it for 3.85 million.

The post is The AI cost of JavaScript frameworks, and it's the first real data I've seen on the "best JavaScript framework for AI coding" question that people keep settling on vibes.

My take after reading it and the Hacker News thread: your framework choice now comes with a token bill, and that bill depends less on how elegant the framework is than on how well the model already knows its current API.

What Lawson actually measured

He gave Claude Opus 5.5 the same spec, the same tests and the same short prompt across 12 frameworks, changing only the framework name. The prompt template from the benchmark repo is:

Implement the app described in SPEC.md using {framework}. Use the latest stable version.
Work autonomously until `npm test` passes.

The app is a Pokémon browser backed by a local copy of PokéAPI, with search and sorting. Each run happened in a fresh Podman container. Data had to be fetched at request time, so no static generation. Tailwind and component libraries were banned. Frameworks that ship an official MCP server or agent skills had them installed. Lawson took the median of 5 runs per framework, then measured the output with mobile Lighthouse (4x CPU throttling, Slow 4G).

He's upfront about the limits: one small, content-heavy app, which favors server-rendered MPAs on first-load metrics, and interactions like search aren't measured, which is where SPAs could win back ground. It's still more real data than every "agents just work better with X" tweet I've read this year.

React vs Svelte vs Vue vs vanilla JS: tokens, cost and Lighthouse results

Medians from the post, sorted by tokens:

Framework	Tokens (M)	Cost (USD)	Time (min)	JS shipped (KiB)	LCP (ms)	Lines of code
Nuxt (Vue)	3.85	$2.82	9.0	84	1727	1415
Astro	4.13	$2.76	8.2	0	810	1461
Hono+htmx	4.26	$2.67	8.6	18	978	1370
Next.js	4.99	$3.14	10.9	142	2090	1539
Vanilla (Vite)	5.00	$2.98	10.1	7	1667	1492
Qwik	5.64	$3.27	10.7	40	979	1744
TanStack Start	7.07	$3.54	10.3	118	2028	1697
SolidStart	7.13	$3.79	11.2	40	1204	1630
React Router	7.58	$3.81	12.5	115	1729	1564
SvelteKit	8.53	$4.28	10.8	36	1130	1611
Gracile+Lit	9.04	$4.65	12.1	8	956	1717
Angular	9.76	$4.97	17.2	93	1954	2009

Cost is at Claude Code API prices, not what he actually paid on a Max plan. Accessibility scored 100 everywhere, and Lighthouse performance landed between 97 and 100 for all of them, so every stack ended up with a working, decent app. Where they differ is the bill and how much JS reaches the browser.

Angular used about 2.5x the tokens of Nuxt and took nearly twice as long. Two of its five runs didn't produce a measurable app because the agent built an SSR app that rejected non-localhost requests, even though the spec said it would sit behind a reverse proxy.

Why SvelteKit cost so many tokens

The agent read SvelteKit's v3 migration guide in every single run. The prompt asked for the latest stable version, which was @sveltejs/kit 3.1.0, and Lawson thinks that release is likely too new to be in the model's training data. So each session started by catching up on APIs the model didn't know.

So yes, training-data bias, but not the version the "LLMs just default to React" crowd describes. React itself gets no special treatment. The model does well on API surface it has seen a lot of and that hasn't changed since, and Next.js and Nuxt are huge, mature and all over the training corpus. React Router and TanStack Start are both React too, and they still used 42-52% more tokens than Next.js, JSX and all.

One HN commenter, ef2k, summed it up: "A significant part of the cost is that newer framework APIs are not known to the current agents."

So the framework you love for shipping a clean new reactivity model is, right now, the one your agent has to re-learn on your dime. smrtinsert wrote that "sveltekit 2 was super quick to use for me," which fits the theory: same framework, but an API the model had already seen.

Vanilla JS didn't save tokens either

I went in expecting vanilla to be the cheapest option, on the theory that fewer abstractions means fewer APIs to hallucinate. It landed mid-pack at 5.00M tokens, basically tied with Next.js, and it was the only stack with layout shift (CLS 0.111). Its LCP of 1667 ms trailed Astro, Gracile+Lit, Hono+htmx, Qwik, SvelteKit and SolidStart.

Lawson's read is that "having some framework can be better than nothing (or better than raw Vite, anyway)." My guess at why: with raw Vite the agent has to invent routing, data loading and rendering conventions from scratch on every run, and that costs tokens too. oatmealsnap on HN made the long-term version of the argument: in a vanilla codebase, "your agents (or human devs) are going to write element.addEventListener and document.querySelectorAll countless times."

The winners were the boring ones: server-first, stable, with a small API surface. Astro shipped 0 KiB of JS, had the best LCP (810 ms) and the shortest median build time (8.2 min). Hono+htmx had the lowest median cost at $2.67 and produced the least code, 1370 lines against Angular's 2009.

Framework MCP servers and skills didn't lower the token bill

Where a framework had official AI tooling, it was installed, and agents used it inconsistently:

• SvelteKit's MCP/plugin, the React Router skill and the Hono skills: used in 5/5 runs
• Angular MCP: 3/5
• Astro MCP: 2/5
• Next.js: skill files read in 1/5 runs, AGENTS.md in 2/5
• Nuxt MCP: never used

Put that list next to the token table. Nuxt never touched its MCP server and was the cheapest on tokens. SvelteKit used its tooling every time and was the third most expensive. Lawson says he suspects the current crop of framework MCPs and skills "may be doing more harm than good." I'd go further: if your framework needs an MCP server so the agent can write it correctly, that's the framework tax showing up on your invoice.

Why your agent keeps picking Next.js

h0rv noted on HN that among their vibe-coder friends who let the agent decide, "the default stack is always Next.js, Vercel, and Supabase." In another subthread, buildfocus wrote: "I would be very surprised if the tool that agents use most effectively is also the one they recommend."

Lawson's data partly vindicates the agent here, since Next.js was cheap to generate. But it also shipped the most JavaScript of any framework (142 KiB), had the worst median LCP (2090 ms) and posted 71 ms of total blocking time. Lawson pins the wide LCP spread across Next.js runs on lazy-loading: one app avoided it and the other four didn't. So Next.js was cheap to write and expensive to serve. You pay the token bill once, and your users pay for the 142 KiB on every page load.

How I'd pick a JavaScript framework for agent-written code now

Here's what I'm changing in my own setup:

1. Check whether the framework's current major version predates your model's training cutoff. If the agent has to read a migration guide to start, you'll pay for that in every fresh session. Pin the previous major if the new one buys you nothing for this project.
2. Default to server-rendered for content-heavy work. Nuxt, Astro and Hono+htmx were the three cheapest to build in this benchmark, and Astro (0 KiB) and Hono+htmx (18 KiB) shipped almost no JS.
3. Don't go vanilla to save tokens. You won't. Go vanilla because you want zero dependencies, and write the conventions down in your repo so the agent stops reinventing them.
4. Don't assume framework MCP servers help. Compare a few runs with and without them before adopting one team-wide.
5. Run your own version. The benchmark repo takes a framework name and a spec. Swap in a spec that looks like your app. The README recommends "3 or more iterations before drawing conclusions," and I'd take that seriously. n=5 on one Pokédex app is enough to make me suspicious of my defaults, and not much more.

Lawson ends with the question I keep coming back to: "Are you really picking your tech stack based on evidence? Or are you just going with what you already know?" With agents in the loop, "what the model already knows" is part of that answer now, like it or not.

Has your coding agent ever talked you into React or Next.js when you didn't need it? And which framework does it actually write best for you? If you've got token counts from your own projects that contradict this table, post them. I want to see them.

Sources

• Nolan Lawson, The AI cost of JavaScript frameworks (Oct 28, 2026)
• nolanlawson/agent-framework-benchmark and results
• Hacker News discussion