Aperant: Desktop-Orchestrierung für autonome Coding-Agenten im 3.0-Neubau
Autonome Multisitzungs-KI-Codierung. Wenn Sie ihn ändern und verteilen oder als Dienst ausführen, muss Ihr Code auch Open Source unter AGPL-3.0 sein.
Auf einen Blick
- Was ist das?
- Aperant, früher Auto Claude, bündelt mehrere Coding-Agenten hinter einer Electron-Oberfläche mit Kanban-Board, Worktree-Isolierung und QA-Schleife. Die stabile 2.7.6 wird nur gewartet, während 3.0 in einem separaten Repository entsteht.
- Für wen ist es gedacht?
- Aperant passt zu Entwicklern, die bereits ein Claude-Abonnement haben und mehrere Agentenaufgaben parallel an einem git-Repository steuern wollen, ohne den Hauptzweig zu gefährden. Wer Code beitragen oder auf eine stabile Weiterentwicklung hoffen will, muss warten: Pull Requests sind pausiert, und 2.7.6 erhält laut README nur noch kritische Korrekturen.
- Darf ich es kommerziell nutzen?
- Ja, unter strengen Bedingungen. AGPL-3.0 ist eine Lizenz mit Netzwerk-Copyleft: Wenn andere eine veränderte Version über ein Netzwerk nutzen, etwa als gehosteten Dienst, müssen Sie ihnen den Quellcode unter derselben Lizenz anbieten.
- Wird es noch gepflegt?
- Ja. Die letzten Commits kamen vor 94 Tagen.
- In welcher Sprache ist es geschrieben?
- Hauptsächlich TypeScript, laut der Sprachstatistik von GitHub.
Die Antworten beruhen auf den GitHub-Daten des Projekts (zuletzt abgeglichen am 14. September 2026) und auf unserer Analyse. Sie sind keine Rechtsberatung.
TIEFGEHENDE OPEN-SOURCE-ANALYSE
Aperant 3.0 im Neubau: Wartung für 2.7.6, pausierte Pull Requests
Aperant trug früher den Namen Auto Claude und ist laut Repository-Beschreibung ein autonomes Framework für die Arbeit mehrerer Agenten an Software. Das README stellt es als ein System vor, das plant, baut und validiert. Geschrieben ist es in TypeScript, der Standardzweig heisst develop.
Der auffälligste Teil des README ist der Status. Für Version 3.0 wird die gesamte Anwendung neu aufgebaut, mit Cloud-Funktionen über der bisherigen Desktop-Erfahrung. Diese Arbeit findet überwiegend in einem separaten Entwicklungsrepository statt und soll später zurückgeführt werden, weshalb das öffentliche Commit-Bild ruhiger wirkt als die tatsächliche Aktivität.
Für die Gegenwart hat das drei Folgen, die das README selbst nennt: Die 2.x-Desktop-App ist im Wartungsmodus und gilt als stabil, erhält aber keine neuen Funktionen. Code-Pull-Requests werden geschlossen, weil die Codebasis ersetzt wird. Und ein Veröffentlichungstermin für 3.0 existiert nicht. Rückmeldungen sollen über Issues, Discussions oder Discord laufen.
Voraussetzungen: Claude-Abonnement, Claude-Code-CLI, git-Repository
Drei Dinge verlangt das README, bevor die App sinnvoll startet. Erstens ein Claude Pro- oder Max-Abonnement. Zweitens die Claude-Code-CLI, installiert über npm install -g @anthropic-ai/claude-code. Drittens ein Projekt, das bereits als git-Repository initialisiert ist.
Der Schnellstart besteht aus fünf Schritten: App herunterladen und installieren, einen Repository-Ordner öffnen, Claude über einen von der App geführten OAuth-Ablauf verbinden, eine Aufgabe mit einer Beschreibung des Ziels anlegen und zusehen, wie die Agenten planen, programmieren und prüfen. Das README beschreibt nicht, was geschieht, wenn kein Abonnement besteht, und lässt offen, welche Berechtigungen der OAuth-Schritt anfordert.
An dieser Liste lässt sich die Architektur ablesen: Aperant bringt keine eigene Modellschicht mit, sondern steuert die CLI und damit das Abonnement des Nutzers. Die Kosten für Modellaufrufe liegen damit ausserhalb des Projekts.
Vom Kanban-Board in den Worktree: der Weg einer Aperant-Aufgabe
Die Oberfläche beginnt beim Kanban-Board, auf dem Aufgaben von der Planung bis zum Abschluss wandern und der Fortschritt der Agenten verfolgt wird. Daneben stehen Agententerminals, in die sich der Kontext einer Aufgabe per Klick einspeisen lässt, sowie eine Roadmap-Ansicht für die Funktionsplanung mit Wettbewerbsanalyse und Zielgruppenbetrachtung.
Die eigentliche Arbeit passiert laut README in git-Worktrees. Jede Änderung entsteht in einem eigenen Worktree, der Hauptzweig bleibt unberührt. Damit ist die Isolierung nicht Softwarerand, sondern Grundlage des Modells: Mehrere Agenten können gleichzeitig an verschiedenen Aufgaben desselben Repositorys arbeiten, ohne sich gegenseitig in den Baum zu schreiben.
Drei weitere Ansichten ergänzen das Bild. Insights ist ein Chat zur Erkundung der Codebasis, Ideation sucht nach Verbesserungen, Leistungsproblemen und Schwachstellen, und Changelog erzeugt Release-Notizen aus abgeschlossenen Aufgaben.
Bis zu zwölf Agententerminals: parallele Ausführung, QA-Schleife, Merge
Die Funktionstabelle des README beziffert die Parallelität: Bis zu zwölf Agententerminals können gleichzeitig laufen. Jeder Task folgt demselben Ablauf, der Nutzer nennt ein Ziel, und die Agenten übernehmen Planung, Implementierung und Validierung.
Zwischen Implementierung und Rückführung liegt eine selbstvalidierende Qualitätsschleife, die Fehler finden soll, bevor ein Mensch die Änderung sieht. Für das Zusammenführen nennt das README eine KI-gestützte Konfliktauflösung, die beim Integrieren in den Hauptzweig greift. Eine Speicherebene soll Erkenntnisse über Sitzungen hinweg festhalten.
Für die Anbindung an bestehende Arbeitsweisen nennt das README zwei Integrationen: GitHub und GitLab zum Importieren von Issues, Untersuchen mit Agenten und Erstellen von Merge-Requests, sowie Linear für die Synchronisation von Aufgaben. Leistungszahlen oder Messwerte zu diesen Funktionen enthält das README nicht.
Sicherheitsmodell mit Sandbox und Zulassungsliste, plus Release-Prüfung
Das README beschreibt die Absicherung in drei Schichten. Eine Sandbox des Betriebssystems führt Bash-Befehle isoliert aus. Beschränkungen auf Dateisystemebene begrenzen Operationen auf das Projektverzeichnis. Eine dynamische Zulassungsliste gibt nur solche Befehle frei, die zum erkannten Stack des Projekts passen.
Diese drei Schichten greifen ineinander, und jede hat eine eigene Schwachstelle: Die Liste hängt an der korrekten Erkennung des Stacks, die Dateisystemgrenze gilt nur innerhalb des Projektpfads, und die Sandbox ist an das Betriebssystem gebunden. Das README sagt nicht, ob alle drei auf Windows, macOS und Linux in gleichem Umfang wirken.
Für die Auslieferung nennt das README zwei Prüfungen: Jedes Release enthält SHA256-Prüfsummen und wird vor der Veröffentlichung mit VirusTotal gescannt, wo möglich kommen Signaturen hinzu, ausdrücklich genannt wird macOS. Welche Scan-Engines laufen und wo die Prüfsummen veröffentlicht werden, bleibt offen.
Download-Katalog: stabile 2.7.6 gegen die Beta-Linie 2.8.0
Als stabile Version führt das README 2.7.6. Die Dateinamen tragen noch den alten Projektnamen: Auto-Claude-2.7.6-win32-x64.exe für Windows, Auto-Claude-2.7.6-darwin-arm64.dmg und Auto-Claude-2.7.6-darwin-x64.dmg für macOS, dazu für Linux ein AppImage, ein Debian-Paket und ein Flatpak, jeweils mit x86_64 beziehungsweise amd64 im Namen.
Die Beta-Linie heisst bereits Aperant. Gelistet ist 2.8.0-beta.5 in denselben sechs Varianten; in den Metadaten erscheint zusätzlich der Tag v2.8.0-beta.6 vom 23. März 2026, während beta.4 und beta.5 beide am 13. März 2026 veröffentlicht wurden. Ein so dichter Beta-Takt deutet auf schnelle Korrekturen hin, ist aber auch ein Hinweis darauf, dass diese Linie Bewegung enthält.
Das README warnt selbst vor Beta-Versionen und verweist auf die Übersicht aller Releases. Wer produktiv arbeitet, bleibt bei 2.7.6 und nimmt dafür in Kauf, dass dort nur kritische Fehler behoben werden.
AGPL-3.0 im Netzwerkbetrieb und Claude-Code als Alternative
Die Lizenz ist AGPL-3.0, und die Repository-Beschreibung formuliert die Konsequenz unmissverständlich: Wer Aperant verändert und weitergibt oder als Dienst betreibt, muss den eigenen Code ebenfalls unter AGPL-3.0 offenlegen. Das README ergänzt, dass eine kommerzielle Lizenzierung verfügbar ist. Für ein internes Team, das die Agenten nur auf eigenen Projekten einsetzt, ohne die Software anzubieten, ist die Fernwirkung geringer; für ein Angebot, das Aperant nach aussen trägt, ist sie der Prüfpunkt. Das ist keine Rechtsberatung.
Die naheliegende Alternative ist genau die Abhängigkeit, die Aperant voraussetzt: die Claude-Code-CLI. Sie arbeitet im Terminal, ohne Kanban-Board, ohne parallele Terminals mit Kontextinjektion und ohne Worktree-Verwaltung über eine Oberfläche. Wer eine Aufgabe nach der anderen abarbeitet und die Isolierung selbst über Branches oder Worktrees organisiert, braucht die Desktop-App nicht.
Der Unterschied liegt damit in der Orchestrierung, nicht im Modell: Aperant verkauft Übersicht über viele parallele Läufe, während die CLI den einzelnen Lauf in der Hand des Nutzers lässt. Angesichts des pausierten Beitragswegs und des laufenden Neubaus ist der einfachere Weg der risikoärmere.
Redaktionelles Fazit
Aperant passt zu Entwicklern, die bereits ein Claude-Abonnement haben und mehrere Agentenaufgaben parallel an einem git-Repository steuern wollen, ohne den Hauptzweig zu gefährden. Wer Code beitragen oder auf eine stabile Weiterentwicklung hoffen will, muss warten: Pull Requests sind pausiert, und 2.7.6 erhält laut README nur noch kritische Korrekturen. Geklärt werden sollten vor dem Einsatz zuerst die AGPL-3.0-Pflichten für den eigenen Netzwerkbetrieb und ob statt der Desktop-App schon die Claude-Code-CLI mit dem Befehl npm install -g @anthropic-ai/claude-code ausreicht.
Community-Notizen