Show HN: Stop Claude Code from forgetting everything

185 points by austinbaggio 2 days ago

I got tired of Claude Code forgetting all my context every time I open a new session: set-up decisions, how I like my margins, decision history. etc.

We built a shared memory layer you can drop in as a Claude Code Skill. It’s basically a tiny memory DB with recall that remembers your sessions. Not magic. Not AGI. Just state.

Install in Claude Code:

  /plugin marketplace add https://github.com/mutable-state-inc/ensue-skill
  /plugin install ensue-memory
  # restart Claude Code

What it does: (1) persists context between sessions (2) semantic & temportal search (not just string grep). Basically git for your Claude brain

What it doesn’t do: - it won’t read your mind - it’s alpha; it might break if you throw a couch at it

Repo: https://github.com/mutable-state-inc/ensue-skill

If you try it and it sucks, tell me why so I can fix it. Don't be kind, tia

ramoz a day ago

I struggle with these abstractions over context windows, esp when anthropic is actively focused on improving things like compaction, and knowing the eventual* goal is for the models to yave real memory layers baked in. Until then we have to optimize with how agents work best and ephemeral context is a part of that (they weren’t RL’d/trained with memory abstractions so we shouldn’t use them at inference either). Constant rediscovery that is task specific has worked well for me, doesn’t suffer from context decay, though it does eat more tokens.

Otherwise the ability to search back through history is a valuable simple git log/diff or (rip)grep/jq combo over the session directory. Simple example of mine: https://github.com/backnotprop/rg_history

Reply View 7 replies

AndyNemmity a day ago

There is certainly a level where at any time you could be building some abstraction that is no longer required in a month, or 3.
I feel that way too. I have a lot of these things.
But the reality is, it doesn't really happen that often in my actual experience. Everyone is very slow as a whole to understand what these things mean, so far you get quite a bit of time just with an improved, customized system of your own.

Reply View | 6 replies
- ramoz a day ago
  
  My somewhat naive heuristic would be that memory abstractions are a complete mistep in terms of optimization. There is no "super claude mem" or "continual claude" until there actually is.
  https://backnotprop.com/blog/50-first-dates-with-mr-meeseeks...
  
  Reply View | 5 replies
  
  AndyNemmity a day ago
  
  I tend to agree with you, however compacting has gotten much worse.
  So... it's tough. I think memory abstractions are generally a mistake, and generally not needed, however I also think that compacting has gotten so wrong recently that they are also required until Claude Code releases a version with improved compacting.
  But I don't do memory abstraction like this at all. I use skills to manage plans, and the plans are the memory abstraction.
  But that is more than memory. That is also about having a detailed set of things that must occur.
  
  Reply View | 4 replies

saberience a day ago

Do we really need another vibe-coded LLM context/memory startup?

Do the authors have any benchmarks or test to show that this genuinely improved outputs?

I have tried probably 10-20 other open source projects and closed source projects purporting to improve Claude Code with memory/context, and still to this date, nothing works better than simply keeping my own library of markdown files for each project specification, markdown files for decisions made etc, and then explicitly telling Claude Code to review x,y,z markdown files.

I would also suggest to the founders, don't found a startup based on improving context for Claude Code, why? Because this is the number 1 thing the Claude Code developers are working on too, and it's clearly getting better and better with every release.

So not only are you competing with like 20+ other startups and 20+ other open-source projects, you are competing with Anthropic too.

Reply View 6 replies

sdoering a day ago

This. Exactly this. Even relatively well working tools (from my experience and for my project types) like Agent OS are no guarantee, that Claude will not go on a tangent, use the "memory files" the framework tells it to use.
And I agree with your sentiment, that this is a "business field" that will get eaten by the next generations of base models getting better.

Reply View | 0 replies
christinetyip a day ago

I mostly agree with this, if the goal were “better persistent memory inside Claude Code,” that wouldn’t be very interesting.
For a single agent and a single tool, keeping project specs and decisions in markdown and explicitly pointing the model at them works well. We do that too.
What we’re focused on is a different boundary: memory that isn’t owned by a specific agent or tool.
Once you start switching between tools (Claude, Codex, Cursor, etc.), or running multiple agents in parallel, markdown stops being “the memory” and becomes a coordination mechanism you have to keep in sync manually. Context created in one place doesn’t naturally flow to another, and you end up re-establishing state rather than accumulating it.
That’s why we're not thinking about this as "improving Claude Code”. We’re interested in the layer above that: a shared, external memory that can be plugged into any other model and tools, that any agent can read from or write to, and that can be selectively shared with collaborators. Context created in Claude can be reused in Codex, Manus, Cursor, or other agents from collaborators - and vice versa.
If one already built and is using one agent in one tool and is happy with markdown, they probably don’t need this. The value shows up once agents are treated as interchangeable workers and context needs to move across tools and people without being re-explained each time.

Reply View | 3 replies
- ramoz 21 hours ago
  
  If markdown in a git repository isn’t good enough for collaboration, then why would any plugged in abstraction be better?
  You imply you have a solution for current wholistic state. For this you would need a solution for context decay and relevant curation — with benchmarks that prove it is also more valuable than constant rediscovery (for quality and cost).
  That narrative becomes harsher once you pivot to “general purpose agents” because you’re then competing with every existing knowledge work platform. So you’ll shift into “unified context for all your KW platforms” - where presumably the agents already have access (Claude today can basically go scrape all knowledge from anywhere).
  So then it becomes an offering of “current state” in complex human processes and this is a concept I’m not sure any technology can capture; whether it’s across codebases (which for humans we settled on git) and especially not general working scenarios. And I guess this is where it becomes a unified multi-agent wholistic state capture. Ambitious and fun problem.
  
  Reply View | 2 replies
  
  austinbaggio 14 hours ago
  
  | need a solution for context decay and relevant curation — with benchmarks that prove it is also more valuable than constant rediscovery (for quality and cost).
  I agree. We are looking at some metr benchmarks, not expecting a simple answer to this, but do you have any in mind you find compelling?
  
  Reply View | 1 reply
  
  ramoz 13 hours ago
  
  Not really. But, You can go viral again with a "Coding Agents with memory build better software using less tokens" showcasing how you benchmarked a "twitter rebuild" -
  1. Setup Claude Code to build some layers of the stack
  2. Setup Codex to build others.
  In one instance equip them both with your product. Maybe bake in some tribal knowledge.
  In another instance let them work raw.
  In both instances, capture:
  - Time to completion - Tokens spent - Ability to meet original spec - Subjective quality - Number of errors and categorize between the layers, to state something like "raw-claude's backend kept failing with raw-codex's frontend" etc
  I imagine this benchmark working well in your favor.
  
  Reply View | 0 replies
floatrock a day ago

right. I stopped reading at "ENSUE_API_KEY | Required. Get one at [dashboard](link to startup showing this is an ad)"
First thought: why do I need an API key for what can be local markdown files. Make contents of CLAUDE.md be "Refer to ROBOTS.md" and you've got yourself a multi-model solution.
Main objection to corporate AI uptake is what are you gonna do with our data. The value prop over local markdown files here is not at all clear to even begin asking that question.

Reply View | 0 replies

gbnwl a day ago

I'm not sure how many HN users frequent other places related to agentic coding like the subreddits of particular providers, but this has got to be the 1000th "ultimate memory system"/break-free-of-the-context-limit-tyranny! project I've seen, and like all other similar projects there's never any evidence or even attempt at measuring any metric of performance improved by it. Of course it's hard to measure such a thing, but that's part of exactly why it's hard to build something like this. Here's user #1001 that's been told by Claude "What a fascinating idea! You've identified a real gap in the market for a simple database based memory system to extend agent memory."

Reply View 47 replies

beefsack a day ago

I feel like so many of these memory solutions are incredibly over-engineered too.
You can work around a lot of the memory issues for large and complex tasks just by making the agent keep work logs. Critical context to keep throughout large pieces of work include decisions, conversations, investigations, plans and implementations - a normal developer should be tracking these and it's sensible to have the agent track them too in a way that survives compaction.

Reply View | 8 replies
- wfn a day ago
  
  Yes. I have (as part of Claude output) a
  - `FEATURE_IMPL_PLAN.md` (master plan; or `NEXT_FEATURES_LIST.md` or somesuch)
  - `FEATURE_IMPL_PROMPT_TEMPLATE.md` (where I replace placeholders with next feature to be implemented; prompt includes various points about being thorough, making sure to validate and loop until full test pipeline works, to git version tag upon user confirmation, etc.)
  - `feature-impl-plans/` directory where Claude is to keep per-feature detailed docs (with current status) up to date - this is esp. useful for complex features which may require multiple sessions for example
  - also instruct it to keep main impl plan doc up to date, but that one is limited in size/depth/scope on purpose, not to overwhelm it
  - CLAUDE.md has summary of important code references (paths / modules / classes etc.) for lookup, but is also restricted in size. But it includes full (up-to-date) inventory of all doc files, for itself
  - If I end up expanding CLAUDE.md for some reason or temporarily (before I offload some content to separate docs), I will say as part of prompt template to "make sure to read in the whole @CLAUDE.md without skipping any content"
  
  Reply View | 0 replies
- ramoz a day ago
  
  Great advise. For large plans I tell the agent to write to an “implementation_log.md” and make note of it during compaction. Additionally the agent can also just reference the original session logs.
  
  Reply View | 4 replies
  
  hasperdi a day ago
  
  The problem with this approach, is that the model may forget to update the log... It usually happens when the context window >50% filled
  
  Reply View | 3 replies
- SkyPuncher a day ago
  
  Yep. I just have my agents write out key details to a markdown file. Doesn’t have to be perfect. Just enough to reorient itself to a problem.
  
  Reply View | 0 replies
- ryanthedev a day ago
  
  I agree. Plan files and I use git for my work logs. Have been successful.
  
  Reply View | 0 replies
xnx a day ago

Some with a coding background love prompt engineering, contrived supporting systems, json prompting and any other superstition that makes it feel like they're really doing something.
They refuse to believe that it's possible to instruct these tools in terse plain English and get useful results.

Reply View | 0 replies
christinetyip a day ago

This is fair, many memory projects out there boil down to better summaries or prompt glue without any clear way to measure impact.
One thing I’d clarify about what we’re building is that it’s not meant to be “the best memory for a single agent.”
The core idea is portability and sharing, not just persistence.
Concretely:
- you can give Codex access to memory created while working in Claude
- Claude Code can retrieve context from work done in other tools
- multiple agents can read/write the same memory instead of each carrying their own partial copy
- specific parts of context can be shared with teammates or collaborators
That’s the part that’s hard (or impossible) to do with markdown files or tool-local memory, and it’s also why we don’t frame this as “breaking the context limit.”
Measuring impact here is tricky, but the problem we’re solving shows up as fragmentation rather than forgetting: duplicated explanations, divergent state between agents, and lost context when switching tools or models.
If someone only uses a single agent in a single tool and already are using their customized CLAUDE.md, they probably don’t need this. The value shows up once you treat agents as interchangeable workers rather than a single long-running conversation.

Reply View | 3 replies
- gbnwl a day ago
  
  > That’s the part that’s hard (or impossible) to do with markdown files or tool-local memory.
  I'm confused because every single thing in that list is trivial? Why would Codex have trouble reading a markdown file Claude wrote or vice versa? Why would multiple agents need their own copy of the markdown file instead of just referring to it as needed? Why would it be hard to share specific files with teammates or collaborators?
  Edit - I realize I could be more helpful if I actually shared how I manage project context:
  CLAUDE.md or Agents.md is not the only place to store context for agents in a project, you can just store docs at any layer of granularity you want. What's worked best for me is to:
  1. Have a standards doc(s) (you can point the agents to the same standards doc in their respective claude.md/agents.md)
  2. Before coding, have the agent create implementation plans that get stored in to tickets (markdown files) for each chunk of work that would take about a context window length (estimated).
  3. Work through the tickets and update them as completed. Easy to refer back to when needed.
  4. If you want you can ask the agent to contribute to an overall dev log as well, but this gets long fast. Is useful for agents to refer to the last 50 lines or so to immediately get up to speed on "what just happened?", but so could git history.
  5. Ultimately the code is going to be the real "memory" of the true state, so try to organize it in a way that's easy for agents to comb through (no 5000 lines files that agents have trouble trying to carefully jump around in to find what they need without eating up their entire context window immediately).
  
  Reply View | 2 replies
  
  christinetyip a day ago
  
  You’re right that reading the same markdown file is trivial, that’s not the hard part.
  Where it stopped being trivial for us was once multiple agents were working at the same time. For example, one agent is deciding on an architecture while another is already generating code. A constraint changes mid-way. With a flat file, both agents can read it, but you’re relying on humans as the coordination layer: deciding which docs are authoritative, when plans are superseded, which tickets are still valid, and how context should be scoped for a given agent.
  This gets harder once context is shared across tools or collaborators’ agents. You start running into questions like who can read vs. update which parts of context, how to share only relevant decisions, how agents discover what matters without scanning a growing pile of files, and how updates propagate without state drifting apart.
  You can build conventions around this with files, and for many workflows that works well. But once multiple agents are updating state asynchronously, the complexity shifts from storage to coordination. That boundary - sharing and coordinating evolving context across many agents and tools — is what we’re focused on and what an external memory network can solve.
  If you’ve found ways to push that boundary further with files alone, I’d genuinely be curious - this still feels like an open design space.
  
  Reply View | 1 reply
  
  gbnwl a day ago
  
  You're still not closing the gap between the problems you're naming and how your solution solves them?
  > With a flat file, both agents can read it, but you’re relying on humans as the coordination layer: deciding which docs are authoritative, when plans are superseded, which tickets are still valid, and how context should be scoped for a given agent.
  So the memory system also automates project management by removing "humans as the coordination layer"? From the OP the only details we got were
  "What it does: (1) persists context between sessions (2) semantic & temportal search (not just string grep)"
  Which are fine, but neither it nor you explain how it can solve any of these broader problems you bring up:
  "deciding which docs are authoritative, when plans are superseded, which tickets are still valid, and how context should be scoped for a given agent, questions like who can read vs. update which parts of context, how to share only relevant decisions, how agents discover what matters without scanning a growing pile of files, and how updates propagate without state drifting apart."
  You're claiming that semantic and temporal search has solved all of this for free? This project was presented as a memory solution and now it seems like you're saying its actually an agent orchestration framework, but the gap between what you're claiming your system can achieve and how you claim it works seems vast.
  
  Reply View | 0 replies
stingraycharles a day ago

imho, if it’s not based on a RAG, it’s not a real memory system. the agent often doesn’t know what it doesn’t know, and as such relevant memories must be pushed into the context window by embedding distance, not actively looked up.

Reply View | 0 replies
austinbaggio a day ago

Which of the 1000 is your favorite? There does seem to be a shallow race to optimizing xyz benchmark for some narrow sliver of the context problem, but you're right, context problem space is big, so I don't think we'll hurry to join that narrow race.

Reply View | 3 replies
- gbnwl a day ago
  
  | Which of the 1000 is your favorite?
  None, that's what I'm trying to say. My favorite is just storing project context locally in docs that agents can discover on their own or I can point to if needed. This doesn't require me to upload sensitive code or information to anonymous people's side projects and has and equivalent amount of hard evidence for efficacy (zero), but at least has my own anecdotal evidence of helping and doesn't invite additonal security risk.
  People go way overboard with MCPs and armies of subagents built on wishes and unproven memory systems because no one really knows for sure how to get past the spot we all hit where the agentic project that was progressing perfectly hits a sharp downtrend in progress. Doesn't mean it's time to send our data to strangers.
  
  Reply View | 1 reply
  
  gck1 a day ago
  
  > no one really knows for sure how to get past the spot we all hit where the agentic project that was progressing perfectly hits a sharp downtrend in progress.
  FWIW, I find this eventual degradation point comes much later and with fewer consequences when there are strict guardrails inside and outside of the LLM itself.
  From what I've seen, most people try to fix only the "inside" part - by tweaking the prompts, installing 500 MCPs (that ironically pollute the context and make problem worse), yell in uppercase in hopes that it will remember etc, and ignore that automated compliance checks existed way before LLMs.
  Throw the strictest and most masochistic linting rules at it in a language that is masochistic itself (e.g. rust), add tons of integration tests that encode intent, add a stop hook in CC that runs all these checks and you've got a system that is simply not allowed to silently drift and can put itself back on track with feedback it gets from it.
  Basically, rather than trying to hypnotize an agent to remember everything by writing a 5000 line agents.md, just let the code itself scream at it and feed the context.
  
  Reply View | 0 replies
- Davidzheng a day ago
  
  Wait.
  
  Reply View | 0 replies
AndyNemmity a day ago

The funny part is, the vast majority of them are barely doing anything at all.
All of these systems are for managing context.
You can generally tell which ones are actually doing something if they are using skills, with programs in them.
Because then, you're actually attaching some sort of feature to the system.
Otherwise, you're just feeding in different prompts and steps, which can add some value, but okay, it doesn't take much to do that.
Like adding image generation to claude code with google nano banana, a python script that does it.
That's actually adding something claude code doesn't have, instead of just saying "You are an expert in blah"

Reply View | 7 replies
- austinbaggio a day ago
  
  It sounds like you've used quite a few. What programs are you expecting? Assuming you're talking about doing some inference on the data? Or optimizing for some RAG or something?
  
  Reply View | 3 replies
  
  AndyNemmity a day ago
  
  An example of a skill i gave, adding image generation to nano banana.
  another is one claude code ships with, using rip grep.
  Those are actual features. It's adding deterministic programs that the llm calls when it needs something.
  
  Reply View | 2 replies
- troupo a day ago
  
  > You can generally tell which ones are actually doing something if they are using skills, with programs in them.
  > Otherwise, you're just feeding in different prompts and steps
  "skills" are literally just .md files with different prompts and steps.
  > That's actually adding something claude code doesn't have, instead of just saying "You are an expert in blah"
  It's not adding anything but a prompt saying "when asked to do X invoke script Y or do steps Z"
  
  Reply View | 2 replies
  
  AndyNemmity 19 hours ago
  
  Skill are md files, but they are not just that. They are also scripts. That's what adding things are. You can make a skill that is just a prompt, but that misses the point of the value.
  You're packaging the tool with the skill, or multiple tools to do a single thing.
  
  Reply View | 1 reply
  
  troupo 15 hours ago
  
  In the end it's still an .md file pointing to a script that ends being just a prompt for the agent that the agent may or may not pick up, may or may not discover, may or may not forget after context compaction etc.
  There's no inherent magic to skills, or any fundamental difference between them and "just feeding in different prompts and steps". It literally is just feeding different prompt and steps.
  
  Reply View | 0 replies
willtemperley a day ago

Replace "Automation" with "Agentic coding" here:
https://xkcd.com/1319/

Reply View | 0 replies
Forgeties79 a day ago

Have you tried using it? Not being flippant and annoying. Just curious if you tried it and what the results were

Reply View | 11 replies
- Game_Ender a day ago
  
  Why should he put effort into measuring a tool that the author has not? The point is there are so many of these tools an objective measure that the creators of these tools can compare against each other would be better.
  So a better question to ask is - Do you have any ideas for an objective way to a measure a performance of agentic coding tools? So we can truly determine what improves performance or not.
  I would hope that internal to OpenAI and Anthropic they use something similar to the harness/test cases they use for training their full models to determine if changes to claude code result in better performance.
  
  Reply View | 2 replies
  
  morkalork a day ago
  
  Well, if I were Microsoft and training co-pilot, I would log all the <restore checkpoint> user actions and grade the agents on that. At scale across all users, "resets per agent command" should be useful. But then again, publishing the true numbers might be embarrassing..
  
  Reply View | 1 reply
  
  kuboble a day ago
  
  I'm not sure it's a good signal.
  I often use restore conversion checkpoint after successfully completing a side quest.
  
  Reply View | 0 replies
- gbnwl a day ago
  
  Who has time to try this when there's this huge backlog here: https://www.reddit.com/r/ClaudeAI/search/?q=memory
  
  Reply View | 6 replies
  
  Forgeties79 a day ago
  
  Have you tried any of those?
  
  Reply View | 4 replies
  
  [removed] a day ago
  
  [deleted]
  
  Reply View | 0 replies
- troupo a day ago
  
  It does nothing but send a bunch of data to a "alpha use at your own risk" third-party site that may or may not run some LLM on your data: https://ensue-network.ai/login
  
  Reply View | 0 replies
johnnyfived a day ago

I imagine HN, despite being full of experts and vet devs, also might have a prevalent attitude of looking down on using tools like MCP servers or agentic AI libraries for coding, which might be why something like this advertised seems novel rather than redundant.

Reply View | 6 replies
- DrewADesign a day ago
  
  > I imagine HN, despite being full of experts and vet devs, also might have a prevalent attitude of looking down on using tools like MCP servers or agentic AI libraries for coding, which might be why something like this advertised seems novel rather than redundant.
  I’m not sure where the ‘despite’ comes in. Experts and vets have opinions and this is probably the best online forum to express them. Lots of experts and vets also dislike extremely popular unrelated tools like VB, Windows, “no-code” systems, and Google web search… it’s not a personality flaw. It doesn’t automatically mean they’re right, either, but ‘expert’ and ‘vet’ are earned statuses, and that means something. We’ve seen trends come and go and empires rise and fall, and been repeatedly showered in the related hype/PR/FUD. Not reflexively embracing everything that some critical mass of other people like is totally fine.
  
  Reply View | 4 replies
  
  gbnwl a day ago
  
  I think maybe the point they were trying to make is that despite people on HN being very technically experienced, skepticism and distrust of LLM-assisted coding tools may have prevented many of them from exploring the space too deeply yet. So a project like this may seem novel to many readers here, when the reality for users who've been using and following tools like Claude Code (and similar) closely for a while now is that claims like the one's this project is making come out multiple times per week.
  
  Reply View | 3 replies
- troupo a day ago
  
  Because experts snd vets can uduslly quickly disassemble layers of marketing bullshit and see through false promises?
  Because experts snd vets often use these tools and find them extremely lacking?
  
  Reply View | 0 replies

ossa-ma a day ago

There are a quadrillion startups (mem0, langmem, zep, supermemory), open source repos (claude-mem, beads), and tools that do this.

My approach is literally just a top-level, local, git version controlled memory system with 3 commands:

- /handoff - End of session, capture into an inbox.md

- /sync - Route inbox.md to custom organised markdown files

- /engineering (or /projects, /tasks, /research) - Load context into next session

I didn't want a database or an MCP server or embeddings or auto-indexing when I can build something frictionless that works with git and markdown.

Repo: https://github.com/ossa-ma/double (just published it publicly but its about the idea imo)

Writeup: https://ossa-ma.github.io/blog/double

Reply View 5 replies

bl4ckneon a day ago

The extention Cline has a "memory bank" feature. It's just a markdown you add as an instruction. Works well for me. Worked with agents.md as well so not just with the Cline extention. Pretty much the same idea.

Reply View | 0 replies
fastball a day ago

What is the purpose of a separate /handoff and /sync command? It seems like handoff could just write learnings straight to their final destinations without needing an .inbox.md buffer in-between.

Reply View | 1 reply
- ossa-ma a day ago
  
  I like to read and review what was captured in .inbox.md before it is committed and synced across my knowledge base. Allows me to catch mistakes, tweak preferences, add context and decide whether something is actually worth pushing.
  I will typically make multiple '/handoff's per day as I use Claude code whereas I typically use '/sync' at the end of the day to organise them all at once.
  
  Reply View | 0 replies
AndyNemmity a day ago

Your approach essentially matches mine, but I call them plans. I agree with you that the other tools don't seem to add any value compared to this structure.
I think at this point in time, we both have it right.

Reply View | 0 replies
kaizenb a day ago

Will explore this idea, thanks.

Reply View | 0 replies

coffeeboy27 2 days ago

What's the data retention/deletion policy and is there a self-hosted option planned? I'd prefer not to send proprietary code to third-party servers.

Reply View 3 replies

austinbaggio 2 days ago

Honestly, very reasonable ask, you're not the first person to ask for a self-hosted version. We have a privacy policy we've drafted that is up-to-date with the current version of the product https://www.ensue-network.ai/privacy-policy.
The project is still in alpha, so you could shape what we build next - what do you need to see, or what gets you comfortable sending proprietary code to other external services?

Reply View | 2 replies
- frumplestlatz 2 days ago
  
  > what do you need to see, or what gets you comfortable sending proprietary code to other external services?
  Honestly? It just has to be local.
  At work, we have contracts with OpenAI, Anthropic, and Google with isolated/private hosting requirements, coupled with internal, custom, private API endpoints that enforce our enterprise constraints. Those endpoints perform extensive logging of everything, and reject calls that contain even small portions of code if it's identified as belonging to a secret/critical project.
  There's just no way we're going to negotiate, pay for, and build something like that for every possible small AI tooling vendor.
  And at home, I feed AI a ton of personal/private information, even when just writing software for my own use. I also give the AI relatively wide latitude to vibe-code and execute things. The level of trust I need in external services that insert themselves in that loop is very high. I'm just not going to insert a hard dependency on an external service like this -- and that's putting aside the whole "could disappear / raise prices / enshittify at any time" aspect of relying on a cloud provider.
  
  Reply View | 1 reply
  
  austinbaggio a day ago
  
  Yeah I get the dependency concern, and also I think about the trust and pricing challenge a lot. I might be getting ahead of my skis here, but living in a future world, assuming there is a local service, what would you want to see with a context management service for your team to actually use it? Or even better - pay for it?
  
  Reply View | 0 replies

qudat 2 days ago

Have you tried https://github.com/steveyegge/beads

Reply View 5 replies

rahimnathwani 15 hours ago

Beads is awesome. I've been using it with a greenfield React Native hobby project. I did some work up front on the spec (with help from AI), and started the repo from a boilerplate, but after that every single bead (epic, ticket) and every single line of code has been written by AI (using a mix of claude, codex, cursor-agent/composer-1).
The app works. When I feel like working on it, I just open a CLI coding agent and say 'start working'. Then every so often I say 'commit and push' or 'find opportunities to improve the code base by refactoring, and create an issue for each opportunity'.
(I followed the instructions to add the boilerplate instructions for both bd and bv, to AGENTS.md)

Reply View | 0 replies
jswny a day ago

Can you give an example of how beads would be used by Claude to do something it otherwise couldn’t? I can’t quite tell what it is useful for

Reply View | 1 reply
- frankc a day ago
  
  Personally, I have been using beads for a few days on a couple of projects. I also like https://github.com/Dicklesworthstone/beads_viewer which is a nice tui for beads (with some additional workflow i haven't tried). I have found its been useful for longer, multi-session implementations. Its easier to get back into the work. I wouldn't go so far as to it couldn't do the work without it, but so far it seems smoother. These things are hard to measure. I think the it's really not that different than how an engineering team would use jira but more hierarchical, which helps preserve context, and with prebuilt instructions for how the agent should use it.
  
  Reply View | 0 replies
PrayagS a day ago

+1 to beads. Works great

Reply View | 0 replies
zyan1de 2 days ago

oh yeah beads is awesome! I'd say this is a bit more general purpose rn especially what is in the skill!

Reply View | 0 replies

JoshGlazebrook 2 days ago

Is anyone else just completely overwhelmed with the number of things you _need_ for claude code? Agents, sub agents, skills, claud.md, agents.md, rules, hooks, etc.

We use Cursor where I work and I find it a good medium for still being in control and knowing what is happening with all of the changes being reviewed in an IDE. Claude feels more like a black box, and one with so many options that it's just overwhelming, yet I continue to try and figure out the best way to use it for my personal projects.

Claude code suffers from initial decision fatigue in my opinion.

Reply View 64 replies

levocardia a day ago

I just take a grug brain approach. I do touch CLAUDE.md and then just explain how the code/files/project spec work, like I'm writing a slack message or email to a really smart colleague, and then let it rip, always using biggest model with thinking on. If something consistently goes wrong I add more to CLAUDE.md or even better, have Claude Code just update CLAUDE.md itself with the new issue explained. I'm probably 3 months behind what you could get with absolute SOTA practices but it still works so well that I'm amazed and amused on a daily, if not hourly, basis.

Reply View | 0 replies
dimitri-vs a day ago

I'm in Claude Code 30+ hr/wk and always have a at least three tabs of CC agents open in my terminal.
Agree with the other comments: pretty much running vanilla everything and only the Playwright MCP (IMO way better than the native chrome integration) and ccstatusline (for fun). Subagents can be as simple as saying "do X task(s) with subagent(s)". Skills are just self @-ing markdown files.
Two of the most important things are 1) maintaining a short (<250 lines) CLAUDE.md and 2) having a /scratch directory where the agent can write one-off scripts to do whatever it needs to.

Reply View | 10 replies
- jswny a day ago
  
  I also specifically instruct Claude how to use a globally git ignored scratch folder “tmp” in each repo. Curious what your approach is
  
  Reply View | 2 replies
  
  austinbaggio a day ago
  
  You store your project context in an ignored tmp folder? Share more plz - what does it look like? What do you store?
  
  Reply View | 1 reply
  
  jswny a day ago
  
  Not memory, I just instruct it to freely experiment with temporary scripts and artifacts in a specific folder.
  This helps it organize temporary things it does like debugging scripts and lets it (or me) reference/build on them later, without filling the context window. Nothing fancy, just a bit of organization that collects in a repo (Git ignored)
  
  Reply View | 0 replies
- brigandish a day ago
  
  How can you - or any human - review that much code?
  
  Reply View | 6 replies
  
  Normal_gaussian a day ago
  
  When I'm coding I have about 6 instances of VSCode on the go at once; each with their own worktree and the terminal is a dangerous cc in docker. most of the time they are sitting waiting for me. Generally a few are doing spec work/reporting for me to understand something - sometimes with issue context; these are used to plan or redirect my attention if I might've missed something. A few will be just hacking on issues with little to no oversight - I just want it to iterate tests+code+screenshots to come up with a way to do a thing / fix a thing, I'll likely not use the code it generates directly. Then one or two are actually doing work that I'll end up PR'ing or if I'm reviewing they'll be helping me do the review - either mechanically (hey claude, give me a script to launch n instances with a configuration that would show X ... ok, launch them ... ok, change to this ... grab X from the db ... etc.) or insight based (hey claude, check issue X against code Y - does the code reflect their comments; look up the docs for A and compare to the usage in B, give me references).
  I've TL'd and PM'd as well as IC'd. Now my IC work feels a lot more like a cross between being a TL and being a senior with a handful of exuberant and reasonably competent juniors. Lots of reviewing, but still having to get into the weeds quickly and then get out of their way.
  
  Reply View | 2 replies
  
  dimitri-vs a day ago
  
  TBH I'm not building "production grade" apps depended on by hundreds of thousands of users - our clients want to get to a live MVP as fast as possible and love the ability to iterate quickly.
  That said, it's well know that Anthropic uses CC for production. You just slow things down a bit, spend more time on the spec/planning stage and manually approve each change. IMO the main hurdle to broader Claude Code adoption isn't a code quality one, it's mostly getting over the "that's not how I would have written it" mindset.
  
  Reply View | 0 replies
  
  bpolly a day ago
  
  From personal experience, most of my time in Claude Code is spent experimenting, iterating, and refining approaches. The amount of code it produces as it relates to time spent working on it tends to be pretty logarithmic in practice.
  
  Reply View | 0 replies
  
  blks a day ago
  
  They don’t, they just push garbage, someone else quickly looks over it (or asks another llm to review for him), and merges.
  
  Reply View | 0 replies
asdev 2 days ago

you really don't need any of this crap. you just need Claude Code and CLAUDE.MD in directories where you need to direct it. complicated AI set ups are mid curve

Reply View | 17 replies
- parpfish a day ago
  
  I refuse to learn all the complicated configuration because none of it will matter when they drop the next model.
  Things that need special settings now won’t in the future and vice versa.
  It’s not worth investing a bunch of time into learning features and prompting tricks that will be obsoleted soon
  
  Reply View | 12 replies
  
  AndyNemmity a day ago
  
  I wish that were true. Models don't feel like they've really had massive leaps.
  They do get better, but not enough to change any of the configuration I have.
  But you are correct, there is a real possibility that the time invested with be obsolete at some point.
  For sure the work towards MCPs are basically obsolete via skills. These things happen.
  
  Reply View | 11 replies
- wouldbecouldbe a day ago
  
  It seems to mostly ignore Claude.md
  
  Reply View | 3 replies
  
  songodongo a day ago
  
  If you can test how often it is being used by having a line in there saying something like “You must start every non-code response with ‘Woohoo!’”
  
  Reply View | 0 replies
  
  csar a day ago
  
  It’s told to only use it if relevant because most people write bad ones. Someone should write a tool to assess CLAUDE.md quality.
  
  Reply View | 0 replies
  
  AndyNemmity a day ago
  
  It does, Claude.md is the least effective way to communicate to it.
  It's always interesting reading other people's approaches, because I just find them all so very different than my experience.
  I need Agents, and Skills to perform well.
  
  Reply View | 0 replies
_the_inflator a day ago

I like the finetuning aspect to it quite a lot. It makes sense to me. What I achieved now is a very streamlined process of autonomous work of an agent, which can more and more often be simply managed than controlled on a code review level basis for everything.
I agree that this level of finetuning feels overwhelming and might let yourself doubting whether you do utilize Claude to its optimum and the beauty is, that finetunging and macro usage don't interfere, when you stay in your lane.
For example I now don't use the planing agent anymore instead incorporated this process into the normal agents much to the project's advantage. Consistency is key. Anthropic did the right thing.
Codex is quite a different beast and comes from the opposite direction so to say.
I use both, Codex and Claude Opus especially, in my daily work and found them complementary not mutual exclusive. It is like two different evangelists who are on par exercising with different tools to achieve a goal, that both share.

Reply View | 1 reply
- AndyNemmity a day ago
  
  Yeah, at a certainly level, it's just a ton of fun to do. I think that's why so many of us are playing with it.
  It's also deeply interesting because it's essentially unsolved space. It's the same excitement as the beginning of the internet.
  None of us know what the answers will be.
  
  Reply View | 0 replies
wouldbecouldbe a day ago

All I use is curse words and it does a damn great job most of the time

Reply View | 3 replies
- lobito25 a day ago
  
  Same here :)))), he's really good at understanding when you're pissed off.
  
  Reply View | 0 replies
- nineteen999 a day ago
  
  I thought I was the only one.
  
  Reply View | 0 replies
- anonzzzies a day ago
  
  Yep, that usually works best.
  
  Reply View | 0 replies
eterm 2 days ago
This isn't necessary. Claude will read CLAUDE.md from both:
1. Current directory ./CLAUDE.md 2. User directory ~/.claude/CLAUDE.md
I stick general preferences in what it calls "user memory" and stick project specific preferences in the working directory.
Reply View | 0 replies
austinbaggio 2 days ago

It feels like Claude is taking more of the Android approach of a less opinionated, but more open stack, so people are bending it to the shape they want to match their workflow. I think of the amnesia problem as pretty agent-agnostic, though, knowing what happens while you're delivering product is more of an agent execution layer problem than a tool problem, and it gets bigger when you have swarms coordinating - Jaya wrote a pretty good article about this https://x.com/AustinBaggio/status/2004599657520123933?s=20

Reply View | 0 replies
AndyNemmity a day ago

I'm the opposite, I find it straight forward to use all these things, and am surprised people aren't getting it.
I've been trying to write blogs explaining it recently, but I don't think I'm very good at making it sound interesting to people.
What can I explain that you would be interested in?
Here was my latest attempt today.
https://vexjoy.com/posts/everything-that-can-be-deterministi...

Reply View | 13 replies
- majormajor a day ago
  
  You say "My Claude Code Setup" but where is the actual setup there? I generally agree with everything about how LLMs should be called you say, but I don't see any concrete steps of changing Claude Code's settings in there? Where are the "35 agents. 68 skills. 234MB of context."? Is the implementation of the "Layer 4" programs intended to be left to the reader? That's hardly approachable.
  
  Reply View | 12 replies
  
  AndyNemmity a day ago
  
  I got similar feedback with my first blog post on my do router - https://vexjoy.com/posts/the-do-router/
  Here is what I don't get. it's trivial to do this. Mine is of course customized to me and what I do.
  The idea is to communicate the ideas, so you can use them in your own setup.
  It's trivial to put for example, my do router blog post in claude code and generate one customized for you.
  So what does it matter to see my exact version?
  These are the type of things I don't get. If I give you my details, it's less approachable for sure.
  The most approachable thing I could do would be to release individual skills.
  Like I have skills for generating images with google nano banana. That would be approachable and easy.
  But it doesn't communicate the why. I'm trying to communicate the why.
  
  Reply View | 11 replies
minimaxir 2 days ago

With Opus 4.5 in Claude Code, I'm doing fine with just a (very detailed) CLAUDE.md.

Reply View | 2 replies
- austinbaggio 2 days ago
  
  Do you find you want to share the .md with the teams you work with? Or is it more for your solo coding?
  
  Reply View | 1 reply
  
  Myrmornis a day ago
  
  Not saying you were suggesting it but people committing AGENTS.md in shared repos is pretty annoying IMO. Those things are personal.
  
  Reply View | 0 replies
lukev 2 days ago

A claude.md file will give you 90% of what you need.
Consider more when you're 50+ hours in and understand what more you want.

Reply View | 1 reply
- AndyNemmity a day ago
  
  In my experience, I'm at the most where I entirely ignore Claude.md - so it's very interesting how many people have very different experiences.
  
  Reply View | 0 replies
austinbaggio a day ago

It is overwhelming. We have support for Cursor mcp as well, but you lose a lot of the auto-magic stuff you get with the Claude Code plugin. Unfortunately, skills are pretty sticky to the Claude Code stack. It is kind of the vim of AI coding agents. . . One of the goals for this tool was to address context management in a single place. i.e instead of setting up all of the rules, claude.md, and skill.md you just semantic query a specific namespace in your knowledge base.
the docs if you are curious: https://www.ensue-network.ai/docs

Reply View | 0 replies
einsteinx2 a day ago

I use both Cursor and Claude Code in VS Code at work (so I get similar control as Cursor). I don’t really use Claude Code any differently than cursor. People way over complicate it.

Reply View | 0 replies
pigpop a day ago

You don't need all that, just have Claude write the same documentation you would (should) write for any project. I find it best to record things chronologically and then have Claude do periodic reviews of the docs and update key design documents and roadmap milestones. The best part is you get a written record of everything that you can review when you need to remember when and why something changed. They also come in handy for plan mode since they act as a guide to the existing code.
The PMs were right all along!

Reply View | 0 replies
csar a day ago

Claude Code is better out of the box, so all that other stuff is orthogonal or optional. If you eg want to give your agent access to your company’s Notion docs you need a skill.

Reply View | 0 replies
metadat 2 days ago

Don't forget about the co-agents.. yeah.

Reply View | 0 replies
animitronix a day ago

Nope, I spend time learning my tools.

Reply View | 0 replies
saidcooldude2 a day ago

[dead]

Reply View | 0 replies

johann8384 9 hours ago

I have markdown files in ~/.claude/guides that I refer to, my subagents have instructions about, and my claude.md in several projects reference them when relevant.

This seems like it wouldn't accomplish much more than those methods. It knows my stack preferences, what I want commit messages to look like, etc.