mem0 کو ایک custom OpenAI-compatible base URL کے خلاف چلائیں۔

فوری جواب: 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۔ تو سب سے صاف override llm config dict میں ایک key ہے: openai_base_url کو https://api.apisrouter.com/v1 پر سیٹ کریں، اس کے ساتھ api_key سیٹ کریں (یا OPENAI_API_KEY export کریں)، اور ہر memory-extraction call gateway کے ذریعے route ہو جاتی ہے۔ یہ upstream mem0 رویہ ہے، mem0/llms/openai.py میں پڑھنے کے قابل، کوئی fork نہیں۔ TypeScript SDK وہی جوڑا camelCase میں expose کرتا ہے: openaiBaseUrl اور apiKey۔ config dict کی values environment variables پر حاوی ہوتی ہیں، جو defaults پر حاوی ہوتی ہیں، تو ایک config-level base URL ان مشینوں پر بھی جیتتا ہے جہاں 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 کرتا ہے، انہیں پہلے سے محفوظ چیز سے compare کرتا ہے، اور فی memory فیصلہ کرتا ہے کہ add، update، delete، یا skip کرے۔ یہ حقیقی reasoning work ہے، اور یہ ہر write پر ہوتا ہے، تو LLM slot اس سے کہیں زیادہ بار فائر ہوتا ہے جتنا زیادہ تر لوگ توقع رکھتے ہیں جب وہ ایک production agent پر memory bolt کرتے ہیں۔ Retrieval دوسرا آدھا حصہ ہے، اور یہ بالکل LLM استعمال نہیں کرتا: search() query کو embed کرتا ہے اور store کے خلاف vector similarity چلاتا ہے۔ دو مختلف clients، دو مختلف models، دو مختلف blocks میں configured (llm اور embedder)۔ کچھ بھی reroute کرنے سے پہلے یہی سب سے اہم چیز سمجھنے کے قابل ہے، کیونکہ اس کا مطلب ہے کہ آپ extraction workload کو multi-vendor gateway پر move کر سکتے ہیں جبکہ embedder اپنے موجودہ provider اور index کو چھوئے بغیر رکھتا ہے۔ Config میں provider "openai" ہی رہتا ہے؛ mem0 model field کو /v1/chat/completions پر plain string کے طور پر pass کرتا ہے۔ جب openai_base_url کے پیچھے موجود endpoint متعدد vendors serve کرے، تو وہ string ایک Claude، GPT، DeepSeek، یا GLM id ہو سکتی ہے، اور extraction model بدلنا provider migration کی بجائے ایک line کی config تبدیلی بن جاتا ہے۔

مکمل سیٹ اپ: config dict یا environment variable۔

Config-dict راستہ precise ہے: یہ صرف LLM کو move کرتا ہے۔ dict بنائیں، اسے Memory.from_config کو دیں، اور memory API کو معمول کے مطابق استعمال کریں۔ api_key field gateway key کو آپ کی vector-store اور embedder settings سے مکمل طور پر باہر رکھتا ہے۔ Environment راستہ بھی موجود ہے: mem0 کی OpenAI classes OPENAI_BASE_URL پڑھتی ہیں جب config key موجود نہ ہو۔ یہ ایک exported variable اور zero code changes ہے، مگر دائرہ نوٹ کریں: embedder کی OpenAI class وہی variables پڑھتی ہے (یہ پرانا OPENAI_API_BASE نام بھی مانتی ہے، جو LLM class نہیں مانتی)۔ OPENAI_BASE_URL export کریں اور آپ نے دونوں components move کر دیے، جو صرف تب درست ہے اگر endpoint آپ کے embedding model کو بھی serve کرے۔ شک ہو تو config dict کو ترجیح دیں اور 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 چننا۔

عملی loop یہ ہے: اپنا embedder fixed رکھیں، ایک ہی conversation fixtures کو دو یا تین extraction models سے چلائیں، اور محفوظ کردہ memories کا diff کریں۔ ایک endpoint کے پیچھے یہ comparison فی candidate ایک config-string edit ہے، اور per-key usage log ہر candidate کے run کی قیمت لگاتا ہے۔

• Extraction quality ہی memory quality ہے۔ LLM فیصلہ کرتا ہے کہ کیا یاد رکھنے کے قابل ہے اور کیا نئی معلومات پرانی سے متضاد ہیں؛ ایک model جو کوئی update miss کرے وہ ہر آنے والے session کے لیے retrieval کو آلودہ کر دیتا ہے۔ claude-sonnet-4-6 اور gpt-5.5 اس trade-off کا قابلِ اعتماد درمیانہ راستہ ہیں۔
• Volume ہر write پر ہے۔ ہر exchange کے بعد add() call کرنے والا ایک chat product روزانہ ہزاروں بار extraction چلاتا ہے، جہاں claude-haiku-4-5-20251001 یا deepseek-v4-flash جیسی تیز id memory layer کو token bill پر حاوی ہونے سے روکتی ہے۔
• تضاد سے بھرپور domains (بدلنے والی preferences، ختم ہونے والے facts) add() پر ایک stronger model سے فائدہ اٹھاتے ہیں چاہے فی call زیادہ خرچ آئے، کیونکہ ایک غلط update decision بعد میں پکڑنا مہنگا ہوتا ہے۔
• Temperature کم ہونی چاہیے۔ Extraction ایک structured-decision task ہے، creative writing نہیں؛ mem0 اسی 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 سے مخصوص failure modes۔

ایک باقی رہ جانے والا OPENROUTER_API_KEY routing hijack کر لیتا ہے۔ mem0 کی OpenAI LLM class اس variable کو special-case کرتی ہے: جب یہ سیٹ ہو، class OpenRouter کے endpoint پر switch ہو جاتی ہے اور آپ کے ارادے کو نظر انداز کرتی ہے۔ اگر requests آپ کے configure کردہ base URL تک نہیں پہنچ رہیں، تو پہلے یہ variable چیک کریں اور 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" کے طور پر presents ہوتا ہے۔ override کو llm config block تک محدود رکھیں اور embedder کو کچھ نظر نہیں آتا۔ Config keys فی-SDK ہیں۔ Python snake_case ہے (openai_base_url، api_key)؛ TypeScript camelCase ہے (openaiBaseUrl، apiKey)۔ ایک Python dict میں camelCase key خاموشی سے نظر انداز ہو جاتی ہے اور آپ default endpoint پر گر جاتے ہیں، جو بالکل ایسا لگتا ہے جیسے override "کام نہیں کر رہا"۔ Model ids exact strings ہیں۔ mem0 model field کو validate نہیں کرتا؛ یہ اسے forward کرتا ہے۔ ایک typo پہلے add() پر gateway سے model-not-found error کے طور پر سامنے آتی ہے، اور /v1/models listing ہی authoritative spelling ہے۔ Embedder بدلنا ایک index فیصلہ ہے، config فیصلہ نہیں۔ مختلف models کے embeddings مختلف vector spaces میں رہتے ہیں، تو embedder کو repoint کرنا موجودہ vectors کے خلاف similarity کو invalidate کر دیتا ہے۔ LLM move کرنا مفت ہے؛ embedder move کرنے کا مطلب store کو دوبارہ embed کرنا ہے۔ انہیں الگ migrations کے طور پر plan کریں۔

mem0 کو gateway کے ذریعے کون route کرتا ہے۔

• وہ agent builders جو assistants میں persistent memory شامل کرتے ہیں۔ Extraction ہر write پر چلتا ہے، تو ایک single billing surface اور per-key usage stack پر bolted ایک دوسرے vendor dashboard سے بہتر ہے۔
• وہ teams جو ایک OpenAI-shaped config کے پیچھے Claude-quality extraction چاہتی ہیں۔ provider string "openai" ہی رہتی ہے؛ صرف base URL اور model id بدلتی ہیں۔
• زیادہ-volume والے chat products جو memory layer کی unit cost کو ایک frontier chat model کو تیز extraction id کے ساتھ pair کر کے کنٹرول کرتے ہیں، ہر ایک ایک ہی endpoint سے addressable۔
• وہ developers جو extraction models کو ساتھ ساتھ evaluate کرتے ہیں۔ ہر candidate fixed fixtures کے خلاف ایک model string ہے، فی vendor نئی provider integration نہیں۔
• وہ developers جن کے پاس کسی مخصوص vendor کی billing تک رسائی نہیں۔ Top-up پر مبنی رسائی بغیر کارڈ کی شرط کے فی-provider sign-up کا انحصار ختم کر دیتی ہے۔

Endpoint verify کریں اور پہلا add() debug کریں۔

Pipeline چلانے سے پہلے تصدیق کریں کہ gateway آپ کی configure کردہ model list کرتا ہے؛ model field کو ایک serve کی گئی id سے بالکل میچ ہونا چاہیے۔ پہلی run کی failures ایک pattern کی پیروی کرتی ہیں۔ 401 کا مطلب ہے LLM نے جو key resolve کی وہ اس endpoint کے لیے غلط ہے جو اس نے resolve کیا، اور چونکہ دونوں ایک config-over-env cascade سے آتے ہیں، دونوں effective values print کریں فرض کرنے کی بجائے؛ env base URL کے ساتھ config api_key (یا اس کا الٹ) ایک classic mismatch ہے۔ Model-not-found error ایک id typo ہے۔ Requests جو واضح طور پر openrouter.ai کو جا رہی ہیں مطلب OPENROUTER_API_KEY special case فائر ہوا۔ اور اگر add() کامیاب ہو جبکہ search() فیل ہو، تو آپ نے environment کے ذریعے غلطی سے embedder move کر دیا؛ base URL کو llm block میں محدود کریں۔ جب memories چلنے لگیں، APIsRouter console per-request model، token counts، اور spend دکھاتا ہے۔ Extraction calls چھوٹی مگر مسلسل ہوتی ہیں، اور usage view وہی ہے جہاں آپ دیکھتے ہیں کہ memory layer فی ہزار writes واقعی کیا لاگت رکھتا ہے، اندازہ لگانے کی بجائے۔

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

عمومی سوالات