Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: Recall – Local project memory for Claude Code

github.com

Post reply on HN
Print view View original

51–60 of 96 posts

Re: Show HN: Recall – Local project memory for Claude Code

#51

Post by jack_pp »

andai wrote: post #50
blitzar wrote: post #48

Earlier quoted context omitted.

In some sessions I find claude to be incredibly dumb - other times we are on the same wavelength and everything flows. I guess I need to do some claude.md work or find other ways to prime the session so i get the good personality and not the evil twin.

Claude Code has a big system prompt, most of which isn't necessary for the more recent models. (Codex too.) I've been running Claude and GPT in my own agent harness. The main difference I notice is that tasks take about 7x longer to complete if they're run in the official Claude or Codex harness (and cost me 7x more). You would think this would lead to increased correctness, but that doesn't seem to be the case. Toda…

So you are using the API directly in your own harness without the subscription?

Re: Show HN: Recall – Local project memory for Claude Code

#52

Post by sdesol »

suprjami wrote: post #25
serial_dev wrote: post #13

I might be missing out on something but I never had to explain my project. Just give it a task, or if you really want to, type it quickly, then you are good to go. I can’t imagine this being worth optimizing. The issue is never that Claude can’t figure out what the projects is about… Am I missing something or does this project not solve a problem most regular people have?

There are many other posts here which agree with you. Filling context with what you think the model needs adds nothing and possibly just inflates context which is harmful. A good method seems to be only make a skill or memory when the LLM gets something wrong, or if you actually observe it's always doing the same step and you can get the model to the same place with less tokens.

> Filling context with what you think the model needs adds nothing and possibly just inflates context which is harmful.

The solution that I've developed is, let the agent figure things out efficiently, without inflating the context. I have what I call a smart repo that better explains this at

https://github.com/gitsense/smart-ripgrep

The basic idea is, when the agent does a ripgrep it gets back files + matching lines + context.

Re: Show HN: Recall – Local project memory for Claude Code

#53

Post by andai »

jack_pp wrote: post #51
andai wrote: post #50

Earlier quoted context omitted.

Claude Code has a big system prompt, most of which isn't necessary for the more recent models. (Codex too.) I've been running Claude and GPT in my own agent harness. The main difference I notice is that tasks take about 7x longer to complete if they're run in the official Claude or Codex harness (and cost me 7x more). You would think this would lead to increased correctness, but that doesn't seem to be the case. Toda…

So you are using the API directly in your own harness without the subscription?

Yeah, I made a simple agent based on this tutorial:

https://minimal-agent.com/

It's slightly bigger now, but here's a ~50 line version for reference. I added the missing outer while-loop, so it takes user input etc.

https://gist.github.com/a-n-d-a-i/bd50aaa4bdb15f9a4cc8176ee3...

I mostly use it with GLM via their coding plan, I got a year for like $20 when it was on sale. But I also hooked it up to Sonnet, Opus, GPT, etc.

Re: Show HN: Recall – Local project memory for Claude Code

#54

Post by computerex »

mikeocool wrote: post #33

I apparently use Claude differently the most people who talk about using Claude on the internet. I’ll typically have a bunch of short sessions over the course of a day. Anytime I start a task that isn’t going to very directly benefit from the existing context I start fresh. I don’t find a lot of benefit in explaining the project overall to Claude — I’ve deleted a lot of that explanation from my Claude.md because it d…

I work in a completely different manner. I have a chief of staff agent, which is one Claude code instance that orchestrates work across all my projects simultaneously with sub agents. In this way the agent helps me context switch and drive work towards everything I’m working on. I only use 1 session, I compact when necessary with todos and on file system files to track wip

Re: Show HN: Recall – Local project memory for Claude Code

#56

Post by kannanvijayan »

aubreykilian wrote: post #43

I have a documentation vault in my repo, organised using Obsidian (bases, wikilinks, frontmatter, etc), and accessible using obsidian-cli (and related Claude skills, thanks kepano). I started the repo agreeing with Claude the structure and front matter of documents and how to edit and read, all stored in a markdown file in the vault, and a specific instruction in the CLAUDE.md file on when and how to access it. Any u…

Yes I've found this to be the case as well. I've also found that it's useful to split these documents into three broad distinguished classes: goals, design, and idioms.

The goal docs provide directionality - helping the agent generally make consistent design decisions. Scoping constraints and stuff are useful to put here, but also feature goals a general idea of where the project is heading long-term (even if none of the items there are on the implementation roadmap anytime soon). It keeps more of the sessions aligned with each other.

The design docs specify the state of the project as it is, and are kept in sync during implementation sessions, by instructing the agents to treat their updates as part of the implementation plan for any work.

The idioms docs keep track of incidental decisions that don't relate to long term goals per se, but things like code style detail, specific project-related investigative techniques, code organization rules, build process guides, etc.

It's a single anecdote but I found that overall the work encountered fewer low-level design mismatches where one session doing work on one thing would make a design decision that didn't really mesh well with another session doing work on another thing. Overall hygiene took less work to maintain.

There are likely a variety of superior ways of organizing things, but at the very least it seems there's a ton of value to be squeezed from just organizing your project meta-information in certain ways. Definitely worth spending some time experimenting with.

Re: Show HN: Recall – Local project memory for Claude Code

#57

Post by senectus1 »

derwiki wrote: post #19
SubiculumCode wrote: post #12

Sometimes its good to start fresh. LLMs need large context restart's sometimes so they can better identify holes that they become blind to.

Back in the human age of coding, I felt the same way sometimes

what a depressing statement.

Re: Show HN: Recall – Local project memory for Claude Code

#58

Post by sdesol »

petee wrote: post #20
giancarlostoro wrote: post #3

I never have to because I use a ticketing system the model goes through in addition to a CLAUDE.md file with a summary, including vision, goals, non-goals etc

Any tricks to get Claude to actually use the CLAUDE.md consistently? Many times now its completely ignored it, despite being short, concise + generated by Claude itself, and I see bug reports about this that are over a year old

What behavioural things are you noticing that Claude does not pickup from the CLAUDE.md. I am working on a `pi-brains` extension for the Pi agent. It is designed to inject rules into write and edits tool calls for matching files.

I am curious if the behaviour you want is outside of writing and editing files.

Re: Show HN: Recall – Local project memory for Claude Code

#60

Post by bengotow »

mikeocool wrote: post #33

I apparently use Claude differently the most people who talk about using Claude on the internet. I’ll typically have a bunch of short sessions over the course of a day. Anytime I start a task that isn’t going to very directly benefit from the existing context I start fresh. I don’t find a lot of benefit in explaining the project overall to Claude — I’ve deleted a lot of that explanation from my Claude.md because it d…

This is my usage pattern and I agree it works really well. I start almost every conversation by asking Claude to read, not write. Then once it's explored a particular slice I let it rip.

This takes a couple minutes (and I suppose I'm spending tokens each time), but sessions rarely reach compaction length and I like that I'm not trying to keep a whole separate pile of docs in sync.

Post reply on HN