Dyad: lokaler KI-App-Builder mit eigener API-Anbindung

Welches Problem Dyad adressiert

Gehostete KI-App-Builder wie Lovable, v0 oder Bolt nehmen dem Nutzer den Aufbau der Umgebung ab. Der Preis dafür ist struktureller Natur: Der Quellcode entsteht auf fremder Infrastruktur, die Modellwahl gibt der Anbieter vor, und die Abrechnung läuft über dessen Konto. Wer eine Anwendung für einen Kunden baut oder mit sensiblen Daten arbeitet, muss diese Abhängigkeit bewusst akzeptieren.

Dyad setzt an genau dieser Stelle an. Das README beschreibt das Projekt als lokal, quelloffen und unter eigener Kontrolle, ausdrücklich als Alternative zu Lovable, v0 und Bolt. Die Zielgruppe sind nach der Selbstbeschreibung "power users", also Anwender, die bereit sind, eigene API-Schlüssel zu verwalten und die Modellwahl selbst zu treffen. Das ist keine Einschränkung am Rand, sondern die eigentliche Produktentscheidung: Dyad übernimmt die Rolle der Oberfläche, nicht die des Anbieters.

Daraus folgt ein Kostenmodell, das sich von gehosteten Buildern unterscheidet. Es gibt laut README keine Registrierung und keinen Abonnement-Zwang. Stattdessen fallen die Modellkosten direkt beim jeweiligen Anbieter an, dessen Schlüssel der Nutzer hinterlegt. Für Vielnutzer kann das günstiger sein, für Gelegenheitsnutzer teurer, weil keine Pauschale die Spitzen abfedert.

Lokal heißt hier: Rechner des Nutzers, nicht Server

Die Architektur lässt sich aus dem Repository nur in Umrissen ablesen. Klar ist: Dyad ist eine Anwendung, die auf Mac oder Windows läuft, nicht ein Dienst, den man im Browser aufruft. Das README nennt Cross-Platform-Unterstützung für diese beiden Systeme. Eine Linux-Version wird an keiner Stelle erwähnt, weder im Feature-Abschnitt noch im Download-Bereich. Wer auf Linux entwickelt, muss das vor der Evaluierung klären.

Der Datenfluss folgt dem Muster "bring your own keys". Der Nutzer hinterlegt einen API-Schlüssel bei einem Modellanbieter, Dyad schickt die Anfragen von der lokalen Anwendung aus dorthin und verarbeitet die Antwort im lokalen Projekt. Die Liste der Themen im Repository nennt Anthropic, OpenAI, Gemini, DeepSeek, Qwen und Ollama. Ollama ist der relevante Eintrag für alle, die keine Daten an einen Cloud-Anbieter geben wollen, weil damit ein lokal laufendes Modell angesprochen werden kann. Ob alle genannten Anbieter gleichwertig unterstützt werden, geht aus dem Material nicht hervor.

Bemerkenswert ist, was das README nicht behauptet. Es gibt keine Aussage über eine Sandbox für generierten Code, keine über Rechtebeschränkungen beim Dateizugriff und keine über eine Freigabeliste für Netzwerkverbindungen. Wer Dyad auf einem Rechner mit Zugang zu internen Systemen laufen lässt, sollte diese Frage selbst beantworten, bevor er ein Modell auf das Projektverzeichnis ansetzt.

Installation ohne Konto, aber mit eigenen Schlüsseln

Der Einstieg ist bewusst niedrig gehalten. Laut README gibt es keinen Sign-up, der Download erfolgt über die Projektseite unter https://www.dyad.sh/#download, getrennt nach Plattform. Ein Installationsbefehl, ein Paketmanager-Aufruf oder ein Homebrew-Tap werden im vorliegenden Material nicht genannt. Wer eine reproduzierbare Installation über eine Kommandozeile erwartet, findet hier keine Anhaltspunkte.

Der zweite Schritt ist die Konfiguration der Modellanbieter. Dyad bringt keine eigenen Schlüssel mit, der Nutzer legt sie in der Anwendung ab. Welche Konfigurationsschlüssel dabei verwendet werden, welche Umgebungsvariablen gelesen werden und wo die Dateien liegen, geht aus dem README nicht hervor. Das ist eine Lücke, die vor einem produktiven Einsatz geklärt werden muss, weil davon abhängt, ob Schlüssel im Klartext auf der Platte landen oder in einem Schlüsselbund des Betriebssystems.

Für Mitwirkende ist der Weg klarer dokumentiert: Das Repository enthält eine CONTRIBUTING.md, auf die das README verweist. Der primäre Sprachanteil liegt bei TypeScript, was für ein Projekt dieser Art naheliegend ist. Ein Bauen aus dem Quelltext setzt damit eine Node-Umgebung voraus, auch wenn das README diesen Schritt nicht ausführt.

Die Lizenz ist zweigeteilt, und das ist der wichtigste Punkt

Dyad steht nicht unter einer einheitlichen Lizenz. Das README trennt ausdrücklich zwei Bereiche: Der Code außerhalb von src/pro steht unter Apache 2.0, der Code innerhalb von src/pro unter der Functional Source License 1.1 mit Apache-2.0 als späterer Lizenz. Der GitHub-Metadatensatz meldet für das Gesamtrepository entsprechend NOASSERTION, weil sich die Teile nicht auf einen einzigen SPDX-Bezeichner reduzieren lassen.

Für die Praxis bedeutet das: Wer den Kern forkt und weiterverwendet, bewegt sich auf bekanntem Terrain. Wer dagegen Funktionen aus src/pro nutzen, ändern oder in ein eigenes Produkt überführen will, muss die FSL 1.1 im Detail lesen. Fair-source bedeutet nicht dasselbe wie Open Source. Die Lizenz erlaubt typischerweise die Nutzung, schränkt aber konkurrierende kommerzielle Angebote ein. Ich gebe hier keine Rechtsberatung; die Bedingungen im LICENSE-Verzeichnis von src/pro sind die maßgebliche Quelle.

Unangenehm ist, dass die Grenze mitten durch das Repository verläuft. Ein Entwickler, der eine Funktion aus der Oberfläche im Quelltext sucht, landet möglicherweise in src/pro, ohne das zunächst zu bemerken. Wer das Projekt in einem kommerziellen Kontext einsetzt, sollte vorher klären, welche Funktionen im fair-source Teil liegen und ob die eigene Nutzung davon erfasst wird.

Wartung, Release-Kadenz und Upgrade-Aufwand

Die Release-Historie zeigt ein Muster, das auf aktive Entwicklung hindeutet: Auf v1.14.0-beta.1 und v1.14.0-beta.2 folgte am selben Tag die stabile Version v1.14.0. Beta-Versionen werden also öffentlich verteilt, bevor sie als stabil markiert werden. Für Anwender heißt das, dass die Beta-Kanäle existieren und dass ein Wechsel zwischen ihnen möglich ist. Ob die Anwendung selbst zwischen stabilen und Beta-Updates unterscheidet, lässt sich aus dem Material nicht belegen.

Der letzte Push liegt laut Metadaten bei 2026-09-09, das Projekt ist nicht archiviert. Die Versionsnummer 1.14.0 bei einem Projekt, das in der Selbstbeschreibung noch als Alternative zu etablierten Buildern auftritt, sagt etwas über die Reife: Die Anwendung ist über die frühe Phase hinaus, aber die Null vor dem Punkt fehlt noch nicht lange genug, um Stabilität als gegeben anzunehmen.

Upgrade-Kosten entstehen bei Dyad an zwei Stellen. Erstens bei der Anwendung selbst, die als Desktop-Programm aktualisiert werden muss. Zweitens bei den Modellen, deren Preise und Fähigkeiten sich unabhängig von Dyad ändern. Ein Anwender, der heute ein günstiges Modell für die Codegenerierung nutzt, kann morgen feststellen, dass der Anbieter die Preisstruktur geändert hat. Dyad kann das nicht abfedern, weil es keine eigene Abrechnung betreibt.

Wo Dyad das falsche Werkzeug ist

Der lokale Ansatz hat einen klaren Preis: Es gibt keinen Server, der die Arbeit übernimmt, wenn der eigene Rechner aus ist. Wer von einem Tablet aus arbeiten oder einem Kollegen einen Link auf eine laufende Vorschau schicken will, braucht dafür eine eigene Lösung. Gehostete Builder liefern diesen Teil mit, Dyad nicht.

Ein zweiter Fall: Wer kein Interesse an Modellauswahl hat. Dyad verlangt vom Nutzer eine Entscheidung, die gehostete Dienste abnehmen. Welches Modell für welche Aufgabe, welcher Anbieter, welcher Schlüssel mit welchem Limit. Das README beschreibt die Schlüsselverwaltung als Feature, nicht als Hürde, aber die Arbeit bleibt beim Anwender.

Drittens die Plattformfrage. Das README nennt Mac und Windows. Eine Linux-Version wird nicht erwähnt. Wer in einer Umgebung arbeitet, in der Linux der Standard ist, muss prüfen, ob das Projekt dort läuft, bevor er es einplant. Aus dem Material geht das nicht hervor.

Schließlich der Fall, in dem ein Team eine gemeinsame Umgebung mit geteilter Konfiguration, Rollen und Abrechnung braucht. Dyad ist auf den einzelnen Rechner zugeschnitten. Eine Teamverwaltung wird im README nicht beschrieben, und die Lizenzstruktur mit dem fair-source Teil deutet nicht darauf hin, dass ein solches Angebot im offenen Kern liegt.

Was ein gehosteter Builder anders macht

Der naheliegende Vergleich ist Lovable, v0 oder Bolt, die das README selbst als Bezugspunkt nennt. Der Unterschied liegt nicht in der Funktion, sondern in der Verantwortung. Bei einem gehosteten Builder läuft die Umgebung beim Anbieter. Der Nutzer bekommt eine URL, eine Vorschau und ein Abrechnungskonto. Er muss weder einen Schlüssel verwalten noch ein Modell auswählen noch ein Update einspielen.

Bei Dyad ist es umgekehrt. Der Nutzer betreibt die Anwendung, hält die Schlüssel und trägt die Modellkosten. Dafür bestimmt er, welche Daten das Haus verlassen. Mit Ollama als einem der genannten Anbieter ist sogar der Fall denkbar, dass die Prompts den Rechner überhaupt nicht verlassen. Das ist der eigentliche Unterschied: nicht die Geschwindigkeit der Generierung, sondern der Ort, an dem die Anfrage endet.

Wer diesen Unterschied nicht braucht, zahlt bei Dyad mit Betriebsaufwand für einen Vorteil, den er nicht nutzt. Wer ihn braucht, weil Kundendaten oder interne Richtlinien das verlangen, findet bei den gehosteten Alternativen keine Entsprechung. Die Entscheidung fällt also nicht über Funktionen, sondern über die Frage, ob die Daten den eigenen Rechner verlassen dürfen.

Redaktionelles Fazit

Wer Dyad einsetzen will, sollte zuerst die Lizenzgrenze zwischen dem Apache-2.0-Kern und src/pro prüfen und die Modellwahl gegen die eigenen API-Kosten abwägen. Für Anwender, die einen lokalen Builder mit eigenen Schlüsseln suchen, ist das Projekt eine naheliegende Option. Wer einen gehosteten Dienst ohne eigene Betriebsverantwortung braucht, ist hier falsch.

Offizielle Quellen

1. dyad-sh/dyad on GitHub
2. Issues
3. Project website
4. README
5. Releases