A gate, not a store.
One shared memory of you that every AI agent reads from and writes to — kept honest at write time, so it stays small, current, and contradiction-free instead of bloating with junk.
$ npx jamgate setup
Wires Jamgate into every MCP client on your machine — Claude Code, Claude Desktop, Cursor, Windsurf. Idempotent and backup-first.
Shared memory is easy. Keeping it clean is the hard part.
You are one person, but every AI you use is a separate island — you re-explain "what I'm working on" every time. The tools that fix this mostly store everything, so the shared memory bloats with junk: duplicates, stale states, one-off chatter.
One production audit of a leading memory system found 97.8% of its stored entries were junk — duplicates, trivia, one-off chatter, stale states. Jamgate sits in the write path and decides what deserves to be remembered before it is stored.
A hybrid pipeline — cheapest checks first.
A memory is kept only if it is durable (still true after this session) and would change a future answer. The gate's main "is this worth remembering?" filter is the calling agent's own understanding — no extra LLM call of Jamgate's own. Around that sit deterministic layers:
Rule pre-filter
Drops obvious non-durable noise — "I'm on a call now", "run this command" — before it ever reaches the store. The cheapest check, run first.
Exact dedup
Identical facts are never stored twice. If it's already known, the save is dropped — the store never accumulates copies of the same thing.
Time-aware supersession
Every memory is a timestamped event. A newer fact retires an older one on the same subject by recency — no contradiction pile-up, and it never throws your own stale words back at you.
Trust-hierarchy conflict guard
A lower-trust source — an agent's guess — can't silently overwrite a higher-trust fact you stated explicitly. The gate refers the conflict back to you instead of picking a winner.
Semantic near-dup optional · local embeddings
Turn on the local embedding backend and a save that means the same as an existing memory comes back as a possible_duplicate to confirm — rather than piling up. The model runs entirely on your machine; nothing is sent to any cloud.
Your machine by default. Your server when you need reach.
Jamgate runs as an MCP server, so any MCP-capable agent connects to the same memory. Start local; add a self-hosted instance the day you want your phone and laptop to share one brain.
Local mode
stdio · default · zero network
One process per agent, on your machine. Your memory lives in a single readable JSON file — ~/.jamgate/memory.json. Same machine, every agent → one shared memory.
- No install step —
npxfetches and runs on demand - Nothing leaves the machine — no cloud, no telemetry
- Three tools:
save_memory,recall_memory,forget_memory
$ claude mcp add jamgate -- npx jamgate
Remote mode self-hosted
one instance · behind HTTPS · shared
Run one Jamgate on a server you control, put it behind a reverse proxy, and point every agent — phone, browser, laptop — at the same URL. Save on your phone, recall on your laptop. Same gate, same store; only the transport is over the network.
- Streamable HTTP with bearer-token auth (constant-time compare)
- Your server, your data — no Jamgate cloud, no telemetry
- Opt-in — stdio stays the default
No terminal? Click a button, log in, get your own instance:
You pay the platform directly (~$5–7/mo for a tiny always-on instance) — Jamgate hosts nothing and takes no cut. The button generates a strong token and a persistent disk for you.
Deliberately small. Honest about the rest.
Jamgate isn't trying to be a hosted platform or a knowledge graph — it's the write-time quality layer those systems are weakest at, packaged as a drop-in local MCP server. Mem0, OpenMemory, Zep and Graphiti are capable systems built for different goals.
| Jamgate | Mem0 / OpenMemory | Zep / Graphiti | |
|---|---|---|---|
| Core model | Write-time quality gate over a flat store | LLM-extracted memory layer | Temporal knowledge graph |
| Where memory lives | Local file on your machine | Hosted platform or self-hosted store | Graph server (self-hosted or cloud) |
| Their strength | — | Rich extraction, broad SDKs, scale | Powerful entity/relationship & temporal modeling |
| Gate before write | ✓ core design | Partial (dedup/update) | Partial |
| Source-trust hierarchy | ✓ | — | — |
| Refers conflicts back to you | ✓ | — | — |
| LLM calls of its own | None | Required | Required |
| Dependencies / infra | 1 dep, no server | SDK + service/DB | Graph DB + service |
| Best for | Keeping one shared personal memory clean, locally | Full-featured app-scale memory | Complex relational/temporal reasoning |
If you need managed scale or graph reasoning, those are the right tool. Jamgate's bet is that for personal cross-agent memory, the hard part is quality at write time — and that it should be local, free, and one command to install.
Your machine, or your server. Nothing leaves.
The memory store, the gate, and — if you enable it — the embedding model all run where you are. Jamgate makes no network calls and talks to no cloud AI. Don't take our word for it; the code is short and the store is readable.
Everything is local
No telemetry, no accounts, no keys. Even the optional embedding model downloads once (~23 MB) and runs on-device — no text is ever sent to any cloud AI.
Readable JSON
Your memory is one flat file at ~/.jamgate/memory.json. Back it up with cp, or use schema-aware export / import that replays every record through the same gate.
Read the code
A local decision log records every gate verdict (saved / duplicate / superseded / conflict / rejected) to a size-capped JSONL file that never leaves your machine. Disable it with one env var.
MIT, built in the open
Free and open-source under MIT. Goal: impact, not profit. The most valuable contributions are around write-time quality — the part the whole field is weakest at.
Pick your client. Run one thing.
Requires Node.js 20+. No install step — npx fetches and runs Jamgate on demand. Restart your client afterwards.
The one-liner that wires everything
Detects the MCP clients installed on your machine — Claude Code, Claude Desktop, Cursor, Windsurf — and wires Jamgate into each. Idempotent, and it backs up every config file before writing.
# wire every detected client $ npx jamgate setup # preview changes, write nothing $ npx jamgate setup --dry-run # see which clients are wired + where the store lives $ npx jamgate status
Safe to run: idempotent, never touches any server entry but its own, backs up each config to <file>.jamgate-backup.
Claude Code
One command adds Jamgate as a local MCP server. On Claude Code, setup uses this under the hood when the CLI is present.
$ claude mcp add jamgate -- npx jamgate
Restart Claude Code. It now has save_memory, recall_memory, and forget_memory.
Claude Desktop
One-click: download the .mcpb bundle from the latest release and open it (Settings → Extensions). Or add to claude_desktop_config.json (Settings → Developer → Edit Config):
{
"mcpServers": {
"jamgate": { "command": "npx", "args": ["jamgate"] }
}
}
The .mcpb bundle is unsigned, so you may see an "unverified" prompt.
Cursor
Add to ~/.cursor/mcp.json (or .cursor/mcp.json in a project) — the same server block:
{
"mcpServers": {
"jamgate": { "command": "npx", "args": ["jamgate"] }
}
}
Windsurf works the same way — add the block to ~/.codeium/windsurf/mcp_config.json.
One memory of you. Kept honest.
Install in one command. It's local, free, and open-source — nothing to sign up for.
$ npx jamgate setup