letta-ai/letta ist nur noch eine Weiterleitung: was das Repository heute noch liefert

Was dieses Repository heute noch ist

Die README beginnt mit einem Hinweis, der die Erwartung sofort zurechtrückt: Dieses Repository dient jetzt als Landingpage für das Letta-Projekt. Der Quellcode liegt laut README in letta-ai/letta-code, zusammen mit dem Agent-Harness, der interaktiven Terminal-Oberfläche, dem App Server, den Channels und der Runtime, die Desktop- und Web-App nutzen. Wer die Repository-Liste nach einem Server durchsucht, findet hier keinen. Was hier bleibt, sind Tags und Releases für Reproduzierbarkeit sowie ein archive-Branch mit dem ausgemusterten Letta V1 API Server. Die letzten Releases liegen bei 0.16.8 vom 14. Mai 2026, 0.16.7 vom 31. März 2026 und 0.16.6 vom 4. März 2026; der letzte Push auf main datiert vom 8. September 2026. Dieses Muster passt zu einem Repository, das nicht mehr aktiv entwickelt wird, sondern Verweise und Historie verwaltet. Die Lizenz ist Apache-2.0, und die README macht keine Angabe dazu, ob diese Lizenz auch für letta-code gilt. Wer die Lizenzbedingungen für den tatsächlich genutzten Code prüfen will, muss das im Ziel-Repository tun, nicht hier.

Das Problem, das Letta adressiert, und für wen es gedacht ist

Die Beschreibung nennt den Kern: eine Plattform für zustandsbehaftete Agenten, also KI mit erweitertem Gedächtnis, die über die Zeit lernen und sich verbessern kann. Der Kontrast zu einem einfachen Chat-Aufruf ist der Zustand. Ein zustandsloser Aufruf kennt nur das, was im aktuellen Kontextfenster steht. Letta setzt dagegen auf Gedächtnis, das zwischen Sitzungen erhalten bleibt. Die README benennt die Zielgruppe indirekt über die Zugangswege: Terminal-Nutzer, die letta starten, Betreiber, die letta server für lokale oder selbst gehostete Agenten ausführen, Nutzer von Desktop-Apps für macOS, Windows und Linux, Browser- und Mobilnutzer über chat.letta.com, Teams in Slack, Telegram, Discord oder eigenen Channels sowie TypeScript-Entwickler, die den Letta Agent SDK verwenden. Es geht also nicht um ein Modell, sondern um die Schicht darüber: Identität, Gesprächsverlauf und Gedächtnis eines Agenten über mehrere Oberflächen und Rechner hinweg. Wer nur eine einzelne Anfrage an ein LLM stellen will, braucht dieses Projekt nicht.

Wie der Zustand getragen wird: Runtime, App Server, Cloud

Aus der README lässt sich der Datenfluss nur grob ablesen, und das sollte man offen sagen. Es gibt eine Runtime, die von Desktop- und Web-App genutzt wird, einen App Server, der laut README für lokale oder selbst gehostete Agenten gedacht ist, und Letta Cloud, die Gedächtnis, Identität und Gespräche über Computer hinweg verfügbar hält. Die Channels Slack, Telegram, Discord und eigene Kanäle sitzen offenbar als weitere Oberflächen auf derselben Agentenschicht. Der SDK bindet Agenten in TypeScript-Anwendungen ein. Damit ergibt sich eine Aufteilung: Die Runtime hält den Agenten samt Gedächtnis, der App Server stellt ihn lokal bereit, die Cloud synchronisiert ihn über Geräte, und die Oberflächen sind austauschbar. Ob das Gedächtnis in einer Datenbank, im Dateisystem oder im Cloud-Dienst liegt, sagt die README nicht. Wer das für eine Kapazitäts- oder Datenschutzentscheidung braucht, muss die Dokumentation unter docs.letta.com lesen; aus diesem Repository lässt sich das nicht beantworten.

Installation: npm, letta, letta server

Die README gibt genau zwei Befehle für den Einstieg. Zuerst die globale Installation über npm:

npm install -g @letta-ai/letta-code

Danach der Start der interaktiven Terminal-Oberfläche:

letta

Für lokale oder selbst gehostete Agenten folgt:

letta server

Das Paket heißt @letta-ai/letta-code, nicht letta-ai/letta. Diese Unterscheidung ist praktisch wichtig, weil ein Leser, der nur den Repository-Namen kennt, sonst nach einem npm-Paket sucht, das zu diesem Repository gehört. Ein Konfigurationsschlüssel, ein Port oder ein Pfad für den App Server wird in der README nicht genannt. Auch eine Angabe zu benötigten Node-Versionen fehlt. Wer letta server hinter einem Reverse Proxy oder in einem Container betreiben will, findet hier keine Vorlage und muss die Deployment-Anleitung in der Dokumentation heranziehen. Die README verweist ausdrücklich auf die README von letta-ai/letta-code und auf docs.letta.com für aktuelle Installations-, Entwicklungs- und Deployment-Anweisungen.

Der archive-Branch ist keine Option für den Produktivbetrieb

Die deutlichste Einschränkung steht im Abschnitt Historical source. Der archive-Branch enthält den ausgemusterten Letta V1 API Server in dem Zustand, in dem dieses Repository archiviert wurde. Die README formuliert die Konsequenz unmissverständlich: Dieser Quellcode wird nicht unterstützt, erhält keine Fehlerkorrekturen und keine Sicherheitsupdates und sollte nicht in der Produktion verwendet werden. Das ist keine vorsichtige Formulierung, sondern eine klare Grenze. Wer den V1-Server heute noch betreibt, arbeitet mit einem Stand, für den es keine Patches gibt. Die vorhandenen Tags und Releases bleiben verfügbar, was für Reproduzierbarkeit nützlich ist, aber nichts über den Wartungszustand aussagt. Ein weiterer Punkt: Die README beschreibt weder einen Migrationspfad von V1 zu letta-code noch eine Kompatibilitätsschicht. Ob Endpunkte, Speicherformate oder Agenten-IDs übernommen werden können, ist aus dem Material nicht ersichtlich. Eine Migration ist damit ein eigenes Vorhaben und nicht ein Wechsel des Installationsbefehls.

Eigenbau auf einem LLM-SDK als Gegenentwurf

Die naheliegende Alternative ist, Agenten direkt auf einem LLM-SDK aufzubauen und den Zustand selbst zu verwalten, etwa mit einer eigenen Datenbanktabelle für Gesprächsverläufe und einer selbst geschriebenen Zusammenfassungsroutine. Der Unterschied liegt nicht im Modellzugriff, sondern in der Zustandsverwaltung. Bei einem Eigenbau bestimmt man selbst, was gespeichert wird, wo es liegt und wann es verdichtet wird; man kontrolliert das Format und ist an keine Runtime gebunden. Dafür entfallen die fertigen Oberflächen: Terminal-UI, Desktop-Apps, Browserzugang, Channels und SDK kommen nicht mit. Wer einen Agenten in Slack und gleichzeitig im Browser mit demselben Gedächtnis betreiben will, müsste jede dieser Anbindungen selbst bauen und den Zustand zwischen ihnen synchron halten. Letta liefert genau diese Anbindungen laut README als Teil des Projekts. Der Preis dafür ist die Bindung an die Runtime von letta-code und, wenn Geräteübergreifendes Gedächtnis gewünscht ist, an Letta Cloud. Wer volle Kontrolle über Speicherort und Format braucht, fährt mit dem Eigenbau besser; wer mehrere Oberflächen mit einem gemeinsamen Agentengedächtnis bedienen will, spart mit Letta erheblich Arbeit.

Wartungskosten und was die Lizenz nicht regelt

Dieses Repository verursacht keine Wartungskosten, weil dort kein laufender Dienst mehr liegt. Die Kosten entstehen im Ziel-Repository. Die Release-Historie hier zeigt drei Veröffentlichungen zwischen März und Mai 2026 und danach keinen weiteren Eintrag; wer auf diesem Stand aufsetzt, übernimmt einen eingefrorenen Codestand. Für letta-code lässt sich aus dem vorliegenden Material kein Release-Takt ableiten, sodass Upgrade-Aufwand und Bruchstellen nicht abschätzbar sind. Bei der Lizenz ist Vorsicht angebracht: Die Angabe Apache-2.0 bezieht sich auf dieses Repository. Die README sagt nichts darüber, unter welcher Lizenz letta-code oder Letta Cloud stehen. Wer den Code kommerziell einsetzt, muss die Lizenzdatei im tatsächlich verwendeten Repository prüfen; eine Aussage über die Vereinbarkeit mit dem eigenen Geschäftsmodell lässt sich daraus hier nicht ableiten, und eine Rechtsberatung ersetzt das ohnehin nicht.

Redaktionelles Fazit

Wer heute einen zustandsbehafteten Agenten mit persistentem Gedächtnis betreiben will, installiert @letta-ai/letta-code und liest die Dokumentation unter docs.letta.com, nicht dieses Repository. Wer bereits den V1-Server auf dem archive-Branch laufen hat, sollte vor jedem weiteren Deployment prüfen, ob der eigene Code Pfade aus der alten API importiert, denn dieser Branch erhält laut README keine Fehler- oder Sicherheitskorrekturen. Vor dem Umstieg zu klären ist, ob die eigene Persistenz- und Identitätsschicht an die Stelle passt, an der Letta Cloud Gedächtnis, Identität und Gespräche über Rechner hinweg hält, oder ob ein lokaler App Server über letta server genügt. Erst messen, ob der bisherige Speicherpfad überhaupt übernommen werden kann, dann migrieren.

Offizielle Quellen

1. letta-ai/letta on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases