Love seeing projects like this. The performance benchmarks are nice to see. Have you done any benchmarks against approaches like OpenAI's Symphony for things like token usage or task completion?
I want this, but also for cross-project memory. Save me from building my own, which I have planned but figure something would eventually pop up in HN...
How well does the model adhere to using this in a harness like Codex where it may be directed to use the built in memory tooling? Maybe I'll need to try an experiment directing it to save to its native memory to use OKF instead
We built OKF Agent Memory because we were frustrated with how AI coding agents (Claude Code, Cursor, Windsurf, local models) handle long-term project context.
Every time a context window closes or a session resets, the agent forgets architectural decisions, domain discoveries, and operational rules. The existing solutions fall into two extremes:
1. Ad-hoc flat files (CLAUDE.md, AGENTS.md, .cursorrules) that inevitably balloon into 20k-token monoliths, degrade agent focus, and cause "lost-in-the-middle" attention failure.
2. Vector databases / background daemons (Mem0, Letta, Zep) that introduce heavy runtimes (Python/Node), docker containers, proprietary storage silos, and recurring embedding API costs (adding 200–800ms per retrieval call).
Our approach: The "LLM Wiki" in pure Go.
OKF Agent Memory (v0.1.0) is a single, zero-dependency Go binary that turns your Git repository into a structured, self-validating knowledge corpus based on Google's Open Knowledge Format (OKF) v0.2 specification:
• In-Memory BM25 Search (<300µs): Fast lexical ranking across titles, YAML metadata, tags, and bodies directly in memory. No embedding APIs, zero network overhead, zero runtime cost.
• Progressive Disclosure: Slashes prompt overhead by up to 90%. Instead of loading thousands of lines of context, the agent searches the bundle index and pulls only the exact 300-token concept required for the current task.
• 100% Git-Native: Everything lives in `knowledge/` as human-readable Markdown. You audit your agent's memory via `git diff`, `git blame`, and code reviews.
• Built-In Stdio MCP Server: `okf mcp knowledge` exposes native Model Context Protocol tools (`okf_search`, `okf_show`, `okf_create`, `okf_validate`) directly to Claude Code and Cursor.
• Trust Tiers: Distinguishes authoritative human law (`verified: human:...`) from agent-generated drafts (`generated: agent:...`).
• Sub-4ms Cold Starts (<15MB RSS): Starts in milliseconds with no VM spin-up.
Try it in 30 seconds:
$ brew install okf-memory/tap/okf
$ cd your-project && okf bootstrap .
Love seeing projects like this. The performance benchmarks are nice to see. Have you done any benchmarks against approaches like OpenAI's Symphony for things like token usage or task completion?
I want this, but also for cross-project memory. Save me from building my own, which I have planned but figure something would eventually pop up in HN...
https://github.com/huggingface/funes
Maybe?
cool going to check it out, I've got an opensource project that might compliment it that I'm excited to try
https://github.com/ucsandman/declick
How are you using this compared to more explicit approaches where you lay out the project documentation in certain formats and conventions?
How well does the model adhere to using this in a harness like Codex where it may be directed to use the built in memory tooling? Maybe I'll need to try an experiment directing it to save to its native memory to use OKF instead
Hey HN,
We built OKF Agent Memory because we were frustrated with how AI coding agents (Claude Code, Cursor, Windsurf, local models) handle long-term project context.
Every time a context window closes or a session resets, the agent forgets architectural decisions, domain discoveries, and operational rules. The existing solutions fall into two extremes: 1. Ad-hoc flat files (CLAUDE.md, AGENTS.md, .cursorrules) that inevitably balloon into 20k-token monoliths, degrade agent focus, and cause "lost-in-the-middle" attention failure. 2. Vector databases / background daemons (Mem0, Letta, Zep) that introduce heavy runtimes (Python/Node), docker containers, proprietary storage silos, and recurring embedding API costs (adding 200–800ms per retrieval call).
Our approach: The "LLM Wiki" in pure Go.
OKF Agent Memory (v0.1.0) is a single, zero-dependency Go binary that turns your Git repository into a structured, self-validating knowledge corpus based on Google's Open Knowledge Format (OKF) v0.2 specification:
• In-Memory BM25 Search (<300µs): Fast lexical ranking across titles, YAML metadata, tags, and bodies directly in memory. No embedding APIs, zero network overhead, zero runtime cost. • Progressive Disclosure: Slashes prompt overhead by up to 90%. Instead of loading thousands of lines of context, the agent searches the bundle index and pulls only the exact 300-token concept required for the current task. • 100% Git-Native: Everything lives in `knowledge/` as human-readable Markdown. You audit your agent's memory via `git diff`, `git blame`, and code reviews. • Built-In Stdio MCP Server: `okf mcp knowledge` exposes native Model Context Protocol tools (`okf_search`, `okf_show`, `okf_create`, `okf_validate`) directly to Claude Code and Cursor. • Trust Tiers: Distinguishes authoritative human law (`verified: human:...`) from agent-generated drafts (`generated: agent:...`). • Sub-4ms Cold Starts (<15MB RSS): Starts in milliseconds with no VM spin-up.
Try it in 30 seconds: $ brew install okf-memory/tap/okf $ cd your-project && okf bootstrap .
GitHub: https://github.com/okf-memory/okf-agent-memory Docs & Landing Page: https://okf-memory.dev
We'd love your feedback on the architecture, the Go implementation, and how your coding agents behave with progressive disclosure memory!