Thread by @JakeArkinstall

The Helios paper from @QuantinuumQC is out on arxiv -

It is feat of quantum hardware and software.

If you follow me, you're probably a software nerd. I want take a scenic tour of a software aspect that is very cool.

No quantum knowledge necessary.arxiv.org/abs/2511.05465

Mandatory note: I work at Quantinuum. Opinions are mine. Metaphors mine, inaccuracies mine, bad writing mine.

I'm posting this because we've done something cool, and now it has launched, I want to share it with software folk who aren't exposed to this field.

Hope you like it.

A primer to define terms.

A normal computer has bits and instructions. A quantum computer has qubits and gates.

In terms of computation they're different, but in terms of process it's the same deal.

I won't explain why qubits are different to bits. It's an enormous topic.

On computers, bits may be encoded as charges, voltage differences, etc.

On QCCD ion traps like Helios, qubits are encoded in the state of ions in a trap. Hence the name!

Throughout operation, you move these ions in and out of storage and gating zones, rearrange them, etc.

A user submits code (more on this later) that talks in an abstract language of qubits and gates.

They want to run it on your machine and get results.

They don't really care about ions, trap architecture, transport, gating zones. That's implementation detail for low level folk.

When they submit that code, you as a provider need to figure out the best way to map the abstract to reality - assign qubits to ions, transport them around the trap, fire gates, parallelise.

This is a hard thing to do optimally.

Qubits lose information fast, so optimal = good.

The usual solution? Analyse the user's code ahead of time.

This requires user code to be deterministic, or have minimal control flow that can be statically analysed.

Which is kind of okay. Much of the industry thinks in static quantum "circuits" like these:

Or, sometimes, basic control flow is allowed - supporting a few if statements (depending on measurement results mid-run). These are called "dynamic" circuits.

If there aren't many branches you can still traverse every possibility and come up with good overall hardware flow.

There's a point that this breaks down.

A major reason that people WANT control flow is that they want to correct quantum errors.

This means frequently making decisions throughout execution. Lots and lots of branching.

The circuit picture blows up.

That's low level stuff providers will do themselves one day, but isn't the only control flow puzzle in town.

AI for quantum! Not a buzzword.

In chemistry simulations, classical NNs could dynamically tune live quantum states to mimic arbitrary molecules

arxiv.org/abs/2502.06517…

Intermission!

Let's recap.

The prevailing paradigm is one of pure quantum, but with very limited classical control.

Providing more control will create opportunities for users, from low level qubit management, right the way up to scientific applications.

Whatever will we do?

The mentality had to flip entirely.

Applications will want to do arbitrary classical things.

To let them do that, dynamic circuits aren't enough. We need programs.

Full, Turing-complete classical programs that drive a quantum device like you'd drive any normal hardware.

This modality is called "Hybrid quantum computing".

Classical code on a CPU is in control and makes calls out to quantum hardware *while the quantum state is still alive*.

Just like you make calls out to a GPU or network card from code running on your CPU. Same deal.

This needs a runtime.

And Helios provides one, responsible for doing all of that mapping from high level instructions to low level ion stuff.

It has qubit versions of malloc and free, for instance, and an interface for gates and measurements. It has, in short, an API.

This runtime is invoked, on demand, by the user's program in realtime. Again, not circuit, not dynamic circuit - actual program.

This program, written by the user, runs on-device.

For those interested in how it achieves that, the paper goes into some detail about how it works.

So far so good. There exists a kind of program that users can write. It does classical things on a CPU, making calls out to a QPU.

But this is all a bit abstract still. What kind of program?

In quantum information there are some rules to follow.

This is where a PL person would talk about linear types, but I'm not a PL person, so here's a glimpse.

You can't clone qubits. It just doesn't math. There's a theorem and everything.

And when you have strict semantics, you should enforce them.en.wikipedia.org/wiki/No-clonin…

(the specific components I'm going to briefly talk about now are open source, so I'm going to link to them so you can check them out if you want)

To ensure that a program simply wouldn't compile if it violated constraints like this for quantum types, but allowed it for classical ones, an IR for hybrid computing was created: HUGR.

For something to compile to HUGR, it has to obey the rules.

github.com/CQCL/hugr/blob…

If you have some HUGR, you can transform it with the new generation of Tket: .

There are ways to optimise programs on the quantum level, rebase gates, and, compile to LLVM.

Not a gate sequence. Not an LLVM subset. LLVM.

Goodbye circuits. Hello programs!github.com/CQCL/tket2

You don't normally want to write your programs in an intermediate representation.

So a friendly programming language was born - Guppy.

It's a language embedded in python, and compiles to HUGR.

It has arbitrary control flow.

docs.quantinuum.com/guppy/

Users can emulate stuff locally with Selene to try it out* from the same interface so they can see what it'll do when they submit it.



*within limits - UNIVERSALLY simulating 98 qubits would take 5 quettabytes of RAM. I said qubits were different.github.com/CQCL/selene

So users can create arbitrary programs (not just "circuits") with the control flow they need, try it out, then submit it to Helios.

E.g this:

Running a guppy program acting as host, JPMC had *full remote control* of Helios, live. No trickery.arxiv.org/abs/2511.03689

That users can run full hybrid programs on Helios is the result of an enormous effort on every detail, from that incredible little junction right up to guppy UX.

Also the choice of trapped ions. They're long-lived and take time to operate on, so CPU work can fit alongside them.

That comes to the end of the tour.

Thanks for making it to the end! Let me know what you think!

I hope you've enjoyed it, learned something new, and gained an glimpse into one of many streams of work that went into Helios.