Launched this week
CodeYam CLI & Memory
Comprehensive memory management for Claude Code
174 followers
Comprehensive memory management for Claude Code
174 followers
We built CodeYam Memory because Claude Code kept repeating the same mistakes and our claude.md files got stale. CodeYam Memory uses a background agent to review your coding session transcripts, identifies confusion patterns, and generates targeted rules with proper scoping. This is a small first step towards our vision of exploring the ideal AI-native development experience, packaged as a lightweight CLI that you can use wherever you use Claude Code.
Durable
This is a real problem. We've burned a lot of time manually updating claude.md files that drift out of sync with how the codebase actually works. Background agent approach makes a lot of sense. Checking this out!
CodeYam CLI & Memory
@jamesclift thanks, and same on previously spending too much time on updating claude.md files that go stale. Trying to catch and maintain those was a huge pain for us as well. If you have any feedback or questions, just let me know. Would love to hear what you think!
CodeYam CLI & Memory
oh man this hits close. been building a desktop app with Claude Code for months and the CLAUDE.md staleness problem is probably our #1 source of wasted time. you write great instructions, they work for a week, then the codebase evolves and the agent starts doing weird things because the context is outdated.
we ended up with this whole system of CLAUDE.md + AGENTS.md + skills files and honestly keeping them in sync is like its own part-time job at this point.
curious about the "confusion pattern" detection — how does it figure out when Claude is confused vs when the instructions are just ambiguous? those feel like two different problems to me but maybe I'm wrong. also does it work with sub-agents / multi-agent setups or only single CLAUDE.md?
CodeYam CLI & Memory
@jarmo_tuisk2 The background agent has instructions and examples of what to look for. The primary goal is to look for something confusing that is likely to happen again in a future session. It doesn't always get it right, though, so we do review our rules on a regular basis. The dashboard provides good tools to help with reviewing and auditing rules so you can keep all rules clean and tidy easily.
@jaredcosulich thanks for the detailed answers! the dashboard for auditing rules sounds really useful — right now we basically do manual grep through all our context files when something breaks, which is... not great.
the path-based rules loading is clever. we have rules scattered across CLAUDE.md, AGENTS.md, and per-agent skill files so having them auto-load based on which files the agent is touching would save a lot of "why did it ignore that instruction" debugging.
gonna try CodeYam this week — the staleness detection alone would probably save us a few hours of confused debugging per week.
CodeYam CLI & Memory
@jaredcosulich @jarmo_tuisk2 thanks James and would love to hear how it goes once you try CodeYam out. If you have any questions, feedback, or issues just reach out and Jared or I are happy to help anytime.
CodeYam CLI & Memory
@jarmo_tuisk2 Regarding the sub-agents, multi-agents: rules are a built in Claude Code mechanism: https://code.claude.com/docs/en/memory#organize-rules-with-claude%2Frules%2F that get loaded in to context when the rule path matches the file being worked on so I believe this will work with any Claude agent in the working session.
Oh this is solving a real pain point. I use Claude Code daily and the CLAUDE.md file situation gets messy fast, especially when you're juggling multiple features across different parts of the codebase. The background agent reviewing transcripts is a clever approach. Does it handle conflicting rules well? Like if one session teaches it something that contradicts a previous rule?
CodeYam CLI & Memory
@mihir_kanzariya Yes it should. The background agent reviews all rules and should catch any conflicts. We also have a pre-written prompt that you can run at any time to audit all rules, look for any inconsistencies or inefficiently communicated rules, etc. and clean them up. Generally speaking, though, we have never had a problem with conflicting rules in our own usage.
Nice memory management for Claude Code is a gap a lot of people are feeling. How are you persisting the memory store is it local-only right now or is there a cloud sync path planned? Curious how you're thinking about keeping sensitive code context from leaking across projects.
CodeYam CLI & Memory
@avinash_matrixgard thank you! Yes, it's completely local-only right now.
In the future, we might introduce the option to cloud sync but it's not on the immediate roadmap and we'd want to do it in a way that protects against leaking sensitive code or context. Is cloud sync a functionality you'd want to have for a tool like this?
@nseldeib Cloud sync would be useful but only if the scoping is airtight the value breaks down fast if context from one project bleeds into another, especially for anyone working across client codebases. Local-first with an optional sync that's project-scoped and encrypted at rest would be the right pattern. The "we'd do it in a way that protects against leaking sensitive code" instinct is exactly right. Most tools in this space add sync first and figure out the isolation model later.
CodeYam CLI & Memory
@avinash_matrixgard CodeYam Memory uses Claude Rules which are stored in the repo. We don't have any plans for cloud sync for this product at the moment as storing in the repo and handling the occasional merge isn't too inconvenient. If we do eventually provide cloud sync there are clear best-practices to avoid sensitive code leaking across projects within a database.
@jaredcosulich The repo-based storage approach is actually cleaner from a security standpoint it means the context lives where the code lives, gets reviewed in the same flow, and doesn't need a separate trust boundary. The merge friction is a real tradeoff but it's the honest one. Curious how you're handling context that's sensitive by nature like API keys or credentials that end up in Claude's context window during a session. Are those filtered before being written to the rules file, or is that left to the developer to manage?
This is super cool and great for us as startup heavily using claude code. How does this compare to Claude's Memory Tool? https://platform.claude.com/docs/en/agents-and-tools/tool-use/memory-tool
CodeYam CLI & Memory
@amelia_wampler great question. @Claude Code's own memory tool is actually something we're using too. In our experience, and with what we've seen from Claude, it's a much more casual and black box experience.
We needed something more aggressive at extracting out anything complex or confusing to ensure that future sessions had better information and we wanted complete visibility into what memories were being created so we could fix them if they weren't great and ensure that they weren't impacting the context window too much, so we built out a rather robust dashboard experience to handle that.
@nseldeib cool thanks!
CodeYam CLI & Memory
@amelia_wampler of course, anytime! Appreciate the question as it’s a good one to clarify and callout.
the stale claude.md problem is real and you've nailed the fix for project context. what i keep running into is the other half of the cold start - claude doesn't know who the developer is either. role, preferences, how they like to work. codeyam handles what the codebase needs claude to know. been working on the human side of that same gap with northr identity. feels like these two would stack well.
CodeYam CLI & Memory
@ivo_gospodinov thanks, I really appreciate this.
Totally agree there are two halves to the cold start problem: what the agent needs to know about the codebase, and what it should know about the developer.
We started with the project side because Claude Code getting lost or confused in our fairly complex codebase was the pain we were feeling most, but the human layer is very interesting too. Would love to learn more about what you've been building and exploring with northr identity!