| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
| Name | Name | Last commit date | ||
|---|---|---|---|---|
A vision for the compute crunch that does not require pouring any more concrete.
Read the vision → · Explore the prototypes → · Read the arithmetic →
The United States is in the middle of a data center buildout without precedent, and it is running into a wall that money cannot move.
US data centers drew 176 TWh in 2023. Lawrence Berkeley National Laboratory now projects 521–843 TWh in 2030, with a 649 TWh reference case. That capacity is being sited next to housing, drawing on local water and local grids, and increasingly meeting organised local opposition.
Power delivery is increasingly a schedule constraint. In April 2026, ERCOT reported 410 GW of prospective large loads, about 87% associated with data centers. That queue is not a forecast of what will be built, but it shows how much demand is converging on the same connection process.
So the industry is buying accelerators it cannot energize. A megawatt of idle silicon loses about $520,833 in value every month it waits.
There are 82.5 million single-family detached homes in the United States. Roughly 60% are passed by fiber. Each has a meter and an electrical service. That does not establish five kilowatts of spare capacity: panel condition, other loads, distribution equipment, permits and utility approval must be screened.
HEARTH asks what happens if you put a 5 kW compute node — the electrical size of an EV charger — behind an existing residential meter, pay the household for hosting it, and schedule a few million of them as one fabric.
The proposed hosting contract asks the household to buy nothing and take no loan. It assumes a dedicated 240-volt circuit, a revenue share and operator ownership. Installation time, heat reuse, insurance and transfer to a later owner are hypotheses for a field pilot—not promises.
This is a feasibility study, not a manifesto. It was run five times and two of those passes concluded the idea does not work. Both corrections turned out to be the most useful findings, and both are published here in full.
| Pass | Basis | Verdict |
|---|---|---|
| 1 | Facility shell only | Home wins by $0.0590 / IT-kWh |
| 2 | Accelerators included at 70% duty | Home loses by $0.2143 |
| 3 | Quoted GPU prices, venue-appropriate silicon | Home wins 2.4–4.6× |
| 4 | Production batch sizes, 32B model | Home loses 1.16–1.80× |
| 5 | Swept across model size | Home wins 0.49× at 8B |
The answer is that it is a small-model inference fleet. That is the specification, not a hedge:
| Served model | Best home | Best datacenter | Ratio |
|---|---|---|---|
| 8B | $0.012869 / Mtok | $0.026000 | 0.49× |
| 32B | $0.043803 | $0.037723 | 1.16× |
| 70B | excluded by single-GPU assumption | $0.075400 | — |
Three thresholds decide everything. The point estimates are illustration; these are the result:
Four million nodes cannot be pooled to run one enormous model — a four-stage pipeline across houses yields 5.67 to 11.74 tokens per second, and training all-reduce moves 28 GB per step. The fleet is wide, not deep, and width is the product:
220,519 homes over 66 months, behind four gates, each buying the answer to one question.
| Gate | Months | Homes | Capital at risk | Question it answers |
|---|---|---|---|---|
| G0 | 1–9 | 250 | $5M | Can a crew install to spec, and does the transformer tolerate it? |
| G1 | 10–24 | 5,000 | $102M | Will households sign at the modelled acquisition cost? |
| G2 | 25–42 | 40,000 | $822M | Will anyone buy 8B inference at this price? |
| G3 | 43–66 | 220,519 | $4.62B | Does it work at national scale? |
That table also shows a flaw the study found in its own plan: $822M is committed before the question most likely to kill the programme is answered, and that question is the cheapest of all to test. It should be first.
Named and priced, because a study that hides its failure modes is just a slower way of finding them.
No figure here came from a spreadsheet. Every quantity is computed as an exact rational by agent-calc, then reported with both its exact fraction and a decimal.
git clone https://github.com/copyleftdev/hearth
cd hearth
for i in "" 2 3 4 5 6 7 8 9 10 11 12; do python3 calc/model$i.py; done| Path | What is in it |
|---|---|
| data/*.json | Every input, with unit and citation |
| calc/kernel.py | Exact-arithmetic bindings to agent-calc |
| calc/model*.py | Twelve modelling stages, each building on the last |
| calc/results*.json | Every computed quantity — exact rational plus decimal |
| docs/HEARTH.md | The written report |
| site/ | The published site |
| build.py | Builds site/ from the report fragments |
Three generalisable lessons, each of which reversed a conclusion here:
A feasibility study, published for scrutiny. Nothing has been built. The numbers are as good as their inputs, which are cited in data/, and the thresholds matter more than the point estimates.
Corrections are welcome and interesting. If a number here is wrong, the model is small enough to show exactly where, and an issue is the fastest way to say so.
MIT — see LICENSE. Use the model, the data and the arguments freely.
| Back | FazBrowse Home | New Git URL |