Letta-Agents auf einem OpenAI-kompatiblen Endpoint betreiben.

Kurzantwort: zwei Umgebungsvariablen auf dem Server.

Lettas dokumentierter Pfad für OpenAI-kompatible Endpoints ist Umgebungskonfiguration auf dem self-hosted Server: setze beim Serverstart OPENAI_API_BASE auf die Endpoint-URL und OPENAI_API_KEY auf deren Key, und Letta registriert die Modelle, die dieser Endpoint bedient. Für APIsRouter ist die Base https://api.apisrouter.com/v1. Es gibt kein Per-Agent-Base-URL-Feld in der UI; der Endpoint ist eine Server-Level-Entscheidung, weshalb die Umgebung die entscheidende Fläche ist. Eine Anforderung ist nicht verhandelbar und lohnt sich, vor allem anderen zu lesen: Lettas Docs erklären, dass OpenAI-kompatible Endpoints Function Calling unterstützen müssen, weil der Agent-Loop auf Tool-Calls aufbaut. Ein Endpoint, der nur einfache Chat Completions macht, kann keinen Letta-Agent überhaupt betreiben. Katalog-Modelle auf APIsRouter sprechen Standard-Tool-Calling über /v1/chat/completions, genau die Form, die Letta erwartet.

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

Warum Letta stärker auf sein Modell setzt als eine Chat-App.

Letta (letta-ai auf GitHub, rund 24.000 Stars) entstand aus dem MemGPT-Forschungsprojekt und baut zustandsbehaftete Agents: Agents mit persistentem, selbst editierendem Gedächtnis, das über Sessions hinweg erhalten bleibt. Während ein Chat-Client deine Nachricht schickt und die Antwort ausgibt, durchläuft ein Letta-Agent bei jeder Interaktion einen inneren Loop, denkt über das nach, was er weiß, ruft Memory-Tools auf, um sein eigenes Core Memory und Archival Storage zu lesen und umzuschreiben, und produziert erst dann eine Antwort. Diese Architektur hat zwei Konsequenzen für Endpoint-Routing. Erstens ist jeder Schritt des Loops ein Tool-Calling-Request, weshalb Function Calling eine harte Anforderung statt eines Nice-to-have ist; ein Modell, das bei Tool-Schemas stolpert, degradiert hier nicht sanft, es bricht die Fähigkeit des Agents, sich zu erinnern. Zweitens ist das Request-Volumen pro Interaktion höher, als das Konversations-Transkript suggeriert, weil Memory-Management neben jeder sichtbaren Antwort feuert. Die Model-ID, die all das bedient, ist gegenüber dem Endpoint ein reiner String, sodass mit einem Multi-Vendor-Gateway hinter OPENAI_API_BASE eine Claude-ID den Agent-Loop betreiben kann, während eine schnelle ID leichtere Agents auf demselben Server bedient, jeder über sein Handle adressiert.

Der ehrliche Support-Status, direkt von Upstream.

Lettas eigene Dokumentation sagt, OpenAI-Proxy-Endpoints seien nicht offiziell unterstützt und man werde vermutlich auf Fehler stoßen, und empfiehlt stattdessen direkte Provider-Verbindungen. Diese Warnung verdient es, zitiert statt begraben zu werden, weil die meisten Seiten zu diesem Thema so tun, als existiere sie nicht. Was das praktisch bedeutet, ist enger, als es klingt: Letta testet gegen First-Party-APIs, und ein Endpoint, der von OpenAI-Semantik abweicht, besonders bei Tool-Calling, produziert Fehler, die Upstream nicht priorisieren wird. Ein Endpoint, der die Spezifikation echt implementiert, Tool-Calls eingeschlossen, läuft problemlos, und genau das ist die Kompatibilitätslatte, an der ein Gateway steht oder fällt. Die Support-Historie hatte auch einen echten Bug, den man kennen sollte. Bis Anfang 2026 wurden über OPENAI_API_BASE registrierte Modelle automatisch mit einem openai-proxy-Provider-Präfix versehen, während die Agent-Erstellung gegen eine kürzere Liste akzeptierter Präfixe validierte, sodass Proxy-Modelle sich registrierten, aber nicht zur Agent-Erstellung genutzt werden konnten. Das Issue wurde im Januar 2026 mit einem Fix geschlossen; betreibst du einen gepinnten älteren Server und die Agent-Erstellung lehnt Modelle ab, die der Server eindeutig listet, ist genau das die Ursache, und ein Upgrade ist die Lösung. Noch ein bewegliches Ziel: Lettas Produktoberfläche hat sich verschoben, und die Docs lenken aktuell neue Nutzer zu neueren Deployment-Modi, während sie festhalten, dass das klassische Docker-Image nicht mehr die aktiv gepflegte Fläche ist. Die Umgebungsvariablen oben sind der dokumentierte Mechanismus für den self-hosted Server; prüfe die aktuellen Docs, welches Server-Artefakt Upstream in der Woche empfiehlt, in der du deployst.

# 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

Modelle für zustandsbehaftete Agents wählen.

Die Bewertung, die zählt, ist Loop-Treue: erstelle einen Test-Agent, führ ein Gespräch, das Memory-Updates erzwingt, und lies dann das Core Memory des Agents und verifiziere, dass es sich tatsächlich geändert hat. Ein Modell kann charmante Antworten schreiben und trotzdem am Memory-Vertrag scheitern, und nur der Loop-Test erwischt das.

• Memory-Editing ist strukturierte Tool-Arbeit. claude-sonnet-4-6 und gpt-5.5 beherrschen den Rewrite-your-own-memory-Loop verlässlich, die Kernkompetenz, die ein Letta-Agent braucht.
• Langlebige Agents akkumulieren Kontext. Modelle, die tief im Context-Window kohärent bleiben, zählen hier mehr als im zustandslosen Chat, wo sich claude-opus-4-7 seinen Platz für High-Stakes-Assistants verdient.
• Flotten leichtgewichtiger Agents, einer pro Nutzer oder Task, sind Volumen-Workloads. claude-haiku-4-5-20251001 hält die Kosten pro Agent flach und macht dabei weiterhin kompetente Tool-Calls.
• deepseek-v4-pro lohnt einen Test für Agents, die Reasoning mit zweisprachigem Traffic mischen; die Tool-Calling-Anforderung ist das Nadelöhr, teste also den Loop, nicht nur die Prosa.
• Was auch immer du wählst, wähle pro Agent. Der Server registriert den ganzen Katalog, und jeder Agent bindet an ein Handle, sodass ein Memory-lastiger Concierge und ein Wegwerf-Task-Agent nebeneinander verschiedene IDs laufen lassen können.

Nutzungsbasiert · unter offiziellem Preis

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

Fehlerbilder speziell für Letta.

Eine Agent-Erstellung, die ein vom Server gelistetes Modell ablehnt, ist der historische Präfix-Bug. Über einen Proxy registrierte Modelle trugen ein Provider-Präfix, das die Agent-Erstellung auf betroffenen Versionen ablehnte. Der Fix landete im Januar 2026; auf aktuellen Releases ist das in der Modell-Liste gezeigte Handle das, das funktioniert. Bist du an ein älteres Image gepinnt, ist das der stärkste einzelne Grund, zuerst zu upgraden, bevor du sonst etwas debuggst. Ein Agent, der antwortet, sich aber nie erinnert, ist ein Tool-Calling-Fehler. Entweder implementiert der Endpoint Function Calling nicht, oder das Modell hinter der ID handhabt Tool-Schemas schlecht. Das Symptom sind Konversationen, die funktionieren, während sich das Core Memory nie aktualisiert. Teste denselben Agent auf claude-sonnet-4-6, um Endpoint-Probleme von Modell-Problemen zu trennen. Umgebungsvariablen am falschen Ort gesetzt sind der Docker-Klassiker: ein in deiner Shell exportiertes OPENAI_API_BASE bewirkt nichts für einen Container, der ohne die -e-Flags gestartet wurde. Die Variablen müssen den Server-Prozess selbst erreichen. Und weil der Endpoint Server-Level ist, denk an den Wirkungsradius: ein geändertes OPENAI_API_BASE bewegt jeden Agent auf diesem Server. Es gibt keinen Per-Agent-Endpoint-Override, also ist ein Server pro Gateway die saubere Topologie, mit Modellwahl pro Agent als Differenzierung.

Wer Letta über ein Gateway routet.

• Builder persistenter Assistants, die Claude-Qualität im Memory-Editing wollen, ohne für jedes getestete Modell ein separates Vendor-Konto, einen Key und eine Billing-Fläche.
• Teams, die Agent-Flotten betreiben, wo jeder Nutzer einen Agent bekommt, und Nutzungstracking pro Key die realen Kosten der Memory-Schicht in einen lesbaren Report verwandelt.
• Forscher, die vergleichen, wie Modelle selbst editierendes Gedächtnis handhaben, wo jeder Kandidat ein Handle-Wechsel an einem Test-Agent ist, keine Provider-Migration.
• Self-Hoster in Umgebungen, wo direkter Vendor-API-Zugang blockiert ist und ein einzelner Gateway-Endpoint das ist, was die Netzwerkrichtlinie erlaubt.
• Entwickler ohne Zugang zum Billing eines bestimmten Vendors. Guthabenbasierter Zugang ohne Kartenpflicht entfernt die Sign-up-Abhängigkeit pro Provider.

Endpoint verifizieren und den ersten Agent debuggen.

Verifiziere das Gateway vor dem Server: liste Modelle mit dem Key, und führ eine Chat Completion mit angehängter Tool-Definition aus, weil Tool-Calling die Fähigkeit ist, auf die Letta tatsächlich angewiesen ist. Funktioniert der Tool-Call-Round-Trip in curl, ist die Endpoint-Hälfte bewiesen. Starte dann den Server mit den zwei Variablen und lies seine Modell-Liste. Erscheinen dort Modelle, beweist das die Registrierung; ein erfolgreich aus einem gelisteten Handle erstellter Agent beweist den Präfix-Pfad; eine Konversation, die das Core Memory aktualisiert, beweist den Loop End-to-End. Debugge in dieser Reihenfolge, weil jede Stufe ein eigenes Fehlerset hat: die Env-Vars, die Server-Version und die Tool-Kompetenz des Modells. Sobald Agents laufen, zeigt die APIsRouter-Konsole Modell, Token-Zahlen und Ausgaben pro Anfrage. Zustandsbehaftete Agents rechnen pro Interaktion mehr ab, als ihre Transkripte suggerieren, da Memory-Management hinter jeder Antwort läuft, und das Nutzungslog ist, wo dieser versteckte Multiplikator zu einer budgetierbaren Zahl wird.

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"}}}}}]}'

Häufige Fragen