Draai Letta-agents op een OpenAI-compatibel endpoint.

Snel antwoord: twee omgevingsvariabelen op de server.

Het gedocumenteerde pad van Letta voor OpenAI-compatibele endpoints is omgevingsconfiguratie op de self-hosted server: zet OPENAI_API_BASE op de endpoint-URL en OPENAI_API_KEY op de bijbehorende sleutel bij het starten van de server, en Letta registreert de modellen die dat endpoint bedient. Voor APIsRouter is de base https://api.apisrouter.com/v1. Er is geen base-URL-veld per agent in de UI; het endpoint is een beslissing op serverniveau, en daarom is de omgeving het oppervlak dat ertoe doet. Eén vereiste staat niet ter discussie en is het waard om als eerste te lezen: de documentatie van Letta stelt dat OpenAI-compatibele endpoints function calling moeten ondersteunen, omdat de agentlus op tool-aanroepen is gebouwd. Een endpoint dat alleen platte chat completions doet, kan helemaal geen Letta-agent draaien. Catalogusmodellen op APIsRouter spreken standaard tool calling over /v1/chat/completions, precies de vorm die Letta verwacht.

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

Waarom Letta zwaarder op zijn model leunt dan een chat-app.

Letta (letta-ai op GitHub, ruim 24K sterren) groeide uit het MemGPT-onderzoeksproject en bouwt stateful agents: agents met persistent, zelfbewerkend geheugen dat sessies overleeft. Waar een chatclient je bericht verstuurt en het antwoord print, draait een Letta-agent bij elke interactie een innerlijke lus, redeneert over wat het weet, roept geheugentools aan om zijn eigen kerngeheugen en archiefopslag te lezen en te herschrijven, en produceert pas dan een antwoord. Die architectuur heeft twee gevolgen voor endpointroutering. Ten eerste is elke stap van de lus een tool-aanroep, en daarom is function calling een harde vereiste in plaats van een leuke bijkomstigheid; een model dat tool-schema's verknoeit, degradeert hier niet gracieus, het breekt het vermogen van de agent om te onthouden. Ten tweede is het verzoeksvolume per interactie hoger dan het gesprekstranscript suggereert, omdat geheugenbeheer meelooft naast het zichtbare antwoord. Het model-ID dat dit alles bedient is een platte string naar het endpoint, dus met een multi-vendor gateway achter OPENAI_API_BASE kan een Claude-ID de agentlus draaien terwijl een snel ID lichtere agents bedient op dezelfde server, elk aangesproken via zijn handle.

De eerlijke ondersteuningsstatus, rechtstreeks van upstream.

De eigen documentatie van Letta zegt dat OpenAI-proxy-endpoints niet officieel worden ondersteund en dat je waarschijnlijk fouten tegenkomt, en raadt directe providerverbindingen aan. Die waarschuwing verdient het om geciteerd te worden in plaats van begraven, want de meeste pagina's over dit onderwerp doen alsof ze niet bestaat. Wat het in de praktijk betekent, is smaller dan het klinkt: Letta test tegen first-party API's, en een endpoint dat afwijkt van OpenAI-semantiek, vooral rond tool calling, produceert fouten waar upstream geen prioriteit aan geeft. Een endpoint dat de spec daadwerkelijk implementeert, tool calls inbegrepen, draait prima, en dat is precies de compatibiliteitslat waar een gateway op leeft of sterft. De ondersteuningsgeschiedenis had ook één echte bug die het waard is om te kennen. Tot begin 2026 werden modellen geregistreerd via OPENAI_API_BASE automatisch voorzien van een openai-proxy-providervoorvoegsel, terwijl agentcreatie valideerde tegen een kortere lijst van geaccepteerde voorvoegsels, waardoor proxymodellen wel registreerden maar niet konden worden gebruikt om agents aan te maken. Het probleem werd gesloten met een fix in januari 2026; als je een vastgepinde oudere server draait en agentcreatie modellen afwijst die de server duidelijk vermeldt, is die mismatch wat je raakt, en upgraden is de oplossing. Nog een bewegend doelwit: het productoppervlak van Letta is aan het verschuiven, en de documentatie stuurt nieuwe gebruikers momenteel naar nieuwere deploymentmodi terwijl wordt opgemerkt dat de klassieke Docker-image niet langer het actief onderhouden oppervlak is. De omgevingsvariabelen hierboven zijn het gedocumenteerde mechanisme voor de self-hosted server; controleer de huidige documentatie voor welk server-artefact upstream aanraadt in de week dat je deployt.

# 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

Modellen kiezen voor stateful agents.

De evaluatie die ertoe doet is lustrouw: maak een testagent, voer een gesprek dat geheugenupdates afdwingt, en lees dan het kerngeheugen van de agent om te bevestigen dat het daadwerkelijk is veranderd. Een model kan charmante antwoorden schrijven en toch falen op het geheugencontract, en alleen de lustest vangt dat.

• Geheugenbewerking is gestructureerd tool-werk. claude-sonnet-4-6 en gpt-5.5 behandelen de rewrite-your-own-memory-lus betrouwbaar, de kerncompetentie die een Letta-agent nodig heeft.
• Langdurige agents stapelen context op. Modellen die diep in een contextvenster coherent blijven, doen er hier meer toe dan bij stateless chat, waar claude-opus-4-7 zijn plek verdient voor high-stakes assistenten.
• Vloten van lichte agents, één per gebruiker of per taak, zijn volumewerklasten. claude-haiku-4-5-20251001 houdt de kosten per agent vlak terwijl het nog steeds competente tool-aanroepen doet.
• deepseek-v4-pro is het waard om te testen voor agents die redeneren mixen met tweetalig verkeer; de tool-callingvereiste is de poort, dus test de lus, niet alleen het proza.
• Wat je ook kiest, kies per agent. De server registreert de hele catalogus, en elke agent bindt aan een handle, dus een geheugenzware concierge en een wegwerpbare taakagent kunnen naast elkaar draaien met verschillende ID's.

Betaal naar gebruik · onder officiële prijzen

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

Faalmodi specifiek voor Letta.

Agentcreatie die een model afwijst dat de server vermeldt, is de historische voorvoegselbug. Modellen geregistreerd via een proxy droegen een providervoorvoegsel dat agentcreatie op getroffen versies weigerde te accepteren. De fix landde in januari 2026; op huidige releases is de handle in de modellijst de handle die werkt. Als je vastzit op een oudere image, is dit de sterkste enkele reden om te upgraden voordat je iets anders debugt. Een agent die antwoordt maar nooit onthoudt, is een tool-callingfout. Ofwel implementeert het endpoint geen function calling, ofwel behandelt het model achter het ID tool-schema's slecht. Het symptoom is gesprekken die werken terwijl het kerngeheugen nooit bijwerkt. Test dezelfde agent op claude-sonnet-4-6 om endpointproblemen van modelproblemen te scheiden. Omgevingsvariabelen die op de verkeerde plek zijn gezet, zijn de Docker-klassieker: OPENAI_API_BASE geëxporteerd in je shell doet niets voor een container die zonder de -e-vlaggen is gestart. De variabelen moeten het serverproces zelf bereiken. En omdat het endpoint op serverniveau zit, onthoud de impactradius: het wijzigen van OPENAI_API_BASE verplaatst elke agent op die server. Er is geen override per agent, dus één server per gateway is de schone topologie, met modelkeuze per agent als differentiator.

Wie routeert Letta via een gateway.

• Bouwers van persistente assistenten die Claude-kwaliteit geheugenbewerking willen zonder een apart leveranciersaccount, sleutel en factureringsoppervlak voor elk model dat ze proberen.
• Teams die agentvloten draaien waar elke gebruiker een agent krijgt, en waar meting per sleutel de echte kosten van de geheugenlaag omzet in een leesbaar rapport.
• Onderzoekers die vergelijken hoe modellen omgaan met zelfbewerkend geheugen, waar elke kandidaat een handle-wijziging is op een testagent in plaats van een providermigratie.
• Self-hosters in omgevingen waar directe leveranciers-API-toegang is geblokkeerd en één gateway-endpoint is wat het netwerkbeleid toelaat.
• Developers zonder toegang tot de facturering van een bepaalde leverancier. Toegang op basis van opwaarderen zonder kaartvereiste verwijdert de aanmeldingsafhankelijkheid per provider.

Verifieer het endpoint en debug de eerste agent.

Verifieer de gateway voordat de server: lijst modellen op met de sleutel, en draai één chat completion met een gekoppelde tool-definitie, want tool calling is de capaciteit waar Letta daadwerkelijk van afhangt. Als de tool-call-heenreis in curl werkt, is de endpoint-helft bewezen. Start dan de server met de twee variabelen en lees zijn modellijst. Modellen die daar verschijnen bewijzen registratie; een agent succesvol aangemaakt vanuit een vermelde handle bewijst het voorvoegselpad; een gesprek dat het kerngeheugen bijwerkt bewijst de lus van begin tot eind. Debug in die volgorde, want elke fase heeft een eigen faalset: respectievelijk de omgevingsvariabelen, de serverversie, en de tool-competentie van het model. Zodra agents draaien, toont de APIsRouter-console model per verzoek, tokenaantallen en uitgaven. Stateful agents factureren meer per interactie dan hun transcripten suggereren, aangezien geheugenbeheer achter elk antwoord meeloopt, en het gebruikslogboek is waar die verborgen vermenigvuldiger een getal wordt dat je kunt budgetteren.

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

Veelgestelde vragen