letta-ai/letta とは何ですか？

このリポジトリは Letta のランディングページに変わった。npm で入るのは @letta-ai/letta-code であり、archive ブランチの V1 サーバはサポート外と明記されている。採用判断に必要な境界を整理する。

letta-ai/letta は商用利用できますか？

できます。Apache-2.0 は寛容なライセンスで、著作権表示とライセンス表示を残せば、使用・改変・販売が可能です。

letta-ai/letta は今もメンテナンスされていますか？

されています。最後のコミットは 5 日前です。

letta-ai/letta はどのプログラミング言語で書かれていますか？

GitHub はこのリポジトリの主な言語を示していません。

letta-ai/letta の現在地: letta-code への移転と V1 サーバの扱い

ひと目でわかる

これは何？: このリポジトリは Letta のランディングページに変わった。npm で入るのは @letta-ai/letta-code であり、archive ブランチの V1 サーバはサポート外と明記されている。採用判断に必要な境界を整理する。
誰に向いている？: 新規に状態を持つエージェントを組むなら、参照先は letta-ai/letta ではなく letta-ai/letta-code と docs.letta.com になる。npm install -g @letta-ai/letta-code で入るのはこのリポジトリのコードではないため、letta server を自前ホストする前に letta-code 側で App Server の運用要件とデータの保存先を確認してほしい。
商用利用できる？: できます。Apache-2.0 は寛容なライセンスで、著作権表示とライセンス表示を残せば、使用・改変・販売が可能です。
今もメンテナンスされている？: されています。最後のコミットは 5 日前です。
何の言語で書かれている？: GitHub はこのリポジトリの主な言語を示していません。

回答はプロジェクトの GitHub データ（最終同期：2026年9月15日）と当サイトの分析に基づくもので、法的助言ではありません。

オープンソース詳細解説

Hysen Labs 編集部 · 2026年9月10日 · letta-ai/letta

このリポジトリが解いている問題は、配布ではなく案内になったことだ

letta-ai/letta を開くと、README の冒頭で「Build stateful agents with memory that can learn and improve over time」と宣言したうえで、すぐに現在のソースの所在が示される。すなわち letta-ai/letta-code であり、そこに agent harness、interactive terminal UI、App Server、channels、そして desktop と web のアプリが使う runtime が入っていると書かれている。このリポジトリ自身は landing page として機能しており、過去の Letta V1 server のソースは archive ブランチに保存されている。つまりここで解かれている問題は「状態を持つエージェントをどう作るか」ではなく、「Letta という名前で配布されているものの現在の入口をどこに一本化するか」である。読者にとっての実務的な意味は大きい。GitHub で letta を検索してこのリポジトリに着地し、タグ v0.16.8 などを手がかりにソースを読み始めると、それは本体ではない。向かうべき先は letta-code と docs.letta.com である。

letta-code が担う範囲と、このリポジトリに残ったもの

README が letta-code の構成要素として挙げるのは、agent harness、interactive terminal UI、App Server、channels、そして desktop および web アプリが使う runtime である。ここから読み取れるのは、エージェントの実行を支える層と、それを人が触るための複数の入口が letta-code 側に集約されたという整理だ。一方、letta-ai/letta に残ったのは landing page としての README と、archive ブランチの歴史的ソース、そして既存のタグとリリースである。README はタグとリリースについて「remain available for reproducibility」と述べており、過去の成果物を再現する用途は想定されている。ただし再現できることと保守されることは別である。archive の記述は明快で、そのソースは unsupported、fix も security updates も受けない、production で使うべきではない、とされている。移転の告知と履歴の保存という二つの役割が、同じリポジトリに同居している状態だと理解しておくのが正確である。

導入は npm の一コマンドから始まる

README が示す導入手順は短い。npm install -g @letta-ai/letta-code でグローバルに入れ、letta を実行すると interactive terminal UI が起動する。ローカルまたはセルフホストでエージェントを動かす場合は letta server で App Server を起動する。この二つが README に載っているコマンドのすべてであり、設定キーについての記述はこの材料には含まれていない。API キーやモデルの指定方法、データの保存先、ポート番号といった項目は docs.letta.com 側で確認する必要がある。ここで注意したいのは、グローバルインストールされるパッケージ名が @letta-ai/letta-code であり、リポジトリ名 letta とは一致しない点だ。CI や手順書にリポジトリ名から類推したパッケージ名を書くと動かない。letta server を自前で動かす判断をするなら、まず letta-code 側の README とドキュメントで App Server の前提を読む順序になる。

入口が複数あることは、採用検討では判断材料になる

README は Letta に触れる経路として、desktop app（macOS、Windows、Linux）、ブラウザの chat.letta.com（モバイルを含む）、Slack、Telegram、Discord および custom channels、TypeScript アプリに組み込むための Letta Agent SDK、そして Letta Cloud を列挙している。Letta Cloud については「keeping agent memory, identity, and conversations available across computers」と説明されており、複数の端末をまたいで記憶と会話を保つ用途が想定されている。選択肢が多いこと自体は、状態を持つエージェントをどの面から使うかを選べるという意味で実用的だ。ただし採用検討の観点では、経路ごとに前提が異なる。SDK を TypeScript に組み込む場合と、letta server を自前ホストする場合と、Letta Cloud に寄せる場合では、記憶と会話がどこに置かれるかが変わる。この材料だけでは各経路のデータの置き場所までは分からない。そこは docs.letta.com で詰めるべき論点であり、ここで推測で埋めるべきではない。

V1 サーバを前提にした資産があるなら、このリポジトリは選ばない

最もはっきりした制約は archive ブランチの扱いである。README は、そこに含まれる retired Letta V1 API server について、サポートされず、修正もセキュリティ更新も受けず、production で使うべきではないと書いている。これは「古いが動く」ではなく「動かす前提を推奨していない」という表明である。したがって、V1 の API 形状に合わせて書いたクライアントや、V1 のサーバを前提に組んだデプロイ手順を持っているチームにとって、letta-ai/letta は移行先にならない。移行するなら letta-code 側の API と App Server に合わせ直す作業が発生する。逆に、これから状態を持つエージェントを新規に作り、V1 の経緯を知らない読者にとっては、archive ブランチは触る必要のないものだ。歴史的参照と再現性のために残されている、という位置づけ以上ではない。

LangGraph との違いは、状態をどこに置くかの設計にある

比較対象として分かりやすいのは LangGraph である。LangGraph はグラフとしてエージェントの制御フローを定義し、状態はそのグラフの実行に紐づけて扱う。開発者はノードとエッジを書き、チェックポイントの仕組みを自分で選ぶ。対して Letta は、README の言葉を借りれば stateful agents with memory であり、記憶を持つ主体としてエージェントを扱い、desktop app、chat.letta.com、各種チャネル、Agent SDK といった複数の入口から同じエージェントに触れる構成を取る。制御フローを組むか、記憶を持つ存在として運用するか、という出発点の違いである。どちらが優れているという話ではない。会話の履歴と identity を端末をまたいで保ちたいなら Letta の提示する形が噛み合い、処理の分岐を細かく設計したいならグラフを書く側の道具が向く。Letta が内部でどう記憶を保持し、いつ更新するのかという機構は、この材料からは分からない。README は「learn and improve over time」と述べるのみで、その実装には触れていない。

Apache-2.0 と、移転したリポジトリの保守コスト

ライセンスは Apache-2.0 である。特許許諾と帰属表示の条件を含む一般的な許容型ライセンスであり、改変物の配布時に何を残す必要があるかはライセンス全文で確認する項目になる。ここで注意すべきは、ライセンスが適用される対象の帰属がリポジトリの移転で見えにくくなる点だ。npm で入るのは @letta-ai/letta-code であり、このリポジトリのコードではない。社内のライセンス台帳や SBOM に「letta-ai/letta」と記録していると、実際に動いている成果物と一致しなくなる。保守コストの面では、このリポジトリに修正を期待する経路が存在しない。README は letta-code が actively developed だと述べ、こちらは landing page だと述べている。リリースは 0.16.6 から 0.16.8 まで 2026 年 3 月から 5 月にかけて刻まれているが、これはタグとリリースが再現性のために残されているという記述と整合する範囲の情報であり、このリポジトリのコードが更新され続けている証拠にはならない。依存先として追うべきは letta-code 側のリリースである。

編集部の結論

新規に状態を持つエージェントを組むなら、参照先は letta-ai/letta ではなく letta-ai/letta-code と docs.letta.com になる。npm install -g @letta-ai/letta-code で入るのはこのリポジトリのコードではないため、letta server を自前ホストする前に letta-code 側で App Server の運用要件とデータの保存先を確認してほしい。逆に、過去に Letta V1 API サーバで組んだ資産をそのまま動かしたい読者には向かない。archive ブランチは README が「unsupported, receives no fixes or security updates, and should not be used in production」と明記しており、互換性の調整に使える窓口はここにはない。採用の可否は、V1 の API 形状に依存していないかを最初に確認するところから決まる。

公式情報源

コミュニティノート