Why does the T-count change in Azure QRE even for an FTQC gate set QASM input?

Hello Akita !

Thank you for posting on MS Learn Q&A.

The T-count shown by Azure Quantum resource estimator is not necessarily the literal number of T or Tdg gates written in the QASM file.

It is the count after the input has been imported, normalized and mapped into the estimator logical resource model.

If you submit through Qiskit/QDK interop, the circuit can go through transpilation, export, import steps.

The QDK Qiskit estimator exposes options such as optimization_level and basis_gates which means the logical representation used by QRE may differ from the textual QASM gate list.

https://learn.microsoft.com/en-us/python/qsharp/qsharp.interop.qiskit?view=qsharp-py

QRE as calculating the number of T states needed plus T-factory resources, runtime, and physical qubits. So the reported T resource is tied to the fault-tolerant implementation model not only to the original syntax.

Also, Azure QRE assumes PSSPC for mapping programs to a 2D logical layout. In this model, Clifford operations are commuted through T gates, rotation and measurements leaving a final Clifford part that can be evaluated classically. This can make the estimator logical accounting differ from a simple gate-by-gate count.

Even when the input is already Clifford+T, compiler normalization can simplify or rewrite patterns. For example, adjacent T/Tdg patterns may cancel, repeated T gates may become a Clifford operation and gates such as CCX, CCZ, controlled operations or rotations may be decomposed or accounted for differently depending on the input path.

Hey there! You’re right on the money thinking that the QRE is doing more than just “counting” the Ts in your input QASM it actually runs its own FTQC-focused compilation and synthesis pipeline, which can add or drop T gates compared to your raw circuit. Here’s what’s happening under the hood:

Front-end normalization

• QRE parses your QASM and rewrites everything into a canonical internal format (even if it’s already FTQC-compatible). That step can expose extra T opportunities or merge T-light sequences.
• PSSPC-based phase‐polynomial synthesis - This pass takes any sets of Z-rotations (T, S, etc.) and re-expresses them via optimized phase polynomials. Sometimes that reduces Ts, sometimes it trades a few Ts for fewer ancillas or lower depth. Peephole/peephole-like optimizations
• Small local rewrites (e.g. canceling T followed by T†, commuting Ts through CNOTs, merging adjacent rotations) can change the overall T tally.
• Final gate decomposition to the exact FTQC gate set
• Even if your QASM uses H, CNOT, T, QRE may decompose composites (like multi-controls or custom rotations) into standard FTQC templates, shifting the T-count slightly.
• All of these steps aim to give a realistic resource estimate—sometimes at the cost of matching your original T count exactly.

If you want to see what QRE is doing, try running your job with verbose logging or a lower optimization level (e.g. disable the PSSPC pass) and compare the “after-compile” circuit.

Reference

• The role of T gates and T factories in quantum computing (includes FTQC gate set & synthesis overview): https://learn.microsoft.com/azure/quantum/concepts-tfactories?wt.mc_id=knowledgesearch_inproduct_azure-cxp-community-insider#universal-set-of-quantum-gates
• Appendix on T factories in the Microsoft Quantum resource estimator: https://learn.microsoft.com/azure/quantum/concepts-tfactories?wt.mc_id=knowledgesearch_inproduct_azure-cxp-community-insider#t-factories-in-the-microsoft-quantum-resource-estimator

. If you have any further queries, let me know. If the information is helpful, please click on Upvote and Accept Answer on it.