Transaction-Science/open-standards
Watch
1
0
Fork
You've already forked open-standards
 0
Code Issues Pull requests Projects Releases 15 Packages Wiki Activity Actions

wai-quantum 0.6.12 and wai-quantum-cli 0.1.0: the quantum stack on today's main, cheaper contraction trees, and the cut-rank table on the GPU #374

Merged
dcharlot merged 19 commits from wai/quantum-0612-land into main 2026-10-20 22:06:26 -04:00
Conversation 0 Commits 19 Files changed 92 +14647 -817
dcharlot commented 2026-10-20 17:46:58 -04:00
Owner
Copy link

This PR lands the whole quantum stack on today's main, as one PR and one CI run.

Where it comes from

  • #371, all green (120 of 120) but conflicting with main in the changelog alone. Its commits are cherry-picked here in order (-x records each origin). #371 carried #364, #368 and #370; each closed PR's description has the detail and checks for its part.
  • Two new commits, released as wai-quantum 0.6.12. 0.6.11 was never published on its own, so 0.6.12 carries it to the package registry.

Since #371

  • Cheaper contraction trees.
    • Each bisection runs two V-cycles.
    • The best few trees are annealed: random rotations, each changing only two contraction costs, accepted at a falling temperature.
    • On the 61-qubit Nighthawk logical circuits, 1024 trials and 8 restarts, the median of 4 seeds goes from 11.12 to 10.97 at depth 16, and from 14.02 to 13.68 at depth 20 (log10 multiply-adds per amplitude). The search takes about 1.7 times as long at depth 20.
    • Also tried and left out: more initial splits, a balanced coarsening rating, more refinement passes, and longer annealing.
    • The tensor-network plan pinned in tests/bit_identity.rs changes by design. The native and WASI builds compute the same new digest.
  • The cut-rank table on the GPU (quantum_cutrank_metal, macOS):
    • One dispatch per pass of the walk over (entry, shot), in f32.
    • Reductions per threadgroup on the device, added on the host in f64 in order.
    • Batches of shots side by side, so one command buffer per qubit for the whole batch. Each shot has its own random stream, so batches change no bit.
    • It is checked against the double-precision walk on 10 to 34 qubits.
    • The engine's cutrank_single method runs on it. auto never picks it, and up to 32 shots run per batch within the job's memory.
    • The service, the command line's metal feature and the desktop app build it in. The service marks its energy figure partial.
    • Each device timed at its quietest on a shared machine, one amplitude takes 0.005 s against 0.024 s on the host at a 23-bit cut, and 0.34 s against 0.54 s at 29 bits. 64 samples at a 20-bit cut take 0.067 s against 1.97 s on the host, which was then at about half its quietest speed.
  • wai-quantum-cli and the desktop app require 0.6.12, since their metal features name quantum_cutrank_metal.

Checked here, on this branch, on the build host:

  • wai-quantum's quantum_tn, quantum_cutrank (GPU declared) and engine:: tests;
  • bit_identity and tn_vs_sv;
  • cargo publish --dry-run --locked;
  • the service's, the command line's and wai-web's engine-binding tests;
  • the repository checks this repo's CI runs, all passing.

🤖 Generated with Claude Code

This PR lands the whole quantum stack on today's main, as one PR and one CI run. **Where it comes from** - **#371**, all green (120 of 120) but conflicting with main in the changelog alone. Its commits are cherry-picked here in order (`-x` records each origin). #371 carried #364, #368 and #370; each closed PR's description has the detail and checks for its part. - **Two new commits, released as wai-quantum 0.6.12.** 0.6.11 was never published on its own, so 0.6.12 carries it to the package registry. **Since #371** - **Cheaper contraction trees.** - Each bisection runs two V-cycles. - The best few trees are annealed: random rotations, each changing only two contraction costs, accepted at a falling temperature. - On the 61-qubit Nighthawk logical circuits, 1024 trials and 8 restarts, the median of 4 seeds goes from 11.12 to 10.97 at depth 16, and from 14.02 to 13.68 at depth 20 (log10 multiply-adds per amplitude). The search takes about 1.7 times as long at depth 20. - Also tried and left out: more initial splits, a balanced coarsening rating, more refinement passes, and longer annealing. - The tensor-network plan pinned in `tests/bit_identity.rs` changes by design. The native and WASI builds compute the same new digest. - **The cut-rank table on the GPU** (`quantum_cutrank_metal`, macOS): - One dispatch per pass of the walk over (entry, shot), in `f32`. - Reductions per threadgroup on the device, added on the host in `f64` in order. - Batches of shots side by side, so one command buffer per qubit for the whole batch. Each shot has its own random stream, so batches change no bit. - It is checked against the double-precision walk on 10 to 34 qubits. - The engine's `cutrank_single` method runs on it. `auto` never picks it, and up to 32 shots run per batch within the job's memory. - The service, the command line's `metal` feature and the desktop app build it in. The service marks its energy figure partial. - Each device timed at its quietest on a shared machine, one amplitude takes 0.005 s against 0.024 s on the host at a 23-bit cut, and 0.34 s against 0.54 s at 29 bits. 64 samples at a 20-bit cut take 0.067 s against 1.97 s on the host, which was then at about half its quietest speed. - **wai-quantum-cli and the desktop app require 0.6.12**, since their `metal` features name `quantum_cutrank_metal`. **Checked here, on this branch, on the build host:** - wai-quantum's `quantum_tn`, `quantum_cutrank` (GPU declared) and `engine::` tests; - `bit_identity` and `tn_vs_sv`; - `cargo publish --dry-run --locked`; - the service's, the command line's and wai-web's engine-binding tests; - the repository checks this repo's CI runs, all passing. 🤖 Generated with [Claude Code](https://claude.com/claude-code) 
The OpenQASM reader moves from the service into the library as
wai_quantum::qasm (feature quantum_qasm). The service, `wai-quantum run --qasm`
and the browser IDE's import now read a program the same way and refuse the
same programs: two registers, broadcast gates and comments read as the
service reads them, where the IDE's line reader dropped what it did not know.

- qasm::dyadic_circuit takes a program whose measurements all come at the
  end, and refuses one that measures and then acts, with the reason.
- quantum_toolchain::from_qasm, the older line reader, refuses what it cannot
  take (more than one register, reset, gate definitions, if/while/for, a gate
  after a measurement, two statements on one line) and names the full reader,
  instead of dropping the line.
- wai-web: the IDE binding builds its JSON with serde_json, so a quote or a
  control character in a program or an error no longer breaks the reply.
  set_signing_key, public_key_hex and key_is_demo let a page sign receipts
  with its own key; without one it signs with the published demo key and
  says so.
- The CLI signs with --key FILE, $WAI_QUANTUM_KEY, or this user's key at
  $XDG_CONFIG_HOME/wai/quantum-key (~/.config/wai/quantum-key), made from the
  operating system's random source with mode 0600 on first use. --demo-key
  keeps the published key, with a note that such a receipt shows the result
  is unaltered, not who signed it.

Co-Authored-By: Claude Opus 5.5 <[email protected]>
(cherry picked from commit 593f80f102)
The CLI signed every receipt as "did🔑wai-quantum-cli" and the IDE as
"did🔑quantum-ide", labels that name no key. Now that each signs with
its own key, the receipt's signer_id is that key's Ed25519 did:key
(wai::signer_id::did_key), so a verifier reads the signer from the id as
jwp-receipts §7.1 describes. The IDE binding gains signer_did() for the
page to show it.

Co-Authored-By: Claude Opus 5.5 <[email protected]>
(cherry picked from commit ef1e3b54e2)
Co-Authored-By: Claude Opus 5.5 <[email protected]>
(cherry picked from commit d6540016f6)
Co-Authored-By: Claude Opus 5.5 <[email protected]>
(cherry picked from commit 04da8bfb54)
The service's planner (catalog), runner (run) and dynamic-circuit walk
(dynamic) move unchanged into wai_quantum::engine, so every host that runs a
job plans and answers it as the service does. The service keeps what is its
own: HTTP, the job queue and its limits, energy metering, its signed
receipts, MCP and its examples.

- The GPU state vector is behind quantum_sv_metal: without it, the plan
  says the build has none, and the build still compiles for any target.
- The feature reads JSON numbers correctly rounded
  (serde_json/float_roundtrip), as the service always has.
- The test of the service's own examples stays with the service; the
  Grover test, which builds its program with the toolchain, runs where
  quantum_toolchain is on.

Co-Authored-By: Claude Opus 5.5 <[email protected]>
(cherry picked from commit 225e62eadd)
- engine::receipt is the service's receipt form, moved: a result sealed over
  the request and the result in their RFC 8785 canonical text, and checked.
  The service keeps its key file and seals with it; the command line seals
  with the user's key in the same form, and one verify checks both. The
  first receipts' form still verifies.
- A job's noise naming a channel the model does not know is refused with
  the channels it knows (catalog::NOISE_CHANNELS). It was read as no noise,
  so a misspelt channel ran the circuit noiseless.
- quantum_receipt::did_key: an Ed25519 key's did:key, held to the W3C
  method's example, for signers that depend on the library alone.

Co-Authored-By: Claude Opus 5.5 <[email protected]>
(cherry picked from commit bc5bd68b52)
A new crate, wai-quantum-cli, whose binary is wai-quantum. It depends on the
wai-quantum library alone, so `cargo install wai-quantum-cli` can install it.

- run: an OpenQASM program planned and run as the service runs it
  (wai_quantum::engine), signed with this user's key; --json prints the job
  as the service returns it. Shots, seed, method, observables, amplitudes,
  noise and method options; an unknown flag or noise channel is an error.
- plan, lint (the line of the first problem), draw (the circuit as text,
  gates packed into columns, conditions in a legend).
- submit: the same job on the service (feature `service`, on by default),
  waiting for a long one.
- verify: a job's receipt from run, submit or the service, and every
  receipt the research tools sign; a changed result is INVALID.
- key: this user's did:key; --key FILE and --demo-key as before.
- methods: each method's reach in a job's memory here.
- mcp: run, plan, lint, draw, verify and the method list for an agent,
  over stdio; runs stay on this machine.
- lab: the earlier wai-quantum command, moved here from wai-rs unchanged
  (wai:: paths now wai_quantum::), its key handling shared with run.
- completions for bash, zsh, fish, elvish and PowerShell.
- Feature `metal`: the GPU state vector on macOS. With no default features
  it builds for wasm32-wasip2.

wai-rs loses the wai-quantum bin and its cli_keys feature. The wai README's
quickstart now uses the new crate. smoke.sh exercises every command, and
.github/workflows/wai-quantum-cli.yml runs the tests, clippy with and
without submit, smoke.sh, and the WASI component against the native build,
byte for byte; on macOS also a run on the GPU.

Co-Authored-By: Claude Opus 5.5 <[email protected]>
(cherry picked from commit d2459835d8)
- engine::job: a job planned, run, sealed with the host's key and returned
  in the service's form (run), its check (verify), a key's did:key (did_of)
  and a program's lint. The command line now calls these; the browser
  binding calls the same.
- engine::draw: the circuit drawer, moved from the command line.
- The engine runs on wasm32-unknown-unknown: a result there carries no
  elapsed_ms (a tab has no clock std reads), and the cut-rank order search
  runs its seeds in turn where there are no threads, finding the same orders.
- A program that measures in the middle on the state vector is admitted
  with the job's memory margin counted once, as trajectories count it, not
  once per state: two 256 MiB margins had left no room in 512 MiB, and the
  service refused a qubit it could hold.
- wai-web, feature quantum_engine (off by default, for the IDE's bundle):
  QuantumEngine (run, plan, methods, signer_did) signing with the page's
  key, and engine_lint, engine_draw and engine_verify. Tested natively and
  in wasm32 under Node, where a job runs and verifies, a changed result is
  refused, and every method a tab holds runs; wai-web-wasm.yml runs both
  with their counts.
- wai-rs: feature quantum_engine re-exports the engine as wai::engine.

Co-Authored-By: Claude Opus 5.5 <[email protected]>
(cherry picked from commit aa516abdb1)
Co-Authored-By: Claude Opus 5.5 <[email protected]>
(cherry picked from commit 5e1bcc0b68)
wai/quantum-studio is an editor for OpenQASM programs with three places to run them: this browser (the engine in WebAssembly, in a worker), this computer (the engine built natively, in the desktop app), and the job service. Each returns the same job, and the Studio shows it the same way and checks its receipt where it runs. The same request and seed give the same counts in every place.

- The editor highlights OpenQASM, completes the standard gates and the program's own registers, marks the engine's diagnostics on their lines, and draws the circuit and shows the plan as the program is typed. Ctrl/⌘+Enter runs; Escape cancels.
- A result shows its method and why, its accuracy class, counts, expectation values, amplitudes with probability and phase, and a receipt naming whose key signed it, checked on this device, which can be downloaded. The program and the history of runs are kept on the device; a link carries the program in its fragment.
- It takes the host's design tokens (tokens.css when it stands alone) and follows the light and dark schemes.
- test/studio.test.mjs runs it in a browser: lint, draw and plan; a run checked here; an error on its line; any angle; the service giving the counts run here, shot for shot; Ctrl+Enter; the program and the history surviving a reload; no sideways scroll at a phone's width.

wai/wai-quantum-desktop is the app: the Studio's build around the engine natively. Each job runs in a process of its own (the binary as `worker`), so Cancel ends it and a large one cannot take the app with it. The worker plans and runs, and the app seals the answer with this user's key, the command line's. Jobs and programs are saved under ~/Documents/Quantum Studio/. `check` runs a Bell pair through the worker, sealed and verified, with no window.

engine::job splits into plan_and_run and seal (run is both), for hosts that run a job away from their key. wai-quantum-cli gains a library target for its key module, shared with the app.

.github/workflows/wai-quantum-studio.yml builds the engine's browser package, builds the Studio and runs its test, and on macOS runs the app's tests, clippy and check.

Co-Authored-By: Claude Opus 5.5 <[email protected]>
(cherry picked from commit 547d6db753)
The Assistant pane talks to a model on this machine: any server with the chat-completions interface and tool calls (the JouleClaw runtime, a llama.cpp server). Its address goes under "Model…", and nothing leaves the machine unless that address points elsewhere. In the desktop app the app itself makes the call (`chat` and `models` commands, http and https only).

- The model's tools are the Studio's engine: read the program, lint, draw, plan and run. Its first turn must call one, so every answer starts from the engine.
- Every program it proposes is read by the engine here. One that does not parse goes back once with the engine's reason. One that parses is run with the settings the model ran it with, so the counts it quoted are the counts shown, and then offered with Apply. A program the model ran through a tool but did not show is offered the same way.
- A figure in its prose that no tool returned is marked "Not from a run". LaTeX is shown as Unicode, and answers are plain text with bold and code built as nodes, never HTML.
- test/studio.test.mjs drives it against a scripted model server: the tool call run on the engine, a broken proposal sent back with its reason, the corrected one checked and run, the tools and the grounding rule in every call, and Apply.
- test/assistant-live.mjs drives it against a real server. Against a local 35B mixture-of-experts model (about 3B parameters active per token), every answer began with an engine call. The GHZ program it wrote was checked and run, with the counts it quoted equal to the counts shown, and a "50/50" it gave itself was marked as not from a run.

Co-Authored-By: Claude Opus 5.5 <[email protected]>
(cherry picked from commit 82269e7f4d)
Co-Authored-By: Claude Opus 5.5 <[email protected]>
(cherry picked from commit f1c3ccb7b0)
A tag wai-quantum-cli-v<version> (the crate's version, checked) builds the
wai-quantum binary on the project's own runners and attaches each archive, with its
SHA-256, to the forge release of that tag:
- macOS: aarch64-apple-darwin and x86_64-apple-darwin, with the GPU state vector;
- Linux: x86_64- and aarch64-unknown-linux-musl, static, checked as such, so any
  distribution runs them;
- Windows: x86_64-pc-windows-msvc, as a zip.
Each binary runs once before it is packaged (--version, and a did:key from
`key --demo-key`). A last job writes the Homebrew formula and the Scoop manifest
from the attached SHA-256 files, leaving out a platform whose build attached nothing,
and attaches them too.

release/package.sh makes the archive (the binary, README and LICENSE; the same bytes
for the same inputs where GNU tar is there) and its .sha256. release/publish.sh
creates the release if no build has yet, replaces an asset of the same name, and
uploads over the private network, not the public tunnel. release/formulae.py writes
the formula and the manifest. The README says how to install it each way.

Checked here: package.sh on the macOS binary (the archive verifies against its
.sha256, unpacks, and runs); formulae.py against a stand-in release with three of the
five platforms attached (the formula holds those three, Ruby reads it, and the
manifest is the Windows one). The workflow itself runs on its first tag.

Co-Authored-By: Claude Opus 5.5 <[email protected]>
(cherry picked from commit 66fd49edc0)
- engine::draw::layout: the drawing as data. It gives the qubits, the columns (each item's cells as [qubit, label], and whether a line joins them) and the legend of conditions, packed as the text drawing packs them. The packing moves into one function, which both forms use.
- wai-web's engine binding gains engine_layout, and the desktop app gains `layout`.
- The Studio draws the circuit as SVG from it:
  - wires, gate boxes, a control's dot joined to its target's ring, swaps;
  - measurements as meters with their bit, resets;
  - a gate under a condition with a dashed outline and the condition's number.
  Colours come from the page's tokens, each item has a title naming its gates and qubits, and the SVG has a text alternative. "Text" shows the text drawing to copy. Past 400 columns the diagram stops and says so.
- Tests: the layout of a circuit with a shared column, a joined CX and a conditioned gate; the binding's layout. The Studio test adds the diagram's glyphs and text alternative, and the Text toggle.

Co-Authored-By: Claude Opus 5.5 <[email protected]>
(cherry picked from commit c2e89a9fd9)
find_path_restarts runs find_path from several seeds side by side and keeps the
cheapest plan. The first restart uses the given seed, so the plan is never
costlier than one search. Each restart's seed depends only on its number, so the
plan does not depend on the thread count. In a browser tab the restarts run in turn.

On large networks the search's cost varies widely with its seed. More trials in one
search barely move it; independent restarts do. The other restarts' seeds come from
a generator of their own: seeds a multiple of the search generator's step apart would
start each search on another's stream a few steps on, and the restarts would repeat
one another, which a first version did.

The engine's tensor_network method runs 8 restarts natively and 1 in a tab, with a
job option path_restarts (1–64) to set it. examples/tn_cost takes RESTARTS.

The 61-qubit Nighthawk logical circuits, split and reduced, 1024 trials. log10 complex
multiply-adds for one amplitude:

  depth   1 search   8 restarts   24 restarts (wall time)
  8       5.33       5.33         5.26 (4 s)
  12      8.17       8.10         8.09 (7 s)
  16      11.24      11.11        11.11 (19 s)
  20      14.35      14.01        13.82 (33 s)

Test: restarts never cost more than one search, repeat their plan, and contract to the
dense state vector's amplitude.

Co-Authored-By: Claude Opus 5.5 <[email protected]>
(cherry picked from commit 260a3ee996)
The workflow-hygiene check requires every workflow to have one. A re-pushed tag
now cancels the run before it, and its own run replaces any asset the cancelled
run had attached.

Co-Authored-By: Claude Opus 5.5 <[email protected]>
(cherry picked from commit ed32a94ed1)
Each bisection now runs two V-cycles after the first projection. The graph is
coarsened again with every match inside one side, so the split carries to the coarse
graph with the same cut. It is refined there and on the way back down, which never
raises the cut.

The best few trees are annealed after reconfiguration (quantum_tn::anneal). Random
rotations at each node are accepted on the change in log total cost at a falling
temperature; the cheapest tree seen is kept, then reconfigured again. A rotation keeps
the node's index set, so it changes the cost of two contractions only.

On the 61-qubit Nighthawk logical circuits (split, reduced, 1024 trials, 8 restarts),
the median of 4 seeds, in log10 complex multiply-adds for one amplitude:

  depth   before   after
  8       5.30     5.29
  12      8.10     8.09
  16      11.12    10.97
  20      14.02    13.68

At depth 20 the search takes about 1.7 times as long.

Also tried, and left out: 24 initial partitions per bisection (no gain at depth 16 at
equal time), a coarsening rating that keeps coarse nodes balanced (mixed), more
refinement passes (no change), and 200 annealing sweeps (no better than 50).

The tensor-network plan pinned in tests/bit_identity.rs changes, by design. The native
and WASI builds compute the same new digest. A test checks that annealing never costs
more, keeps every tensor contracted once and after it exists, repeats its tree for a
seed, and gives the dense amplitude.

The changelog also records what 0.6.11 gained after its entry was written: the
circuit's layout as data, path-search restarts and the command line's release builds.

Co-Authored-By: Claude Opus 5.5 <[email protected]>
(cherry picked from commit 5c253c907402ce4a8e6140a676e3e58d86e01398)
quantum_cutrank_metal (feature quantum_cutrank_metal, macOS) runs the cut-rank walk's
passes on the platform's GPU:

- each shot's table is 2^cut single-precision entries in one shared buffer, at most
  2^31 a table, so every index fits in 32 bits;
- each pass is one dispatch over (entry, shot), in the walk's order and with its
  arithmetic, done in f32; the passes are the same for every shot, and only each
  shot's weights (set by the outcomes it drew) differ, read from a small per-shot
  array; an amplitude is every pass encoded into one command buffer;
- a sample's sums are reduced per threadgroup on the device (a SIMD-group sum, then the
  groups in order) and added on the host in f64, in order, for each shot; the outcome
  is drawn as the host's walk draws it (outcome_norm and draw, now shared by both);
- a batch of shots is sampled side by side, so a qubit is one command buffer for the
  batch: the previous qubit's passes for each shot's outcome, then this qubit's sums;
- each shot draws from a stream of its own, so a seed's samples are the same at any
  batch size.

The kernels are compiled in the platform's safe math mode, so a run is the same bits
on one device. Tests hold it to the double-precision walk on states of 10 to 34
qubits: amplitudes within 1e-5 of each amplitude's size and the same bits run to run;
samples whose probabilities are their own and whose counts follow them; and the same
samples one at a time and seven side by side. Without a device the tests skip;
WAI_QUANTUM_CUTRANK_METAL_EXPECT makes that a failure, and the service workflow's
macOS job sets it and checks both GPU tests by name.

The engine's cutrank_single method runs a cutrank job on that table where the build
has the feature and the host a GPU; auto never picks it. It samples up to 32 shots a
batch, as many as 2 GiB beside its first table holds within the job's memory, and the
plan counts them. Its amplitudes carry the circuit's global phase, found on the same
table (catalog::cutrank_phase_with takes the amplitude function). The job service, the
command line's metal feature and the desktop app's metal feature build it in. The
service's schemas list it, and it marks the method's energy figure partial, since the
counter does not read the GPU.

examples/cutrank_gpu times one state's amplitudes and samples on the host's tables and
on the GPU, and each kernel's pass alone. On a shared desktop machine, each device at
its quietest (either side ran up to five times slower under other work), seconds for
one amplitude of a random graph state:

  widest cut   host, double   host, single   GPU
  23 bits      0.027          0.024          0.005
  25 bits      0.057          0.045          0.019
  27 bits      0.18           0.17           0.046
  29 bits      1.03           0.54           0.34

and for 64 samples, 16 a batch, the host at about half its quietest speed:

  widest cut   host, single   GPU, one at a time   GPU, 16 a batch
  16 bits      0.52           0.62                 0.036
  20 bits      1.97           0.73                 0.067
  23 bits      3.87           0.91                 0.34
  25 bits      7.48           1.82                 1.20

A pass runs at about 550 GB/s on an idle device.

Co-Authored-By: Claude Opus 5.5 <[email protected]>
(cherry picked from commit f7c7160a9ab5a6255c28d34af57ee2fbc017b055)
wai-quantum-cli and the desktop app require wai-quantum 0.6.12
All checks were successful
wai-quantum CPU vector units / member · vector unit, rvv 1024-bit (riscv64, emulated) (pull_request) Successful in 18s
Details
wai-quantum CPU vector units / member · vector unit, sve 128-bit (aarch64, emulated) (pull_request) Successful in 33s
Details
wai-quantum CPU vector units / member · vector unit, rvv 128-bit (riscv64, emulated) (pull_request) Successful in 32s
Details
wai-quantum CPU vector units / member · vector unit, sve 2048-bit (aarch64, emulated) (pull_request) Successful in 16s
Details
wai-quantum CPU vector units / member · vector unit, avx2 (x86_64 silicon) (pull_request) Successful in 16s
Details
wai-quantum CPU vector units / member · vector unit, sve 512-bit (aarch64, emulated) (pull_request) Successful in 17s
Details
WAI conformance / cargo-class corpora · macos (pull_request) Successful in 12m31s
Details
WAI conformance / cross-arch byte-equality · macos (pull_request) Successful in 18s
Details
wai-quantum WebGPU member / member · software Vulkan (linux) (pull_request) Successful in 2m8s
Details
WAI conformance / codec wrappers · fuzz smoke, text decode limits, C entry points, provenance, the semantic path (pull_request) Successful in 40s
Details
wai-quantum WebGPU member / shader checks · browser build · wasip2 inertness · MSRV (pull_request) Successful in 3m10s
Details
WAI energy receipts / energy receipts · macos (pull_request) Successful in 3m54s
Details
wai-web wasm32 / wai-web wasm32 build · corpus, menu and writers (pull_request) Successful in 4m7s
Details
wai-pack / wai-pack · macos (pull_request) Successful in 1m0s
Details
WAI mbt2018_mean integer decode (regenerated vectors) / regenerate mbt2018_mean integer vectors → Rust decode, required (pull_request) Successful in 5m21s
Details
wai-quantum command line / command line · macos (pull_request) Successful in 26s
Details
wai-quantum dataflow member / member · dataflow device absent (macos) (pull_request) Successful in 12s
Details
wai-quantum FPGA member / member · FPGA datapath, simulated (macos) (pull_request) Successful in 1m5s
Details
wai-quantum Metal member / member · Metal (macos) (pull_request) Successful in 27s
Details
wai-web reach builds / wai-web reach builds · the package of record, every output as recorded (pull_request) Successful in 2m47s
Details
wai-web reach builds / wai-web reach builds · this tree's wai-web, every rung on its engine line (pull_request) Successful in 4m14s
Details
wai-quantum neural-processor member / member · neural processor (macos) (pull_request) Successful in 5m36s
Details
wai-quantum OpenCL member / member · OpenCL GPU (macos) (pull_request) Successful in 18s
Details
wai-quantum service / service · macos (pull_request) Successful in 37s
Details
wai-quantum matrix-extension member / member · matrix extension absent (macos) (pull_request) Successful in 9s
Details
wai-quantum studio and desktop / desktop app · macos (pull_request) Successful in 1m57s
Details
wai-quantum portable tensor program / tensor program · Metal and the arm64 CPU (macos) (pull_request) Successful in 13s
Details
wai-quantum CPU vector units / member · vector unit absent (macos) (pull_request) Successful in 12s
Details
wai-quantum WebGPU member / member · Metal (macos) (pull_request) Successful in 2m20s
Details
wai-quantum WebGPU member / member · browser WebGPU (macos) (pull_request) Successful in 1m34s
Details
95b3bc5f3e 
Their metal features turn on quantum_cutrank_metal, which 0.6.12 adds. 0.6.11 was not
published on its own; 0.6.12 carries it, and the changelog says so.

Co-Authored-By: Claude Opus 5.5 <[email protected]>
Sign in to join this conversation.
Reviewers
No reviewers
Labels
Clear labels
No items
No labels
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
Transaction-Science/open-standards!374
No description provided.