Compare running your own model against paying per token.

Round synthetic numbers chosen to make the arithmetic legible. They are not a market survey, a quotation, or anything KyperX has paid or charged.

• Currency — AUD
• Requests — 1200000 a month
• Average input tokens — 2400 per request
• Average output tokens — 400 per request
• API input price — 2.5 per million tokens
• API output price — 10 per million tokens
• Hardware capital cost — 420000 one-off
• Useful life — 4 years
• Total IT draw at planning load — 24 kW
• Average load factor — 55 %
• Power usage effectiveness — 1.4 PUE
• Electricity price — 0.21 per kWh
• Rack, hosting or space cost — 3200 a month
• Software and support — 36000 a year
• Operations effort — 0.4 FTE
• Loaded annual cost per FTE — 185000 a year
• Other annual cost — 12000 a year
• Low scenario volume — 50 % of planned
• High scenario volume — 200 % of planned
• Low scenario load factor — 35 %
• High scenario load factor — 80 %

Annual API cost

AUD 144,000

a year

Annual owned cost

AUD 299,396

a year

First-year cash outlay

AUD 614,396

the full capital cost plus a year of operating cost — a different question

Annual difference

AUD -155,396

a year

Break-even volume

2,494,965

requests a month

Assumptions register

Every figure below is one the reader supplied, not one this page chose. They travel with the result so a reviewer can argue with them.

• Useful life — 4 years
• Average load factor — 55 %
• Power usage effectiveness — 1.4 PUE
• Operations effort — 0.4 FTE
• Low scenario volume — 50 % of planned
• High scenario volume — 200 % of planned
• Low scenario load factor — 35 %
• High scenario load factor — 80 %

Information gaps

Nothing in this example is missing or self-contradictory.

Annualised cost and cash outlay are different questions

The costs most often missing from a self-hosting comparison

1. Facility overhead. Cooling, distribution losses and everything else the site consumes to keep the equipment running. That is what PUE captures, and omitting it is the single largest energy error.
2. Operations labour. Someone patches it, watches it, and is woken when it stops. Even a fraction of an FTE at a loaded cost is usually larger than the electricity.
3. Idle time. Owned hardware costs the same at three per cent utilisation as at ninety. The load factor input is where that shows up, and a peaky workload is the usual argument against owning.
4. Serving, monitoring and support software. Rarely free at production scale, and rarely in the first version of the spreadsheet.
5. Refresh, not just depreciation. Useful life decides the annualised figure. What happens at the end of it is a second capital decision.
6. Evaluation effort. Every model or stack change requires re-evaluating against your own material. The API route does not remove that either; it changes who triggers it and when you find out.
7. The capability question. A self-hosted open-weight model may not do the task as well as the hosted model you are comparing against. This tool compares cost, not capability, and a cheaper system that does not work is not cheaper.

1. It does not establish that the hardware can serve the load. Cost and throughput are separate questions, and a cost case built on hardware that cannot meet peak demand is worthless. That is the capacity planner, and it should be run first.
2. It carries no prices. No GPU price, no electricity tariff, no per-token rate. Everything commercial is yours, and the tool has no opinion about whether your figures are plausible.
3. It compares cost, not capability or quality. Two options with the same annual cost may not do the same job.
4. It is a single-period model. Constant volume, constant prices, straight-line annualisation. No discounting, no cost of capital, no tax effect, no ramp, no price escalation.
5. The scenarios are yours. The low and high cases apply the percentages you enter; they are not a forecast and not a probability.
6. It ignores the non-cost reasons for either option. Residency, retention, model control and exit frequently decide this before cost does — see the deployment path finder.

• Annualised cost — capital cost divided by useful life, plus operating cost. The figure comparable with an annual API bill.
• First-year cash outlay — the whole capital purchase plus a year of operating cost. A different question, usually asked by a different person.
• PUE — power usage effectiveness: facility input power divided by IT load. A PUE of 1.4 means the site draws 1.4 kW for every 1 kW the equipment uses.
• Load factor — average draw as a share of the planning load across the year. The main lever on energy cost, and on whether owning makes sense.
• Break-even volume — the monthly request count at which annual API cost equals annual owned cost, at your current token mix.
• Token — the unit models are priced in. Output tokens usually cost several times input tokens, which is why the two prices are separate inputs.