RoRo Quantum
Open console
Playbooks · Chapter 12 of 14

For hackathons

Fork, run, ship to hardware without regret.

~2 min read4 sectionssame text as the guide inside the lab
All chapters
Overview
Start here
Getting started
Working in the lab
Projects & files Run a circuit Python in the browser Notebooks Circuit builder & emulator Library Copilot
Reference
Machines & credits Sharing & GitHub Keyboard shortcuts
Playbooks
For hackathons For teams & integration For researchers

Words marked like thisin the lab are buttons inside the lab — they open a panel, a dialog or the tour there. On this page they are plain text.

Keys are written for macOS, the way the lab prints them — on Windows and Linux read ⌘ as Ctrl, ⌥ as Alt, ⇧ as Shift, ↵ as Enter.Keys are shown for Windows / Linux to match your platform — on a Mac, Ctrl is ⌘ and Alt is ⌥. Every binding: Keyboard shortcuts.

On this page
Hour zero: get a working thingWorking as a teamPutting it on hardware without regretDemo day

You have a weekend, a team, and a judge who wants to see something run on real hardware. Here is the fastest honest path.

Hour zero: get a working thing

  1. Open the library galleryin the lab. Pick something on the Applications or Algorithms shelf close to your idea — every card there runs here, free. Open it, read what it teaches and the observed output, press Fork into a project.
  2. It opens on the entry file. Press ▶ Run file (Python) or look at the .qasm in Circuit view and press ∿ emulate. You now have output on screen inside five minutes.
  3. Ask Copilotin the lab: "Explain this project, file by file." Then: "Change it to solve my problem" — read the diff card before Apply.

Working as a team

  • One project per person, ⌘O to switch; Share gives teammates a read-only snapshot link they can Copy into my lab. There is no live co-editing — pass snapshots, or keep the source of truth in a GitHub repo and import from the Source control rail (public URL, or My repos if GitHub is connected).
  • Everyone gets the same 48-item library and the same machines, so a teammate can reproduce your run from the codename alone.
  • Keep the demo path in a README.md in the project — the editor renders nothing special for it, but it is the first thing a forker sees.

Putting it on hardware without regret

  • Iterate on the simulator: instant, cheap, and the quote on the Run rail is the truth of what a real submission will hold.
  • Switch Machine to real hardware only when the circuit is final. Read the Run on real hardware? dialog: machine, codename, shots, hold, balance. Real queues take minutes to hours — submit early, keep working, the run updates itself in the Runs rail even if you close the lab.
  • 1024 shots is plenty for a histogram that tells a story; more shots is more credits, linearly.
  • If a machine reads queue N or offline, pick another — the codename in your code is a one-line change.
  • A machine-side failure is refunded automatically; a queued run you cancel is refunded. Nothing else is.

Demo day

  • Select the finished run in Runs → the dock shows the timeline, histogram and credit line. Explain this result produces a narration you can read aloud (metered, cancellable).
  • Put the simulator run and the hardware run side by side: the forbidden outcomes that appear only on hardware are the story — the GHZ template exists for exactly this.
  • Share the project so judges can open the code without an account.

Related: Library · Run a circuit · Copilot