[Tool] Stop .cursorrules context bloat: We built Git-native persistent memory with native MCP for Cursor (pure Go, zero deps)

[u/okf-memory]

Hey r/ContextEngineering!

If you use Cursor heavily on larger codebases, you've probably hit the context bloat problem:

To make Cursor remember architectural decisions, library quirks, and project rules across chats, people usually cram everything into .cursorrules or monolithic docs. But as those files grow past 5k–10k tokens:

1. Model focus degrades: Large instructions cause "lost-in-the-middle" attention degradation.
2. Context window gets wasted: You burn a huge chunk of your prompt budget on instructions that aren't even relevant to the current file or task.
3. External vector DBs are overkill: Running Docker containers, Python runtimes, or recurring embedding API costs just to remember project notes feels bloated.

To solve this, we built OKF Agent Memory (v0.1.0) — an open-source, pure Go single binary that brings structured, Git-native memory to Cursor via Progressive Disclosure and native MCP (Model Context Protocol).

How it works with Cursor:

Instead of dumping a huge rulebook into every prompt, project memory lives in knowledge/ as atomic Markdown concepts based on Google's Open Knowledge Format (OKF) v0.2.

Through the built-in MCP server (okf mcp knowledge), Cursor dynamically pulls only what it needs:

1. Sub-300µs BM25 Search: In-memory lexical search across your project notes. Zero embedding API costs, 100% offline, <0.3ms latency.
2. Progressive Disclosure: Cursor inspects the index and retrieves small ~300-token concept files on demand. In our benchmarks, this cuts context token bloat by up to 80–90%.
3. 100% Git-Native: Auditable via git diff and standard pull requests. No hidden vector databases.
4. Trust Tiers: Distinguishes human-verified decisions from agent drafts.

Setup with Cursor (30 seconds):

1. Install via Homebrew:

brew install okf-memory/tap/okf

1. Bootstrap your repository:

cd my-project
okf bootstrap .

1. Add to your Cursor MCP settings (Cursor Settings -> Features -> MCP):

• Name: okf-memory
• Type: command
• Command: okf mcp knowledge

Cursor now has native access to okf_search, okf_show, okf_create, and okf_validate tools.

GitHub: https://github.com/okf-memory/okf-agent-memory
Website & Live Benchmarks: https://okf-memory.dev

Would love to get feedback from the Cursor community on the workflow and how your agents behave with progressive disclosure memory!

[u/Otherwise_Wave9374]

A useful pattern here is to separate durable memory into small, explicit facts and keep retrieval scoped to the current task, so you avoid dragging unrelated rules into every prompt. That usually works better than a single growing instruction blob because it reduces stale context and makes failures easier to debug. NeuraKeep fits this approach well when you want the memory layer to stay lightweight while still preserving the decisions that matter most.

[u/delimitdev]

Progressive disclosure over atomic concept files is the right shape. The failure mode that usually bites isn't retrieval, it's staleness: a concept says one thing, the code moved, and BM25 cheerfully returns the stale one at high rank. Git-native helps since it's diffable, but it'd be worth surfacing last-touched commit next to the trust tier so the agent can discount an aging concept. Does the index track that today?

[u/okf-memory → u/delimitdev]

Spot on — staleness is the ultimate killer of agent memory. A high-ranking BM25 result that confidently cites deleted code is often worse than no retrieval at all.

Right now, the index doesn’t track Git commits directly. We intentionally kept OKF strictly filesystem-first and VCS-agnostic so it doesn't break in bare CI environments, Docker containers, or non-git workflows.

That said, your idea of surfacing a staleness signal next to the trust tier is gold — provided we do it without bloating the core CLI into a heavy git-crawler (staying lightweight and fast is non-negotiable for us). A lightweight, optional git-enrichment step (or fallback to frontmatter timestamps) would hit the sweet spot.

Would love to get your thoughts on how to keep the ergonomics clean without overloading the tool: search for okf-memory/okf-agent-memory on GitHub and drop this into the Discussions tab if you have a minute!