[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"$f1ellnupndipqi":3},{"code":4,"message":5,"data":6,"timestamp":26},10000,"success",{"full_name":7,"position":8,"description":9,"language":10,"stars":11,"forks":12,"stars_gained":13,"age_days":14,"hn_threads":15,"one_liner":16,"summary_md":17,"topic":18,"github_topics":21,"license":22,"homepage":23,"updated_at":24,"history":25},"akitaonrails\u002Fai-memory",19,"Solution for long term memory for agent coding CLIs and to facilitate handoff between different agent vendors","Rust",13219,929,4858,155,[],"Shared long-term memory for coding agents so you can switch harnesses or machines mid-task without re-explaining context.","## The problem\n\nCoding agents now ship their own memory, but it is trapped: one agent, one laptop, one person. Hand a half-finished task from Claude Code to Codex, or resume the same repo on another machine, and you re-explain the architecture, the dead ends, and the open questions. ai-memory puts capture, storage and retrieval behind a shared server so every harness in a project reads the same memory.\n\n## What's different\n\nThe usual approaches split into fact extractors (Mem0\u002FLangMem-style per-turn facts), temporal knowledge graphs (Zep, Graphiti), and file-first markdown tools (basic-memory). ai-memory picks the file-first side and pushes it further: the source of truth is a git-backed wiki of plain `.md` pages, with a derived index that can be rebuilt, so nothing is locked into a binary store or vector DB. On top of that it adds capture from lifecycle hooks across a long list of supported harnesses, plus typed, claim-once handoffs between agents. Memory aging — decay, dedup, contradiction flagging — runs with zero LLM calls and is reversible via git version history; the LLM-backed consolidation is opt-in and off by default. Whether that is genuinely better than a per-turn fact store depends on whether you value editable pages over atomic rows.\n\n## Who it's for\n\nDevelopers who regularly switch between coding agents or machines on the same repositories, and small teams that want one shared project memory with per-person attribution. It fits people willing to run a server, on a laptop or homelab. It is a poor fit if you only ever use one agent on one machine and its built-in memory is enough, or if you want a fully hosted zero-ops service — this is self-run infrastructure. Anyone expecting a polished, long-battle-tested product should also wait.\n\n## Cost of adoption\n\nYou need Rust 1.95+ to build, a server process to run, and per-harness hook\u002FMCP registration (the support matrix is long but uneven: some agents are hooks-only or MCP-only, and native Windows is experimental — WSL2 is the supported path). The zero-LLM default keeps it cheap, but the README is thin on operational details: no benchmark numbers beyond an asserted write ceiling, and the aging\u002Fdreaming features require tuning to be useful. MIT licensed, single binary, no paid tier, which lowers lock-in risk. Maturity is the real cost: the project is recent and the docs are the main source of truth.\n\n## Verdict\n\nA genuinely differentiated idea — agent-agnostic, file-first, LLM-optional memory — aimed at a real pain point that agent vendors will keep half-solving in incompatible ways. The momentum is real but young: 13.2k stars in about five months, with +3,449 in a single week, and no trending-board or Hacker News footprint to corroborate the spike. That pattern suggests organic interest plus a burst, not yet evidence of a stable user base. Worth trialling if you already switch harnesses and can tolerate a self-hosted server and early-stage docs; otherwise bookmark it and revisit once the operational story settles.",{"slug":19,"name":20},"developer-tools","Developer Tools",[],"MIT",null,"2026-10-24T16:06:02Z",[],1792868639]