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.
Atlaso started as a question I couldn't shake: what would it actually take to give AI a real memory?
Not a bigger context window. Not a notes file stapled onto the side. A real memory foundation layer — one that persists, stays honest, and actually helps across sessions and tools.
That question turned into research. We ran our own memory benchmarks, and our approach held up better than the other memory systems we tested against. A lot of the work was in the unglamorous parts: what should be saved, what should be surfaced, and how to make sure memory orients you instead of quietly making things up.
The reason I cared so much is simple — I was tired of re-explaining myself to every AI I used. I'd tell Claude Code about a project, switch to Cursor, and start over. Then again in Codex. Same context, same decisions, same preferences, over and over.
Atlaso is what came out of that work: one memory layer for the AI tools you already use. Connect it once and your context follows you — global memory for what travels with you, per-project memory for what should stay separate.
My favorite part is Ambient Memory — what we call giving AI a subconscious. Before you type a word, Atlaso surfaces a short orientation from your own memory, so the AI picks up where you actually left off. It orients, it never invents.
It's free to start. I'm Ashish, the founder — I'll be in the comments all day, and I'd genuinely love your feedback: what would make AI memory actually useful to you?
Report
@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.
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.
"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.
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?
Report
Congrats on the launch Ashish, and the way you’re answering people here is genuinely refreshing. Publishing the benchmark you lose on is not a small thing.
My question comes from outside the dev lane. Memory is scoped global and per project, which is right for one person, but at our company half the context worth remembering belongs to the team, not to me. Brand rules, who owns what, decisions we made and why. Today if I correct something, my AI knows it and my colleague’s still gets the old version. Is a shared team memory layer on the roadmap, with the same supersede logic applied across people rather than tools? That’s the version I could roll out to 36 people instead of just using myself.
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.
Report
Congrats on the launch!
What sets Atlaso apart from Supermemory, which I'm currently using? Especially interested in how you handle developer-focused workflows across tools like Claude Code and Cursor.
Also, is there an easy way to import or sync existing memory from Supermemory, or do we need to start from a clean slate?
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.
Report
@ashish_khandelwal11 Ah awesome, thanks for the detailed response Ashish! The hands-off sync between Cursor and Claude Code sounds ideal because that was literally one of my biggest pain points. Appreciate the offer on the data import too! Gonna try out the MCP workflow today.
@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.
Report
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.
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.
Report
Does memory compile and bulge the memory file or is there a natural decay built in?
@zrk222 No decay — the store just grows, and we don't prune or expire anything. But it never bulges what reaches the model: recall pulls the top 5 relevant memories, so the block injected into your session is about the same size whether you have 50 memories or 5,000. What grows is the archive, not the context.
Report
Interesting! How is it different from SuperMemory?
Short version: Supermemory is a platform you build with — APIs and connectors that ingest your docs and knowledge. Atlaso installs into the coding tools themselves — Claude Code, Cursor, Codex and more — captures decisions as you work, and injects the relevant ones back on your next prompt, across all of them. Nothing to file, nothing to call. It just shows up. Happy to go deeper if you're curious about a specific workflow.
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.
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.
Does memory compile and bulge the memory file or is there a natural decay built in?
Atlaso
@zrk222 No decay — the store just grows, and we don't prune or expire anything. But it never bulges what reaches the model: recall pulls the top 5 relevant memories, so the block injected into your session is about the same size whether you have 50 memories or 5,000. What grows is the archive, not the context.
Interesting! How is it different from SuperMemory?
Atlaso
@itsshashank
Short version: Supermemory is a platform you build with — APIs and connectors that ingest your docs and knowledge. Atlaso installs into the coding tools themselves — Claude Code, Cursor, Codex and more — captures decisions as you work, and injects the relevant ones back on your next prompt, across all of them. Nothing to file, nothing to call. It just shows up. Happy to go deeper if you're curious about a specific workflow.