Skip to main content
Four versions released in July, led by two headline features: a new architecture that makes synthesis significantly faster, and predefined hardware benchmarking across the IDE and SDK.

Key Updates: Synthesis & Benchmarking

A faster synthesis architecture, and predefined quantum hardware benchmarks

5 Enhancements

A new QNN layer, language ergonomics, and direct session configuration

5 Documentation & Library Additions

Benchmarking and QNN guides, plus three library notebooks

7 Bug Fixes & Deprecations

Correctness fixes and API deprecations

A Faster, Scalable Synthesis Architecture

Synthesizing Qmod code (in the IDE or via the SDK’s synthesize) now returns a Qmod-based executable representation rather than a QASM circuit. This representation is a subset of Qmod: it captures the concrete implementations and resource allocations chosen for the high-level constructs in the source, while preserving the function hierarchy and symbolic control flow. Compilation is therefore significantly faster, cutting synthesis runtime by up to 10x, and scales better to larger problems and algorithms. The quantum program visualization is generated directly from this representation.
Transpilation no longer occurs at synthesis. To restore the old flow, in which transpilation occurs during synthesis, set compatibility_mode=True in the synthesis preferences.

Exporting to Target Languages

After synthesizing high-level Qmod code into a concrete gate-level quantum program, the export function, or the export menu in the Classiq IDE, transpiles it into a circuit in a target language of your choice: OpenQASM 2.0, OpenQASM 3.0, QIR, Cirq JSON, or Q#. The export menu in the Classiq IDE: a dropdown from the download button in the top bar listing the available target languages By default no further transpilation is applied; pass transpilation_config=True in the SDK (see example below) to reuse the transpilation level, backend, gate set, and connectivity map defined in the synthesis preferences, or an explicit TranspilationConfig object to override them. For a full explanation of transpilation and the available levels, see the Quantum Program Transpilation guide. Exporting a synthesized program to OpenQASM 3 with a specific gate set and connectivity:
Execution, by contrast, transpiles the program for the backend you run on; the backend and transpilation level you set for that execution override the synthesis preferences, if there is a conflict.

Fault-Tolerant Export

Exporting a program to a fault-tolerant circuit with a Clifford+T gate set is now faster and more accurate, driven by the gridsynth algorithm rather than the Solovay-Kitaev method used previously. Passing a FaultTolerantTranspilationConfig object to export (instead of a regular TranspilationConfig) activates fault-tolerant transpilation. Its clifford_t_approximation_error parameter sets the error threshold for approximating the RZ rotations into Clifford+T gates, where a lower threshold gives a more accurate but deeper circuit.

Circuit Metrics

Two new functions now report a program’s resource estimates: get_circuit_metrics returns the logical width, depth, and gate counts of the Qmod-based executable, without transpilation. get_transpiled_circuit_metrics transpiles the program using the synthesis preferences first, then returns the same counts for the resulting hardware-targeted circuit.

Hardware Benchmarking

The new hardware benchmarking suite scores how accurately a backend runs standard quantum algorithms, and lets you compare across different hardware providers. To get started, open the Execution page within the Classiq IDE and switch to the Benchmark tab, then pick one of the available predefined benchmarks: GHZ, Adder, QFT, State Preparation, or Dynamical Localization. Configuring a GHZ benchmark on the Execution page: selecting simulators and hardware backends on the left, with problem-size range, shots, and per-backend Emulate and Run Via Classiq options on the right At the bottom of the page, a panel describes the benchmark you chose and explains how it is scored. Set the range of problem sizes to sweep as min / max / step, select the backends, and set the shots per job; each backend has the option to be run via Classiq on an allocated budget, so no provider credentials are needed, and to be emulated against the device’s noise model instead of the physical QPU.
Up to 10 backends can be selected, spanning QPUs, hardware emulators, and simulators, and a session can include up to 15 jobs, one per backend per problem size, so the number of backends times the number of problem sizes must not exceed 15.
Click Run to submit, and the results come back as a table of backend scores by problem size and a chart plotting them all together. The benchmark Jobs page: a score-versus-problem-size chart comparing the Classiq simulator against two IBM devices, with a per-job table of scores, cost, and status below Each job receives a score between 0 and 1, where 1 means the measured outcomes match the noise-free ideal and lower values reflect hardware noise and error. For a full walkthrough, see the Benchmarking in the Classiq IDE section of the Predefined Benchmarks user guide. Benchmarks can also be run through the Python SDK, where run_benchmark takes a BenchmarkRequest and returns a BenchmarkSession to poll for results.
A dedicated SDK benchmarking package is on the way, adding support for custom benchmarks alongside the predefined ones. It is expected in the upcoming months.

Enhancements

New QLayer Interface for QNN

The new QLayerV2 is a cleaner, faster quantum layer for training quantum neural networks. It accepts a synthesized quantum program and an optional list of Pauli observables (see example below), and produces a torch module with one output feature per observable, with no execute or post_process function to write. Its gradients use adjoint differentiation, so they are exact rather than finite-difference estimates, and training is much faster.
QLayerV2 is set to supersede the existing QLayer (now exported as QLayerV1) as the canonical interface. For a comparison and guidance on when to use each, see Choosing between the two layers. QLayerV2 is Studio-only for now, with support outside Studio expected in the coming months.

Language Ergonomics

Several small changes cut friction when writing in Qmod:
  • New classical functions range_ and reversed_, mirroring Python’s range and reversed, are now available. They operate on Qmod classical variables within classical expressions.
  • The subscript and slice_ path operators can now be imported directly from the top-level classiq package (from classiq import *), and no longer need an explicit import.
  • Declaring a local quantum variable as a QArray or QNum now requires only its defining arguments, where a name was previously required as well.

Direct Execution Session Configuration

Continuing the move toward flatter configuration, ExecutionSession now accepts the advanced constructor arguments noise_properties, amplitude_threshold, include_zero_amplitude_outputs, and job_name directly, matching fields previously reachable only through execution preferences.

Backend Modality Data

The DataFrame returned by get_backend_details now includes a modality column, letting you filter and compare backends by modality when deciding where to execute your quantum program. The reported modalities are superconducting, trapped-ion, simulator-cpu, and simulator-gpu.

Optional Execution Progress Logging

A verbose parameter was added to the execution functions and ExecutionSession methods, including sample, observe, variational_minimize, and calculate_state_vector. It allows the progress logging to be turned off (the “Submitting job to…” and “Job: …” logs) by setting verbose=False (defaults to True). This is useful for repeated calls within a loop.

Documentation Additions

  • Hardware Benchmarking Guide: Covering the new functional-level benchmarking suite, the different predefined benchmarks, how each is scored, and how to run them. For more information, see the Hardware Benchmarking section above.
  • QLayerV2 Guide: Covering the streamlined QLayerV2 layer for hybrid QNNs, its interface and observables, worked examples, and how to choose between it and the existing QLayer. For more information, see the New QLayer Interface for QNN section above.

Library Additions

  • Projection-Based Embedding: A notebook demonstrating the Wavefunction-in-DFT Embedding capability added in June, putting the EmbeddingCalculator to use on a water molecule. It treats a chemically active fragment with a quantum method such as VQE while describing the surrounding environment with DFT, then recombines the two to recover the total energy.
  • Numerical Gradient Estimation: Implementing Jordan’s algorithm to estimate the gradient of a d-dimensional scalar function with a single quantum query, in place of the d+1 evaluations a classical finite-difference approach would require.
  • Quantum Likelihood Estimation: A hybrid algorithm for Hamiltonian learning that identifies an unknown Hamiltonian, accessible only through the time evolution it generates, from a candidate set. It implements the optimal variant, developed with the paper’s authors, which jointly optimizes all five circuit parameters each iteration to make every measurement maximally informative. It converges in roughly an order of magnitude fewer experiments than standard QLE.

Bug Fixes

  • Synthesis now catches unsafe qubit-layout changes in control-flow blocks: reordering a quantum variable’s qubits inside a power, repeat, foreach, or if block is now rejected up front with a descriptive error.
  • Classical path operators return correctly-typed results: subscript, slice_, and reversed_ in the Python SDK now correctly infer their result type from their argument.
  • observe no longer emits a spurious deprecation warning: calling the observe function now runs cleanly, after previously surfacing a misplaced submit_estimate() is deprecated warning.
  • Quantum variable constructors reject non-string names cleanly: passing a non-string name to QArray, QNum, QBit, or QStruct now raises a clear error, where it previously failed internally.

Deprecations

  • QuantumProgram.qasm and transpiled_circuit deprecated: following the synthesis architecture update, these QuantumProgram attributes are replaced by export for a QASM circuit and get_circuit_metrics or get_transpiled_circuit_metrics for resource estimation, as covered in the synthesis architecture section above.
  • execute_qnn accepted observable type change: execute_qnn now takes its observable as a SparsePauliOp; passing the deprecated PauliOperator is converted automatically, and emits a DeprecationWarning.
  • slice Qmod operator renamed to slice_: calling slice now emits a deprecation warning; use slice_ instead.
For the technical entries behind these changes, see the Changelog.