Launched this week
Atlaso
One memory for every AI you use
400 followers
One memory for every AI you use
400 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?
"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
@ridhwikvinod
Thanks — and no, I won't pretend team memory exists yet. Atlaso today is one person's memory across their tools. It's partitioned per user, so there's no shared layer, no roles, no attribution.
Straight about the rest too: the supersede logic you're describing isn't shipped even across tools yet.
But here's the honest workaround, founder to founder. A paid account allows up to 100 devices — so one account signed in across your team really does give you one shared memory that everyone's tools read and write. It isn't what I built it for, but it works today, and I'd rather tell you that than have you wait on a roadmap.
Two things before you try it. Recall is rate-limited per account and sized for one person, and Claude Code pulls memory on every prompt — so a dozen people going at once will start getting throttled. And there's no attribution: everything lands in one pool, so one person's preference becomes everyone's, and anyone can delete anything.
Which is why I'd start with four or five people rather than all 36, and then tell me what breaks. That's worth more to me than a signup, and it's how the team version gets designed properly instead of guessed at.
Also i would love to know how you operate with a team in detail. Please send me an email at ashish@atlaso.ai and i would like to work on this next to make this available as team account. So would love to talk further on this on what exactly do you need.
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.
Atlaso
@you_li525 You've got it right, and the answer to "what decides" is: nothing good. Ordering is reciprocal-rank fusion of BM25 and embeddings, and since disagreement never fires in a consumer store that sort key is constant — so it's pure similarity with no tiebreak. Between an old fact and its correction, same topic and same vocabulary, the winner is whichever scores marginally higher, which is effectively arbitrary. And usually both land in the k=5. So yes — the agent gets both and picks confidently. That's the sharpest description of the failure anyone's given me.
The one-signal-two-jobs framing is the part I'll be repeating back to myself. It's exactly why decay is off: I removed the only recency signal because it punished old-but-true, which left old-and-superseded with nothing punishing it either.
Roadmap — yes, and in the order you'd guess. The read side already honours supersede edges; the engine excludes superseded targets from consumer recall today. What's missing is the write path: the deposit API doesn't expose a contradicts field, so nothing shipped can create one. Small change, and it goes first.
The write-time flag is the right interim, and I'd rather ship that than the fully automatic version. Every memory is already embedded on the way in, so the nearest-neighbour lookup is nearly free — surfacing "this looks like it updates X — supersede it?" at write time is cheap, and it keeps the human in the loop, which as you say is the only reason yours stays trustworthy. Automatic detection can come later and be wrong quietly. A flag can only be wrong loudly.
And yes — please write it up. What forced the split is the part I most want to read; I can guess the design, not what broke first. Launch day is the best possible day to be told what to build.
@ashish_khandelwal11 Here's the structure. The short version: I don't rank, I scope.
Root — two memory files and a routing map. MEMORY.md is live. ARCHIVE.md is superseded content, and it's outside the retrieval path entirely. The routing map is a table: this kind of task → that workstation.
Workstation — each one has its own rules file and its own memory. Profile is one, self-employment is another.
Project — under a workstation, each project has its own memory again. Under Profile I have CV and Interview as separate projects, each with their own.
So retrieval is two steps, and the first one isn't a search. The router decides which files are even in scope, deterministically, from the task. Only then does anything get read. Similarity never runs across the whole store.
That's why the contradiction problem mostly doesn't reach me. Two facts that would collide in a flat store usually belong to different scopes — same vocabulary, different owner. The router separates them before a ranker ever sees them, so there's no tiebreak to get wrong. And within a single scope there are few enough facts that I can actually spot a contradiction.
Two honest limits. The map is hand-written, so it's me doing the work your engine would have to do. And it breaks when a fact genuinely belongs in two scopes — which is exactly why "one owner per fact" is a rule and not a preference.
So the question back: does Atlaso have any notion of scope — per project, per tool, per workspace — or is it one global store per user? Because for the most common contradiction, scoping might be cheaper than dispute edges. The old fact isn't wrong, it just belongs to a context you're no longer in.
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.
The re-explaining tax is real, I switch between Claude Code and other tools daily and re-establishing context every time is the part nobody talks about when they compare AI coding tools. Curious how you handle the per-project vs global split when two projects share similar tech but different conventions.
Atlaso
@aareldigital
Honestly that's the whole reason this exists. Everyone benchmarks the tools against each other and nobody counts the twenty minutes you spend getting each one back up to speed.
On the split: each repo keeps its own memory, so two projects on the same stack never see each other's conventions. The same repo cloned somewhere else does share, because it's still the same project.
Global is only for things that are true about you rather than about the code — we work that out from how you say it. "I prefer tabs" is you. "The build uses X" is the repo. When it's ambiguous it stays with the repo, on the theory that a fact turning up where it doesn't belong is worse than a fact you have to say twice.
Try it out! I'm sure you'll like it.
The global vs project split feels right. Can related repos share one memory space without making it global?
Atlaso
@yanhe_jack Not today. There are only two levels — personal, or one repo — and nothing in between, so related repos can't share a space without going fully global.
It keeps coming up though, which tells me it's a real gap rather than an edge case. The obvious shape is a middle tier: a named group of repos you opt into. That's cheap for us to build, because the scoping machinery is already there — it just only knows one key at a
time right now.
Worth admitting it errs the other way too. A package inside a monorepo with its own package.json gets treated as its own project rather than inheriting the repo, so sometimes things that should share already don't.