Memmy: memoria condivisa per agenti AI su VPS

Che cos’è Memmy e cosa archivia

Memmy è un hub di memoria locale per agenti AI che viene eseguito sul proprio VPS (virtual private server). Conserva un unico database SQLite con ciò che gli agenti hanno appreso; ogni agente presente sul server legge e scrive nello stesso archivio. Il progetto è memmy-agent di MemTensor, distribuito con licenza MIT, alla versione 1.2.401 al 1 novembre 2026; Memory segue una numerazione di versione indipendente ed è alla versione 2.1.7.

Su un server interessa soltanto una parte del progetto. Memmy distribuisce un servizio di memoria in ascolto su http://127.0.0.1:18960, un’interfaccia memmy-memory a riga di comando (CLI) che comunica con il servizio e un workbench desktop. Il workbench è disponibile solo per macOS e Windows; su un VPS Linux si eseguono quindi il servizio e la CLI. È sufficiente per fornire una memoria condivisa a Claude Code, Codex e Cursor.

Memmy organizza i dati archiviati in quattro livelli. Capture salva prima un Raw Turn separato, quindi scrive un elemento L1 Trace per ogni passaggio acquisito, incluse richieste, risposte, chiamate agli strumenti e risultati. L2 Policy è una procedura derivata dalle tracce che si è dimostrata utile. L3 World Model contiene conoscenze stabili su un progetto o un ambiente. Skill è una procedura richiamabile, consolidata a partire da una policy. Capture crea le tracce L1, i processi in background fanno evolvere i livelli superiori e le scritture esplicite possono selezionare un livello. Se queste distinzioni sembrano astratte, la memoria è una delle fasi successive di un percorso graduale per imparare a creare agenti e i livelli diventano più chiari dopo aver scritto personalmente un semplice ciclo di esecuzione di un agente e averne osservato la perdita completa dello stato tra un’esecuzione e l’altra.

Cosa cambia un hub di memoria condivisa rispetto alla memoria specifica di ogni strumento

Oggi ogni agent dispone di una propria memoria. Claude Code conserva i file delle istruzioni nel repository. Cursor conserva le regole nel database del workspace. Codex conserva i log delle sessioni in ~/.codex. Ogni archivio appartiene a uno strumento, quindi un’informazione insegnata lunedì in uno strumento non è disponibile martedì in un altro. Questo comporta un doppio costo: i token usati per spiegare di nuovo lo stesso progetto e il lavoro errato eseguito da un agent sulla base di un’ipotesi che avevi già corretto altrove.

Un hub sposta l’archivio fuori dallo strumento. Memmy legge anche gli archivi esistenti, quindi non devi partire da un database vuoto. Il relativo scanner conosce dieci origini integrate: Claude Code in ~/.claude/projects/**/*.jsonl, Codex in ~/.codex/sessions/<YYYY>/<MM>/<DD>/rollout-*.jsonl, OpenCode in ~/.local/share/opencode/opencode.db, i file state.vscdb di Cursor, i database SQLite di OpenClaw in ~/.openclaw, Hermes in ~/.hermes, DeepSeek Harness in ~/.dsh/sessions, WorkBuddy in ~/.workbuddy/projects, Pi in ~/.pi/agent/sessions e QwenWork in ~/.qwenworkcn/projects. Il workbench desktop può aggiungere un altro agent per nome e chiede il percorso della relativa cronologia solo quando non riesce a individuare autonomamente l’agent. Lo scanner lato server non dispone di origini personalizzate, quindi su un VPS headless sono disponibili quelle integrate.

I contatori dell’importazione non coincideranno, ed è previsto. Lo scanner raggruppa i messaggi per origine e conversazione, quindi scrive una memoria L1 per ogni turno completo. Un turno è completo quando contiene contenuto non vuoto dell’utente e termina con un messaggio non vuoto dell’assistant; un turno incompleto non contribuisce finché una sincronizzazione successiva non può completarlo. I messaggi vengono deduplicati tramite checkpoint delle conversazioni e ID stabili dei turni. Nella stessa esecuzione differiscono il numero di elementi analizzati, il numero di messaggi importati e il numero di nuove memorie.

Questa è la parte complementare a come Claude Code gestisce il contesto all’interno di una singola sessione. La gestione del contesto decide cosa può rientrare in una singola finestra. Un hub di memoria decide cosa rimane disponibile dopo la chiusura della finestra.

Cosa serve sul VPS

• Node.js 22 o versione successiva. La documentazione di Memmy lo richiede, mentre Ubuntu 24.04 include Node 18.
• git e una toolchain di compilazione, perché better-sqlite3 è un modulo nativo che potrebbe essere compilato durante l'installazione.
• RAM sufficiente per l'installazione del workspace root e per la relativa toolchain di build frontend.
• Spazio su disco sufficiente per node_modules e per il database.

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 --version

node --version dovrebbe restituire v22 o una versione successiva per la build dai sorgenti descritta nella documentazione. Un valore v18 indica che il passaggio NodeSource non è stato applicato. Il valore predefinito di npm per engine-strict è false, quindi una dichiarazione engine incompatibile normalmente genera un avviso invece di interrompere automaticamente l'installazione.

Installare Memmy dal codice sorgente su Ubuntu 24.04

git clone https://github.com/MemTensor/memmy-agent.git
cd memmy-agent
cp .env.example .env
npm install
npm run memory:build

npm run memory:build compila lo spazio di lavoro @memmy/memory in Memory/dist. Compila inoltre AgentSourceCore, il visualizzatore della memoria e gli asset di integrazione richiesti da quello spazio di lavoro. Verificare che il modulo nativo sia stato caricato:

node -e "const Database = require('better-sqlite3'); const db = new Database(':memory:'); db.close(); console.log('better-sqlite3 loads')"

Se quella riga genera un errore invece di stampare un risultato, leggere il messaggio per identificare il problema di caricamento o di inizializzazione del database. In caso di incompatibilità del modulo nativo, eseguire npm rebuild better-sqlite3. È esattamente il comando eseguito dallo script di avvio del progetto prima di avviare qualsiasi componente.

Il README documenta bash scripts/dev-start.sh come comando di avvio unico. Non eseguirlo su un VPS headless. Avvia la shell desktop Electron e un server di sviluppo Vite sulla porta 19000 insieme al servizio di memoria. Electron richiede un display, quindi su un server senza sessione grafica lo script si blocca o termina.

Le release recenti includono inoltre memmy-agent-linux-cli.tar.gz e un install.sh per Linux x64 e arm64. L'installer richiede Node.js 22.23.4+ nella serie 22.x, 24.22.1+ nella serie 24.x oppure 26.12.1+ nella serie 26.x, oltre a una sessione utente systemd. Rifiuta le altre versioni principali. Inserisce i launcher memmy e memmy-memory in ~/.local/bin e avvia il servizio di memoria come unità utente su 127.0.0.1:18960. Questa guida mantiene la compilazione dal codice sorgente perché consente di leggere ogni script prima della sua esecuzione.

Avviare il servizio di memoria e verificare che risponda

npm run memory:serve:dev

Questo è il metodo documentato per eseguire il servizio di memoria dal codice sorgente. Si associa a 127.0.0.1:18960, mantiene il database in ~/.memmy/memory-service/memory.sqlite e legge la configurazione da ~/.memmy/config.yaml. Il server accetta gli stessi valori come flag, se vuoi specificarli in modo esplicito:

npm run memory:serve:dev -- \
  --host 127.0.0.1 --port 18960 \
  --db ~/.memmy/memory-service/memory.sqlite \
  --config ~/.memmy/config.yaml

Da una seconda shell, chiedi al servizio se è attivo:

curl -sS http://127.0.0.1:18960/api/v1/health

Il controllo dello stato non richiede un token, perciò è la sonda corretta. Se curl termina con il codice 7 e un messaggio Failed to connect to 127.0.0.1 port 18960, la connessione non è riuscita; questo, da solo, non dimostra se esiste un listener. Controlla indirizzo, porta e firewall locale, quindi leggi il terminale in cui è in esecuzione il servizio per individuare eventuali errori di avvio. ss -lntp | grep 18960 conferma il socket quando il servizio è attivo.

Il resto dell'API HTTP (application programming interface) si trova sotto /api/v1.

• POST /api/v1/memory/add scrive una memoria e POST /api/v1/memory/search esegue query.
• GET /api/v1/memory/:id e DELETE /api/v1/memory/:id leggono e rimuovono una voce.
• POST /api/v1/sessions/open e POST /api/v1/sessions/:sessionId/close delimitano una sessione dell'agente.
• POST /api/v1/turns/start e POST /api/v1/turns/:turnId/complete registrano un turno.
• GET /api/v1/panel/overview, /api/v1/panel/analysis e /api/v1/panel/items alimentano il dashboard.

Memmy riserva un blocco di porte e, in modalità headless, ne usi soltanto la prima: 18960 per la memoria, 18970 per lo stato del gateway, 18980 per l'interfaccia web e l'HTTP di amministrazione, 18990 per l'API compatibile con OpenAI avviata da memmy serve, quindi 19000 per il server di sviluppo Vite del frontend desktop e 19001 per il socket di hot reload. La pagina delle porte del progetto indica ancora 19010 per l'hot reload, ma la configurazione Vite imposta 19001. Se una di queste porte è già occupata sul tuo sistema, questo è il punto in cui verificare.

Da dove proviene effettivamente il comando memmy-memory

È in questa fase che una prima installazione tende a non funzionare, quindi leggete il pacchetto invece di fare supposizioni. Il nome del comando non ha alcun rapporto con il nome del repository. Proviene dal campo bin del workspace che lo definisce:

node -p "JSON.stringify(require('./Memory/package.json').bin)"

Questo comando stampa {"memmy-memory":"./dist/src/cli/index.js"}. Il punto di ingresso compilato è quindi Memory/dist/src/cli/index.js e viene creato solo dopo npm run memory:build, perché è la compilazione a creare dist e a impostare il file come eseguibile. Eseguitelo direttamente:

node Memory/dist/src/cli/index.js health

Se volete usare il nome breve nel PATH, create un link allo stesso file:

sudo ln -s "$PWD/Memory/dist/src/cli/index.js" /usr/local/bin/memmy-memory
memmy-memory health

Per impostazione predefinita, la CLI usa http://127.0.0.1:18960 e accetta --url, --token, --config, --source e --user-id. I relativi sottocomandi sono init, health, search, add, get e delete, oltre alle chiamate di sessione e di turno usate dagli agenti anziché dagli utenti, e a install, upgrade, service e stop per gestire direttamente il servizio. memmy-memory search "deploy steps" e memmy-memory add "staging migrates on deploy" sono i due comandi eseguiti più spesso da un agente.

Come si collega Claude Code a Memmy?

Memmy non si registra come server all’interno di Claude Code. Si collega tramite file che Claude Code legge già, e la portata dell’integrazione dipende da quale memmy-memory esegui. Da un checkout del sorgente, memmy-memory init --agent claude scrive una Skill memmy-memory in ~/.claude/skills/ e un blocco di memoria contrassegnato in ~/.claude/CLAUDE.md; Claude Code esegue quindi memmy-memory come un normale comando shell quando le istruzioni glielo indicano. Il launcher che l’installer Linux inserisce in ~/.local/bin fa un passo ulteriore: lo stesso comando registra anche gli hook in ~/.claude/settings.json per SessionStart, UserPromptSubmit, Stop, PostCompact e SessionEnd. Questi hook iniettano la memoria pertinente e salvano ogni turno completato senza che il modello debba decidere di farlo.

Scrivi manualmente l’istruzione una volta, così sai esattamente cosa è stato comunicato all’agente. Claude Code legge CLAUDE.md dalla root del progetto all’inizio di ogni sessione. Nel percorso del sorgente, l’integrazione completa consiste quindi in una sezione come questa:

## 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.

Definisci chiaramente cosa ottieni. Senza gli hook, l’integrazione opera a livello di istruzioni: funziona quando il modello decide di eseguire il comando, e non altrimenti. Nulla forza l’esecuzione. Se una sessione termina senza add, l’istruzione non ha salvato nulla; una scansione successiva della cronologia può comunque importare il turno completato. È lo stesso compromesso dei file di memoria propri di Claude Code, con una differenza: lo store è condiviso, quindi la nota raggiunge anche Codex e Cursor sulla stessa macchina. Gli hook colmano questa lacuna invece di limitarsi a richiedere l’operazione. Per questo la memoria persistente figura insieme ai limiti di budget e alle regole di autorizzazione tra i plugin di DeepSeek Harness che vale la pena installare.

Il percorso inverso non richiede alcuna configurazione. Lo scanner di Memmy legge già ~/.claude/projects/**/*.jsonl, ovvero la posizione in cui Claude Code scrive le trascrizioni delle sessioni. Esegui Memmy sullo stesso server in cui esegui Claude Code all’interno di una sessione tmux: il lavoro del giorno precedente diventa memoria senza configurare altro.

Memmy funziona come server MCP per Claude Code?

No, e conoscere questa distinzione fa risparmiare tempo. MCP (model context protocol) prevede client e server. Memmy è un client. Si connette ai server MCP e rende disponibili i relativi strumenti al proprio runtime dell'agente. Non espone un endpoint MCP a cui claude mcp add possa connettersi. L'unico bridge MCP nel repository appartiene all'integrazione Composio all'interno dell'API locale desktop, e questa API si associa a una porta casuale su 127.0.0.1 dietro la propria intestazione x-memmy-mcp-token.

Il lato client è configurato in ~/.memmy/config.yaml, il file indicato da MEMMY_CONFIG, in tools.mcpServers:

tools:
  mcpServers:
    example:
      type: stdio
      command: npx
      args:
        - "-y"
        - "your-mcp-server"
      toolTimeout: 30
      enabledTools:
        - "*"

type accetta stdio, sse e streamableHttp. Un server stdio viene eseguito come processo figlio di Memmy. Il relativo comando deve quindi essere disponibile sullo stesso computer ed essere eseguito dallo stesso utente. Se mantieni già server MCP in esecuzione su un VPS, sono questi i server da elencare qui.

Mantenere privato l’archivio della memoria

Tutto ciò che Memmy possiede si trova in ~/.memmy: config.yaml, l’area di lavoro, memory-service/memory.sqlite e i file di runtime. La scansione e l’acquisizione dei dati avvengono localmente e le memorie vengono scritte nel file SQLite locale. La configurazione predefinita è quindi realmente locale.

La connessione cloud è un percorso da controllare. MEMMY_CLOUD_SERVICE identifica l’origine cloud. Il codice non definisce alcun valore predefinito, ma .env.example, che i passaggi di installazione copiano in .env, la imposta su https://api.memmy.cn. Questa configurazione abilita la modalità account con i relativi token di prova. Quando è impostata, il codice di analisi di Memmy invia a tale origine anche gli eventi di utilizzo, inclusa la modalità con API key: nomi degli eventi e dei comandi, versioni e un ID dell’installazione. La CLI segnala soltanto parole di comando fisse, mai le query di ricerca o il testo delle memorie. Il codice di analisi non invia nulla quando il valore non è impostato. Su un server che usa soltanto API key, quindi, svuota quella riga in .env prima di avviare qualsiasi servizio. Il programma di miglioramento della memoria è un’impostazione separata nelle preferenze sulla privacy.

Le chiamate ai modelli costituiscono un altro percorso. Se configuri un provider di embedding ospitato, il testo della memoria da incorporare viene inviato a quel provider affinché possa essere convertito in un vettore. Lo storage locale non impedisce questo invio. Per chiudere il percorso, usa il provider di embedding locale integrato oppure un endpoint di embedding gestito da te. Anche i modelli ospitati per i riepiloghi, l’evoluzione e il filtraggio per rilevanza ricevono il contenuto delle memorie quando vengono eseguiti questi processi. Controlla quindi anche le relative impostazioni dei modelli.

Mantieni la porta 18960 sull’indirizzo di loopback. Non serve alcuna regola firewall, perché un servizio associato a 127.0.0.1 non è raggiungibile dall’esterno del server. Puoi raggiungerlo dal laptop tramite SSH:

ssh -N -L 18960:127.0.0.1:18960 you@your-vps

Il servizio di memoria attuale rifiuta gli indirizzi di bind diversi da loopback. Impostare storage.token nella configurazione, oppure la variabile d’ambiente MEMMY_MEMORY_TOKEN o MEMORY_SERVICE_TOKEN, protegge con un bearer token le normali chiamate all’API della memoria. L’endpoint di health resta non autenticato e il visualizzatore nel browser usa controlli separati per le richieste locali. I valori di configurazione supportano riferimenti ${ENV_NAME}, quindi il token e le API key dei modelli non vengono salvati direttamente nel file. È la stessa pratica descritta in mantenere i secret fuori dagli agenti AI in tutto il sistema, mentre una policy ufw predefinita deny costituisce una protezione aggiuntiva nel caso in cui una versione futura cambi l’indirizzo di bind predefinito.

Esegui il backup di ~/.memmy prima di considerarlo affidabile

memory.sqlite è l'intero archivio. I vettori risiedono nello stesso file tramite l'estensione sqlite-vec, quindi il backup consiste in un unico file. Copiarlo con cp mentre il servizio sta scrivendo può produrre un database incoerente. Usa il comando di backup integrato in SQLite:

mkdir -p ~/memmy-backup
sqlite3 ~/.memmy/memory-service/memory.sqlite ".backup '$HOME/memmy-backup/memory.sqlite'"

In questo modo ottieni una copia coerente mentre il servizio continua a funzionare. Trasferiscila fuori dal server secondo una pianificazione; è proprio questo lo scopo di restic per lo storage off-site. La perdita di config.yaml comporta la necessità di reinserire le impostazioni del provider. La perdita di memory.sqlite comporta la perdita dei ricordi registrati dall'ultimo backup utilizzabile; il servizio crea inoltre un backup locale prima delle migrazioni dello schema, ma non si tratta di una copia off-site aggiornata.

Eseguire il servizio di memoria con systemd

npm run memory:serve:dev eseguito in una shell termina insieme alla shell. Un file unit mantiene il servizio attivo anche dopo i riavvii. Il servizio viene eseguito con l'utente memmy, usa un checkout in /opt/memmy e la relativa configurazione nella home di quell'utente. Arresta la copia in esecuzione nella shell, quindi sposta il checkout e la configurazione e aggiorna il collegamento memmy-memory:

sudo useradd -m -s /bin/bash memmy
sudo mkdir -p /opt/memmy
sudo mv ~/memmy-agent /opt/memmy/memmy-agent
sudo chown -R memmy:memmy /opt/memmy
sudo ln -sfn /opt/memmy/memmy-agent/Memory/dist/src/cli/index.js /usr/local/bin/memmy-memory
sudo install -d -o memmy -g memmy -m 700 /home/memmy/.memmy
sudo install -o memmy -g memmy -m 600 ~/.memmy/config.yaml /home/memmy/.memmy/config.yaml
sudo install -d -m 755 /etc/memmy

Il servizio archivia il database in /home/memmy/.memmy, quindi viene avviato con uno store vuoto.

[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.target

Non inserire il token nella unit. Salvalo in /etc/memmy/memory.env, assegnalo a root e imposta i permessi a 600:

MEMMY_CONFIG=/home/memmy/.memmy/config.yaml
MEMMY_MEMORY_TOKEN=replace-this-with-a-long-random-string

sudo 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/health

La presenza di status=203/EXEC nell'output di stato indica che systemd non è riuscito a eseguire ExecStart, quindi controlla which npm: in un'installazione NodeSource si trova in /usr/bin/npm, mentre con nvm si trova in una directory nella home dell'utente, che systemd non individua. Se una unit viene avviata e termina subito, controlla lo stato di uscita e il journal: il codice 0 indica una terminazione corretta, mentre gli altri risultati includono terminazioni con codice diverso da zero, segnali e timeout. Esegui journalctl -u memmy-memory -n 50 per visualizzare l'output del servizio. La procedura è la stessa di qualsiasi altro servizio systemd su un VPS.

Il progetto offre ora due alternative a livello utente. Per una compilazione dai sorgenti, il percorso indicato nel README è memmy-memory install --service-only: scarica la versione bloccata di Memory e registra un servizio utente. L'installer Linux configura memmy-memory.service come unit systemd --user. Nessuna delle due alternative abilita linger. Esegui sudo loginctl enable-linger <user> per mantenere in esecuzione il service manager dell'utente dopo il logout e avviarlo al boot.

Cosa non fa ancora Memmy

• Non esiste una build desktop per Linux. Gli script di packaging coprono macOS e Windows, quindi il workbench e la relativa procedura guidata di onboarding non sono disponibili direttamente sul server. Il servizio di memoria include ora un visualizzatore nel browser all'indirizzo http://127.0.0.1:18960/viewer/, raggiungibile tramite il tunnel SSH indicato sopra. Per Linux sono invece disponibili un archivio tarball della CLI e install.sh.
• memory:serve:dev esegue l'entry point TypeScript tramite tsx, un percorso di sviluppo. Il repository include anche memory:serve per l'output compilato. Esegui npm run senza argomenti per verificare quali script sono effettivamente disponibili nel tuo checkout.
• Il recupero costruisce la finestra di ricerca a partire dalle 2,000 righe vettoriali più recenti, quindi applica la selezione Top-K all'interno di quella finestra. In uno store molto grande, una memoria obsoleta può trovarsi al di fuori della finestra.
• La generazione degli embedding avviene dopo l'acquisizione e gli errori vengono inseriti in una coda di retry, invece di bloccare il turno dell'agente. Una memoria aggiunta poco prima potrebbe non essere ancora individuabile tramite la ricerca vettoriale.
• Un secondo server con un proprio database SQLite locale dispone di una memoria separata.

La versione 1.2.401, aggiornata al 1 novembre 2026, descrive ancora un progetto giovane che evolve rapidamente. Flag, percorsi e nomi degli script cambiano tra le release. Leggi il campo bin e l'output di npm run nel tuo checkout, invece di fidarti di un comando copiato da qualsiasi fonte, incluso questo documento.

FAQ

Perché il controllo dello stato restituisce «connection refused»?

Un codice di uscita 7 di curl con Failed to connect to 127.0.0.1 port 18960 indica una connessione non riuscita, ma non specifica se Memmy è arrestato, terminato in modo anomalo, in ascolto su un altro indirizzo o non accessibile. Controlla l'indirizzo e la porta, esegui ss -lntp | grep 18960 e leggi il terminale o il journal in cui è stato avviato il servizio. Se il log segnala una mancata corrispondenza del modulo SQLite nativo, esegui npm rebuild better-sqlite3. Controlla anche la versione di Node: la documentazione sorgente richiede Node 22 o versioni successive, mentre l'installer Linux accetta solo Node.js 22.23.4+ nella serie 22.x, 24.22.1+ nella serie 24.x oppure 26.12.1+ nella serie 26.x.

Da dove proviene il comando memmy-memory dopo la compilazione dal codice sorgente?

Dal campo bin del pacchetto workspace @memmy/memory, non dal nome del repository. Esegui node -p "JSON.stringify(require('./Memory/package.json').bin)" nella directory del checkout: il comando stampa {"memmy-memory":"./dist/src/cli/index.js"}. Il file esiste solo dopo npm run memory:build, perché la compilazione crea dist e imposta il file come eseguibile. Eseguilo come node Memory/dist/src/cli/index.js health oppure crea un link simbolico in /usr/local/bin per usare il nome breve.

Posso aggiungere Memmy a Claude Code con claude mcp add?

No. Memmy è un client MCP, non un server MCP. Stabilisce connessioni in uscita verso i server elencati in tools.mcpServers all'interno di ~/.memmy/config.yaml e rende disponibili i relativi strumenti al proprio runtime. Claude Code raggiunge Memmy nell'altro verso, eseguendo la CLI memmy-memory come comando shell. memmy-memory init --agent claude scrive una Skill e un blocco CLAUDE.md che specificano quando utilizzarla; inoltre, il launcher dell'installer Linux aggiunge hook di Claude Code che salvano automaticamente le interazioni.

L'esecuzione di Memmy invia i miei ricordi a un servizio cloud?

La scansione e l'acquisizione dei dati vengono eseguite localmente e i ricordi vengono scritti in ~/.memmy/memory-service/memory.sqlite sul disco locale. MEMMY_CLOUD_SERVICE, impostato su https://api.memmy.cn in .env.example, gestisce la modalità account e i token di prova e riceve dati analitici sull'utilizzo, senza il testo dei ricordi, finché l'impostazione resta attiva; svuotalo quindi se usi soltanto chiavi API. Il programma di miglioramento della memoria dispone di un'impostazione separata per la privacy. Un modello di embedding ospitato riceve il testo del ricordo che converte in un vettore; per mantenere questa elaborazione in locale, usa il provider locale integrato oppure un endpoint gestito da te. Anche i modelli ospitati per i riepiloghi, l'evoluzione e il filtraggio della rilevanza ricevono il contenuto dei ricordi quando vengono eseguiti i relativi job.