pacjam

Oh interesting - it's just a .mp4. I put it on vercel blob storage just as a fast way to make it easily embeddeded in our CMS system, but I think I put it on the wrong Vercel account and the bucket got rate limited (happened a few hours ago, which is when I think you were probably looking). Can you see it now? In my own Firefox it looks OK now.

I think it's mostly complimentary, in the same way a linear MCP would be complementary to a MemGPT/Letta-style memory system

I guess the main potential point of confusion would arise if it's not clear to the LLM / agent which tool should be used for what. E.g. if you tell your agent to use Letta memory blocks as a scratchpad / TODO list, that functionality overlaps with Beads (I think?), so it's easy to imagine the agent getting confused due to stale data in either location. But as long as the instructions are clear about what context/memory to use for what task, it should be fine / complementary.

Yes! Letta Code also has a "danger" mode, it's `--yolo`. If you're running Claude Code in a sandbox in headless mode, Letta Code has that too, just do something like `letta -p "Do something dangerous (it's just a sandbox, after all)" --yolo`

More on permissions here: https://docs.letta.com/letta-code/permissions

Install is just `npm install -g @letta-ai/letta-code`

Cool, let us know what you think! Would recommend trying w/ Sonnet/Opus 4.5 or GPT-5.2 (those are the daily drivers we use internally w/ Letta Code)

Yeah exactly - it's all just tokens that you have full control over (you can run CRUD operations on). No hidden prompts / hidden memory.

I'm curious - how do you currently manage this `llm.md` in the tooling you use? E.g., do you symlink `AGENTS/CLAUDE.md` to `llm.md`? Also, is there any information you duplicate across your project-specific `llm.md` files that could potentially be shared globally?

Ah gotcha! In that case, I think Terminal-Bench is currently the best proxy for "how good is this harness+agent combo at coding (quantitatively)" question. I think it used to be SWE-Bench, but I think T-Bench is a better proxy for this now. Like you said though, unfortunately Cursor isn't listed (probably their choice to not list it, maybe because it doesn't place highly).

Beads looks cool! I haven't tried it, but as far as I can tell, it's more of a "linear for agents" (memory as a tool), as opposed to baking long-term memory into the harness itself. In many ways, CLAUDE.md is a weak form of "baking memory into the harness", since AFAIK on bootup of `claude`, the CLAUDE.md gets "absorbed" and pinned in the system prompt.

Letta's memory system is designed off the MemGPT reference architecture, which is intentionally very simple - break the system prompt up into "memory blocks" (all pinned to the context window, since they are injected in system, which are modifiable via memory tools (the original MemGPT paper is still a good reference for what this looks like at a high level: https://research.memgpt.ai/). So it's more like a "living CLAUDE.md" that follows your agent around wherever it's deployed - ofc, it's also interoperable with CLAUDE.md. For example, when you boot up Letta Code and run `/init`, it will scan for AGENTS.md/CLAUDE.md, and will ingest the files into its memory blocks.

LMK if you have any other questions about how it works happy to explain more

Not sure why Cursor CLI isn't on the leaderboard... I'm guessing it's because Cursor is focused primarily on their IDE agent, not their CLI agent, and Terminal-Bench is an eval/benchmark for CLI agents exclusively.

If you're asking about why Letta Code isn't on the leaderboard, the TBench maintainers said it should be up later today (so probably refresh in a few hours!). The results are already public, you can see them on our blog (graphs linked in the OP). They are also verifiable, all data is available for the runs + Letta Code is open source, so you can replicate the results yourself.

Does somebody have a clear case on why this is something that we should want

For coding agents, I think it's clear that nobody wants to repeat the same thing over an over again. If a coding agent makes a mistake once (like `git add .` instead of manually picking files), it should be able to "learn" and never make the same mistake again.

Though I definitely agree w/ you that we shouldn't aspire to 1:1 replicate human memory. We want to be able to make our machines "unlearn" easily when needed, and we also want them to be able to "share" memory with other agents in ways that simply isn't possible with humans (until we all get neuralinks I guess)

IMO context poisoning is only fatal when you can't see what's going on (eg black box memory systems like ChatGPT memory). The memory system used in the OP is fully white box - you can see every raw LLM request (and see exactly how the memory influenced the final prompt payload).

I think it cuts both ways - for example I've definitely had the experience where when typing into ChatGPT I know ahead of time that whatever "memory" they're storing and injecting is likely going to degrade my answer, so I hop over to incognito mode. I've also had the experience where I've had a loosely related follow-up question to something and I didn't want to dig through my chat history to find the exact convo, so it's nice to know that ChatGPT will probably pull the relevant details into context.

I think similar concepts apply to coding - in some cases, you have all the context you need up front (good coding practices help with this), but in many cases, there's a lot of "tribal knowledge" scattered across various repos that a human vet working in the org would certainly know, but an agent wouldn't (of course, there's somewhat of a circular argument here that if the agent eventually learned this tribal knowledge, it could just write it down into a CLAUDE.md file ;)). I think there's also a clear separation between procedural knowledge and learned preferences, the former is probably better represented as skills committed to a repo, vs I view the latter more as a "system prompt learning" problem.

One cool option is having Void-2 run inside the Letta Code harness (in headless mode) on a sandbox to let is have free access over a computer, just to see what it will do while also connected to bluesky

I think Cameron (Void's handler) has some experience wiring up production Void to his computer via Letta Code

Thanks for sharing!! (Charles here from Letta) The original MemGPT (the starting point for Letta) was actually an agent CLI as well, so it's fun to see everything come full circle.

If you're a Claude Code user (I assume much of HN is) some context on Letta Code: it's a fully open source coding harness (#1 model-agnostic OSS on Terminal-Bench, #4 overall).

It's specifically designed to be "memory-first" - the idea is that you use the same coding agents perpetually, and have them build learned context (memory) about you / your codebase / your org over time. There are some built-in memory tools like `/init` and `/remember` to help guide this along (if your agent does something stupid, you can 'whack it' with /remember). There's also a `/clear` command, which resets the message buffer, but keeps the learned context / memory inside the context window.

We built this for ourselves - Letta Code co-authors the majority of PRs on the letta-code GitHub repo. I personally have been the same agent for ~2+ weeks (since the latest stable build) and it's fun to see its memory become more and more valuable over time.

LMK if you have any q's! The entire thing is OSS and designed to be super hackable, and can run completely locally when combined with the Letta docker image.

MemGPT was also first a CLI (and Discord bot), truly returning to our CLI roots: https://news.ycombinator.com/item?id=37901902

I'm talking about the Letta part - unless I'm missing something, the RunAgent framework has to communicate with the Letta server over the Letta API (I'm saying that part can be done w/ Python SDKs, TS SDKs, REST APIs, and down the line Rust natively etc).

This is pretty sweet. The Letta SDKs are actually auto-generated off of the REST API spec, which means that adding an (official) SDK for another language is just a matter of having enough demand to justify the spend to generate it. I did see a community-made Rust SDK here: https://github.com/orual/letta-rs

check out Letta - the OSS codebase (https://github.com/letta-ai/letta) is basically focused on solving the memory/context problem in a generalized way (via "agentic context management"). if you're more interested in papers, we also worked on MemGPT and more recently sleep-time compute (https://arxiv.org/abs/2504.13171)

If you're interested in the full schema you can look at the Pydantic models here: https://github.com/letta-ai/letta/blob/main/letta/serialize_...

Agent File is intended to support "one thread" agents, ie agents that have an indefinite conversation/event history, even if the underlying in-context message history is limited. That's why there's a distinction between just "messages" and "in-context messages" (a subset of messages).

Totally agree - a well-defined REST API "standard" for tool listing and tool execution would have been much better. Could extend as needed to websockets for persistent connections / streaming data.

In Letta that's referring to an LLM agent that has persistent memory (eg keep running the agent far beyond its context window limit, but maintain some persistent state to avoid derailment / enable indefinite use / learning over long horizons).

If you implement this persistent memory via tool use, then it's related to inserting/querying databases, because some agent has to read/write to a data store (potentially backed by a database) to maintain memories.

-charles from letta

indeed - hello there

I'm also not really sure what's going on with the hype wave atm (people like having things to hype?) since MCP has also been around for a bit, seems like a bit of a meme.

IMO, the main value (as an agent / AI developer) that you get from MCP is another style of tool repository. Similar to how it's nice to have pre-made tools (eg Composio), MCP servers are another repo of tools to pull from (you just need to add MCP client functionality to your agent loop). So if a ton of energy is going into building MCP servers, might as well add MCP client support so that you can take advantage of the additional tools.

-charles from letta

We're working on it, I'm hoping we can get an integration in sometime next week! If you want to track progress on it would recommend joining our Discord.

To clarify - by "it", I mean making Letta agents an MCP client, so that you can easily connect to MCP servers as tools (not the other way around, where Letta itself is an MCP server - if you want that, someone in the community already made one: https://github.com/oculairmedia/Letta-MCP-server)

-charles from letta

"voice interactive LLM with memory"

Our team has been working really hard on a low-latency voice integration that enables (open source) "advanced voice mode", but with long-term memory!

If you're interested definitely hop in our Discord to keep track of dev progress (you can also monitor our docs). It's all OSS of course, so you can use it with any model you want and run it all locally (your agent data stays on device).

Once available you can definitely use Letta for this usecase - basically provision a stateful Letta agent for your dad, with instructions / prompting that your dad has memory loss issues, and the agent should be proactive in recording memories (and potentially jogging your dad's memory too). All the memory/state will be stored in postgres, so you can expose it to other tools as well, eg could even collate the memories into a nextjs/mobile app where you dad can browse them.

-charles from letta

Super cool, as LLM agents continue to grow in popularity the field needs more open datasets for function calling + open models finetuned specifically for function calling. Excited to try and integrate the new function calling model into MemGPT and compare it to the various Mistral 7B finetunes.

Thanks for checking out the paper! Just to clarify in case there was any misunderstanding, recursive summarization is just one part of the memory management in MemGPT: as you mentioned, in MemGPT the conversation queue is managed via recursive summarization, just like in prior work (and many chatbot implementations). However there is also a (read/write) "pinned" section of "LLM memory" that's unrelated to recursive summarization, we call this "working context" in the paper. So MemGPT has access to both recursive summaries (generated automatically), as well as working context, which MemGPT actively manages to keep up-to-date.

These are both separate from MemGPT's external context, which is pulled into the conversation queue via function calls. In all our examples, reads from external context are uncompressed (no summarization) and paginated. MemGPT receives a system alert when the queue summarization is triggered, so if MemGPT needs to keep specific details from the conversation queue it can write it to working context before it's erased or summarized.

In the conversational agent examples, working context (no summarization, and separate from the conversation queue) is used to store key facts about the user and agent to maintain consistent conversation. Because the working context is always seen by the LLM, there's no need to retrieve it to see it. In doc QA, working context can be used to keep track of the current task/question and progress towards that task (for complex queries, this helps MemGPT keep track of details like the previous search, previous page request, etc.).

These are all great points - who or what you ask to manage memory is a design decision and IMO there's two main ways to do it (in the context of chatbots):

* implicit memory management, where the "main LLM" (or for chat, the "dialogue thread") is unaware that memory is being managed in the background (by a "memory LLM", a rule-based script, a small neural network, etc.), and

* explicit memory management (MemGPT), where one LLM does everything

Prior research in multi-session / long-range chat is often implicit, with a designated memory creation process. If I had to guess, I'd say the vast majority of consumer chatbots that implement some type of memory store are also implicit. This is because getting explicit memory management to work requires a lot of complex instruction following, and in our experience this just isn't possible at the moment with most publicly available LLMs (we're actively looking into ways to fix this via eg fine-tuning open models).

The tradeoffs are as you mentioned: with implicit, you don't have to stuff all the memory management instructions into the LLM preprompt (in MemGPT, the total system message is ~1k tokens). But on the upside, explicit memory management (when the LLM works) makes the overall system a lot simpler - there's no need to manage multiple LLM models running on parallel threads, which can add a lot of overhead.

Grammar-based sampling is a great idea and a perfect fit for something like MemGPT! In our experiments using MemGPT with non-gpt-4 models, the biggest issue impacting performance ended up being incorrect use of function parameters and function hallucination. For example, even large models finetuned on function call data (eg https://huggingface.co/jondurbin/airoboros-l2-70b-2.1#agentf...) would generally output correct parsable JSON, but the arguments or function name would be wrong. For example the LLM might output a call to `personal_diary.add` (never specified in the preprompt) instead of the correct `working_context.append` call (explicitly specified in the preprompt) when trying to write data.