Skip to content
[ METHODOLOGY · PUBLIC RECORD ]

How we pick, score, and verify.

A directory is only useful if you trust the picks. Below is a written record of exactly how recommendations are made on this site — what we measure, what we don't, what we deliberately refuse to do.

100
tools tracked
87
run locally
13
cloud-only
77
open source
57
Apple Silicon

Who, how, and why

Who: content is published by the AI Hub Search editorial desk, an organizational byline. We do not create a fictional expert, biography, credential, or lab.

How: we start with official documentation, upstream repositories, release notes, and model cards. Community reports may reveal edge cases, but are labeled separately and never converted into an official minimum. AI can assist with outlining and copy editing; the published conclusion and source selection receive editorial review.

Why: every page should help a reader finish a decision—choose a hardware tier, reject an incompatible tool, or assemble a reproducible workflow. Catalogue volume and search traffic are not sufficient reasons to publish a page.

Evidence levels and confidence

Documented
Highest confidence

A capability or requirement stated by the project, vendor, model card, or upstream repository. The page should link the source.

Editorial synthesis
Reasoned conclusion

Our decision or comparison derived from documented facts. It is labeled as judgment rather than presented as a vendor statement.

Workload-dependent
Validate locally

A planning range affected by model variant, precision, context, resolution, frames, batch, runtime, or offload. It is not a universal minimum.

Community-reported
Corroboration only

A workaround or result reported outside official documentation. It must be attributed and is never promoted to an official requirement without upstream support.

Things we deliberately don't do

  • No paid placements. No tool can pay to be ranked higher, featured, or recommended. Order is a pure function of the scoring system below.
  • No invented benchmarks. We don't list synthetic tokens-per-second numbers we didn't run ourselves. Hardware data comes from the project's own README, release notes, or upstream documentation — and we say so.
  • No astroturfed reviews. There's no “user rating” widget on the site because we can't verify them and they're trivially gameable on a niche directory.
  • No SEO doorway pages. A route must contain enough original decision support to justify its existence. Thin frontier-model datasheets are deliberately excluded from indexing until they gain model-specific analysis; we do not pad them to hit a word count.

How tools are scored

Every tool has two numeric signals in the database that drive ranking on the homepage, the Stack Builder, the “Best for X” decision tree, and the use-case pages:

power_user_score
0–100

An editorial assessment of documentation maturity, project maintenance, workflow capability, hardware transparency, and the quality of available upstream evidence. It is not a measured user-satisfaction score.

trending_score
0–100

An editorial recency signal based on releases and meaningful ecosystem activity. It is reviewed over time; it is not presented as a live, exhaustive measure of community usage.

Both are editorial values, not algorithmic — and we say that openly. The honest claim is “a human read the docs and the issue tracker and rated it,” not “an algorithm crunched a benchmark.”

How the Stack Builder picks

The Stack Builder combines those scores with hardware fit:

fit = power_user_score * 0.6
    + trending_score   * 0.2
    + 5 if open_source
    + 5 if hobbyist_friendly
    * 1.05 if tool runs comfortably (rec VRAM ≤ budget)

eligible = (tool.minimum_vram_gb <= budget)
       AND (platform = 'any' OR matches platform filter)
       AND (compute_location is local, when budget > 0)

Each slot in the stack is independent — we don't fudge picks to force compatibility between slots. If your VRAM budget can't fit a slot, we leave that slot empty and tell you why. That's the trust contract: an empty answer is more useful than a wrong one.

What "hardware-verified" actually means

On every tool page you'll see VRAM and disk numbers. These come from three sources, in order of preference:

  1. The project's own documentation — when the README states “requires 12 GB VRAM”, that's what we record.
  2. The official Hugging Face / GitHub release notes — for models, this is where the quantization tier and matching VRAM ceiling come from.
  3. Reproduced community reports — when a number isn't officially documented, we use the figure that's converged across multiple independent reports (GitHub issues, subreddit threads, Discord screenshots).

What we don't do: claim we ran the model on a specific card and got a specific tokens-per-second number. That would require an infrastructure we don't have and would be impossible to verify from our side anyway. The site is an editorial layer, not a benchmark rig.

Affiliate links

Some outbound links may become affiliate links through Skimlinks and known affiliate destinations are marked and qualified as sponsored. They cost the reader nothing and may help fund hosting and editorial coverage.

They do not influence ranking. A tool with an affiliate link is subject to the same published scoring rules as a tool without one. Commercial availability is not an evidence level and does not establish a recommendation.

Corrections

If you spot a wrong VRAM number, a stale model link, or a tool that's been ranked above one that's clearly stronger today — tell us. The catalogue is updated on a rolling basis; getting it right matters more than being first.

You'll see an “Updated” date on catalogue entries and a material-change date on guides. Dates are source-backed or editorially set; a site rebuild does not pretend that old content was newly reviewed.

[ NEXT ]

Find your stack

The Stack Builder is the fastest way to see the methodology in action — a real, hardware-filtered set of picks for your card and your goal in three clicks.