> ## Documentation Index
> Fetch the complete documentation index at: https://docs.classiq.io/llms.txt
> Use this file to discover all available pages before exploring further.
# Release News: Aug-Sep 2026
Six versions released over August and September, headlined by the fault-tolerance engine and the new agentic Quantum Engineering interface.
> **[Key Updates: Fault Tolerance & Agentic AI](#fault-tolerance-engine)**
>
> A fault-tolerance engine and a new Quantum Engineering interface
> **[7 Enhancements](#enhancements)**
>
> Block encodings, batched observables, optimized arithmetic, and more
> **[6 Documentation & Library Additions](#documentation-additions)**
>
> Fault-tolerance and block-encoding guides, a revamped Qmod tutorial
> **[11 Bug Fixes & Deprecations](#bug-fixes)**
>
> Correctness fixes, deprecations, and breaking changes
## Fault-Tolerance Engine
Classiq's new [fault-tolerance engine](https://docs.classiq.io/user-guide/error-correction.md) sheds light on what a fault-tolerant quantum program would actually cost to run on error-corrected hardware. It routes a synthesized program, whether you wrote it in Qmod, took a ready-made example from the [Classiq Library](https://github.com/Classiq/classiq-library), or built it with the new [Quantum Engineering interface](#quantum-engineering-interface), onto a surface-code lattice, and estimates the total logical error of the whole computation at each code distance you choose. Because it works from a concrete lattice-surgery plan, the estimate includes costs that gate counts miss, such as idle steps and long CNOT paths.
### Choosing a Noise Model and Routing
The engine first needs a logical noise model, which gives the error rate of each error-corrected operation, such as an idle step, a CNOT, or a T gate, as a function of the code distance. Load a precomputed [public model](https://docs.classiq.io/user-guide/error-correction/noise-models.md), such as the generic `public/depolarize_1e-3` or the illustrative `public/google_willow_like` and `public/ibm_heron_r2_like`, or [simulate one](https://docs.classiq.io/user-guide/error-correction/logical-noise.md) from the physical error rates of your device of choice.
Next, transpile the program to Clifford+T with [`export`](https://docs.classiq.io/sdk-reference/synthesis#export), setting the maximum total approximation error allowed for its rotations, and pass the result to [`route_circuit`](https://docs.classiq.io/sdk-reference/error-correction#route_circuit), which places each logical qubit on a surface-code patch and schedules every operation as lattice surgery, including the magic-state cultivation each T gate needs.
[comment]: DO_NOT_TEST
```python theme={null}
from classiq import *
from classiq.error_correction import get_logical_noise, route_circuit
# Loading a public logical noise model; any public model name works here
logical_noise = get_logical_noise("public/depolarize_1e-3")
# Transpiling the synthesized program (qprog) to Clifford+T
clifford_t_qasm = export(
qprog,
target_language=TargetLanguage.QASM2,
transpilation_config=FaultTolerantTranspilationConfig(
# Setting the maximum total approximation error allowed for the rotations
clifford_t_approximation_error=1e-3
),
)
# Routing the Clifford+T circuit onto the surface-code lattice
topological_program = route_circuit(clifford_t_qasm)
```
### Visualizing the Routed Program
[`view_program`](https://docs.classiq.io/sdk-reference/error-correction#view_program) renders the routed plan as an interactive 3D page, with the grid of patches on the horizontal axes and time, in cycles, on the vertical axis.
### Estimating the Total Logical Error
Finally, [`estimate_total_errors`](https://docs.classiq.io/sdk-reference/error-correction#estimate_total_errors) combines the routed program with the logical noise model and returns the estimated total logical error, `1 - fidelity`, at each code distance you pass.
[comment]: DO_NOT_TEST
```python theme={null}
from classiq.error_correction import estimate_total_errors
# Estimating the total logical error at each given code distance
total_errors = estimate_total_errors(
topological_program, logical_noise, code_distances=[11, 13, 15]
)
```
In the [end-to-end tutorial](https://docs.classiq.io/explore/tutorials/technology_demonstrations/fault_tolerance_engine_end_to_end/fault_tolerance_engine_end_to_end.md), running the engine on a small quantum phase estimation (QPE) with 3 phase qubits under the `public/depolarize_1e-3` noise model gives these results:
| Code distance | Physical qubits required | Total logical error | Fidelity |
| - | - | - | - |
| 11 | 2,445 | 0.188 | 0.812 |
| 13 | 3,357 | 0.040 | 0.960 |
| 15 | 4,413 | 0.009 | 0.991 |
The tutorial counts physical qubits from the routed layout: 2d² − 1 for each surface-code patch, plus 2d + 1 for each boundary strip that joins neighboring patches (d is the code distance).
For a full walkthrough, refer to the Error Correction [user guides](https://docs.classiq.io/user-guide/error-correction.md) and [SDK reference](https://docs.classiq.io/sdk-reference/error-correction.md).
## Quantum Engineering Interface
The new agentic Quantum Engineering interface, accessible via the [Classiq web platform](https://platform.classiq.io/), lets you create quantum algorithms and applications alongside the meticulously crafted Quantum Engineer agent, leveraging the full Classiq stack.
You set the goal in natural language, or attach a paper, a circuit image, or a code file, and the agent proposes a plan and works through it with you: designing the algorithm, writing the Qmod model, synthesizing it into a quantum program, executing it, and analyzing the results, all in one thread. Each step produces an interactive **artifact** you can open, review, and build on: the Qmod code, the quantum program visualizer, the execution results, and an analysis report.
The agent explaining a generated Grover model, with the Code artifact open alongside the chat.
To open the new interface, available to users with an active Classiq subscription, click **Try now** on the banner at the top of the platform's home page. For a full walkthrough, see the [Quantum Engineering Interface](https://docs.classiq.io/user-guide/ai/quantum-engineering-interface.md) user guide.
### One AI Layer, Two Entry Points
Unlike a general-purpose coding agent on its own, the Quantum Engineer is built on the Classiq AI layer: skills, tools, and MCP capabilities that integrate directly with the full Classiq API. It is this layer that gives the Quantum Engineer agent its edge; every step harnesses Classiq's own core technology, and its skills are grounded in the Classiq knowledge base and continuously evaluated against rigorous internal benchmarks. The interface is one of two ways into this layer. The other is the [Quantum Engineer plugin](https://docs.classiq.io/user-guide/ai/quantum-engineer-plugin.md), which brings it into agentic coding platforms such as Claude Code, Cursor, Codex, and Copilot.
```mermaid theme={null}
%%{init: {"flowchart": {"wrappingWidth": 240}, "themeCSS": ".nodeLabel, .nodeLabel p, .nodeLabel span { font-weight: normal; } .nodeLabel b { font-weight: bold; }"}}%%
flowchart TB
local["Your local environment:
Quantum Engineer plugin"]
web["Classiq web platform:
Quantum Engineering interface"]
layer["Classiq AI layer:
Skills, tools,
and MCP capabilities"]
core["Core Classiq capabilities:
Modeling, synthesis,
and execution"]
docs["Reference material:
Classiq documentation and
algorithms library"]
local -- "Installed in coding agents" --> layer
web -- "Embedded in the platform" --> layer
layer -- "Skills and tools" --> core
layer -- "MCP" --> docs
```
The Quantum Engineer plugin is available as a zip file under **More from Classiq** in the interface sidebar. To install it, follow the [installation steps](https://docs.classiq.io/user-guide/ai/quantum-engineer-plugin.md#installation) in the user guide, or ask your coding agent to do it for you.
## Enhancements
### Composable Block Encodings
The new [`BlockEncoding`](https://docs.classiq.io/user-guide/applications/block-encoding) class turns block encodings, the primitive underneath QSVT, qubitization, and Hamiltonian simulation, into objects you can combine just like the matrices they encode. Each block encoding carries its scaling factor, number of block qubits, and approximation error, and every sum, product, or other composition returns a new encoding with these already computed, so you don't need to work out the block sizes or scaling factors yourself.
* **Create an encoding:** From a dense matrix (optionally with the [FABLE algorithm](https://arxiv.org/abs/2205.00081)), a sparse Pauli operator (encoded by default with the new [`unary_select`](https://docs.classiq.io/sdk-reference/qmod/functions/open_library/unary_iteration#unary_select) open library function), or constant diagonals.
* **Combine encodings:** Add, multiply, scale, or take tensor products of encodings to get an encoding of the sum, product, scaled matrix, or tensor product of the encoded matrices. A single encoding can also be turned into an encoding of the inverse matrix or into its qubitized walk operator.
* **Check the implemented matrix:** `to_matrix` reconstructs the encoded matrix by simulation, up to a global phase, so you can compare it with the matrix you expect.
```python theme={null}
from classiq import *
from classiq.applications.block_encoding import BlockEncoding
# Create: encodings of two sparse Pauli operators
be_a = BlockEncoding.from_sparse_pauli_op(0.5 * Pauli.X(0) + 0.5 * Pauli.Z(0))
be_b = BlockEncoding.from_sparse_pauli_op(Pauli.Z(0))
# Combine: an encoding of the product of the two encoded matrices
product = be_a @ be_b
# Check: the encoded product matrix, up to a global phase
print(product.to_matrix())
```
### Faster Batched Observable Estimation
[`observe`](https://docs.classiq.io/user-guide/execution/observe) now accepts a list of observables and evaluates them in a single call, instead of one call per observable. Before execution, each observable is split into groups of terms that can be measured together, and groups that need the same measurement basis share one sampling run, so the number of circuit executions drops sharply. The [Adapt-QAOA](https://github.com/Classiq/classiq-library/blob/main/applications/optimization/adapt_qaoa/adapt_qaoa.ipynb), [Adapt-VQE](https://github.com/Classiq/classiq-library/blob/main/algorithms/quantum_state_preparation/adapt_vqe/adapt_vqe.ipynb), and [Fermi-Hubbard](https://github.com/Classiq/classiq-library/blob/main/applications/physical_systems/fermi_hubbard_model_1D/fermi_hubbard_1D.ipynb) notebooks now use batched observables, with these observed speedups:
| Workload | Speedup |
| - | - |
| Adapt-QAOA, one iteration | over 20x |
| Adapt-VQE, full algorithm | about 10x |
| Fermi-Hubbard, full algorithm | about 10x |
For Fermi-Hubbard, this reduces the cost that had kept larger 1D and 2D instances out of reach. Because observables may now share a sampling run, their expectation values can be correlated rather than independently sampled. For details, see [Batch of observables](https://docs.classiq.io/user-guide/execution/observe.md#batch-of-observables).
Observable estimation also gains two smaller improvements:
* [`ExecutionSession.observe`](https://docs.classiq.io/sdk-reference/execution#observe) and [`ExecutionSession.submit_observe`](https://docs.classiq.io/sdk-reference/execution#submit_observe) now take an `estimate` argument, matching the standalone `observe`. Pass `estimate=False` on the [Classiq simulator](https://docs.classiq.io/user-guide/execution/cloud-providers/classiq-backends.md#simulator-usage) to compute the exact expectation value from the state vector, free of shot noise, for noiseless programs of up to 26 qubits.
* An observable can now act on fewer qubits than the program, and is automatically padded with identities on the remaining qubits.
### Optimized Comparisons and Increments
Two of the most common arithmetic operations in Qmod, comparing a quantum number against a constant and incrementing it by 1, now use dedicated primitives. Each has several variants that trade auxiliary qubits against gate count, and the compiler picks the one that fits your [optimization parameter](https://docs.classiq.io/sdk-reference/synthesis.md#constraints) and a `max_width` [constraint](https://docs.classiq.io/user-guide/synthesis/constraints.md), if you set one.
* **Constant comparisons:** Comparisons with [`<`, `<=`, `>`, or `>=`](https://docs.classiq.io/qmod-reference/language-reference/expressions#relational-operators), such as `x < 5`, no longer need an auxiliary quantum variable as wide as the operand:
* **Optimizing for width (the default):** The comparison uses no auxiliary qubits.
* **Optimizing for CX count:** The comparison uses auxiliary qubits to keep its CX count growing linearly with the operand's width, instead of quadratically as in the auxiliary-free variant. In addition, under a [`control`](https://docs.classiq.io/user-guide/modeling/controlled-operations#operations-controlled-by-expressions), each control qubit adds only 6 CX gates.
* **Increment by 1:** For an [in-place increment or decrement](https://docs.classiq.io/user-guide/modeling/quantum-numbers-arithmetics.md#two-common-in-place-operators) by 1 (`x += 1`, `x += -1`), including inside a `control` block, optimizing for width selects a QFT-based variant with no auxiliary qubits, and optimizing for CX count selects a fault-tolerant, Toffoli-based variant with far fewer CX gates. The [Discrete Quantum Walk](https://github.com/Classiq/classiq-library/blob/main/tutorials/advanced_tutorials/discrete_quantum_walk/discrete_quantum_walk.ipynb) tutorial now compares the new increment with a hand-built one.
### Earlier Qubit Release in Uncomputation
[Automatic uncomputation](https://docs.classiq.io/qmod-reference/language-reference/uncomputation.md#semantics-of-uncomputation) now releases auxiliary qubits as early as possible, reducing the width of the synthesized quantum program. This applies when the optimization parameter is `width` or left unset (the default). Models optimized for depth or gate count, and programs synthesized with `compatibility_mode=True`, are left unaffected. Releasing qubits earlier can require recomputing intermediate values later, so depth and two-qubit gate count may grow for some models.
### Upgraded Quantum Layer for QNNs
The quantum layer for training hybrid quantum neural networks gets two upgrades:
* [`QLayer`](https://docs.classiq.io/user-guide/applications/qml/qnn/qlayerv2) now builds the new, faster quantum layer, previously available only as `QLayerV2`. Pass `observables=...` to output expectation values, or use the new `readout` argument with `SamplingReadout` to sample the program and apply your own post-processing. The older call forms still build the classic `QLayerV1`, which is now deprecated, as described in [Deprecations](#deprecations) below.
* The layer trains in any environment where the SDK runs, not only in [Classiq Studio](https://docs.classiq.io/user-guide/studio.md). In Studio, it runs on the in-process simulator for circuits of up to 26 qubits, up from 12, and computes exact gradients for expectation-value outputs. Outside Studio, it runs the circuits on an execution backend instead.
### State Vectors of Up to 24 Qubits
[`calculate_state_vector`](https://docs.classiq.io/user-guide/execution/calculate-state-vector) on the [Classiq simulator](https://docs.classiq.io/user-guide/execution/cloud-providers/classiq-backends.md#simulator-usage) (`classiq/simulator`) and the [NVIDIA simulator](https://docs.classiq.io/user-guide/execution/cloud-providers/classiq-backends.md#nvidia-simulator-usage) (`classiq/nvidia_simulator`) now returns state vectors of up to 24 unfiltered qubits, up from 18. Update to SDK 1.31.0 or later to use it. Large state vectors take time to download and need several GB of memory from 22 qubits up, so [filter variables](https://docs.classiq.io/user-guide/execution/state-vector-filtering.md) or set an [amplitude threshold](https://docs.classiq.io/user-guide/execution/state-vector-filtering.md#amplitude-threshold) where you can.
### Parsing Results from Other Platforms
The new [`parse_sample_result(qprog, counts)`](https://docs.classiq.io/sdk-reference/execution#parse_sample_result) function turns a raw bitstring histogram into the same DataFrame format that [`sample`](https://docs.classiq.io/user-guide/execution/sample) returns. Use it when you run an exported circuit elsewhere, such as on an external simulator or on hardware, and want to bring the results back into Classiq. For CUDA-Q-style bitstrings, pass `bit_order=BitOrder.QUBIT_ZERO_LEFT`, or use [`parse_cudaq_result`](https://docs.classiq.io/sdk-reference/cudaq#parse_cudaq_result), which applies that setting for you.
## Documentation Additions
* **[Quantum Engineering Interface](https://docs.classiq.io/user-guide/ai/quantum-engineering-interface.md) Guide:** Covers how to open the new web interface, run a task from idea to analyzed results in a single thread, work with the artifacts each step produces, and write effective prompts, expanding on the [Quantum Engineering Interface](#quantum-engineering-interface) section above.
* **[Fault-Tolerance Engine](https://docs.classiq.io/user-guide/error-correction.md) Guides:** Six pages covering every aspect of the engine, from [publicly available](https://docs.classiq.io/user-guide/error-correction/noise-models.md) and [custom](https://docs.classiq.io/user-guide/error-correction/logical-noise.md) noise models to [routing](https://docs.classiq.io/user-guide/error-correction/routing.md), [visualization](https://docs.classiq.io/user-guide/error-correction/visualization.md), and [total-error estimation](https://docs.classiq.io/user-guide/error-correction/total-error.md), complemented by an end-to-end tutorial notebook listed under [Library Additions](#library-additions) below. For a quick tour of the workflow, see the [Fault-Tolerance Engine](#fault-tolerance-engine) section above.
* **[Block Encoding](https://docs.classiq.io/user-guide/applications/block-encoding.md) Guides:** Three pages introducing the new [`BlockEncoding`](https://docs.classiq.io/sdk-reference/applications/block_encoding#blockencoding) class. [Constructing Block Encodings](https://docs.classiq.io/user-guide/applications/block-encoding/constructing-block-encodings.md) covers building block encodings from a dense matrix, a sparse Pauli operator, or constant diagonals, and [Composing Block Encodings](https://docs.classiq.io/user-guide/applications/block-encoding/composing-block-encodings.md) covers combining them and verifying the result, expanding on the example in the [Composable Block Encodings](#composable-block-encodings) section above.
* **Revamped [Qmod Tutorial](https://docs.classiq.io/getting-started/classiq_tutorial/Qmod_tutorial_part1.md):** The two-part, hands-on Qmod tutorial was rewritten from the ground up, as part of a broader revision of Classiq's tutorials, with new tutorials on the way. [Part I](https://docs.classiq.io/getting-started/classiq_tutorial/Qmod_tutorial_part1.md) covers the language foundations, from quantum variables and types to arithmetic and control, and [Part II](https://docs.classiq.io/getting-started/classiq_tutorial/Qmod_tutorial_part2.md) covers the statements and operators used to express real quantum algorithms, from phase statements to hybrid execution.
## Library Additions
* **[Fault-Tolerance Engine: End-to-End Tutorial](https://github.com/Classiq/classiq-library/blob/main/tutorials/technology_demonstrations/fault_tolerance_engine_end_to_end/fault_tolerance_engine_end_to_end.ipynb):** Walks you through the full fault-tolerance workflow step by step; it starts from a synthesized quantum program transpiled to Clifford+T, moves through noise-model selection, routing onto the surface-code lattice, and visualization, and ends with the estimated total logical error and physical-qubit count at each code distance.
* **Block-Encoding Notebooks Revisited:** Thirteen library notebooks now use the new [`BlockEncoding`](https://docs.classiq.io/sdk-reference/applications/block_encoding#blockencoding) class, including [QSVT matrix inversion](https://github.com/Classiq/classiq-library/blob/main/algorithms/quantum_linear_solvers/qsvt_matrix_inversion/qsvt_matrix_inversion.ipynb), [VQLS with LCU](https://github.com/Classiq/classiq-library/blob/main/algorithms/quantum_linear_solvers/vqls/vqls_with_lcu.ipynb), [Hamiltonian simulation with QSVT](https://github.com/Classiq/classiq-library/blob/main/algorithms/hamiltonian_simulation/hamiltonian_simulation_with_block_encoding/hamiltonian_simulation_qsvt.ipynb), [GQSP](https://github.com/Classiq/classiq-library/blob/main/algorithms/hamiltonian_simulation/hamiltonian_simulation_with_block_encoding/hamiltonian_simulation_gqsp.ipynb), and [qubitization](https://github.com/Classiq/classiq-library/blob/main/algorithms/hamiltonian_simulation/hamiltonian_simulation_with_block_encoding/hamiltonian_simulation_qubitization.ipynb), the [quantum linear solvers for CFD](https://github.com/Classiq/classiq-library/blob/main/applications/CFD/QLS_for_hybrid_solvers/qls_qsvt.ipynb), and the [Vlasov-Ampère](https://github.com/Classiq/classiq-library/blob/main/applications/plasma/vlasov_ampere/vlasov_ampere.ipynb) and [cooling systems optimization](https://github.com/Classiq/classiq-library/blob/main/applications/automotive/cooling_systems_optimization/cooling_systems_optimization.ipynb) applications.
## Bug Fixes
* **Uncomputation keeps rolled loops and `skip_control` bodies:** [Automatic uncomputation](https://docs.classiq.io/qmod-reference/language-reference/uncomputation.md) now preserves a rolled [`repeat`](https://docs.classiq.io/qmod-reference/language-reference/statements/classical-control-flow#classical-repeat) or [`foreach`](https://docs.classiq.io/qmod-reference/language-reference/statements/classical-control-flow#classical-foreach) loop, or a [`skip_control`](https://docs.classiq.io/qmod-reference/language-reference/statements/skip-control) body, in a function that has a variable to uncompute.
* **`power` and `invert` handle `repeat` and `foreach` loops correctly:** [`power`](https://docs.classiq.io/qmod-reference/language-reference/statements/power) now raises the whole loop to the power, where it previously raised each iteration to the power separately, and [`invert`](https://docs.classiq.io/qmod-reference/language-reference/statements/invert) now reverses the iteration order, where it previously kept the original order.
* **Output variable names can match result column names:** An output variable of `main` can now share a name with a column of the result DataFrame. In case of a name clash with a built-in column, such as `phase` in [`calculate_state_vector`](https://docs.classiq.io/user-guide/execution/calculate-state-vector), your variable keeps its name, the built-in column is renamed to `result_`, and a warning is issued.
## Deprecations
* **`observable` parameter renamed to `observables` in `observe`:** The second parameter of the standalone [`observe`](https://docs.classiq.io/user-guide/execution/observe) function is now named `observables`, and it also accepts a list, as covered in the [Faster Batched Observable Estimation](#faster-batched-observable-estimation) section above. Calls that use the old keyword, `observable=...`, raise a `TypeError`; use `observables=...` instead, or pass the argument without a keyword.
* **`hamiltonian` parameter deprecated in favor of `observables` in `ExecutionSession`:** The session's [`observe`](https://docs.classiq.io/sdk-reference/execution#observe) and [`submit_observe`](https://docs.classiq.io/sdk-reference/execution#submit_observe) now also take `observables`, which accepts a single observable or a list. Calls that use the old keyword, `hamiltonian=...`, still run with a deprecation warning, and `hamiltonian` will be removed in an upcoming release. For details, see the [dedicated section](https://docs.classiq.io/user-guide/execution/observe.md#observables-keyword-and-legacy-hamiltonian-support) of the `observe` user guide.
* **`ExecutionSession` estimate aliases removed:** The deprecated [`ExecutionSession`](https://docs.classiq.io/user-guide/execution/ExecutionSession) aliases `estimate`, `submit_estimate`, `batch_estimate`, and `submit_batch_estimate` have been removed. Use the session's [`observe`](https://docs.classiq.io/sdk-reference/execution#observe) or [`submit_observe`](https://docs.classiq.io/sdk-reference/execution#submit_observe) instead, passing a list of parameter dicts for batched execution.
* **`QLayer` now builds `QLayerV2`, and `QLayerV1` is deprecated:** Calling `QLayer` with the `observables` or `readout` keyword arguments now builds the new [`QLayerV2`](https://docs.classiq.io/user-guide/applications/qml/qnn/qlayerv2). The older call forms, `QLayer(qprog, post_process, ...)` and `QLayer(qprog, execute, post_process, ...)`, still build the classic [`QLayerV1`](https://docs.classiq.io/user-guide/applications/qml/qnn/qlayer), now with a deprecation warning. `QLayerV1` will be removed in a future release.
* **Qubit-layout check extended to `control`, `invert`, and function bodies:** A quantum variable must now end a `control` or `invert` block (or a function body) with the same qubit layout it started with, extending the [check added in July](https://docs.classiq.io/release-news/recap-july-2026.md#bug-fixes) for `power`, `repeat`, `foreach`, and `if` blocks. Programs that break this raise an error. To avoid the error, use [`bind`](https://docs.classiq.io/qmod-reference/language-reference/statements/bind) to re-join the variable's parts in their original order, as described in [Qubit Layout Stability](https://docs.classiq.io/qmod-reference/language-reference/statements/bind.md#qubit-layout-stability).
* **`inplace_binary_to_one_hot` in-out parameter split into `source` and `target`:** The open library function [`inplace_binary_to_one_hot`](https://docs.classiq.io/sdk-reference/qmod/functions/open_library/encodings#inplace_binary_to_one_hot) now takes separate input and output parameters (`source: Input[QArray]`, `target: Output[QArray]`) instead of a single in-out array parameter.
* **Run via Classiq restricted and emulation paused on Azure Quantum:** [Run via Classiq](https://docs.classiq.io/user-guide/execution/budget-management.md) is no longer available for [Azure Quantum backends](https://docs.classiq.io/user-guide/execution/cloud-providers/azure-backends.md) in the IDE, for both execution and benchmarking. The SDK also rejects it for Azure QPUs and for all Quantinuum targets, so pass your own Azure Quantum credentials to run on them. In addition, emulation on Azure is temporarily unavailable; to simulate IonQ hardware noise, use the [IonQ provider's `emulate` option](https://docs.classiq.io/user-guide/execution/cloud-providers/ionq-backends#ionq-hardware-noise-simulation-emulate) instead.
* **C12 backend preference field `ininoisy` renamed to `ininoise`:** The [`C12BackendPreferences`](https://docs.classiq.io/sdk-reference/providers/C12#c12backendpreferences) field now matches the C12 Callisto API. The old name is ignored without an error, so replace `ininoisy` with `ininoise` in any code that sets it.
## Announcements
Platform access is now by invitation only, and free access is not currently available. Existing users are unaffected and retain full access.
For the technical entries behind these changes, see the [Changelog](https://docs.classiq.io/release-notes.md).
This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.