Cindy: Ein Open-Source-Client, der Claude Code und Codex in einem lokalen Agenten orchestriert
Cindy ist ein quelloffener KI-Agent-Client unter Apache-2.0. Er bündelt mehrere Harnesses (zuerst Claude Code und Codex), Modelle und Werkzeuge in einem Agenten, der lokal läuft und echte Dateien sowie angemeldete Apps nutzt. Modell und Harness lassen sich mitten in der Aufgabe wechseln, während Arbeitsbereich, Gedächtnis, Skills und Werkzeuge durchgängig bleiben. Eine Aufgabe kann von verschiedenen Kombinationen geplant, parallel ausgeführt und geprüft werden. Das Repository enthält Desktop- und Mobile-Client. Das Backend liegt separat, Benchmarks fehlen im README.
Was es ist: ein lokaler Client, der mehrere Coding-Agenten orchestriert
Cindy (makecindy/cindy) ist ein quelloffener KI-Agent-Client mit dem Leitspruch „Consider it done“. Die Idee ist einfach. Statt zwischen Claude Code, Codex und anderen Coding-Agenten hin und her zu wechseln, bündelt Cindy mehrere Harnesses (die Laufzeitumgebungen der Agenten), Modelle und Werkzeuge in einem einzigen Agenten. Dieser läuft auf dem eigenen Rechner und arbeitet mit den echten Dateien und den bereits angemeldeten Anwendungen. Das Repository steht unter der Apache-2.0-Lizenz und ist ein pnpm-Monorepo. Es enthält eine Electron-Desktop-App, eine mobile App auf Basis von Expo / React Native und gemeinsame Pakete für Authentifizierung, Geräteverknüpfung, Agenten-Orchestrierung und Modellanbieter.
Ein Punkt kommt zuerst. Dieses Repository enthält nur den Client. Laut README liegt der Backend-Dienst in einem separaten Repository und gehört nicht zu diesem Monorepo. „Open Source“ meint hier den Quellcode des Clients, nicht den gesamten Cloud-Dienst.
Kernarchitektur: Harness, Modell und Werkzeuge getrennt
Nach der Beschreibung im README trennt das Design drei Dinge. Das erste ist das Harness. Claude Code und Codex sind die ersten unterstützten Harnesses. Das Projekt gibt an, dass weitere folgen und ein natives Harness in Arbeit ist. Die Verzeichnisse apps/*-bin enthalten Werkzeug-Binärdateien, die mit der Desktop-App ausgeliefert werden. claude-code, codex und ripgrep werden bei pnpm install je Plattform heruntergeladen. Die Android-platform-tools werden vor dem Windows-Packaging in einer festgelegten Version mit sha256-Prüfung geholt. Cindy baut also keinen Coding-Agenten neu. Es bündelt vorhandene Agent-CLIs und behandelt sie als austauschbare Ausführungsmaschinen.
Das zweite ist das Modell. Modelle und Harnesses lassen sich frei kombinieren, und man kann mitten in einer Aufgabe wechseln. Das README nennt vier Wege, Modelle einzubringen: die Anmeldung beim offiziellen Cindy-Dienst, bei dem die Nutzung transparent abgerechnet wird; die Freigabe eines bereits bezahlten Coding Plans von Claude Code oder Codex, den man in Cindy ohne doppelte Rechnung weiter nutzt; eigene API-Schlüssel; oder lokale Modelle. Das dritte ist die Arbeitsumgebung, die über Engines hinweg durchgängig bleibt. Arbeitsbereich, Gedächtnis, Skills und Werkzeuge bleiben bestehen, wenn man Harness oder Modell wechselt. Das ist der wertvollste und zugleich schwierigste Teil des Entwurfs. Jeder Agent hat eigene Konventionen für Kontext, Format der Werkzeugaufrufe und Skill-Beschreibungen. Den Zustand beim Engine-Wechsel zu erhalten, erfordert eine eigene Abstraktionsschicht.
Multi-Agenten-Arbeit: planen, parallel ausführen, prüfen
Laut README kann eine Aufgabe von Agenten auf unterschiedlichen Kombinationen aus Harness und Modell geplant, parallel ausgeführt und geprüft werden. Das entspricht einem gängigen Muster der Multi-Agenten-Entwicklung: Ein Modell zerlegt die Aufgabe, mehrere Ausführende arbeiten gleichzeitig in sich nicht überschneidenden Bereichen, und ein Modell anderer Herkunft prüft das Ergebnis unabhängig. So verringern sich die blinden Flecken, die entstehen, wenn ein Modell seine eigene Arbeit bewertet. Cindy macht daraus eine Produktfunktion, sodass niemand Skripte von Hand verknüpfen muss.
Über Code hinaus kann Cindy Browser, Computer und Telefon steuern. Es nimmt außerdem Aufträge aus Instant-Messaging (IM) und aus Zeitplänen an. Das Ziel scheint ein dauerhaft verfügbarer Allzweck-Arbeitsagent zu sein, nicht nur ein Programmierhelfer.
Die Schicht „zum Formen“: Gedächtnis, Skills, Automatisierung, MCP, Plugins
Das Projekt fasst seine Erweiterungspunkte unter „Yours to shape“ zusammen. Gedächtnis: Man korrigiert einmal, und der Agent macht es danach richtig, auch über Harnesses hinweg. Skills: Man bringt eine Arbeitsweise einmal bei und nutzt sie überall; die Weitergabe an Teams ist noch in Arbeit.
Automatisierung: Wiederkehrende Aufgaben planen sich selbst, laufen selbst und melden zurück. MCP: Interne Werkzeuge und Geschäftssysteme werden angebunden. Plugins: Sie sollen über einen offenen Marktplatz geteilt werden, der ebenfalls noch in Arbeit ist; derzeit installiert man sie über SkillHub oder manuell. Der Quellcode selbst lässt sich prüfen, forken, erweitern und unter Apache-2.0 zurückgeben.
Bereitstellung und Nutzungsmodi
Der Anmeldebildschirm bietet zwei Modi. Der gehostete Dienst nutzt ein Cindy-Cloud-Konto. „Skip Sign-In“ braucht kein Konto und führt lokale Agenten aus; die App zeigt dann „Nicht angemeldet“ an, und Funktionen, die den Server benötigen, stehen nicht zur Verfügung. Standardmäßig verbindet sich der Client mit den offiziellen Cloud-Diensten.
Die Endpunkt-Manifeste sind config/endpoint.json und config/endpoint.global.json, und die automatischen Desktop-Updates kommen vom offiziellen CDN. Für die Entwicklung startet man pnpm restart:desktop:remote --region=cn oder --region=global mit dem eigenen Cindy-Konto. Voraussetzungen sind Node.js 22.x, pnpm 10.x (Version 11 wird noch nicht unterstützt) und Git LFS. Für Ubuntu, Arch Linux und Omarchy gibt es eine Installationsanleitung.
Leistung und Kosten: noch keine öffentlichen Benchmarks
Das muss klar gesagt werden: Das README veröffentlicht keine Benchmark-Daten. Es nennt weder Latenzen noch Erfolgsquoten noch einen Kostenvergleich. Aus dieser Quelle lässt sich daher nicht sagen, wie viel schneller oder genauer Cindy gegenüber Claude Code oder Codex allein ist. Gesichert ist nur die Kostenstruktur.
Mit einem vorhandenen Coding Plan entsteht keine doppelte Rechnung. Beim offiziellen Dienst wird die Nutzung abgebucht. Bei eigenen Schlüsseln oder lokalen Modellen trägt man die Kosten selbst. Parallele Prüfung durch mehrere Agenten vervielfacht den Token-Verbrauch. Das ist ein Zielkonflikt, der alle Entwürfe dieser Art betrifft; die tatsächlichen Zahlen müssen im Betrieb gemessen werden.
Auswirkungen, Grenzen und Ausblick
Für Entwickler liegt der Nutzen in weniger Kontextschleppen zwischen Agenten-Werkzeugen und in einem fest eingebauten Prüfschritt. Für Unternehmen sind ein Apache-2.0-Client, prüfbarer Quellcode und ein lokaler Betrieb mit echten Dateien attraktiv. Der Datenweg hängt aber weiterhin von der gewählten Modellquelle ab und davon, ob die offizielle Cloud genutzt wird.
Die Grenzen sind ebenso deutlich. Erstens ist das Backend nicht offen, das Verhalten des gehosteten Dienstes lässt sich also nicht prüfen. Zweitens hat ein Agent, der echte Dateien, angemeldete Anwendungen und ein Telefon bedienen kann, eine sehr breite Berechtigungsfläche; Prompt-Injection und Fehlaktionen müssen Nutzer selbst bewerten und eindämmen. Drittens hängt Cindy von den Upstream-CLIs Claude Code und Codex ab, sodass Änderungen an deren Schnittstellen oder Lizenzbedingungen Cindy direkt treffen. Viertens sind das native Harness, die Skill-Weitergabe im Team und der Plugin-Marktplatz allesamt als „in Arbeit“ gekennzeichnet, die Roadmap ist also noch nicht eingelöst. Beobachtenswert sind die Veröffentlichung des nativen Harness, weitere Harness-Anbindungen, unabhängige Bewertungen durch Dritte und ein dokumentiertes Sicherheitsmodell.