Dyad vs. Lovable: lokales BYOK, gehostete Credits und App-Eigentum

Dyad und Lovable unterscheiden sich inzwischen darin, wo der Build ausgeführt wird und wer den Modellschlüssel besitzt, nicht darin, ob sie Desktop- oder Browser-Apps sind. Dyad ist eine kostenlose Desktop-App, die Node und Ihre App auf Ihrem eigenen Rechner ausführt und jeden von Ihnen bereitgestellten OpenAI-kompatiblen API-Schlüssel akzeptiert. Lovable ist eine verwaltete Cloud-Plattform, die Arbeit in Credits abrechnet und ihrem Builder-Agent weder eine Modellauswahl noch die Verwendung eines eigenen Schlüssels ermöglicht – unabhängig vom Plan. Wählen Sie Dyad, wenn Sie die Tokenrechnung und den Quellbaum unter Ihrer Kontrolle haben möchten; wählen Sie Lovable, wenn ein Unternehmen Build, Datenbank, Hosting und Domain ausführen soll.

Die Einordnung „Desktop versus Browser-Tab“, die die meisten Vergleiche noch verwenden, ist seit einiger Zeit überholt: Lovables Dokumentation zur Desktop-App erklärt, dass ein nativer macOS- und Windows-Client „in allen Plänen, einschließlich Free, ohne zusätzliche Kosten“ verfügbar ist, mit Unterstützung für lokale MCP-Server und Tabs für mehrere Projekte. Beide Produkte haben ein Desktop-Symbol. Nur eines führt Ihren Build auf Ihrem eigenen Rechner aus.

Eine Klarstellung vor den Zahlen, da beide Namen leicht verwechselt werden. JuliaHub vertreibt ein unabhängiges Produkt namens Dyad – physikbasierte Modellierungssoftware –, dessen Light-AI-Tarif ebenfalls 20 $ pro Monat kostet; ein Preis von der falschen Seite wirkt daher völlig plausibel. Alle folgenden Dyad-Zahlen stammen von dyad.sh oder github.com/dyad-sh/dyad. Und der KI-Builder ist lovable.dev; lovable.com leitet per 301 dorthin weiter, lovable.it ist jedoch eine unabhängige italienische Dessousmarke (geprüft am 21. September 2026).

Welche solltest du auswählen

Beginnen Sie mit der Einschränkung, die sich nicht umgehen lässt, weil sie die meisten dieser Fälle allein entscheidet: Lovables Builder-Agent hat keine Modelleinstellung und akzeptiert keinen externen Schlüssel. Lovables FAQ beantwortet die Frage direkt: „Nein. Lovable verwaltet das zugrunde liegende Modell, das der Agent im Build-Modus und im Plan-Modus verwendet“, und ergänzt, dass es keine Einstellung gibt, um den Agenten zwischen bestimmten Modellen umzuschalten. Das ist eine fehlende Funktion und keine Bezahlschranke; daher führt kein Upgrade dorthin.

Die Zeile zu Trainingsdaten ist diejenige, die die meisten Leser noch nicht gesehen haben. Lovables FAQ erklärt: „Ab dem 9. September 2026 darf Lovable Kundendaten aus Free- und Pro-Plänen … verwenden, um seine KI-Modelle zu trainieren, zu entwickeln und zu verbessern“, mit einer kontoabhängigen Opt-out-Einstellung unter AI model training; Business- und Enterprise-Workspaces sind standardmäßig ausgeschlossen. Geprüft am 19. September 2026.

Zwei Dinge, die Dyads eigene Vergleichsseite über Lovable falsch darstellt

Dyad veröffentlicht eine Vergleichsseite zu Lovable, die für diese Suchanfrage rankt; zwei ihrer Behauptungen halten einer Prüfung anhand der aktuellen Lovable-Dokumentation jedoch nicht stand. Die Seite trägt kein Datum, daher lässt sich sagen, dass die Behauptungen heute falsch sind, ohne sagen zu können, wann sie aufhörten, wahr zu sein.

Dieselbe Seite nennt außerdem „bis zu 500 Nachrichten/Tag für Gemini 2.5 Flash“ als kostenlose Modelloption, während Dyads FAQ 250 tägliche Anfragen und der Schnellstart 250 Nachrichten pro Tag für dasselbe Modell angibt. Beide beziehen sich auf eine Modellgeneration, die inzwischen abgelöst wurde, und Google veröffentlicht keine Tabelle der kostenlosen Anfragen pro Tag je Modell mehr – die eigene Seite zu Ratenlimits erklärt nun, dass Limits in Google AI Studio eingesehen werden können. Betrachten Sie jede Zahl zu „kostenlosen Nachrichten pro Tag“ für eine Dyad-plus-Free-Tier-Konfiguration als nicht verifizierbar, und beachten Sie, dass Googles Preisseite Inhalte der kostenlosen Stufe als zur Verbesserung seiner Produkte verwendet kennzeichnet.

Pläne und Preise im direkten Vergleich

Quellen: dyad.sh/pricing, lovable.dev/pricing und Lovable subscription plans, alle am 19. September 2026 geprüft. Beide Credit-Staffeln reichen deutlich über die Basisebene hinaus; bestätigen Sie Ihre eigene Tarifstufe im Checkout.

Drei Credit-Regeln bestimmen mehr von den tatsächlichen Kosten als der angezeigte Preis. Lovables Preisseite gibt an, dass ungenutzte Credits monatlicher Tarife zwei Monate nach ihrer Ausgabe verfallen, Credits von Jahrestarifen einen Monat nach Ende des Jahreszeitraums, zusätzlich gekaufte Credits zwölf Monate nach dem Kauf und täglich gewährte Build-Credits am Ende jedes Tages; außerdem wird angegeben, dass Credits weder erstattungsfähig noch gegen Bargeld einlösbar sind. Zusätzlich gekaufte Credits kosten pro Credit mehr als Abonnement-Credits — die Credit-Dokumentation setzt sie bei Pro mit 15 $ pro 50 Credits und bei Business mit 30 $ pro 50 Credits an, gegenüber 0,25 $ pro Credit im Pro-Basistarif, und gibt ihnen eine Gültigkeit von 12 Monaten ab dem Kauf. Ein Downgrade auf Free friert die durch das Abonnement gewährten Credits ein: Lovables Seite zu den Abonnementplänen gibt an, dass nach dem Wechsel des Arbeitsbereichs auf Free ungenutzte monatliche Tarif-Credits und übertragene Credits eingefroren werden, auf Free nicht verwendet werden können und nicht erstattet werden. Sie können jedoch bis zu ihrem ursprünglichen Ablaufdatum genutzt werden, wenn Sie vorher wieder upgraden. Bei Dyad werden KI-Credits für einen Monat übertragen, aber Dyad veröffentlicht nirgendwo einen Credit-Satz pro Modell, sondern nur, dass „ein Credit direkt den Kosten des Sendens einer Nachricht an ein KI-Modell entspricht“ — daher lässt sich für keines der beiden Produkte eine Umrechnung „X Credits kaufen Y Tokens“ ableiten.

Wo ein Kunavo-Schlüssel verwendet werden kann und wo nicht

Das ist der Teil, den die meisten Vergleiche vereinfachen, und es ist leicht, sich dabei in die eine oder andere Richtung zu irren. Dyad behandelt einen OpenAI-kompatiblen Endpunkt als erstklassige Einstellung. Lovable tut das für seinen Builder nicht — dokumentiert aber einen Weg in die von Ihnen ausgelieferte App.

Dyads custom models guide sagt: „Dyad lets you use any AI model or provider, as long as they offer an OpenAI-compatible API.“ Der Pfad lautet Settings, dann AI Providers, dann Add Custom Provider und anschließend Add Custom Model innerhalb dieses Anbieters.

Drei Grenzen sollten Sie kennen, bevor Sie diesen Weg einplanen. Die untenstehenden Quellenangaben wurden am 19. September 2026 unter dem Tag v1.16.0 gelesen.

Nur Chat Completions. In get_model_client.ts wird ein benutzerdefinierter Anbieter mit dem createOpenAICompatible-Client des AI SDK anhand Ihrer Basis-URL erstellt. Für einen benutzerdefinierten Anbieter gibt es keinen Anthropic-Messages-Pfad und keinen OpenAI-Responses-Pfad. Die gehosteten integrierten Einträge im selben Switch — OpenAI, Anthropic, Google, xAI, Bedrock, MiniMax — werden allein aus einem API-Schlüssel erstellt, ohne Base-URL-Feld zur Umleitung; ein Gateway gehört daher in einen benutzerdefinierten Anbieter und nicht in einen dieser Einträge. Die beiden Ausnahmen sind die Einträge für lokale Server, Ollama und LM Studio, die zwar eine Base-URL akzeptieren, aber für lokale Modellserver dokumentiert sind. Dem Client für benutzerdefinierte Anbieter wird außerdem ein includeUsage-Flag übergeben, aber der Quellcode setzt es nur auf dem Pfad, auf dem Dyad Pro zusammen mit einem benutzerdefinierten oder lokalen Anbieter aktiviert ist; der einfache Bring-your-own-Key-Pfad belässt es bei seinem false-Standardwert. In beiden Fällen wurde auf dieser Seite nicht getestet, wie ein bestimmtes Gateway die Streaming-Nutzung meldet.

Pro-Modi können Ihren Schlüssel nicht verwenden. Die FAQ auf dyad.sh/pricing beantwortet dies direkt: Pro-Modi wie Smart Context funktionieren nur mit den KI-Credits von Dyad Pro, da sie serverseitige Verarbeitung über mehrere Modelle hinweg benötigen. Der ausgelieferte Quellcode stimmt strukturell damit überein — der Dyad-Pro-Zweig erstellt einen separaten Engine-Client anhand der eigenen Engine-Basis-URL von Dyad mit einem Dyad-API-Schlüssel, und Smart Context wird als dyad-engine-Provider-Option übergeben. Die Funktionen, die sehr große Codebasen erschwinglich machen, sind somit genau diejenigen, die ein Bring-your-own-Key-Setup nicht erreichen kann. Es gibt keine Konfiguration, die beides ermöglicht.

Der Free-Agent-Modus ist unabhängig vom verwendeten Schlüssel begrenzt. free_agent_quota_limit.ts setzt FREE_AGENT_QUOTA_LIMIT = 20, und der Handler definiert ein 23-Stunden-Fenster, das anhand des Date-Headers vom eigenen Health-Endpunkt von Dyad geprüft wird, um Uhrmanipulationen zu verhindern; der Hook, der diesen Wert liest, läuft nur für Nicht-Pro-Nutzer, und die Begrenzung selbst greift nur, wenn Dyad Pro deaktiviert ist und der ausgewählte Chat-Modus der lokale Agent ist — der dahinterliegende Anbieter und Schlüssel spielen keine Rolle. Die Zahl erscheint nirgendwo auf dyad.sh, obwohl der eigene Modusauswahldialog der App die Option „Free tier (20 messages/day)“ nennt, und Dyad ungefähr wöchentlich veröffentlicht — behandeln Sie dies daher als beobachtetes Verhalten bei einem Tag und nicht als veröffentlichte Zusage. Der Build-Modus mit einem benutzerdefinierten Anbieter unterliegt dieser Begrenzung nicht.

Auf der Lovable-Seite ist der Builder geschlossen, die ausgelieferte App jedoch nicht. Lovables AI features documentation gibt an, dass der integrierte KI-Connector immer über Lovable läuft und Arbeitsbereichs-Credits abrechnet, dass es sich um einen von Lovable ausgegebenen Schlüssel handelt und dass Anthropic-Modelle darüber nicht verfügbar sind — wenn Ihre App jedoch einen Anbieter benötigt, den der Connector nicht anbietet, kann Lovable die API dieses Anbieters direkt aus einer Backend-Edge-Funktion mit Ihrem eigenen, als Secret gespeicherten Schlüssel aufrufen; in diesem Fall verbraucht die App für die Ausführung der Funktion nur reguläre Cloud-Nutzung. Das sind zwei verschiedene Systeme, und Lovables eigene Dokumentation sagt dies ausdrücklich: Die Modelle des Connectors „are not the models Lovable uses to write, edit, or reason about your code.“ Ein Kunavo-Schlüssel kann die Laufzeit-KI innerhalb einer mit Lovable erstellten App über diese Edge-Funktion bedienen. Lovables Builder kann er niemals bedienen.

Eine beispielhafte Kostenschätzung für den Dyad-Weg

Diese Zahlen sind veranschaulichende Token-Arithmetik, keine gemessenen Aufgabenkosten und keine Abrechnungsobergrenze. Nehmen Sie eine Sitzung im Build-Modus an, die 150.000 nicht zwischengespeicherte Eingabetokens sendet und 15.000 Ausgabetokens empfängt, sowie eine umfangreichere Sitzung im Agentenstil mit 600.000 Eingabetokens und 40.000 Ausgabetokens. Beide Token-Strukturen dienen nur der Veranschaulichung. Die Preise stammen aus dem aktuellen Kunavo-Katalog pro einer Million Tokens.

Lesen Sie dies im Verhältnis zu den Abonnements und nicht als direkten Gleich-zu-Gleich-Tausch. Ein Lovable-Credit bezahlt neben der Modellarbeit den verwalteten Build, das Hosting, die Datenbank und die Domain; ein Tokenpreis bezahlt nur den Modellaufruf, und Supabase oder Neon sowie ein Deployment-Ziel müssen Sie weiterhin selbst bereitstellen. Der tatsächlich entscheidbare Vergleich betrifft die Vorhersagbarkeit: Auf dem Token-Weg wird der Stückpreis im Voraus veröffentlicht, auf beiden Credit-Wegen hingegen nicht — Dyad veröffentlicht keinen Credit-Satz pro Modell, und Lovable gibt an, dass die Kosten im Build-Modus von der Komplexität der Anfrage und der abgeschlossenen Arbeit abhängen. Bei Claude Sonnet 4.6 wird die oben genannte einzelne Sitzung auf $0,473 geschätzt; dieselbe Struktur auf Claude Haiku 4.5 wird auf $0,158 geschätzt. Der günstigste angegebene Preis und die niedrigsten Kosten für die Fertigstellung der Aufgabe sind weiterhin zwei verschiedene Fragen — ein günstigeres Modell, das drei Versuche benötigt, kann mehr kosten als eines, das einen Versuch benötigt — messen Sie daher in Ihrem eigenen Repository, bevor Sie sich festlegen.

Der Katalogbetrag von Kunavo ist ein Abrechnungsuntergrenze und keine Obergrenze: Wenn der Upstream seine Kosten meldet, entspricht die Rechnung dem höheren Wert aus den Katalogkosten und den Upstream-Kosten multipliziert mit dem geltenden Aufschlag. Cache-Gebühren und externe Tools sind in diesem Beispiel nicht enthalten. Die minimale Aufladung beträgt $10 als Prepaid-Guthaben; dies ist eine Mindestfinanzierung und weder eine Aufgabengebühr noch ein Abonnement — siehe Abrechnungsdetails.

Migrationskosten verlaufen nur in eine Richtung

Lovable zu Dyad ist die unterstützte Richtung. Lovables Tariftabelle weist für jeden Tarif einschließlich Free Git-Synchronisierung aus, und Dyads importing guide nennt mit Lovable, V0 oder Bolt erstellte Apps als importierbar — vorbehaltlich dreier Einschränkungen, die der Leitfaden selbst nennt: Der Import ist als experimentell gekennzeichnet, unterstützt werden nur JavaScript-Apps auf Node.js-Basis, und die App muss mit npm run dev laufen. Dyad bewahrt importierte Apps unter ~/dyad-apps/ auf der lokalen Festplatte als gewöhnliche Git-Repositories auf, weshalb die FAQ behaupten kann, dass Sie frei zwischen Dyad und anderen Tools wechseln können.

Dyad zu Lovable wird überhaupt nicht als Import unterstützt. Lovables FAQ gibt an, dass es derzeit keine Möglichkeit gibt, ein Lovable-Projekt aus bereits vorhandenem Code zu starten, beispielsweise aus GitHub. Dieser Weg bedeutet, die App innerhalb von Lovable neu zu erstellen und für den Wiederaufbau Credits zu bezahlen.

Eigentum ist in einer zweiten Hinsicht asymmetrisch, die erst beim Verlassen sichtbar wird. Lovable sagt, dass Sie Eigentümer Ihres Codes sind und Apps über Git-Synchronisierung überall gehostet werden können, aber die eigene deployment and ownership page gibt ebenfalls an, dass Editor und KI-Agent ein verwalteter Dienst sind, der nicht selbst gehostet oder innerhalb einer Kunden-VPC bereitgestellt werden kann, und dass die Migration des Backends zu plain PostgreSQL oder einem anderen Datenbankanbieter standardmäßig nicht unterstützt wird. Die Anwendung ist also portierbar; die Build-Umgebung ist es nicht.

Die Open-Source-Behauptung braucht eine Einschränkung

Das Repository von Dyad ist aktiv — nicht archiviert, am 11. April 2025 erstellt, zuletzt am 18. September 2026 gepusht, mit 21.597 Sternen (GitHub API, 21. September 2026). Seine LICENSE stellt Inhalte außerhalb von src/pro/ unter Apache 2.0 und Inhalte innerhalb davon unter die Functional Source License 1.1 mit einer zukünftigen Apache-2.0-Lizenzgewährung und einer als Competing Use bezeichneten Nutzungsbeschränkung. Der Code des Agent-Modus wird aus src/pro/ ausgeliefert, daher ist „vollständig Open Source“ speziell für den Agenten eine übertriebene Beschreibung — also für den Teil, der mit Lovables geschlossener Plattform verglichen wird.

Zwei Versionsdetails sollten Sie in Ihrer eigenen Installation klären und nicht anhand eines Abzeichens. Der neueste Tag ist v1.16.0, und package.json bei diesem Tag enthält 1.16.0 — der GitHub-Endpunkt für die neueste Veröffentlichung liefert jedoch weiterhin v1.15.0 vom 11. September 2026, ohne veröffentlichtes Release-Objekt für v1.16.0 (geprüft am 21. September 2026). Außerdem deklariert dasselbe package.json "license": "MIT", während die LICENSE-Dateien etwas anderes sagen und GitHubs Detektor NOASSERTION meldet. Die LICENSE-Dateien sind maßgeblich; die Metadaten sind veraltet.

Einrichtung des Dyad-Wegs

Kunavo hat keine Dyad-spezifische Einrichtungsseite, und Dyad wurde hier nicht zur Laufzeit getestet — die obige Konfiguration wurde aus Dyads Dokumentation und dem ausgelieferten Quellcode abgelesen und ist daher eine Referenz, kein Kompatibilitätstest. Der allgemeine Weg entspricht dem, den Dyad dokumentiert: eine OpenAI-kompatible Basis-URL, ein Schlüssel und eine exakte Modell-ID. Beginnen Sie mit the OpenAI-compatible API guide, halten Sie während des Ausprobierens einen funktionierenden Weg verfügbar, führen Sie einen begrenzten Build aus und lesen Sie anschließend die Belastung ab, die Ihr Konto tatsächlich dafür verzeichnet hat. Create a Kunavo account, wenn Sie bereit sind, einen Schlüssel aufzuladen.

Wenn Sie noch zwischen Buildern und nicht zwischen Anbietern wählen, behandelt the coding model comparison, welche Modellfamilien für welche Arbeitsarten geeignet sind, und AI cost optimization erläutert, wie Sie einen Weg in Ihrem eigenen Repository statt anhand einer Preistabelle messen.

Häufig gestellte Fragen

Direkt am 19. September 2026 geöffnet: die Preis- und Lovable-Vergleichsseiten von dyad.sh sowie der Leitfaden für benutzerdefinierte Modelle; beide Dyad-LICENSE-Dateien; package.json, get_model_client.ts, free_agent_quota_limit.ts und der Agenten-Quota-Handler beim Tag v1.16.0; das GitHub-Repository sowie die Releases- und Tags-API; außerdem Lovables Preisseite sowie die Dokumentation zu Subscription-Plänen, Credits und Nutzung, FAQ, KI-Funktionen, Projektsichtbarkeit, Deployment und Eigentum sowie zur Desktop-App. Am 21. September 2026 erneut geöffnet: die Antworten hinter dem FAQ-Akkordeon der Dyad-Preisseite; Dyads FAQ, Quickstart-, Import-, Veröffentlichungs- und Maximize-AI-Credits-Seiten; der Dialog Add Custom Provider, der Free-Agent-Quota-Handler und die Chat-Modus-Begrenzung beim Tag v1.16.0; Lovables Dokumentation zu Git-Synchronisierung, Enterprise und Subscription-Plänen; sowie das GitHub-Repository und die Releases-API. Die Kunavo-Tokenpreise stammen aus dem aktuellen Katalog, und jede Dollarangabe im Beispiel ist veranschaulichende Token-Arithmetik und keine gemessene Aufgabenkostenangabe.