The four usual reasons, one by one
| Reason | Verdict | Why |
|---|---|---|
| Privacy | Partly true | True of the model call. Not true of the whole system. |
| Cost | A myth for a single user | The break-even threshold runs to billions of tokens a year. |
| No restrictions | True, but not free | No limits and no content filter — but no frontier quality either. |
| Offline operation | True, and needs no qualifying | A local model runs on a plane too. |
And the fifth, which the usual four leave out: the model does not vanish from under you.
This is not theory. One large provider's own deprecation page lists these dates for 2026 and 2027:
| What is going away | Date |
|---|---|
| An earlier assistant API | 26 August 2026 |
| Several fine-tuned models | 23 October 2026 |
| The agent-building surface and the evaluation platform | 30 November 2026 |
| The self-service fine-tuning platform | 6 January 2027 |
A model file you have downloaded will still be the same file in 2027. This is the least clichéd argument for running locally, and it can be backed end to end from primary sources. Handling a deprecation is what the model deprecation article walks through in detail.
The money: the price of a token is watts divided by speed
[Own calculation] The formula is trivial, and yet it is written down almost nowhere:
The electricity cost of generating one million tokens:
kWh / 1M tokens = P [watts] / (3.6 × TPS)
P = the machine's average draw while generating
TPS = tokens per second, the measured speed
I checked it against an independent measurement taken at the wall socket: at 94 W and 74 tokens per second the formula gives 0.353 kWh per million tokens — exactly what the measurement reported.
The usable lesson in one sentence: the price of a token divides watts by speed. Which is why a slow small model can be more expensive than a fast large one — the most counter-intuitive and most useful finding in the whole subject.
Measured examples, for four hardware-and-model pairs:
| Machine and model | Watts | Tokens/s | kWh / 1M | In Hungary | At the EU average |
|---|---|---|---|---|---|
| Powerful desktop, sparse large model | 94 | 74 | 0.353 | $0.042 | $0.111 |
| The same, medium dense model | 138 | 21.5 | 1.783 | $0.210 | $0.563 |
| GPU PC, tiny model | 154 | 136 | 0.315 | $0.037 | $0.099 |
| The same, 27-billion-parameter model | 283 | 25.4 | 3.095 | $0.365 | $0.977 |
Electricity: this is where country differences are largest
According to the EU statistical office's figures for the second half of 2025, household electricity prices look like this:
| EUR / kWh | |
|---|---|
| Hungary (the cheapest in the EU) | 0.1082 |
| Spain | 0.2669 |
| EU average | 0.2896 |
| Germany | 0.3869 |
| Ireland (the most expensive) | 0.4042 |
[Own calculation] The German price is 3.58 times the Hungarian one, the Spanish one 2.47 times. The same machine, running the same model, can therefore show a threefold difference on the electricity bill depending on the country. Open the one that applies to you:
Hungary — cheapest household electricity, and among the most expensive industrial
On household prices Hungary is first in the EU, at 0.1082 euro per kWh. The "it will eat electricity" objection is therefore weaker there than anywhere else in the Union: for local running, hardware amortisation dominates, not the power bill.
There is a twist, though, that most comparisons leave out. On industrial consumer prices the same ranking flips: in the 500–1,999 MWh annual band Hungary sits at 0.2132 euro per kWh, 23rd out of 27, 16% above the EU average.
What that means in practice: for a model running on a desktop machine, the cheap Hungarian household price is a real advantage. For a machine in a rack on a business tariff it disappears — there the calculation has to be redone at the industrial price, and the break-even threshold for local running moves a long way up.
Spain — exactly the other way round: mid-table at home, near the top industrially
On household prices Spain is the 16th cheapest of 27, at 0.2669 euro per kWh — roughly 8% below the EU average, but two and a half times the Hungarian price. On a home machine, electricity is a real line item there, not a rounding error.
As an industrial consumer, however, Spain is the fourth cheapest in the Union, at 0.1324 euro per kWh: 28% below the EU average, and 0.62 times the Hungarian industrial price. Same machine, same model: on a business tariff, electricity in Spain costs two thirds of what it costs in Hungary.
What that means in practice: if the question is the office desktop, the Spanish calculation sits closer to the EU average. If the question is a small server or a dedicated machine on a business contract, Spain is one of the best places in the Union to run locally — the exact opposite of what the household ranking would suggest.
The break-even threshold
[Own calculation] The formula:
hardware price / lifetime_years
N_threshold = ─────────────────────────────────────
API_price − local_electricity_cost
(all per 1 million tokens)
Assumptions that have to be written out, because without them the number means nothing: a 3:1 input-to-output ratio (typical chat and agent load), four-year straight-line amortisation, the machine used exclusively for AI, and no internet, no floor space and none of your time included.
Case "A" — a $3,500 machine, EU-average electricity, $875 of annual amortisation:
| What you compare it to | Threshold (million tokens/year) | That much continuous running |
|---|---|---|
| Cheapest API tier ($0.45) | 2,581 | 133 days/year |
| Mid-range ($1.50) | 630 | 32 days/year |
| Entry-level frontier ($2.00) | 463 | 24 days/year |
| Mid frontier ($4.00) | 225 | 12 days/year |
Case "B" — an entry-level GPU PC, $1,658 all in, $415 of annual amortisation. Here the cheaper Hungarian electricity pushes the threshold down, since the marginal cost is lower:
| What you compare it to | Threshold at the EU average | Threshold in Hungary |
|---|---|---|
| Cheapest API tier | 1,206 | 1,012 |
| Mid-range | 298 | 284 |
Three conclusions:
- Against the cheapest API tier, a private individual essentially never recoups it. 2.6 billion tokens a year means the machine generates continuously for a third of the year. Even someone working eight hours a day with agents does not get there.
- Against the mid-range, a heavy user does recoup it. Three hundred to six hundred and thirty million tokens a year, that is 16 to 32 days of continuous running — realistic for a permanently running agent.
- Against the frontier tier it pays back immediately — except that a local model cannot do frontier-grade work.
The third point is the trap, and it is worth saying out loud: the volume at which local running pays off is exactly the volume at which the local model is no longer good enough.
Three cases the calculation does not see
1. You already own the hardware. If the machine is your work machine anyway, the amortisation does not belong to the AI. In that case only the marginal electricity cost counts — and that is $0.04 per million tokens in Hungary and $0.10 in Spain, against the cheapest API's $0.45. Between a fourfold and a tenfold difference, and this is the one setup in which local running is unambiguously cheaper.
2. Several people use it. Under concurrent requests, with the right serving software, throughput jumps an order of magnitude. In one measurement, on the same hardware with the same model: 793 tokens/s under parallel load with the proper server, against 41 tokens/s with a single-user runner — while for one user the two are practically identical (130-180 tokens/s). For a team, then, the volume each person has to contribute to reach the threshold drops by the number of people using it.
3. Idle draw, on the other hand, works against you. [Own calculation] A 70-watt desktop machine left switched on burns 613 kWh a year doing nothing — $194 at the EU average, $72 in Hungary, $179 in Spain, $259 in Germany, every year. Well-specified machines idle at a fraction of that (6-9 watts according to the manufacturer), where the same figure comes to between $6 and $33 a year.
The idle draw of an always-on desktop machine can eat the entire saving on its own for a medium user.
What "it's free" leaves out
Five items the calculation has to include:
1. IDLE POWER DRAW
613 kWh a year for a 70 W machine left running.
2. THE MODEL STAYS LOADED
One runner keeps it in memory for 5 minutes by
default, another for as long as 60 minutes.
That is not power but RAM - it drives sizing.
3. HARDWARE AMORTISATION
$3,500 / 4 years = $875 a year.
A subscription is $240 a year.
4. HARDWARE PRICES ARE NOT ON YOUR SIDE
Driven by data-centre memory demand, the street
price of top-end graphics cards was two to two
and a half times the manufacturer's recommended
price at the time of writing.
5. YOUR OWN TIME
Setting it up, picking a model and debugging is
measured in hours, and in the calculation above
it counts as ZERO.
Where local running is NOT more private
This part matters because most people start precisely for privacy reasons.
What is true: good runners are reachable only from the machine itself by default, the models sit on your disk, and the provider does not see your prompts.
What does not follow from that:
1. A model file is not data, it is code. In early 2025 two malicious models were found on a popular model-sharing site. The trick: they swapped the compression mode of the file format and put the harmful part at the front of the file — the security checker validated before it inspected, so the code ran before the scanner reached it. The payload was a connection opening to an external address.
2. The model loader is software too, and it has bugs. In the processor for the most widespread local model format, serious vulnerabilities were found in 2024, 2025 and 2026 alike — including ones that could lead to code execution, and that affect every runner built on it.
3. "We do not see your prompt" is not the same as "we send nothing". At one of the most widely used runners, the public question about telemetry has been open since February 2024.
4. The name is no guarantee. In 2026 the same product name often means two things: a local runner and a cloud service. Only one of them is local.
The correct summary: local running makes the model call more private. It does not make a system private. Keeping data on your own premises is covered at length by the private AI piece.
How much weaker is it?
According to an analyst firm's measurement, since January 2026 the best open-weight models have been an average of four months behind the closed frontier.
Without two qualifications that number is misleading. First: open weights are not the same as runs-on-a-laptop — the open models topping the list are in the hundreds of billions of parameters. Second: the gap is task-dependent — small on a single-turn tool call, an order of magnitude on a multi-turn agent task.
On top of that, a small model fine-tuned for a narrow task can beat one a hundred times its size — the fine-tuning payback post brings measurements on that. There is a serious counter-argument too. According to a researchers' position paper, serving models under ten billion parameters on consumer devices is 10 to 30 times cheaper — in latency, in energy and in computation alike — and a significant share of agent tasks does not need a frontier model.
(That is a position paper, not a measurement. But the idea is usable.)
What to take away
The strongest argument for running locally is neither cost nor, primarily, privacy — it is that the model does not vanish from under you, and next to a provider's deprecation calendar that is a concrete, dated risk.
On cost, three numbers: the price of a token is watts divided by speed; the threshold against the cheapest API tier is 2.6 billion tokens a year; and if you already own the hardware, the marginal cost is a tenth of the API's.
So the right question is not "local or cloud" but which call you put where. The high-volume, simple, sensitive-data call can run locally; the heavy, multi-turn, accuracy-critical work cannot. Hardware is the subject of the hardware for local AI article, and the runners are compared in the local AI runners round-up, one by one.