lumen: Side-by-side-Diff, PR-Review und KI-Commit-Nachrichten im Terminal
Beautiful git diff viewer, generate commits with AI, get summary of changes, all from the CLI
Auf einen Blick
- Was ist das?
- lumen ist ein in Rust geschriebener Diff-Viewer für das Terminal, der Git- und Jujutsu-Repositories, GitHub-Pull-Requests und optional KI-gestützte Commit-Nachrichten in einem einzigen Binary bündelt. Der Diff-Viewer funktioniert ohne jede Konfiguration, die KI-Funktionen sind ausdrücklich optional.
- Für wen ist es gedacht?
- Wer regelmäßig große Diffs oder GitHub-PRs im Terminal liest und dafür bisher auf eine GUI ausweicht, findet in lumen einen Kandidaten, den man an einem Nachmittag ausprobiert: brew install jnsahaj/lumen/lumen oder cargo install lumen, danach lumen diff gegen ein echtes Repository. Wer nur gelegentlich einen kleinen Diff anschaut, bleibt bei git diff --color-words, weil der Mehrwert erst bei der Navigation durch viele Hunks und Dateien greift.
- 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 61 Tagen.
- In welcher Sprache ist es geschrieben?
- Hauptsächlich Rust, 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
Welches Problem lumen löst und für wen es gedacht ist
git diff ist ein zeilenweiser Stream. Sobald ein Commit hunderte Zeilen umfasst, verliert man beim Scrollen die Orientierung, weil alte und neue Fassung untereinander stehen und nicht nebeneinander. lumen setzt genau dort an: Das README beschreibt einen Side-by-side-Diff-Viewer mit tree-sitter-Syntaxhervorhebung, der als einzelnes statisches Rust-Binary ausgeliefert wird und laut eigener Aussage auch bei Diffs mit mehreren tausend Zeilen reaktionsfähig bleibt. Die Zielgruppe sind Entwickler, die Reviews im Terminal erledigen und dafür keine grafische Oberfläche starten wollen. Dazu kommen zwei Erweiterungen, die über einen reinen Viewer hinausgehen. Erstens die Anbindung an GitHub-Pull-Requests, sodass man einen PR direkt aus der Kommandozeile öffnet und Dateien als gelesen markiert, was laut README mit GitHub synchronisiert wird. Zweitens optionale KI-Funktionen für Commit-Nachrichten, Erklärungen und natürlichsprachige Git-Befehle. Wer lumen nur als Diff-Viewer nutzt, braucht weder API-Schlüssel noch Netzwerkzugriff, und das ist eine bewusste Trennung, die das README an mehreren Stellen wiederholt.
Der Diff-Viewer als eigenständiges Werkzeug, die KI als Zusatzmodul
Die Architektur, die aus dem Material hervorgeht, ist zweigeteilt. Der Kern ist ein interaktives TUI, das einen Diff einliest und zweispaltig darstellt. Die Quelle dieses Diffs ist nicht fest verdrahtet: lumen diff liest unbestätigte Änderungen im Arbeitsverzeichnis, lumen diff HEAD~1 einen einzelnen Commit, lumen diff main..feature/A einen Bereich zwischen zwei Branches, und lumen diff --pr 123 beziehungsweise eine vollständige PR-URL holt den Diff von GitHub. Dasselbe TUI wird also mit unterschiedlichen Datenquellen gespeist, und die Navigation bleibt gleich. Das erklärt, warum dasselbe Werkzeug sowohl für lokale Arbeit als auch für Fremd-Reviews taugt. Die KI-Schicht sitzt daneben und wird nur bei lumen draft, lumen explain und der Befehlsgenerierung aktiv. Das README formuliert das explizit: Die KI-Helfer benötigen einen konfigurierten Anbieter, der Diff-Viewer nicht. Diese Trennung ist der wichtigste Entwurfsentscheid des Projekts, weil sie die Einstiegshürde auf null setzt und die Abhängigkeit von einem externen Dienst auf die Funktionen beschränkt, die sie tatsächlich brauchen.
Installation und die erste sinnvolle Konfiguration
lumen lässt sich auf zwei Wegen installieren, die das README nennt: brew install jnsahaj/lumen/lumen für macOS und Linux, oder cargo install lumen, wobei das README ausdrücklich darauf hinweist, dass cargo zusammen mit Rust installiert wird. Als Voraussetzung gilt git. Zwei optionale Abhängigkeiten werden benannt: fzf wird für lumen explain --list gebraucht, mdcat für eine hübschere Ausgabeformatierung. Beide sind nicht Teil des Kerns. Die Konfiguration liegt in ~/.config/lumen/lumen.config.json. Für die Darstellung gibt es mehrere Wege, denselben Wert zu setzen: das Flag lumen diff --theme dracula, die Umgebungsvariable LUMEN_THEME=catppuccin-mocha, oder der Schlüssel theme in der Konfigurationsdatei. Das README legt die Priorität offen: CLI-Flag vor Konfigurationsdatei vor LUMEN_THEME vor automatischer Erkennung des Betriebssystems. Diese Reihenfolge ist ungewöhnlich, weil die Umgebungsvariable sonst oft Vorrang vor der Datei hat. Wer also eine Theme-Einstellung in der Datei hinterlegt und sich wundert, warum sie nicht greift, sollte zuerst prüfen, ob LUMEN_THEME noch in der Shell gesetzt ist. Für die KI-Seite führt lumen configure durch die Einrichtung von Anbieter, API-Schlüssel und Modell, und schreibt das Ergebnis in dieselbe Datei. Das README nennt über zehn unterstützte Anbieter, ohne sie an dieser Stelle aufzulisten.
Stacked-Modus, Watch-Modus und Annotationen: die eigentlichen Review-Werkzeuge
Drei Funktionen heben lumen von einem reinen Betrachter ab. Der Stacked-Modus, aktiviert mit lumen diff main..feature --stacked, zeigt nicht den gesamten Bereich auf einmal, sondern jeden Commit einzeln. Die Navigation erfolgt über ctrl+h und ctrl+l oder über Pfeilschaltflächen in der Kopfzeile, die Position, SHA und Nachricht des aktuellen Commits anzeigt. Wichtiger als die Navigation ist der Zustand: Gelesene Dateien werden pro Commit verfolgt, sodass der Fortschritt beim Wechsel erhalten bleibt. Bei einem PR synchronisiert die Leertaste diesen Status mit GitHub. Wer schon einmal einen Pull-Request mit vierzig geänderten Dateien in der Web-Oberfläche durchgeklickt hat, kennt den Unterschied zwischen einem Viewer und einem Werkzeug mit persistentem Zustand. Der Watch-Modus, lumen diff --watch oder die Taste w, aktualisiert die Ansicht bei Dateiänderungen. Die Annotationsfunktion arbeitet auf drei Ebenen: eine Auswahl per Maus, ein Hunk über die Tasten { und }, oder eine ganze Datei, wenn weder Auswahl noch Hunk fokussiert ist. Die Taste i legt die Annotation an, I öffnet die Verwaltung zum Bearbeiten, Löschen, Kopieren oder Exportieren. Annotierte Zeilen erhalten eine ▍-Markierung im Rand. Das ist eine durchdachte Abstufung, allerdings bleibt im Material offen, in welchem Format der Export erfolgt und ob Annotationen über Sitzungen hinweg erhalten bleiben.
Wo lumen an seine Grenzen stößt
Die KI-Funktionen sind ohne konfigurierten Anbieter nicht verfügbar. Das ist keine Einschränkung, die man wegdiskutieren kann, sondern eine harte Grenze: lumen draft, lumen explain und die Befehlsgenerierung setzen einen API-Schlüssel und ein Modell voraus, die über lumen configure hinterlegt werden. Wer in einer Umgebung arbeitet, in der gestagte Änderungen das Repository nicht verlassen dürfen, kann diese Funktionen nicht nutzen, und damit fällt ein Teil des beworbenen Funktionsumfangs weg. Der Diff-Viewer bleibt davon unberührt, aber die Entscheidung für lumen sollte dann allein auf dem Viewer basieren. Eine zweite Grenze betrifft die PR-Anbindung: lumen diff --pr 123 und --detect-pr setzen GitHub voraus. Für Repositories bei anderen Hosting-Anbietern greift nur der lokale Pfad über Branches und Commits. Drittens die optionalen Abhängigkeiten: lumen explain --list funktioniert ohne fzf nicht, und ohne mdcat entfällt die formatierte Ausgabe. Das sind kleine Stolpersteine, aber sie stehen im README unter Prerequisites und nicht in den jeweiligen Befehlsbeschreibungen, was die Fehlersuche unnötig erschwert. Schließlich bleibt die Frage der Leistung: Das README behauptet Reaktionsfähigkeit bei Diffs mit mehreren tausend Zeilen, nennt aber keine Messmethode und keine Vergleichswerte. Das ist eine Aussage, die man an den eigenen Dateien prüfen muss, nicht eine, die man übernehmen sollte.
Was lumen von delta oder einem GUI-Review unterscheidet
Der naheliegendste Vergleich ist delta, das ebenfalls Diffs im Terminal aufwertet. Der Unterschied liegt im Interaktionsmodell. delta ist ein Pager: Es formatiert die Ausgabe von git diff und beendet sich, wenn man durchgescrollt hat. lumen ist eine Anwendung mit eigenem Zustand. Man navigiert mit j und k, springt mit { und } zwischen Hunks, klappt mit tab eine Seitenleiste ein, markiert Dateien als gelesen und kehrt später zum selben Commit zurück. Diese Zustandsführung ist der eigentliche Unterschied, und sie ist auch der Grund, warum lumen bei einem einzelnen kleinen Diff mehr Aufwand bedeutet als Nutzen: Man startet ein TUI, um drei Zeilen zu sehen. Umgekehrt skaliert der Pager-Ansatz nicht auf einen PR mit vielen Dateien, weil es keinen Begriff von Fortschritt gibt. Gegenüber einer Web-Oberfläche wie der GitHub-Review-Ansicht tauscht lumen grafische Bequemlichkeit gegen Tastaturnähe und die Möglichkeit, den Diff im Kontext des lokalen Arbeitsverzeichnisses zu lesen, inklusive der Taste e zum Öffnen der Datei im Editor. Wer ohnehin im Browser reviewt und dort Kommentare hinterlässt, gewinnt durch lumen wenig, es sei denn, die Annotationen lassen sich in den eigenen Workflow exportieren.
Wartung, Lizenz und die Frage der Anbieterabhängigkeit
lumen steht unter der MIT-Lizenz. Das ist eine permissive Lizenz, die kommerzielle Nutzung, Veränderung und Weitergabe erlaubt, sofern Lizenz- und Urheberrechtshinweis erhalten bleiben. Für die meisten Teams bedeutet das keine Einschränkung, und es entstehen keine Copyleft-Pflichten für den eigenen Code. Eine rechtliche Bewertung ersetzt das nicht, insbesondere wenn lumen in eine kommerzielle Toolchain eingebettet wird. Zur Wartung lässt sich aus dem Material nur wenig Sicheres ableiten. Der letzte Push liegt laut Repository-Angabe bei 2026-07-16, die letzten Releases v2.32.0 und v2.31.0 stammen von Mitte Juli 2026, v2.30.0 von Anfang Juni. Das Muster deutet auf eine aktive Versionsfolge mit kleineren Abständen hin, aber die Nummerierung springt zwischen Minor-Versionen, was auf häufige, überschaubare Änderungen schließen lässt, ohne dass sich daraus ein Versprechen über die Stabilität der Konfigurationsschlüssel ableiten ließe. Die eigentliche Wartungslast liegt ohnehin woanders: bei der KI-Seite. Ein konfigurierter Anbieter bedeutet einen API-Schlüssel, ein Modell und einen Dienst, dessen Verfügbarkeit und Preise nicht in lumens Hand liegen. Wer lumen draft regelmäßig nutzt, hängt einen Teil des eigenen Commit-Workflows an einen externen Endpunkt. Das sollte man bei der Entscheidung gegen den Komfort des Diff-Viewers abwägen, der ohne all das auskommt.
Redaktionelles Fazit
Wer regelmäßig große Diffs oder GitHub-PRs im Terminal liest und dafür bisher auf eine GUI ausweicht, findet in lumen einen Kandidaten, den man an einem Nachmittag ausprobiert: brew install jnsahaj/lumen/lumen oder cargo install lumen, danach lumen diff gegen ein echtes Repository. Wer nur gelegentlich einen kleinen Diff anschaut, bleibt bei git diff --color-words, weil der Mehrwert erst bei der Navigation durch viele Hunks und Dateien greift. Vor einem breiteren Einsatz sollte man prüfen, ob lumen configure mit dem eigenen Anbieter und Modell sauber durchläuft und ob lumen draft auf den eigenen gestagten Änderungen brauchbare Nachrichten liefert, denn das ist der Teil, der ohne Provider-Konfiguration schlicht nicht existiert.
Community-Notizen