Fusion Economics Code (FECONs) Overview
- FECONs is a spreadsheet-based costing framework for fusion power plants that standardizes and audits the physics-to-economics workflow.
- It maps engineering and subsystem data into a structured chart-of-accounts to generate NOAK estimates and support cross-concept comparisons.
- The open-source pyFECONs and CATF extension add probabilistic costing, safety-informed mapping, and finance modules for more robust sensitivity studies.
Fusion Economics code (FECONs) is a spreadsheet-based costing framework for fusion power plants that was developed through ARPA-E-supported work from 2017 through 2024 and later released in an open-source Python implementation, pyFECONs. Its defining characteristic is a standards-aligned, auditable physics-to-economics workflow: a physics-informed power balance and an engineering-constrained radial build are translated into subsystem quantities, mapped into a chart-of-accounts derived from the IAEA / GEN-IV EMWG / EPRI lineage, rolled up into total capital cost, and then annualized into quantities such as levelized cost of electricity (LCOE). In its CATF-supported extension, the framework is reorganized around architecture-specific dominant cost drivers for Magnetic Fusion Energy (MFE), Inertial Fusion Energy (IFE), and Magneto-Inertial Fusion Energy (MIFE), while adding probabilistic costing, safety-informed cost mapping, and finance and value metrics (Woodruff, 29 Jan 2026, Woodruff et al., 22 Feb 2026).
1. Definition and analytical purpose
FECONs was developed in response to a persistent methodological problem in fusion techno-economics: cost studies had often been one-off and non-comparable across concepts, limited to capital cost point estimates, too dependent on legacy scaling relations, and not always aligned with a standard cost-account structure. The framework is therefore intended to support credible programmatic comparisons across fusion concepts, identification of dominant cost drivers, evaluation of cost-reduction pathways, and consistent computation of LCOE (Woodruff, 29 Jan 2026).
The framework is primarily oriented toward Nth-of-a-kind (NOAK) estimates. In that usage, FECONs approximates a mature deployment case in which design learning has occurred, manufacturing and construction practices are industrialized, and unit costs are closer to steady-state values. This NOAK orientation does not remove uncertainty; rather, it establishes a common reference case for comparing concept classes that are still pre-commercial. A central implication is that FECONs is not merely a bookkeeping device. It is a plant-level techno-economic model in which physics assumptions, geometry, subsystem sizing, construction categories, and annualized economics are mechanically connected.
In the later CATF extension, the scope broadens beyond deterministic capital-cost and LCOE estimation. The framework is described as an extensible analysis environment suitable for transparent sensitivity studies, uncertainty propagation, and safety- and finance-coupled interpretation of fusion pilot-plant and NOAK scenarios. That extension preserves the standards-aligned backbone rather than replacing it (Woodruff et al., 22 Feb 2026).
2. Historical development and institutional lineage
The development trajectory of FECONs begins with early ARPA-E-supported costing work that applied ARIES-style cost-scaling relations to generate NOAK estimates. A 2017 pilot study benchmarked balance-of-plant costs and plant-level reasonableness with Bechtel and Decysive Systems from an engineering, procurement, and construction perspective. Those early studies showed that ARIES-style estimates were directionally reasonable, especially for balance-of-plant costs, but also exposed the sensitivity of total plant cost to layout, buildings, major equipment sizing, and plant integration (Woodruff, 29 Jan 2026).
By 2019, the methodology expanded to treat indirect costs explicitly and to examine cost-reduction pathways for non-fusion-island systems through design-for-cost practices, modularization, centralized manufacturing, and learning. This shift was informed by Lucid Catalyst studies of nuclear cost drivers. The framework also received enhanced treatment of tritium handling and plant integration with Princeton/PPPL support, reflecting the fact that fuel handling, extraction, detritiation, containment, and radioactive waste treatment affect not only the fuel cycle but also facility layout, safety scope, and indirect costs (Woodruff, 29 Jan 2026).
A major refactor occurred in 2023, when the costing capability was aligned with the IAEA / GEN-IV EMWG / EPRI code-of-accounts lineage. At that point, legacy ARIES-derived scaling relations were replaced, where possible, by bottom-up subsystem models for dominant fusion cost drivers, coupled to physics-informed power balances and engineering-constrained radial builds. These developments were implemented in the spreadsheet-based FECONs and released as the open-source Python framework pyFECONs. The 2024–2025 CATF International Working Group extension then deepened the framework around architecture-defining cost-driver tracks for MFE, IFE, and MIFE, while preserving the chart-of-accounts as the stable spine of the model (Woodruff et al., 22 Feb 2026).
3. Core workflow and chart-of-accounts structure
The basic FECONs workflow is a sequential chain: power balance, radial build / geometry, driver and power-core sizing, balance-of-plant sizing, building/layout allocation, cost account assembly, annualization, and LCOE computation. In the CATF extension, the workflow is described in nearly the same terms: a physics-informed power balance fixes gross and net electric output, an engineering-constrained radial build determines heat-island geometry and subsystem quantities, and those quantities feed the dominant fusion driver and the balance-of-plant equipment before costs are rolled into standardized accounts and annualized figures (Woodruff, 29 Jan 2026, Woodruff et al., 22 Feb 2026).
At the top level, the standards-aligned cost structure uses the GEN-IV-style grouping:
- Account 10: pre-construction costs
- Account 20: direct costs
- Account 30: indirect service costs
- Account 40: owner’s costs
- Account 50: supplementary costs
- Account 60: financial costs
The total capital cost is then expressed as
Within the direct-cost categories, FECONs allocates subsystem estimates into detailed subaccounts. The paper identifies buildings and site structures in Account 21; reactor or heat-island plant equipment in Account 22; turbine plant equipment in Account 23; electric plant equipment in Account 24; miscellaneous plant equipment in Account 25; heat rejection in Account 26; special materials in Account 27; and digital twin / simulator in Account 28 (Woodruff, 29 Jan 2026).
The implemented LCOE expression in the spreadsheet framework is
$\mathrm{LCOE}\;[\$/\mathrm{MWh}] = \frac{ C_{\mathrm{AC}} + \left(C_{\mathrm{OM}} + C_F\right)(1+y)^Y } { 8760 \; P_E \; p_a } ,$
where annual capital charge, annual operations and maintenance cost, annual fuel cost, annual escalation factor, plant lifetime, net electric power, and plant availability are explicitly represented (Woodruff, 29 Jan 2026).
Traceability is an explicit design feature. In the CATF-supported Python implementation, the script computes global assumptions, power balance, capital cost categories, annualized costs, and LCOE, then writes outputs directly into LaTeX report templates by overwriting placeholders with computed values. This is meant to ensure that published numbers remain mechanically linked to intermediate quantities and account totals (Woodruff et al., 22 Feb 2026).
4. Driver-centric architecture and subsystem modeling
A defining methodological innovation in the refactored framework is the replacement of generic top-down scaling with bottom-up subsystem models for the dominant fusion-specific cost drivers. The most important locus of this change is Account 22.1.3, historically labeled “Coils or Lasers or Pulsed Power.” In the CATF extension, this account is treated as a controlled swap-point: the generic placeholder is replaced by a full cost-account development for the dominant driver in each architecture class, while Account 22.1.7 captures the supporting power supplies / pulse-forming infrastructure (Woodruff et al., 22 Feb 2026).
| Fusion family | Account 22.1.3 dominant driver | Account 22.1.7 role |
|---|---|---|
| MFE | Magnet account | Supporting electrical category |
| IFE | Laser/driver account | Supporting electrical category |
| MIFE | Pulsed-power driver account | Supporting electrical category |
For MFE, the driver account becomes an explicit magnet account covering TF/PF/CS magnets, superconductors, conductor, structural materials, cryostat interfaces, fabrication, installation, and related learning effects. The earlier ARPA-E work already described a detailed magnet routine based on REBCO tape length, conductor cost, copper, steel, insulation, manufacturing multipliers, structural cost, and coil-set totals, replacing older generic magnet scaling with a more physically grounded estimate (Woodruff, 29 Jan 2026, Woodruff et al., 22 Feb 2026).
For IFE, Account 22.1.3 becomes a laser or driver account tied to pulse energy, repetition rate, wall-plug efficiency, modular driver architecture, optics and pumping modules, and consumables/lifetime logic. For MIFE, the account becomes a pulsed-power driver model built around installed \$/J, module count, capacitor banks, switches, charging and dump circuits, buswork, diagnostics, and replacement-versus-life-of-plant strategies via derating (Woodruff et al., 22 Feb 2026).
This driver-centric treatment is embedded in a larger “physics → geometry → equipment → accounts → LCOE” chain. The radial build includes the plasma or target region, first wall, blanket, shield, coil envelope, bioshield, and maintenance space, and is constrained by engineering limits such as surface heat loading, material limits, shielding needs, and maintenance access. The framework therefore does not treat driver costs in isolation; the dominant account is linked to plant geometry, heat-island size, and balance-of-plant requirements (Woodruff, 29 Jan 2026).
5. Probabilistic costing, safety-informed costing, and finance/value modules
The CATF extension converts the deterministic backbone into a probabilistic costing framework by compounding materials price uncertainty, TRL-based maturity uncertainty, and learning-curve uncertainty into cost distributions. Material uncertainty is driven by geometry-derived mass estimates; TRL uncertainty is represented with a TRL-dependent log-normal multiplier whose spread decreases as maturity increases; and learning is modeled with the standard experience-curve form
To estimate uncertainty in learning, the prototype fits a linear regression to and bootstraps pairs to generate an empirical distribution for the learning exponent and therefore the learning rate (Woodruff et al., 22 Feb 2026).
The same extension adds a safety-informed costing layer. The safety module has three stated purposes: enumerate hazards, identify mitigating systems/structures/components, and map those mitigations into the chart-of-accounts rather than leaving them as informal adders. Enumerated hazards include plasma disruptions, vacuum boundary breaches and oxidation, direct radiation exposure, cooling disruption accidents such as LOCA/LOFA/LOHR, corrosion and mass transport, cryogenic hazards, tritium and activated material releases, supplementary heating hazards, vacuum system hazards, radwaste, and fuel handling hazards. Cost scope is then allocated conservatively across standardized accounts, including site/land implications in Account 20, civil and structural confinement and bioshield elements in Account 21, fusion-island confinement features in Account 22.1, contingencies in Account 52, insurance in Account 53, decommissioning and end-of-life liabilities in Account 54, and licensing and regulatory fees in Account 62 (Woodruff et al., 22 Feb 2026).
The macroeconomic and finance extension broadens the framework beyond LCOE to include WACC-based annualization, NPV, IRR, MIRR, TLCC, revenue requirement, EAC, simple and discounted payback periods, BCR, SIR, IRP/DSM ratio tests, consumer and producer surplus, Residual Value (RV), Follow-On Value (FOV), and APV. The explicit goal is to compute investment and planning measures from the same chart-of-accounts-mapped outputs used for plant costing (Woodruff et al., 22 Feb 2026).
These additions are intended for pilot-plant and NOAK scenarios alike. Pilot plants are treated as the stage where uncertainty, safety scope, licensing, and FOAK risk matter most, whereas NOAK scenarios are supported by learning curves, modularization assumptions, and market-trajectory modeling. The extension is careful, however, to state that the safety module is not a substitute for full risk assessment or licensing-grade analysis, and that the probabilistic layer is an overlay rather than a replacement for the deterministic baseline (Woodruff et al., 22 Feb 2026).
6. Software, developer experience, and organizational context
FECONs emerged within a broader reorganization of computational practice in fusion and fission energy. A 2024 survey of 103 computational scientists described software as “the dominant tool for design” and defined “affordance” as “the degree to which a tool influences the outcome of what is designed with it.” The same study defined developer experience (DevEx) as the overall experience and satisfaction a developer has while interacting with tools and platforms, and found a shift toward modern programming languages, open-source codes, modular software, and multiphysics codes (Coto et al., 10 Jul 2025).
The survey reported Python as the most-used language, with C++ close behind and Fortran in third place. The reported usage shares were approximately Python 40%, C++ 34%, Fortran 12%, MATLAB 6.3%, C 3.1%, Julia 4.7%, and other 0.78%. It also reported nuclear engineering software budgets ranging from $0 to$50,000,000, with a median of $1 million, a 25th percentile of$1,000, a 75th percentile of $5,000,000, and a maximum response of$50 million. Respondents identified lack of open-source access, slow performance, limited development activity, unresolved errors, antiquated input/output formats, steep learning curves, poor documentation, cumbersome meshing workflows, weak GPU support, difficult installation, vague errors, and lack of a GUI as recurrent sources of dissatisfaction (Coto et al., 10 Jul 2025).
This software-economic context is directly relevant to pyFECONs. The framework’s open-source Python implementation, modular chart-of-accounts structure, auditable mapping from subsystem estimates to standardized accounts, and explicit attention to reproducibility are consistent with the survey’s observed preference for modern languages, modular software, transparency, extensibility, and active development. This suggests that FECONs should be understood not only as a costing framework but also as part of a wider transition in fusion software toward open, community-readable, and developer-visible infrastructure (Coto et al., 10 Jul 2025).
7. Relation to other fusion-economic frameworks and limits of interpretation
FECONs belongs to a larger family of fusion techno-economic tools, but its role is distinct. PROCESS is a reactor systems code that assesses the engineering and economic viability of a hypothetical fusion power station using simple models of all parts of a reactor system, with user-selectable constraints. It explicitly links magnet design, shielding, thermal efficiency, planned and unplanned downtime, and pulsed duty cycle to availability, capacity factor, and cost of electricity. Its authors emphasize that omitted effects such as safety, first wall erosion, and fatigue life could be crucial, which underscores the general point that fusion systems codes are powerful but constraint-dependent (Kovari et al., 2016).
A different abstraction appears in the generalized economic viability criterion based on the economic gain factor . That framework normalizes revenue and cost rates to an energy-capture surface, introduces ten controlling normalized design parameters, and defines breakeven through . In base-case scans it finds a threshold around $\mathrm{LCOE}\;[\$/\mathrm{MWh}] = \frac{ C_{\mathrm{AC}} + \left(C_{\mathrm{OM}} + C_F\right)(1+y)^Y } { 8760 \; P_E \; p_a } ,$0 for basic economic viability and emphasizes the nonlinear tradeoff among power density, surface replacement time, surface energy fluence, target cost, financing, and efficiency. Unlike FECONs, it is not organized around a chart-of-accounts or subsystem cost roll-up; it is a concept-agnostic screening criterion (Whyte et al., 6 Apr 2026).
The broader fusion cost literature also imposes a cautionary backdrop. A stochastic analysis of projected future fusion costs harmonized 590 entries from 56 references spanning 1975–2024, used 10,000 Monte Carlo iterations for each technology-maturity combination with sufficient data coverage, and reported mean mature LCOE values of 114.6, 110.3, and 143.9 USD/MWh for MCF, ICF, and MIF devices, respectively. The same study inferred mean learning rates of 30.0% for ICF, 19.5% for MCF, and 20.7% for MIF, but judged the resulting projections “rather optimistic” and urged policymakers to caution when fusion developers refer to the potential economic competitiveness of fusion power plants (Böhnlein et al., 25 Jun 2026).
Within that landscape, FECONs is best understood as an auditable standards-aligned costing backbone rather than an oracle. Its value lies in exposing how geometry, subsystem assumptions, indirect costs, learning, safety posture, licensing, insurance, and capital structure alter final cost and value metrics. A plausible implication is that FECONs becomes most useful when it is used to make assumptions legible, comparable, and stress-testable, rather than to confer false precision on inherently uncertain pilot-plant and commercialization scenarios.