DEV Community: Ripon C Malo

We Built a Free, Open Source Alternative to Topaz for Image and Video Upscaling

Ripon C Malo — Tue, 25 Aug 2026 20:41:33 +0000

Most of my AI-generated videos come out at 720p. The tools that upscale them well are either subscription software at around $199 per year, or open source models that need a command line, separate weight downloads, and a lot of patience.

So we built NextGenUp: a free, open source AI upscaler for both images and video, with a point-and-click interface. Everything runs locally. Nothing you upscale ever leaves your machine.

What it does

Images up to 8K with four modes: Quick (browser AI), Quality (FFmpeg Lanczos plus CAS sharpening), Enhance (same resolution, AI cleanup), and Ultra (server-side AI that works from any device)
Video up to 4K, with audio preserved and portrait or landscape handled automatically
Face restoration with GFPGAN: detected faces are aligned, restored, and blended back seamlessly
Batch processing with a zip download, a before/after slider on every result, and cancellable jobs
Desktop apps for macOS, Windows, and Linux, with FFmpeg and the models bundled, so there is no setup

It is MIT licensed. There is no account, no watermark, and no telemetry.

How it works

The architecture is a local Flask server plus a web UI, wrapped in Tauri for the desktop:

Super-resolution uses Real-ESRGAN (the compact realesr-general-x4v3 model, about 5 MB as ONNX). In the browser it runs through ONNX Runtime Web on WebGPU, with a WASM fallback. On the server it runs through ONNX Runtime on CPU.
Tiling keeps memory bounded: images are processed in overlapping tiles (64 to 128 px with padding), then stitched. This is why a 6000 px photo works on modest hardware.
Face restoration chains YuNet detection, a similarity transform to the FFHQ template, GFPGAN v1.4 inference at 512x512, and a feathered paste-back.
The desktop app is a thin Rust shell that spawns the Python server as a PyInstaller sidecar and points a webview at it. Auto-updates are handled by the Tauri updater with signed releases on GitHub.

Three bugs worth sharing

The 95 percent hang. Video encoding kept freezing near the end. Cause: I piped both stdout and stderr from FFmpeg but only read stdout. FFmpeg filled the 64 KB stderr pipe buffer, blocked on writing, and we deadlocked. Fix: drain stderr in a background thread. If you spawn FFmpeg from any language, you have probably hit this.

The orphaned server. Quitting the desktop app left the backend running. PyInstaller one-file binaries run as a bootloader that spawns the real process as a child, so killing the direct child orphans the grandchild. Fix: put the sidecar in its own process group on Unix and kill the group; use taskkill /T on Windows.

The relocated FFmpeg. I bundled the ffmpeg binary from my own machine and every server feature silently broke in the packaged app. It was a dynamically linked build that only works from its original install directory. Always bundle static builds.

Honest limitations

The compact Real-ESRGAN model does not beat Topaz on extreme fine detail like hair at 4x. Pro video mode is slow without WebGPU. The macOS builds are not notarized yet, so the first launch needs right-click and Open. A max-quality tier with larger models (Real-ESRGAN x4plus or HAT) is on the roadmap.

Try it

Installers for macOS, Windows, and Linux are on the releases page, or run it from source with Python and FFmpeg. If it is useful to you, a star on GitHub helps other people find it.

I would love feedback, especially from anyone who has compared upscaling models in practice.

NextGenUp is a matily.org product, MIT licensed.

How to Free Up Disk Space as a Developer: Clear Hugging Face, npm, conda, and Docker Caches

Ripon C Malo — Sun, 26 Jul 2026 19:00:41 +0000

If you write code — and especially if you work with machine learning — your disk
is quietly filling up with data you downloaded once and forgot about. A model
you tried for an afternoon. Package caches from five virtualenvs. Docker images
from a project you finished months ago. This guide covers where that space
goes, how to reclaim it manually, and how to do it all from one place.

Where a developer's disk space actually goes

The biggest offenders almost never show up in Finder or Explorer, because
they're hidden in cache directories:

Machine learning model caches

These are the heavyweights. A single large language model can be several
gigabytes, and most people accumulate dozens.

Hugging Face — ~/.cache/huggingface
Ollama — ~/.ollama/models
PyTorch hub — ~/.cache/torch
Whisper — ~/.cache/whisper

To clear the Hugging Face cache manually:

rm -rf ~/.cache/huggingface/hub

The catch: this deletes every model, including the ones you actually use.
They'll re-download on demand, but that's a lot of bandwidth if you only wanted
to remove one abandoned model.

Package manager caches

Every language ecosystem keeps a cache to speed up reinstalls. They regenerate
automatically, so they're safe to clear:

npm cache clean --force            # ~/.npm/_cacache
pip cache purge                    # pip download cache
conda clean --all                  # conda packages and tarballs
cargo cache --autoclean            # Rust crate registry (needs cargo-cache)
go clean -cache                    # Go build cache
docker system prune -a             # dangling images, containers, build cache

Build artifacts and IDE caches

Xcode DerivedData — ~/Library/Developer/Xcode/DerivedData (can hit tens of GB)
Gradle — ~/.gradle/caches
JetBrains IDEs — ~/Library/Caches/JetBrains
node_modules in dead projects — often gigabytes each

The stuff manual commands miss

Two categories that no clean command touches:

Duplicated Python packages. Install torch in eight virtualenvs and you have eight copies — often 2–3 GB each.
App leftovers. Uninstalling an app on macOS usually leaves its Application Support, Caches, and Preferences behind forever.

The problem with cleaning it manually

Running these commands works, but it has real downsides:

You have to remember every location across every tool you use.
rm -rf on a cache is all or nothing — you can't keep the models you use.
You can't easily see what's actually taking up space before deleting.
It's different on Windows, where the paths change (%LOCALAPPDATA%\pip\Cache, the registry-based uninstaller, etc.).

Doing it all from one place: Jharu

Jharu is a free, open-source disk cleaner built
specifically for this problem. It runs on macOS and Windows and understands the
developer and AI locations above — but instead of blunt deletion, it tells you
what each thing is and whether you've used it.

Per-model ML cleanup. Jharu lists every Hugging Face, Ollama, PyTorch, and
Whisper model individually, with its size and — crucially — whether you've
actually loaded it since downloading. So you can reclaim the 6 GB model you
tried once without touching the ones you use daily. Shared Ollama layers are
preserved, so removing one model never breaks another.

Deep cache scan. It scans 25+ known locations (npm, pip, uv, yarn, pnpm,
conda, Cargo, Go, Gradle, Maven, NuGet, Docker, Xcode, JetBrains, Playwright,
and more), each rated safe to clear, re-downloadable, or review first.

Python environment analyzer. It finds every virtualenv and conda
environment and quantifies duplication across them — the "torch is installed
eleven times" problem, in one view.

A treemap of your whole disk. See every folder sized by what it holds, so
the biggest space-eater is literally the biggest block. Click to drill in.

Clean uninstaller. Removes an app and the leftovers it scattered across
your system.

Safe by design

Nothing is ever permanently deleted — everything goes to the Trash or Recycle Bin, and a dialog tells you the real consequence first.
No telemetry, no tracking, no subscription.
No registry "cleaner" (it doesn't work), and if Jharu can't read a folder it says so instead of silently hiding it.

Get it

Jharu is free and open source under Apache 2.0.

Download: jharu.matily.org (macOS Apple Silicon + Intel, and Windows 64-bit)
Source: github.com/riponcm/Jharu

Run one scan and you'll usually find tens of gigabytes you didn't know were
there. If you reclaim some space, drop a comment with how much.

OSSDrop — a curated, community-ranked directory of open-source tools

Ripon C Malo — Mon, 20 Jul 2026 03:16:53 +0000

Finding a good open-source tool is mostly luck. You catch it in a buried Hacker News thread, or a coworker mentions it, or you trip over a repo with 300 stars that does exactly what you needed six months ago. Meanwhile thousands of genuinely useful projects sit unseen because discovery is noisy and nobody's curating it.

We built OSSDrop to make that less random.

What OSSDrop is

OSSDrop is a curated, community-ranked directory of open-source tools, live at ossdrop.com. Every listing points to a real repository with a verified license and star count — no dead links, no vaporware. You can browse by category, upvote the tools you actually use, and submit your own project in a single step.

It runs across three places:

ossdrop.com — the ranked directory, plus a forum for the people building and using these tools.
OSSDrop/OSSDrop on GitHub — an open list you can add your tool to with a pull request.
r/OSSDrop — the subreddit for discussion and finds.

The list and the site share the same data, so anything on the GitHub list flows into the directory.

How the ranking works — and what doesn't buy you rank

This is the part we care most about getting right, so we made it public. There's a full How OSSDrop works page that spells out the ranking, but the short version:

Tools rank on community votes and recency. People upvote what they use; fresh, well-received tools rise. It's the same intuition as a link aggregator, applied to a directory.
Karma is earned, not handed out. You build it by posting and voting like a normal member. Admins can't gift it, and there's no way to buy it.
Boosts and promotion don't move ranking scores. If we ever offer paid visibility, it's clearly labeled placement — it will never quietly reorder the rankings. The vote-based order stays honest.

We wrote it down partly so you can hold us to it.

What you'll actually find on it

A good chunk of the early catalog is the kind of tool developers pass around by word of mouth. If you live in a terminal, a few that are already listed:

lazygit — a terminal UI for git that makes staging, branching, and rebasing genuinely fast.
ripgrep — recursive search that's absurdly quick and respects your .gitignore by default.
fzf — a fuzzy finder that plugs into your shell, history, and just about everything else.
bat — cat with syntax highlighting, line numbers, and git integration.
httpie — a human-friendly HTTP client for testing APIs without wrestling curl flags.

Beyond the terminal, the catalog spans everything from projects out of large labs to tools maintained by one person on weekends. Notable and verified projects carry a Curated badge so it's clear what's been checked.

Adding your tool takes about a minute

If you maintain something open source, submitting is one step: paste the repository URL and OSSDrop auto-fetches the name, description, license, and stars from the forge so you're not filling out a long form. If your tool is already on the list, you can claim it — that request goes to a human, and once it's verified you own the listing and can keep it up to date.

That's the whole point of the "drop" in the name: drop your open-source tool and let people find it.

Why it's built this way

OSSDrop is made by Matily, a nonprofit open-source studio. That shapes the rules: it's free, it's privacy-respecting, and it's neutral. We list other people's tools — including things that compete with each other, and things that compete with us — fairly. A directory is only worth anything if it isn't gatekept, and if you can trust that what's near the top got there honestly.

No fake metrics, no dark patterns, no "best tool ever." Just an accurate, community-ranked home for open-source work.

FAQ

Is OSSDrop free?
Yes. Browsing, voting, submitting, and claiming a tool are all free.

How is it different from Awesome lists or a GitHub topic?
Awesome lists are static and unranked, and topics are just tag pages. OSSDrop is ranked by the people using the tools, kept current, and it's a place to discuss them — not only a list.

Do I have to use GitHub?
You can sign in with GitHub or Google, and the GitHub list accepts pull requests. Support for tools hosted on other forges is on the roadmap.

Can I list a tool I didn't build?
Yes — the directory is meant to be generous. If you're the maintainer and want to manage the listing, use the claim flow to take ownership after a quick verification.

Have a tool you rely on that more people should know about? Add it, or upvote the ones already there: ossdrop.com.

Open-source Grammarly alternatives in 2026 — and why I built another one

Ripon C Malo — Tue, 14 Jul 2026 16:44:22 +0000

If you search "Grammarly alternative," you get listicles full of freemium tools that are just smaller subscriptions. What I actually wanted was simpler: grammar checking in every text field of my browser, without a subscription and without my text being routed through a company's servers.

I went through the open-source options first. Here's the honest rundown — and then the tool I ended up building, which is also free and open source.

The open-source landscape, honestly

LanguageTool — the most mature open-source grammar checker (the core is open source and self-hostable via Docker). Rule-based, supports 40+ languages, solid browser extension. The catch: the hosted extension most people install is freemium with premium rules paywalled, and rule-based checking misses things an LLM catches easily — run-on sentences, agreement across clauses, awkward phrasing. Self-hosting fixes the privacy question but means running a Java server.

Harper — a modern grammar engine in Rust, compiled to WASM, running fully locally. Genuinely private (nothing leaves your machine) and fast. The trade-off is the flip side of being local and rule-based: English-focused, and it won't judge whether your whole sentence makes sense the way an LLM does.

Vale — not really a Grammarly alternative; it's a style linter for docs-as-code (enforcing style guides in CI). Great at what it does, different problem.

So the field splits into two camps: rule-based and private (Harper, self-hosted LanguageTool) or LLM-smart but subscription-and-server-based (Grammarly, QuillBot). I wanted the third quadrant: LLM-smart and private and free.

The trick that makes the third quadrant possible

The insight behind GemType is almost embarrassingly simple: Google's Gemini API has a genuinely usable free tier, and modern flash-tier models are more than good enough for grammar work. So instead of running a paid middleman server between the user and the model, the extension talks directly from the browser to Google's API using the user's own free key.

That single architectural decision cascades into everything people actually want:

Free — the user's free-tier key covers daily writing comfortably
Private — there is no vendor server; I never see anyone's text or key
Auditable — no backend means the entire data path is in the extension source
Any language — the model checks whatever language you write in, auto-detected

The parts that were actually hard to build

The LLM plumbing is the easy 10%. The hard 90% is the same thing that makes Grammarly's engineering interesting:

1. Underlines without touching the page's DOM. If you wrap flagged words in <span>s inside a React/ProseMirror editor, you corrupt its internal state (Grammarly abandoned exactly this approach years ago). GemType draws wavy underlines on a transparent overlay in a shadow root, positioned via Range.getClientRects() for rich editors and a hidden mirror element for plain <textarea>s.

2. Snippets, not offsets. LLMs are unreliable at reporting character offsets. Instead, Gemini returns structured JSON (responseSchema) with the exact erroneous snippet and its correction; the client locates snippets with substring search and re-anchors them live as you type.

3. Undo-safe fixes. Corrections are applied with document.execCommand('insertText'), which preserves the native undo stack and fires real input events — so frameworks treat the fix as a user edit.

4. Sentence re-checks. After every accepted fix, the surrounding sentence is automatically re-checked (scoped to that sentence, not the document — token-frugal). Word-level fixes stop leaving broken sentences behind.

5. The bug I'll remember: on Reddit everything worked — invisibly. Reddit ships CSS that hides unknown custom elements (visibility:hidden), which nuked my overlay host. Fix: every host style set inline with !important.

It's all vanilla JavaScript, Manifest V3, no build step. If you're building an extension that has to coexist with hostile editors, the source may save you some scars: github.com/riponcm/GemType.

Where each tool actually fits

Tool	Engine	Privacy	Languages	Cost
LanguageTool (self-hosted)	Rules	Local	40+	Free + your server
Harper	Rules (Rust/WASM)	Fully local	English-focused	Free
Vale	Style rules	Local/CI	n/a (style)	Free
Grammarly / QuillBot	LLM + rules	Vendor servers	English + few	Freemium → $12–30/mo
GemType	LLM (Gemini)	Direct to Google with your key; no vendor server	Any, auto-detected	Free (your free-tier key)

Honest trade-offs of GemType: you spend two clicks getting a free API key from Google AI Studio (no card), you need an internet connection, and Google Docs isn't supported (it renders to canvas and gates its annotation API to whitelisted vendors — the one place only Grammarly-tier companies can go).

Try it

Website / live demo: gemtype.matily.org
Chrome: Chrome Web Store
Edge: Edge Add-ons
Firefox: Firefox Add-ons
Source (Apache-2.0): github.com/riponcm/GemType
2-minute tutorial:

One more thing that only an open-source tool can offer: don't trust my privacy claims — paste the repo into ChatGPT/Claude/Gemini and ask it to audit where your text and key are sent. The answer should be "generativelanguage.googleapis.com and nowhere else."

It's a solo project under my studio, Matily. Issues and PRs welcome — editor-compatibility reports are gold. And if it's useful, a GitHub star genuinely helps people find it.

Disclosure: I'm the author of GemType. It's an independent project, not affiliated with or endorsed by Grammarly, QuillBot, LanguageTool, or Google. "Grammarly" is a trademark of Grammarly, Inc.

🚀 Solo dev, months of work, launching today on Product Hunt. projectmem — local memory + judgment layer for AI coding agents. Open source. MIT. Free forever. 5 seconds of support means the world 🙏 https://producthunt.com/products/projectmem

Ripon C Malo — Thu, 21 May 2026 16:28:06 +0000

producthunt.com

How I built projectmem — an MCP server that gives Claude, Cursor, and Codex persistent memory

Ripon C Malo — Thu, 21 May 2026 02:30:29 +0000

Few months back, my AI coding agent confidently suggested this fix:

.header-preview {
    contain: layout;
}

I'd tried that exact thing the previous Friday. It didn't work. The agent had no memory of the failure — different chat, fresh context, same dead-end.

This happens every Monday. Across Claude, Cursor, Codex, Antigravity — agents are stateless between sessions. Each new conversation pays 5,000–20,000 tokens to rebuild context that existed yesterday. The model isn't broken; the architecture is.

So I built projectmem. This post walks through what it actually does — five killer features, a four-view D3 dashboard, the architecture, and the conda/venv hook bug that nearly shipped v0.1.3 broken. It's open source, MIT, runs 100% local, ships as a single pip install.

What projectmem is, in 60 seconds

A small Python package that does three things:

Captures development events — bugs, fix attempts, fixes, decisions, gotchas — into plain-text JSONL inside your repo (.projectmem/events.jsonl). You commit it. You can git diff it.
Exposes 14 MCP tools so any MCP-capable AI client (Claude Desktop, Claude Code, Cursor, Antigravity, Codex) reads and writes that memory directly. One config block per client, works in all of them.
Runs git hooks that warn you at commit time before you repeat a logged failed approach.

pip install projectmem
pjm init

That's the install. pjm init writes the memory directory, drops a CLAUDE.md bridge file, installs the git hooks, pre-populates PROJECT_MAP.md from your stack manifests, and prints a ready-to-paste MCP client config block. No cloud, no daemon, no telemetry.

The five killer features

1. Pre-commit warnings (the differentiator)

The git pre-commit hook checks your staged file against memory. If there's a logged failed approach on that file, it warns you before the commit lands.

projectmem: Pre-Commit Check
────────────────────────────────────────────────────────────

  styles.css
    WARN  1 failed attempt on this file
           Last failure: tried contain: layout — preview still jumps
             (3 days ago)

────────────────────────────────────────────────────────────
1 warning(s). Review before committing.

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. The pre-commit hook is the unlock.

2. Cross-project memory

Lessons in one repo automatically surface in others on the same stack. Library gotchas, framework decisions, patterns you only had to learn once.

~/.projectmem/global/
├── library_gotchas.jsonl
├── patterns.jsonl
└── .promotable.json    ← self-curating cache

When you pjm init a new project, projectmem detects your stack from pyproject.toml / package.json / Cargo.toml / go.mod and injects relevant cross-project gotchas into AI_INSTRUCTIONS.md. Stack-aware filtering, so a vite project's mention of "next" doesn't pollute Next.js gotchas in your actual Next.js repos.

100% local — ~/.projectmem/global/ stays on your machine. No cloud sync, no account, no telemetry. A gin gotcha you log in proj-go shows up in your next Go repo. A vite gotcha in proj-react shows up in your next React repo.

3. Provable ROI (`pjm score`)

An A+ → F letter grade backed by concrete numbers. The first AI memory tool with metrics a CTO can verify.

$ pjm score

projectmem Prevention Score: A- (87/100)
  Failed approaches on record: 8
  Decisions documented: 14
  Fixes with context: 12
  Debugging hours saved: ~12h
  Tokens saved: 47,500
  Estimated USD saved: $4.75

Output as terminal, JSON for CI (pjm score --format json), or a shields.io badge for your README. Lets you put a number on the value the memory layer is actually producing — instead of a marketing claim.

4. Smart context injection (`pjm wrap`)

Launches your AI agent with a token-budgeted context block already loaded — so the agent starts with your project memory inherited, instead of blank.

$ pjm wrap claude --tokens 2000
# launches Claude with a 2000-token context block of:
# - your project summary
# - recent decisions
# - relevant cross-project gotchas
# - any failed approaches on files you'll likely touch

Works with Claude Code, Cursor (writes to .cursorrules), Aider, and clipboard-paste for everything else. The AI session begins experienced, not from zero.

5. Real-time file watcher (`pjm watch`)

Auto-starts on pjm init in interactive terminals. Detects rapid edits to the same file (debugging sessions) and logs churn events automatically. Battery-aware, gitignore-aware. Catches what AI silently misses — the between-commits iteration where most actual debugging happens.

$ pjm watch --status
projectmem watcher: active (PID 47891)
  Watching: /Users/me/repos/your-project
  Events captured today: 12 churn, 3 commit
  Battery: AC power (full speed)

The visualization: four D3 dashboards from one command

This is the part I think most projects skip and shouldn't.

$ pjm visualize
# opens localhost:8765 in your browser

You get an interactive D3 dashboard with four views, all auto-generated from your memory — zero extra AI tokens.

Story Map

The complete narrative of your project — every decision, milestone, and failure visualized as an interactive force-directed graph. Failed files glow red in the heatmap. Drag nodes around. Zoom into problem areas. Your AI reads this to understand not just what your project is, but how it got here.

ROI Dashboard

Live visualization of how much projectmem actually saves you. Animated counters for tokens prevented and USD protected. Capture-source donut showing manual vs auto-captured events. File churn heatmap surfacing your most-debugged files. Cumulative savings area chart over time.

Architecture Map

Toggle between a horizontal dendrogram (clean, hierarchical) and a force-directed graph (relationships, churn). Both auto-generated from PROJECT_MAP.md. Zoom, pan, color-coded by folder.

Event Timeline

Every event in your memory rendered chronologically — with AUTO badges distinguishing auto-captured events from manual ones. Filter by Manual / Auto-captured / event type. Activity bar chart shows the rhythm of your project.

The whole thing is one HTTP server, vanilla D3.js, no React, no framework. Loads instantly. The view your AI agent reads in summary.md is the same view you can scrub through interactively when you open the dashboard.

The architecture (for the engineers in the room)

Stack:

Python 3.10+, ~600 LOC core
Dependencies: mcp, typer, watchdog. That's it. No frameworks, no daemon, no port.
Storage: append-only JSONL inside the repo, distilled into Markdown.
Transport: stdio MCP. The AI client spawns the server as a subprocess; no network, no localhost binding, no process to babysit.

The 14 tools:

get_instructions     get_summary        get_project_map
get_context          get_score          get_global_gotchas
get_issue            search_events      precheck_file
log_issue            record_attempt     record_fix
add_decision         add_note

Every parameter has a Pydantic Field(description=…) annotation, and where it matters, a schema-level constraint:

def record_attempt(
    summary: Annotated[str, Field(description="One-line description of what you tried.")],
    outcome: Annotated[str, Field(
        description="Result of the attempt.",
        pattern="^(worked|failed|partial)$",
    )] = "failed",
    ...
)

The schema literally rejects outcome="maybe" before the tool body runs. Cleanest way I've found to add real guardrails to LLM-generated tool calls.

Why stdio, not HTTP

agentmemory (the most-starred competitor) runs a Node daemon on three ports (3111 / 3112 / 3113) with a separate iii-engine binary and ~21,800 LOC. Excellent retrieval. Heavy install.

projectmem stays stdio-only on purpose:

No port to babysit
No daemon to remember to start
No conflict with existing infra
The AI client manages the subprocess lifecycle for free

Tradeoff: no cross-process state. For single-developer-per-project workflows, that's not a real tradeoff — every benefit goes to "one less thing to debug."

The privacy guardrail

projectmem stores event text verbatim in your repo. That's the whole point — the memory is plain text you can git diff. The downside: a careless paste in an AI chat — "the bug repros when I set OPENAI_API_KEY=sk-..." — would otherwise land that key on disk.

v0.1.3 closes that hole. Before any event hits disk, storage.append_event runs a conservative pattern scrubber across the user-supplied text fields. Matches against high-confidence patterns get replaced with [REDACTED:<kind>]:

Patterns: OpenAI sk-, GitHub PAT, AWS AKIA, Google AIza,
          Slack tokens, Stripe live/test keys, JWTs (eyJ...),
          Bearer tokens, PEM private-key blocks.

Patterns are intentionally narrow. Ordinary debugging prose — "tried contain: layout", "forgot password reset flow" — is never touched. 29 unit tests pin both true-positive and false-positive behavior.

Default-on. PROJECTMEM_NO_REDACT=1 opts out for the rare contexts where you genuinely want the raw text.

Either it's there from day one or users learn not to trust the tool. v0.1.3 makes it day one.

How to try it

pip install projectmem
cd your-project
pjm init

pjm init ends by printing a ready-to-paste MCP config block (absolute sys.executable baked in to dodge the Claude-Desktop / Cursor PATH-inheritance gotcha). Paste it into your client's config file:

Claude Desktop: ~/Library/Application Support/Claude/claude_desktop_config.json
Cursor: ~/.cursor/mcp.json
Antigravity legacy IDE: ~/.gemini/antigravity/mcp_config.json
Codex (TOML, not JSON): ~/.codex/config.toml

Cold-start your client and the 14 projectmem tools appear in the MCP panel.

Links:

Repo: https://github.com/riponcm/projectmem
60-second demo: https://youtu.be/YCqfJ8-XVqY
Step-by-step tutorial: https://github.com/riponcm/projectmem/blob/main/TUTORIAL.md
PyPI: https://pypi.org/project/projectmem
Official MCP Registry: https://registry.modelcontextprotocol.io (search projectmem)

What's next

The v0.2 roadmap:

Stale-memory detection — flag, never delete. Cross-reference each decision's referenced file against recent git activity; surface decisions that predate heavy churn as "possibly stale, confirm or supersede."
Explicit --supersedes on add_decision — the honest version of memory decay. Old decision retired with a back-reference; nothing destroyed; full audit trail.
Semantic search as an opt-in extra (sentence-transformers + sqlite-vec). Default install stays dependency-light.

Honest about the rough edges

Search is exact substring today, not semantic
API may still shift before 1.0
The precheck heuristics are simple right now (file-name match → surface failed attempts)
Recall benchmarks are unpublished (the equivalent for "judgment accuracy" hasn't been defined yet)

But: 58 unit tests, end-to-end verified across Claude Desktop / Claude Code / Cursor / Antigravity / Codex, the conda gotcha properly fixed, the privacy guardrail real and tested, the visualization dashboard genuinely useful.

If you build with AI coding agents every day, try it once on a real project. The pre-commit hook usually catches its first real failure within the first week.

What's the worst "I already told you this last week" moment you've had with your AI agent? Reply below — that's exactly the pattern the precheck heuristics need to learn from.

Thanks for reading.

— Ripon

DEV Community: Ripon C Malo

We Built a Free, Open Source Alternative to Topaz for Image and Video Upscaling

What it does

How it works

Three bugs worth sharing

Honest limitations

Try it

How to Free Up Disk Space as a Developer: Clear Hugging Face, npm, conda, and Docker Caches

Where a developer's disk space actually goes

Machine learning model caches

Package manager caches

Build artifacts and IDE caches

The stuff manual commands miss

The problem with cleaning it manually

Doing it all from one place: Jharu

Safe by design

Get it

OSSDrop — a curated, community-ranked directory of open-source tools

What OSSDrop is

How the ranking works — and what doesn't buy you rank

What you'll actually find on it

Adding your tool takes about a minute

Why it's built this way

FAQ

Open-source Grammarly alternatives in 2026 — and why I built another one

The open-source landscape, honestly

The trick that makes the third quadrant possible

The parts that were actually hard to build

Where each tool actually fits

Try it

🚀 Solo dev, months of work, launching today on Product Hunt. projectmem — local memory + judgment layer for AI coding agents. Open source. MIT. Free forever. 5 seconds of support means the world 🙏 https://producthunt.com/products/projectmem

How I built projectmem — an MCP server that gives Claude, Cursor, and Codex persistent memory

What projectmem is, in 60 seconds

The five killer features

1. Pre-commit warnings (the differentiator)

2. Cross-project memory

3. Provable ROI (pjm score)

4. Smart context injection (pjm wrap)

5. Real-time file watcher (pjm watch)

The visualization: four D3 dashboards from one command

Story Map

ROI Dashboard

Architecture Map

Event Timeline

The architecture (for the engineers in the room)

Why stdio, not HTTP

The privacy guardrail

How to try it

What's next

Honest about the rough edges

3. Provable ROI (`pjm score`)

4. Smart context injection (`pjm wrap`)

5. Real-time file watcher (`pjm watch`)