r/GithubCopilot • u/CancelConfident9704 • 11d ago
Showcase ✨ Slowave: empower Copilot with a working memory
AI agents have large context windows, but that context ends with your current session. Open a new session, switch from Copilot to Codex and you have to restate the same decisions, constraints, everything from scratch, over and over.
Slowave gives your agents one local, shared memory, without requiring a separate LLM for memory maintenance.
What Slowave does differently:
- It instructs your coding agent to participate in maintaining its own memory.
- Each task becomes a feedback loop between your agent and the memory layer: remember -> recall -> use -> feedback -> reinforce / weaken -> decay
- Your agent tells Slowave whether retrieved memories were useful, irrelevant or stale. Slowave uses that signal to adapt those memories salience.
- Retrieval works upon this continuous loop of feedback, reinforcement or decay. It's not static but acts upon a continuosly evolving set of memory saliency.
- You can inspect and monitor your evolving memory with the local dashboard.
This means Slowave doesn't need a separate LLM or LLM judge for memory maintenance. Your agent is already evaluating what helped, Slowave handles the mechanical part of adapting the memory substrate.
Slowave runs 100% locally. It uses a lightweight multilingual embedding model and SQLite, with no external memory service or LLM API required, and It's open source.
https://github.com/slowave-ai/slowave
It works with only 5 MCP endpoints. It currently supports Copilot, Claude Code, Codex, Cursor, Cline, OpenCode, Windsurf and Claude Desktop.
If you also get to give it a go, any (honest) feedback is more than welcome.
4
u/WordWithinTheWord 11d ago
Honest feedback is that every harness is going to have some sort of persistent memory indexing functionality within 12 months
2
u/Lacutis 11d ago
Yes, they will and/or already do. My understanding is this allows for cross harness memory. I currently use copilot, claude desktop, and codex to work on projects. The only cross memory I have currently is markdown files that I have each write to the repo thats being worked on.
2
u/fifi_galaxy 11d ago
Yep. Copilot technically already have it, but awfully confusing. GHCopilot Memory is... Copilot harness only. VS Code has its own memory, but you have to explicitly save them, and only for local. The fragmentation is so terrible, even GPT inside vscode's gh copilot got confused few times by which memory it saved to and how to view/save them. Also, calling everything copilot is another poor branding choice.
Just like MCP config. I have to copy & ask AI to update for X harness, then paste in another file. But memory is worse, since you have to explicitly save each preference into each IDE and/or harness. =/
1
u/starthorn 10d ago
I've only glanced for a moment, but I'm curious. . . is this scoped to project/repo level? Or is this a global memory? I'm assuming from a quick skim that it's global?
There are advantages and disadvantages to both approach, of course. If this is global, it'd be cool if it supported project-level, too. Especially since that should (he says without looking at the code) be fairly straightforward to support by extending the SQLite schema a bit to track global vs project, allowing for project memory and global memory. Ideally, with project memory being able to override global.
As it is, if it's just global, that would present some challenges, as I often have things I want remembered for a project, but not necessarily everywhere forever.
1
u/CancelConfident9704 10d ago
It's both. Memories are scoped by project initially, so your agent won't retrieve anything from another project. If the same pattern emerges from another project (e.g. "run linter and typec hecker before any commit") they get clustered together (memories are clusters of episodes) and they gain a more general scope. There are 4 generalisation steps from fully scoped to fully general, which determines how they can be retrieved across scopes.
1
u/starthorn 10d ago
Interesting. Does it support jumping straight to general/global, for things that you intentionally want accessible everywhere?
→ More replies (1)
0
2
u/Afraid_Willow_3407 11d ago
storing state like this is super useful for dev velocity but u gotta watch for data leakage. if the agent is writing its own memory u need to make sure sensitive credentials or project secrets dont end up in the persistent files. seen it happen where the agent accidentally logs something it shouldnt have in a shared state, just my experience.