Microsoft Quantum Resource Estimator: Photonic Plans SHYPS Models

Photonic and Microsoft's Quantum Resource Estimator Collaboration Is a Plan, Not a Release​

The announcement came as a Photonic press release carried by GlobeNewswire and republished by The Quantum Insider. All of those copies are the same text. Photonic says the collaboration builds on the companies' existing strategic partnership, combining Photonic's expertise in next generation error correction codes and distributed quantum computing with Microsoft's Quantum Resource Estimation (QRE) framework. In practice, the companies say they are studying how architectural choices, networking requirements between quantum systems, and emerging error-correction approaches influence the resources required to run quantum algorithms at scale.

"Resources" has a specific meaning here: how many physical qubits a machine needs, how long an algorithm takes to run, and the overall system overhead. According to the release, Photonic plans to use the Microsoft estimator to examine its SHYPS quantum low-density parity-check codes and other approaches for future fault-tolerant systems.

The release does not include a delivery date, a preview build, named benchmark algorithms, or any numbers. It says the capabilities are coming "in advance of the release" on Microsoft's estimator, and Photonic invites organisations to sign up for updates. Don't assume SHYPS models or network-cost modelling are in the current Quantum Development Kit (QDK). Microsoft's public estimator documentation does not list SHYPS as a built-in model.

Both companies are quoted. Paul Terry, Photonic's Chief Engineering Officer, said the aim is "giving the industry a clearer picture of what it will take to run practical applications on tomorrow's quantum hardware." Matthias Troyer, Technical Fellow and CVP at Microsoft Quantum, said resource estimation helps developers understand what quantum applications will really need before large-scale machines exist, and that working with Photonic lets Microsoft explore how distributed architectures and error-correction advances affect scalability. Both statements describe goals, not findings. The only public record of the collaboration so far is Photonic's release; there is no separate Microsoft announcement.

How Microsoft's Resource Estimator in the QDK Works Today​

The estimator ships in the Python package of the Microsoft Quantum Development Kit. Microsoft's documentation describes it as an open-source tool that estimates the physical qubits and runtime a quantum program would need on a fault-tolerant computer, for a given hardware design and error-correction scheme. The reason this matters is error correction. Real qubits are noisy, so a useful machine groups many physical qubits into one logical qubit that can correct errors while a program runs. That grouping multiplies the hardware needed, and the multiplier depends heavily on which error-correction code you use.

The tool builds its answer from four inputs that you can mix and match:

• An application model describes the computation. It can be a Q# program, Cirq, OpenQASM, QIR, plain logical resource counts, or a custom application.
• An architecture model describes the hypothetical hardware, such as gate-based qubits with specific gate times and error rates.
• An error-correction and "magic state" factory model is paired with that architecture. Factories produce the special high-quality states that certain operations need.
• An error budget sets the maximum error allowed across logical operations.

From these, the estimator works out a physical instruction set with operation times, qubit costs and error rates. It then tries every combination of options, such as different code distances (how strongly the code protects data), factory protocols and gate-decomposition settings. The results are narrowed to a Pareto frontier: the set of configurations where nothing else uses both fewer qubits and less time while staying within the error budget. You get a range of trade-offs rather than one number.

Microsoft's documentation also says users can define their own hardware and error-correction models to explore hypothetical architectures. That is why the tool is a sensible home for Photonic's work: a new code family can in principle be modelled without Microsoft rebuilding the estimator. Whether inter-module networking fits that same plug-in approach, or needs deeper changes, is what the collaboration still has to show.

Why SHYPS Codes Are the Center of the Photonic–Microsoft Work​

SHYPS stands for Subsystem Hypergraph Product Simplex. It is Photonic's family of quantum low-density parity-check (QLDPC) codes. QLDPC codes have long been attractive because they can protect quantum information with fewer physical qubits than the widely modelled surface code. The catch has been doing calculations with them. Photonic's own account says researchers had previously found such codes useful for memory (i.e., storage for quantum states) but lacking the ability to perform the applications that will make quantum computing so impactful. Photonic says its paper "Computing Efficiently in QLDPC Codes" is the first to demonstrate how to compute using SHYPS QLDPC codes.

The companies have worked together on SHYPS before. Photonic's SHYPS introduction thanks collaborators at Microsoft for their work on this animated overview of the code. The same release lists a Photonic follow-up on QLDPC logic published in Nature Communications in August 2026.

Photonic's efficiency claim is that by helping quantum computing systems do more with fewer physical qubits, code innovations such as SHYPS play a significant role in improving the efficiency of high-connectivity architectures. The key words are "high-connectivity". SHYPS works best when qubits that are physically far apart can interact directly. A surface code only needs neighbouring qubits to interact. That difference is why Photonic's hardware matters here. Its release describes an Entanglement First™ architecture built on optically linked silicon spin qubits, meant to fit into data centre and telecom environments.

Photonic's comparisons against the surface code are the company's own figures from its own chosen scenarios. The September release gives no workload or baseline for the Microsoft work, so any efficiency number is a claim still to be tested by the estimator, not a result of it.

Photonic's December 2025 Distributed QRE Estimate Sets Up the Microsoft Work​

This collaboration follows an argument Photonic made publicly nine months earlier. In December 2025 it announced its own distributed resource-estimation method. The Quantum Insider reported that the approach accounts for inter-module communication and networking costs, providing realistic benchmarks for large-scale quantum applications such as Shor's algorithm. Photonic said that for the first time, a QRE estimate for Shor's algorithm has been precisely calculated with Photonic's high-connectivity SHYPS QLDPC code family on a fully distributed architecture. The accompanying white paper, "SHYPS to Shor's: A Call for Distributed QRE", reported about 7 million qubits and roughly 3.9 days of runtime for that calculation. Those figures come from Photonic's own model. They are not results from the Microsoft collaboration.

Photonic's criticism of earlier estimates is the most useful background for understanding this deal. The company argued that while recent QRE analyses for Shor's algorithm set a high bar, they underestimate costs by assuming the algorithm can be completed on monolithic designs that won't be easy to achieve by today's leading qubit modalities. Put simply, many headline estimates assume one enormous processor. If real machines end up as linked modules, the cost of moving quantum information between them has to be counted, and ignoring it makes the numbers look better than they are.

The September release makes the same point: as modular architectures gain momentum across the quantum computing industry, resource estimates must account for the cost of running algorithms across interconnected systems. The practical change the collaboration aims for is that Microsoft's widely used, open-source estimator could reflect those networking costs. Until now, Photonic's distributed estimates have come from its own separate method.

Where the QDK Resource Estimator Stands for Developers Right Now​

What developers can use today is Microsoft's current estimator. Microsoft's quickstart makes two points that matter for anyone with a workflow built on it. First, the tool is now used through the qdk.qre Python module. The docs warn that the resource estimator inside the QDK extension for VS Code will soon be deprecated. Second, you don't need an Azure account.

The documented setup assumes current versions of Visual Studio Code, the QDK extension, and the Python and Jupyter extensions. Microsoft's walkthrough looks like this:

1. Install the package with the estimator extra: pip install --upgrade "qdk[qre]".
2. Create a Q# file from a sample program. The quickstart uses the "Ising Model (Simple 1D)" sample saved as ising-1d-sample.qs. You can also use your own Q# program.
3. In a Jupyter notebook, load the program with qsharp.eval(...), then wrap it as an application with QSharpApplication(qdk.code.Main).
4. Define the hardware. The example uses the built-in GateBased model with an error rate of 1e-4, a 100 ns gate time and a 500 ns measurement time.
5. Run estimate(...), passing the application, the architecture, a query for which error-correction and factory options to try (the example uses SurfaceCode.q() * RoundBasedFactory.q()), and a maximum error of 0.01.
6. View the Pareto-optimal results as a table with results.as_frame(), or plot them with plot_estimates(...).

If it works, you get a table of qubit-count and runtime trade-offs rather than a single answer. Pay attention to step 5. Every number depends on the hardware and code you chose, and the default example uses the surface code. When the Photonic work arrives, the obvious test will be to run the same application with a SHYPS-based model and a distributed architecture, and compare the frontiers.

What this means for you​

If you already use the estimator, move to the qdk.qre Python module now; there is nothing Photonic-specific to adopt yet. Most Windows and enterprise IT teams can ignore this announcement for now. It matters more to quantum software developers, researchers, and the architecture or strategy teams that use resource estimates to judge when quantum computing will be practical. Those groups should keep in mind that current surface-code estimates for single large processors may look quite different once networking costs and QLDPC codes can be modelled in the same tool.

• The Photonic–Microsoft work, announced September 23, 2026, is a planned expansion of the estimator's modelling, with no release date or published results.
• Microsoft's Quantum Resource Estimator is open source, runs through pip install --upgrade "qdk[qre]", and does not need an Azure account.
• The resource estimator in the QDK extension for VS Code is due to be deprecated, so scripts and notebooks should be moved to the qdk.qre Python module.
• SHYPS is not a documented built-in model today, although the estimator already accepts custom hardware and error-correction models.
• Photonic's efficiency figures, including its December 2025 Shor's algorithm estimate, come from its own calculations and are not results of the Microsoft collaboration.
• Because estimates change with the chosen code and architecture, comparisons across vendors are only meaningful when the assumptions are stated side by side.

The strongest part of this collaboration is not any headline figure. It is the prospect of a widely used, open-source Microsoft tool treating networked, modular quantum machines as normal when it calculates cost. Photonic has argued since December 2025 that single-processor estimates leave out real expenses. Getting that argument into Microsoft's estimator would let anyone test it with their own inputs. For now, the concrete milestone is the release of those estimator capabilities. Until it ships, SHYPS-on-distributed-hardware estimates remain Photonic's own numbers.