alookai/alook v0.1.24: Gemeinsame Räume für Menschen und Coding-Agenten
Projektüberblick: Die Kollaborationsebene für Ihre KI-Belegschaft. Führen Sie ein Team von KI-Agenten, die sich per E-Mail koordinieren, den Speicher teilen und mit jeder Aufgabe besser werden.
Auf einen Blick
- Was ist das?
- Das Projekt gibt lokalen Coding-Agenten eine beständige Identität und stellt sie in gemeinsame Räume. Was npx @alook/app onboard einrichtet, welche Laufzeiten angebunden werden und wo die gehostete Ebene liegt.
- Für wen ist es gedacht?
- Geeignet ist alook für Teams, die bereits mit Coding-Agenten arbeiten und diese für Kollegen adressierbar machen wollen, statt sie in einzelnen Terminals zu betreiben. Weniger geeignet ist es für Vorhaben ohne gehostete Ebene, weil Orchestrierung und Speicher laut Diagramm dort liegen, und für alle, die eine ausgereifte Version erwarten, da die Releases bei v0.1.24 stehen.
- Darf ich es kommerziell nutzen?
- Ja. Apache-2.0 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
Was alookai/alook unter v0.1.24 zwischen Menschen und Agenten aufspannt
Die Repository-Beschreibung nennt alook eine Kollaborationsebene für die KI-Belegschaft, in der eine Gruppe von Agenten sich per E-Mail abstimmt, Erinnerung teilt und mit jeder Aufgabe besser wird. Das README formuliert es räumlich: Alook sei der Ort, an dem Menschen und KI-Agenten dieselben Räume teilen. Lokale Coding-Agenten erhielten beständige Identitäten, bestehend aus einem Handle, einem Postfach und Mitgliedschaften, sodass ein Team sie in Servern, Kanälen und Direktnachrichten so ansprechen könne wie eine Person.
Die Metadaten weisen TypeScript als Hauptsprache aus, die Lizenz ist Apache-2.0, der Standardbranch heißt main. Bei der Materialsammlung standen 1165 Sterne, 186 Forks und 85 offene Issues in den Metadaten. Die Releases liegen dicht beieinander: v0.1.24 vom 28. August 2026, v0.1.23 vom Vortag, v0.1.22 vom 27. August 2026.
Die Versionsnummer verdient Beachtung. Bei 0.1.x ist von einem frühen Stand auszugehen, unabhängig von der Sternzahl. Das README enthält keine Aussage zur Reife.
npx @alook/app onboard und die Oberfläche unter localhost:15210
Der Einstieg besteht aus einem Aufruf ohne vorherige Installation:
npx @alook/app onboard
Laut README führt dieser Befehl durch die Einrichtung: Er verbindet den eigenen Rechner, erkennt vorhandene Laufzeiten und startet alook lokal. Danach wird http://localhost:15210 geöffnet.
Welche Laufzeiten erkannt werden, bleibt offen. Das README nennt keine Liste für den Erkennungsschritt, sondern verweist auf die eigene Tabelle im Abschnitt Bring Your Own Agent. Ob sich der Port konfigurieren lässt, welche Node-Version vorausgesetzt wird und welche Betriebssysteme unterstützt sind, steht im README nicht.
Als zweiter Weg wird die Website alook.ai genannt, über die sich eine lokale Laufzeit verbinden lässt. Damit gibt es zwei Pfade mit demselben Ziel: ein lokaler, der mit npx beginnt, und ein gehosteter, der über die Website läuft.
Handle, Postfach und Mitgliedschaften: wie Agenten adressierbar werden
Der Kern des Ansatzes ist die Identität. Ein Agent erhält einen Handle, ein Postfach und Mitgliedschaften in Räumen. Damit ist er nicht mehr ein Prozess in einem Terminal, sondern ein Gegenüber, das angesprochen werden kann. Das README beschreibt das Ziel so, dass ein Team Agenten in Servern, Kanälen und Direktnachrichten erreicht, auf demselben Weg wie eine Person.
Dazu gehört die Behauptung der Beständigkeit: Eine Identität bleibt über Räume hinweg dieselbe. Der im README genannte Vorteil liegt auf der Hand, wenn mehrere Menschen mit demselben Agenten arbeiten.
Zwei weitere Eigenschaften nennt das README ohne technische Einzelheiten. Local-first and Always-on bedeutet, dass der Agent auf dem eigenen Rechner läuft, während andere in alook mit ihm sprechen. Memory with initiative beschreibt einen Agenten, der Dinge in allen Räumen voranbringt. Wie dieser Antrieb ausgelöst wird und wo das Erinnerungswissen liegt, wird nicht erläutert.
Bring Your Own Agent: Claude Code, Codex, Cursor, OpenCode und Pi
Der Abschnitt Bring Your Own Agent trifft eine klare Aussage zur Arbeitsteilung: Alook verbindet sich mit den Coding-Agenten, die auf dem eigenen Rechner bereits vorhanden sind. Es stellt keine Modelle bereit und betreibt keine eigenen. Das README formuliert den Beitrag des Projekts als Erreichbarkeit.
Die Tabelle listet fünf Laufzeiten, alle mit dem Status Supported: Claude Code, Codex, Cursor, OpenCode und Pi. Damit deckt die Liste die gängigen Werkzeuge ab. Eine Spalte für Einschränkungen oder einen Zeitplan gibt es nicht, der Status ist binär.
Für die Planung folgt daraus zweierlei. Erstens entstehen die Modellkosten nicht bei alook, sondern beim Anbieter des jeweiligen Agenten. Zweitens hängt der Nutzen daran, dass einer der fünf Agenten im eigenen Ablauf schon eine Rolle spielt. Wer keinen davon einsetzt, findet im README keinen Weg, einen eigenen Agenten anzubinden; eine Schnittstellenbeschreibung fehlt.
Agent Machine, Hosted Machine und Storage im Architekturdiagramm
Das README enthält ein Diagramm, das die Aufteilung in drei Bereiche zeigt. Auf der Agent Machine liegen zwei Komponenten: der Daemon aus dem Paket @alook/daemon sowie das Arbeitsverzeichnis des Agenten. Auf der Hosted Machine liegen die Webanwendung @alook/app und Warteschlangen. Als Storage sind eine SQLite-Datenbank und Dateien eingetragen.
Diese Aufteilung erklärt die im README beworbene Kombination aus lokalem Betrieb und Erreichbarkeit von außen. Der Agent arbeitet im eigenen Arbeitsverzeichnis, während Orchestrierung und Speicher auf der gehosteten Seite liegen. Die Verbindung zwischen beiden Bereichen läuft laut Diagramm über WebSocket.
Für eine Datenschutzbetrachtung ist genau diese Grenze der Prüfpunkt. Zu klären ist, was der Daemon aus dem Arbeitsverzeichnis an die gehostete Seite überträgt und was dort in SQLite landet. Das README beantwortet diese Frage nicht, und das Diagramm zeigt nur die Verbindungen, nicht deren Inhalt.
Next.js, Cloudflare Workers und Bun als Unterbau von alook
Unter dem Diagramm nennt das README den Stack: Next.js, Cloudflare Workers und Bun. Zusammen mit TypeScript als Hauptsprache ergibt das ein Bild der gehosteten Seite. Next.js trägt die Webanwendung, Cloudflare Workers die Ausführung am Netzrand, Bun die Laufzeit für Werkzeuge und Skripte.
Im Repository sind außerdem eine GitHub-Actions-Pipeline und eine Codecov-Abdeckungsanzeige eingebunden, wie die Verweise im Kopf des README zeigen. Beides sind Hinweise auf Automatisierung, keine Aussage über Prüftiefe.
Die Kombination hat eine praktische Folge. Wer alook selbst betreiben will, statt alook.ai zu nutzen, braucht Kenntnisse in allen drei Teilen des Stacks. Das README verweist Beitragende an CONTRIBUTING.md, das im vorliegenden Material nicht enthalten ist.
Grenzen von alook v0.1.x: gehostete Ebene, offene Fragen, keine Modelle
Die wichtigste Grenze folgt aus der Architektur. Orchestrierung, Webanwendung und Speicher liegen auf einer gehosteten Maschine. Wer alook einsetzt, verlässt sich auf eine Ebene außerhalb des eigenen Rechners, auch wenn der Agent lokal bleibt. Für Umgebungen mit strengen Vorgaben zum Datenabfluss ist das vorab zu prüfen; das README enthält dazu keine Aussage.
Zweitens stehen technische Einzelheiten aus. Wie ein Agent angebunden wird, welche Schnittstelle er erfüllen muss, wie die Erkennung im Onboarding arbeitet und ob der Port konfigurierbar ist, bleibt offen. Bei 85 offenen Issues in den Metadaten ist damit zu rechnen, dass manche dieser Fragen erst im Betrieb auftauchen.
Drittens fehlen belegbare Werte. Das README nennt keine Antwortzeiten, keine Zahl gleichzeitiger Räume und keine Grenzen der Warteschlangen. Die Funktionsbeschreibungen sind Produktaussagen. Wer belastbare Zahlen braucht, muss sie selbst erheben.
Alternative zu alook: Agenten direkt im Terminal ohne gemeinsame Räume
Die Alternative ist der Verzicht auf die Zwischenschicht: Claude Code, Codex oder OpenCode werden wie bisher im Terminal oder in der eigenen IDE bedient. Der Unterschied liegt in der Adressierbarkeit. Ohne alook hat ein Agent keinen Handle, kein Postfach und keine Mitgliedschaften, bleibt also an die Sitzung des jeweiligen Rechners gebunden. Für Einzelpersonen, die allein mit einem Agenten arbeiten, ändert sich dadurch wenig.
Der zweite Unterschied betrifft die Geräte. Das README bewirbt Reach, also denselben Raum auf Desktop und Telefon, ohne dass beim Wechsel etwas verloren geht. Dieses Ziel setzt eine zentrale Instanz voraus, die ein rein lokaler Betrieb nicht bietet.
Wer zwischen beiden Wegen entscheidet, kann mit dem im README genannten Befehl anfangen: Nach npx @alook/app onboard lässt sich unter http://localhost:15210 prüfen, ob die eigene Laufzeit erkannt wird und ob ein Agent im Raum tatsächlich antwortet. Erst danach lohnt die Frage, ob weitere Personen eingeladen werden.
Redaktionelles Fazit
Geeignet ist alook für Teams, die bereits mit Coding-Agenten arbeiten und diese für Kollegen adressierbar machen wollen, statt sie in einzelnen Terminals zu betreiben. Weniger geeignet ist es für Vorhaben ohne gehostete Ebene, weil Orchestrierung und Speicher laut Diagramm dort liegen, und für alle, die eine ausgereifte Version erwarten, da die Releases bei v0.1.24 stehen. Vor dem Einsatz gehört geklärt, ob die eigene Laufzeit aus der Tabelle unterstützt wird, was der Daemon aus dem Arbeitsverzeichnis nach außen gibt und ob ein Betrieb über localhost:15210 hinaus vorgesehen ist.
Community-Notizen