Inspiration

Quantum computing is a promising new paradigm of computation with unexplored possibility—but unfortunately, there is a lack of knowledge about its capabilities. Even amongst experts, there is a gap in knowledge between what can be done in theory and how it performs in practice. Our product qpilot helps bridge this gap for both novices and experts by allowing novices to quickly design quantum circuits for their use cases and how they would perform in practice, and for experts, it allows them to design and optimize quantum circuits taking into the considerations and limitations of real world hardware.

What it does

qpilot is a full-stack quantum circuit platform that bridges theory and practice in three ways:

  • For novices: A Visual Circuit Composer lets you build circuits by dragging gates (H, X, Y, Z, CX, RZ, RX, Measure) onto a grid, with live QASM output, probability charts, and a Q-sphere view so you can see how circuits behave without writing code. An AI agent can generate circuits from plain English (e.g. “Create a 3-qubit quantum teleportation circuit”) using a multi-turn, tool-using workflow that validates and self-corrects the generated QASM.

  • For experts: A Code Editor supports OpenQASM 2.0 with one-click optimization for real hardware. You pick a backend (e.g. IBM Brisbane, Google Sycamore, Rigetti Aspen, IonQ) and a strategy (Fast, Balanced, Aggressive, Quartz superoptimization, or Hybrid). The pipeline shows input → baseline → optimized with gate count, depth, estimated cost, and fidelity. Compare Strategies and Compare Backends (or Compare Both) let you rank results by cost or fidelity across hardware and strategies in one view.

  • A single **AI Assistant* offers three modes: Optimize (improve an existing circuit and explain choices), Build (generate circuits from problem descriptions), and Demo. The build flow uses an agentic workflow with tools like validate_qasm and estimate_cost, multi-turn refinement, and optional LaTeX-style explanations (e.g. for QAOA or Grover). Optimize and Build each keep their own context so you can switch between editing in the code editor and the visual composer without the two interfering.

Deployed Architecture:

  • Production API: Modal (serverless GPU inference for RL optimization)
  • Frontend: Vercel Edge (global CDN with <50ms latency)
  • Local Version: Full feature set with PyTorch RL agent and Quartz superoptimization

How we built it

  • Backend (Python/FastAPI): REST API with lazy-loaded QuantumOptimizer that wires together circuit parsing (OpenQASM 2.0), a hardware database (IBM, Google, Rigetti, IonQ), and an optimization strategy layer. Optimization uses Qiskit transpilation (levels 1–3) plus optional Quartz-inspired superoptimization and a dedicated IonQ path. Fidelity and cost are estimated from backend metadata. Comparison endpoints run the same circuit across many backend/strategy pairs and return sortable results.

  • AI agents: A meta-coordinator routes user intent (optimize vs build vs explain) to specialist agents. The “Claude Agent SDK”–style builder (backed by Gemini/Claude) does multi-turn circuit generation with tool use (validate_qasm, estimate_cost, get_example_circuit), self-validation, and iterative correction. The RL Optimizer and LLM Circuit Builder handle optimization explanations and “explain this circuit,” using a model router (Gemini first, then GPT/Claude) for cost and compatibility.

  • Frontend (vanilla JS/CSS): Single-page app with resizable panels, tabbed Code Editor and Visual Composer (each with its own QASM so they don’t overwrite each other), pipeline UI for optimization stages, comparison tables (sort by cost or fidelity), circuit SVGs/PNGs, and an embedded AI terminal with mode-specific greetings and workflow badges. KaTeX is used for math in agent messages.

  • Stack: Python 3.8+, FastAPI, Uvicorn, Vercel, Modal, Qiskit (and optional qiskit-ibm-runtime, qiskit-ionq), Anthropic/OpenAI/Google GenAI, BlueQubit (optional), PyTorch (optional for RL agent). Frontend uses no framework; static files served by FastAPI.

Challenges we ran into

Being our first time with this type of pipeline, it took a few hours to get our local version hosted in Railway so that Vercel handles the fronted. We wanted to launch this fully as a web app on Vercel however midway through the night, ran out of Vercel credits to keep developing and iterating, and thus had to move bad to developing our local version. We developed a robust Reinforcement Learning algorithm to optimize quantum circuits, based on

Accomplishments that we're proud of

  • Real hardware in the loop: Full optimization and comparison against multiple backends (IBM, Google, Rigetti, IonQ) with strategy-specific behavior (e.g. IonQ-only strategy for IonQ hardware) and honest fidelity/cost estimates.

  • Agentic circuit generation: Build-from-description uses a multi-turn agent with tools, validation, and self-correction—demonstrable via workflow steps and iteration/tool counts—so generated circuits are valid and cost-aware instead of one-shot guesses.

  • Dual editing experience: Code Editor and Visual Composer are first-class; each keeps its own QASM, and you can toggle between them at any time. Optimize and Compare always use whichever tab is active, and the AI assistant reflects the active tab’s circuit in its context.

  • Quartz-style optimization: Integration of research-based and optimized (including both accuracy and efficiency optimization) Quartz-based superoptimization (RL-search) alongside standard Qiskit levels and a hybrid strategy, so users can trade off speed vs gate reduction and depth.

  • Hybrid deployment strategy: Built two versions—a cloud-deployed web app (Modal + Vercel) for accessibility and a feature-complete local version with advanced RL optimization—demonstrating both production readiness and technical depth.

  • Democratization through AI: 97% success rate on standard quantum algorithms means non-experts can generate production-quality circuits (4-qubit Grover, QFT, QAOA) from natural language, lowering the barrier from PhD-level to undergraduate-accessible.

What we learned

  • Theory vs practice is real: Real backends have coupling maps, gate errors, and coherence limits that drastically change which circuits are viable; showing baseline vs optimized and fidelity/cost side-by-side makes that gap tangible for both beginners and experts.

  • Agents need structure: Multi-turn flows with tools (validate, estimate cost) and clear failure handling produce much more reliable circuit generation than a single prompt; surfacing “iterations” and “tools used” in the UI helps users trust the process.

  • Editor state is tricky: Sharing one buffer between code and visual editors caused subtle bugs; having two explicit sources of truth and a single “active” reader (getActiveQASM()) simplified behavior and made tab switching predictable.

What's next for qpilot

  • Stronger RL optimizer: Since, we faced both time and technical difficulties for training and fine-tuning the RL agent on real optimization traces, if given more time we would focus on this so strategy and parameter suggestions are more tailored to each backend and use case. We would implement more optimizations, such as curriculum learning, and graph pooling, as well as finetuning the model for specific inputs.

-Scalable Deployment: If we didn't run out of Vercel credits, we intended to full deploy this as a scalable web-app through the platform. This would also be a simple next step.

Built With

  • anthropic-claude-api
  • bluequbit
  • claude-agent-sdk
  • docker
  • edge-cdn
  • fastapi
  • google-gemini
  • google-quantum-ai
  • html5-drag-&-drop-api
  • ibm-quantum
  • ionq
  • javascript
  • katex
  • modal
  • multi-model-llm-routing
  • openai-gpt-4
  • openqasm-2.0
  • python
  • pytorch
  • qiskit
  • qiskit-aer
  • qiskit-ibm-runtime
  • qiskit-ionq
  • quartz-optimization
  • railway
  • reinforcement-learning
  • rest
  • rigetti-computing
  • serverless-gpu
  • uvicorn
  • vercel
Share this project:

Updates