Letta のエージェントを、OpenAI 互換エンドポイントで動かす。

早わかり: サーバーに環境変数を2つ。

Letta がドキュメント化している OpenAI 互換エンドポイント向けの経路は、セルフホストサーバーでの環境設定です。サーバー起動時に OPENAI_API_BASE をエンドポイント URL に、OPENAI_API_KEY をそのキーに設定すれば、Letta はそのエンドポイントが提供するモデルを登録します。APIsRouter の場合、base は https://api.apisrouter.com/v1 です。UI にはエージェントごとの base-URL フィールドはありません。エンドポイントはサーバーレベルの決定であり、だからこそ環境変数が重要な面なのです。 1つの要件は交渉の余地がなく、他の何よりも先に読む価値があります。Letta のドキュメントは、エージェントループがツール呼び出しの上に構築されているため、OpenAI 互換エンドポイントは function calling に対応していなければならないと述べています。プレーンなチャット補完しかできないエンドポイントでは、Letta のエージェントはまったく動きません。APIsRouter のカタログモデルは、/v1/chat/completions で標準的なツール呼び出しを話し、それは Letta が期待する形です。

docker run \
  -v ~/.letta/.persist/pgdata:/var/lib/postgresql/data \
  -p 8283:8283 \
  -e OPENAI_API_KEY="$APISROUTER_API_KEY" \
  -e OPENAI_API_BASE="https://api.apisrouter.com/v1" \
  letta/letta:latest

Letta が、チャットアプリよりもモデルに強く依存する理由。

Letta(GitHub 上では letta-ai、スター数はおよそ24K)は、MemGPT の研究プロジェクトから生まれ、ステートフルなエージェントを構築します。セッションをまたいで存続する、永続的で自己編集可能なメモリを持つエージェントです。チャットクライアントがあなたのメッセージを送って返信を表示するだけなのに対し、Letta のエージェントはやり取りのたびに内部ループを実行し、自分が知っていることについて推論し、メモリツールを呼び出して自身のコアメモリとアーカイブストレージを読み書きし、そのうえで初めて応答を生成します。 このアーキテクチャは、エンドポイントのルーティングに2つの帰結をもたらします。第一に、ループのすべてのステップがツール呼び出しのリクエストであり、だからこそ function calling は「あれば良い」ではなく「必須」の要件です。ツールスキーマでつまずくモデルは、ここでは緩やかに劣化するのではなく、エージェントの記憶する能力そのものを壊します。第二に、やり取りあたりのリクエスト量は、会話の見た目のトランスクリプトが示唆するよりも多くなります。メモリ管理が、見える返信と並行して発火するからです。このすべてを支えるモデル id は、エンドポイントに対してはプレーンな文字列であるため、OPENAI_API_BASE の裏にマルチベンダーのゲートウェイがあれば、Claude の id がエージェントループを動かす一方、同じサーバー上で速い id が軽量なエージェントを提供し、それぞれがそのハンドルでアドレスされます。

正直なサポート状況、upstream そのままに。

Letta 自身のドキュメントは、OpenAI プロキシエンドポイントは公式にはサポートされておらず、エラーに遭遇する可能性が高いと述べ、代わりに直接プロバイダーに接続することを勧めています。この警告は、隠すのではなく引用に値します。このテーマに関するほとんどのページは、それが存在しないふりをしているからです。実際に意味することは、聞こえるほど広くはありません。Letta は自社製の API に対してテストしており、OpenAI のセマンティクスから逸脱するエンドポイント、特にツール呼び出し周りで逸脱するものは、upstream が優先して直さない失敗を生みます。仕様(ツール呼び出しを含む)を本当に実装しているエンドポイントは問題なく動作し、それこそが、ゲートウェイの生死を分ける互換性の基準です。 サポートの歴史には、知っておく価値のある本物のバグも1つありました。2026年初頭まで、OPENAI_API_BASE 経由で登録されたモデルは openai-proxy プロバイダーとして自動的にプレフィックスが付けられていましたが、エージェント作成は、受け付けるプレフィックスのより短いリストに対して検証していたため、プロキシのモデルは登録できてもエージェント作成には使えませんでした。この問題は2026年1月の修正でクローズされました。もし古いバージョンに固定したサーバーを運用していて、サーバーが明確に一覧しているモデルをエージェント作成が拒否する場合、あなたが直面しているのはこの不一致であり、アップグレードが解決策です。 もう一つ動いている的があります。Letta のプロダクト面は変化し続けており、そのドキュメントは現在、新規ユーザーを新しいデプロイモードへ誘導する一方で、古典的な Docker イメージはもはや積極的にメンテナンスされている面ではないと注記しています。上記の環境変数は、セルフホストサーバー向けのドキュメント記載済みの仕組みです。デプロイする週に upstream がどのサーバーアーティファクトを推奨しているか、現行のドキュメントを確認してください。

# after the server is up, list models Letta knows about
curl -s http://localhost:8283/v1/models/ | head -50
# use the handle exactly as listed when creating agents

ステートフルなエージェント向けのモデル選び。

重要な評価はループの忠実度です。テスト用のエージェントを作成し、メモリの更新を強制する会話を行い、そのエージェントのコアメモリを読んで、実際に変わったかどうかを確認してください。魅力的な返信を書くモデルでも、メモリの契約を満たせないことがあり、それを捉えられるのはループのテストだけです。

• メモリの編集は構造化されたツール作業です。claude-sonnet-4-6 と gpt-5.5 は、自身のメモリを書き換えるループを確実に扱い、それこそが Letta のエージェントに必要な中核能力です。
• 長寿命のエージェントは文脈を蓄積していきます。コンテキストウィンドウの深いところまで一貫性を保てるモデルは、ステートレスなチャットよりもここで重要になります。それが、重要な役割を担うアシスタント向けに claude-opus-4-7 がその座に値する理由です。
• ユーザーごと・タスクごとの軽量エージェントの群れは、ボリュームのあるワークロードです。claude-haiku-4-5-20251001 は、有能なツール呼び出しをこなしつつ、エージェントあたりのコストを一定に保ちます。
• 推論とバイリンガルなトラフィックを組み合わせるエージェントには、deepseek-v4-pro を試す価値があります。ツール呼び出しの要件がゲートとなるため、文章だけでなくループそのものをテストしてください。
• 何を選ぶにせよ、エージェントごとに選んでください。サーバーはカタログ全体を登録し、各エージェントはハンドルに紐づくため、メモリを多用するコンシェルジュと使い捨てのタスクエージェントが、異なる id で並んで動作できます。

従量課金 · 公式価格より安い

Selected models are priced below official list prices. Exact input, output, cache, and per-request prices are shown for each model.

Letta に特有の失敗パターン。

サーバーが一覧しているモデルをエージェント作成が拒否するのは、歴史的なプレフィックスのバグです。プロキシ経由で登録されたモデルはプロバイダーのプレフィックスを持っていましたが、影響を受けたバージョンではエージェント作成がそれを受け付けませんでした。修正は2026年1月に着地しており、現行リリースでは、モデル一覧に表示されるハンドルがそのまま使えるハンドルです。古いイメージに固定している場合、他の何をデバッグするよりも先にアップグレードする理由として、これが最も強力です。 返信はするのに何も記憶しないエージェントは、ツール呼び出しの失敗です。エンドポイントが function calling を実装していないか、その id の背後にあるモデルがツールスキーマをうまく扱えていません。症状としては、会話自体は機能するのにコアメモリが一切更新されない、というものです。同じエージェントを claude-sonnet-4-6 でテストして、エンドポイントの問題とモデルの問題を切り分けてください。 間違った場所に設定された環境変数は、Docker の定番の問題です。シェルで OPENAI_API_BASE を export しても、-e フラグなしで起動されたコンテナには何の効果もありません。変数はサーバープロセス自体に届かなければなりません。 そして、エンドポイントはサーバーレベルであるため、影響範囲を忘れないでください。OPENAI_API_BASE を変更すると、そのサーバー上のすべてのエージェントが動きます。エージェントごとのエンドポイントの上書きはないため、ゲートウェイごとにサーバーを1つ用意するのがきれいなトポロジーであり、差別化はエージェントごとのモデル選択で行います。

ゲートウェイ経由で Letta を使うのは誰か。

• 永続的なアシスタントを構築するビルダーで、試すモデルごとに別々のベンダーアカウント・キー・請求面を持つことなく、Claude 級のメモリ編集を求める人。
• ユーザーごとにエージェントを割り当てるエージェントの群れを運用するチームで、キーごとの利用状況トラッキングが、メモリ層の実際のコストを読めるレポートに変えてくれる人。
• モデルが自己編集メモリをどう扱うかを比較する研究者で、各候補が、プロバイダーの移行ではなく、テスト用エージェントのハンドル変更で済む人。
• 直接のベンダー API アクセスがブロックされ、ネットワークポリシーが許すのが単一のゲートウェイエンドポイントだけである環境のセルフホスター。
• 特定ベンダーの請求手段にアクセスできない開発者。チャージ制でカード不要のアクセスなら、プロバイダーごとのサインアップという依存を取り除けます。

エンドポイントを検証し、最初のエージェントをデバッグする。

サーバーより先にゲートウェイを検証してください。キーでモデルを一覧し、ツール定義を添えて1回チャット補完を実行します。ツール呼び出しこそが、Letta が実際に依存している能力だからです。curl でツール呼び出しの往復が動けば、エンドポイント側は証明済みです。 次に、2つの変数を使ってサーバーを起動し、そのモデル一覧を読んでください。そこにモデルが現れれば登録が証明され、一覧されたハンドルからエージェントを正常に作成できればプレフィックスの経路が証明され、コアメモリを更新する会話ができればループ全体が端から端まで証明されます。この順序でデバッグしてください。それぞれの段階が、環境変数・サーバーのバージョン・モデルのツール能力という、別々の失敗の集合に対応しているからです。 エージェントが動き始めたら、APIsRouter コンソールがリクエストごとのモデル、トークン数、支出を表示します。ステートフルなエージェントは、トランスクリプトが示唆するよりもやり取りあたりの請求が多くなります。すべての返信の裏でメモリ管理が動いているからです。利用ログこそが、その隠れた乗数を予算化できる数字に変える場所です。

curl -s https://api.apisrouter.com/v1/chat/completions \
  -H "Authorization: Bearer $APISROUTER_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"model":"claude-sonnet-4-6",
       "messages":[{"role":"user","content":"What is 2+3?"}],
       "tools":[{"type":"function","function":{
         "name":"calc","description":"add numbers",
         "parameters":{"type":"object","properties":{
           "a":{"type":"number"},"b":{"type":"number"}}}}}]}'

よくある質問