VPS پر AI agents کے لیے Memmy local memory hub
Memmy آپ کے AI agents کے لیے ایک مشترکہ SQLite memory store بناتا ہے۔ Ubuntu پر source سے build کریں، service کو port 18960 پر چلائیں، اور notes local رکھیں۔
Memmy کیا ہے اور یہ کیا محفوظ کرتا ہے
Memmy، AI agents کے لیے ایک مقامی memory hub ہے جو آپ کے اپنے VPS (virtual private server) پر چلتا ہے۔ یہ آپ کے agents کی سیکھی ہوئی معلومات کا ایک SQLite database رکھتا ہے، اور اس server پر موجود ہر agent اسی store سے data پڑھتا اور اس میں data لکھتا ہے۔ یہ project MemTensor کی طرف سے memmy-agent ہے، MIT licensed ہے، اور July 2026 تک version 1.0.4 پر ہے۔
Server پر صرف اس کے کچھ حصے اہم ہیں۔ Memmy ایک memory service فراہم کرتا ہے جو http://127.0.0.1:18960 پر listening کرتی ہے، ایک memmy-memory command line interface (CLI) فراہم کرتا ہے جو اس service سے رابطہ کرتا ہے، اور ایک desktop workbench بھی فراہم کرتا ہے۔ Workbench صرف macOS اور Windows کے لیے packaged ہے، اس لیے Linux VPS پر آپ service اور CLI چلاتے ہیں۔ Claude Code، Codex اور Cursor کو مشترکہ memory دینے کے لیے یہ کافی ہے۔
Memmy محفوظ کیے جانے والے data کو چار layers میں تقسیم کرتا ہے۔ L1 Trace خام turn ہوتا ہے: request، response اور tool calls۔ L2 Policy ان traces سے اخذ کیا گیا ایسا طریقۂ کار ہوتا ہے جو مفید ثابت ہوا ہو۔ L3 World Model کسی project یا environment کے بارے میں مستقل knowledge ہوتا ہے۔ Skill، Policy سے بننے والا callable procedure ہوتا ہے۔ Service کسی turn کو ingest کرتے وقت اس کے لیے layer مقرر کرتی ہے، اس لیے آپ کو یہ layers دستی طور پر بنانے کی ضرورت نہیں ہوتی۔
مشترکہ میموری ہب فی ٹول میموری کے مقابلے میں کیا تبدیل کرتا ہے
آج ہر agent اپنی میموری کے ساتھ آتا ہے۔ Claude Code repository میں instruction files رکھتا ہے۔ Cursor اپنے workspace database میں rules رکھتا ہے۔ Codex session logs کو ~/.codex کے تحت رکھتا ہے۔ ہر store صرف ایک tool سے وابستہ ہوتا ہے، اس لیے پیر کو ایک tool میں سکھائی گئی حقیقت منگل کو دوسرے tool کے لیے نامعلوم ہوتی ہے۔ اس کی دوہری قیمت ادا کرنی پڑتی ہے: ایک بار اسی project کی دوبارہ وضاحت پر خرچ ہونے والے tokens کی صورت میں، اور دوسری بار اس وقت ہونے والے غلط کام کی صورت میں جب agent ایسی مفروضہ بنیاد پر عمل کرے جسے آپ پہلے ہی کہیں اور درست کر چکے ہوں۔
hub store کو tool سے باہر منتقل کر دیتا ہے۔ Memmy موجودہ stores کو بھی پڑھتا ہے، اس لیے آپ خالی database سے شروع نہیں کرتے۔ اس کا scanner چھ sources کو جانتا ہے: Claude Code کو ~/.claude/projects/**/*.jsonl پر، Codex کو ~/.codex/sessions/<YYYY>/<MM>/<DD>/rollout-*.jsonl پر، OpenCode کو ~/.local/share/opencode/opencode.db پر، Cursor کی state.vscdb files کو، OpenClaw کے SQLite databases کو ~/.openclaw کے تحت، اور Hermes کو ~/.hermes کے تحت۔ آپ نام اور local path دے کر دستی طور پر کوئی source شامل کر سکتے ہیں۔
Import counters کا ایک جیسا نہ ہونا متوقع ہے۔ scanner messages کو source اور conversation کے مطابق گروپ کرتا ہے، پھر ہر مکمل turn کے لیے ایک L1 memory لکھتا ہے۔ turn اس وقت مکمل شمار ہوتا ہے جب اس میں non-empty user content ہو اور وہ non-empty assistant message پر ختم ہو، اس لیے interrupted session میں سے کچھ بھی شامل نہیں ہوتا۔ Messages کو conversation checkpoints اور stable turn IDs کے ذریعے deduplicate کیا جاتا ہے۔ ایک ہی run میں scanned count، imported message count اور new memory count سب مختلف ہوتے ہیں۔
یہ وہ حصہ ہے جو ایک session کے اندر Claude Code کے context management کے طریقے کے ساتھ مل کر کام کرتا ہے۔ Context management طے کرتا ہے کہ ایک window میں کیا سما سکتا ہے۔ memory hub طے کرتا ہے کہ window بند ہونے کے بعد کیا محفوظ رہے گا۔
VPS پر درکار چیزیں
- Node.js 22 یا اس کے بعد کا ورژن۔ Memmy کی دستاویزات میں یہ درکار ہے، جبکہ Ubuntu 24.04 کے ساتھ Node 18 جاری ہوتا ہے۔
gitاور build toolchain، کیونکہbetter-sqlite3ایک native module ہے جو installation کے دوران compile ہو سکتا ہے۔- تقریباً 2 GB RAM۔ root installation ایک بڑا workspace اور frontend build chain حاصل کرتی ہے۔
node_modulesاور database کے لیے چند GB خالی disk space۔
sudo apt update
sudo apt install -y git build-essential python3 curl ca-certificates sqlite3
curl -fsSL https://deb.nodesource.com/setup_22.x | sudo -E bash -
sudo apt install -y nodejs
node --versionnode --version کو v22 یا اس سے زیادہ دکھانا چاہیے۔ یہاں v18 کا مطلب ہے کہ NodeSource step کامیاب نہیں ہوا، اور بعد میں project کے engine check پر installation ناکام ہو جائے گی۔
Ubuntu 24.04 پر Memmy کو سورس سے انسٹال کریں
git clone https://github.com/MemTensor/memmy-agent.git
cd memmy-agent
cp .env.example .env
npm install
npm run memory:buildnpm run memory:build، @memmy/memory workspace کو Memory/dist میں compile کرتا ہے۔ Headless server کے لیے tree میں موجود کسی اور چیز کو build کرنے کی ضرورت نہیں ہے۔ تصدیق کریں کہ native module لوڈ ہو گیا ہے:
node -e "require('better-sqlite3'); console.log('better-sqlite3 loads')"اگر یہ لائن پرنٹ کرنے کے بجائے error دے، تو native module آپ کے Node version سے مطابقت نہیں رکھتا۔ npm rebuild better-sqlite3 چلائیں۔ یہی وہ عمل ہے جو project کی اپنی start script کسی بھی چیز کو launch کرنے سے پہلے انجام دیتی ہے۔
README میں bash scripts/dev-start.sh کو ایک command سے start کرنے کا طریقہ بتایا گیا ہے۔ اسے headless VPS پر نہ چلائیں۔ یہ memory service کے ساتھ Electron desktop shell اور port 19000 پر Vite dev server شروع کرتا ہے۔ Electron کو display درکار ہوتی ہے، اس لیے graphical session کے بغیر server پر script رک جاتی ہے یا exit ہو جاتی ہے۔
میموری سروس شروع کریں اور جانچیں کہ یہ جواب دیتی ہے
npm run memory:serve:devماخذ کوڈ سے میموری سروس چلانے کا دستاویزی طریقہ یہی ہے۔ یہ 127.0.0.1:18960 پر bind ہوتی ہے، database کو ~/.memmy/memory-service/memory.sqlite پر رکھتی ہے، اور configuration کو ~/.memmy/config.yaml سے پڑھتی ہے۔ جب آپ یہی values واضح طور پر دینا چاہیں تو README میں بھی یہی values درج ہیں:
npm run memory:serve:dev -- \
--host 127.0.0.1 --port 18960 \
--db ~/.memmy/memory-service/memory.sqlite \
--config ~/.memmy/config.yamlدوسرے shell سے سروس سے پوچھیں کہ آیا یہ فعال ہے:
curl -sS http://127.0.0.1:18960/api/v1/healthHealth وہ واحد endpoint ہے جو کبھی token طلب نہیں کرتا، اسی لیے یہ درست probe ہے۔ اگر curl code 7 کے ساتھ exit کرے اور Failed to connect to 127.0.0.1 port 18960 پیغام دکھائے، تو کوئی بھی چیز listen نہیں کر رہی۔ سروس چلانے والے terminal کو دیکھیں، کیونکہ startup پر crash وہیں ظاہر ہوتا ہے۔ عام وجہ native SQLite module کا load نہ ہونا ہے۔ سروس شروع ہونے کے بعد ss -lntp | grep 18960 socket کی تصدیق کرتا ہے۔
باقی HTTP API (application programming interface) /api/v1 کے تحت موجود ہے۔
POST /api/v1/memory/addmemory لکھتا ہے اورPOST /api/v1/memory/searchqueries چلاتا ہے۔GET /api/v1/memory/:idاورDELETE /api/v1/memory/:idایک entry کو پڑھتے اور حذف کرتے ہیں۔POST /api/v1/sessions/openاورPOST /api/v1/sessions/:sessionId/closeagent session کے آغاز اور اختتام کو متعین کرتے ہیں۔POST /api/v1/turns/startاورPOST /api/v1/turns/:turnId/completeایک turn کو record کرتے ہیں۔GET /api/v1/panel/overview،/api/v1/panel/analysisاور/api/v1/panel/itemsdashboard کو data فراہم کرتے ہیں۔
Memmy ports کا ایک block reserve کرتا ہے، اور headless استعمال میں آپ صرف پہلا port استعمال کرتے ہیں: memory کے لیے 18960، gateway health کے لیے 18970، web UI اور admin HTTP کے لیے 18980، memmy serve کے شروع کردہ OpenAI-compatible API کے لیے 18990، اور desktop frontend کے dev server کے لیے 19000 اور 19010۔ اگر آپ کے box پر کوئی سروس پہلے ہی ان میں سے کسی port کو استعمال کر رہی ہے، تو دیکھنے کی جگہ یہی فہرست ہے۔
memmy-memory کمانڈ اصل میں کہاں سے آتی ہے
یہ وہ مرحلہ ہے جہاں پہلی تنصیب عموماً غلط ہو جاتی ہے، اس لیے اندازہ لگانے کے بجائے اسے پیکیج سے پڑھیں۔ کمانڈ کے نام کا repository کے نام سے کوئی تعلق نہیں۔ یہ اس workspace کے bin فیلڈ سے آتی ہے جو اسے متعین کرتا ہے:
node -p "JSON.stringify(require('./Memory/package.json').bin)"یہ {"memmy-memory":"./dist/src/cli/index.js"} دکھاتا ہے۔ اس لیے تیار کردہ entry point Memory/dist/src/cli/index.js ہے، اور یہ صرف npm run memory:build کے بعد موجود ہوتا ہے، کیونکہ build ہی dist بناتا ہے اور فائل کو executable بناتا ہے۔ اسے براہِ راست چلائیں:
node Memory/dist/src/cli/index.js healthاگر آپ PATH پر مختصر نام چاہتے ہیں تو اسی فائل سے link بنائیں:
sudo ln -s "$PWD/Memory/dist/src/cli/index.js" /usr/local/bin/memmy-memory
memmy-memory healthCLI بطورِ طے شدہ http://127.0.0.1:18960 استعمال کرتا ہے اور --url، --token، --config، --source اور --user-id قبول کرتا ہے۔ اس کے subcommands init، health، search، add، get اور delete ہیں، اس کے علاوہ session اور turn calls بھی ہیں جنہیں agents افراد کے بجائے استعمال کرتے ہیں۔ memmy-memory search "deploy steps" اور memmy-memory add "staging migrates on deploy" وہ دو کمانڈز ہیں جنہیں agent سب سے زیادہ چلاتا ہے۔
Claude Code کو Memmy سے کیسے مربوط کریں؟
Claude Code میں memory plugin کا interface نہیں ہے، اس لیے Memmy اس میں hook نہیں ہوتا۔ Integration اس سے زیادہ سادہ ہے۔ Claude Code memmy-memory کو ایک عام shell command کے طور پر چلاتا ہے، اور ایک instruction file اسے بتاتی ہے کہ یہ command کب چلانی ہے۔ Memmy کا documented installer یہ file آپ کے لیے لکھتا ہے: memmy-memory init --agent target agent کی rules directory میں memory instruction file رکھتا ہے۔
Instruction ایک بار خود لکھیں، کیونکہ اس طرح آپ کو ٹھیک معلوم رہتا ہے کہ agent کو کیا ہدایت دی گئی ہے۔ Claude Code ہر session کے آغاز پر project root سے CLAUDE.md پڑھتا ہے، اس لیے درج ذیل جیسا section مکمل integration فراہم کرتا ہے:
## Memory
Before starting a task, run `memmy-memory search "<topic>"` and read what comes back.
When a task is done, run `memmy-memory add "<what you learned>"` for anything that will matter next session.واضح رہے کہ اس سے آپ کو کیا فائدہ ملتا ہے۔ یہ instruction-level integration ہے، اس لیے یہ صرف اس وقت کام کرتا ہے جب model command چلانے کا فیصلہ کرے۔ اس کے علاوہ یہ خودکار طور پر نہیں چلتا۔ کوئی چیز call کو لازمی نہیں بناتی۔ اگر کوئی session add کے بغیر ختم ہو جائے تو کچھ بھی محفوظ نہیں کیا جاتا، اور اگلی بار search کرنے پر واحد اشارہ empty result ہوتا ہے۔ یہ Claude Code کی اپنی memory files جیسا ہی trade-off ہے، لیکن ایک فرق کے ساتھ: store مشترکہ ہوتا ہے، اس لیے یہی note اسی machine پر Codex اور Cursor تک بھی پہنچتا ہے۔
دوسری سمت کے لیے کسی setup کی ضرورت نہیں۔ Memmy کا scanner پہلے ہی ~/.claude/projects/**/*.jsonl پڑھتا ہے، جہاں Claude Code اپنے session transcripts لکھتا ہے۔ Memmy اسی server پر چلائیں جہاں آپ tmux session کے اندر Claude Code چلاتے ہیں، اور گزشتہ دن کا کام بغیر کسی configuration کے memory بن جائے گا۔
کیا Memmy، Claude Code کے لیے MCP server کے طور پر کام کرتا ہے؟
نہیں، اور سمت پہلے سے معلوم ہونے پر وقت بچتا ہے۔ MCP (model context protocol) میں clients اور servers ہوتے ہیں۔ Memmy ایک client ہے۔ یہ MCP servers سے outbound connection بناتا ہے اور ان کے tools اپنے agent runtime کو فراہم کرتا ہے۔ یہ ایسا MCP endpoint شائع نہیں کرتا جس سے claude mcp add connect کر سکے۔ Repository میں واحد MCP bridge، desktop local API کے اندر موجود Composio integration سے تعلق رکھتا ہے۔ یہ API 127.0.0.1 پر random port bind کرتی ہے اور اپنے x-memmy-mcp-token header کے پیچھے کام کرتی ہے۔
Client side کو ~/.memmy/config.yaml میں configure کیا جاتا ہے۔ MEMMY_CONFIG اسی file کی طرف اشارہ کرتا ہے، tools.mcpServers کے تحت:
tools:
mcpServers:
example:
type: stdio
command: npx
args:
- "-y"
- "your-mcp-server"
toolTimeout: 30
enabledTools:
- "*"type، stdio، sse اور streamableHttp قبول کرتا ہے۔ stdio server، Memmy کے child process کے طور پر چلتا ہے۔ اس لیے اس کا command اسی box پر موجود ہونا چاہیے اور اسی user کے طور پر چلنا چاہیے۔ اگر آپ VPS پر چلنے والے MCP servers پہلے سے رکھتے ہیں، تو یہی servers یہاں درج کریں۔
میموری اسٹور کو نجی رکھنا
Memmy کی ملکیت کی ہر چیز ~/.memmy کے تحت رہتی ہے: config.yaml، workspace، memory-service/memory.sqlite اور runtime فائلیں۔ اسکیننگ اور ingestion مقامی طور پر ہوتی ہے، اور memories اسی مقامی SQLite فائل میں لکھی جاتی ہیں، اس لیے پہلے سے طے شدہ طرزِ عمل واقعی مقامی ہے۔
دو paths نیٹ ورک تک پہنچتے ہیں۔ MEMMY_CLOUD_SERVICE کی default قدر https://memmy-api.memtensor.cn ہے اور یہ اپنے trial tokens کے ذریعے account mode چلاتا ہے، اس لیے API key mode اسے کبھی call نہیں کرتا۔ memory improvement program privacy settings میں ایک الگ toggle ہے، اور جب تک آپ اسے فعال نہ کریں، یہ بند رہتا ہے۔
تیسرا path نظر انداز کرنا آسان ہے۔ اگر آپ hosted embedding provider configure کرتے ہیں، تو ہر memory کا متن اس provider کو بھیجا جاتا ہے تاکہ اسے vector میں تبدیل کیا جا سکے۔ مقامی storage اس معاملے میں مدد نہیں کرتی۔ اسے مکمل طور پر روکنے کا واحد طریقہ یہ ہے کہ embedding endpoint خود host کریں۔
Port 18960 کو loopback address پر رکھیں۔ اس کے لیے firewall rule کی ضرورت نہیں، کیونکہ 127.0.0.1 سے bind کی گئی service، machine سے باہر قابلِ رسائی نہیں ہوتی۔ اپنے laptop سے SSH کے ذریعے اس تک رسائی حاصل کریں:
ssh -N -L 18960:127.0.0.1:18960 you@your-vpsاگر آپ کبھی اسے زیادہ وسیع address پر bind کریں، تو پہلے token مقرر کریں۔ config میں storage.token، یا MEMMY_MEMORY_TOKEN یا MEMORY_SERVICE_TOKEN environment variable مقرر کرنے سے health کے سوا ہر endpoint کے لیے bearer token درکار ہوگا۔ Config values ${ENV_NAME} references کو support کرتی ہیں، اس لیے token اور آپ کی model API keys خود file میں ظاہر نہیں ہوتیں۔ یہ وہی عادت ہے جس کے تحت باقی جگہوں پر بھی AI agents سے secrets باہر رکھنا چاہیے، اور default deny ufw policy اس صورت میں آخری حفاظتی تہہ ہے جب مستقبل کا کوئی version اپنا default bind address تبدیل کر دے۔
memory.sqlite پر اعتماد کرنے سے پہلے ~/.memmy کا بیک اپ لیں
memory.sqlite مکمل store ہے۔ Vectors اسی file میں sqlite-vec extension کے ذریعے محفوظ ہوتے ہیں، اس لیے یہی ایک file بیک اپ ہے۔ سروس کے لکھنے کے دوران اسے cp سے copy کرنے پر database کا نامکمل snapshot بن سکتا ہے۔ SQLite کا اپنا backup command استعمال کریں:
mkdir -p ~/memmy-backup
sqlite3 ~/.memmy/memory-service/memory.sqlite ".backup '$HOME/memmy-backup/memory.sqlite'"اس سے سروس کے چلتے رہنے کے دوران ایک consistent copy بن جاتی ہے۔ اسے مقررہ شیڈول کے مطابق machine سے باہر بھیجیں؛ off-site storage کے لیے restic اسی مقصد کے لیے ہے۔ config.yaml ضائع ہونے پر provider settings دوبارہ درج کرنی پڑیں گی۔ memory.sqlite ضائع ہونے پر تمام memories ضائع ہو جائیں گی، اور machine پر کسی دوسری جگہ ان کی copy موجود نہیں ہوتی۔
systemd کے تحت memory سروس چلائیں
شیل میں npm run memory:serve:dev شیل کے ساتھ بند ہو جاتا ہے۔ unit فائل سروس کو reboot کے بعد بھی چلتا رکھتی ہے۔
[Unit]
Description=Memmy memory service
After=network-online.target
[Service]
Type=simple
User=memmy
WorkingDirectory=/opt/memmy/memmy-agent
EnvironmentFile=/etc/memmy/memory.env
ExecStart=/usr/bin/npm run memory:serve:dev
Restart=on-failure
RestartSec=5
[Install]
WantedBy=multi-user.targettoken کو unit میں نہ رکھیں۔ اسے /etc/memmy/memory.env میں رکھیں، مالک root ہو اور mode 600 ہو:
MEMMY_CONFIG=/home/memmy/.memmy/config.yaml
MEMMY_MEMORY_TOKEN=replace-this-with-a-long-random-stringsudo systemctl daemon-reload
sudo systemctl enable --now memmy-memory
systemctl status memmy-memory --no-pager
curl -sS http://127.0.0.1:18960/api/v1/healthstatus output میں status=203/EXEC کا مطلب ہے کہ systemd ExecStart کو بالکل چلا نہیں سکا۔ اس لیے which npm چیک کریں: NodeSource کی installation میں یہ /usr/bin/npm ہوتا ہے، جبکہ nvm میں صارف کے home directory کے اندر ہوتا ہے، جسے systemd تلاش نہیں کر پائے گا۔ جو unit شروع ہوتے ہی بند ہو جائے، اس میں خرابی npm کے اندر ہوئی ہے؛ journalctl -u memmy-memory -n 50 وجہ دکھاتا ہے۔ طریقہ کار VPS پر کسی بھی دوسری systemd سروس جیسا ہی ہے۔
Memmy ابھی کیا نہیں کرتا
- Linux ڈیسک ٹاپ build موجود نہیں ہے۔ Packaging scripts macOS اور Windows کا احاطہ کرتے ہیں، اس لیے workbench، اس کا onboarding wizard، اور memory dashboard خود server پر دستیاب نہیں ہیں۔
memory:serve:dev،tsxکے ذریعے TypeScript entry point چلاتا ہے؛ یہ development path ہے۔ Repository compiled output کے لیےmemory:serveبھی فراہم کرتا ہے۔ اپنے checkout میں موجود scripts دیکھنے کے لیےnpm runکو بغیر arguments کے چلائیں۔- Retrieval اپنی search window تازہ ترین 2,000 vector rows سے بناتا ہے، پھر اسی window کے اندر Top-K selection لاگو کرتا ہے۔ بہت بڑے store میں پرانی memory اس window سے باہر رہ سکتی ہے۔
- Embedding، capture کے بعد ہوتی ہے، اور ناکامی agent کی turn کو روکنے کے بجائے retry queue میں چلی جاتی ہے۔ کچھ لمحے پہلے شامل کی گئی memory ابھی vector search سے قابل تلاش نہ ہو۔
- ایک SQLite file صرف ایک node کے لیے ہوتی ہے۔ Clustering موجود نہیں ہے، اس لیے دوسرا server ایک الگ memory رکھتا ہے۔
Version 1.0.4 اور July 2026 تک تقریباً 329 stars اس بات کی نشاندہی کرتے ہیں کہ یہ ابھی نیا project ہے۔ Flags، paths اور script names مختلف releases کے درمیان تبدیل ہو سکتے ہیں۔ کسی بھی جگہ سے نقل کیے گئے command پر، بشمول یہاں موجود command پر، بھروسا کرنے کے بجائے اپنے checkout میں bin field اور npm run کے output کو دیکھیں۔
FAQ
صحت کی جانچ connection refused کیوں واپس کرتی ہے؟
port 18960 پر کوئی سروس listening نہیں کر رہی۔ Failed to connect to 127.0.0.1 port 18960 کے ساتھ curl کا exit code 7 ظاہر کرتا ہے کہ memory service چل نہیں رہی یا startup کے وقت بند ہو گئی ہے، اس لیے terminal یا اس journal کو پڑھیں جہاں یہ سروس شروع ہوئی تھی۔ دو عام وجوہات یہ ہیں: better-sqlite3 native module آپ کے Node version سے مطابقت نہیں رکھتا، جسے npm rebuild better-sqlite3 سے درست کیا جا سکتا ہے؛ یا Node version 22 سے کم ہے۔ سروس چلنے کے بعد ss -lntp | grep 18960 سے socket کی تصدیق کریں۔
source سے build کرنے کے بعد memmy-memory command کہاں سے آتی ہے؟
یہ repository name سے نہیں، بلکہ @memmy/memory workspace package کے bin field سے آتی ہے۔ checkout کے اندر node -p "JSON.stringify(require('./Memory/package.json').bin)" چلائیں؛ یہ {"memmy-memory":"./dist/src/cli/index.js"} دکھاتا ہے۔ یہ file صرف npm run memory:build کے بعد موجود ہوتی ہے، کیونکہ build dist بناتا ہے اور file کو executable بناتا ہے۔ اسے node Memory/dist/src/cli/index.js health کے طور پر چلائیں، یا مختصر نام کے لیے اسے /usr/local/bin میں symlink کریں۔
کیا میں claude mcp add کے ساتھ Memmy کو Claude Code میں شامل کر سکتا ہوں؟
نہیں۔ Memmy ایک MCP client ہے، MCP server نہیں۔ یہ ~/.memmy/config.yaml میں tools.mcpServers کے تحت درج servers سے outbound connection بناتا ہے اور ان کے tools اپنے runtime کو فراہم کرتا ہے۔ Claude Code دوسری سمت سے Memmy تک پہنچتا ہے۔ یہ memmy-memory CLI کو shell command کے طور پر چلاتا ہے، اور اس کے لیے memmy-memory init --agent agent کی rules directory میں ایک instruction file لکھتا ہے۔
کیا Memmy چلانے سے میری memories کسی cloud service کو بھیجی جاتی ہیں؟
Scanning اور ingestion مقامی طور پر چلتے ہیں، اور memories آپ کی اپنی disk پر ~/.memmy/memory-service/memory.sqlite میں لکھی جاتی ہیں۔ account mode اور trial tokens کے لیے MEMMY_CLOUD_SERVICE، https://memmy-api.memtensor.cn کی طرف اشارہ کرتا ہے، جبکہ memory improvement program اس وقت تک غیر فعال رہتا ہے جب تک آپ اسے فعال نہ کریں۔ جس path کی نگرانی ضروری ہے وہ embedding provider ہے: hosted embedding model ہر memory کا متن وصول کرتا ہے جسے وہ vector میں تبدیل کرتا ہے۔ اگر یہ بات اہم ہے تو ایسا endpoint استعمال کریں جسے آپ خود چلاتے ہوں۔