Challenges
Datasets
Workspaces
Papers
Discussions
Leaderboard
Log inSign up
Challenges
Datasets
Workspaces
Papers
Discussions
Leaderboard
Blog
Job Board
Q3AS

© 2026 Aqora Quantum S.A.S.

TermsPrivacyLegal Notice

Bringing your Quantum Applications to DLR Quantum Hardware: The QCI Connect SDK

Gary Schmiedinghoff, Elisabeth Lobe, David da Costa, Thomas Keitzl, Johannes Renkl, Stehle, Thomas, Lukas Windgätter

Published May 11, 2026• 0 citations
OpenAlex

Related papers

QCI Connect SDK: A Flexible Toolbox for bringing Applications to Quantum Computers

Gary Schmiedinghoff, Elisabeth Lobe, Thomas Stehle +4 more

•Jul 10, 2026•0 citations

Access to Quantum Computers and Simulators via QCI Connect

Keitzl, Thomas

The presentation contains the current state of the QCI Connect Platform, Client and SDK. It was given along with a live demonstration of the access to the DLR's quantum computers.

•May 9, 2025•0 citations

QCI Connect: A Modular Full-Stack Quantum Computing Platform

Eric Bertok, Hannes Busche, Florian Drinkler +17 more

In a world of various competing quantum computing architectures, hardware-agnostic, full-stack platforms are necessary to bring the full power of quantum computing hardware to domain experts via the cloud. QCI Connect and its Software Development Kit provide a reference architecture for a full-stack platform with a modular design and open-source interface definitions, built to facilitate a community-driven application ecosystem. Here, we present its overall design and features, central interfaces, and lessons learned, both for users of the platform and as a reference guide for future developments.

quant-pharXiv:2606.14456•Jun 15, 2026•0 citations

Quantum Software Tools Overview

José A. Cruz-Lemus, Manuel Serrano

Springer eBooks•Jan 1, 2022•2 citations

Connecting Quantum Software Stacks - MQSS and QCI Connect

Ioan-Albert Florea

Quantum computing systems are increasingly accessed through software stacks that hide hardware-specific details behind higher-level abstractions. This is necessary because current quantum resources differ in their physical realisation, supported program formats, execution parameters, calibration data, status models, and result representations. At the same time, independent software stack initiatives create an interoperability challenge: even systems with similar goals may not communicate directly if their APIs encode different assumptions. This thesis studies this problem for the Munich Quantum Software Stack (MQSS), whose backend abstraction is the Quantum Device Management Interface (QDMI), and QCI Connect, a modular full-stack quantum computing platform developed within the DLR Quantum Computing Initiative. The goal is to connect these systems bidirectionally while preserving their architectural abstractions. In one direction, MQSS resources are exposed as QCI Connect QPUs via a dedicated QPU connector. In the other direction, QCI Connect is exposed as a QDMI-compatible device that translates QDMI session, query, job, status, cancellation, and result calls into QCI Connect API requests. The thesis compares the relevant API concepts and implements mappings for resource discovery, job submission, status handling, cancellation, and result retrieval. The implementation shows that bidirectional communication is feasible through existing extension points in both stacks. It also reveals semantic mismatches, including incomplete metadata equivalence, differences in status granularity, assumptions about circuit formats, and result fields requiring custom handling. These findings show that interoperability between quantum software stacks is possible, but long-term portability requires clearer standardisation of capabilities, execution parameters, status models, and result schemas.

•Jul 14, 2026•0 citations

QCSim, Quantum Computation Simulator

Paul E. Black

•Dec 1, 2003•0 citations
In a world of various competing quantum computing architectures, hardware-agnostic, full-stack platforms are necessary to bring the full power of quantum computing hardware to domain experts via the cloud. QCI Connect and its Software Development Kit provide a reference architecture for a full-stack platform with a modular design and open-source interface definitions, built to facilitate a community-driven application ecosystem. Here, we present its overall design and features, central interfaces, and lessons learned, both for users of the platform and as a reference guide for future developments.
Quantum computing systems are increasingly accessed through software stacks that hide hardware-specific details behind higher-level abstractions. This is necessary because current quantum resources differ in their physical realisation, supported program formats, execution parameters, calibration data, status models, and result representations. At the same time, independent software stack initiatives create an interoperability challenge: even systems with similar goals may not communicate directly if their APIs encode different assumptions. This thesis studies this problem for the Munich Quantum Software Stack (MQSS), whose backend abstraction is the Quantum Device Management Interface (QDMI), and QCI Connect, a modular full-stack quantum computing platform developed within the DLR Quantum Computing Initiative. The goal is to connect these systems bidirectionally while preserving their architectural abstractions. In one direction, MQSS resources are exposed as QCI Connect QPUs via a dedicated QPU connector. In the other direction, QCI Connect is exposed as a QDMI-compatible device that translates QDMI session, query, job, status, cancellation, and result calls into QCI Connect API requests. The thesis compares the relevant API concepts and implements mappings for resource discovery, job submission, status handling, cancellation, and result retrieval. The implementation shows that bidirectional communication is feasible through existing extension points in both stacks. It also reveals semantic mismatches, including incomplete metadata equivalence, differences in status granularity, assumptions about circuit formats, and result fields requiring custom handling. These findings show that interoperability between quantum software stacks is possible, but long-term portability requires clearer standardisation of capabilities, execution parameters, status models, and result schemas.