How every figure in this atlas is built, how much weight it can take, and where it breaks. If a number here surprises you, the reason is on this page. And if the reason does not satisfy you, that tells you something about the number, not about the page.
Every chart, and every figure that matters, is marked with one of these five
Taken from a named public source without modification. Check the source link for the original.
Who each company is: its name, its ticker, its exchange and where it is run from, for all 63 of them. We checked each one against a source we name, then wrote it into the register with a link and the day we did it.
Derived from published inputs using a documented method. Directionally reliable; individual digits are approximations.
Used now for: how much of each material is dug up each year. How much is left in the ground. What a build takes as read. The exposure scores, and the numbers behind each scenario.
A demonstration value with a plausible shape. NOT market data — never use it for analysis or a decision.
Used now for: every price series, every commodity price, every equity series.
Real data, but past its expected refresh window. The level may no longer reflect current conditions.
Not used yet. No source we are joined to has fallen behind.
No value could be obtained from the configured source.
Not used yet. No adapter is set up, so nothing has failed.
Bundled demonstration dataset. No external price feed is connected, so treat every level as illustrative. The headline status is on purpose the weakest status in the dataset, not an average. An average would let solid company facts hide the fact that every price level here is a made-up value.
Counted one record at a time — one per price series, one per resource dataset, one per company — not one per field. A company record still counts as estimated even though we have now checked who it is. Each record ties who the company is to the exposure scores beside it, and the weaker of the two wins. Who each company is has its own check, per company, in the register.
The one thing to take away. No price in Compute Atlas is a market price. Each series is built by hand to match the shape and rough size of real, written-up events: the 2017–18 memory up-cycle, the GPU demand shocks of 2018 and 2021, the 2022 fall, the memory squeeze driven by AI after 2024, the rise in electrical-equipment costs after 2021. They are the right story with invented numbers. Use them to understand structure, and connect a real feed before you use them for anything else.
Each index follows a representative product at each date, not one fixed model number. One fixed model would be no use. The card that set the upper-mid tier in 2015 stopped being made years ago, and what is left of its price today would tell you about the second-hand market, not the market.
The five component indexes are built from monthly price paths. We set anchor points by hand and fill the gaps in log space, with a small, fixed month-to-month wobble so the series look like data rather than straight line segments. Filling in log space keeps moves smooth in percent terms, and makes sure a series can never cross zero.
The four system indexes are derived, not authored. A system index is the sum of its own parts list, with every line priced again each month from the index for that line. That is why the representative PC build cost can never disagree with the GPU, CPU, memory and storage indexes shown next to it. It is the sum of them. Edit a component index and the system index moves with it.
A product that stops being made is swapped in the basket for whatever now holds the same place in the market. The index is joined across the swap rather than started again. So the index measures the cost of a place in the market over time, not the cost of one object.
A brand new product is not filled in backwards. Data-centre accelerators only became their own thing in April 2016, so the accelerator index — and everything built on it, including the AI server build index — starts there and not in 2015. An index that quietly stretched a 2016 product back to 2015 would be inventing history, and the charts would look tidier for exactly the wrong reason.
The one idea that matters most in this whole app
A capability-adjusted price is the real price split by what the product actually gives you. It answers a different question from the sticker price, and the two answers often point opposite ways. Since 2015 the sticker price of a GPU has risen a lot, while its cost per benchmark point has fallen by about two-thirds.
A capability-adjusted figure is only as good as the thing you divide by, so every category says exactly what that is:
| Category | Denominator | Definition |
|---|---|---|
| Consumer GPU | benchmark point | How much one point of speed costs. Take the street price of the card. Divide it by its rasterisation benchmark score, where January 2015 = 100 points. |
| Desktop CPU | benchmark point | How much one point of speed costs. Take the street price of the part. Divide it by its multi-core benchmark score. On that score, the part we follow in January 2015 sits at 100 points. |
| DDR memory | GB | How much one GB of memory costs. Take the price of the memory and divide it by its size in GB. The memory we follow grows from 8 GB in 2015 to 64 GB by 2026. So the nominal line and the capability-adjusted line pull far apart. |
| NVMe storage | TB | How much one TB of room costs. Take the price of the NVMe drive and divide it by the room you can use, in TB. The drive we follow grows from 240 GB in 2015 to 2 TB by 2026. |
| AI accelerator | PFLOP/s | How much AI speed costs. Take the price of one accelerator. Divide it by its throughput, in petaFLOP per second. We use the dense BF16 number only. Sparse and low precision numbers are left out, because they are not all counted the same way. |
| Budget gaming PC | performance point | How much one point of speed costs for a whole machine. Take the total build cost. Divide it by a score that adds up CPU throughput, GPU rasterisation and drive speed. On that score, the 2015 build at this price = 100. |
| High-end gaming PC | performance point | How much one point of speed costs for a whole machine. Same score, and the same 2015 = 100 scale as the build at the low end. |
| Local AI workstation | performance point | How much one point of speed costs for a whole machine. Take the total build cost. Divide it by a score that leans on memory size and low precision throughput, on the same 2015 = 100 scale. |
| AI server | PFLOP/s | How much AI speed costs for a whole box. Take the price of the box and divide it by the throughput of all eight accelerators added up, on the same dense BF16 number. |
Where this breaks. A benchmark score is not a straight measure of how useful something is, and a blended score hides which job it was measured on. Petaflops are worse still. Makers quote sparse and low-precision figures in their own ways, so only dense BF16-class throughput is used here. And capability adjustment says nothing about whether you canuse the capability. A card with twice the throughput and the same memory may be worth nothing extra for the model you actually want to run.
Nominal prices are the money of the day: what the price tag said at that moment. Inflation-adjusted prices are given in money of the reference date. So a 2015 figure is shown as the amount of today's money that would buy the same thing.
The CPI series is set so the reference month of the dataset is exactly 100. That turns the adjustment into a simple ratio, and gives the reading you would expect: an inflation-adjusted 2015 price is “what that would cost in today's money”. Figures at the reference date are the same under both views, by design.
For hardware, taking inflation out matters less than people expect, and capability adjustment matters more. Inflation since 2015 adds up to a few tens of percent. The change in capability over the same years is measured in multiples.
Illustrative The bundled CPI series is built from rough yearly US CPI-U rates. The shape is close to the published series, including the 2021–23 spell, but these are not the published index values. This build is not joined to a live statistics feed. When it is, the published series takes over from this one, and the label above changes with it.
A build is a parts list plus a set of facility assumptions. No line carries a fixed price. Each one names a price driver and how it sits against that driver's representative product, and the unit price is worked out from the driver at the chosen date. That is what lets us price a build at a past date, or under a scenario, without keeping a second set of numbers that could drift apart.
Pricing at a past date uses the same parts list. It answers “what would this build have cost then”, not “what would you have built then”. In 2015 nobody would have asked for this machine, and most of the parts in it did not exist in this form.
The concentration score is the square root of the Herfindahl–Hirschman index of production shares, put on a 0–100 scale. The square root is what makes the number readable: a score of 82 acts like one producer holding 82% of world supply, which says far more than a raw HHI of 0.67.
Whatever is left over as “rest of world” is kept out of the sum. Counting dozens of small producers as one big one would make things look far more concentrated than they are. Copper is the clearest case.
The score measures mining, and mining is often not where the real problem sits. Rare earths show this best. The mining has genuinely spread out, while separating them and making magnets is still held in very few hands. Read the bottleneck notes on each resource, not just the dial.
Reported reserves are the part of a resource that is worth digging up at today's prices, with today's technology. They are not a countdown. Reserves often grow as the price rises, as new deposits turn up, as mining gets better or as the rules change. That is why this atlas gives reserves as years of production at today's rate, and never as a date when it runs out.
Compute Atlas never says a resource will “run out” in a set number of years. Where a reserves figure is published, the app says that reported reserves are worth about X years of production at today's rate. Where there is no figure worth giving, the app says so and says why, rather than showing a blank. Gallium, germanium and tantalum come out as by-products; electricity is a flow; water is local.
Two scores appear on every company, and both are Compute Atlas estimates, not company figures.
Revenue share is our estimate of how much of the group's money comes from this category, worked out from the segment numbers the company reports. Segments rarely line up neatly with places in the supply chain, so this is a judgement call.
Pure-play score (0–100) puts three things together: the revenue share, how directly the company sits in the tight step, and whether it can set its own price there. A company can have a high revenue share and a lower pure-play score if it sells into the bottleneck without holding it.
Who a company is — name, ticker, exchange, home base, what it supplies, where it sits in the chain — is public and checked. Customers are listed only where the link is public and widely known. Where it is not, the field is left empty rather than guessed at.
Exposure scores say what a company is tied to. They say nothing about whether the price already knows it. So each company also carries a market capitalisation, forward P/E, EV/EBITDA, revenue growth and gross margin. The priced-in read sets the pure-play score against the EV/EBITDA percentile of that company among the 63 companies in this atlas, not the whole market, and gives back one of three readings.
These labels describe; they never tell you what to do. Nothing here ranks companies as buys, and the valuation figures are made-up values shown to demonstrate the idea. A made-up multiple looks far more like something you could act on than a made-up price, so treat it with more suspicion, not less.
Compute Atlas is here to teach. It does not give investment advice. Exposure scores are estimates built from a method; they are not recommendations. Nothing here asks you to buy or sell anything, and no figure should be leaned on for a money decision.
How the Scenario Lab decides who a shock helps and who it hurts
One rule, used the same way on all ten links. A shock moves the price of something. That price is money in for whoever sells it and money out for whoever buys it. Each link carries two sets of weights over the same modelled quantities: one for what drives its sales, one for what drives its costs. The net position is one minus the other.
No link is marked a winner or a loser in the data. The verdict is worked out, which is why the same link gains in one scenario and is squeezed in the next. Memory makers gain most from an AI boom and lose most from an AI pause, from the very same coefficients.
A few weights are below zero on purpose, because being short of something is exactly what some links are paid for. A memory maker earns more when there is less HBM about, so its weight on that input is below zero. The same shortage turns up as a cost for the accelerator designers buying it. Without that pair, an HBM shortage would show memory makers as untouched, in the one scenario where they hold all the power over price.
A net figure is what the model says happens to the economics of a link. It is not a share price move, not a return, and not a recommendation. What each link spends is a judgement call, not a set of reported segment accounts.
Every number that sits behind a scenario, all in one table
The model shows how sensitive things are. It is not a forecast. A demand shock passes through six things that soften it and one that makes it worse before it reaches a price:
So twice the AI demand moves the price by tens of percent for the tightest categories, not by double. A price also falls a little less easily than it rises, because a factory cuts output when demand is weak.
One knock-on effect is worth calling out, because it surprises people: More HBM about means less ordinary DRAM to go round. Making more HBM uses up wafer capacity that would otherwise turn out ordinary DRAM bits, so serving the accelerator market squeezes the desktop memory market. That one coefficient is why an HBM shortage makes accelerators far dearer and desktop memory a little cheaper.
| Driver | AI exposure | Elasticity | Energy | Commodity | Capacity | HBM | Efficiency | Inventory | Lead time | Substitution | Uncertainty |
|---|---|---|---|---|---|---|---|---|---|---|---|
| AI accelerators | 0.92 | 0.55 | 0.05 | 0.06 | 0.50 | 0.55 | 0.35 | 1.5m | 9m | 0.15 | ±12% |
| DRAM memory | 0.62 | 0.35 | 0.12 | 0.08 | 0.65 | -0.40 | 0.15 | 2.5m | 14m | 0.10 | ±16% |
| Consumer GPUs | 0.42 | 0.60 | 0.05 | 0.10 | 0.45 | -0.20 | 0.20 | 3.0m | 7m | 0.30 | ±14% |
| Processors (CPU) | 0.28 | 0.80 | 0.06 | 0.07 | 0.40 | 0.00 | 0.15 | 4.0m | 6m | 0.35 | ±10% |
| NAND storage | 0.45 | 0.55 | 0.10 | 0.08 | 0.40 | -0.12 | 0.08 | 3.5m | 11m | 0.25 | ±15% |
| Network adapters | 0.78 | 0.65 | 0.05 | 0.12 | 0.30 | 0.00 | 0.10 | 2.5m | 6m | 0.20 | ±13% |
| Optical transceivers | 0.85 | 0.50 | 0.06 | 0.18 | 0.20 | 0.00 | 0.05 | 2.0m | 7m | 0.20 | ±15% |
| Switching | 0.72 | 0.70 | 0.05 | 0.12 | 0.28 | 0.00 | 0.08 | 3.0m | 6m | 0.30 | ±12% |
| UPS & switchgear | 0.60 | 0.40 | 0.08 | 0.35 | 0.05 | 0.00 | 0.30 | 1.5m | 15m | 0.15 | ±13% |
| Transformers & interconnection | 0.48 | 0.25 | 0.10 | 0.45 | 0.02 | 0.00 | 0.30 | 1.0m | 26m | 0.08 | ±15% |
| Construction & shell | 0.35 | 0.85 | 0.14 | 0.40 | 0.00 | 0.00 | 0.15 | 2.0m | 12m | 0.25 | ±12% |
Amber values are below zero on purpose. These are judgement calls, picked so the model behaves the way real, written-up events behaved. None of them is fitted by regression.
Sensitivity is computed, not asserted. The order of which input matters most is worked out, not written down. Each lever is nudged by 10% of its own range, and we measure what that does to the pressure index. So the order stays right when the coefficients change, and it shifts as you move the other levers, because it genuinely depends on where you are.
The things this app cannot do
Every price level here is illustrative. The structure, the links between things and the order they fall in are the product. The numbers are there to show how it works.
The model has no view on what will happen. It answers an if: if these inputs each shifted this much, what would the model then say. Nothing here has been checked against how things really turned out.
We chose them so the model would behave the way we know things behave. Someone else would choose other numbers and get other answers. The order things fall in would hold up better than the levels.
Nothing like the Taiwan scenario has ever happened before. Read it as an order of who is most exposed, and not as a guess at a price. That is also why its answers come back with low confidence.
Good enough to put the materials in order of which matter most for a build. Not good enough to check a supply chain, or to back a decision to buy.
Revenue share and pure-play score are both estimates. We work them out from what a company tells the public, using a set of rules that we have written down. They are not numbers the company reports, and they are not a recommendation.
For a lot of these, the real problem sits after the mine and not at it. The bottleneck notes cover that where the dial does not.
The money picker is there so you can read the numbers in the money you use every day. It is not a live feed of exchange rates, and it never updates.
Named even where we are not yet joined to it, so every figure says who it should come from
| Source | Publisher | Frequency | Status | Used for |
|---|---|---|---|---|
| Mineral Commodity Summaries | U.S. Geological Survey | Annual | Reference | Global mine production, reported reserves and producing-country shares for metals and critical minerals. |
| Commodity Markets ('Pink Sheet') | World Bank | Monthly | Adapter ready | Monthly benchmark prices for copper, aluminium, tin and energy. |
| Non-ferrous metal reference prices | London Metal Exchange | Daily | Reference | Cash settlement prices for copper, aluminium and tin. |
| Consumer Price Index (CPI-U, all items) | U.S. Bureau of Labor Statistics | Monthly | Adapter ready | Converting nominal prices to constant-dollar (inflation-adjusted) prices. |
| Electric Power Monthly | U.S. Energy Information Administration | Monthly | Adapter ready | Industrial electricity prices used as a regional default in Build Lab. |
| Energy and AI | International Energy Agency | Annual | Reference | Order-of-magnitude anchors for global data-centre electricity demand and its growth range. |
| Electricity Data Explorer | Ember | Monthly | Adapter ready | Grid carbon-intensity factors by region. |
| Company filings and exchange listings | Issuer investor-relations disclosures | Quarterly | Reference | Company identity, listing venue, headquarters, reported segments and stated dependencies. |
| Equity price history | Configurable market-data provider | Daily | Adapter ready | Stock price history shown beside component and resource indexes. |
| Retail component price panel | Configurable retail/marketplace feed | Daily | Adapter ready | Street prices for the representative product baskets behind each component index. |
| Published benchmark suites | Independent benchmark publishers | Quarterly | Reference | Performance scores used as the denominator in capability-adjusted pricing. |
| Compute Atlas internal model | Compute Atlas | Monthly | Connected | Illustrative series shapes, exposure scores, build-cost assumptions and the scenario sensitivity model. |
Adapter ready means an adapter already sits in lib/adapters/ with the right shape and a working fallback. It still needs a key and the code that makes the request. Reference means the source shaped the shipped estimates but no code reads it. An adapter never fails over a missing key, and never passes made-up data off as live. It hands back the bundled dataset with the status dropped to illustrative, which is what the badges across the app show.