Which QASM input format is recommended for Azure QRE, NISQ-style gates or FTQC-compatible Clifford+T?

Hello Akita !

Thank you for posting on MS Learn Q&A.

You should not treat a NISQ transpiled circuit and a Clifford+T circuit as equivalent inputs because they represent different compilation assumptions so different results are expected.

In practice, I would recommend using algorithm level or logical QASM as the default input where you keep meaningful gates such as rx, ry, rz controlled ops and measurements...

Then let Azure QRE account for the fault tolerant cost using its target parameters, error budget, rotation synthesis assumptions, T-state requirements and QEC model.

Azure QRE is specifically intended to estimate resources for running a quantum algorithm on a fault tolerant quantum computer and not to simulate a NISQ backend gate set.

You can check about estimation here : https://learn.microsoft.com/en-us/azure/quantum/intro-to-resource-estimation

Or you can use a pre decomposed Clifford+T QASM only when you have intentionally performed a fault tolerant compilation yourself and you want QRE to estimate the resources for that exact decomposition. In that case, the T-count or the T-depth and synthesis precision are already baked into your input circuit.

The reason the results differ is that QRE reports and uses different logical quantities, including tCount, rotationCount, rotationDepth, numTstates, and numTsPerRotation. Arbitrary rotations are not the same as explicit T gates: QRE can estimate the T-state cost of rotations based on rotation synthesis assumptions, while a Clifford+T input directly fixes the number of T gates seen by the estimator.

https://learn.microsoft.com/en-us/azure/quantum/overview-resource-estimator-output-data

Hello Akita,

Azure Quantum Resource Estimator supports both high-level OpenQASM input and circuits that are already decomposed into a fault-tolerant gate set such as Clifford+T.

The estimator calculates results based on the target configuration and fault-tolerant assumptions selected for the run, including factors such as the physical qubit model, quantum error correction scheme, error budget, T-state distillation, and rotation gate synthesis. Because of these assumptions, two functionally equivalent circuits can produce noticeably different estimates depending on how the circuit is represented.

For example, a circuit written with arbitrary rotation gates may require the estimator to internally synthesize those rotations into fault-tolerant operations, while a pre-decomposed Clifford+T circuit already defines those operations explicitly. As a result, differences in logical qubit counts, T counts, runtime, or physical resource estimates are expected behavior and do not necessarily indicate a service issue.

At this time, this behavior is not identified as a known Azure Quantum Resource Estimator issue.

It is also important to note that there is no general requirement to always provide Clifford+T OpenQASM as input. Both higher-level OpenQASM and pre-decomposed fault-tolerant circuits are supported workflows. The recommended approach is to choose the representation that aligns with the type of estimation you want to perform:

If you want to estimate the cost of a specific fault-tolerant implementation that has already been optimized or decomposed, then providing the decomposed Clifford+T circuit is appropriate.

If you want to estimate resources directly from a higher-level algorithm description, then higher-level OpenQASM input is also fully supported, with the understanding that the estimator will apply its own synthesis and fault-tolerant modeling assumptions.

For the most consistent comparison between different circuit representations, we recommend keeping the estimator configuration identical across runs, especially the qubit model, QEC scheme, and error budget settings. This ensures that any differences in the output are attributable to the circuit representation itself rather than configuration changes.

Reference:

• https://learn.microsoft.com/en-us/azure/quantum/intro-to-resource-estimation
• https://learn.microsoft.com/en-us/azure/quantum/resource-estimator-known-estimates?tabs=tabid-known-estimates-qsharp
• https://learn.microsoft.com/en-us/azure/quantum/resource-estimator-batching