If you’ve ever watched your AI coding assistant spend minutes re-reading the same files every session, you know the feeling: a mix of frustration and helplessness. You’re paying for every token, and the damn thing just can’t remember.
You’ve tried better prompts. You’ve tried fine-tuning. You’ve even tried switching models. But the core problem remains: every new session, your expensive AI agent re-digests the entire codebase from scratch.
That’s like hiring a brilliant surgeon and making them re-read Gray’s Anatomy before every operation.
Enter Live-Memory — an open-source plugin for Claude Code that acts as a persistent, always-fresh memory of your repository. It’s not another prompt hack. It’s a fundamental architectural shift: offload the boring context retrieval to a cheap, large-context-window model that passively learns your repo’s structure, conventions, and organization. Your premium agent becomes a thin reasoning layer that never touches raw files.
And the numbers? They’re absurd. In a controlled A/B test on a complex repo, Live-Memory offloaded ~93% of the premium model’s codebase-reading tokens. That slashed the premium model’s cost by 61% per task — and made it run 22% faster. Even after accounting for the memory model’s own compute, you’re looking at a 25% all-in cost reduction on Anthropic’s Haiku, and up to 57% if you use a cheaper model like DeepSeek-v4-flash.
The real unlock isn’t making your agent smarter — it’s giving it a photographic memory that costs pennies.
This mirrors how human experts work: they don’t re-read every file themselves. They have junior assistants pre-digest the context. Live-Memory is that junior assistant — always listening, always up-to-date, always ready with the relevant snapshot.
I know what you’re thinking: “But won’t the memory get stale?” Yes — and that’s the tension. Live-Memory balances freshness by only updating when the file system changes, not by re-reading the entire repo. It’s designed to be ‘always-fresh’ within a window of activity. The trade-off is negligible: you trade a tiny bit of staleness for massive savings.
And the best part? It’s zero-config if you have a Claude subscription (uses Haiku by default). Point it at DeepSeek, GPT-4o-mini, or any OpenAI-compatible local model. It runs as a long-lived HTTP server — start it once, and it shares memory across all your Claude Code sessions.
This isn’t a marginal improvement. It’s a fundamentally more efficient architecture for AI-assisted coding. Most developers are still optimizing the wrong layer — they fiddle with prompts and context windows when the real multiplier is offloading the entire context-gathering phase to a cheap coprocessor.
Stop treating your AI agent like an intern who has to read every file. Give it a memory, and watch both your speed and your budget transform.
The repo is at github.com/shofer-dev/claude-code-live-memory. Try it on a large repo. You’ll never go back.
FAQ
Q: Doesn't the memory model introduce its own cost that offsets the savings?
A: Yes, but the memory model is cheap (e.g., Haiku or DeepSeek). In tests, the all-in cost still dropped 25–57% depending on the model chosen. The memory model runs passively and shares context across sessions, so its cost is amortized over many tasks.
Q: How do I set this up in my existing workflow?
A: It's a local HTTP server you start once. Point it at any OpenAI-compatible model (default uses Haiku via Anthropic). Then connect it to Claude Code as an MCP server. The plugin automatically observes file changes and builds memory. No manual training or configuration files needed.
Q: Why not just use a bigger, smarter model with a larger context window instead of this memory trick?
A: Because even the largest models still re-read every token per session. A bigger model costs more per token and doesn't solve the redundancy problem. Live-Memory uses a cheap model to pre-digest context, then feeds only the relevant summary to your premium agent. It's not about model size — it's about architecture.