Launching today
Atlaso
One memory for every AI you use
64 followers
One memory for every AI you use
64 followers
Atlaso is a memory layer for AI. Connect it once and every AI you use, from Claude Code to Cursor, Codex and ChatGPT, automatically recalls the context that matters: your projects, your decisions, and the way you like to work. No more re-explaining yourself at the start of every session. One shared memory that follows you across every tool, instead of being locked inside one app. Free to start, and backed by original memory research.
Free Options
Launch Team / Built With
Atlaso
@ashish_khandelwal11Β Congrats on the launch! I really like the distinction between thin, settled, contested, and superseded memories. I havenβt seen many memory tools make uncertainty this explicit.
How do you prevent something inferred from a conversation from overriding whatβs actually true in the repo, docs, or a newer decision?
Also, any plans for a fully local or self-hosted mode? Thatβs probably the main thing Iβd need before trying it on sensitive repos.
Thank you!
Atlaso
@martin_herranΒ
Thank you β and both good questions.
On the first: memory doesn't override the repo. Recalled notes go in as notes, alongside the code the model still reads for itself. The repo is checkable and a memory isn't, so what's actually in the files wins.
For a newer decision there's a real path, and it works in any tool through our MCP β tell the AI something has changed and it finds the old memory, removes it, and saves the new one. The plugin ships with instructions to supersede rather than pile up contradictions, so you don't have to manage it by hand.
What it won't do yet is catch a reversal you never flagged. If you quietly move on without mentioning it, nothing spots that on its own. That's the part I'm working on.
On self-hosted: nothing today, and I won't pretend it's ready for a locked-down repo. Worth saying what does happen in the meantime β secrets never make it in. API keys, tokens, private keys, passwords, credentials in URLs all get stripped on your machine before anything is sent, and stripped again when it arrives. And we don't read your memories or train anything on them, free or paid.
If self-hosting is still your blocker, tell me what would clear it β full self-host, or your own storage with our engine on top?
I've built a version of this by hand for a single tool β a memory file with explicit ownership rules so every fact lives in exactly one place, plus an archive for anything superseded. It works, but only because I maintain it myself. Two questions from the maintenance end:
Tidy-up. Mine stays usable because I prune it, and because there's a rule that a new fact contradicting an old one gets flagged to me rather than silently overwriting. As Atlaso's store grows across four tools and hundreds of sessions, what happens when session 40 contradicts session 4 β overwrite, version, or surface the conflict? And does anything decide a memory has gone stale, or does it accumulate forever?
Token cost. If memory is injected into every session, my bill scales with how much I've remembered. Is it selective retrieval or the whole store? Roughly what's the per-session overhead at 500 memories versus 50?
Atlaso
@you_li525Β
Both fair. Straight answers.
Token cost β selective, and here's the number rather than a promise. Recall is a top-k hybrid search (BM25 + embeddings, rank-fused), k=5, hard-capped at 50 server-side. Only those 5 get rendered, so the injected block is ~650 tokens at our median memory length. I measured it against a real 934-memory store: at 50, 500 and 5,000 memories the block comes back the same size, because what's fixed is the count, not a share of the store. The search runs on our server with no LLM in the path, so it costs you nothing β your bill only ever sees those 5 notes. The real multiplier is turns, not memories: Claude Code, Codex and OpenCode recall on every prompt, Cursor writes it once per session.
Tidy-up β none of the three, and I'd rather say that than have you find out. Both rows are stored, both stay live, both can come back, and nothing marks either as contradicting the other. Append-only, so nothing gets silently overwritten β but that's the flip side of your rule, not a version of it. The atlaso engine has typed dispute/supersede semantics and honors them on read; no shipped connector can write those edges yet. Today the correction path is you or the agent explicitly forgetting the old one and re-saving.
Nothing expires either. No TTL, no pruning, and we turned recency decay off in ranking on purpose β it down-ranked old-but-still-true facts and cost us accuracy on LongMemEval-S. So the store grows forever; what's bounded is what comes back, not what's kept.
@ashish_khandelwal11Β Thank you for answering "none of the three" rather than spinning it β that's rarer than it should be. And the 650-token fixed block measured against a real 934-memory store is the most useful number on this page.
The tidy-up answer creates one follow-up, though. Store grows forever, both rows stay live, no shipped connector can write supersede edges, and recency decay is deliberately off. So when an old fact and its correction are both sitting there, they look nearly identical to BM25 plus embeddings β same topic, same vocabulary β and both are strong candidates for the same k=5. What decides which comes back? And if both do, the agent gets two contradictory facts with nothing marking which is current. That's arguably worse than returning neither, because it'll pick confidently.
I take the point that recency decay cost you accuracy on old-but-still-true facts. But "old but still true" and "old and superseded" are indistinguishable to a ranker with no dispute edges β you're asking one signal to do two jobs.
Is the shipped path to those edges on the roadmap? Or is there an interim where the connector flags at write time that a new memory conflicts with a stored one? A write-time flag is cheap and puts the human back in the loop, which is the only reason my hand-rolled version stays trustworthy.
If it's useful I can write up what I ended up doing β splitting into a live file and an archive, and what forced the split. Happy to, but I'm conscious it's your launch day.
"It orients, it never invents" is the claim I'd want stress tested, and not against a benchmark you ran yourself. The hard case for auto capture isn't invention, it's a decision you reversed three sessions ago still getting injected as settled, and it reads exactly as confident as a correct one. So the real question is how a memory dies. If I can't see what got injected and kill it in one keystroke, I'll turn the whole thing off the first time it confidently reminds me of the wrong thing.
Atlaso
@asadmalik901Β
Fair on all three.
Β Β
The benchmark is ours β we built the harness and ran both sides. What I'd stand behind is the method, not the number: same reader for both arms, four judges including mem0's own judge prompt, answers normalised so a judge can't tell which system wrote them. We also publish LoCoMo, where we lose by 11.5 points.
On the reversed decision, you're right. We have the machinery to retire a superseded memory, but nothing in the shipped tools actually triggers it β so the old one stays live and looks identical to the new one. Same confidence, exactly as you said.
And on seeing it: in Claude Code and Codex the recalled block goes to the model, not your terminal. So today you can't see it, and killing one means a trip to the dashboard, not a keystroke.
That's a real gap and I'd rather fix it than argue it. What would you want β an id on every line and one command to kill it?
Atlaso
@hanneshΒ
Thanks Hannes β and good question, Supermemory's a solid product so let me be specific rather than hand-wavy.
The biggest difference is where the memory lives and how it gets there. Supermemory is largely a platform you build with β APIs, SDKs, and connectors that ingest your documents and knowledge sources. Atlaso installs into the coding tools themselves. There's a plugin for Claude Code, Cursor, Codex, OpenCode, Antigravity and Claude Desktop, and once it's in, two things happen on their own: it captures decisions and preferences out of the sessions as you work, and it injects the relevant ones back at the top of your next prompt. You don't file anything, and you don't call a recall tool. It just shows up.
The second is that it's cross-tool by design rather than per-app. Correct something in Claude Code and Cursor reads the corrected version on its next recall, not a stale copy. Memory is scoped globally and per project, so one repo's context doesn't bleed into another.
On import β you don't need one. Atlaso exposes an MCP server, so whichever tool you're already in can write memories directly. Export from Supermemory, paste it into Claude Code or Cursor or Claude Desktop, and say "save each of these to my Atlaso memory." It'll loop through and write them in at roughly 60 a minute, so a few hundred takes a couple of minutes. No new tool to set up, no waiting on us.
And if you'd rather not babysit it, send me the export and I'll load it into your account myself. Either way you're not starting from a clean slate.
Atlaso
@hanneshΒ Great β let me know how the MCP import goes, especially if any of it feels clunky. And the offer stands if you'd rather just send me the export.