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:

• + Hugging Face Hub, daily: downloads, likes and the Hub's own trending score for every tracked model. The download counter is the Hub's rolling 30-day window — not an all-time total, and not unique users.
• + OpenRouter, daily: API prices per million input and output tokens (catalogue licensed CC BY 4.0). Models are matched by their published Hugging Face id, never by name similarity.
• + Vast.ai, daily: rental offers per GPU class. We publish the median of verified, currently rentable on-demand offers; multi-GPU hosts are normalized to a per-GPU price. A price movement below 2% is displayed as steady — marketplace noise is not a trend.
• + The catalog itself, weekly: every curated model's published config.json and GGUF file listing is re-read, so a re-quantized repo updates our numbers without anyone remembering to run a script. Newly discovered releases wait in a review queue — a person assigns their roles before they appear anywhere.

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 words on the pages

Since 31 October 2026 the pages answer in words and keep the numbers one click away: behind “Show the numbers”, on the board, on this page and in the API. Every word is a fixed translation of a value that already exists; nothing is computed for the word alone. This is the table.

The pages summarise; the API carries every number. The word “Heat Score” itself appears on the board, here, in the API and in the pick's rule card, and nowhere else on the pages.

Measured, computed, assumed, refused

Since 23 October 2026 the memory tables and the derived price figures carry a small word per column that says which of the three kinds a number is, so a reader can argue with the exact term instead of the total. Measured is read from somewhere at a time we show: the size of a GGUF file from the Hub's file listing, a marketplace median from the offers at the top of the hour, a cloud list price from the provider's price page, downloads and likes from the Hub. Computed is arithmetic over published inputs that are shown next to it: the context cache from a model's layer count, KV heads and head dimension, the price per gigabyte-hour, the 30-day range and swing, the Rent Index. Assumed is an allowance we declare and you can change: the runtime overhead, the 12% memory margin, the usable memory of a card. The API says the same thing in a basis block on every fit.

Four kinds of number do not appear here at all, by rule: no tokens per second or any other speed figure, because a speed depends on the runtime, the build, the settings and the day, and a published ceiling is read as a measurement whatever label it carries; no benchmark or quality score, because we do not run them and will not relay someone else's; no street or asking price for used hardware, because a listing is not a sale; and no forecast of any series, because the data describes what was measured and nothing else.

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.

Maker board

The maker board groups the tracked models by the creator named on their pages and adds up what those pages already show. Its order is a rule, printed above the table: most models in the Heat Score top ten first, ties by the best-placed model, then by summed 30-day downloads. Mean Heat is the average of a maker's scored models; the 7-day change averages the moves of the models that had a reading a week ago and says over how many models. Downloads are the Hub's rolling 30-day counts per tracked repository, summed, with a 7-day change weighted by those counts — a count of repository downloads, not of people. Release dates are repository creation dates. Nothing on the board is estimated or forecast, and a maker with one tracked model is judged on that one model, which the board says.

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.

How this differs from the GPU rental indices that futures and prediction markets reference — list prices, marketplace medians and transaction indices side by side, with their publishers — is set out in GPU price indices explained.

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 window can be switched to 14, 30 or 90 days (also ?window= in the API); a longer window compares the current span with the previous one of the same length, needs proportionally more days to count, and says from which date it will. The same cleaned series feeds the price alerts (an RSS feed, no account): a Vast.ai or Clore.ai median that moved by 10% or more between two complete days, or any change of a list price (RunPod, AWS, Azure, Oracle Cloud). The partial current day never triggers an alert. 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.

Since 21 September 2026 a second source stands next to the marketplace: RunPod's lowest posted on-demand price per class, read hourly from its public price list. That is a different kind of number — what one provider charges at its cheapest, not the middle of a market — so it is shown in its own column as “from”, gets its own index, and is never blended into the Vast.ai median. Where RunPod lists several types for one class (H100 SXM, PCIe, NVL), the cheapest is taken and named. Since 27 October 2026 one guard sits in front of that: a type priced below two fifths of the class's next-cheapest type is set aside and named in the data instead of becoming the figure. The rule was added after RunPod's API had reported an H200 NVL at $0.50 per hour for a few hours on most days since 22 September, next to an H200 SXM at $3.59, and then no stock for that type at all; the 70 hourly readings that carried the $0.50 were removed on 27 October, the daily medians never contained it. A class with a single priced type has nothing to compare against and is shown as it is.

Since 24 September 2026 a third source, and a second marketplace, stands beside them: Clore.ai. Its public listing is read hourly and treated exactly like Vast.ai's — a median over the hosts a renter could take at that moment, with the offer count and the min–p75 band — but the arithmetic differs: Clore.ai posts one price per host and per day, so a host's price is divided by its number of cards and by 24 hours, taking the lowest USD equivalent among the coins the host accepts. Hosts with mixed cards and the laptop and “D” variants of consumer cards are left out; datacenter types fold into their class as above. It gets its own column, its own index and its own alerts, and is never blended into the Vast.ai median.

Since 2 October 2026 the list prices of two big clouds stand beside the rental sources, in a table of their own: Azure and Oracle Cloud, whose price lists can be read without an account. Both are read four times a day and are a third kind of number — a pay-as-you-go list price per GPU-hour, with no offer count and no statement about free capacity. Oracle's public price list states a price per GPU-hour and has no regions; where it lists two shapes for a class (the A100 with 40 or with 80 GB) the cheaper one is taken and named. Azure prices whole virtual machines per region, so the per-GPU price is a VM's hourly Linux price divided by its GPU count, and that count comes from Microsoft's size documentation: a size the price list carries but the documentation does not describe is left out, never guessed. The lowest result across documented sizes and public regions is shown; spot and low-priority prices and the US government regions are left out. Both clouds sell GPUs as whole instances — one, two, four or eight cards on Azure, eight on every tracked Oracle shape — so each row names the instance, its GPU count and what the whole instance costs per hour. GB200 systems are not counted as B200: Oracle lists the two as separate products at separate prices, and Azure's GB200 size is left out for the same reason. The list prices get their own index lines and alerts (any change counts) and are never blended into a marketplace median.

Since 19 October 2026 two GPU clouds stand in the same table, read the same way four times a day from public pages that need no account: Lambda and Nebius. Lambda prices per GPU-hour in clusters of eight, four, two or one card, and the lowest price across the class's plans and cluster sizes is shown, with the plan and the cluster size named; its reserved and contract prices are left out. Nebius prices per GPU with a fixed vCPU and RAM allotment, so one GPU is the smallest instance; only its on-demand table is read, and its preemptible prices are left out like Azure's spot prices. Neither takes part in the cloud premium, which compares the three hyperscalers only: a GPU cloud and a hyperscaler are different products, and folding them into one factor would hide which of the two moved. Since 24 October 2026 CoreWeave is the third GPU cloud: its public pricing page lists on-demand instances of eight cards per region, North America and Europe, and the per-GPU figure is the instance price divided by its GPU count, the lowest across the regions, spot prices left out, as for Azure. Its page stays out of the sitemap for now, like every new page during the index recovery. Since 27 October 2026 Hyperstack is the fourth GPU cloud: its public pricing page lists on-demand prices per card and per hour, so the figure is the listed price itself, the cheapest of a class's SXM, NVLink and PCIe rows, with reservation and spot prices left out.

Two derived figures were added on 21 October 2026, both from the daily series above. The 30-day range of a class at a source is the lowest and the highest cleaned daily median of the last thirty days, the days they fell on, the mean of all days in the window, and the swing, which is high minus low divided by that mean; glitch days are excluded by the Rent Index rule, so a one-day spike cannot become the high, and a list price that never moved reports a swing of zero. The price per gigabyte-hour divides a class's cheapest competing reading on the price board by the memory in gigabytes of the card that reading refers to, which for the A100 class means the memory of the cheapest variant and is named in the row. It prices memory only: bandwidth, compute, interconnect and availability are not in it, and the table says so. Neither figure is a forecast; both are recomputable from the public API's daily data.

Since 5 October 2026 AWS is the third cloud in that table. Like Azure it prices a whole instance per region, so the per-GPU price is an instance's hourly Linux on-demand price divided by its GPU count from AWS's documentation of accelerated computing instances, the lowest across those instance types and public regions; GovCloud and the European Sovereign Cloud are left out. The source needs a word: AWS's documented bulk price list is about 300 MB per region, some 10 GB for all of them, so the prices are read from the small per-region files that AWS's own on-demand pricing page loads. Those files are not a documented interface. They carry the same publication date as the bulk list, and on the day the source was added every price used here was compared with the bulk file of one region and was identical; each run records both publication dates.

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

• + No quality benchmarks. We measure adoption and prices, not intelligence. “Most adopted” is written where others would write “best”.
• + No composite score without explainable inputs. The board ran without one for its first week, until the momentum history existed; the Heat Score above publishes its full formula, and every raw signal stays visible beside it.
• + No street prices. Hardware prices are vendor list prices with their date — retail moves too fast to quote as fact, so the field is yours to edit.
• + No provider's usage numbers dressed up as market share. OpenRouter's catalogue is OpenRouter's view, and is labeled as such.
• + No transaction prices, and no basket (stated 29 October 2026). Every price on this site was listed: read from the public page of a named source at the stated time, with the offer count beside it where there is one. What a renter actually paid is a different measurement, made by transaction-based reference prices such as Ornn Data's OCPI from data this site does not have; we do not estimate it, we do not republish it, and we do not blend sources into one index. Each source keeps its own column, its own kind of number and its own cadence, and the daily rows behind every column can be downloaded as CSV from the board, from each class page and from the API.

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.