Calculators
Open models for the numbers that decide an AI build — one project, worked end to end: size the cluster, price the build, cost the runtime, then see if the finance closes. Defaults trace to the numbers register (current as of 2026-08); change them to your case, then save, share a permalink, or export to CSV.
Size it
Cluster sizing — model to megawatts
The MW figure is for energy and cost, at nominal TDP. Electrical design uses your rack's facility design power and transient peak (GB300 NVL72: 135 kW nominal, up to 142 kW facility basis, 155 kW peak) — three different numbers, never interchangeable → Ch 7.2. VRAM sets only a minimum. Enter a replica size you have tested for your model, runtime, hardware, context and batch size; it need not be a power of two. Purchase quantum is the smallest unit you can buy or contract, and does not follow from rack density. Facility design power follows installed units, while rental cost follows the active fractional fleet. At long context the KV cache can dominate VRAM → Ch 9.7.
Worked decision — stated assumptions
All ledger inputs are assumed teaching values chosen to exercise this chapter’s method; they are not market quotes, OEM performance claims or operating records. Arithmetic uses the full entered precision.
| Input | Value |
|---|---|
| Model size | 70 B params |
| Bytes / param | 1 bytes |
| KV cache / token | 330 KB |
| Context length | 32000 tok |
| Concurrent requests / replica | 64 requests |
| Activation + framework overhead | 15 % |
| HBM per GPU | 288 GB |
| Peak demand | 50000 tok/s |
| Throughput / replica | 11200 tok/s |
| Serving capacity | 70 % |
| GPUs / replica | 8 GPUs |
| GPUs / rack | 72 GPUs |
| Purchase quantum | 72 GPUs |
| GPU TDP | 1400 W |
| Host overhead | 1.3393 × GPU TDP |
| PUE | 1.15 ratio |
| Underwriting rental rate | 18 $/GPU-hr |
Illustrative purchase decision: assume a 70-billion-parameter model at one byte per parameter, 330 KB of KV cache per token, 32,000-token context, 64 concurrent requests and 15% framework overhead. Memory is (70 + 330 × 32,000 × 64 / 1,000,000) × 1.15 = about 858 GB per replica. Assume 288 GB per GPU and an eight-GPU replica you have tested: the three-GPU memory floor does not replace that qualification.
Assume 50,000 output tokens/s peak demand, 11,200 tokens/s per replica and 70% serving capacity. Round 50,000 / (11,200 × 0.70) up to seven replicas: 56 active GPUs. A 72-GPU purchase unit gives 72 installed GPUs, 16 stranded slots and one 72-GPU rack. At an assumed 135 kW nominal rack input and PUE 1.15, the nominal facility screen is about 155 kW. Fractional rental at an assumed $18/GPU-hour costs $1,008/hour for the active fleet.
Assume a $1,100/hour active-fleet rental allowance. The seven-replica case fits. Above 7 × 11,200 × 0.70 = 54,880 output tokens/s, demand needs an eighth replica: at 60,000 tokens/s, 64 active GPUs cost $1,152/hour and exceed the allowance, while the same 72-GPU purchase unit still fits. Acquire the exact serving qualification before committing the purchase.
Guide derivation. Method and handoff: Chapter 1.7 — The Requirements-and-Consequences Matrix.
Rack cooling check
| Path | Today (135 kW) | Roadmap (228 kW) |
|---|---|---|
| Air only | Not applicable: 121.5 kW of this rack's heat must go to liquid | Not applicable: 205.2 kW of this rack's heat must go to liquid |
| Air + rear door | Not applicable: 121.5 kW of this rack's heat must go to liquid | Not applicable: 205.2 kW of this rack's heat must go to liquid |
| Direct liquid + room air | Works: liquid 121.5 kW, room 13.5 kW of its 20 kW | Fails: residual air 22.8 kW exceeds the room's 20 kW |
| Direct liquid + rear door | Not applicable: no rear door entered | Not applicable: no rear door entered |
How this works: liquid heat is rack power times the liquid share, and the room's air takes the rest, through a rear door if you have one. The coolant reaching the rack is the facility water plus the CDU approach, and it must not be warmer than the rack allows → Ch 5.6. Flow uses OCP's PG25 guideline of 1.25–2.0 L/min per kW of liquid heat, which keeps the coolant rise near 7.5–12 °C → Ch 5.11. This is a screen: before you buy, get the rack maker's flow, pressure and fluid limits and check the room's airflow at the rack → Ch 5.4, Ch 5.3.
Worked decision — stated assumptions
All ledger inputs are assumed teaching values chosen to exercise this chapter’s method; they are not market quotes, OEM performance claims or operating records. Arithmetic uses the full entered precision.
| Input | Value |
|---|---|
| Rack power | 132 kW/rack |
| Heat captured to liquid | 87 % of rack heat |
| Room air capacity per rack | 20 kW/rack |
| Rear-door capacity | 0 kW/rack |
| Facility water to the CDU, hottest day | 30 °C |
| CDU approach | 5 K |
| Warmest coolant the rack accepts | 45 °C |
| Roadmap rack power | 132 kW/rack |
| Roadmap heat captured to liquid | 87 % of rack heat |
Decide whether a GB200 NVL72-class rack fits this hall. Assume 132 kW per rack with 87% of the heat going to liquid (HPE's split), a room that can take 20 kW of air per rack, 30 °C facility water on the hottest day, a CDU with a 5 K approach and a rack that accepts coolant up to 45 °C. Liquid heat is 132 × 0.87 = 114.84 kW, and the room takes the other 17.16 kW, inside its 20 kW. The coolant reaches the rack at 30 + 5 = 35 °C, under the 45 °C limit, so direct liquid with room air works. At OCP's 1.25–2.0 L/min per kW, the CDU must deliver about 144–230 L/min to this rack.
Raise the hottest-day facility water to 41 °C: the coolant arrives at 46 °C and the liquid path fails. The crossover is 40 °C facility water at a 5 K approach; a CDU with a 3 K approach moves it to 42 °C. Get the rack maker's flow curve and pressure limits before you order.
Primary method: ASHRAE Handbook (2023), Applications ch. 20 — thermal paths and CDUs. Method and handoff: Chapter 5.6 — CDUs & the Secondary Loop.
Build it
Build cost — capex per megawatt
Benchmarks: JLL global-average shell/core ≈ $11.3M/MW (50 MW single-tenant, air-cooled; liquid +10%); Epoch's 1 GW model runs facility+land+utility ~$11.8M/MW and network ~$4.9M/MW, with servers ~$21.2M/MW on top → ~$38B/GW up-front. Electrical dominates the facility split → Ch 2.5, Ch 1.8.
Scope & how the benchmarks reconcile
This models construction-period capex excluding the server fleet. The benchmarks, reconciled on Epoch AI's May-2026 1 GW model: $11.3M/MW is JLL's global-average shell-and-core (air-cooled, 50 MW single-tenant; liquid cooling adds ~10%); Epoch's facility + land + utility works line is ~$11.8M/MW and its network and cluster infrastructure ~$4.9M/MW; servers — GPUs included — add ~$21.2M/MW, which is how a 1 GW campus reaches ~$38B up-front. Electrical systems are 45–70% of construction cost (as of 2026 → register). The server fleet is deliberately outside this calculator — the TCO model owns it, and adding it here would double-count.
Worked decision — stated assumptions
All ledger inputs are assumed teaching values chosen to exercise this chapter’s method; they are not market quotes, OEM performance claims or operating records. Arithmetic uses the full entered precision.
| Input | Value |
|---|---|
| IT capacity | 10 MW |
| Facility, land & utility works | 10 $M/MW |
| Network & cluster infra (excl. servers) | 4 $M/MW |
| Project-priced facility premium | 20 % |
| Regional multiplier | 1.1 × |
Illustrative capital scope: assume 10 MW of usable IT capacity, facility/land/utility works at $10 million per MW, network infrastructure at $4 million per MW, a quoted 20% facility premium and a 1.10 regional factor. Facility cost is 10 × 10 × 1.20 × 1.10 = $132 million. Network cost is 10 × 4 × 1.10 = $44 million. The total is $176 million, or $17.60 per IT watt, excluding servers.
An illustrative $180 million allowance for those same two scopes passes with $4 million remaining. Raising only the facility premium to 25% raises the total to $181.5 million and fails. The topology drawing and supplier scope establish the premium; the reliability requirement buttons do not price it. Add the server purchase once in the shared program capital model.
The facility-premium crossover is 23.6%: (180 − 44) / (10 × 10 × 1.10) − 1. Above it, reduce scope or raise the same-scope capital allowance.
Guide derivation. Method and handoff: Chapter 2.5 — Project Finance & Capital Formation (Mechanics).
Site-scoring playbook
Kill gates come first: power or interconnect at ≤2, or water or land/zoning at ≤1, disqualifies a site no matter how the weighted score averages out. This is an illustrative weighting template: power availability carries the most weight, and the 0–10 scores are your judgment calls, so record the evidence behind each one. Adjust the weights and add a latency gate for inference workloads before ranking real candidates → Ch 3.13.
Worked decision — stated assumptions
All ledger inputs are assumed teaching values chosen to exercise this chapter’s method; they are not market quotes, OEM performance claims or operating records. Arithmetic uses the full entered precision.
| Input | Value |
|---|---|
| Power availability / speed-to-MW | 7 /10 |
| Interconnect & permitting | 6 /10 |
| Power price / PPA | 6 /10 |
| Land & expandability | 7 /10 |
| Water & climate | 6 /10 |
| Incentives / tax | 5 /10 |
Decide whether candidate A merits the next diligence spend. Assume judgment scores of 7, 6, 6, 7, 6 and 5 for power, interconnect, price, land, water and incentives. The displayed rubric weights those axes 30%, 20%, 15%, 15%, 10% and 10%. These are an illustrative investment preference, not executed agreements or measurements. The weighted trace is (7×30 + 6×20 + 6×15 + 7×15 + 6×10 + 5×10) / 10 = 63.5/100: “Workable with mitigation.”
Advance A to evidence collection under this rubric; hold a site commitment until the service date, land rights, thermal/water design and workload latency are settled (Chapter 3.13). Change the power score to 2: the score becomes 48.5 and the power kill gate disqualifies A. The crossover is power ≤2, regardless of incentives. Reallocate diligence to a candidate with a viable power path.
Guide derivation. Method and handoff: Chapter 3.13 — Market Clusters & the Site-Scoring Playbook.
Redundancy options compared
N = 800 kW ÷ 200 kW, rounded up = 4 modules.
| Option | Modules | × N | Load per module | Rides through a module failure | Service a module live | Service a path live | Survives losing a path | Survives a failure during service | Modelled downtime |
|---|---|---|---|---|---|---|---|---|---|
| N | 4 | 1× | 100% | no | no | no | no | no | 140 h a year |
| N+1 | 5 | 1.25× | 80% | yes | yes | no | no | no | 2.8 h a year |
| 2N | 8 | 2× | 50% | yes | yes | yes | yes | no | 2.2 h a year |
| 2(N+1) | 10 | 2.5× | 40% | yes | yes | yes | yes | yes | 3 s a year |
| 3N/2 | 6 | 1.5× | 67% | yes | yes | yes | yes | no | 1.7 h a year |
| 4N/3 | 8 | 2× | 50% | yes | yes | yes | yes | no | 3.3 h a year |
Concurrent maintainability means you can service any module or path with the load held; it needs a second path, so N+1 on one shared path does not qualify (losing that bus drops the load) → Ch 0.5. Module count tracks equipment cost only: distribution, transfer switches and controls are extra, and 3N/2 and 4N/3 need more of them → Ch 12.1. The downtime column is a screening model: modules fail independently at your rate, each path or block has one repair crew, the paths share nothing and every transfer works. Shared buses, controls and common causes usually set real downtime, so read these hours as a floor → Ch 12.5.
Worked decision — stated assumptions
All ledger inputs are assumed teaching values chosen to exercise this chapter’s method; they are not market quotes, OEM performance claims or operating records. Arithmetic uses the full entered precision.
| Input | Value |
|---|---|
| Load to protect | 800 kW |
| Module size | 200 kW |
| Failures per module per year | 4.38 per yr |
| Repair time per failure | 8 h |
| Distribution paths for N and N+1 | one |
| Concurrent maintainability required? | yes |
| Ride through one module failure? | yes |
Decide how much plant to buy for an 800 kW load from 200 kW modules when the owner wants both concurrent maintainability and ride-through of one module failure. N is 800 ÷ 200 = 4 modules. With one shared distribution path, N+1 rides through a module failure but cannot keep the load up while that path is serviced, so it fails the maintainability requirement. Of the options that meet both, 3N/2 needs the fewest modules: three blocks of two, 6 modules or 1.5× N, each module 67% loaded. 2N needs 8 and 2(N+1) needs 10. At Chapter 12.5's illustrative power-path rates (one failure per 2,000 hours, 8 h repair), 3N/2 models about 1.7 hours of downtime a year before shared causes.
Add a standby distribution path for maintenance: N+1 now meets both requirements with 5 modules, 1.25× N. The trade is a second path and its transfer equipment against one fewer module, so price both before you choose, and prove the transfer works in commissioning.
Guide derivation. Method and handoff: Chapter 0.5 — Reliability, Redundancy & Availability: The Design-Basis Primer.
Run it
Training run — time, cost, energy & CO₂
MFU and goodput compound: a 40% MFU × 90% goodput scenario yields 36% of peak theoretical FLOPs as committed training work, by the definitions you use. Treat 90% versus 96% only as an illustrative sensitivity; measure your own fleet, job and time window, then find where the lost time went before blaming checkpointing or node cordoning → Ch 12.2.
Worked decision — stated assumptions
All ledger inputs are assumed teaching values chosen to exercise this chapter’s method; they are not market quotes, OEM performance claims or operating records. Arithmetic uses the full entered precision.
| Input | Value |
|---|---|
| Model size | 70 B params |
| Training tokens | 15 T tokens |
| Peak per GPU | 2.5 PFLOPS |
| Cluster size | 10000 GPUs |
| MFU | 40 % |
| Goodput | 90 % |
| Rental rate | 18 $/GPU-hr |
| GPU TDP | 1200 W |
| Host overhead | 1.5 × GPU TDP |
| PUE | 1.2 ratio |
| Power price | 0.08 $/kWh |
| Grid carbon | 400 gCO₂/kWh |
Illustrative dense-model run: assume 70 billion parameters, 15 trillion training tokens, 10,000 GPUs at 2.5 dense PFLOPS each, 40% MFU and 90% goodput. Define MFU on productive compute time so goodput does not deduct the same lost time twice. Training work is 6 × 70 billion × 15 trillion = 6.3 × 10²⁴ FLOPs. Effective rate is 10,000 × 2.5 × 10¹⁵ × 0.40 × 0.90 = 9 × 10¹⁸ FLOP/s. The run takes 700,000 seconds, or 8.10 days and about 1.94 million GPU-hours.
At an assumed $18/GPU-hour, rental is $35 million. With assumed 1.2 kW GPU power, a 1.50 total-IT multiplier and PUE 1.20, constant-power energy is 4,200 MWh: $336,000 at $0.08/kWh and 1,680 tonnes at 400 gCO₂/kWh. Do not add electricity to rental when the rental already includes it.
The run passes an illustrative nine-day deadline. At 80% goodput it takes 9.11 days and fails. Change the training-work model for sparse or non-dense workloads; the screening formula does not qualify model placement or convergence.
The nine-day deadline requires at least 81.0% goodput: 6.3 × 10²⁴ / (10,000 × 2.5 × 10¹⁵ × 0.40 × 9 × 86,400). Below that, reserve more capacity or move the deadline.
Primary method: Kaplan et al. (2020), §2.1 — 6N training FLOPs per token. Method and handoff: Chapter 12.2 — The AI-Cluster Reliability Rethink: Goodput vs Facility Availability.
GPU TCO & cost-per-GPU-hour
The facility charge puts space and power delivery into the owned cost, so it compares like-for-like with a rental rate that already includes them; energy is billed separately at PUE. Compare against the contract rate you would actually sign, not an on-demand list price. Ownership beats that rate only above the breakeven utilization computed from your own inputs — below it a debt-financed cluster bleeds cash → Ch 1.8.
Worked decision — stated assumptions
All ledger inputs are assumed teaching values chosen to exercise this chapter’s method; they are not market quotes, OEM performance claims or operating records. Arithmetic uses the full entered precision.
| Input | Value |
|---|---|
| Server cost | 240000 $ |
| GPUs / server | 8 GPUs |
| Depreciation life | 3 yr |
| GPU TDP | 1000 W |
| Server power multiplier | 1 × GPU TDP |
| PUE | 1 ratio |
| Annual-average IT load | 100 % of nominal |
| Power price | 0.1142 $/kWh |
| Owned-use utilization | 50 % |
| Installed / active allocation | 1.25 × |
| Opex | 5 %/yr |
| Facility / colocation charge | 0 $/kW-month |
| Contract rental comparator | 4 $/GPU-hr |
Illustrative server-ownership decision: assume $30,000 per installed GPU, three-year straight-line cost allocation, $1,000 annual energy, annual opex equal to 5% of purchase cost, and 1.25 installed GPUs per active GPU. Annual cost per active GPU is (30,000 / 3 + 1,000 + 1,500) × 1.25 = $15,625. At 50% productive use, divide by 4,380 hours: $3.57 per productive GPU-hour.
An assumed like-for-like $4/hour rental crosses that cost at 15,625 / (8,760 × 4) = 44.6% utilization. Above that utilization ownership is cheaper on these costs; below it rental is. With all other inputs fixed, five- and seven-year ownership lives reduce the result to $2.43 and $1.94/hour. These are life sensitivities, not evidence that the fleet earns for those periods. The facility charge is set to zero here to isolate the server; a rental rate includes powered, cooled space, so enter the facility's capital recovery per kW-month and reconcile services outside either quote before making a full-service purchase decision.
At 40% productive use, ownership costs $4.46 per productive GPU-hour and the assumed $4 rental wins. Change productive use, not the independent electrical-load assumption.
Guide derivation. Method and handoff: Chapter 1.8 — Business Models, Economics & ROI.
Inference cost per million tokens
Compare ownership and rental on the same throughput and productive-use denominator. Owned node cost is the calendar-hour allocation of capex, energy, and opex; rented node cost is the capacity held for that hour. Prices enterprises paid for tokens fell ~$10 → ~$2.50/M in a year (Ramp spend data, Mar 2025), so underwrite inference revenue with a price-decline curve → Ch 1.8.
Worked decision — stated assumptions
All ledger inputs are assumed teaching values chosen to exercise this chapter’s method; they are not market quotes, OEM performance claims or operating records. Arithmetic uses the full entered precision.
| Input | Value |
|---|---|
| Rented node cost | 20 $/hr |
| Owned node calendar cost | 10 $/hr |
| Throughput | 1000 tok/s |
| Owned-use utilization | 50 % |
Illustrative serving case: assume one tested node produces 1,000 useful output tokens/s within the declared latency target and runs productively 50% of each paid hour. Useful output is 1,000 × 3,600 × 0.50 = 1.8 million tokens/hour. Assumed rental of $20/hour costs $11.1 per million output tokens; an assumed owned calendar cost of $10/hour costs $5.56 per million.
Against an illustrative $6 per million output-token cost allowance, ownership passes and rented capacity fails. At 40% productive use the owned cost rises to $6.94 and also fails. Keep the model, precision, prompt/output mix, batching, latency target and cost boundary identical; prompt tokens and cached tokens do not silently enter this output denominator.
The owned case crosses the $6 allowance at 46.3% productive utilization: 10 / (1,000 × 3,600 × 6 / 1,000,000).
Guide derivation. Method and handoff: Chapter 1.8 — Business Models, Economics & ROI.
Facility energy & water
Annual energy uses nominal IT power × the average load you enter × energy-weighted PUE × 8,760. Site water uses IT energy × WUE. Cooling technology does not determine PUE; use plant curves and weather/load bins → Ch 15.1.
Worked decision — stated assumptions
All ledger inputs are assumed teaching values chosen to exercise this chapter’s method; they are not market quotes, OEM performance claims or operating records. Arithmetic uses the full entered precision.
| Input | Value |
|---|---|
| Nominal installed IT power | 10 MW |
| Annual-average IT load | 60 % of nominal |
| PUE | 1.2 ratio |
| Power price | 0.08 $/kWh |
| WUE | 0.4 L/kWh IT |
Illustrative annual operating case: assume 10 MW nominal installed IT power, 60% annual-average load, energy-weighted PUE 1.20, electricity at $0.08/kWh and site-water WUE 0.40 L/kWh of IT energy. Average IT power is 6 MW; annual IT energy is 6 × 8,760 = 52,560 MWh. Facility energy is 63,072 MWh, costing $5,045,760. Site water is 52,560 × 1,000 × 0.40 = 21,024,000 litres.
Against an illustrative $5.2 million annual electricity allowance, this case passes with $154,240 remaining. The allowance crosses at 61.8% average load. Holding all other assumptions constant at 100% nominal operation raises electricity cost to $8,409,600 and fails that allowance. Productive utilization alone does not change either energy case; change the average-load assumption when the load study changes.
Guide derivation. Method and handoff: Chapter 15.1 — Efficiency Metrics: PUE, WUE, ERF, REF & the Post-PUE Metric Stack.
Fund it
Project finance — CFADS, DSCR, IRR
This is the guide's default project, and on these inputs it loses money. One NVIDIA GB300 NVL72 rack ($8.5M with its share of the building) is rented on a 3-year take-or-pay contract at $5/GPU-hour, then re-let at the market rate, which the default assumes falls 15% a year. Debt coverage is 1.55× or better while the contract runs, then falls below the 1.35× covenant in year 4, after renewal. That is the result of the sourced default inputs, not an error. To see what makes the deal work, try a longer contract (hyperscaler anchor contracts run about 5 years), a higher rate or a lower server price → Ch 1.8.
Fails your debt covenant. The fleet earns for 5 years over a 5-year hold.
The model keeps the original fleet for the whole hold. Revenue is flat for the take-or-pay contract term; at renewal the fleet re-lets at the rate the revenue-growth trend has reached since the stabilized year. Sustaining spend is a cash cost and buys no replacement fleet; tax life only sets deductions. A refresh needs a separately funded second fleet. Exit proceeds are your exit multiple times final-year EBITDA, with remaining debt repaid at exit. Taxes use illustrative straight-line depreciation, an interest shield and a zero floor, with no NOL carryforwards or working-capital model. DSCR = CFADS ÷ scheduled interest and principal during ownership; exit debt payoff is shown separately. Loan covenants use their contract definitions. One entered rate discounts both project and equity cash flows. IDC uses a simple average-balance estimate allocated evenly across construction years → Ch 2.5, Ch 1.8.
Annual cash-flow bridge
| Line | close 0 | build 1 | ops 2 | ops 3 | ops 4 | ops 5 | ops 6 |
|---|---|---|---|---|---|---|---|
| Capital expenditure | 0 | 8.504 | — | — | — | — | — |
| Debt drawn for capex | 0 | 5.102 | — | — | — | — | — |
| IDC capitalized (average-balance allocation) | 0 | 0.179 | — | — | — | — | — |
| Equity funding | 0 | 3.402 | — | — | — | — | — |
| Reserve funding | 0.644 | 0 | — | — | — | — | — |
| Revenue | — | — | 3.154 | 3.154 | 3.154 | 1.937 | 1.646 |
| Operating cost | — | — | 0.788 | 0.788 | 0.788 | 0.484 | 0.412 |
| EBITDA | — | — | 2.365 | 2.365 | 2.365 | 1.453 | 1.235 |
| Tax depreciation | — | — | 0.85 | 0.85 | 0.85 | 0.85 | 0.85 |
| Levered cash tax | — | — | 0.24 | 0.254 | 0.268 | 0.092 | 0.063 |
| Unlevered cash tax | — | — | 0.318 | 0.318 | 0.318 | 0.126 | 0.081 |
| Sustaining capital expenditure | — | — | 0.095 | 0.095 | 0.095 | 0.058 | 0.049 |
| Cash available for debt service | — | — | 2.03 | 2.017 | 2.002 | 1.302 | 1.122 |
| Interest | — | — | 0.37 | 0.305 | 0.237 | 0.163 | 0.084 |
| Principal | — | — | 0.918 | 0.983 | 1.051 | 1.125 | 1.204 |
| Debt service | — | — | 1.288 | 1.288 | 1.288 | 1.288 | 1.288 |
| Debt before exit payoff | 0 | 5.281 | 4.363 | 3.38 | 2.329 | 1.204 | 0 |
| DSCR (ratio) | — | — | 1.576 | 1.566 | 1.554 | 1.011 | 0.871 |
| Operating equity cash flow | — | — | 0.742 | 0.729 | 0.714 | 0.014 | −0.166 |
| Enterprise exit proceeds | — | — | 0 | 0 | 0 | 0 | 0 |
| Exit debt payoff | — | — | 0 | 0 | 0 | 0 | 0 |
| Reserve released | — | — | 0 | 0 | 0 | 0 | 0.644 |
| Project cash flow | 0 | −8.504 | 1.952 | 1.952 | 1.952 | 1.268 | 1.105 |
| Equity cash flow | −0.644 | −3.402 | 0.742 | 0.729 | 0.714 | 0.014 | 0.478 |
Worked decision — stated assumptions
All ledger inputs are assumed teaching values chosen to exercise this chapter’s method; they are not market quotes, OEM performance claims or operating records. Arithmetic uses the full entered precision.
| Input | Value |
|---|---|
| Total capex | 100 $M |
| Construction period | 0 yr |
| Debt / leverage | 50 % |
| Interest rate | 0 % |
| Debt term | 4 yr |
| Revenue (stabilized) | 40 $M/yr |
| Ramp to stabilized | 0 yr |
| Opex | 25 % of rev |
| Cash tax rate | 20 % |
| Tax depreciation life | 3.5 yr |
| Sustaining capex | 0 % of rev |
| Revenue growth | 0 %/yr |
| Hold period | 4 yr |
| Exit multiple | 0 × EBITDA |
| NPV discount rate / equity hurdle | 10 % |
| DSRA | 0 mo |
| Grace period | 0 yr |
| Fleet earning period | 4 yr |
| Lender's minimum DSCR | 1.5 × |
Illustrative retained-fleet case, all amounts in $M: assume capex 100, immediate operation, debt 50 at zero interest amortized over four years, revenue 40/year, opex 25% of revenue, cash tax 20%, tax depreciation over 3.5 years, no sustaining spend, no growth, four-year hold, zero exit proceeds and no reserve. Assume the original fleet supports all four earning years. These tax and earning periods are independent assumptions.
Closing equity is 50. Annual EBITDA is 30. Tax depreciation is 28.5714 in years 1–3 and 14.2857 in year 4, totaling 100. Cash tax is 0.2857 in years 1–3 and 3.1429 in year 4. Annual principal is 12.5; minimum DSCR is 26.8571 / 12.5 = about 2.15. Equity cash flow is 17.2143 in years 1–3 and 14.3571 in year 4. At a 10% hurdle, equity NPV is −50 + Σ[17.2143 / 1.1ᵗ, t=1…3] + 14.3571 / 1.1⁴ = about 2.62.
The case passes the assumed 1.50 covenant and positive-NPV hurdle. A covenant of 2.20 fails. Without an earning period the return is not decided; a tax depreciation schedule does not supply that evidence. The bridge shows the complete annual lines, including zero terminal proceeds.
Primary method: Microsoft NPV — end-of-period cash flows and initial investment. Method and handoff: Chapter 2.5 — Project Finance & Capital Formation (Mechanics).
Then turn the sizing into dates: the lead-time planner reverse-schedules every long-lead PO from your ready-for-service target.