Patakbuhin ang mga agent ng Letta sa isang OpenAI-compatible endpoint.

Mabilisang sagot: dalawang environment variable sa server.

Ang naka-document na path ng Letta para sa mga OpenAI-compatible na endpoint ay environment configuration sa self-hosted na server: itakda ang OPENAI_API_BASE sa URL ng endpoint at OPENAI_API_KEY sa key nito kapag sinisimulan ang server, at ire-register ng Letta ang mga model na si-serve ng endpoint na iyon. Para sa APIsRouter, ang base ay https://api.apisrouter.com/v1. Walang per-agent na base-URL field sa UI; server-level na desisyon ang endpoint, kaya't ang environment ang surface na mahalaga. Isang requirement na hindi puwedeng ipagpaliban at karapat-dapat basahin bago ang lahat: nakasaad sa docs ng Letta na dapat suportahan ng mga OpenAI-compatible na endpoint ang function calling, dahil ang agent loop ay binuo sa tool calls. Ang isang endpoint na plain chat completions lamang ang kaya ay hindi kayang magpatakbo ng agent ng Letta kahit kaunti. Nagsasalita ang mga model ng katalogo sa APIsRouter ng standard na tool calling sa pamamagitan ng /v1/chat/completions, na siyang hugis na inaasahan ng 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

Bakit mas umaasa ang Letta sa model nito kaysa sa isang chat app.

Ang Letta (letta-ai sa GitHub, humigit-kumulang 24K stars) ay lumago mula sa MemGPT research project at bumubuo ng stateful na mga agent: mga agent na may persistent, self-editing na memory na nananatili sa buong sesyon. Kung saan ipinapadala ng isang chat client ang mensahe mo at nilalathala ang sagot, nagpapatakbo ang isang agent ng Letta ng inner loop sa bawat interaksyon, nangangatwiran tungkol sa kung ano ang alam nito, tumatawag ng memory tools para basahin at muling isulat ang sarili nitong core memory at archival storage, at doon lamang gumagawa ng sagot. May dalawang bunga ang architecture na iyon para sa routing ng endpoint. Una, bawat hakbang ng loop ay isang tool-calling na request, kaya mahalaga ang function calling bilang hard requirement sa halip na nice-to-have; ang isang model na napapahamak sa tool schemas ay hindi tahimik na bumababa dito, sinisira nito ang kakayahan ng agent na mag-alala. Ikalawa, mas mataas ang request volume per interaksyon kaysa sa iminumungkahi ng transcript ng usapan, dahil tumatakbo ang memory management kasama ang bawat sagot na nakikita. Isang plain string sa endpoint ang model id na naglilingkod sa lahat ng ito, kaya sa isang multi-vendor gateway sa likod ng OPENAI_API_BASE, maaaring tumakbo ang agent loop gamit ang isang id ng Claude habang naglilingkod ang mas mabilis na id sa mas magaan na agents sa parehong server, bawat isa tinatawag sa sariling handle.

Ang tapat na estado ng suporta, direkta mula sa upstream.

Sinasabi ng sariling dokumentasyon ng Letta na hindi opisyal na sinusuportahan ang mga OpenAI proxy endpoint at maaari kang makatagpo ng mga error, na inirerekomenda ang direktang koneksyon sa provider. Karapat-dapat sipiin ang babalang iyon sa halip na ilibing ito, dahil karamihan sa mga pahina tungkol sa paksang ito ay nagkukunwaring wala ito. Ang ibig sabihin nito sa praktika ay mas makitid kaysa sa tunog nito: sinusubukan ng Letta laban sa mga first-party API, at ang isang endpoint na lumihis sa OpenAI semantics, lalo na sa tool calling, ay gumagawa ng mga kabiguan na hindi bibigyang-priyoridad ng upstream. Ang isang endpoint na tunay na nagpapatupad ng spec, kasama ang tool calls, ay tumatakbo nang maayos, at eksakto iyan ang compatibility bar na kinabubuhayan o kinamamatayan ng isang gateway. May isa ring tunay na bug ang kasaysayan ng suporta na karapat-dapat malaman. Hanggang unang bahagi ng 2026, ang mga model na na-register sa pamamagitan ng OPENAI_API_BASE ay awtomatikong pinauna ng openai-proxy na provider prefix habang ang agent creation ay vine-validate laban sa mas maikling listahan ng tinatanggap na prefix, kaya nagre-register ang mga proxy model pero hindi magamit para gumawa ng agents. Isinara ang isyu na may fix noong Enero 2026; kung nakapin ka sa isang mas lumang server, ang hindi pagkakatugmang iyon ang tinatamaan mo, at ang pag-upgrade ang solusyon. Isa pang gumagalaw na target: nagbabago ang product surface ng Letta, at kasalukuyang idinidirekta ng docs nito ang mga bagong user sa mas bagong deployment modes habang binabanggit na ang classic na Docker image ay hindi na ang aktibong pinapanatiling surface. Ang mga environment variable sa itaas ang naka-document na mekanismo para sa self-hosted na server; suriin ang kasalukuyang docs para sa deployment mode na inirerekomenda ng upstream sa linggong i-deploy mo ito.

# 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

Pagpili ng mga model para sa stateful na mga agent.

Ang pagsusuring mahalaga ay loop fidelity: gumawa ng test agent, magkaroon ng usapang pumipilit ng mga memory update, pagkatapos ay basahin ang core memory ng agent at kumpirmahin na talagang nagbago ito. Maaaring makagawa ang isang model ng kaakit-akit na sagot at bumagsak pa rin sa memory contract, at ang loop test lamang ang nakakahuli niyan.

• Structured tool work ang pag-edit ng memory. Maaasahang hinahawakan ng claude-sonnet-4-6 at gpt-5.5 ang loop ng pagsulat-muli-sa-sariling-memory, na siyang core competence na kailangan ng isang agent ng Letta.
• Nag-iipon ng context ang mga agent na matagal nang tumatakbo. Mas mahalaga rito kaysa sa stateless na chat ang mga model na nananatiling coherent nang malalim sa isang context window, kung saan kinikita ng claude-opus-4-7 ang slot nito para sa mga high-stakes na assistant.
• Volume workloads ang mga fleet ng magaan na agents, isa per user o per task. Pinapanatili ng claude-haiku-4-5-20251001 na patag ang gastos per agent habang gumagawa pa rin ng maasahang tool calls.
• Sulit subukan ang deepseek-v4-pro para sa mga agent na naghahalo ng reasoning at bilingual na traffic; ang requirement ng tool-calling ang gate, kaya subukan ang loop, hindi lamang ang prosa.
• Anuman ang pinili mo, piliin per agent. Ire-register ng server ang buong katalogo, at nakadikit ang bawat agent sa isang handle, kaya maaaring tumakbo nang magkatabi ang isang memory-heavy na concierge at isang disposable na task agent gamit ang iba't ibang id.

Pay-as-you-go · mas mababa sa opisyal na presyo

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

Mga failure mode na specific sa Letta.

Ang agent creation na tumatanggi sa isang model na nakalista ng server ay ang makasaysayang prefix bug. Nagdadala ng provider prefix ang mga model na na-register sa pamamagitan ng isang proxy na tinanggihan ng agent creation sa mga apektadong bersyon. Dumating ang fix noong Enero 2026; sa kasalukuyang mga release, ang handle na ipinapakita sa model listing ang handle na gumagana. Kung nakapin ka sa mas lumang image, ito ang pinakamalakas na dahilan para mag-upgrade bago mag-debug ng iba pa. Ang isang agent na sumasagot pero kailanman hindi nag-aalala ay isang kabiguan sa tool-calling. Alinman sa hindi nagpapatupad ang endpoint ng function calling, o hindi maayos na hinahawakan ng model sa likod ng id ang mga tool schema. Ang sintomas ay mga usapang gumagana habang kailanman hindi nagbabago ang core memory. Subukan ang parehong agent sa claude-sonnet-4-6 para ihiwalay ang mga problema sa endpoint mula sa mga problema sa model. Ang mga environment variable na itinakda sa maling lugar ay ang klasikong problema sa Docker: walang ginagawa ang OPENAI_API_BASE na na-export sa shell mo para sa isang container na sinimulan nang walang mga -e flags. Dapat maabot ng mga variable ang server process mismo. At dahil server-level ang endpoint, tandaan ang saklaw: ginagalaw ng pagpapalit ng OPENAI_API_BASE ang bawat agent sa server na iyon. Walang per-agent na endpoint override, kaya isang server per gateway ang malinis na topology, na may pagpili ng model per agent bilang nagbibigay ng pagkakaiba.

Sino ang nagru-route ng Letta sa pamamagitan ng isang gateway.

• Mga builder ng persistent na assistant na gustong makuha ang Claude-quality na memory editing nang walang hiwalay na vendor account, key, at billing surface para sa bawat model na sinusubukan nila.
• Mga team na nagpapatakbo ng agent fleets kung saan bawat user ay may agent, at ginagawang isang mababasang report ng per-key usage tracking ang tunay na gastos ng memory layer.
• Mga mananaliksik na naghahambing kung paano hinahawakan ng mga model ang self-editing na memory, kung saan ang bawat kandidato ay isang pagpapalit ng handle sa isang test agent sa halip na paglipat ng provider.
• Mga self-hoster sa mga kapaligiran kung saan hinaharangan ang direktang vendor API access at ang isang gateway endpoint lamang ang pinapayagan ng network policy.
• Mga developer na walang access sa billing ng isang partikular na vendor. Ang top-up based na access na walang kailangang card ay inaalis ang per-provider na sign-up dependency.

I-verify ang endpoint at i-debug ang unang agent.

I-verify muna ang gateway bago ang server: ilista ang mga model gamit ang key, at magpatakbo ng isang chat completion na may naka-attach na tool definition, dahil ang tool calling ang kakayahang talagang inaasahan ng Letta. Kung gumana ang tool-call round trip sa curl, napatunayan ang kalahati ng endpoint. Pagkatapos, simulan ang server gamit ang dalawang variable at basahin ang model listing nito. Pinapatunayan ng mga model na lumitaw doon ang pagpaparehistro; pinapatunayan ng isang agent na matagumpay na ginawa mula sa isang nakalistang handle ang prefix path; pinapatunayan ng isang usapang nag-a-update ng core memory ang loop mula umpisa hanggang dulo. Mag-debug sa order na iyon, dahil bawat yugto ay may iba't ibang set ng kabiguan: ang mga env var, ang bersyon ng server, at ang kakayahan sa tool ng model. Kapag tumatakbo na ang mga agent, ipinapakita ng APIsRouter console ang per-request na model, token counts, at gastos. Mas mabigat ang bill ng stateful na agents per interaksyon kaysa sa iminumungkahi ng transcripts nila, dahil tumatakbo ang memory management sa likod ng bawat sagot, at ang usage log ang lugar kung saan ang nakatagong multiplier na iyon ay nagiging numerong maaari mong pag-budget.

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

Mga madalas itanong