Title: Why I gave my coding agent a memory (and how Cortex works)

A developer created Cortex, a local memory system for coding agents that stores and retrieves context using SQLite, deduplication, and a ranking engine. The tool addresses token waste and context loss by keeping all data on the machine, with features like a dashboard and optional autopilot mode. The project is open-source and seeking feedback on its memory ranking component.

The problem, concretely. A real session where the agent re-derived or re-broke something it had already handled. Name the cost: wasted tokens, wasted time, lost context. Why existing options didn't fit. Cloud memory = your code leaves the machine. Bigger context windows = you still pay to re-read everything and still lose it at session end. The design. Walk the flow: capture policy dedup + normalize, drop the "done " noise → typed provenance links → full-text index → ranking engine that packs recall to a token budget. One SQLite file, one local process. Drop in the architecture mermaid diagram from the README. The parts people can see. Dashboard blocked work first, explained search scores, graph view . Then Autopilot as the "if you want it" layer — git worktrees, model routing, the hard off-limits guard as the safety story. What's next / call for feedback. Be honest that it's early. Link the repo, invite issues, say which part you most want eyes on the memory ranking . git https://github.com/gsl0001/Cortex.git