Cqlib: Quantum SDK for Cloud Services

• Cqlib is a quantum computing SDK that streamlines circuit construction, transpilation, execution, and post-processing for cloud-accessible superconducting systems.
• Its hybrid architecture integrates high-level circuit abstractions with HPC, simulators, and quantum hardware, ensuring efficient quantum-classical workflows.
• Cqlib offers cross-platform compatibility by interfacing with Tianyan, QuantumCTek, Qiskit, Cirq, and PennyLane through specialized adapters.

Searching arXiv for 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 (Group, 11 Dec 2025). 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” (Group, 11 Dec 2025). 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” (Group, 11 Dec 2025). 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 (Group, 11 Dec 2025). 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” (Group, 11 Dec 2025). 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 (Group, 11 Dec 2025).

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 (Group, 11 Dec 2025). 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 (Group, 11 Dec 2025). 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}\}$ (Group, 11 Dec 2025). 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” (Group, 11 Dec 2025). 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 (Group, 11 Dec 2025).

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 (Group, 11 Dec 2025). 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 (Brown et al., 14 Aug 2025). 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 (Lu et al., 2024). 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 (Schwickerath et al., 2023).

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 (Group, 11 Dec 2025). 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.