Pith. sign in

REVIEW 5 major objections 5 minor 40 references

A Practical Open-Source Software Stack for a Cloud-Based Quantum Computing System

T0 review · 5 major / 5 minor · reviewed 2026-08-06 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗ Review JSON

Pith's one-line read OQTOPUS is a fully open-source software stack that operates a real cloud quantum computer end to end, demonstrated here by two live jobs on a superconducting chip.

desk verdict OQTOPUS is a real, open-source stack worth knowing; just don't trust the paper's claims about multiprogramming or error mitigation until they are actually tested. read the letter →

arxiv 2507.23165 v1 pith:IFWXRINT submitted 2025-07-31 quant-ph

Norihiro Kakuko , Shun Gokita , Naoyuki Masumoto , Keita Matsumoto , Kosuke Miyaji , Takafumi Miyanaga , Toshio Mori , Haruki Nakayama
show 5 more authors
Keita Sasada Yasuhito Takamiya Satoyuki Tsukano Ryo Uchida Masaomi Yamaguchi
This is my paper · ORCID
classification quant-ph
keywords quantumcomputingcloudservicessoftwareopen-sourcetranspilermulti-programmingerrormitigationOQTOPUS
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

The paper aims to prove that a practical cloud-based quantum computing system can be built entirely from open-source software, including the backend layers closest to the chip that commercial vendors keep closed. It introduces OQTOPUS, a three-layer stack spanning a user-side Python frontend, a serverless cloud job manager, and a backend that transpiles, schedules, and executes circuits on real hardware. The authors' central claim is that any institution with a quantum chip and a pulse controller can adopt the released software and stand up a working quantum cloud service, which they argue is the missing precondition for standardization and for scaling toward supercomputer-class workloads. A sympathetic reader would care because, if true, the result turns hardware ownership into a deployable service and opens the field to groups that today face a prohibitive software barrier.

What carries the argument

The central object is OQTOPUS, a three-layer software architecture named in the paper. In the frontend layer, QURI Parts OQTOPUS converts user-written Python circuits into OpenQASM 3 jobs; in the cloud layer, OQTOPUS Cloud and OQTOPUS Frontend authenticate users, store jobs, and expose an OpenAPI interface that lets third-party frontends and devices attach; in the backend layer, OQTOPUS Engine, Tranqu, Tranqu Server, and Device Gateway implement the six key features — server-side transpilation, server-side execution of hybrid algorithms, multi-programming, error mitigation, estimation, and the composer. The load-bearing design decision is that everything except the composer runs on the provider's side next to the chip, where qubit connectivity and live calibration data are known, so the system can tune transpilation and error mitigation to the device's current state without requiring users to requeue between iterations.

What would settle it

Deploy OQTOPUS from the public repository with a simulator as the Device Gateway backend and run the paper's two code listings unchanged, then submit several two-qubit circuits both separately and as one batched multi-programming job: the central claim is refuted if the released source cannot complete the documented path, or if batching does not reduce total wall-clock time compared with running the jobs sequentially.

Watch

Extended reading notes

Core claim

The paper presents OQTOPUS (Open Quantum Toolchain for OPerators and USers) as one of the largest open-source quantum computing software projects, and its discovery is that a full-stack system of this kind can be assembled, released, and operated in practice. The stack spans a frontend built around the QURI Parts Python library, a serverless cloud layer on AWS that manages users and jobs, and a backend — the part vendors rarely disclose — containing the OQTOPUS Engine, the Tranqu transpiler framework and its server, and the Device Gateway that talks to the pulse controller. In that backend layer the paper implements six key features: server-side transpilation, server-side execution of quantum–classical hybrid algorithms, multiprogramming of several circuits onto one chip, readout error mitigation, expectation-value estimation, and a visual circuit composer. The paper reports that the system has begun operating a real 64-qubit superconducting quantum computer, and it demonstrates two live jobs — a one-qubit sampling run and a two-qubit estimation run, each of 1000 shots — as evidence that a user with only hardware and pulse software can run quantum computation through the stack.

Load-bearing premise

The load-bearing premise is that the six implemented features actually work and deliver their claimed benefits, since the only evidence offered is a one-qubit sampling job and a two-qubit estimation job, each with 1000 shots and no error analysis or comparison against a baseline or another system.

Editorial extensions

If this is right

  • Any organization that owns quantum hardware can launch a functional quantum cloud service using only publicly available components, removing the need to build job management, transpilation, and calibration software from scratch.
  • The OpenAPI-based interface between the cloud and backend layers means third-party frontends and third-party quantum devices can plug into the same system, which the paper identifies as a path toward standardization.
  • Server-side execution lets a quantum–classical hybrid algorithm hold the quantum chip for an entire optimization loop without being requeued between iterations, removing a major source of waiting in current services.
  • Because error mitigation and estimation run in the backend, they can be matched to real-time error conditions on the device and combined — for example, estimation jobs automatically use the readout error mitigator.
  • Releasing calibration workflow software (QDash) alongside the execution stack reduces the dependence of qubit calibration on individual researcher expertise, making reproducible system operation more accessible.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • A consequence the paper leaves implicit is that an open backend commoditizes quantum hardware access: if the full stack is public, vendors compete on qubit quality, price, and uptime rather than on proprietary software lock-in.
  • The paper's throughput claim for multi-programming is untested, but it is directly checkable: submit N identical two-qubit circuits both sequentially and as one batched job on the same device and compare wall-clock time per circuit.
  • Since the error-mitigation and estimation features wrap existing Qiskit components, the natural next experiment is to compare the packaged server-side versions against running the same Qiskit code in a user's local environment, isolating whether automatic tuning to live calibration data adds value.
  • The declared plan to automatically combine circuits from different users would convert multi-programming from a manual tool into a system scheduling policy, raising a real design question about which circuits should share a chip and how fairness is preserved.
Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

5 major / 5 minor

Summary. The paper presents OQTOPUS, an open-source full-stack software stack for cloud-based quantum computing, covering a frontend layer (QURI Parts OQTOPUS), a cloud layer (OQTOPUS Cloud and Frontend), a backend layer (OQTOPUS Engine, Tranqu, Tranqu Server, Device Gateway), and operations tools (OQTOPUS Admin, QDash). The authors claim six key features—server-side transpiler, server-side execution, multi-programming, error mitigation, estimation, and composer—implemented in the backend layer, and they report two use cases against a real superconducting quantum computer: a 1-qubit sampling job and a 2-qubit estimation job. The paper's central claim is that OQTOPUS is a complete, publicly available path from user circuit submission to execution on real hardware, lowering the barrier to entry into the quantum computing field.

Significance. If the claims are borne out, OQTOPUS would be a valuable community resource: it is an unusually complete open-source stack that includes operational software (user management, calibration, web UI) that is typically proprietary. The public GitHub repositories, documentation, and API references are concrete artifacts that the community can inspect, reuse, and extend. The paper also identifies a real gap—the scarcity of open software close to the quantum hardware—and proposes a layered architecture with standard technologies. However, the significance as a scientific contribution is limited by the absence of quantitative validation: the paper demonstrates that the system can run two trivial jobs, but it does not show that the claimed efficiency/effectiveness features (multiprogramming, error mitigation, server-side execution) work as intended, nor does it compare against baselines or quantify noise/error characteristics. The release itself is the main contribution; the experimental and comparative claims are currently unsupported.

major comments (5)
  1. [Section IV (Use Cases) / Listing 1 and Listing 2] The only experiments reported are a 1-qubit H-gate sampling job and a 2-qubit CNOT estimation job, each with 1000 shots. Neither of these exercises the features that the paper identifies as key contributions: multi-programming (Section III.C.1.b), error mitigation (Section III.C.1.c), or server-side execution (Section III.C.1.a). The abstract's claim that OQTOPUS enables quantum computing 'effectively and efficiently' and the second contribution bullet ('we implement key features') are therefore not supported by the presented data. I request additional experiments that directly validate multiprogramming (e.g., throughput or qubit-utilization comparison vs. sequential execution), error mitigation (e.g., accuracy vs. no mitigation on a biased readout), and server-side execution (e.g., a hybrid loop that does not requeue).
  2. [Section III.C.1.b (Multi-Programming)] The description of multiprogramming is too high-level to verify correctness: it says that multiple circuits are 'combined' into one, executed, and results are 'divided,' but it does not specify the qubit-allocation policy, how cross-circuit crosstalk is avoided, or how the combined measurement outcomes are mapped back to individual circuits. A bug in any of these steps would silently corrupt results, yet no experiment or unit test is shown. Please provide a precise algorithmic description (or a reference to the code) and a correctness check, for instance by comparing multiprogrammed results against the same circuits executed individually on the same device.
  3. [Section III.C.1.c (Error Mitigation)] The error-mitigation section says the system is based on Qiskit's 1-qubit tensor-product readout mitigator and is 'automatically tuned to real-time error conditions,' but it does not describe how the calibration data are obtained, how often they are refreshed, or what improvement is expected. No experiment demonstrates that error mitigation increases accuracy in this deployment. Please include a measurement of readout assignment error, a description of the calibration procedure, and a comparison of mitigated vs. unmitigated results for the sampling or estimation job.
  4. [Section IV.B (Estimation Job)] The estimation example (Listing 2) computes an expectation value for H = 1.5XX + 1.2YZ on the state produced by a CNOT applied to |00>, for which the ideal value is exactly 0 (since XX and YZ both have zero diagonal matrix elements in the computational basis). The paper shows only the UI screenshot and does not report the numerical result, error bars, or a comparison to the ideal value. Reporting the measured expectation value and its deviation from the ideal (with and without error mitigation) is necessary to establish that the estimation pipeline is correct and useful.
  5. [Section II / Table I] Table I asserts that OQTOPUS is the only system among IBM Quantum, Amazon Braket, Azure Quantum, Qibo, and qBraid that provides all six features publicly ('P'), but the classification is not justified beyond pointing to marketing pages. The criteria for 'P' (public vs. non-public) are not defined, and the table conflates feature existence with public availability. For example, the claim that IBM Quantum lacks multiprogramming appears to conflict with the existence of batched execution in Qiskit Runtime; the table needs a precise definition and verifiable references for each cell (ideally repository links or documentation URLs, not just homepages).
minor comments (5)
  1. [Title/Abstract] The phrase 'one of the world's largest open-source software projects' is an unsupported superlative; consider replacing it with a measurable criterion (e.g., number of lines of code, number of repositories, or number of components).
  2. [Section III.C (Backend Layer)] The paper uses 'Tranqu' both as the transpiler framework and as part of 'Tranqu Server'; the relationship is clear, but the notation is inconsistent. Consider writing 'Tranqu (framework)' and 'Tranqu Server (service)' consistently throughout.
  3. [References] Reference [2] contains a typo: 'Bracket' should be 'Braket'. Reference [40] has 'develoment' instead of 'development'.
  4. [Figures 2 and 3] The screenshots in Figure 2 and Figure 3 are discussed in the text, but the captions do not state what the axes or displayed numbers mean, nor do they identify the device calibration date/time. Adding a short explanation of the UI elements would improve reproducibility.
  5. [Section III.D (Operation)] The description of QDash says it 'improves reproducibility and efficiency' but no evidence is given, and it is unclear how QDash is evaluated. A citation to a longer description or a demonstration would help.

Circularity Check

0 steps flagged · score 1.0 of 10

No significant circularity: OQTOPUS is a systems-implementation paper with no derivation chain, fitted parameters, or predicted quantity; the two hardware use cases are direct execution traces, and the self-references are inspectable artifact pointers that carry no derived conclusion.

full rationale

OQTOPUS is a software-systems paper, not a derivation paper: it contains no equations, no fitted parameters, and no quantity predicted from a model, so no step reduces to its own input by construction. The two experimental use cases in Section IV are direct execution traces (a 1-qubit H-gate sampling job and a 2-qubit CNOT estimation of the operator 1.5XX + 1.2YZ, 1000 shots each) whose evidence base is real measurement on the Osaka University hardware, an independent physical event; the central claim that the full stack exists and is open remains externally checkable through the public GitHub repository cited as [15]. Candidate self-references are not load-bearing: [15] (the OQTOPUS repository), [35] (ouqu-tp, attributed to Osaka University, which overlaps with several co-authors' affiliation), and [40] (the team's own API reference) are pointers to inspectable software artifacts, and none is used to justify a derived conclusion. The 'QCOps' nomenclature is explicitly presented as a relabeling of DevOps and MLOps, not as a derived result. Two validation gaps should be weighed as non-circular weaknesses: the headline multi-programming feature (Section III.C.1.b) is never exercised, since both use cases submit single circuits, and the paper itself states that 'an automatic combining mode of multiple quantum circuits requested by different users is also planned for implementation'; and the error-mitigation benefit (Section III.C.1.c) is never quantified against an unmitigated baseline, with the estimation result shown without comparison to the ideal expectation value. Section V also concedes that the quantum control system and system monitoring tools remain future work, bounding the full-stack claim. These are missing-evidence concerns rather than circularity, so the circularity score is low.

Assumptions & free parameters 0 free parameters · 4 assumptions · 1 invented entities

The paper has no free parameters or fitted values. It relies on domain assumptions about the chosen error mitigator, AWS architecture, OpenQASM 3, and the value of multiple transpilers. The only invented entity is the OQTOPUS software stack itself, which is open-source and thus independently checkable.

assumptions (4)
  • domain assumption The 1-qubit tensor product readout error mitigator from Qiskit is an appropriate and effective error mitigation technique for the system.
    Section II.C.c describes the error mitigation implementation as based on Qiskit's 1-qubit tensor product readout error mitigator, with no experimental validation of its effectiveness in OQTOPUS.
  • domain assumption The AWS serverless architecture is a suitable and sufficiently secure foundation for a quantum cloud execution environment.
    Section III.B states the cloud layer is built on AWS with a serverless architecture, relying on AWS services for security without quantitative risk analysis.
  • domain assumption OpenQASM 3 is a sufficiently expressive intermediate representation for the intended quantum computations.
    Section III.A.1 uses OpenQASM 3 as the circuit representation; the success of the system depends on its adequacy.
  • domain assumption The transpilation problem requires heuristics and no single transpiler dominates, motivating the Tranqu framework.
    Section II.C.2 states transpilers solve an NP-complete problem, so multiple transpiler comparison is useful; this is a background assumption about transpiler quality variance.
invented entities (1)
  • OQTOPUS (Open Quantum Toolchain for OPerators and USers) independent evidence
    purpose: Full-stack open-source software system for operating a cloud-based quantum computing service, including frontend, cloud, and backend layers.
    The system is publicly available on GitHub and docs, providing a falsifiable handle. However, its scientific validation in this paper is minimal.

how reviews work

0 comments
Cite this review

Pith. "Pith review of A Practical Open-Source Software Stack for a Cloud-Based Quantum Computing System." pith.science (2026). https://pith.science/paper/IFWXRINT

@misc{pith2026250723165,
  author       = {Pith},
  title        = {Pith review of: A Practical Open-Source Software Stack for a Cloud-Based Quantum Computing System},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/IFWXRINT}},
  note         = {Machine review of arXiv:2507.23165}
}
read the original abstract

Since the late 2010s, quantum computers have become commercially available, and the number of services that users can run remotely via cloud servers is increasing. In Japan, several domestic superconducting quantum computing systems, including our own, began operation in 2023. However, the design of quantum computing systems, especially in the most critical areas near quantum computers, remains largely undisclosed, creating a significant barrier to entry into the quantum computing field. If this situation continues, progress toward standardization, which is essential for guiding quantum computer development, will stall, and it will be difficult to develop a practical quantum computing system that can perform calculations on a supercomputer scale. To address this issue, we propose Open Quantum Toolchain for OPerators and USers (OQTOPUS), a full-stack quantum computing system developed from research with real quantum computers. OQTOPUS is one of the world's largest open-source software projects, covering operational software from cloud-based execution environment construction to system operation. Furthermore, to perform quantum computing effectively and efficiently, it implements key features, such as transpilers, multiprogramming, and error mitigation, in an area as close as possible to a quantum computer, an area that system vendors rarely disclose. Finally, this study presents experimental results of applying OQTOPUS to a real quantum computer. OQTOPUS is publicly available on GitHub and will notably lower the barrier to entry into the quantum computing field, contributing to the formation of a quantum computing developer community through open discussion.

Figures

Figures reproduced from arXiv: 2507.23165 by the authors.

Figure 1
Figure 1. Overview of OQTOPUS [PITH_FULL_IMAGE:figures/full_fig_p003_1.png] view at source ↗

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

40 extracted references · 39 canonical work pages

  1. [1]

    IBM Quantum,

    The IBM Quantum development team , “IBM Quantum,” [Online]. Available: https://quantum.ibm.com/, accessed:2025-03-03. Fig. 2. Sampling result displayed via OQTOPUS Frontend UI. Fig. 3. Estimation result displayed using OQTOPUS Frontend UI. 7

    work page 2025

  2. [2]

    Amazon Braket ,

    The Amazon Bracket development team , “Amazon Braket ,” [Online]. Available: https://aws.amazon.com/braket/, accessed:2025-03-03

    work page 2025

  3. [3]

    Azure Quantum,

    The Azure Quantum development team , “Azure Quantum,” [Online]. Available: https://azure.microsoft.com/en-us/solutions/quantum- computing, accessed:2025-03-03

    work page 2025

  4. [4]

    Japan’s First Homemade Quantum Computer Goes Online,

    The RIKEN Center for Quantum Computing , “Japan’s First Homemade Quantum Computer Goes Online,” [Online]. Available: https://www.riken.jp/en/news_pubs/news/2023/20230921_3/index.html, accessed:2025-03-03

    work page 2023

  5. [5]

    Fujitsu and RIKEN Develop Superconducting Quantum Computer at the RIKEN RQC -Fujitsu Collaboration Center, Paving the Way for Platform for Hybrid Quantum Computing,

    Fujitsu Limited, “Fujitsu and RIKEN Develop Superconducting Quantum Computer at the RIKEN RQC -Fujitsu Collaboration Center, Paving the Way for Platform for Hybrid Quantum Computing,” [Online]. Available: https://www.fujitsu.com/global/about/resources/news/press- releases/2023/1005- 01.html?_gl=1*a797ew*_gcl_au*MTMzNzkxNjg5OS4xNzQwNTUzMj I5*_ga*MTEzMTk3MD...

    work page 2023

  6. [6]

    Research Group Launches Japan’s Third Quantum Computer at Osaka University,

    Center for Quantum Information and Quantum Biology, Osaka University, “Research Group Launches Japan’s Third Quantum Computer at Osaka University,” [Online]. Available: https://www.fujitsu.com/global/about/resources/news/press- releases/2023/1220-01.html, accessed:2025-04-14

    work page 2023

  7. [7]

    Quantum Robustness Verification: A Hybrid Quantum-Classical Neural Network Certification Algorithm,

    N. Franco, T. Wollschläger, N. Gao, J. M. Lorenz , and S. Günnemann, “Quantum Robustness Verification: A Hybrid Quantum-Classical Neural Network Certification Algorithm,” 2022 IEEE International Conference on Quantum Computing and Engineering (QCE), pp. 142-153, 2022

    work page 2022

  8. [8]

    cuQuantum SDK: A High -Performance Library for Accelerating Quantum Science,

    H. Bayraktar, A. Charara, D. Clark, S. Cohen, T. Costa, Y. L. Fang, et al., “cuQuantum SDK: A High -Performance Library for Accelerating Quantum Science, ” 2023 IEEE International Conference on Quantum Computing and Engineering (QCE), pp. 1050-1061, 2023

    work page 2023

Show all 40 references
  1. [9]

    Cut&Shoot: Cutting & Distributing Quantum Circuits Across Multiple NISQ Computers,

    G. Bisicchia, A. Bocci, J. García -Alonso, J. M. Murillo , and A. Brogi, “Cut&Shoot: Cutting & Distributing Quantum Circuits Across Multiple NISQ Computers, ” 2024 IEEE International Conference on Quantum Computing and Engineering (QCE), pp. 187-192, 2024

    2024

  2. [10]

    Available: https://qibo.science/, accessed:2025-03-03

    The Qibo development team, “Qibo,” [Online]. Available: https://qibo.science/, accessed:2025-03-03

    2025

  3. [11]

    Available: https://www.qbraid.com/, accessed:2025-03-03

    The qBraid development team, “qBraid,” [Online]. Available: https://www.qbraid.com/, accessed:2025-03-03

    2025

  4. [12]

    Available: https://www.cda.cit.tum.de/research/quantum/qdmi/, accessed:2025-03- 03

    The QDMI development team, “QDMI,” [Online]. Available: https://www.cda.cit.tum.de/research/quantum/qdmi/, accessed:2025-03- 03

    2025

  5. [13]

    Strangeworks,

    The Strangeworks development team, “Strangeworks,” [Online]. Available: https://strangeworks.com/, accessed:2025-03-03

    2025

  6. [14]

    Quantinuum Nexus ,

    The Quantinuum Nexus development team, “Quantinuum Nexus ,” [Online]. Available: https://nexus.quantinuum.com/, accessed:2025-03- 03

    2025

  7. [15]

    Open Quantum Toolchain for OPerators and USers (OQTOPUS),

    The OQTOPUS development team, “Open Quantum Toolchain for OPerators and USers (OQTOPUS),” [Online]. Available: https://oqtopus- team.github.io/, accessed:2025-03-21

    2025

  8. [16]

    QURI Parts,

    The QURI Parts development team, “QURI Parts,” [Online]. Available: https://quri-parts.qunasys.com/, accessed:2025-03-04

    2025

  9. [17]

    QURI Parts,

    The QURI Parts development team, “QURI Parts,” gitHub repository. [Online]. Available: https://github.com/QunaSys/quri-parts, accessed:2025-03-04

    2025

  10. [18]

    Available: https://www.ibm.com/quantum/qiskit, accessed:2025-03-03

    The Qiskit development team, “Qiskit,” [Online]. Available: https://www.ibm.com/quantum/qiskit, accessed:2025-03-03

    2025

  11. [19]

    Array Programming with NumPy,

    C. R. Harris, K. J. Millman, S. J. van der Walt, R. Gommers, P. Virtanen, D. Cournapeau, et al., “Array Programming with NumPy,” Nature, vol. 585, pp. 357–362, 2020

    2020

  12. [20]

    SciPy 1.0: Fundamental Algorithms for Scientific Computing in Python,

    P. Virtanen, R. Gommers, T. E. Oliphant, M. Haberland, T. Reddy, and D. Cournapeau, et al., “SciPy 1.0: Fundamental Algorithms for Scientific Computing in Python,” Nature Methods vol. 17, pp. 261-272, 2020

    2020

  13. [21]

    OpenQASM 3: A Broader and Deeper Quantum Assembly Language,

    A. Cross, A. Javadi-Abhari, T. Alexander, N. D. Beaudrap, L. S. Bishop, S. Heidel, et al., “OpenQASM 3: A Broader and Deeper Quantum Assembly Language,” ACM Transactions on Quantum Computing, vol. 3, no. 3, pp. 1-50, 2022

    2022

  14. [22]

    Understanding the Difference between Traditional and Serverless Development,

    The AWS development team, “Understanding the Difference between Traditional and Serverless Development,” [Online]. Available: https://docs.aws.amazon.com/serverless/latest/devguide/serverless-shift- mindset.html, accessed:2025-03-04

    2025

  15. [23]

    AWS Best Practices for DDoS Resiliency,

    The AWS development team, “AWS Best Practices for DDoS Resiliency,” [Online]. Available: https://docs.aws.amazon.com/whitepapers/latest/aws-best-practices- ddos-resiliency/aws-best-practices-ddos-resiliency.html, accessed:2025- 03-04

    2025

  16. [24]

    OpenAPI Specification,

    The OpenAPI Specification development team, “OpenAPI Specification,” gitHub repository. [Online]. Available: https://github.com/OAI/OpenAPI-Specification/, accessed:2025-04-10

    2025

  17. [25]

    Amazon Cognito,

    The AWS development team, “Amazon Cognito,” [Online]. Available: https://aws.amazon.com/cognito/, accessed:2025-03-04

    2025

  18. [26]

    Amazon API Gateway ,

    The AWS development team, “Amazon API Gateway ,” [Online]. Available: https://aws.amazon.com/api-gateway/, accessed:2025-03-04

    2025

  19. [27]

    AWS Lambda ,

    The AWS development team, “AWS Lambda ,” [Online]. Available: https://aws.amazon.com/lambda/, accessed:2025-03-04

    2025

  20. [28]

    Amazon Relational Database Service ,

    The AWS development team, “Amazon Relational Database Service ,” [Online]. Available: https://aws.amazon.com/rds/, accessed:2025-03-04

    2025

  21. [29]

    Amazon Amplify,

    The AWS development team, “Amazon Amplify,” [Online]. Available: https://aws.amazon.com/amplify/, accessed:2025-03-18

    2025

  22. [30]

    Available: https://grpc.io/, accessed:2025-03-03

    The gRPC development team, “gRPC,” [Online]. Available: https://grpc.io/, accessed:2025-03-03

    2025

  23. [31]

    A Case for Multi - programming Quantum Computers ,

    P. Das, S. S. Tannu, P . J. Nair, and M. Qureshi, “A Case for Multi - programming Quantum Computers ,” Proceedings of the 52nd Annual IEEE/ACM International Symposium on Microarchitecture, pp. 291-303, 2019

    2019

  24. [32]

    A New Qubits Mapping Mechanism for Multi- programming Quantum Computing,

    X. Dou and L. Liu, “A New Qubits Mapping Mechanism for Multi- programming Quantum Computing,” Proceedings of the ACM International Conference on Parallel Architectures and Compilation Techniques, pp. 349-350, 2020

    2020

  25. [33]

    Enabling Multi-programming Mechanism for Quantum Computing in the NISQ Era,

    S. Niu and A. Todri-Sanial, “Enabling Multi-programming Mechanism for Quantum Computing in the NISQ Era,” 2021, arXiv: 2102.05321. [Online]. Available: https://arxiv.org/abs/2102.05321

    2021 arXiv

  26. [34]

    Quantum Multi- programming for Grover’s Search,

    G. Park, K . Zhang, K . Yu, and V. Korepin, “Quantum Multi- programming for Grover’s Search,” 2022, arXiv: 2207.14464. [Online]. Available: https://arxiv.org/abs/2207.14464

    2022 arXiv

  27. [35]

    ouqu-tp,

    The ouqu-tp development team, “ouqu-tp,” gitHub repository. [Online]. Available: https://github.com/Qulacs-Osaka/ouqu-tp, accessed:2025-03- 03

    2025

  28. [36]

    What is a RESTful API?,

    The AWS development team, “What is a RESTful API?,” [Online]. Available: https://aws.amazon.com/what-is/restful-api/?nc1=h_ls, accessed:2025-04-10

    2025

  29. [37]

    [Online]

    The Qulacs development team, “Qulacs,” gitHub repository. [Online]. Available: https://github.com/qulacs/qulacs, accessed:2025-03-03

    2025

  30. [38]

    Critical Challenges to Adopt DevOps Culture in Software Organizations: A Systematic Review,

    M. S. Khan, A. W. Khan, F. Khan, M. A. Khan , and T. K. Whangbo, “Critical Challenges to Adopt DevOps Culture in Software Organizations: A Systematic Review,” IEEE Access, vol. 10, pp. 14339- 14349, 2022

    2022

  31. [39]

    Machine Learning Operations (MLOps): Overview, Definition, and Architecture,

    D. Kreuzberger, N. Kühl, and S. Hirschl, “Machine Learning Operations (MLOps): Overview, Definition, and Architecture,” IEEE Access, vol. 11, pp. 31866-31879, 2023

    2023

  32. [40]

    QURI Parts OQTOPUS API Reference

    The QURI Parts OQTOPUS develoment team, “QURI Parts OQTOPUS API Reference”, [Online]. Available: https://quri-parts- oqtopus.readthedocs.io/en/stable/reference/API_reference/, accessed:2025-03-17

    2025

Pith tools

Reviewed August 6, 2026 · model on record in the stance chip above.