Launching today

projectmem

Launching today

Memory + judgment for AI coding agents (local, MIT)

5 followers

Memory + judgment for AI coding agents (local, MIT)

5 followers

Visit website

Lightweight memory + judgment layer for AI coding agents. No daemon, no ports — just stdio MCP + plain-text JSONL in your repo. Captures bugs, failed attempts, and fixes inside your project, then warns at git commit before you repeat a known dead-end. 14 tools, ~600 LOC, open source, MIT, 100% local — your AI finally remembers what it tried last week.

Free

Launch tags:Open Source•Developer Tools•Artificial Intelligence

Launch Team / Built With

Fulcrum Agent Rentals — Your own AI agent — 7 days free, then from $25/mo

Your own AI agent — 7 days free, then from $25/mo

Promoted

Maker

📌

Hi PH 👋 A few weeks ago I watched my AI coding agent confidently suggest the same broken CSS fix I'd rejected the previous Friday. Same contain: layout solution. No memory I'd already tried it. Every new chat was Groundhog Day. I'd been hacking on a fix for months — that incident pushed me to finally ship. projectmem is a local-first memory + judgment layer for AI coding agents. It captures development events — bugs, failed attempts, fixes, decisions, gotchas — into plain-text files inside your repo. Your AI agent (Claude / Cursor / Antigravity / Codex) reads it through 14 MCP tools. Same agent, same model — but now it actually remembers what worked, what didn't, and why. Five killer features, all wired by one pjm init: 1. Pre-commit warning — the git hook checks your staged file against memory and warns BEFORE the commit if there's a logged failed approach on that file. The killer feature. Memory + judgment at the moment of action. 2. Cross-project memory — lessons learned in one repo automatically surface in other repos with the same stack (~/.projectmem/global/). A React gotcha you fix in proj-a appears in proj-b. Stack-aware filtering, so a vite project's "next" mention doesn't pollute Next.js gotchas in your actual Next.js repos. 100% local, no cloud sync. 3. Provable ROI (pjm score) — an A+ → F grade backed by concrete numbers: debugging hours saved, tokens prevented, dollars protected. Output as terminal, JSON for CI, or a shields.io badge for your README. The first AI memory tool with metrics a CTO can actually verify. 4. Smart context injection (pjm wrap) — launches your agent with a token-budgeted context block already loaded. Your AI starts experienced, not blank. Works with Claude Code, Cursor, Aider, and clipboard-paste for the rest. 5. Real-time file watcher (pjm watch) — auto-starts on pjm init in interactive terminals. Catches rapid edits to the same file (debugging sessions). Battery-aware, gitignore-aware, opt-out with --no-watch. Plus an interactive D3 dashboard (pjm visualize) with four views, all auto-generated from your memory — zero extra AI tokens: • Story Map — every decision, milestone, and failure as an interactive graph. Failed files glow red in the heatmap. • ROI Dashboard — animated counters for tokens prevented and USD protected, capture-source donut, cumulative savings chart. • Architecture Map — toggle between a horizontal dendrogram (hierarchical) and a force-directed graph (relationships, churn). • Event Timeline — chronological events with AUTO / Manual badges and a project-activity bar chart. The framing I keep landing on: most "AI memory" tools are retrieval engines — they store conversations and surface them when asked. projectmem is a judgment layer — it captures events with explicit outcomes (worked / failed / partial) and uses git context to interrupt you before you waste another afternoon. What it isn't: → Not a chat memory — captures development events, not conversations → Not a retrieval engine — search is exact substring; semantic search is opt-in for v0.2 → Not a daemon — stdio MCP, no port, no process to babysit → Not networked — no cloud, no telemetry, no accounts 100% local. MIT. ~600 LOC Python. 58 unit tests. End-to-end verified across Claude Desktop, Claude Code, Cursor, Antigravity, Codex. Install: pip install projectmem Try it on a real project — the pre-commit hook usually catches its first real failure within the first week. If it doesn't, you've lost 60 seconds of pjm init. If it does, you've recovered an afternoon. Honest about rough edges — search is substring not semantic, API may shift before 1.0, the precheck heuristics are simple right now. v0.2 roadmap: stale-memory detection (flag, never delete), explicit --supersedes on add_decision, semantic search as opt-in. Genuinely curious what would make this useful for your stack. What's the worst "I already told you this last week" moment you've had with your AI agent? That's exactly the pattern I optimized this for. Thanks for taking a look 🙏 — Ripon

Report

11h ago

Memory for coding agents makes sense, but the interesting engineering challenge is relevance filtering .A codebase with months of history has way more context than any session can use. The 'judgment' part of the name suggests projectmem has an opinion on what to surface and what to leave out. Would love to understand the mechanism behind that, is it semantic similarity, recency, or something more task-aware?

Report

3h ago

Maker

@ayushi18 Thanks Ayushi! really good a question, and you put your finger on exactly the part I think about most.

Honest answer for v0.1.3: the "judgment" today is structural, not semantic. There are no embeddings yet. The filtering happens on three axes:

1. Structure. Events aren't a flat chat log ; they're typed: issue, attempt(worked|failed|partial), fix, decision, note, gotcha. So when an agent calls get_context, it's not getting raw history; it's getting open issues + recent decisions + the latest fix per issue. Closed-and-fixed stuff drops out by default.

2. File-path keying. This is where the pre-commit warning gets its bite. When you git commit styles.css, the hook runs precheck_file styles.css , it surfaces only failed attempts and gotchas tied to that path. So "months of history" never floods in; you get the slice that's literally about the code you're touching right now. Task-aware in the narrow sense.

3. Recency + caps. get_context defaults to the last N events with a hard cap (configurable). search_events is keyword + type filter, not vector search.

So today: opinionated because of the schema, not because of an ML ranker.

Semantic similarity is the obvious next layer, it's on the v0.3 roadmap (local embeddings, no cloud). The harder question I keep circling is task-aware ranking, knowing the agent is debugging a layout bug vs. refactoring auth, and weighting differently. That probably needs the agent itself to pass a query intent, not just a keyword. Still figuring it out.

Appreciate the sharp question, exactly the kind of feedback I was hoping launch day would surface.

Report

2h ago