Fifty-Two Stars and a Filesystem That Finally Remembers

SCM is interesting not because it searches photos, but because it quietly picks a side in one of the oldest arguments in agent design: where should perception be stored?

The project, a macOS tool from a developer going by allenv0, does deep AI search across every photo and every frame of video in any folder. It hit Show HN last week, pulled 86 points and 47 comments, and sits at 52 stars on GitHub. Those are small numbers in absolute terms. They are not small when you look at who shows up in a 47-comment thread about local vision inference. That ratio of comments to points is the signal here — practitioners arguing, not spectators upvoting.

Perception that writes to disk instead of a vector store

The design choice I keep turning over is this one: SCM uses local AI vision models to analyze photos and automatically rename them based on what the model sees. The library becomes searchable privately on the user’s own hardware, through Ollama.

Renaming. Not embedding into a sidecar database. Not a proprietary index that lives in ~/Library/Application Support and dies when you uninstall. The model’s output gets committed to the one piece of metadata that every tool on every operating system already understands.

That is a more opinionated architectural stance than it first appears. Most retrieval systems built on vision models treat the filesystem as dumb storage and the index as the real artifact. The index is where the intelligence lives, and the index is fragile — it is versioned to a specific embedding model, it rots when you swap models, and it is useless to anything that was not built to query it. Write the perception into the filename instead and you get something different: a description that Spotlight can find, that grep can find, that a shell script can find, that a future agent with no knowledge of SCM can still read.

The tradeoff is lossy and permanent

I do not want to pretend this is free. A filename is a brutally narrow channel. An embedding holds a few hundred or few thousand dimensions of what the model understood about an image; a filename holds a sentence fragment. You are taking a rich internal representation and projecting it down to whatever survives as text. Everything else is discarded.

And it is a destructive write. Renaming files mutates the thing being described. If the model is wrong — and vision models are confidently wrong in characteristic ways, especially on faces, text in images, and anything culturally specific — the error is now baked into your library rather than sitting in a rebuildable cache. Re-indexing with a better model later means overwriting the previous model’s guesses, with no clean record of what changed.

Both of those are real costs. They are also the costs you accept in exchange for durability and tool-agnostic readability, which is a trade I have seen almost nobody make deliberately.

Every frame is the hard part

The photo side of this is tractable. The video side is where the engineering gets uncomfortable, and the project’s own description — every frame of video — is a claim about compute, not features.

Consider the arithmetic. A single hour of 30fps video is over a hundred thousand frames. Run a vision model on each one and you are doing more inference on one home video than most people do on their entire photo library. Any system making this promise has to be doing aggressive work upstream of the model:

• Temporal deduplication — adjacent frames are near-identical, so the vast majority can be skipped without information loss
• Scene and shot-boundary detection — a cheap classical signal that tells you where content actually changes
• Keyframe prioritization — spending the expensive model only where the cheap filters say something new happened

I have not read the implementation, so But this is the layer where local-first vision tools succeed or fail, and it is the layer that gets the least attention in demos. The model is the easy part now. Deciding what not to send to the model is the actual intelligence.

Why the local constraint sharpens the design

Running through Ollama on user hardware is a privacy claim, and that is how it will be marketed. For my purposes it is more useful as a design constraint. When inference is metered by someone else’s API, the lazy answer is always to send more frames. When it runs on the machine in front of you, every wasted forward pass costs you fan noise and battery, and the incentive flips toward being smart about selection.

Constraints like that tend to produce better architecture than abundance does. The tools that will matter for personal media retrieval are the ones that treat model calls as expensive even when they are technically free, and that write their outputs somewhere the next tool can still read them.

Fifty-two stars is not a verdict on any of that. But the choice to make the filesystem the index, rather than a database nobody else can query, is worth more argument than it is currently getting.

🕒 Published: October 5, 2026