Skip to content
AI Compute Radar

The rules

How every number is made

Every figure on this site is one of three things: a measured reading with a collection timestamp, a sourced vendor fact with a citation, or a declared assumption you can see and change. When none of the three exists, we show the reason there is no number — a wrong price is worse than no price.

What is measured, and how often

Four collectors run on our servers — no browser is involved, and they run whether or not anyone visits:

The three badges

● Collected marks a measured reading and names its age; the exact instant sits in the markup, so the claim can be checked. A section's freshness is always its oldest contributing source — a fresh price run is not allowed to vouch for old download numbers.

◇ Estimated marks a figure computed from our curated catalog by a deterministic engine — real inputs, real arithmetic, but not a live reading.

◈ Demo data marks placeholder values that exist so the interface can be developed offline. You should not see this badge in production; if you do, a data source is down and the page is telling you so rather than pretending.

The Heat Score

Heat answers one question — how much momentum and relevance does this model have right now — and it refuses to pretend it is objective truth. It is a weighted average of five components, every one a measured signal expressed as the model's percentile among all models with a full week of history:

35% trending level (Hugging Face, today)
30% 7-day download growth (Hugging Face)
15% 7-day trending change (our own daily history)
15% 30-day downloads (Hugging Face)
5% Hub likes (Hugging Face)

heat = 100 × Σ(weight × percentile) / Σ(weight of available components)

Percentiles, not raw counts, so a four-digit trending score and a nine-digit download counter can share one scale without magic constants. When a component cannot be measured for a model, its weight is renormalized across the rest — and the coverage is published as the confidence figure next to every score. Absence lowers certainty; it never silently lowers the score.

The rules around the number: a model gets no score at all until its history spans seven days (“ collecting” is not “cold”); download momentum only counts on a baseline that is itself about a week old and at least 10,000 downloads deep, so a tiny new repo cannot fake a breakout; the direction arrow needs a move beyond ±5% of the trending baseline (downloads only ever vote “up” — a falling 30-day window usually means an old spike aging out, so only trending may vote “down”). BREAKOUT marks a model in the top 5% of download growth with confidence ≥ 65%; COOLING marks a previously relevant model whose trending score fell by a quarter or more over the week.

Two components of the original design are deliberately absent: cross-provider usage momentum (no public source exists — the one we wanted is login-gated) and benchmark quality (we refuse benchmarks entirely). The board keeps showing every raw signal beside the composite, and the score is recomputable from the stored daily history alone — there is no hidden state to trust.

The pick of the week

Once a week one model gets a written report. Which model is not a matter of taste: a published rule chooses it from measured signals, and the rule is stored with every issue together with the full candidate list, so the choice can be recomputed.

Pick of the week is the model with the largest Heat Score rise over the last seven days among tracked models that run comfortably (GOOD or EXCELLENT) on at least one consumer card of up to 24 GB at 8K context. A rise counts only when it is at least three points, the model's Heat Score is at least 50 today, and the model's own direction is not falling — a low score that climbs while the models around it fall has only moved because they moved. Ties break by the higher Heat Score, then by 30-day downloads. A model cannot be picked again within four weeks. While the heat history is younger than a week, the rise is measured over the readings that exist and the report says so; when no rise counts, the rule falls back to the highest Heat Score and records that.

The rule decides the model; people write the text. Every number in a report is frozen at selection time and links back to where it was measured, the fit ladder comes from the same engine as the finder, and a “watch out” section is mandatory. No benchmarks, no speed claims, no sponsor has a say in the choice. Issues are permanent at /pick/<week> and never rewritten after publication.

The local-fit estimate

Whether a model runs on your machine is arithmetic, not opinion:

estimated memory = measured weights + computed context cache + runtime overhead
usable memory = your memory − safety margin

The weights figure is the byte size of a real, published GGUF file — never derived from a parameter count. The context cache is computed from the model's own config.json: layer by layer, respecting hybrid attention (many modern models cache full context on only a fraction of their layers), sliding windows, and latent attention (which stores one compressed vector instead of separate keys and values). The safety margin reserves 12% of memory for the display, the OS and allocator overhead — and on Apple Silicon we plan with only 70% of unified memory, because macOS caps what the GPU may take.

When a model's attention shape is unpublished or one we cannot model, the site says UNKNOWN instead of guessing. Fit labels are working comfort levels, not benchmarks: we publish no quality scores and no speed claims.

The cost comparison

The calculator prices the same model three ways. Cloud uses the measured per-token prices; your own machine uses a sourced vendor list price (editable — what you actually pay wins) plus electricity from the vendor's power figure and your rate; rental uses the cheapest measured GPU class that actually fits the model. Usage volume, active hours, the input/output token split and the amortization window are assumptions, listed next to the result, every one changeable. A configuration that cannot exist — a model too big for the card — gets a reason, never a price.

The Rent Index

Rental prices come from hourly marketplace snapshots: verified on-demand offers on Vast.ai, multi-GPU hosts normalised to a per-GPU price. The index turns those snapshots into a description of what prices did — never a forecast. A day is the median of its hourly medians, counting only hours with at least five verified offers, because a single overpriced listing once made an hour's median twenty dollars. A day whose median is more than twice or less than half the median of the surrounding days (three on each side) is treated as a marketplace glitch and excluded, and the page lists every excluded day.

A week is the median of its remaining days and needs at least four of them; the weekly change compares this week with the seven days before it, never one day with another. “Since start” compares the current week with the first week collected and states how long the record is. A 30-day change appears only once thirty days are on record — before that it is null, not an estimate. The words follow fixed thresholds published next to the numbers: up or down from ±8%, sharply from ±20%, offers up or down from ±15%. Fewer than two usable weeks reads “collecting”. The rule lives in src/lib/rent-index.ts with its tests, and the same figures ship in the API. The price history charts and the price moves in the homepage edition read the same cleaned daily series — the edition compares complete days, yesterday against the day before, never one snapshot against another.

Radar Cards

A card is a spec sheet with a hologram, not a fan poster. Every fact on it carries a status — vendor (the maker’s own page or press release), review (a contemporary review naming the figure) or reported (a secondary source quoting the period) — and a link to that source. A fact without an honest source is left off, which is why the GeForce 256 has no price. Machines the site already tracks take price, power and bandwidth from their hardware profile at render time, so a card can never disagree with the finder.

“What runs on it today” is the same fit engine as every other page, at 8K context: measured file plus computed context cache plus overhead, against the usable share of the machine’s memory (88% of a card, 70% of Apple unified memory). A retro machine enters the engine with nothing but its memory. The hologram is drawn from the machine’s dimensions and a parts list — fans, fin stacks, ports, power plug — never from a product photo or a scan; where the maker publishes no dimensions the card says the proportions are approximate.

Numbers are issued in claim order by the database, one row per issued number holding the card, the number, the edition month and the fit count at that moment — no name, no identifier, nothing that can be bought. The number stays in the reader’s browser. There is no blockchain and no marketplace, and there will be none.

What we refuse to publish

Independence

Outbound links to providers route through an internal redirect and currently carry no referral codes; if that ever changes, the legal notice will disclose it first. Referral revenue never influences a ranking, a recommendation or a fit verdict — all three are computed from the measured data by deterministic code, and this page is the standing promise that it stays that way.

Corrections

Found a number that looks wrong? The contact address is in the legal notice. A correction that survives checking updates the data — and, where the mistake was systematic, the rule that produced it.