Classiq Introduces Fault Tolerance Engine for Quantum Applications

TEL AVIV, Israel, Sept. 30, 2026 /CourierPR/ -- Classiq, a leading quantum computing software company, has introduced a new Fault Tolerance Engine designed to bridge the gap between quantum applications and fault-tolerant hardware. The engine translates optimized logical quantum programs into fault-tolerant execution plans, providing detailed resource estimates and reliability measures for running applications on real machines.

According to Nir Minerbi, co-founder and CEO of Classiq, fault-tolerant quantum computing introduces a new software challenge.

Classiq's Fault Tolerance Engine performs this translation, carrying the logical quantum program built in the company's high-level modeling and synthesis environment through to a concrete fault-tolerant implementation. This includes how the protected qubits are laid out, how their interactions are routed, and the schedule that runs them. The engine can produce an architecture-aware execution plan and resource estimates, covering factors such as physical qubit requirements, error-correction cycles, code distance, runtime, routing, scheduling, and accumulated error.

The engine also accounts for particularly expensive fault-tolerant operations, such as T gates and the magic-state resources commonly required to implement them. Because these figures are measured from the plan the engine actually produced, rather than calculated from formulas, they describe the implementation a machine would run. This allows users to move beyond asking whether an algorithm is logically correct or whether a circuit can be optimized. They can begin asking whether a target application is physically implementable on a specific machine, based on that machine's measured noise characteristics, which resources dominate its cost, and what would need to be improved to make the application practical.

Minerbi emphasized that fault tolerance changes the question quantum software has to answer.

Classiq's model-first approach is particularly important in fault-tolerant computing because the most efficient logical circuit is not necessarily the most efficient fault-tolerant implementation. Physical cost can depend on factors including T-gate requirements, routing, parallelism, code distance, and the amount of fault-tolerant infrastructure needed to support a computation. Choices that appear similar at the logical level can therefore produce very different requirements once mapped to a protected physical architecture.

The Fault Tolerance Engine's routing is an optimization that decides how protected qubits are laid out and how their interactions are routed so the implementation uses as few physical qubits as possible, which is usually the largest single cost in a fault-tolerant computation. This architecture creates a path to evaluating implementation choices before their cost is multiplied across potentially large numbers of physical qubits and error-correction cycles.

For Classiq users, the result is a broader development workflow. The platform can support not only the design and optimization of quantum algorithms but also the study of their physical feasibility. Reducing what a workload requires and predicting it realistically is what moves a first useful fault-tolerant run earlier in the roadmap.

The Fault Tolerance Engine goes beyond resource estimation alone. It both analyzes the requirements of a fault-tolerant computation and generates an architecture-aware execution plan for carrying it out on the target hardware. A fault-tolerant computation is both a spatial and temporal problem. Protected logical qubits must be positioned, interactions must be routed, error-correction procedures must run continuously, costly auxiliary resources must be available when needed, and the full computation must meet a target reliability level.

By bringing these factors together, the Fault Tolerance Engine can help users examine questions such as: How many physical qubits could an application require? How many error-correction cycles are needed? What runtime could the resulting fault-tolerant computation require? Which operations or resources represent the main bottleneck? How do layout, routing, and scheduling affect the performance? What level of protection is needed to reach a target failure probability? Which aspects of the hardware or software would need to improve for the workload to become practical?

These capabilities are relevant to application developers evaluating future quantum workloads, enterprises planning quantum programs, and research organizations comparing algorithms and architectures. They matter equally to hardware teams, as a complete fault-tolerant execution plan tied to a specific machine gives a software vendor and a hardware builder the same concrete artifact to work against when planning a joint roadmap.