Something genuinely new ships most weeks. A model that relights an interior from a single image. A mesh generator that finally produces usable topology. A video model that holds a camera move a little longer than the last one. The demo reel is spectacular, the launch thread is euphoric, and three days later nobody can tell you whether the thing has weights you can download, a licence that survives contact with a paying client, or a memory footprint that fits on a card you own.
I used to keep up by reading. That does not scale, and it is biased in a specific way: release-week enthusiasm tells you what a tool does in the best case, on the author’s hardware, with the author’s chosen input. It tells you nothing about the three questions that decide whether I can point a tool at your project. Is it real, or a paper with a project page? Is it licensed so the images can be used commercially? Will it run on machines I own, in my building?
So I stopped reading and built a database.
An internal web app on a machine in the office: Python and SQLite behind FastAPI, a React front end, a scheduled worker that keeps it current. Not public. It exists so one studio can answer one question quickly.
Mid-September 2026 it holds 1,537 tools, harvested from several hundred source videos on the AI channels I follow, plus direct imports from GitHub and Hugging Face, the ComfyUI custom-node registry, the Ollama model library, and scraped roundup pages. Entries are classified against 21 categories: text-to-image, image editing, upscaling and restoration, relighting, depth estimation, 3D mesh, Gaussian splatting, video, language models, vision-language models, voice cloning, LoRA training, and the rest.
Release state, on a ladder. Announced → paper-only → code released → weights released → runs locally. A tool’s state only moves up unless a person overrides it, so an entry records the best thing ever confirmed about it, not whatever a check saw on a bad day. The current catalogue is instructive: of 1,537 entries, 674 are open-source and local in principle, 515 are verified runnable locally. The rest are a paper, an announcement, code without weights, a hosted service, or unchecked. Roughly a third of what gets talked about is something you could run this week.
Licence, and whether it is commercially safe. Verification reads the licence metadata the repository itself publishes and classifies it: permissive, copyleft, non-commercial, use-restricted. Anything carrying “NC”, “non-commercial” or “research only” is flagged unusable for client work. Right now 270 tools are confirmed commercially safe; 1,225 carry no readable licence string at all, which means “not for client work” until a person reads the terms.
Hardware. Where a model publishes weights I can measure, a minimum VRAM figure is derived from parameter count or weight-file size, and the browser filters to “fits my GPU”. That number exists for only a small fraction of the catalogue so far. Stars, downloads and last-push date ride along as an activity signal. Abandoned is a status too.
Where it runs in my stack. ComfyUI support as native, custom node, or none: 206 tools have a custom node, two are native. A separate flag marks the 233 that pull straight through Ollama, cross-checked against what is installed on my own node.
A fit score against my own projects. Each internal project has a profile: priority categories, preferences, hard requirements. A local language model scores every plausibly relevant tool from 0 to 1 with a one-sentence rationale. Where a project requires commercial licences, a non-commercial or copyleft tool is forced to 0.2 or below no matter how good it looks.
Once a week a job pulls new material, parses tool mentions with a local model, deduplicates, re-verifies everything below “runs locally” because that is where states flip, then re-scores fit, re-enriches, rebuilds the search index and writes a digest of what changed.
It reports on itself. Every stage records success, rows touched, time taken; the run exits with a failure code if any stage broke and raises an in-app alert. It refuses to start while another writer is running, because two concurrent writers corrupted the database once and that is not a lesson worth learning twice. When GitHub rate-limits the checks, the affected tools are marked rate-limited instead of quietly downgraded.
A watchlist sits on top: tools I am waiting on (a licence change, a ComfyUI node, weights finally landing) raise an alert when their status moves.
A licence decides whether you can use the image. Several of the most impressive open models ship under non-commercial or research-only terms. An image made with one of those is not something I can hand you for a brochure, a hoarding or an investor deck. Checking before a tool enters production is much cheaper than finding out after the print run.
Running locally decides where your material lives. Unbuilt schemes, tenant layouts, plans under NDA. The runtime filters exist so I can prefer tools that run on my own machines. Nothing uploaded, nothing retained by a third party, no per-image cost quietly shaping how many variations I try.
Hardware limits are real limits. A model that needs more memory than my cards have is not a future option, it is not an option on your schedule.
It does not tell me a tool is good. It tells me the tool exists, what state it is in, how it is licensed and where it runs. Whether it holds up on a real interior with a real material palette only comes out of trying it on actual work, and most things that clear the filter still fail that test.
Its metadata is only as good as its sources. 1,225 entries carry no licence string the checker could read. VRAM figures are thinner still. Categories are drafted automatically and fit scores come from a model; both are editable by hand, and I edit them.
Scoring fit is a judgement call. A high score means “worth an afternoon”, not “adopt this”. The value is not in the number. It is in never choosing tools from memory, or from whatever was most recently impressive.
The tools that pass go into the production pipeline, where every model carries its licence class into the files it produces. If you want to know what this means for a specific project — what is realistic this quarter, what is licensed cleanly enough to publish, what stays on my machines — get in touch.