Letta agents को एक OpenAI-compatible endpoint पर चलाएं।

Quick answer: server पर दो environment variables।

OpenAI-compatible endpoints के लिए Letta का documented path self-hosted server पर environment configuration है: server शुरू करते समय OPENAI_API_BASE को endpoint URL पर और OPENAI_API_KEY को उसकी key पर set करें, और Letta उस endpoint के serve किए गए models register करता है। APIsRouter के लिए base https://api.apisrouter.com/v1 है। UI में per-agent base-URL field नहीं है; endpoint एक server-level decision है, यही वजह है कि environment वह surface है जो matter करता है। एक requirement non-negotiable है और बाकी सब से पहले पढ़ने लायक है: Letta के docs कहते हैं कि OpenAI-compatible endpoints को function calling support करना चाहिए, क्योंकि agent loop tool calls पर बना है। एक endpoint जो सिर्फ plain chat completions करता है वह Letta agent को बिल्कुल भी नहीं चला सकता। APIsRouter पर catalog models /v1/chat/completions पर standard tool calling बोलते हैं, जो वह shape है जो Letta expect करता है।

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 अपने model पर एक chat app से ज़्यादा क्यों भरोसा करता है।

Letta (GitHub पर letta-ai, लगभग 24K stars) MemGPT research project से निकला और stateful agents बनाता है: ऐसे agents जिनकी persistent, self-editing memory sessions के पार बची रहती है। जहां एक chat client आपका message भेजता है और reply print करता है, एक Letta agent हर interaction पर एक inner loop चलाता है, यह reasoning करते हुए कि वह क्या जानता है, अपनी core memory और archival storage पढ़ने व rewrite करने के लिए memory tools call करते हुए, और तभी एक response produce करते हुए। उस architecture के endpoint routing पर दो consequences हैं। पहला, loop का हर step एक tool-calling request है, यही वजह है कि function calling एक nice-to-have नहीं बल्कि hard requirement है; एक model जो tool schemas में गड़बड़ करता है वह यहां gracefully degrade नहीं होता, यह agent की याद रखने की ability को तोड़ देता है। दूसरा, प्रति interaction request volume conversation transcript से ज़्यादा है, क्योंकि memory management हर visible reply के साथ-साथ fire होती है। इस सबको serve करने वाली model id endpoint को एक plain string है, तो OPENAI_API_BASE के पीछे एक multi-vendor gateway के साथ, एक Claude id agent loop चला सकती है जबकि एक fast id same server पर lighter agents serve करती है, हर एक अपने handle से addressed।

Honest support state, सीधे upstream से।

Letta की अपनी documentation कहती है कि OpenAI proxy endpoints officially supported नहीं हैं और आप errors देख सकते हैं, direct provider connections recommend करते हुए। वह warning quote किए जाने लायक है दबाए जाने की बजाय, क्योंकि इस topic पर ज़्यादातर pages ऐसे pretend करते हैं जैसे यह exist ही नहीं करती। Practice में इसका मतलब जितना सुनने में लगता है उससे narrower है: Letta first-party APIs के against test करता है, और एक endpoint जो OpenAI semantics से deviate करता है, खासकर tool calling के around, ऐसी failures produce करता है जिन्हें upstream prioritize नहीं करेगा। एक endpoint जो genuinely spec implement करता है, tool calls शामिल, ठीक चलता है, और यही exactly वह compatibility bar है जिससे एक gateway जीता या मरता है। Support history में एक असली bug भी है जो जानने लायक है। 2026 की शुरुआत तक, OPENAI_API_BASE के through registered models को एक openai-proxy provider के तौर पर auto-prefixed किया जाता था जबकि agent creation accepted prefixes की एक shorter list के against validate करता था, तो proxy models register तो होते थे लेकिन agents बनाने के लिए इस्तेमाल नहीं हो पाते थे। January 2026 में एक fix के साथ issue close हुआ; अगर आप एक pinned older server चलाते हैं और agent creation ऐसे models reject करता है जो server स्पष्ट रूप से list करता है, तो यही mismatch है जो आपके साथ हो रहा है, और upgrade करना ही fix है। एक और moving target: Letta की product surface shift होती रही है, और इसके docs अभी नए users को नए deployment modes की तरफ steer करते हैं जबकि note करते हैं कि classic Docker image अब actively maintained surface नहीं है। ऊपर वाले environment variables self-hosted server के लिए documented mechanism हैं; जिस हफ्ते deploy करें उसमें current docs check करें कि upstream कौन-सा server artifact recommend करता है।

# 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

Stateful agents के लिए models चुनना।

जो evaluation matter करता है वह loop fidelity है: एक test agent बनाएं, एक ऐसी conversation करें जो memory updates को force करे, फिर agent की core memory पढ़ें और verify करें कि यह actually बदली। एक model charming replies लिख सकता है और फिर भी memory contract fail कर सकता है, और सिर्फ loop test यह पकड़ता है।

• Memory editing structured tool work है। claude-sonnet-4-6 और gpt-5.5 rewrite-your-own-memory loop को भरोसेमंद तरीके से handle करते हैं, जो एक Letta agent की core competence है।
• Long-lived agents context accumulate करते हैं। जो models context window में गहराई तक coherent रहते हैं वे यहां stateless chat से ज़्यादा matter करते हैं, यही वजह है कि high-stakes assistants के लिए claude-opus-4-7 अपनी slot कमाता है।
• Lightweight agents के fleets, per user या per task, volume workloads हैं। claude-haiku-4-5-20251001 competent tool calls करते हुए भी per-agent cost को flat रखता है।
• deepseek-v4-pro उन agents के लिए test करने लायक है जो reasoning को bilingual traffic के साथ mix करते हैं; tool-calling requirement gate है, तो सिर्फ prose नहीं loop test करें।
• जो भी चुनें, per agent चुनें। Server पूरा catalog register करता है, और हर agent एक handle से bind होता है, तो एक memory-heavy concierge और एक disposable task agent साथ-साथ अलग ids चला सकते हैं।

जितना उपयोग उतना भुगतान · आधिकारिक मूल्य से कम

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

Letta के लिए specific failure modes।

Agent creation का किसी ऐसे model को reject करना जो server list करता है, वही historical prefix bug है। एक proxy के through registered models एक provider prefix carry करते थे जिसे affected versions पर agent creation accept नहीं करता था। Fix January 2026 में आया; current releases पर model listing में दिखने वाला handle ही वह handle है जो काम करता है। अगर आप एक older image पर pinned हैं, कुछ और debug करने से पहले upgrade करने की यही सबसे मज़बूत वजह है। एक agent जो reply करता है लेकिन कभी याद नहीं रखता वह tool-calling failure है। या तो endpoint function calling implement नहीं करता, या id के पीछे वाला model tool schemas को खराब तरीके से handle करता है। Symptom ऐसी conversations हैं जो काम करती हैं जबकि core memory कभी update नहीं होती। Endpoint problems को model problems से अलग करने के लिए same agent को claude-sonnet-4-6 पर test करें। गलत जगह set किए गए environment variables Docker का classic है: आपके shell में export किया गया OPENAI_API_BASE बिना -e flags के शुरू किए गए एक container के लिए कुछ नहीं करता। Variables को server process तक ही पहुंचना चाहिए। और चूंकि endpoint server-level है, blast radius याद रखें: OPENAI_API_BASE बदलना उस server के हर agent को move करता है। कोई per-agent endpoint override नहीं है, तो per gateway एक server clean topology है, model choice per agent differentiation करते हुए।

कौन Letta को एक gateway के through route करता है।

• Persistent assistants बनाने वाले builders जो हर model try करने के लिए एक अलग vendor account, key, और billing surface के बिना Claude-quality memory editing चाहते हैं।
• Teams जो agent fleets चलाती हैं जहां हर user को एक agent मिलता है, और per-key usage tracking memory layer की असली cost को एक readable report में बदल देता है।
• Researchers जो compare करते हैं models self-editing memory कैसे handle करते हैं, जहां हर candidate provider migration नहीं बल्कि एक test agent पर handle change है।
• Self-hosters ऐसे environments में जहां direct vendor API access blocked है और network policy एक single gateway endpoint allow करती है।
• Developers जिनके पास किसी given vendor की billing तक access नहीं है। बिना card requirement वाला top-up based access per-provider sign-up dependency हटा देता है।

Endpoint verify करें और पहले agent को debug करें।

Server से पहले gateway verify करें: key से models list करें, और एक tool definition attached करके एक chat completion चलाएं, क्योंकि tool calling वही capability है जिस पर Letta actually depend करता है। अगर curl में tool-call round trip काम करे, तो endpoint वाला half proven है। फिर दोनों variables के साथ server शुरू करें और इसकी model listing पढ़ें। वहां दिखने वाले models registration साबित करते हैं; listed handle से successfully बनाया गया agent prefix path साबित करता है; core memory update करने वाली एक conversation पूरा loop end to end साबित करती है। उसी order में debug करें, क्योंकि हर stage का अपना distinct failure set है: क्रमशः env vars, server version, और model की tool competence। जब agents चलने लगें, APIsRouter console per-request model, token counts, और spend दिखाता है। Stateful agents transcripts के दिखाए जाने से ज़्यादा per interaction bill करते हैं, चूंकि memory management हर reply के पीछे चलती है, और usage log वह जगह है जहां वह छुपा हुआ multiplier एक ऐसा number बनता है जिसे आप 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"}}}}}]}'

अक्सर पूछे जाने वाले प्रश्न