OKF Agent Memory gives coding agents a searchable memory with no embedding API

OKF Agent Memory was published on GitHub on 5 September and reached the Hacker News front page the same day with 53 points and 17 comments. It stores what a coding agent has learned about a project as ordinary Markdown files inside the repository, and searches them with BM25 rather than with embeddings. The GitHub API showed 124 stars, 7 forks and an MIT licence when checked on 6 September 2026, against a repository created at 21:26 UTC the previous evening. The okf-memory organisation was created on 28 August and has three public repositories.

Files in git instead of a vector database

The memory lives in a knowledge/ directory as Markdown with YAML frontmatter, following the Open Knowledge Format v0.2 specification. That means the history of what an agent believes about a codebase shows up in git diff and git log like any other change, and a reviewer can argue with an entry in a pull request. The frontmatter carries provenance in a sources field, a status and a stale_after date, and a trust tier that separates what a person verified from what an agent drafted.

The project is written in Go with no external dependencies and builds to a single binary. It runs either as a command-line tool or as an embedded Model Context Protocol server over stdio, and the README lists Claude Code, Cursor and Codex among the clients that can reach it that way.

The numbers the project publishes

The README states search latency under 300 microseconds using in-memory BM25, full corpus validation of more than 50 concepts in about 4.0 milliseconds, a memory footprint under 15 MB, and a cost of $0.00 per 1,000 queries because nothing leaves the machine. Startup is given as under 5 milliseconds. These are the project's own figures and nobody independent has measured them.

The author's Hacker News comment frames the design against two things they found unsatisfying: a single large Markdown file that grows until it crowds out the rest of the prompt, and a hosted vector database that adds cost and latency. Their claim for the middle path is that retrieving only the entries a task needs cuts prompt overhead by up to 90 percent. The repository description puts the same idea at 80 percent, so the two numbers the project publishes about itself do not agree, and neither has a published method behind it.

Where this differs from the agent-memory projects of the past week is the retrieval mechanism. BM25 is a keyword ranking function from classical search, so it needs no model, no API key and no index rebuild against a provider. It also cannot match a question to an entry that uses different words, which embeddings can. That trade is the whole design, and whether it holds depends on how consistent the vocabulary in a given repository is.

For a team, the part worth testing is the review path rather than the speed. Agent memory that sits in a hosted service is invisible to code review, so a wrong belief about a system persists until someone notices the agent acting on it. Memory kept as files in the repository fails differently: a bad entry arrives as a diff someone can reject, and a stale one carries a date that says so. The cost is that the knowledge directory becomes a thing the team has to maintain, which is real work that no benchmark measures.

Source

okf-memory/okf-agent-memory on GitHub, and the Hacker News discussion.