Compartment offline agent memory कैसे काम करता है

Compartment क्या अलग करता है

Compartment एक agent memory store है जो हर रिकॉर्ड को उसी मशीन पर एन्क्रिप्टेड रखता है जहाँ उसे बनाया गया था और यह कभी भी किसी नेटवर्क सर्विस से संपर्क नहीं करता है। दो विकल्प इसे agent memory क्षेत्र के अन्य विकल्पों से अलग करते हैं। vault एक सीलबंद फाइल है जिसे केवल आपका passphrase खोल सकता है, और embedding चरण स्थानीय रूप से चलता है, इसलिए memory का टेक्स्ट vector में बदलने के लिए कहीं भी नहीं भेजा जाता है। Version 4.6.0 को 10 August 2026 को release किया गया था, इसका licence Apache-2.0 है, और यह PyPI से install होता है।

यह एक threat model का दावा है, इसलिए यह गाइड इसे उसी रूप में देखती है। Encryption at rest और offline डिज़ाइन चीजों की एक विशिष्ट सूची की सुरक्षा करते हैं। वे अन्य चीजों को खुला छोड़ देते हैं, और यही अंतर वह जगह है जहाँ day two की समस्याएं उत्पन्न होती हैं।

यह गाइड 11 August 2026 को पढ़ी गई प्रोजेक्ट की अपनी documentation और release notes का पालन करती है। Compartment एक desktop application, macOS पर एक menu bar item और Windows पर एक notification area icon के साथ-साथ अपना command line tool भी प्रदान करता है, और एक passphrase prompt को automated container से संचालित नहीं किया जा सकता है। नीचे दी गई जानकारी को documented व्यवहार मानें, न कि यहाँ मापा गया व्यवहार। किसी भी वास्तविक डेटा के साथ भरोसा करने से पहले इसे एक spare machine पर चलाकर देखें।

Encryption at rest वास्तव में क्या सुरक्षित करता है

Vault को XChaCha20-Poly1305 से सील किया गया है, जो एक AEAD (authenticated encryption with associated data) सिफर है। मास्टर की (master key) को रखने वाले की-स्लॉट्स (keyslots) को Argon2id से रैप किया गया है, जो एक पासवर्ड हैशिंग फंक्शन है जिसे धीमा और अधिक मेमोरी की आवश्यकता के लिए बनाया गया है। इसके दो परिणाम होते हैं। चोरी हुई डिस्क, पुराने बैकअप या सपोर्ट टिकट के साथ अटैच की गई फाइल की एक कॉपी केवल बाइट्स (bytes) है और कुछ नहीं। और फाइल खुलते समय एक भी बिट के बदलने पर ऑथेंटिकेशन फेल हो जाता है, इसलिए करप्शन (corruption) गलत उत्तर के बजाय एक स्पष्ट त्रुटि (loud error) के रूप में सामने आता है।

एम्बेडिंग वेक्टर्स (embedding vectors) भी एन्क्रिप्टेड होते हैं, जो सुनने में जितना लगता है उससे कहीं अधिक महत्वपूर्ण है। एक एम्बेडिंग हैश नहीं है। एम्बेडिंग इनवर्जन (embedding inversion) पर शोध ने केवल वेक्टर से ही मूल टेक्स्ट के पठनीय अंशों को रिकवर किया है, इसलिए एन्क्रिप्टेड डेटाबेस के बगल में रखा गया प्लेनटेक्स्ट वेक्टर इंडेक्स डेटाबेस को खुला छोड़ने के समान है। Compartment डिस्क पर कोई प्लेनटेक्स्ट इंडेक्स नहीं लिखता है।

डिलीशन (deletion) का अर्थ वास्तविक डिलीशन है। प्रत्येक रिकॉर्ड की अपनी की (key) होती है, और compartment forget --shred उस की को नष्ट कर देता है, इसलिए पीछे छूटा हुआ सिफरटेक्स्ट किसी के द्वारा भी डिक्रिप्ट नहीं किया जा सकता, आप भी नहीं। इसकी तुलना डेटाबेस फाइल से डिलीट की गई रो (row) से करें, जो आमतौर पर फ्री पेजों में तब तक पठनीय रहती है जब तक कि कोई अन्य डेटा उसे ओवरराइट न कर दे।

ऑफलाइन होना इसका दूसरा महत्वपूर्ण पहलू है। कुछ भी अपलोड नहीं किया जाता है, इसलिए कोई वेंडर अकाउंट आपकी यादों को नहीं रखता है और न ही कोई ऐसी API key है जो उन्हें लीक कर सके।

Compartment किन चीजों की सुरक्षा नहीं करता है

दावा vault की सीमा तक ही सीमित है, और वह सीमा दिखने से कहीं अधिक निकट है।

Agent plaintext को पढ़ता है। Recall मेमोरी को decrypt करता है और टेक्स्ट को agent को सौंप देता है। यदि वह agent एक hosted model है, तो वह मेमोरी अगले prompt के भीतर model provider के पास चली जाती है, ठीक वैसे ही जैसे context window में मौजूद बाकी सब कुछ। Encryption at rest फाइल की सुरक्षा करता है। यह retrieval (पुनर्प्राप्ति) की सुरक्षा नहीं करता है। इसलिए AI agents से secrets को दूर रखना में दिए गए नियम इस कारण ढीले नहीं होते कि store encrypted है: एक पासवर्ड जिसे मेमोरी के रूप में save किया गया है, वह एक ऐसा पासवर्ड है जिसे आपने स्वचालित रूप से prompt में paste करने की व्यवस्था की है।

चलती हुई मशीन पर unlocked vault खुला होता है। प्रोजेक्ट के security notes इसे स्पष्ट रूप से कहते हैं। जब तक vault unlocked है, master key और working set RAM में रहते हैं, Python यह गारंटी नहीं दे सकता कि buffer को पूरी तरह मिटाया गया है, और swap या hibernation image उस मेमोरी को disk पर लिख सकते हैं। आपके user के रूप में चलने वाले malware को कभी भी cipher को तोड़ने की आवश्यकता नहीं होती, क्योंकि वह पहले से unlocked vault से जानकारी मांग सकता है।

Caller की पहचान घोषणात्मक (declarative) होती है। Namespaces को प्रति caller प्रतिबंधित किया जा सकता है, लेकिन caller का नाम host process से आता है, इसलिए जो host अपने नाम के बारे में झूठ बोलता है, उसे वे अधिकार मिल जाते हैं जिनका वह दावा करता है। Namespace permissions एक संगठन का विषय हैं, न कि किसी hostile local program के खिलाफ एक सुरक्षा सीमा।

Shredding प्रतियों (copies) तक नहीं पहुँच सकती। forget --shred वर्तमान फाइल के भीतर की key को नष्ट कर देता है। shredding से पहले लिया गया backup उस रिकॉर्ड को सुरक्षित रखता है, और वह उस दिन के passphrase के साथ अभी भी खुल जाता है।

एक कमजोर passphrase चर्चा को समाप्त कर देता है। Argon2id प्रत्येक अनुमान (guess) को महंगा बनाता है। यह उस passphrase को नहीं बचाता जो word list में मौजूद होता है।

Pinned release से Compartment इंस्टॉल करें

Compartment के लिए Python 3.11 या उससे नया वर्ज़न आवश्यक है। यह प्रोजेक्ट तेज़ी से विकसित हो रहा है और 10 August 2026 तक PyPI पर इसके तीस वर्ज़न उपलब्ध हो चुके हैं, इसलिए इंस्टॉलेशन के दिन जो भी वर्ज़न उपलब्ध हो उसे लेने के बजाय किसी विशिष्ट वर्ज़न को पिन (pin) करें।

python3 --version
pip install "compartment==4.6.0"
compartment --version
compartment init

compartment --version को आपके द्वारा पिन किए गए वर्ज़न को प्रिंट करना चाहिए। यदि शेल compartment: command not found उत्तर देता है, तो इसका मतलब है कि इंस्टॉल डायरेक्टरी आपके PATH में नहीं है, और अधिकांश सिस्टम पर वह डायरेक्टरी ~/.local/bin होती है। pipx install compartment==4.6.0 और uv tool install compartment==4.6.0 अपने स्वयं के पाथ को मैनेज करके इस समस्या से बचाते हैं।

compartment init दो बार पासफ्रेज़ मांगता है और कुछ भी इको (echo) नहीं करता है। वह पासफ्रेज़ ही एकमात्र की (key) है। यह प्रोजेक्ट कोई पासवर्ड या रिकवरी फ्रेज़ जनरेट नहीं करता है, और यह जानबूझकर किया गया है: सॉफ्टवेयर के पास ऐसी कोई क्रेडेंशियल नहीं होती जो आपके पास न हो।

किसी भी चीज़ को इससे जोड़ने से पहले परिणाम की जाँच करें।

compartment status

एक सही स्थिति वाला वॉल्ट (vault) रिपोर्ट करता है कि वह अनलॉक है। यदि यह लॉक्ड रिपोर्ट करता है, तो compartment unlock चलाएँ और पासफ्रेज़ दर्ज करें। रीस्टार्ट करने पर यह फिर से लॉक हो जाता है, क्योंकि इसे खुला रखने वाली क्रेडेंशियल प्रति-बूट (per boot) सीक्रेट पर निर्भर करती है। macOS पर, compartment unlock --keychain उस क्रेडेंशियल को सिस्टम कीचेन (keychain) में स्टोर करके रीबूट के बाद भी उसे बनाए रखने का विकल्प देता है।

डेटा वास्तव में कहाँ स्थित होता है

डिफ़ॉल्ट वॉल्ट ~/.compartment/memory.vault है। किसी भी कमांड पर --vault PATH के साथ या COMPARTMENT_VAULT एनवायरनमेंट वेरिएबल के साथ इसे कहीं और पॉइंट करें।

वह एक फ़ाइल ही पूरा स्टोर है। यह एक हेडर के साथ खुलती है जिसमें फॉर्मेट वर्शन और Argon2id कीस्लॉट होते हैं, उसके बाद सील्ड पेलोड होता है, और फिर जैसे-जैसे नई यादें आती हैं, जर्नल एंट्रीज़ जुड़ती जाती हैं। प्रत्येक जर्नल एंट्री को उसकी लंबाई और उस लंबाई के CRC (साइक्लिक रिडंडेंसी चेक) के साथ फ्रेम किया जाता है, ताकि क्रैश के कारण बीच में रुकने वाले राइट को डेटा के रूप में पढ़ने के बजाय एक ट्रंकेटेड एंट्री के रूप में पहचाना जा सके। कॉम्पैक्शन वॉल्ट को सीरियलाइज़ करता है, एक अस्थायी फ़ाइल लिखता है, उसे fsync करता है, और फिर उसे रीनेम करके सही जगह पर रख देता है, जिसका अर्थ है कि रीडर कभी भी आधी लिखी हुई वॉल्ट नहीं देखता।

इसका उपयोगी परिणाम यह है: एक बैकअप स्क्रिप्ट ठीक एक पाथ को कॉपी करती है। इसका कठिन परिणाम यह है: आप इसे grep नहीं कर सकते, और आप इसे टेक्स्ट एडिटर में रिपेयर नहीं कर सकते। यदि आप ऐसी मेमोरी चाहते हैं जिसे आप cat के साथ पढ़ सकें और git में कमिट कर सकें, तो Memmy की प्लेन लोकल मेमोरी फ़ाइलें इसके विपरीत विकल्प हैं। दोनों ही उचित हैं, यह इस पर निर्भर करता है कि आप लैपटॉप चोरी होने से डरते हैं या किसी ऐसे टूल के खराब होने से जो काम करना बंद कर दे।

compartment uninstall सॉफ़्टवेयर को हटा देता है और वॉल्ट को सुरक्षित रखता है। --purge केवल तभी पास करें जब आप वास्तव में ऐसा करना चाहते हों।

एजेंट के साथ जोड़ना

एक कमांड समर्थित क्लाइंट को जोड़ देती है।

compartment integrate --list
compartment integrate claude

Claude Code के लिए, जो एक MCP (model context protocol) सर्वर एंट्री और एक PostToolUse हुक को ~/.claude/settings.json में लिखता है, पहले फाइल का बैकअप लेता है, /compartmentalize स्किल को ~/.claude/skills/ के अंतर्गत इंस्टॉल करता है, और ~/.claude/CLAUDE.md में एक मैनेज्ड ब्लॉक जोड़ता है जो एजेंट को बताता है कि Compartment उस फाइल-आधारित मेमोरी की जगह ले रहा है जिसका वह उपयोग कर रहा था। दोनों हिस्सों की पुष्टि करें:

compartment hook status
compartment recent

सर्वर को मैन्युअल रूप से रजिस्टर करने के लिए:

claude mcp add --scope user compartment -- \
    compartment --vault ~/.compartment/memory.vault --caller claude-code serve

कोई भी अन्य MCP-सक्षम होस्ट उसी सर्वर को अपने स्वयं के कॉलर नाम के साथ स्वीकार करता है।

{ "mcpServers": { "compartment": {
    "command": "compartment",
    "args": ["--vault", "/path/to/memory.vault",
             "--caller", "your-agent-name", "serve"] } } }

प्रत्येक होस्ट को एक अलग --caller मान दें। यह वह लेबल है जिसे ऑडिट लॉग रिकॉर्ड करता है और वह कुंजी है जिसके विरुद्ध नेमस्पेस ग्रांट लिखे जाते हैं, इसलिए एक साझा नाम दोनों को बेकार बना देता है।

यदि Claude Code पहले से ही अपनी मेमोरी फाइलों में तथ्य लिख रहा है, तो compartment import-claude --dry-run यह दिखाता है कि कुछ भी स्थानांतरित होने से पहले क्या स्थानांतरित होगा। पहले Claude Code अपनी मेमोरी फाइलों में क्या रखता है पढ़ें, क्योंकि एक साल के नोट्स को एक नए वॉल्ट में इम्पोर्ट करने से मेमोरी स्टोर उन चीजों से भर जाता है जिन्हें कोई भी रखना नहीं चाहता था।

Local vault कितना तेज़ है

ये वे आंकड़े हैं जिन्हें प्रोजेक्ट एक व्यक्तिगत आकार के vault के लिए प्रकाशित करता है। ये आंकड़े इसके documentation से लिए गए हैं, न कि यहाँ किए गए किसी परीक्षण से।

[
  {
    "label": "Store one memory, end to end",
    "latency_ms": 40
  },
  {
    "label": "Embed one memory, bundled model",
    "latency_ms": 25
  },
  {
    "label": "Hybrid search, median",
    "latency_ms": 11.6
  },
  {
    "label": "Vector search at 20k records, p95",
    "latency_ms": 0.68
  }
]

एक memory को स्टोर करने में 40 ms का समय लगता है, और बीस हज़ार records में vector search करने में 95th percentile के लिए 0.68 ms का समय लगता है। memory को local रखने के पक्ष में प्रोजेक्ट का तर्क गणितीय है: एक hosted memory API तक एक बार का network round trip अक्सर यहाँ पूर्ण hybrid search के 11.6 ms median से अधिक महंगा पड़ता है।

दो design विवरण search के इन आंकड़ों की व्याख्या करते हैं। बीस हज़ार records से नीचे, Compartment query की तुलना हर vector से करता है, इसलिए recall अनुमानित होने के बजाय संरचनात्मक रूप से सटीक होता है। उससे ऊपर, यह HNSW (hierarchical navigable small world) पर स्विच हो जाता है, जो एक approximate index है और गति के लिए recall में थोड़ी कमी करता है। vault embedding model के SHA-256 hash को भी record करता है और किसी भिन्न model के तहत खुलने से इनकार कर देता है, क्योंकि दो अलग-अलग models के vectors की तुलना बिना किसी त्रुटि के की जा सकती है, और प्राप्त होने वाले scores का कोई अर्थ नहीं होता।

Backups, और वह कॉपी जिसे आप अगले साल भी खोल सकें

एक locked vault एक पोर्टेबल फाइल होती है, इसलिए इसे कहीं और ले जाना केवल एक कॉपी बनाना है।

compartment lock
scp ~/.compartment/memory.vault other-machine:
compartment --vault memory.vault unlock

इसे पहले lock करें। यदि आप agent के लिखते समय ही कॉपी करते हैं, तो हो सकता है कि journal entry बीच में ही copy हो जाए। हालाँकि CRC framing के कारण reader उस अधूरे हिस्से को छोड़ सकता है, लेकिन उसके अंदर की memory खो जाती है। compartment lock --sign फाइल को एक Ed25519 manifest के साथ seal करता है, ताकि प्राप्त करने वाली मशीन बिना passphrase के यह verify कर सके कि कॉपी सही सलामत पहुँची है।

चूँकि फाइल पहले से ही sealed है, इसलिए सामान्य cloud storage इसके लिए एक स्वीकार्य स्थान है। यही वह बिंदु है जहाँ encryption at rest का लाभ सीधे मिलता है: backup target कभी भी memory को देख नहीं पाता।

दो चेतावनियाँ। Shredding का असर backups पर नहीं होता, इसलिए जिसे आपने आज crypto shred किया है, वह पिछले सप्ताह की कॉपी में किसी भी ऐसे व्यक्ति के लिए पठनीय रहेगा जिसके पास पिछले सप्ताह का passphrase है। और compartment export --plaintext पूरी vault को unencrypted रूप में लिखता है, जो किसी अन्य चीज़ पर migrate करने के लिए तो सही tool है, लेकिन ~/Downloads में छोड़ने के लिए यह गलत फाइल है।

कुछ ही कॉपियाँ रखें और उन पर तारीख डालें। यदि कोई memory store को साफ़ (prune) नहीं करता है, तो वह एक दायित्व (liability) बन जाता है, और यही वह तर्क है जो why stale agent memories quietly poison retrieval में दिया गया है।

Key handling, rotation, और second factor

compartment rekey
compartment 2fa enable
compartment 2fa status

rekey वर्तमान फाइल के keyslot में master key को फिर से wrap करके passphrase बदलता है। पुरानी प्रतियों में पुराना passphrase ही रहता है, क्योंकि वे bytes बदलाव से पहले ही seal हो चुके थे और उन्हें edit करने का कोई तरीका नहीं है। प्रतियों को भी rotate करें, या यह स्वीकार करें कि एक पुराना passphrase अभी भी किसी फाइल को खोल सकता है।

2fa enable एक keyfile को second factor के रूप में जोड़ता है, जो key derivation के दौरान passphrase के साथ मिल जाता है, इसलिए vault खोलने के लिए दोनों की आवश्यकता होती है। इससे उन चीजों की संख्या भी दोगुनी हो जाती है जिन्हें आप खो सकते हैं। Keyfile को उस मशीन से दूर रखें जिस पर vault मौजूद है।

Scripts और CI (continuous integration) के लिए, passphrase को COMPARTMENT_PASSPHRASE environment variable के माध्यम से भेजा जा सकता है, और unlock --passphrase-stdin इसे pipe से पढ़ता है। Pipe का उपयोग करना बेहतर है। Environment variable को उसी user के स्वामित्व वाली अन्य प्रक्रियाओं द्वारा पढ़ा जा सकता है, और यह अक्सर job logs में भी दर्ज हो जाता है।

Audit history hash chained होती है, और compartment audit verify इसे scan करके पहली टूटी हुई link की रिपोर्ट देता है। इसे किसी भी restore के बाद चलाएं, क्योंकि तभी एक silently truncated फाइल का पता चलता है।

जब आप passphrase खो देते हैं तो क्या होता है

कुछ नहीं होता है, और यही इसका डिज़ाइन है। इसमें कोई reset, कोई recovery phrase, और संपर्क करने के लिए कोई पता नहीं होता है, क्योंकि आपकी memory और वैकल्पिक keyfile के बाहर key की कोई प्रतिलिपि मौजूद नहीं होती है। vault केवल random दिखने वाले bytes की एक file बना रहता है।

इसलिए recovery plan, vault के लिए नहीं होता है। यह passphrase के लिए एक plan होता है। जिस दिन आप compartment init चलाते हैं, उसी दिन इसे एक password manager में दर्ज करें। फिर इसका परीक्षण करें: vault को lock करें, केवल वही उपयोग करके इसे unlock करें जो आपने लिखा है, और उसके काम करने के बाद एक agent को इसे भरना शुरू करने दें।

Compartment या memory server

Compartment को डिज़ाइन के अनुसार एक ही मशीन पर चलने के लिए बनाया गया है। इसे साझा करने का अर्थ है locked file को कॉपी करना या export/import करना। इसमें concurrent writer की सुविधा नहीं है, इसलिए यदि एक laptop और एक workstation एक ही file का उपयोग करेंगे, तो वे एक-दूसरे के काम को overwrite कर देंगे।

जब कई मशीनों को एक ही समय में एक ही memory की आवश्यकता होती है, तो यह एक server से संबंधित समस्या बन जाती है। VPS पर self-hosted Mem0 memory server इसका समाधान है: एक endpoint, कई clients, और ऐसी memory जो laptop के बंद होने के बाद भी बनी रहती है। इसकी लागत को स्पष्ट रूप से समझना आवश्यक है। वह server एक ऐसी process चलाता है जो अपने द्वारा संग्रहीत डेटा को पढ़ सकता है, इसलिए अब आपके threat model में वह VPS और उस API तक पहुँच रखने वाला कोई भी व्यक्ति शामिल हो जाता है।

उस नुकसान के आधार पर चुनाव करें जिसका आपको वास्तव में डर है। यदि डर laptop चोरी होने या किसी vendor द्वारा आपके notes पढ़ने का है, तो encrypted local vault एक बेहतर विकल्प है। यदि समस्या यह है कि मशीन बदलते ही आप सब कुछ भूल जाते हैं, तो server का उपयोग करना सही है।

FAQ

Compartment का एन्क्रिप्शन वास्तव में क्या सुरक्षित करता है?

यह फाइल को सुरक्षित करता है। Vault को XChaCha20-Poly1305 के साथ सील किया जाता है, इसके keyslots को Argon2id के साथ रैप किया जाता है, और embedding vectors भी एन्क्रिप्टेड होते हैं। इसलिए, चोरी हुई डिस्क या पुराना बैकअप केवल ऐसे बाइट्स प्रदान करता है जिन्हें पढ़ा नहीं जा सकता। यह चलते हुए मशीन पर अनलॉक किए गए vault को सुरक्षित नहीं करता है, क्योंकि vault खुलने के दौरान master key RAM में रहती है। साथ ही, यह इस बात को नियंत्रित नहीं करता है कि recall के बाद plaintext के रूप में प्राप्त जानकारी का agent क्या करता है।

यदि Compartment ऑफलाइन है, तो क्या मेरी यादें मेरे मॉडल प्रदाता से निजी रहती हैं?

केवल तब तक जब तक उन्हें recall नहीं किया जाता। स्टोरेज और सर्च बिना नेटवर्क के होते हैं और embedding model स्थानीय रूप से चलता है, इसलिए लिखते समय मशीन से कुछ भी बाहर नहीं जाता है। पढ़ते समय agent को plaintext प्राप्त होता है, और यदि वह agent एक hosted मॉडल है, तो वह याद context window के बाकी हिस्सों की तरह prompt में शामिल होकर प्रदाता के पास चली जाती है। किसी भी credential को कभी भी याद (memory) के रूप में स्टोर न करें।

यदि मैं अपना Compartment पासफ्रेज खो दूँ तो क्या होगा?

Vault को रिकवर नहीं किया जा सकता, यह जानबूझकर ऐसा रखा गया है। Compartment कोई seed या recovery phrase उत्पन्न नहीं करता है और आपके पास मौजूद credential के अलावा कोई अन्य जानकारी नहीं रखता है, इसलिए रीसेट करने के लिए कुछ भी नहीं है। पासफ्रेज को एक password manager में रखें, किसी भी 2FA keyfile को उस मशीन से दूर रखें जहाँ vault स्टोर है, और यह सुनिश्चित करें कि vault में कोई महत्वपूर्ण डेटा रखने से पहले आप उसकी एक कॉपी को अनलॉक कर सकते हैं।

क्या दो मशीनें एक Compartment vault साझा कर सकती हैं?

एक ही समय पर नहीं। एक locked vault एक एकल पोर्टेबल फाइल होती है, और अनुशंसित तरीका यह है कि इसे lock करें, कॉपी करें, और फिर दूसरी मशीन पर --vault के साथ अनलॉक करें। इसमें concurrent access की सुविधा नहीं है, इसलिए यदि दो मशीनें एक ही फाइल में लिखेंगी तो यादें खो जाएंगी। जब आपको इसकी आवश्यकता हो, तो एक memory server चलाएं।