mem0 को एक custom OpenAI-compatible base URL के against चलाएं।

Quick answer: llm block के अंदर एक config key।

mem0 का OpenAI LLM provider अपना endpoint config पहले, environment दूसरे, default तीसरे के हिसाब से resolve करता है: self.config.openai_base_url, फिर OPENAI_BASE_URL environment variable, फिर https://api.openai.com/v1। तो सबसे clean override llm config dict में एक key है: openai_base_url को https://api.apisrouter.com/v1 set करें, इसके साथ api_key set करें (या OPENAI_API_KEY export करें), और हर memory-extraction call gateway के through route होती है। यह upstream mem0 behavior है, mem0/llms/openai.py में पढ़ने लायक, कोई fork नहीं। TypeScript SDK camelCase में वही pair expose करता है: openaiBaseUrl और apiKey। Config dict में values environment variables को override करती हैं, जो defaults को override करती हैं, तो एक config-level base URL उन machines पर भी जीतता है जहां OPENAI_BASE_URL कहीं और point करता है।

config = {
    "llm": {
        "provider": "openai",
        "config": {
            "model": "claude-sonnet-4-6",
            "openai_base_url": "https://api.apisrouter.com/v1",
            "api_key": os.environ["APISROUTER_API_KEY"],
        },
    }
}

mem0 अपने LLM से असल में क्या करता है।

mem0 (GitHub पर mem0ai, लगभग 61K stars) AI agents के लिए एक memory layer है। हर add() call एक pipeline चलाता है: LLM नए conversation turns पढ़ता है, candidate memories extract करता है, उन्हें पहले से stored चीज़ों के against compare करता है, और प्रति memory decide करता है कि add, update, delete, या skip करना है। यह असली reasoning work है, और यह हर write पर होता है, तो जब कोई इसे एक production agent पर bolt करता है तो LLM slot ज़्यादातर लोगों के expect करने से कहीं ज़्यादा fire होता है। Retrieval दूसरा आधा हिस्सा है, और यह LLM का इस्तेमाल बिल्कुल नहीं करता: search() query को embed करता है और store के against vector similarity चलाता है। दो अलग clients, दो अलग models, दो अलग blocks में configured (llm और embedder)। किसी भी चीज़ को reroute करने से पहले समझने वाली सबसे important बात यही split है, क्योंकि इसका मतलब है आप extraction workload को एक multi-vendor gateway पर move कर सकते हैं जबकि embedder अपना existing provider और index छुए बिना रहता है। Config में provider "openai" ही रहता है; mem0 model field को /v1/chat/completions पर एक plain string के तौर पर pass through करता है। जब openai_base_url के पीछे वाला endpoint कई vendors serve करता है, वह string एक Claude, GPT, DeepSeek, या GLM id हो सकती है, और extraction model swap करना एक provider migration की बजाय एक one-line config change बन जाता है।

पूरा setup: config dict या environment variable।

Config-dict path precise है: यह सिर्फ LLM move करता है। Dict बनाएं, Memory.from_config को दें, और memory API सामान्य रूप से इस्तेमाल करें। api_key field gateway key को आपकी vector-store और embedder settings से पूरी तरह बाहर रखती है। Environment path भी exist करता है: जब config key absent हो तो mem0 की OpenAI classes OPENAI_BASE_URL पढ़ती हैं। यह एक exported variable और zero code changes है, लेकिन scope नोट करें: embedder की OpenAI class same variables पढ़ती है (यह पुराने OPENAI_API_BASE नाम को भी मानती है, जिसे LLM class नहीं मानती)। OPENAI_BASE_URL export करें और आपने दोनों components move कर दिए, जो सही तभी है जब endpoint आपका embedding model भी serve करे। शक होने पर, config dict को prefer करें और environment को अकेला छोड़ दें।

import os
from mem0 import Memory

config = {
    "llm": {
        "provider": "openai",
        "config": {
            "model": "claude-sonnet-4-6",   # any catalog id
            "openai_base_url": "https://api.apisrouter.com/v1",
            "api_key": os.environ["APISROUTER_API_KEY"],
            "temperature": 0.1,
        },
    },
    # embedder block unchanged: keeps its own provider and key
}

m = Memory.from_config(config)
m.add("I prefer window seats and vegetarian meals.", user_id="alice")
print(m.search("seat preference?", user_id="alice"))

Extraction model चुनना।

Practical loop: अपना embedder fixed रखें, same conversation fixtures को दो-तीन extraction models से चलाएं, और stored memories diff करें। एक endpoint के पीछे वह comparison per candidate एक config-string edit है, और per-key usage log आपके लिए हर candidate के run की price करता है।

• Extraction quality ही memory quality है। LLM decide करता है क्या याद रखने लायक है और क्या नई information पुरानी से contradict करती है; जो model एक update miss करता है वह हर आने वाले session के लिए retrieval पॉल्यूट कर देता है। claude-sonnet-4-6 और gpt-5.5 इस trade-off का reliable middle हैं।
• Volume हर write पर है। हर exchange के बाद add() call करने वाला एक chat product extraction को रोज़ाना हज़ारों बार चलाता है, यहीं claude-haiku-4-5-20251001 या deepseek-v4-flash जैसी fast id memory layer को token bill पर हावी होने से रोकती है।
• Contradiction-heavy domains (preferences जो बदलती हैं, facts जो expire होते हैं) add() पर एक stronger model से फायदा उठाते हैं चाहे प्रति call ज़्यादा खर्च हो, क्योंकि एक गलत update decision बाद में detect करना महंगा है।
• Temperature कम रहनी चाहिए। Extraction एक structured-decision task है, creative writing नहीं; mem0 same config block में temperature expose करता है, और लगभग 0.1 add/update/delete decisions को consistent रखता है।

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

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

mem0 के लिए specific failure modes।

एक बचा हुआ OPENROUTER_API_KEY routing hijack करता है। mem0 की OpenAI LLM class उस variable को special-case करती है: जब यह set होता है, class OpenRouter के endpoint पर switch करती है और आपके intent को ignore करती है। अगर requests आपकी configured base URL तक नहीं पहुंच रहीं, पहले यह variable check करें और unset करें। Environment variable आपके सोचने से ज़्यादा move करता है। OPENAI_BASE_URL LLM और embedder दोनों से पढ़ा जाता है। अगर gateway आपका embedding model serve नहीं करता, तो एक env-level override search() तोड़ता है जबकि add() काम करता रहता है, जो "memory writes fine but retrieval is empty or erroring" जैसा दिखता है। Override को llm config block तक scope करें और embedder को कभी पता नहीं चलेगा। Config keys per-SDK हैं। Python snake_case है (openai_base_url, api_key); TypeScript camelCase है (openaiBaseUrl, apiKey)। एक Python dict में camelCase key चुपचाप ignore हो जाती है और आप default endpoint पर वापस गिर जाते हैं, जो exactly override के "काम न करने" जैसा दिखता है। Model ids exact strings हैं। mem0 model field validate नहीं करता; यह इसे forward करता है। एक typo पहले add() पर gateway से एक model-not-found error के तौर पर सामने आती है, और /v1/models listing authoritative spelling है। Embedder बदलना एक config decision नहीं, एक index decision है। अलग-अलग models से embeddings अलग vector spaces में रहती हैं, तो embedder repoint करना existing vectors के against similarity invalidate करता है। LLM move करना free है; embedder move करने का मतलब है store re-embed करना। इन्हें separate migrations के तौर पर plan करें।

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

• Agent builders जो assistants में persistent memory add करते हैं। Extraction हर write पर चलता है, तो per-key usage वाला एक single billing surface stack पर bolt की गई दूसरे vendor dashboard से बेहतर है।
• Teams जो एक OpenAI-shaped config के पीछे Claude-quality extraction चाहती हैं। Provider string "openai" ही रहती है; सिर्फ base URL और model id बदलते हैं।
• High-volume chat products जो एक frontier chat model को एक fast extraction id के साथ pair करके memory layer की unit cost control करते हैं, हर एक same endpoint से addressable।
• Developers जो extraction models को side by side evaluate करते हैं। हर candidate per vendor नए provider integration की बजाय fixed fixtures के against एक model string है।
• Developers जिनके पास किसी given vendor की billing तक access नहीं है। बिना card requirement वाला top-up based access per-provider sign-up dependency हटा देता है।

Endpoint verify करें और पहले add() को debug करें।

Pipeline चलाने से पहले confirm करें कि gateway आपके configure किए गए model को list करता है; model field एक served id से exactly match होना चाहिए। First-run failures एक pattern follow करती हैं। 401 का मतलब है LLM ने जो key resolve की वह endpoint के लिए गलत है, और चूंकि दोनों config-over-env cascade से आते हैं, assume करने की बजाय दोनों effective values print करें; एक env base URL के साथ एक config api_key (या उल्टा) एक classic mismatch है। Model-not-found एक id typo है। Requests visibly openrouter.ai पर जाना मतलब OPENROUTER_API_KEY special case fire हुआ। और अगर add() succeed करे जबकि search() fail करे, आपने environment के through गलती से embedder move कर दिया; base URL को llm block तक scope करें। जब memories चलने लगें, APIsRouter console per-request model, token counts, और spend दिखाता है। Extraction calls छोटी लेकिन relentless हैं, और usage view वह तरीका है जिससे आप देखते हैं कि memory layer प्रति हज़ार writes genuinely कितना खर्च करता है, estimate करने की बजाय।

curl -s https://api.apisrouter.com/v1/models \
  -H "Authorization: Bearer $APISROUTER_API_KEY" | head -50

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