Introducing Kilo Memory: Project-Scoped Memory for Your Agents

Kilo has introduced Kilo Memory, a local, project-scoped memory system for AI coding agents that stores session digests, project environment details, user corrections, and explicit memory updates to share context across sessions and worktrees. The feature, available in Kilo's CLI and VS Code Agent Manager, captures high-signal information on session close and recalls it via startup injection, prompt-targeted recall, and an explicit tool, with a consolidation step to keep memory lean and token costs low.

Introducing Kilo Memory: Project-Scoped Memory for Your Agents Your agents shouldn't have to re-learn your project every session The other day, one of our engineers was debugging an issue in Kilo’s CLI. He’d spent a full session isolating the problem, identifying the root cause, and narrowing down the fix. Then his session timed out. He started a fresh one, and the agent immediately tried the exact thing he’d already ruled out twenty minutes earlier. This is a familiar frustration. Every new AI coding session starts from zero. The agent has to re-derive your project structure, re-read your test setup, re-figure out your deployment pipeline. It doesn’t know that you prefer vitest over jest, that the packages/core directory has a weird circular dependency you’ve been working around, or that the last three sessions all failed because of a missing environment variable. We built Kilo Memory https://github.com/Kilo-Org/kilocode/pull/11172 to fix that. How engineers actually work now The way we write code has changed. I don’t have one terminal open with one coding session anymore. On a typical day, I might have: A CLI session refactoring a module A VS Code Agent Manager tab running tests in parallel Another session handling a quick PR review An agent in GitHub dealing with a bug in a related service That’s four surfaces, all working in the same repo, all starting with no shared context. Each new session is a blank slate that has to bootstrap itself — read file calls, directory traversals, grepping through git history just to understand what happened an hour ago. Multiply that by a team, and you’ve got agents spending significant portions of their context window just getting oriented. What Kilo Memory does Kilo Memory is a local, project-scoped memory system. Memories are stored in Kilo's global data directory, with each repository getting its own isolated memory store for example, <Kilo Global Path /memory/<repo-path-hash . When enabled, it lets your agents share context across sessions and worktrees, so you don't have to manually re-explain things every time you switch contexts. It stores: Session digests — Short summaries of what happened in recent sessions capped at the last 10 Project environment — Your repo setup, testing config, build pipeline, relevant tooling context User corrections — When you tell the agent “no, we don’t use that library” or “always run tests with --coverage”, it remembers Explicit memory updates — Anything you explicitly tell Kilo to remember or forget for example, using /memory . And it recalls context in three ways: Startup injection — High-signal project context gets loaded at session start Prompt-targeted recall — When your current request looks memory-relevant, it pulls in related context Explicit tool recall — The kilo memory recall tool with search, typed, digest, and catalog modes The key design decision: a consolidation step decides what’s worth saving. Most things get skipped. This keeps memory lean and token costs low rather than naively dumping everything into a growing blob. The architecture Memory is file-system based and stored locally on your machine. There is no separate cloud sync or external memory database. Memory is stored in Kilo’s global data directory and scoped to each project using a hash of its repository path, so every repository gets its own isolated memory store. The memory store consists of durable memory files, short session digests, and a search index. Memory Store ├── Memory files ├── Sessions/ └── Search index Capture happens automatically on session close. When a session ends, the system evaluates what’s worth remembering — decisions made, corrections issued, environment details discovered — and writes only durable, useful information. Recall is selective. Rather than expensive full-index searches on every turn, a digest layer sits above the index and only triggers deeper recall when the current request looks memory-relevant. Memory can be enabled or disabled through the configuration or the /memory commands. If anything goes sideways, a single toggle turns it off without deleting stored memory. Controlling memory The same /memory commands are available in the CLI, TUI, and VS Code chat. Commands: /memory on|off — Toggle memory on or off /memory auto on|off — Toggle automatic memory capture on or off /memory remember <message — Explicitly save something /memory status — View memory status and configuration /memory show — Inspect what’s stored /memory forget <query — Remove specific memories /memory purge — Removes all project memory files completely VS Code also provides a dedicated Settings page for memory control and storage inspection. When you disable memory, no context is injected — but your memory remains on disk. You can re-enable it at any time without losing anything. Why local matters I’ve been watching the memory-for-agents space closely. Engram https://github.com/cyanheads/engram-mcp-server uses SQLite, Continuum https://www.continuum.sh/ is MCP-based, Kairo https://github.com/nicobailon/kairo scans your repo once and remembers architecture, mem0 https://mem0.ai/ is building managed memory services. All of them are external tools that require separate setup and MCP plumbing. Kilo Memory is different because it's built into Kilo. No MCP server to configure. No external service to trust with your codebase context. Once enabled, it works across the CLI, TUI, and VS Code without requiring separate integrations for each surface. Trade-offs and limitations This is still experimental. Some things to know: Capture quality is still evolving — The consolidation step tries to retain durable, useful information while filtering out transient, noisy, or sensitive context, but the heuristics are not perfect yet. Multilingual support is still evolving — Memory is designed to work across languages rather than relying on English-specific logic. As a result, capture and retrieval quality may occasionally be less precise while the system continues to improve. Needs adversarial testing — We haven’t fully stress-tested for false positives injecting irrelevant memory , stale facts remembering something that’s no longer true , or missed recalls failing to surface relevant context . Prompt injection surface — Memory content is injected as non-instructional context, but any time you inject stored text into a model context, you need to think about prompt injection boundaries. We’re reviewing this carefully. Stored outside the repository — Memory is stored in Kilo’s global data directory rather than inside the repository. This allows it to be shared across worktrees and keeps generated files out of the project, but it also means memory cannot currently be versioned or shared with teammates through Git. Memory ships as an opt-in feature. Turn it on if you want to try it. Turn it off if it gets in the way. Try it Kilo Memory is available now as an opt-in feature. To enable it: Make sure you’re on the latest Kilo version In any session, run /memory enable Work normally — memory captures automatically on session close Start a new session and notice the agent already knows your project context Tell it to remember specific things: /memory remember we use pnpm, not npm or / memory remember the auth service requires REDIS URL to be set locally. If you hit issues or have feedback, drop into the Kilo Discord https://discord.gg/kilocode — we’re actively collecting input on recall quality, capture decisions, and what kinds of context are most useful to persist. Kilo Memory is part of PR 11172, built by johnnyeric.