Qiskit Global Summer School 2026: 4 labs, 473 seconds of real quantum time, 1 badge

At 20:43 on Friday 24 July, 1 Estimator call on ibm_marrakesh consumed 264 seconds of real quantum processor time. That is 44% of everything the free IBM plan gives you in a month, spent on 1 cell of 1 notebook, 5 days before a deadline. The notebook offered a simulator instead. I ran it on the machine, because the lesson was on the machine.

That job is 1 line in the logbook of the Qiskit Global Summer School 2026, and the logbook is why this post exists, more than the Quantum Excellence badge IBM issued for it on 21 August. The badge is my 6th IBM Quantum credential. The 5 before it, from the first in May to the general formulation badge in June, were courses, some with a 20 question exam at the end, and they attest to understanding. I was careful to say so each time.

This one is different. It came from 2 weeks of lectures and 4 graded labs, each a Jupyter notebook that hands you a half written function and a grader that inspects the object your code produces. In the last 2 labs, the object came back from a real quantum computer. You do not pass by knowing the answer. You pass by making the answer run. And there was a deadline, 29 July at noon Eastern, with work on my side of the Atlantic that did not care about it.

I am a self taught automation builder. No physics degree, no computer science degree, in quantum since 1 paragraph about Grover's algorithm caught me in the spring. A program with a grader and a clock is the kind of thing the version of me from a year ago assumed was for other people. So instead of remembering the 2 weeks, I pulled the list.

The logbook, from my own job history

What follows is not memory. It is the job list from my IBM Quantum account, exported and converted to my time zone. Every hardware run leaves a record: a job ID, a timestamp, a backend, a program type, the seconds of QPU time it consumed, and the tags you attached. Most of the lab notebooks tagged their jobs qgss26, and the 2 runs that went out untagged are easy to pick out by their circuits.

My IBM Cloud instance was created on 22 June. My first job ever on a real machine ran on 24 June, on ibm_kingston, at 21:39. Before the first job with the school's tag on it, I had 15 hardware jobs to my name. Everything ran on the free Open Plan of the IBM Quantum Platform, which gives you 10 minutes of real QPU time per 28 day window. Here is every run that belongs to the summer school, in German time, which is the time zone I was sitting in when I pressed run. The first line is Lab 0, the ungraded setup notebook released before the school opened, which ends with an optional run on a real machine. The last column is what the notebook said the cell would cost before you ran it.

473 seconds. Under 8 minutes of QPU time, spread over 4 evenings, 1 afternoon and 1 dawn, out of the 10 minutes the plan gives you. The estimates were honest, sometimes to the second: Lab 3 said 1 min 30 s and took 80 seconds, Lab 4b said 5 min 30 s and took 5 min 23 s without the bonus, the 4c sampling said 2 seconds and took 3. So the school quietly teaches you to budget a scarce resource, to know before you press run how much you are about to spend, and to retrieve a finished job by its ID instead of rerunning it when your kernel dies. Those are the skills I already had from running pipelines that cost money, and it was the first time I saw them written into a physics course as a first class concern.

2 things in that table are worth pointing at. The first is that the Lab 3 jobs are stamped 21:20 on Monday 20 July, and the Lab 3 notebook landed on GitHub that same afternoon at 17:36. I had it running on a real chip less than 4 hours after it existed. The second is the last line, and I will get to it.

What the Qiskit Global Summer School 2026 actually was

The Qiskit Global Summer School is IBM's free, online, 2 week program on quantum computing with Qiskit. The 2026 edition was its 7th year, and it ran from 13 to 24 July under the theme A decade on the cloud, because on 4 May 2016 IBM put a 5 qubit processor on the internet and let anyone run circuits on it. The 2016 announcement predicted machines of 50 to 100 qubits within 10 years. The machines in my table have 156.

IBM's attendee guide said about 12,000 people registered, and IBM Quantum's own wrap up post counted more than 5,000 attendees from 95 countries and nearly 1,900 cities. Registration opened on 26 May and was closed by 29 June. If you are thinking about 2027, that is the part to plan for. The labs give you 2 weeks. The registration window gave 5, and it did not wait.

The shape of a day was nearly fixed: a core lecture by an IBM Quantum researcher at 8:00 in the morning Eastern time, a live Q&A with that lecturer at 10:00, and around midday a lab release, a workshop or a guest lecture. 10 core lectures over the 2 weeks by IBM Quantum researchers, from Roland de Putter's opening on why quantum at all to a 4 part algorithms series that ends with Sabina Dragoi on optimisation. 4 distinguished speakers on top: Ignacio Cirac, Kenneth Merz and Fangchun Liang from the Cleveland Clinic, and Aram Harrow. And 4 optional workshops, one of them titled "Why Does Quantum Computing Seem Scary?". I live in Germany. 8:00 Eastern is 14:00 here, the middle of a working day, so I watched every lecture recorded, at my own pace.

The rules were explicit. The platform tracks how much of each video you actually watch, and to qualify for anything you needed 80% of all core lectures viewed. From there, a Certificate of Completion needed nothing else, the Quantum Fundamentals badge needed 1 or 2 labs completed, and the Quantum Excellence badge needed 3 or 4. Guest lectures, panels and workshops counted for nothing. Labs could be resubmitted as many times as you wanted, and only the highest score counted. The 80% is a watch time counter, and I know the difference between a counter and understanding. The labs were where the understanding got checked.

Lab 1: circuits for real hardware, in 2 languages

Lab 1, written by James Weaver, is about building circuits that survive contact with a real processor. It starts with X, H and CNOT and the Bell state, and turns into an engineering lab about depth. A GHZ state on N qubits is trivially a Hadamard followed by a chain of CNOTs, N layers deep, and depth is what costs you most on real hardware, because every layer is time and time is decoherence. So you fan out from the middle, then recursively, and the exercise asks for a 16 qubit GHZ state in depth 5. Then transpilation. Heron processors, the IBM generation every machine in my table belongs to, do not run H or CNOT natively. Their native gate set is RZ, SX, X and CZ, where SX is √X, and the transpiler rewrites everything else into those, on a heavy hex lattice where each qubit has 2 or 3 neighbours. A CNOT between qubits that are not neighbours costs SWAPs at 3 entangling gates each. The final challenge is a 64 qubit GHZ state on a simulated 133 qubit Heron, built from a breadth first search over the coupling map from qubit 25 and entangled along the resulting tree layer by layer.

New this year, Lab 1 also came in C++, written against the Qiskit C API. You only had to solve 1 version. I did both, in VS Code, on my own laptop, in an environment I had learned to pin the hard way 2 days before the school opened.

Lab 2: noise, backends, and 1 dynamic circuit on a real chip

Lab 2, by Alberto Maldonado Romo and Gwonhak Lee, is where the circuit model meets calibration data. You load the backend object for ibm_fez and read what defines a machine: native gates, coupling map, gate errors, readout errors, and T1 and T2, the 2 clocks that say how long a qubit keeps its energy and its phase. You build 3 toy noise models by hand, depolarising, Pauli and thermal relaxation, compare Heron's heavy hex lattice with Nighthawk, IBM's newer square lattice processor, by transpiling a 120 qubit GHZ circuit onto both, and finish with dynamic circuits, where a measurement in the middle of the circuit decides the next gate. The bonus is the second line in my table: a 12 qubit dynamic GHZ on ibm_marrakesh, Thursday 16 July at 22:00, 3 seconds. The notebook says the gap between the simulator's prediction and the real result is crosstalk, leakage, drift and the overhead of the classical feedforward, and that narrowing that gap is one of the central goals of error mitigation research. Which is Lab 3.

Lab 3: the one that cannot run on a simulator

Lab 3, by Sophy Shin and Sophie Engineer, is titled "Your New Tool For Quantum Advantage", and it opens with a sentence I had not seen in a course before: this lab requires execution on real hardware, and it is not possible to run it on a simulator. It is about learning the noise of a specific device and then using what you learned, and a simulator has no noise of its own to learn.

It starts with what the Qiskit Runtime already gives you as switches on the Estimator. Dynamical decoupling and Pauli twirling, which suppress errors before they land. TREX, ZNE, PEA and PEC, four error mitigation methods, which clean up afterwards, from correcting the readout to learning the noise and sampling circuits that invert it. The switches are whole circuit policies. Twirl every 2 qubit gate, decouple every idle window. They cannot treat one layer differently from another, and they cannot show you the noise they learned. 6 weeks later, in the Bell state post, where I ran the simplest entangled circuit on a real chip and accounted for every wrong answer, I switched 2 of them on and watched them do nothing. This lab had already explained why.

Then it hands you the tool that can. Samplomatic, a Qiskit library, lets you box up a slice of a circuit and annotate the box: Twirl, InjectNoise, ChangeBasis. NoiseLearnerV3 runs jobs on the real device to learn the Pauli noise of each entangling layer, and the Executor primitive runs the boxed program. The worked example is a 1D Ising chain, a line of spins each coupled to its neighbours, evolved with a Trotter circuit, the standard way of approximating time evolution with gates, and run forward and backward, so the ideal answer is known and the whole deviation is noise. On top sit 2 add ons: one rewrites the observable to absorb the learned noise, the other, shaded lightcones, cuts the sampling cost of PEC down to the part of the circuit an observable can actually see. I ran them on 10 and 15 qubits.

The overhead is the point of the whole lab. Error mitigation does not cost you qubits. It costs you shots, and for probabilistic methods that cost grows exponentially, with a base set by the learned noise. A lower gate error shrinks the base, and because the base is raised to the size of the circuit, a small improvement in hardware collapses the bill. I had read that sentence before. Lab 3 made me pay for it: 10 jobs on ibm_marrakesh between 21:20 and 21:37 on 20 July, the evening the lab was released, 80 seconds of QPU time. A month later, on 21 August, the day the badge was issued, my n8n node for IBM Quantum, the connector I maintain so that an automation workflow can submit circuits to IBM machines, was submitting noise learner jobs of its own.

Lab 4: towards quantum advantage, and the night I did not sleep

Lab 4 is 3 notebooks, written by Jorge Martínez de Lejarza and Boseong Kim, titled "Towards quantum advantage". It landed on GitHub on Thursday 23 July, 6 days before the deadline. It is the one I want to be most precise about.

Lab 4a is reading. It sends you to the paper "A Framework for Quantum Advantage" by Lanes and colleagues for the 2 criteria a computation must satisfy before anyone gets to use the phrase, then to the Quantum Advantage Tracker, the community run site that documents claimed demonstrations under 3 pathways, to look up 2 specific numbers: the lowest energy reported for an iron sulfur cluster with a particular method, and a Loschmidt echo on 49 qubits and 648 gates. It is the first time a lab made me read the primary literature to pass a grader.

Lab 4b is QAOA, the Quantum Approximate Optimization Algorithm, on the partition problem: split a list of numbers into 2 groups whose sums are as close as possible. The notebook turns a 6 number grocery example into a cost Hamiltonian whose couplings are the products of pairs of numbers, hands you a QAOA circuit with pretrained parameters, and sends it to the machine through the Sampler at 1,000 shots, 2 times: once with no mitigation, once with dynamical decoupling + twirling. 2 more jobs that Friday evening are tagged "M3 calibration", 8 circuits each at 4,096 shots, the runs mthree fires to correct readout errors without ever building the full 2ⁿ × 2ⁿ assignment matrix.

Then it scales. A 160 number problem needs 160 qubits the naive way. Pauli Correlation Encoding stores the variables in the correlations between pairs of qubits instead of in the qubits themselves, and the count comes out at 11. Exercise 4 sends the encoded problem through the Estimator in 4 runs with increasing ambition: nothing, TREX with twirling, ZNE with twirling, and PEC with twirling. The notebook warns you before the last one: 4 min 26 s of estimated QPU time for a single cell, and if you are not comfortable with that, run it on a simulator instead and lose the lesson.

I ran it on the machine. The PEC job on ibm_marrakesh consumed 264 seconds, 4 min 24 s, within 2 seconds of the estimate. 44% of the plan's allowance, on 1 Estimator call, on an 11 qubit circuit. The lecture on sampling overhead had a number in it now.

Then there was the bonus, and the bonus is where the lab held me. 10× larger: 1,600 numbers, which under the same encoding is a 34 qubit circuit. Not required for the badge. Scored from 0 to 100 on how small a difference you achieve between the 2 partitions, and only results from real hardware count. The recommended path trains the QAOA parameters on hardware in a session, about 32 seconds per iteration, 16 minutes for 30 iterations, 35 minutes estimated for the cell. By the free plan's arithmetic, 432 of the window's 600 seconds were already gone at that point in the evening: the 420 in the table and a 12 second job from 1 July that had nothing to do with the school. That left 168 seconds. So I took the path the notebook offers for people like me: skip the hardware training, measure the expectation value on hardware with untrained parameters, then do the rest with your head, a custom error mitigation configuration and a local search that flips single bits around the best solution decoded from the quantum run, to repair the flips the noise put there.

My last Estimator job of the night went out at 20:54 with readout mitigation, zero noise extrapolation and twirling all switched on, 4,096 shots, 50 seconds of QPU time. And then the post processing, which is classical. Whatever you think of quantum computers, the honest description of this bonus is a quantum estimate that a classical search then has to rescue, and getting the rescue right on a 34 qubit encoding of 1,600 numbers was the hardest thing in the 2 weeks. Not the physics. The engineering around the physics.

One participant wrote under IBM's wrap up post, "When I first opened lab 4, I was scared." I read that after the school. The timestamps in my table are my version of the same sentence.

I did not stop when the bonus was done. Lab 4c was the third notebook, sample based quantum diagonalisation on the nitrogen molecule, marked at the top as a bonus lab. 26 active orbitals, 5 electrons of each spin, 65,780 configurations per spin sector, a Hilbert space of over 4 billion states. You seed a LUCJ ansatz, a local unitary cluster Jastrow circuit, from a classical coupled cluster calculation, sample bitstrings from the hardware, recover the ones that violate electron number, and hand the survivors to a classical solver that diagonalises the Hamiltonian inside that small subspace. The quantum computer proposes which electron arrangements matter. The classical computer does the linear algebra. It is the hybrid loop from my variational badge, and the third of the 3 ways to diagonalise a giant matrix I wrote up in June, pointed at chemistry.

The sampling job for the LUCJ circuit ran on ibm_kingston at 05:48 on Saturday morning. 3 seconds of QPU time. I had not slept. I went from the Friday evening jobs straight through the bonus and into 4c and did not stop until every exercise in it had passed, including the ones that were never going to count. I am not recommending it. I am recording it, because this is a logbook, and the timestamp is real. The deadline was Wednesday 29 July at noon Eastern. The table has nothing after 05:48 on Saturday, 4 days before it.

3 things the lectures left behind

I will not summarise 10 lectures. These stayed. Thaddeus Pellegrini's lecture on entanglement spent a whole section on what entanglement does not mean, including the assumption that it automatically delivers a speedup. 6 weeks later, in the Bell state post, I wrote a caution of my own about what a histogram does not prove. Different claim, same instinct, and the lecture got there first. Vincent Pascuzzi's lecture on quantum + HPC made the argument I have been making to myself since June: the credible claim is not that quantum computers replace supercomputers. It is a CPU, a GPU and a QPU in 1 workflow, each doing the part it is good at. That is the shape of every system I have ever wired. And Minh Tran's lecture on tracking advantage had a line worth keeping: quantum advantage is not a destination. 6 days after the school closed, on 30 July, IBM and its partners announced 3 verified quantum advantage demonstrations. The tracker that Lab 4a had made me learn to read was suddenly the place to read them.

What the Quantum Excellence badge is, and what it is not

The rules say Quantum Excellence is 80% of the core lectures + 3 or 4 labs completed. I did all 4 at full score on every graded exercise, and the 4b bonus and the whole of 4c on top. That is what I did and I am putting it on the record the way I put everything here, dated, with the job history behind it.

What it is not is a research result. The grader checks that the object your code produced is the object it expected, the same idea I later built 20 exercises around. It does not check whether you understood why. That part is on you, because the alternative is a badge that knows more than you do. It is not a claim that error mitigation works at scale. I watched PEC cost 264 seconds on 11 qubits, and the lab itself shows the exponent that number lives under. And it is not a certificate of hardware mastery. The machines were noisy on 24 July just as they were noisy on 30 August, when I ran the Bell state, and the honest state of the field is the one I wrote about after that run, not a softer one.

Why this one matters to me

Before the school I had run 15 jobs on real hardware, most of them in 1 evening in June. By 10 September the count was 327, across ibm_fez, ibm_marrakesh and ibm_kingston: the n8n node being tested against real machines, the Bell state with its 50 impossible outcomes, the 2 error codes I had to catalogue because they kept coming back. The summer school sits between those 2 numbers. To me this badge is the bridge to real hardware, and the job list is the evidence.

I came into quantum through the side door, from automation. The school turned out to be 2 weeks of budgets, retries, job IDs and knowing what a tool is for before switching it on, and the hardest exercise in it was a classical search. That is the door I came through.

The badge is dated 21 August 2026. The email arrived on 11 September. The last job in its logbook is dated 05:48 on a Saturday. All 3 of those are true, and I would not trade any of them.

5 badges said I understood. This one says the circuits ran. I know which of the 2 I trust more.