Orkas: Multi-Agenten-Desktop-Client mit lokalem Speicher und eigener Kommando-Ebene
Open-source multi-agent AI desktop client — build and command your AI agent team through conversation. A commander LLM dispatches sub-agents in parallel or in series; agents self-evolve via reflection and skill crystallization. Local-first, BYO LLM keys (Claude · OpenAI · Gemini · DeepSeek · Kimi · GLM · Qwen). macOS / Windows / Linux.
Auf einen Blick
- Was ist das?
- Orkas ist ein quelloffener Desktop-Client, in dem ein Commander-LLM Spezialagenten parallel oder sequenziell steuert. Die Modellschlüssel und Dateien bleiben lokal, die Orchestrierung läuft über einen Chat statt über Orchestrierungscode.
- Für wen ist es gedacht?
- Wer mehrere LLM-Anbieter parallel nutzen will und keinen Server dazwischen möchte, findet in Orkas einen lokal gespeicherten Orchestrierungs-Client unter MIT-Lizenz. Wer reproduzierbare Pipelines, versionierte Agent-Definitionen oder garantierten Linux-Support braucht, sollte zuerst die Quellcode-Installation und die Agent-Konfigurationsdateien prüfen, bevor er Produktionsaufgaben überträgt.
- Darf ich es kommerziell nutzen?
- Ja. MIT ist eine freizügige Lizenz: Sie dürfen darauf aufbauende Software nutzen, verändern und verkaufen, solange Sie die Urheberrechts- und Lizenzhinweise beibehalten.
- Wird es noch gepflegt?
- Ja. Die letzten Commits kamen vor 1 Tag.
- 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 15. September 2026) und auf unserer Analyse. Sie sind keine Rechtsberatung.
TIEFGEHENDE OPEN-SOURCE-ANALYSE
Ein Chat statt vieler Einzelgespräche mit Modellen
Das Problem, das Orkas adressiert, ist die Zerstreuung: Wer heute Recherche, Text, Präsentation und Dateikonvertierung mit LLMs erledigt, wechselt zwischen Browser-Tabs, kopiert Zwischenergebnisse per Hand und verliert den Überblick darüber, welches Modell welche Teilaufgabe bearbeitet hat. Orkas setzt dagegen einen Commander ein, der ein Ziel in Schritte zerlegt und diese an Spezialagenten verteilt. Das README nennt als Beispiel einen Auftrag, der Recherche, Bericht und Foliendeck umfasst und von DeepResearcher, ContentWriter und PptMaker abgearbeitet wird. Die Zielgruppe sind damit keine Bibliotheksentwickler, sondern Anwender, die eine Aufgabe beschreiben und danach fertige Dateien auf der Platte vorfinden wollen. Der Desktop-Client ist für macOS, Windows und Linux gedacht, wobei für Linux laut README nur der Start aus dem Quellcode beschrieben ist.
Commander, Spezialisten und der Weg der Daten
Die Architektur, die aus dem Material hervorgeht, hat drei Ebenen. Oben sitzt der Commander, ein LLM, das Kontext liest, das Ziel in Schritte zerlegt und entscheidet, welcher Agent, welche Fähigkeit und welches Werkzeug zum Zug kommt. Darunter liegen die Spezialagenten, jeder mit eigenen Skills, eigenem Gedächtnis und eigenen Werkzeugen. Die Dritte Ebene sind externe Werkzeuge und CLI-Agenten: Das README nennt Claude Code, Codex, OpenCode und Cline sowie das Open-Source-Projekt HyperFrames, die als lokale Werkzeuge eingebunden und vom selben Commander koordiniert werden. Bemerkenswert ist, dass der Commander nicht nur delegiert, sondern allgemeine Teile selbst erledigt, wenn kein Spezialist besser passt. Das ist eine bewusste Designentscheidung gegen einen reinen Router. Die Ausführung erfolgt laut Beschreibung parallel oder sequenziell, je nach Abhängigkeit der Schritte. Modellaufrufe gehen laut README direkt von der Maschine zum Anbieter, ohne Zwischenschicht. Gespräche, Dateien, API-Schlüssel, Wissensbasen und selbst gebaute Agenten liegen auf der lokalen Festplatte.
Neun Agenten ab Werk, dreißig im Marktplatz
Orkas liefert neun Spezialagenten direkt im Installationspaket mit. DeepResearcher plant Untersuchungen, prüft Quellen, markiert Widersprüche und liefert einen Bericht mit Zitaten. ContentWriter erzeugt Beiträge, Artikel, Newsletter und Fallstudien. PptMaker baut aus einem Thema, einer Gliederung oder einem Dokument ein bearbeitbares PPTX-Deck. ProductDeveloper arbeitet repository-bezogen an PRDs, Fehlern, Refactorings und Codereviews. OfficeWorker erstellt und prüft Word-, Excel-, PowerPoint- und PDF-Dateien, einzeln oder im Stapel. VideoStudio und ImageStudio decken Bewegtbild und Grafik ab, wobei ImageStudio laut README zuerst HTML, CSS und SVG nutzt und Bildmodelle nur dann einsetzt, wenn das Motiv sie erfordert. UIDesigner erzeugt aus Produktzielen, PRDs, Screenshots oder Figma-Material bearbeitbare, HTML-basierte UI-Ergebnisse. SeoGeoAgent nimmt eine URL entgegen und liefert technisches Audit, Inhaltsqualität, Core Web Vitals, GEO-Zitierbarkeit, einen Gesundheitswert und eine gewichtete Liste von Korrekturen. Insgesamt nennt das README dreißig Agenten im Marktplatz, und der Commander kann auf Zuruf einen eigenen Agenten bauen. Diese Aufteilung nach Domänen statt nach Modellfähigkeiten ist der eigentliche Strukturgedanke: Der Anwender wählt nicht GPT oder Claude, sondern Recherche oder Präsentation.
Installation und Modellschlüssel
Für macOS und Windows gibt es fertige Installer. Das README verlinkt Orkas-mac-arm64.dmg für Apple Silicon, Orkas-mac-x64.dmg für Intel-Macs und Orkas-Setup.exe für Windows x64. Linux ist der Ausnahmefall: Dort verweist das README auf den Abschnitt Quick start und darauf, dass glibc-basierte x64- und arm64-Systeme derzeit aus dem Quellcode laufen. Da das Projekt in TypeScript geschrieben ist und Electron verwendet, ist der Quellcode-Weg für Linux-Anwender kein Nebenschauplatz, sondern der offiziell beschriebene Pfad. Die Modellanbindung folgt dem BYO-Key-Prinzip. Das README listet Claude, OpenAI, Gemini, DeepSeek, Kimi, GLM, Qwen, MiniMax und Doubao. Die Zuweisung erfolgt pro Agent, sodass ein Agent auf Claude, ein zweiter auf DeepSeek und ein dritter auf einem lokalen Endpunkt laufen kann. Das ist praktisch relevant, weil verschiedene Agenten sehr unterschiedliche Anforderungen haben: Ein Recherche-Agent profitiert von langem Kontext und Zitatfähigkeit, ein Formatierungsagent von niedrigen Kosten. Konkrete Konfigurationsschlüssel für die Anbieterauswahl nennt das bereitgestellte Material nicht, hier bleibt nur der Verweis auf die Anwendung selbst. Wer die Kosten kontrollieren muss, sollte vor dem ersten längeren Auftrag klären, welcher Agent welches Modell verwendet, denn das README macht keine Aussage über Standardzuordnungen.
Reflexion und Skill-Kristallisation als Erhaltungskosten
Der Self-Evolution-Mechanismus ist der Teil, der budgetiert werden muss. Laut README verbessert sich jeder Agent nach jeder Aufgabe durch Reflexion, und Fähigkeiten werden als Skills kristallisiert. Das bedeutet: Nach einem Lauf entstehen neue Artefakte, die den nächsten Lauf beeinflussen. Das ist kein neutrales Protokollieren. Wer einen Agenten über Wochen auf dieselbe Weise arbeiten lässt, bekommt unter Umständen einen anderen Agenten zurück als den, der ursprünglich installiert wurde. Das README beschreibt weder, wie sich eine Kristallisation rückgängig machen lässt, noch ob es eine Versionierung der Skills gibt. Genau hier liegt die wichtigste offene Frage für den produktiven Einsatz. Solange die Anbieterdokumentation keine Rollback-Semantik für Skills und Gedächtnis beschreibt, ist die Selbstverbesserung ein Merkmal, das man beobachten und nicht blind vertrauen sollte. Ein pragmatischer Umgang wäre, die lokalen Verzeichnisse für Agenten und Wissensbasen vor größeren Änderungen zu sichern. Das Material nennt diese Pfade nicht, aber die Tatsache, dass alles auf der Platte liegt, macht eine solche Sicherung überhaupt erst möglich.
Grenzen: Linux, Reifegrad und die Frage der Reproduzierbarkeit
Die deutlichste Einschränkung steht im README selbst. Fertige Installer gibt es nur für macOS und Windows, Linux läuft aus dem Quellcode. Für eine Werkstatt mit gemischten Arbeitsplätzen ist das ein Bruch in der Einheitlichkeit, weil die Linux-Variante dann nicht dieselbe Update-Route hat wie die gepackten Varianten. Eine zweite Grenze betrifft die Orchestrierung als solche. Ein Commander, der zur Laufzeit entscheidet, welche Agenten in welcher Reihenfolge laufen, produziert Ergebnisse, die sich schwerer reproduzieren lassen als ein fest verdrahteter Ablauf. Wer Prüfpfade, Audits oder deterministische Ausgaben braucht, wird mit einem Chat-Interface nicht glücklich. Drittens ist der Vergleich mit Cloud-Plattformen nicht nur ein Vorteil: Lokale Speicherung bedeutet, dass Backup, Verschlüsselung und Zugriffskontrolle beim Anwender liegen. Das README nennt diese Punkte nicht, und das ist eine Lücke, denn ein Verzeichnis mit API-Schlüsseln und Kundendokumenten auf einem Laptop ist ein anderes Risikoprofil als ein verwalteter Dienst. Viertens ist Orkas kein Werkzeug für Einzelaufgaben. Wer einmalig einen Text zusammenfassen will, trägt mehr Installations- und Konfigurationsaufwand als nötig.
Der Unterschied zu LangChain, CrewAI und Cloud-Orchestrierung
Das README selbst vergleicht Orkas mit LangChain, CrewAI, Cloud-Agent-Plattformen und OpenClaw. Der Vergleich ist aufschlussreich, weil er die Achse zeigt, auf der Orkas sich positioniert. LangChain ist eine Bibliothek für Entwickler, die Orchestrierung in eigenem Python- oder JavaScript-Code schreiben. CrewAI definiert Rollen und Crews ebenfalls im Code. Orkas verschiebt genau diese Definition in eine Desktop-Anwendung: Statt eine Kette zu programmieren, beschreibt man ein Ziel im Chat. Der Preis dafür ist Kontrolle. In LangChain oder CrewAI ist der Ablauf ein Artefakt, das man versionieren, testen und in eine CI-Pipeline hängen kann. In Orkas ist der Ablauf das Ergebnis einer Entscheidung des Commander zur Laufzeit. Der Unterschied zu Cloud-Orchestrierung liegt beim Datenpfad: Dort liegen Gespräche, Dateien und Schlüssel auf fremder Infrastruktur, bei Orkas laut README lokal, mit direkten Modellaufrufen zum Anbieter. OpenClaw wiederum ist ein einzelner, dauerhaft laufender Assistent, der über Messaging-Kanäle erreichbar ist. Das ist ein anderes Modell: Dort gibt es einen Agenten mit vielen Eingängen, hier mehrere Spezialisten unter einer Kommandoebene. Wer bereits ein Agenten-Framework im Einsatz hat, findet in Orkas keine Bibliothek, sondern eine Anwendung, und das schließt eine schrittweise Migration aus.
Lizenz, Wartung und was vor dem Einsatz zu prüfen ist
Orkas steht unter der MIT-Lizenz. Das ist die permissivste übliche Variante: Nutzung, Änderung und Weitergabe sind erlaubt, solange der Urheberrechtshinweis und der Lizenztext erhalten bleiben. Für Unternehmen bedeutet das geringe rechtliche Reibung, aber auch keine Garantie. Es gibt keine Klausel, die Haftung oder Support zusichert, und das README macht dazu keine Zusage. Die Release-Historie im Material zeigt drei Veröffentlichungen innerhalb weniger Wochen im August 2026, was auf eine aktive Entwicklungsphase hindeutet. Eine Aussage über langfristige Wartung lässt sich daraus nicht ableiten, und das sollte man auch nicht versuchen. Wer Orkas einführt, prüft zuerst drei Dinge: ob der eigene Arbeitsplatz auf der Liste der gepackten Installer steht oder ob der Quellcode-Weg zumutbar ist, wie sich die Modellzuordnung pro Agent konfigurieren lässt und ob die lokal abgelegten Agenten- und Wissensverzeichnisse in die bestehende Backup-Routine passen. Erst danach lohnt der Blick auf die Agenten selbst, denn die Selbstverbesserung verändert das Verhalten über die Zeit, und dafür beschreibt das Material keinen Rückweg.
Redaktionelles Fazit
Wer mehrere LLM-Anbieter parallel nutzen will und keinen Server dazwischen möchte, findet in Orkas einen lokal gespeicherten Orchestrierungs-Client unter MIT-Lizenz. Wer reproduzierbare Pipelines, versionierte Agent-Definitionen oder garantierten Linux-Support braucht, sollte zuerst die Quellcode-Installation und die Agent-Konfigurationsdateien prüfen, bevor er Produktionsaufgaben überträgt.
Community-Notizen