v0 vs Claude Code for UI: Ownership, Screens and Cost

The v0 vs Claude Code question usually gets answered on one component: a card or a form, generated in a minute. The harder part starts at the third screen. A sign-in page, a pricing page and a settings page belong to one product, so they have to share buttons, fields, spacing and tone, call your real API, and still match after six months of changes. This post compares v0 and Claude Code on that yardstick: who owns and maintains the code, how each keeps many screens consistent, what each costs and where each one wins. Lovable sits alongside.

We build Wingo UI, a component registry that Claude Code installs from, so read this as a vendor's view. We ran no generation benchmark and show no v0 or Lovable output: what we say about them comes from their docs and pricing pages, checked in October 2026 and linked. The Claude Code side uses our real Login, Pricing and Settings Page blocks. More head to head posts live under Comparisons and alternatives, and the shadcn alternatives guide covers the libraries these tools install.

How are v0 and Claude Code different?

v0 is a hosted builder: you chat on v0.app, it writes code in a sandbox, previews it and deploys to Vercel. Claude Code is an agent in your repository: it reads and edits your files, runs your commands and commits through git, from the terminal, an IDE, the desktop app or the web. Lovable is another hosted builder with a live preview, and it picks the framework and the database for you.

As of October 2026, from each vendor's own docs:

Sources: the v0 FAQ (opens in a new tab), GitHub docs (opens in a new tab), Design Systems 2.0 (opens in a new tab) and pricing (opens in a new tab); the Claude Code overview (opens in a new tab) and Claude pricing (opens in a new tab); the Lovable FAQ (opens in a new tab), plans (opens in a new tab) and design systems (opens in a new tab).

The two have converged: v0 imports existing repositories and opens pull requests, and its sandbox ships with Claude Code pre-installed in the terminal, on by default outside Enterprise and billed to the team's AI Gateway credits (v0 docs (opens in a new tab)). What still separates them is the loop. v0's centers on the preview: prompt, look, adjust, publish. Claude Code's centers on the diff: prompt, read the change, run your type-check and tests, commit.

Who owns AI-generated UI code, and who maintains it?

You do: v0 and Lovable say so in their own terms, and Claude Code writes straight into your repository. The difference is where the source of truth lives and whether anything upstream can fix it later.

The v0 FAQ says "Vercel doesn't own the code generated based on your queries and prompts." Once you connect GitHub, the repository "becomes the source of truth for your project's code": each chat gets its own branch, v0 pushes changes to it automatically, and publishing merges a pull request. The Lovable FAQ says "Your apps, code, and the content you create with Lovable are yours." Claude Code edits your working tree, and you decide what gets committed.

Ownership has a second half the vendor FAQs skip: maintenance. Whatever generator writes them, generated screens have no upstream. When the sign-in screen mishandles a pasted one-time code, nobody ships a patch: you prompt for a fix, screen by screen, and hope each chat fixes it the same way.

Code installed from a registry has an upstream. Our blocks carry versions (in release 1.7.0 the Login Page is 1.0.1, the Pricing Page 1.1.0 and the Settings Page 1.0.0), the CLI records what it installed, and update runs a 3-way merge that keeps your edits:

npx wingo-ui@latest outdated            # installed items vs the latest release
npx wingo-ui@latest diff login-page     # your file vs upstream
npx wingo-ui@latest update login-page   # merge upstream changes into your edited file

That upstream comes with the code, whichever tool installs it; v0's agent also runs shell commands in its sandbox (opens in a new tab), though we have not tried our CLI there. Our guide to updating copied components without losing edits shows the merge step by step.

How do you keep AI-built screens consistent?

Make every screen import the same component files, and give the agent rules that forbid anything else. "Match the other pages" in a prompt does not survive a new chat.

v0's answer is Design Systems 2.0: you teach v0 your system once from an npm package, a repository or an app that uses it, and v0 saves it as a skill that a team owner on a paid plan can make the default for new chats. Its core rule is strict in the right way: "If a component, prop, or token cannot be verified from the sources, v0 should not use it." Two limits matter here: existing projects do not update when the skill changes (you ask v0 to update each one), and an import should stick to one design system and one framework stack where possible. Lovable copies a design system into src/design-system/<slug>/ of each connected project and offers new versions as an "Update available" prompt in the project chat.

With Claude Code, consistency lives in the repository. The three Wingo UI blocks share code at the file level: the Login Page, the Pricing Page and the Settings Page all import Button from @/components/ui/button, and their dependency trees share 13 registry items, among them the avatar, the toast, the spinner, the tones and the motion presets. Change the button file once and the sign-in submit, the plan buttons and the settings save bar change together.

Every block also reads its defaults through the UI config provider, so one UIProvider in the root layout sets the tone and corners of all three screens, and a prop on one page still wins:

// app/layout.tsx
import type { ReactNode } from "react";
import { UIProvider } from "@/lib/ui-config";
import "./globals.css";

// keyed by each block's data-slot name
const defaults = {
  "login-page": { tone: "brand", radius: "lg" },
  "pricing-page": { tone: "brand", ctaTone: "brand", radius: "lg" },
  "settings-page": { tone: "brand", radius: "lg" },
};

export default function RootLayout({ children }: { children: ReactNode }) {
  return (
    <html lang="en">
      <body>
        <UIProvider defaults={defaults}>{children}</UIProvider>
      </body>
    </html>
  );
}

The rules file closes the loop: a few lines in CLAUDE.md saying that screens are built from installed blocks and components and that the agent searches the MCP server before it writes UI. Our Claude Code shadcn setup has the full block, and the component library MCP guide explains why the rules and the server need each other.

The sign-in screen below is the Login Page block with nothing wired; its simulated sign-in rejects passwords shorter than 8 characters.

How do you build sign-in, pricing and settings pages with Claude Code?

Install the blocks, then spend the agent on the wiring: handlers, data and routes, the part only your repository knows.

npx wingo-ui@latest login                                      # Pro items need a signed-in key
npx wingo-ui@latest add login-page pricing-page settings-page

The CLI writes the blocks to components/blocks, everything they import to components/ui, hooks and lib, and installs their npm packages. In release 1.7.0 the three blocks and their dependencies come to 83 registry items in 88 files. The blocks are Pro; the Button they share is free.

Each route is then one block with your handlers and copy. The sign-in page:

// app/(auth)/sign-in/page.tsx
"use client";

import Link from "next/link";
import { useRouter } from "next/navigation";
import { LoginPage } from "@/components/blocks/login-page";

export default function SignInRoute() {
  const router = useRouter();
  return (
    <LoginPage
      layout="centered"
      logo={<span className="text-lg font-semibold">Acme</span>}
      labels={{ appName: "Acme", signInDescription: "Sign in to your Acme account to continue." }}
      methods={["password"]}
      showProviders={false}
      registerHref="/sign-up"
      linkComponent={Link}
      onSignIn={async ({ email, password, remember }) => {
        const res = await fetch("/api/auth/sign-in", { method: "POST", body: JSON.stringify({ email, password, remember }) });
        if (!res.ok) throw new Error("The email or the password is not correct");
      }}
      onSuccess={() => router.push("/dashboard")}
    />
  );
}

The pricing page, with your plans inside your own site header and footer:

// app/(marketing)/pricing/page.tsx
"use client";

import Link from "next/link";
import { useRouter } from "next/navigation";
import { PricingPage } from "@/components/blocks/pricing-page";
import type { PricingPlan } from "@/components/ui/pricing-table";

const PLANS: PricingPlan[] = [
  { id: "free", name: "Free", price: 0, features: ["3 projects", "Community support"], cta: { label: "Start for free" } },
  {
    id: "pro",
    name: "Pro",
    price: { monthly: 12, yearly: 120 },
    featured: true,
    features: ["Unlimited projects", "Priority email support"],
    cta: { label: "Start a 14 day trial" },
  },
];

export default function PricingRoute() {
  const router = useRouter();
  return (
    <PricingPage
      plans={PLANS}
      currencies={["USD"]}
      labels={{ title: "Simple pricing for every team", subtitle: "Start free and upgrade when you need more projects." }}
      faqs={[{ question: "Can I cancel anytime?", answer: "Yes. Your plan stays active until the end of the period you paid for." }]}
      header={false}
      footer={false}
      showComparison={false}
      showLogos={false}
      showTestimonials={false}
      showCta={false}
      linkComponent={Link}
      onSelectPlan={(planId, period) => router.push(`/checkout?plan=${planId}&period=${period}`)}
    />
  );
}

On the Pricing Page, the period switch rolls every price to its new value, and in a column narrower than 768px, like the one below or a phone, the plans turn into a swipeable carousel that starts on the featured plan.

And the settings page, saving each section to your API (password, two-step and session changes have their own handlers):

// app/(app)/settings/page.tsx
"use client";

import { SettingsPage } from "@/components/blocks/settings-page";

export default function SettingsRoute() {
  return (
    <SettingsPage
      sections={["profil", "cont", "notificari", "securitate"]}
      onSave={async (section, values) => {
        const res = await fetch(`/api/settings/${section}`, { method: "PUT", body: JSON.stringify(values) });
        if (!res.ok) throw new Error("We could not save. Please try again.");
      }}
    />
  );
}

Three things the blocks leave to you:

• Simulated handlers. A handler you leave out stays simulated so the demo works: without onVerifyCode the code views accept 123456, and without onSave the settings page pretends to save.
• Sample content. The defaults describe demo companies: Northwind CRM on sign-in, Acme CRM on pricing, Emma Carter's profile in settings. Pass your own labels, logo, plans, faqs and profile.
• Section ids. The settings sections are keyed by Romanian words (profil, cont, notificari, facturare, securitate, pericol), while the labels default to English. The billing form validates a Romanian company ID (CUI) and a Romanian address, so leave facturare out if you bill elsewhere.

A prompt that covers all three: "Build /sign-in, /pricing and /settings from the installed Wingo UI blocks, reading their props with get_block first. Wire every handler to app/api, list any on* handler left on its simulated default, then type-check and lint."

The Settings Page below is narrower than 768px here, so it shows its phone layout: a list that pushes each section in.

How much do v0, Lovable and Claude Code cost?

Entry plans cost about the same, $20 to $30 a month, but each meters something different: v0 pricing turns tokens into credits, Lovable charges credits per message, and Claude Code comes with a subscription's usage limits or bills API tokens. Prices as of October 2026, before tax:

Lovable's credit examples come from its pricing page (opens in a new tab). We did not measure what each tool spends on these screens, so we put no price on a screen. One structural point is safe: the three blocks' own files are about 7,650 lines of TypeScript, and the settings page with its dependencies is 74 registry items. Generating screens of that depth costs output tokens or credits on every line, and again on every fix. Installing them costs none, and the agent's budget goes to the wiring.

When should you use v0, and when Claude Code?

v0 wins before there is a repository. Claude Code wins once there is one.

v0 is the better choice when:

• You need a clickable screen today, at a URL you can share. Deploys take one click.
• A designer does the iterating. Design Mode edits styles visually on every plan, Free included, and on paid plans v0 turns a Figma link into a working app (opens in a new tab).
• Your stack is already Next.js, Tailwind CSS and shadcn/ui on Vercel, so v0's defaults are your defaults.

Claude Code is the better choice when:

• The screens call your real APIs, with your environment variables, database and tests.
• You are building the tenth screen of a product, and it has to match the first nine.
• Your stack is not v0's default: another framework, another component library, a monorepo.
• You want every change as a diff you read before it lands.

Lovable vs Claude Code is a different question: who is building. Lovable suits a founder who does not want to read code and needs a hosted app with a database. It offers no framework choice and cannot connect an existing repository, so a developer with a Next.js codebase is better served by Claude Code.

As of October 2026, a search for v0 vs Claude Code Reddit threads mostly returns comparison sites, and the advice they repeat is the hybrid: draft in v0, integrate with Claude Code. That holds, with one change for products with many screens: let the draft settle the layout, then build the real screens from components already in your repository, so the draft never becomes your design system.

Where does Cursor fit next to v0 and Claude Code?

In a v0 vs Cursor vs Claude Code comparison, Cursor sits on Claude Code's side of the line: an editor whose agent works on the files in your repository, and Claude Code runs inside it through the same extension it uses in VS Code (Claude Code overview (opens in a new tab)). Between those two, pick the interface you prefer; the v0 question stays the same.

Where should you start?

If you have no repository yet and need something to show this week, start in v0 and connect GitHub from the first chat. If you have a repository, put the screens there. Connect the Wingo UI MCP server with npx wingo-ui@latest agents install claude, install the three blocks and spend your prompts on wiring. The blocks are part of Wingo UI Pro; the Button they share and 74 other items are free.

FAQ

Is v0 better than Claude Code for building UI?

For a first draft you can click through and share, often yes: v0 shows a live preview, edits styles visually and deploys with one click. For screens that call your real API, follow your conventions and must match screens built months earlier, Claude Code fits better because it works in your repository with your files and rules.

Can I use v0 and Claude Code together?

Yes. Connect the v0 project to GitHub and pull its branch into your local checkout for Claude Code. As of October 2026, v0 also pre-installs Claude Code in its sandbox terminal, where its requests use your team's AI Gateway credits.

Who owns the code that v0 or Lovable generates?

You do, by their own terms as of October 2026. The v0 FAQ says Vercel does not own the code generated from your prompts, and the Lovable FAQ says your apps, code and content are yours, subject to third-party rights such as open source licenses.

Does Lovable support Next.js?

No. As of October 2026 the Lovable FAQ says it does not offer a choice of framework: new apps use TanStack Start and older ones React with Vite. If your app runs on Next.js, v0 or Claude Code fit better.

How much does Claude Code cost?

As of October 2026 it is not in Claude Free; it is included in Claude Pro at $20 a month, or $17 a month billed yearly, and in Max from $100 a month. It also runs on an Anthropic API key billed by usage, and Team seats start at $20 a month billed yearly.

Can Claude Code install the Wingo UI login, pricing and settings pages?

Yes. Run npx wingo-ui@latest add login-page pricing-page settings-page and the CLI writes the three blocks and everything they import into your project. They are Pro items, so sign in first with npx wingo-ui@latest login.