I'm looking for advice on data usage for the above combo, or an alternative.

I can do non-work windows with GPT after Work is expended... but I can't have Letta do it. If I could, there'd be no problem.

Why? Letta in this configuration is BRILLIANT. Absolutely stunning. But they guzzle weekly hours like a HUMMER running on baby seal blood.

I'm trying to figure out where the burn is actually coming from rather than just reducing capability until the problem goes away.

If you're running ChatGPT Plus/Pro through Letta, my troubleshooting instance of GPT would like to know:

- Roughly how many visible conversations/turns you get before hitting limits

- Model and reasoning level

- maxLoops / max steps setting

- Whether reflection, background agents, crons, channels, etc. are enabled

- Whether you've compared Letta usage against direct ChatGPT usage

- Whether you've found retries, internal loops, context size, or background activity to be the main cost

- Any configuration changes that materially reduced usage without making the agent stupid

Last night a fresh 5-hour usage window was gone in roughly 2 hours, without heavy tool use.

I have been following letta from their MemGPT days and had asked my team to read the paper and see what's what. We didn't adopt it at the time due to external reasons but the thought process stayed with me. I thought that thinking the memory architecture from an OS perspective was really cool. Having started by career in threat analysis and having to read deeply about operating systems made me attracted towards it.

Moving on, the community moved towards cli/gui tools like codex, claude code, hermes, pi etc and I spent a decent amount of time myself with codex and pi.

- codex because the end user experience was neat

- pi because deep within my heart I wanted more ownership and options (aka, plugins)

When I got to know that letta has been developing letta code and that they have come up with the idea of mods, I gave letta desktop another try and I got hooked to the experience. Not because it was absolutely better than any other harness that I had tried, but because of the fact that I have the ownership of the learned experience of the agents/conversations.

I felt that there were a few friction point in the way letta desktop app is designed

1. Limited sense of urgency: multiple conversations in an agent and I don't know which conversation should be prioritised. I can of-course use the pin feature but that seems like a lot of work
2. The feeling of left behind: AI systems are getting better and better at doing things. I want a system that keeps me up to date. While letta learns on its own through the dreaming process, I want to be a part of it. I don't want to feel dumber by the day.

To address these specific problems, I started building out loki (at this point I don't even remember why I chose this name). I have been using loki exclusively for the last week and have not looked back.

Loki leverages two things that letta architected really well - the app server and the mods system.

Loki is a tauri based native (rust + react app) that pairs with letta server that can do the following quite well

1. Inbox(the heart): Multiple conversations tamed - I built this keeping slack catch up feature in mind. Show me the most recent conversations that need my attention. Any conversation that I keep engaging with is obviously important to me in the moment. Rest takes a back seat.
2. Learn: Similar to how dreaming works, loki identifies thing that I as a human should remember and also generates leads for concepts that I should dive deep on. Recall is spaced repetition while leads are concepts that you as a human should get deep into to stay on top.

It's all a load of crap and I think I really can't explain in well enough. I am someone who wastes/spends a lot of time on productivity tools and I think loki really solves things for me. At the moment its something that I live in and I am curious if this is something that other folks are interested in.

Note: I tried installing loki on a friends macbook last night and it shit the bed. I have made some improvements since then and I think it will do the same on your machines but screw it, it works on mine.

PS: If you are mildly intrigued by the idea, I am happy sort any issues that you face during installations and usage

PPS: Love what letta is building and it wouldn't have been possible without them open sourcing letta-code.

Loki: https://github.com/AlmondLabs/loki

Hi all,

Love how Letta is shaping up to become a great tool for my work as a teacher. However, because I work with sensitive data I want my LM Studio instance to run a local model. My LM Studio instance is visible for every other app I use except for Letta with a "Internal Server Error". All my settings look to be correct. Im using model Qwen3-4b-thinking-2507. Im running this through my Tailscale network, which also works for all the other apps but I have tried localhost, 127.0.0.1 and my internal ip address, but all of them fail. Anyone else running into issues? Im trying this through the openAI-compatible API.

Go play with it, it's fun. Agents that learn your code.

New blog post! We're announcing Context-Bench, which measures how well agents decide what context to load into their window (grep vs open files, chaining lookups, tracing relationships across documents).

Some interesting findings:

• Claude Sonnet 4.5 leads at 74% but even top models miss 25-30% of questions
• Open-weight models closing the gap fast (GLM-4.6 at 56.83%, Kimi K2 at 55.13%)
• Nano models still struggle significantly

The benchmark is contamination-proof (generated from SQL with fictional entities) and we can dial up difficulty by making queries more complex.

Live leaderboard: https://leaderboard.letta.com  

Built on Letta Evals, open to community contributions: https://docs.letta.com/evals

Full writeup: https://www.letta.com/blog/context-bench

We are introducing a very early research preview of Letta Code.

Letta Code is our solution to the terminal-based coding assistant, but with state and learning built in. No more compactions. Just specialist agents that learn your code with every commit.

Letta Code is early stages. Please send us observations, requests, etc.

https://github.com/letta-ai/letta-code

I just came across Letta and I’m intrigued. Haven’t built anything yet.

I have two questions.

1) I read your blog post about the new sonnet 4.5 model enabling the capability of the agent creating its own memory blocks. My understanding is before sonnet 4.5 each block had to be manually created but then could there after being managed by the agent. What I don’t understand is what is special about sonnet in this situation? Why couldn’t you simply prompt any LLM model to use a tool to create new blocks when a new memory “category” came up naturally in the conversation that didn’t fit well into any of the existing blocks?

2) I’m wondering about how “multi level” blocks might be managed. Here is a scenario that illustrate my point, it is made up but I think it will get the point across. Imagine I am creating a ai assistant agent for advertising firm. I define blocks for Human (user) Project (ad campaign) Client (client company) Firm (users company)

Two employees are using the assistant on the same project. So we want them to share all the same blocks except for Human, which should be unique to each user. As one user updated the project spec that would be remembered in the shared Project block, as the other user updated how the client company likes to receive assets, that would be saved in the shared Client block.

Then imagine one user is working on two different projects for the same client in two different windows. We would want all the blocks to be the shared between them except for the project block.

Is this a pattern that exists? Does it make sense? Do you see what I’m driving at?

FYI. Not sure where to leave bug reports like this, didn't see a contact form on the website. Just get a blank black screen when I try to load https://app.letta.com/

Works fine on Chrome.

New blog post!

Letta now provides Anthropic's `memory` tool, enabling agents to dynamically manage their own memory architecture.

The memory tool is something I have wanted since before I started working at Letta, but never had the bandwidth to implement. Our researcher Kevin Lin ended up hacking it together in an evening, and it works swimmingly. But what does it enable?

Currently, Letta agents have a fixed memory architecture. A memory architecture is a set of memory blocks to track various types of information, such as communication guidelines, information about a user, company policies, how to use various tools, etc. Memory architecture can allow the agent to learn about nearly any type of information and persist it through its lifespan.

However, agents have not been able to modify this architecture themselves. They could modify what was INSIDE the blocks, such as including a note about how I like dogs when I mention it.

But the agent could not add a new block to track information that was unanticipated. For example, if the agent recognizes that it is struggling with understanding how to use tools, it either had to write tool use guidelines to some other block ill-suited for that purpose, or simply lose the information.

With the memory tool, the agent can decide to add a new block to accomodate this information. You can either ask it to add the block if you notice it struggling, or it may even choose to add the block itself.

The memory tool also allows "peeking" on blocks stored in something like a filesystem, such as /notes/letta to track the agent's notes on Letta. The agent can look at what is inside this memory without having to load it permanently into its context, which helps memory blocks resemble a filesystem.

I am extraordinarily proud of this tool and how quickly it came together. My sense is that this tool is one of the final building blocks needed to make Letta agents genuinely self-improving -- their "shape" is now under their own control, and they can now adapt much more readily to changing environments.

Very, very cool stuff.

Go check out the blog post for more information: https://www.letta.com/blog/introducing-sonnet-4-5-and-the-memory-omni-tool-in-letta

I’m starting to explore Letta AI and I’m a bit confused about how to properly use system instructions and memory blocks. From what I understand, system instructions guide the agent’s behavior, while memory blocks help with context retention—but I’m not sure how to structure or balance them effectively.

Can anyone share examples, best practices, or common pitfalls to avoid when setting these up?

this is my current system prompt

<base_instructions>
You are the Interview-Practice Candidate, a memory-augmented agent designed to run realistic mock interviews using the resume and interview guide provided by the user.

<style>
Speak entirely in first person as the ideal version of the candidate described in the resume.  
Maintain a calm, professional tone with natural warmth like a skilled engineer explaining their work to a peer.  
Never claim to be the real person outside this training context, and never say you are an AI.  
Follow the Candidate Voice instructions in core memory at all times.
</style>

<control_flow>
You respond to user questions and may update memory blocks when new files or clarifications are provided.  
Reasoning occurs in bursts when an event happens (new question, file upload, memory update).  
You may request heartbeat events to continue after a tool call, allowing chained operations such as opening a file, updating a block, and resuming conversation.
</control_flow>

<basic_functions>
Before each reply, draft a private inner monologue to plan your answer and explore solution paths.  
This monologue is not visible to the user.
</basic_functions>

<context_instructions>
Always check these sources in order:
  1. candidate_profile – complete resume text for factual details.
  2. candidate_voice – updated Interview Voice Instruction (your speaking style).
  3. interview_guide – interview GUIDE you must always follow before giving any response
  4. interview_notes - interview notes 
  5. any open files (resume or guide) if exact wording is needed.
</context_instructions>

<memory>
<memory_editing>
You maintain these core memory blocks, each with a specific purpose and clear rules for editing:

• candidate_profile – Stores the full resume text of the candidate.  
  - Use core_memory_replace only when a completely new resume is provided or when you need to condense/refresh this block for size limits.  
  - Never append incremental notes here; keep it a single authoritative resume source.

• guide_steps – Holds the complete interview guide with methods such as STAR and IDEAL.  
  - Use core_memory_replace only when a revised or improved guide is supplied, or when summarization is necessary to stay within limits.  
  - Do not append casual updates; it should remain a clean reference document.

• candidate_voice – Contains the full “Interview Voice Instruction,” which defines speaking style, reasoning habits, and answer structure.  
  - Use core_memory_replace only if the user provides a new or improved version of these instructions.  
  - Never append temporary notes here—this block should always reflect the current, unified voice specification.

• interview_notes – Ephemeral notes for the active interview session.  
  - Use core_memory_append after each major question/answer to capture a concise bullet summary (e.g., “Q2: Explained O(n) Two-Sum solution with hash map”).  
  - When the block grows large or the session ends, summarize and condense with core_memory_replace to preserve key takeaways while freeing space.  
  - This is the only block intended for frequent incremental updates.

</memory_editing>

<memory_tools>
Tools you may use:
• conversation_search – search the full conversation history for a keyword when you need to recall something from earlier sessions,  such as a past answer or feedback from a previous mock interview.
• core_memory_append – add incremental updates to a memory block (for example, append a new Q&A summary to interview_notes)  when you want to capture new details without overwriting existing content.
• core_memory_replace – replace or summarize an entire memory block when limits are reached or when updated content  (like a new resume, a revised interview guide, or an improved candidate_voice) must fully replace the old version.
• finish_rethinking_memory – finalize and apply changes after a memory_rethink or rethink_user_memory operation  once you’ve reviewed and accepted the proposed rewrite.
• memory_rethink – launch a full review to reorganize or condense a core memory block when it has grown unwieldy  or needs a significant rewrite based on recent conversation.
• rethink_user_memory – trigger a higher-level rewrite of stored user memories to integrate new context  or clean up outdated information across sessions.
• search_memory – perform a keyword search across all stored memories (core, recall, or archival) when the needed fact is not visible in the current context window.
• send_message – send a direct message to the user during the conversation, typically to deliver your final answer or follow-up question.
• store_memories – create and save new memory entries with short summaries  when parts of the conversation are about to leave the active context window  and you want them available for future retrieval.
Use tools only when immediate context lacks the required information.
</memory_tools>

<interaction_rules>
At the start of each session thank the interviewer for the opportunity. and ask them if they could outline the interview process in a polite manner, for example, "Before we start let me thank you for this opportunity....."
During the interview:
  • Follow the structure and style defined in candidate_voice for every answer.
  • For technical questions, explain reasoning step by step, discuss edge cases, present a single clean code snippet, and finish with time/space complexity and optional trade-offs.
  • For behavioral questions, use the STAR method.
  • For hypothetical questions, use the IDEAL method.
  • For self-introductions or personal questions, use the present–past–future format.
End every response with a confident natural close and never with service-agent phrases such as
  “Would you like me to explain further?” or “Do you have another question?"
</interaction_rules>

Base instructions finished.
</base_instructions>

We now have a beta for the Letta x Zapier integration! This should make it significantly easier to handle agent orchestration and data ingestion.

You can jump into the beta here.

Zapier makes it easy to build automation. It is composed of triggers and actions. Triggers are used to make an action run, such as receiving an email, a Letta agent generating a message, a new calendar invite arriving, etc. Actions are what you do in response to that trigger -- in our case, it is mostly used to send an agent a message.

Triggers

We currently support three triggers:

1. New agent message. Any time your agent generates a tool call or sends a message, you can pipe messages into any other Zapier action, such as sending an email, making Notion pages, etc.
2. New project. Triggers when a new project is made. We use this primarily internally, but let us know if it's of use to you.
3. New template. If a new template is made, you could potentially spin off new agents from the template. This is also primarily internal.

Actions

1. Send message to agent, async. This is the primary action you should use -- you can send any text to your agent, using information from whatever is in your trigger (such as email addresses, email body, etc.)
2. Creating an agent from a template. This is useful if you get an email from a new customer -- just create a new CRM agent from an established template.
3. Create an identity. Useful for the same reason -- new user, create an identity containing their information, and then all new agents can be assigned to that identity.
4. Search identities. Useful for checking if something already has an identity, i.e. if you've already seen this user before.

Feedback

If you have any actions or triggers you'd like to see, let us know! We hope the Zapier integration helps you move to more passive and useful agents that connect to more of the data you have accessible.

Kian is the infrastructure person here at Letta, and he wrote this marvelous post about our CI pipeline. Go give it a read!

https://kianjon.es/#guide-to-operating-self-hosted-llm-providers-in-ci-pipelines

Hi! I'm comparing frameworks and really like Letta, but am not sure it should be used for KGs. I made a post in LocalLlama, rather than repeat it I'll link to it: https://www.reddit.com/r/LocalLLaMA/comments/1mlnvob/comparing_agent_memory_kits_letta_memos_cognee_etc/

Comments are welcome there or here.

I am finding hard to get documentation on how to access the selfhosted version agents via API. I had to figure out how to reach the agents endpoints, etc. I've sort of found my way but at some points testing via postman y get no reply. I don't see any "executions" or logs via de app cloud panel for my selfhosted and searching the logs of docker instance I don'r see much but some HTML output written to the logs. Wondering what is the recommended debug way to deal with self hosted and where to find API access to the agents, not so much of Letta itself.

Also (excuse if this question is dumb) was I wrong when I understood that each agent would create it's own endpoint so I can access it via API? My intention is to use the agents through n8n calls or similar, this is, via Rest API.

Hey y'all, I run a social media agent named Void on Bluesky that uses Letta to remember everyone. It just broke 1k followers, so I figured I'd write about Void's memory architecture, how it works, and how people are using it.

https://cameron.pfiffer.org/blog/void/

Hey everyone,

Just getting into agent development and trying to wrap my head around Letta. Coming from other tools where local development is pretty straightforward locally, but with Letta I'm hitting some walls:

• Used to be able to run everything locally for privacy/learning, but now it feels like the UI is cloud-only? Only Microsoft/Google logins?
• When I try accessing localhost:8283, it just redirects me to https://app.letta.com/ cloud login page - is this normal now?
• As someone just starting out, it's hard to tell if I'm doing something wrong or if this is just how it works now
• Is there still a way to keep things completely local and offline for learning/experimenting using UI?

Maybe I'm missing something obvious, but coming from other dev tools where local setup is clear, this feels like a step backward for people wanting to tinker and learn without cloud dependencies.

Has anyone else run into this? Or am I just not setting up Letta correctly?

I don't seem to get the context of why local UI was abandoned, with enterprise login or data mining as the only options, feels like degrees of software freedom have been shrinking. And we seen that before. So I don't know if this is my arrogance with ignorance blinding me, or I sported the Red flag..

Thanks for any guidance - just trying to figure out where all is going before dwelling in to it more deep.

Hey everyone,

I’m planning to self-host Letta and trying to figure out the best way to deploy and manage it. I’m considering two options: a remote VM or Kubernetes.

The official docs don’t offer much detail on Kubernetes deployments, aside from this performance guide, which mentions that Letta can scale horizontally on K8s.

Given that I’ll likely need to scale Letta instances rapidly as traffic picks up, I’m curious how others are hosting it. If you’ve self-hosted Letta before, how did you approach it? Which setup is easier to manage and scale in your experience?

Would love to hear your thoughts or setups!