Quantum Resource Estimation

• Quantum Resource Estimation (QRE) is the systematic process of converting abstract quantum algorithms into specific physical and logical resource requirements for execution.
• It integrates design-time budgeting with runtime monitoring, thereby estimating qubit counts, gate operations, error thresholds, and execution time across different hardware scopes.
• QRE supports architecture-level trade-offs and hardware-software co-design by analyzing resource metrics to guide decisions in fault-tolerant and NISQ environments.

Quantum Resource Estimation (QRE) is the systematic process of identifying, estimating, and managing the physical and logical resources required to make a quantum application executable and reliable. In the literature, the term spans multiple regimes. In fault-tolerant quantum computing (FTQC), QRE usually denotes the translation of an abstract algorithm into concrete requirements such as logical qubits, code distances, T-state production, runtime, and physical-qubit footprints. In the NISQ era, the same term is increasingly used for dynamic, developer-facing viability analysis that combines static budgeting with run-time monitoring, capability probes, and conditional execution under changing device conditions (Lammers et al., 6 Aug 2025, Lammers et al., 23 Aug 2025).

1. Conceptual scope and historical framing

QRE has developed along two partially overlapping lines. One line treats it as a full-stack FTQC planning discipline: an abstract circuit is compiled into an implementable architecture, error correction is included explicitly, and the resulting computation is evaluated in terms of space, time, and failure budgets. A representative formulation is the “shoe box” model, where the principal figure of merit is the space–time volume

$V = Q \times T,$

with $Q$ the number of physical qubits and $T$ the runtime of the compiled, error-corrected circuit. In this view, QRE is not merely gate counting; it is architecture-constrained scheduling and bottleneck analysis under conservative assumptions about locality, distillation, measurement, and feedforward (Paler et al., 2019).

A second line, sharpened by recent NISQ work, treats QRE as a discipline embedded in the software lifecycle rather than as a purely pre-execution exercise. Under this view, resource estimation includes design-time budgeting, compile-time overhead accounting, and run-time verification of whether current hardware conditions are sufficient for a given circuit. This formulation explicitly includes dynamic, run-time monitoring and decisioning, and it shifts emphasis from idealized long-range projections to near-time feasibility checks on noisy devices (Lammers et al., 6 Aug 2025).

This broader scope also changes where QRE sits in the development workflow. A fault-tolerant workflow may replace the execution step with an estimation step that accepts either a quantum program or pre-layout logical counts, combines them with hardware assumptions and an error budget, and returns physical qubits, runtime, code distance, and factory provisioning. A plausible implication is that QRE functions as a design instrument even when target hardware is unavailable, while remaining relevant to deployment-time choices when hardware is available but unstable (Quetschlich et al., 2024).

2. Resource layers, metrics, and cost models

The literature consistently separates resources into physical and logical layers. In the NISQ-oriented taxonomy, physical resources include the number of qubits and their quality, gate and readout error rates, gate fidelity, coherence times $T_1/T_2$, entanglement capacity, topology or connectivity graphs, noise characteristics, and calibration snapshots and drift. Logical resources include gate sets and native operations, circuit width and depth, gate counts, measurements and supported operations, transpilation artifacts, error correction or mitigation mechanisms, algorithmic primitives and their resource footprints, and temporal platform artifacts such as queue delays and asynchronous scheduling (Lammers et al., 23 Aug 2025).

A more metric-oriented presentation makes these categories explicit through quantities such as width $W$, depth $D$, total gate count $G$, one-qubit gate count $G_1$, two-qubit gate count $G_2$, non-Clifford or T-gate count $T$, T-depth $Q$0, and measurement operations $Q$1. Hardware-side parameters include coherence times $Q$2 and $Q$3, gate durations $Q$4, readout time $Q$5, connectivity, crosstalk, and calibrated error parameters $Q$6. These metrics are intended to be reported both before and after transpilation because mapping to native gates and topology can materially change depth, routing, and error accumulation (Lammers et al., 6 Aug 2025).

Several simple analytic models recur in NISQ-focused QRE. A coarse success-likelihood model is

$Q$7

with circuit duration estimated by

$Q$8

Routing overhead is commonly summarized by

$Q$9

where $T$0 is the number of inserted SWAPs. Statistical sampling costs are often bounded using

$T$1

These models are explicitly presented as coarse planning tools rather than exact predictors (Lammers et al., 6 Aug 2025).

In FTQC, the dominant metrics shift. Logical qubits $T$2, physical qubits $T$3, code distance $T$4, runtime $T$5, T-count, T-depth, cycle time $T$6, and factory throughput become primary. The “shoe box” methodology emphasizes that logical-to-physical conversion is context-dependent: patch area scales with $T$7, but total $T$8 also includes syndrome ancilla, lattice-surgery interfaces, routing corridors, and temporary workspace for distillation. A widely used practical criterion for NISQ plausibility before full error correction is

$T$9

with implementation considered plausible if the worst physical error rate $T_1/T_2$0 satisfies $T_1/T_2$1 (Paler et al., 2019).

3. Estimation workflows, toolchains, and compilation interfaces

Modern QRE is organized around staged workflows. Pre-layout logical estimation counts qubits, measurements, and gate types; compile-time estimation adds routing, decomposition, and layout overhead; post-layout logical estimation derives logical depth and T-state demand; and physical mapping chooses a code distance and factory configuration to satisfy a target failure probability. This workflow is explicit in the Azure Quantum Resource Estimator, which compiles Q# or Qiskit programs to QIR, derives post-layout logical metrics, maps them through surface-code or floquet-code models, and reports code distance, physical qubits, runtime, and rQOPS (Dam et al., 2023).

Representative toolchains cover distinct parts of this design space.

Framework	Orientation	Emphasis
Azure Quantum Resource Estimator	FTQC-oriented	logical-to-physical mapping, code distance, runtime
Qualtran	cost-aware abstractions	algorithm composition and resource tables
BenchQ	FTQC benchmarking	distillation, decoders, architecture studies
QuRE	FTQC estimator	cost across physical technologies
MQT Bench	NISQ benchmarking	reproducible cross-hardware comparisons
Qonscious	runtime-aware NISQ	conditional execution via dynamic checks

These tools are not interchangeable. Azure Quantum Resource Estimator, Qualtran, BenchQ, and QuRE are described as FTQC-oriented; MQT Bench emphasizes standardized NISQ benchmarking with previously obtained data; and Qonscious is explicitly a prototype runtime layer for conditional execution driven by resource introspection (Lammers et al., 6 Aug 2025, Lammers et al., 23 Aug 2025).

Compilation has become a first-class QRE concern because logical metrics can change substantially after synthesis, placement, routing, and decomposition. This is particularly visible in compilation-driven frameworks for early fault-tolerant architectures, where arbitrary circuits are first decomposed into Clifford+$T_1/T_2$2 form, then into Clifford+T, and finally into hardware-specific logical primitives with known latencies and movement costs. This suggests that coarse analytical models and post-layout compilation models are complementary rather than competing abstractions (Campbell et al., 1 Apr 2026).

4. Runtime-aware QRE in the NISQ era

A central recent development is the reframing of QRE from a static FTQC cost-modeling exercise into a run-time mechanism for NISQ devices. In this formulation, software exposes resource constraints programmatically, introspects the backend immediately before execution, and conditionally executes, skips, or redirects the computation according to the measured device state. The intended workflow is explicitly “express constraints → introspect at runtime → conditionally execute or skip,” and the rationale is that fidelity, decoherence, and global properties such as entanglement fluctuate on timescales relevant to execution decisions (Lammers et al., 23 Aug 2025).

The Qonscious framework operationalizes this model. It introduces backend adapters that normalize vendor backends, constraints that run resource tests and evaluate decision policies, and an executor API of the form executor.run_conditionally(backend_adapter, constraint, on_pass, on_fail, shots=…). Its exemplar constraint, PackedCHSHTest, runs four CHSH measurements in parallel on four qubit pairs, computes correlators $T_1/T_2$3 from counts, and forms the CHSH score

$T_1/T_2$4

A simple policy such as MinimumAcceptableValue(2.2) accepts execution only if $T_1/T_2$5, thereby requiring measurable non-classical correlation above the classical bound of $T_1/T_2$6 before the main circuit runs (Lammers et al., 23 Aug 2025).

The run-time perspective also exposes platform limitations. Three challenges are identified repeatedly: limited introspection in current APIs, the need for extensible high-level resource metrics beyond vendor-provided calibrations, and temporal decoupling between introspection and execution because queueing and asynchronous scheduling can invalidate earlier measurements. This directly affects QRE because any near-time estimate must be contextual, stale-data tolerant, and robust to the absence of shot-level conditional aborts or mid-job reconfiguration (Lammers et al., 6 Aug 2025).

The current prototype remains narrow by design. It demonstrates feasibility with IBM Quantum via QiskitRuntimeService, an IBMSamplerAdapter, and 1024-shot CHSH-based gating of a Bell-state circuit, but it does not provide quantitative performance tables, integrate with transpilers for conditional re-routing, or model mitigation and QEC decisions directly. This suggests a transition from static benchmarking toward resource-aware middleware rather than the replacement of existing FTQC estimators (Lammers et al., 23 Aug 2025).

5. Application domains and architecture-level studies

QRE has become a general methodology for comparing algorithmic variants. In arithmetic, Azure-based studies of schoolbook, Karatsuba, and windowed multiplication report logical metrics, code distances, physical qubits, and runtime across superconducting, trapped-ion, and Majorana presets. Within the tested ranges, windowed multiplication is fastest for moderate sizes, schoolbook uses fewer qubits, and Karatsuba’s asymptotic advantage appears only at much larger inputs. A later arithmetic survey extends this style of analysis to addition, division, and modular exponentiation, using Pareto frontiers over factory counts to expose space–time trade-offs (Hansen et al., 2024, Fedoriaka et al., 6 Sep 2025).

Chemistry and many-body simulation are major QRE targets. QREChem estimates logical resources for Trotterized quantum phase estimation, reports T-gate counts from roughly $T_1/T_2$7 to $T_1/T_2$8 across molecules and basis sets, and gives FeMoco estimates of approximately $T_1/T_2$9 and $W$0 logical T gates for two active spaces. A complementary workflow study uses QRE to replace execution in application development and reports a chemistry case study with 1,318 logical qubits, 270 billion required T states in the baseline high-fidelity scenario, and hardware-regime outputs such as 1.30M physical qubits and 8 days in the “M ns, $W$1” setting. At the logical level, many-body ground-state preparation studies use gap- and fidelity-based formulas to estimate time-to-solution and report T-depth reductions between $W$2 and $W$3 for qubitization plus rewind relative to product-formula baselines (Otten et al., 2024, Quetschlich et al., 2024, Lemieux et al., 2020).

Architecture-level QRE extends beyond monolithic processors. For distributed quantum computers, a recent framework models surface-code nodes, magic-state distillation, inter-node Bell-pair distillation, and network throughput, and reports that at a 45K-qubit node size distributed systems require on average about $W$4 more physical qubits and about $W$5 longer execution time than monolithic systems, while remaining more favorable from a hardware implementation standpoint. At the networking layer, entanglement-routing QRE derives a polynomial scaling exponent $W$6 for nested repeater protocols and argues that two-qubit gate errors below 1.3% are needed to keep the polynomial degree below 10 (Filippov et al., 26 Aug 2025, Dawar et al., 2024).

NISQ and early fault-tolerant studies show the same logic in other settings. A 50-qubit Hubbard-model VQE analysis estimates on the order of 20,000 two-qubit gates, argues that two-qubit error rates of about $W$7 are needed for meaningful results with mitigation, and shows that a gradient-descent iteration takes days unless parallelized across hundreds of QPUs. Partial FTQC studies of the STAR architecture similarly use QRE to identify a “Goldilocks zone” for roughly $W$8–$W$9 small-angle rotations and report minute-scale runtimes for modest 2D Fermi–Hubbard systems on hundreds of thousands of physical qubits (Cai, 2019, Chung et al., 13 Mar 2026).

6. Limitations, benchmark sensitivity, and future directions

A recurrent limitation of QRE is dependence on assumptions that are hard to validate at scale. FTQC estimators encapsulate hardware models, decoder behavior, factory schedules, and logical-to-physical mappings that may change with architecture; NISQ estimators depend on drift-prone calibration data, stale backend properties, and queue-induced temporal mismatch. Several papers therefore call for standardized metrics, uncertainty quantification, and technology-agnostic reporting that goes beyond FTQC-centric T-counts while remaining resistant to benchmark “gaming” (Lammers et al., 6 Aug 2025, Lammers et al., 23 Aug 2025).

Another issue is that compilation, routing, and architecture features increasingly dominate estimates. Compilation-driven QRE for neutral-atom platforms shows that magic-state production can dominate early fault-tolerant workloads, but that movement, routing, and measurement-zone choices become the critical bottlenecks as problem size grows. This suggests that hardware–software co-design must include movement-aware compilation and frugal routing rather than treating compilation overhead as a secondary correction (Campbell et al., 1 Apr 2026).

The future directions outlined across the literature are consistent. They include extending NISQ constraints beyond entanglement to contextuality, magic, and depth viability; tightening integration with schedulers, transpilers, and service-quality frameworks; standardizing resource schemas across vendors; and turning QRE into a component of a broader quantum operating system capable of analytics, scheduling, and eventually just-in-time adaptation (Lammers et al., 23 Aug 2025, Paler et al., 2019).

A further development is the suggestion that QRE itself can exhibit quantum advantage. One recent proposal argues that small quantum computers can directly measure state-dependent simulation errors of Trotterized algorithms and use those measurements to tighten resource estimates for larger, classically intractable systems, with reported reductions of two orders of magnitude at 14 qubits and a prediction of roughly three orders at 100 qubits. This suggests that QRE is not only a methodology for evaluating quantum algorithms but may itself become a practically useful quantum workload (Simon et al., 1 Dec 2025).