How Cappy decides
Every catalog entry follows the same four steps before we stamp it. After publication, the community helps keep the catalog accurate.
The evidence grade
Each entry shows an evidence grade beside its source count. The grade reflects how much independent, verified material supports it. Even a strong model gets a C when the sources are thin. Cappy will tell you when the evidence isn't there.
- Grade A
- Five or more independent sources, nearly all of them checked.
- Grade B
- Three or more sources, most of them checked.
- Grade C
- Sourced, but thinly. Treat the details as provisional.
Record the claims
Every catalog claim links to an official doc, paper, or model card. Source counts on cards show the evidence behind each entry. Entries clearly label estimates rather than measurements. If Cappy can't back a claim, it doesn't ship.
Check the hardware math
Choose a hardware tier to see whether each model fits. A model that fits on 32 GB may not fit on 16 GB. More available memory can improve the fit rating. Less memory can lower it.
Every fit verdict, VRAM figure, and speed estimate on this site comes from one formula, printed here in full. No black box: if a number looks wrong, this is the section to argue with.
- Weights
- parameters (billions) × bits-per-weight ÷ 8, in decimal GB. Q4_K_M ≈ 4.85 bits, Q5_K_M ≈ 5.69, Q6_K ≈ 6.59, Q8_0 ≈ 8.5.
- KV cache
- 2 (keys + values) × layers × KV heads × head dimension × 2 bytes (fp16) × context tokens. The calculation uses the model's own GQA head counts when known. Otherwise it uses an architecture estimate for the model size and marks the result as estimated.
- Overhead
- a flat 1.5 GB allowance for the runtime, CUDA/Metal context, and activation scratch.
- Fits when
- weights + KV cache + overhead ≤ usable memory × 0.95. Apple unified memory counts 75% of its physical size as usable, because the OS shares it.
- Mixture-of-experts
- all parameters count for memory (every expert sits in VRAM). Only the active parameters count for speed.
- Partial offload
- the memory deficit ÷ per-layer weight size = layers moved to CPU RAM. A CPU layer is ~8× slower, and every token visits every layer, so speed multiplies by 1 ÷ (GPU share + CPU share × 8).
- Speed estimate
- decode is memory-bandwidth-bound: tok/s ≈ memory bandwidth × 0.5 ÷ active-weights GB. The 0.5 is real-world efficiency, not marketing.
Worked example. A 14B model at Q4_K_M on a 12 GB card, 8k context
- Weights: 14 × 4.85 ÷ 8
- 8.49 GB
- KV cache: 2 × 40 × 8 × 128 × 2 B × 8,192
- 1.34 GB
- Runtime overhead
- 1.50 GB
- Total
- 11.33 GB
- Budget: 12 × 0.95
- 11.40 GB
11.33 GB against a 11.40 GB budget: it fits, with 0.07 GB to spare. The matrix calls that “runs, tight”. Raise the context slider and the KV-cache line is the only one that grows.
Validation: these are estimates, and they wear an est. badge until the community proves them. When 3 or more rig reports corroborate a figure on matching hardware, the site shows the measured median instead and the badge flips to measured, n=X. Where measured runs and the formula have disagreed, the measured runs won and the constants above were tuned. That's the record, not a promise.
Stamp a verdict
- RUN IT
Worth your time. For models, it fits its recommended hardware and its claims check out against sources.
- FINE
Solid but not special, or it fits your tier only with compromises like shorter context or slower speeds. Still useful if it matches what you need.
- SKIP
Cappy reviewed it and recommends against it. Every SKIP includes a written reason based on catalog data. That reason may be a license restriction, a hardware mismatch, or an unsupported claim.
How often the desk gets re-checked
New models land constantly, and re-checks happen when there's something to re-check. No schedule is promised. The "re-checked" date on the front page comes from real catalog timestamps, not a date someone typed in once, so the record speaks for itself.
What we measure
Cappy.fyi counts a short list of anonymous interaction events so the desk can tell whether a page actually helps. This is the complete list:
- start_step, start_complete, start_drop
- progress through the Start-here picker: which step was reached, finished, or left.
- rig_set
- a rig was chosen from the hardware list.
- rig_detect_optin
- the opt-in “Detect my GPU” button was pressed.
- fit_chip_open
- a fit chip’s explanation was opened.
- flow_filter
- a filter was applied on the release timeline.
- picker_to_entity
- a recommended pick was followed to its catalog page.
- share_copy
- a share or copy-for-forum button was used.
- ledger_search
- the considered-not-included ledger was searched.
- frontier_toggle
- the frontier chart’s use case was switched.
- ways_row_click
- a “ways to run it” row was clicked.
- catalog_question_open, catalog_question_submit, catalog_question_thread_click, catalog_questions_view_all
- a catalog question composer was opened or submitted, or an entity question/library link was followed. Question text is never recorded.
What we don't measure: anything about you. Counting is done by cookieless Plausible Analytics. No cookies, no fingerprinting, no session recording, and no personal data. Events carry only the names above plus coarse properties like a step number or a GPU tier, never free text you typed and never an account identity. Cappy counts splashes, not which capybara made them.