Cloud memory tiers have a fundamental problem: your agent context - the most sensitive data you have - leaves your machine. I wanted memory that never does.
So Awareness runs a local-first daemon:
npx @awareness.market/local start
No account. No API key. No cloud. SQLite + ONNX embeddings on your machine, served to Claude Code, Cursor, or any MCP client on localhost.
What the daemon gives you
| Storage | SQLite, human-readable, yours forever |
| Embeddings | all-MiniLM-L6-v2 as ONNX (23MB) - zero API calls |
| Retrieval | hybrid BM25 + vector RRF - 1.7s per query on an M1 8GB |
| Memory types | knowledge cards, bi-temporal facts, conflict detection |
| Upgrade path | optional cloud sync to pgvector when you want team sharing |
Why local matters more than you think
Three things a cloud memory tier can never give you:
- No vendor risk. The provider cannot deprecate your workflow, raise your price, or read your context.
- No token billing surprises. Retrieval is deterministic compute - the same query costs the same every time, forever.
- Cross-tool continuity. One local daemon serves Claude Code, Cursor, Windsurf and anything that speaks MCP - the memory is shared, not siloed per vendor.
The honest numbers
95.6% recall@5 on LongMemEval_S, on an M1 with 8GB RAM and zero LLM calls at retrieval. Two competitors edge us by ~1 point on recall, running hosted stacks. Full methodology with the tables we do not win:
https://awareness.market/benchmarks
When cloud is still right
Local-first does not mean local-only. Burst inference, team-shared memories, and cross-device sync are real needs - the daemon upgrades to cloud (pgvector) with one command when you need it. The point is that local is the default, not the fallback.
Repo and SDK: https://github.com/everest-an/Awareness
What would make you switch your agent memory to local-first?
This article was originally published by DEV Community and written by Everest An.
Read original article on DEV Community