---
title: 'Cqlib: Quantum SDK for Cloud Services'
url: https://www.emergentmind.com/topics/cqlib
type: topic
---

# Cqlib: Quantum SDK for Cloud Services

Searching arXiv for recent papers mentioning Cqlib and closely related terms to ground the article.
Cqlib is an open-source software development kit (SDK) and quantum computing programming framework used to expose the Tianyan Quantum Cloud Platform as a cloud service. In the Tianyan ecosystem, it is described as software for “executing algorithms on quantum systems,” “designed for working with quantum systems at the level of extended quantum circuits, operators, and primitives,” and built upon the Quantum Computing Instruction Set (QCIS) as its core framework [2512.10504]. The published description presents Cqlib not as a thin job-submission client, but as an end-to-end layer spanning circuit construction, transpilation, execution, and post-processing for cloud-accessible superconducting quantum hardware integrated with simulators and HPC servers.

## 1. Definition and functional scope

Within the Tianyan platform, Cqlib is the user-facing software stack that makes a superconducting quantum processor available as a cloud service rather than merely as a laboratory system. The paper calls it both an “open-source software development kit (SDK)” and an “open-source quantum computing programming framework,” and states that it provides “an end-to-end toolkit for scientific experiments and software developments” [2512.10504]. The appendix further attributes to it three broad capability classes: “End-to-end quantum circuit processing,” “High-efficiency simulation and visualization,” and “Cross-platform and cross-ecosystem compatibility.”

The most explicit abstraction-level description is that Cqlib is “designed for working with quantum systems at the level of extended quantum circuits, operators, and primitives” [2512.10504]. The paper does not provide formal API definitions for “extended quantum circuits,” “operators,” or “primitives,” and it does not spell out a formal object model for these abstractions. A cautious interpretation, consistent with the published wording, is that Cqlib exposes higher-level programming objects above QCIS while retaining a direct connection to hardware-executable representations.

## 2. Architectural model

The architecture described for Cqlib is hybrid and service-oriented. User code is written against high-level software abstractions, but execution proceeds through a backend infrastructure that includes a scheduler, quantum circuit simulators, HPC servers, and quantum hardware systems [2512.10504]. The paper states that, during execution, “HPC servers act as the classical collaborator, coordinating circuit dispatch, sampling collection, and associated data-processing routines,” and that “hybrid tasks can be executed in an iterative manner across quantum systems and HPC backends.”

This architecture is significant because it places Cqlib inside a tightly coupled quantum-classical control loop rather than a simple remote-batch interface. The platform description emphasizes “local low-latency interaction between quantum and HPC systems” via compact deployment. In that model, Cqlib mediates not only circuit submission but also hardware-aware compilation, scheduling, optimization, retrieval, and result analysis. The appendix’s statement that Cqlib is built on QCIS as its core framework is especially important in this context: it suggests a layered stack in which instruction-set-level control and user-level workflow abstractions coexist within one software environment.

## 3. Four-stage programming workflow

The clearest operational description of Cqlib is a four-step workflow that the paper states is “compatible with its software architecture shown in Fig. 3” [2512.10504]. The steps are circuit construction, transpilation, execution, and post-processing. In prose, the workflow begins with translating a classical problem into quantum circuits built using high-level abstractions, continues through transpilation with qubit mapping and structural optimization, then submits tasks to Tianyan’s scheduling system, and finally post-processes the returned data.

| Stage | Representative interfaces and modules |
|---|---|
| Circuit construction | `from cqlib_experiments.rcs.circuit import setup_circuit_with_depth` |
| Transpilation | `TianYanPlatform`, `download_config(machine='tianyan-287')`, `from cqlib.mapping import transpile` |
| Execution | `run_task(config, transpiled_circuits, shots=samples, auto_opt=True)`, `supremacy_result(task_id)` |
| Post-processing | `download_data(task_id, file_name=f'{task_id}.zip')`, `show_opt_parameters(config, task_id)` |

The worked example shows that the demonstrated user model is Python-based and object/programmatic. In the circuit-construction step, the package `cqlib_experiments` is used to generate random circuits from a list of logical qubits, a dictionary of connection patterns `A`, `B`, `C`, and `D`, a list of circuit depths, and a repetition count. In the transpilation step, a `TianYanPlatform` object is initialized with a login key, hardware configuration is retrieved with `download_config(machine='tianyan-287')`, and `transpile(circuit, config)` converts logical circuits into hardware-compatible instructions according to the topology and gate parameters of the `tianyan-287` system [2512.10504].

The execution step is batch-oriented and job-based. The example submits transpiled circuits through `run_task`, specifies a shot count, and receives a `task_id` that can later be resolved through `supremacy_result(task_id)`. The post-processing step includes archival download of the result package and visualization of optimization parameters. The paper states that post-processing is used to evaluate final fidelity using the XEB model and to visualize results.

## 4. Execution semantics and role in Tianyan benchmark workloads

Cqlib’s most detailed published use case is the random circuit sampling (RCS) workflow on Tianyan hardware. The example shows batch execution with `shots=samples`, where `samples = 30000`, and enables `auto_opt=True` so that, after sampling, an automatic optimization module on the locally connected HPC refines gate parameters [2512.10504]. The text explains that this optimization is applied to the output distributions and is used to refine iSWAP-like gate parameters; the code comment mentions optimization of the `fsim` gate model.

The benchmark context matters because it shows what Cqlib is operationally capable of driving. The Tianyan paper reports a “cloud-accessible superconducting quantum prototype, named Tianyan-287,” with “105 qubits” and operational fidelities of “99.90%,” “99.56%,” and “98.7%” for single-qubit gates, two-qubit gates, and readout, respectively [2512.10504]. For a random circuit sampling task on “a 74-qubit system over 24 cycles,” the platform is reported to complete “one million samples in just 18.4 minutes,” whereas “state-of-the-art classical supercomputers would require approximately 16,000 years to complete the equivalent calculation.”

In the benchmark design used to illustrate Cqlib, iSWAP-like two-qubit gates are arranged in patterns `A`, `B`, `C`, and `D`, executed in the sequence `ABCD–CDAB` within each cycle, while single-qubit gates are randomly chosen from the set $\{\sqrt{X},\sqrt{Y},\sqrt{W}\}$ [2512.10504]. The software role of Cqlib in this setting includes circuit generation and parameterization, hardware-aware compilation, job submission and tracking, sampling collection, HPC-assisted parameter optimization, and post hoc fidelity analysis and visualization. The paper does not state that Cqlib itself implements the tensor-network classical verification algorithms used to estimate classical cost; its role is the hardware-side and workflow-side execution path.

## 5. Interoperability, platform coverage, and ecosystem position

The appendix places considerable emphasis on Cqlib’s interoperability. It states that the framework offers “Cross-platform and cross-ecosystem compatibility,” including native support for “two major quantum computing cloud platforms (Tianyan and QuantumCTek),” and interoperability with “Qiskit, Cirq, and PennyLane through adapters” [2512.10504]. This positions Cqlib less as a closed single-vendor runtime than as an integration layer connecting multiple cloud services and software ecosystems.

The same appendix attributes to Cqlib native support for simulation and visualization. It describes “High-efficiency simulation and visualization” as including classical simulation and verification of quantum circuits together with visual displays of circuits and results. The body text further indicates that Cqlib is already used to access several Tianyan systems through the cloud service. Figure 1 is described as stating that the listed systems are cloud-accessible via Cqlib, and the named systems include Tianyan-287, Tianyan-176, Tianyan-504, and Tianyan-24 [2512.10504].

The paper repeatedly calls Cqlib open-source, but it does not provide a repository URL in the text available here. It likewise does not document package installation, versioning, release processes, or command-line tooling. These omissions are notable because they delineate the difference between the published platform description and a full SDK manual.

## 6. Limits of the published description and terminological distinctions

The paper’s treatment of Cqlib is substantial enough to establish its architectural role, but it remains selective. It gives one detailed RCS workflow and a high-level summary of capabilities, yet it does not provide a formal API reference, a full specification of the core abstractions, or a broad application portfolio beyond the benchmark example [2512.10504]. It also does not discuss queue times, service-level guarantees, pricing, user quotas, or access restrictions. The conclusion explicitly notes that “RCS tasks based on iSWAP-like gates have limited practical application,” which constrains how far the flagship demonstration can be generalized as evidence of wider utility.

The name also requires disambiguation. In the arXiv literature, **Cqlib** should be distinguished from **CQ**, which is “a specification for a C-like API for quantum accelerated HPC” together with the C99 reference implementation CQ-SimBE; CQ focuses on runtime offloading from languages such as C and Fortran in hybrid quantum-classical HPC settings [2508.10854]. It should also be distinguished from **CQL** in corpus linguistics, where CQL denotes Corpus Query Language and appears in work on text-to-CQL semantic parsing for corpus search engines [2402.13740]. By contrast, the revived CERNLIB status report explicitly states that “CQLIB is not mentioned anywhere in the paper,” so the term does not denote a documented CERNLIB component in that source [2303.07506].

Taken together, the current arXiv record supports a precise characterization: Cqlib is the central software entry point for Tianyan’s cloud quantum service, built on QCIS and organized around circuit construction, transpilation, execution, and post-processing, with tight integration into simulators, HPC servers, and superconducting hardware backends [2512.10504]. The same record also shows that the published description is a platform-level overview rather than exhaustive SDK documentation, and that the term must be carefully separated from the distinct arXiv usages of CQ and CQL.

Source: https://www.emergentmind.com/topics/cqlib