v0 vs Claude Code für UI: Code, Screens und Kosten

Die Frage v0 vs Claude Code wird meist an einer einzigen Komponente entschieden: eine Karte oder ein Formular, in einer Minute generiert. Der schwierige Teil beginnt beim dritten Screen. Eine Login-Seite, eine Pricing-Seite und eine Einstellungsseite gehören zu einem Produkt. Sie müssen sich Buttons, Felder, Abstände und Ton teilen, deine echte API aufrufen und auch nach sechs Monaten Änderungen noch zusammenpassen. Dieser Artikel vergleicht v0 und Claude Code an diesem Maßstab: wem der Code gehört und wer ihn pflegt, wie beide viele Screens einheitlich halten, was sie kosten und wo jedes Tool gewinnt. Lovable nehmen wir nebenbei mit.

Wir bauen Wingo UI, eine Komponenten-Registry, aus der Claude Code installiert. Lies das also als Sicht eines Anbieters. Wir haben keinen Generierungs-Benchmark gemacht und zeigen keinen Output von v0 oder Lovable: Was wir über die beiden sagen, stammt aus ihrer Doku und ihren Preisseiten, geprüft im Oktober 2026 und verlinkt. Für Claude Code nutzen wir unsere echten Blöcke Login Page, Pricing Page und Settings Page. Weitere direkte Vergleiche findest du unter Vergleiche und Alternativen, und unser Überblick über shadcn-Alternativen behandelt die Bibliotheken, die diese Tools installieren.

Worin unterscheiden sich v0 und Claude Code?

v0 ist ein gehosteter Builder: Du chattest auf v0.app, v0 schreibt Code in einer Sandbox, zeigt eine Vorschau und deployt auf Vercel. Claude Code ist ein Agent in deinem Repository: Er liest und bearbeitet deine Dateien, führt deine Befehle aus und committet über git, aus dem Terminal, einer IDE, der Desktop-App oder dem Web. Lovable ist ein weiterer gehosteter Builder mit Live-Vorschau, und er wählt Framework und Datenbank für dich.

Stand Oktober 2026, laut der Doku der jeweiligen Anbieter:

Quellen: bei v0 das FAQ (opens in a new tab), die GitHub-Doku (opens in a new tab), Design Systems 2.0 (opens in a new tab) und die Preise (opens in a new tab); bei Claude Code die Übersicht (opens in a new tab) und die Claude-Preise (opens in a new tab); bei Lovable das FAQ (opens in a new tab), die Pläne (opens in a new tab) und die Design Systems (opens in a new tab).

Die beiden haben sich angenähert: v0 importiert bestehende Repositories und öffnet Pull Requests, und seine Sandbox bringt Claude Code vorinstalliert im Terminal mit, außerhalb von Enterprise standardmäßig aktiv und über die AI-Gateway-Credits des Teams abgerechnet (v0-Doku (opens in a new tab)). Was sie weiter trennt, ist die Arbeitsschleife. Bei v0 steht die Vorschau im Mittelpunkt: prompten, anschauen, anpassen, veröffentlichen. Bei Claude Code steht der Diff im Mittelpunkt: prompten, die Änderung lesen, Type-Check und Tests laufen lassen, committen.

Wem gehört KI-generierter UI-Code, und wer pflegt ihn?

Dir: v0 und Lovable sagen das in ihren eigenen Bedingungen, und Claude Code schreibt direkt in dein Repository. Der Unterschied liegt darin, wo die Source of Truth liegt und ob es einen Upstream gibt, der Fehler später beheben kann.

Laut dem v0-FAQ gehört Vercel der Code nicht, der aus deinen Anfragen und Prompts entsteht (v0-FAQ (opens in a new tab)). Sobald du GitHub verbindest, wird das Repository laut der GitHub-Doku von v0 (opens in a new tab) zur maßgeblichen Quelle für den Code deines Projekts: Jeder Chat bekommt seinen eigenen Branch, v0 pusht Änderungen automatisch dorthin, und beim Veröffentlichen wird ein Pull Request gemergt. Das Lovable-FAQ (opens in a new tab) sagt, dass deine Apps, dein Code und die Inhalte, die du mit Lovable erstellst, dir gehören. Claude Code bearbeitet deinen Working Tree, und du entscheidest, was committet wird.

Zum Eigentum gehört noch etwas, das die FAQs der Anbieter auslassen: die Pflege. Egal welcher Generator sie schreibt, generierte Screens haben keinen Upstream. Wenn die Login-Seite einen eingefügten Einmalcode falsch verarbeitet, liefert niemand einen Patch: Du promptest einen Fix, Screen für Screen, und hoffst, dass jeder Chat ihn gleich umsetzt.

Code aus einer Registry hat einen Upstream. Unsere Blöcke tragen Versionen (in Release 1.7.0 ist die Login Page 1.0.1, die Pricing Page 1.1.0 und die Settings Page 1.0.0), das CLI merkt sich, was es installiert hat, und update führt einen 3-Way-Merge aus, der deine Änderungen behält:

npx wingo-ui@latest outdated            # installierte Einträge vs. neuestes Release
npx wingo-ui@latest diff login-page     # deine Datei vs. upstream
npx wingo-ui@latest update login-page   # upstream-Änderungen in deine bearbeitete Datei mergen

Dieser Upstream kommt mit dem Code mit, egal welches Tool ihn installiert; der Agent von v0 führt auch Shell-Befehle in seiner Sandbox (opens in a new tab) aus, unser CLI haben wir dort aber nicht ausprobiert. Unsere Anleitung zum Aktualisieren kopierter Komponenten, ohne Änderungen zu verlieren zeigt den Merge Schritt für Schritt.

Wie hältst du KI-gebaute Screens einheitlich?

Lass jeden Screen dieselben Komponentendateien importieren und gib dem Agenten Regeln, die alles andere verbieten. „Pass es an die anderen Seiten an“ im Prompt überlebt keinen neuen Chat.

Die Antwort von v0 heißt Design Systems 2.0: Du bringst v0 dein System einmal bei, aus einem npm-Paket, einem Repository oder einer App, die es nutzt, und v0 speichert es als Skill. Ein Team-Owner in einem bezahlten Plan kann ihn zum Standard für neue Chats machen. Die Kernregel ist streng, und zwar an der richtigen Stelle: Was sich aus den Quellen nicht als Komponente, Prop oder Token belegen lässt, soll v0 laut der Doku zu Design Systems 2.0 (opens in a new tab) nicht verwenden. Zwei Einschränkungen sind hier wichtig: Bestehende Projekte aktualisieren sich nicht, wenn sich der Skill ändert (du bittest v0, jedes einzeln zu aktualisieren), und ein Import sollte sich nach Möglichkeit auf ein Design System und einen Framework-Stack beschränken. Lovable kopiert ein Design System nach src/design-system/<slug>/ in jedes verbundene Projekt und bietet neue Versionen im Projekt-Chat als Hinweis „Update available“ an.

Bei Claude Code liegt die Einheitlichkeit im Repository. Die drei Wingo-UI-Blöcke teilen sich Code auf Dateiebene: Login Page, Pricing Page und Settings Page importieren alle Button aus @/components/ui/button, und ihre Abhängigkeitsbäume teilen sich 13 Registry-Einträge, darunter Avatar, Toast, Spinner, die Tones und die Motion-Presets. Änderst du die Button-Datei einmal, ändern sich der Submit-Button beim Login, die Plan-Buttons und die Speicherleiste der Einstellungen gemeinsam.

Jeder Block liest seine Defaults außerdem über den Provider UI Config. Ein einziger UIProvider im Root Layout setzt also Ton und Ecken aller drei Screens, und ein Prop auf einer Seite gewinnt trotzdem:

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

// Schlüssel ist der data-slot-Name jedes Blocks
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="de">
      <body>
        <UIProvider defaults={defaults}>{children}</UIProvider>
      </body>
    </html>
  );
}

Die Regeldatei schließt den Kreis: ein paar Zeilen in der CLAUDE.md, die sagen, dass Screens aus installierten Blöcken und Komponenten gebaut werden und dass der Agent den MCP-Server durchsucht, bevor er UI schreibt. Unser Claude-Code-Setup mit shadcn und MCP enthält den vollständigen Block, und der Leitfaden zu MCP für Komponentenbibliotheken erklärt, warum Regeln und Server einander brauchen.

Der Login-Screen unten ist der Block Login Page ohne jede Anbindung; sein simulierter Login lehnt Passwörter unter 8 Zeichen ab.

Wie baust du Login-, Pricing- und Einstellungsseiten mit Claude Code?

Installier die Blöcke und setz den Agenten für die Anbindung ein: Handler, Daten und Routen, also den Teil, den nur dein Repository kennt.

npx wingo-ui@latest login                                      # Pro-Einträge brauchen einen angemeldeten Key
npx wingo-ui@latest add login-page pricing-page settings-page

Das CLI schreibt die Blöcke nach components/blocks, alles, was sie importieren, nach components/ui, hooks und lib, und installiert ihre npm-Pakete. In Release 1.7.0 kommen die drei Blöcke mit ihren Abhängigkeiten auf 83 Registry-Einträge in 88 Dateien. Die Blöcke sind Pro; der Button, den sie sich teilen, ist kostenlos.

Jede Route ist dann ein Block mit deinen Handlern und Texten. Die Login-Seite:

// 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: "Melde dich bei deinem Acme-Konto an, um fortzufahren." }}
      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("E-Mail oder Passwort ist nicht korrekt");
      }}
      onSuccess={() => router.push("/dashboard")}
    />
  );
}

Die Pricing-Seite, mit deinen Plänen in deinem eigenen Header und 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 Projekte", "Community-Support"], cta: { label: "Kostenlos starten" } },
  {
    id: "pro",
    name: "Pro",
    price: { monthly: 12, yearly: 120 },
    featured: true,
    features: ["Unbegrenzte Projekte", "Bevorzugter E-Mail-Support"],
    cta: { label: "14 Tage testen" },
  },
];

export default function PricingRoute() {
  const router = useRouter();
  return (
    <PricingPage
      plans={PLANS}
      currencies={["USD"]}
      labels={{ title: "Einfache Preise für jedes Team", subtitle: "Starte kostenlos und wechsle in einen größeren Plan, wenn du mehr Projekte brauchst." }}
      faqs={[{ question: "Kann ich jederzeit kündigen?", answer: "Ja. Dein Plan bleibt bis zum Ende des bezahlten Zeitraums aktiv." }]}
      header={false}
      footer={false}
      showComparison={false}
      showLogos={false}
      showTestimonials={false}
      showCta={false}
      linkComponent={Link}
      onSelectPlan={(planId, period) => router.push(`/checkout?plan=${planId}&period=${period}`)}
    />
  );
}

Auf der Pricing Page rollt der Zeitraum-Schalter jeden Preis auf seinen neuen Wert, und in einer Spalte unter 768px Breite, wie unten oder auf einem Smartphone, werden die Pläne zu einem wischbaren Karussell, das beim hervorgehobenen Plan startet.

Und die Einstellungsseite, die jeden Abschnitt über deine API speichert (für Passwort, Zwei-Faktor-Login und Sessions gibt es eigene Handler):

// 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("Speichern hat nicht geklappt. Bitte versuch es noch einmal.");
      }}
    />
  );
}

Drei Dinge überlassen die Blöcke dir:

• Simulierte Handler. Ein Handler, den du weglässt, bleibt simuliert, damit die Demo funktioniert: Ohne onVerifyCode akzeptieren die Code-Ansichten 123456, und ohne onSave tut die Einstellungsseite nur so, als würde sie speichern.
• Beispielinhalte. Die Defaults beschreiben Demo-Firmen: Northwind CRM beim Login, Acme CRM bei den Preisen, das Profil von Emma Carter in den Einstellungen. Übergib deine eigenen labels, logo, plans, faqs und profile.
• Abschnitts-IDs. Die Abschnitte der Einstellungen haben rumänische Wörter als Schlüssel (profil, cont, notificari, facturare, securitate, pericol), die Labels sind standardmäßig englisch. Das Abrechnungsformular validiert eine rumänische Firmen-ID (CUI) und eine rumänische Adresse, also lass facturare weg, wenn du anderswo abrechnest.

Ein Prompt, der alle drei abdeckt: „Bau /sign-in, /pricing und /settings aus den installierten Wingo-UI-Blöcken und lies vorher mit get_block ihre Props. Verbinde jeden Handler mit app/api, liste jeden on*-Handler auf, der noch simuliert ist, und lass dann Type-Check und Lint laufen.“

Die Settings Page unten ist hier schmaler als 768px und zeigt deshalb ihr Smartphone-Layout: eine Liste, aus der jeder Abschnitt als eigene Ansicht hereingeschoben wird.

Was kosten v0, Lovable und Claude Code?

Die Einstiegspläne kosten ungefähr gleich viel, 20 bis 30 $ im Monat, aber jedes Tool rechnet etwas anderes ab: Das v0 Pricing rechnet Tokens in Credits um, Lovable berechnet Credits pro Nachricht, und Claude Code bringt die Nutzungslimits eines Abos mit oder rechnet API-Tokens ab. Preise Stand Oktober 2026, ohne Steuern:

Die Credit-Beispiele von Lovable stammen von seiner Preisseite (opens in a new tab). Wir haben nicht gemessen, was jedes Tool für diese Screens ausgibt, also nennen wir keinen Preis pro Screen. Eine Aussage zur Struktur ist sicher: Die eigenen Dateien der drei Blöcke umfassen etwa 7.650 Zeilen TypeScript, und die Einstellungsseite mit ihren Abhängigkeiten besteht aus 74 Registry-Einträgen. Screens dieser Tiefe zu generieren kostet Output-Tokens oder Credits für jede Zeile, und das bei jedem Fix noch einmal. Sie zu installieren kostet nichts, und das Budget des Agenten fließt in die Anbindung.

Wann nimmst du v0 und wann Claude Code?

v0 gewinnt, bevor es ein Repository gibt. Claude Code gewinnt, sobald es eins gibt.

v0 ist die bessere Wahl, wenn:

• Du heute einen klickbaren Screen unter einer teilbaren URL brauchst. Deploys gehen mit einem Klick.
• Eine Designerin oder ein Designer iteriert. Der Design Mode bearbeitet Styles visuell in jedem Plan, Free eingeschlossen, und in bezahlten Plänen macht v0 aus einem Figma-Link eine funktionierende App (opens in a new tab).
• Dein Stack schon Next.js, Tailwind CSS und shadcn/ui auf Vercel ist, die Defaults von v0 also deine Defaults sind.

Claude Code ist die bessere Wahl, wenn:

• Die Screens deine echten APIs aufrufen, mit deinen Umgebungsvariablen, deiner Datenbank und deinen Tests.
• Du den zehnten Screen eines Produkts baust und er zu den ersten neun passen muss.
• Dein Stack nicht der Default von v0 ist: ein anderes Framework, eine andere Komponentenbibliothek, ein Monorepo.
• Du jede Änderung als Diff sehen willst, den du liest, bevor er landet.

Lovable vs Claude Code ist eine andere Frage: Wer baut? Lovable passt, wenn du als Gründer keinen Code lesen willst und eine gehostete App mit Datenbank brauchst. Es bietet keine Wahl des Frameworks und kann kein bestehendes Repository verbinden. Hast du als Entwickler eine Next.js-Codebasis, bist du mit Claude Code besser bedient.

Stand Oktober 2026 liefert eine Suche nach „v0 vs Claude Code Reddit“ oder „Claude Code vs v0“ vor allem Vergleichsseiten, und ihr immer gleicher Rat ist der Hybrid-Weg: in v0 entwerfen, mit Claude Code integrieren. Das passt, mit einer Anpassung für Produkte mit vielen Screens: Lass den Entwurf das Layout klären und bau die echten Screens dann aus Komponenten, die schon in deinem Repository liegen. So wird der Entwurf nie zu deinem Design System.

Wo steht Cursor neben v0 und Claude Code?

In einem Vergleich v0 vs Cursor vs Claude Code steht Cursor auf der Seite von Claude Code: ein Editor, dessen Agent mit den Dateien in deinem Repository arbeitet, und Claude Code läuft darin über dieselbe Extension wie in VS Code (Claude-Code-Übersicht (opens in a new tab)). Zwischen diesen beiden wählst du die Oberfläche, die dir lieber ist; die Frage nach v0 bleibt dieselbe.

Wo fängst du an?

Wenn du noch kein Repository hast und diese Woche etwas zeigen musst, starte in v0 und verbinde GitHub ab dem ersten Chat. Wenn du ein Repository hast, bau die Screens dort. Verbinde den Wingo-UI-MCP-Server mit npx wingo-ui@latest agents install claude, installier die drei Blöcke und investier deine Prompts in die Anbindung. Die Blöcke gehören zu Wingo UI Pro; der Button, den sie sich teilen, und 74 weitere Einträge sind kostenlos.

Häufige Fragen

Ist v0 für UI besser als Claude Code?

Für einen ersten Entwurf, den du durchklicken und teilen kannst, oft ja: v0 zeigt eine Live-Vorschau, bearbeitet Styles visuell und deployt mit einem Klick. Für Screens, die deine echte API aufrufen, deinen Konventionen folgen und zu Screens von vor Monaten passen müssen, eignet sich Claude Code besser, weil es in deinem Repository mit deinen Dateien und Regeln arbeitet.

Kann ich v0 und Claude Code zusammen nutzen?

Ja. Verbinde das v0-Projekt mit GitHub und hol dir seinen Branch in deinen lokalen Checkout für Claude Code. Stand Oktober 2026 installiert v0 außerdem Claude Code vorab im Terminal seiner Sandbox; die Anfragen dort laufen über die AI-Gateway-Credits deines Teams.

Wem gehört der Code, den v0 oder Lovable erzeugen?

Dir, laut ihren eigenen Bedingungen, Stand Oktober 2026. Laut dem v0-FAQ gehört Vercel der Code nicht, der aus deinen Prompts entsteht, und laut dem Lovable-FAQ gehören dir deine Apps, dein Code und deine Inhalte, vorbehaltlich der Rechte Dritter wie Open-Source-Lizenzen.

Unterstützt Lovable Next.js?

Nein. Stand Oktober 2026 bietet Lovable laut seinem FAQ keine Wahl des Frameworks: Neue Apps nutzen TanStack Start, ältere React mit Vite. Läuft deine App auf Next.js, passen v0 oder Claude Code besser.

Was kostet Claude Code?

Stand Oktober 2026 ist es nicht in Claude Free enthalten; es steckt in Claude Pro für 20 $ im Monat, oder 17 $ im Monat bei jährlicher Abrechnung, und in Max ab 100 $ im Monat. Es läuft auch mit einem Anthropic-API-Key, der nach Verbrauch abgerechnet wird, und Team-Plätze beginnen bei 20 $ im Monat bei jährlicher Abrechnung.

Kann Claude Code die Login-, Pricing- und Einstellungsseiten von Wingo UI installieren?

Ja. Führ npx wingo-ui@latest add login-page pricing-page settings-page aus, und das CLI schreibt die drei Blöcke samt allem, was sie importieren, in dein Projekt. Es sind Pro-Einträge, also melde dich vorher mit npx wingo-ui@latest login an.