Hadron.

The ARM of AI compute.
Hadron is a patent-pending runtime that routes every AI workload to the cheapest hardware that can actually run it, across cloud, edge, on-prem, mobile and your user's own browser. Operators cut their compute bills, we take a fee on every workload routed, and no data leaves their systems.
Only filed IP in cross-platform dispatch 5 UK patents 447 tests, zero failures Up to 45x faster 5B devices addressable
See it run Talk to us
Detecting GPU...
UI heartbeat: 0 frames painted Longest frame gap (last 5s): 0 ms main thread responsive

Dispatch decision, live drag the slider

The patent isn't WebGPU. The patent is the routing decision made on every call. Below, the same sortAsync function gets different backends as you change the input. Drag the slider or pick a scenario - the scorer publishes its workload profile, its seven weighted factors, and the final tier. Then press Race the lanes to actually run the workload three ways.

1,000,000
Workload profile
n elements1,000,000
data typeFloat64
presortedness0%
entropy estimate1.00
GPU class detecteddiscrete
hardware tuningauto-detected
Scoring math 7 factors, weighted
composite signal borderline
CPU
score 0, below GPU threshold
Three-lane race naive / vanilla-GPU / Hadron
Press Race the lanes to run all three implementations at the current size. Wallclock captured live.
Runs three implementations, same data.
What you just saw. The same function call - sortAsync(arr) - is routed to a different backend depending on the array's shape. Vanilla WebGPU doesn't make that choice; it pays the upload cost on every call. Hadron's scorer publishes its seven factors and the named reason for every dispatch, so the decision is auditable. This is what the patent filings protect.

The moat: five patents, watch each one work click Play on any card

Five UK patent applications, all assigned to Ayoob AI Ltd, covering the cross-platform dispatch layer. Each Play button runs a short sequence that shows the exact mechanism the patent protects.

P1

Adaptive sort dispatch

Same function, eight possible paths, picked per call.

A stream of six differently-shaped sort calls. Each is routed to a different backend based on its workload profile - decision published per call.

Press Play to start the stream.
0 / 6 calls
P2

Precision sufficiency

Hadron refuses GPU when Float32 would lose accuracy.

Two matmuls, identical shape, different value range. Run 1 fits Float32; Hadron goes GPU. Run 2 overflows Float32; Hadron refuses and falls back to Float64 CPU.

Run 1 - values [0, 1] awaiting
Run 2 - values [0, 10^20] awaiting
precision check pending
P3

Per-operator routing + buffer retention

Each operator scored independently; GPU intermediates stay GPU-resident.

A 1M-row pipeline: filter → groupBy → sort. Each box gets its own tier. When two consecutive operators are GPU, the intermediate buffer stays on-device (the core dispatch routing).

filter-
groupBy-
sort-
pipeline pending
P4

Two-phase GPU search

Pre-filter on GPU (cheap), verify on CPU (precise).

2M chars of synthetic text. Phase 1 runs a pre-filter pass on GPU; rules out 95% of the corpus in one pass. Phase 2 verifies the remaining 5% on CPU with a CPU literal-search path.

Phase 1 - GPU pre-filter
-
Phase 2 - CPU verify
-
phases pending
P5

Categorical GPU refusal

Six named structural reasons. Each refusal cites a different one.

Four search patterns submitted in sequence. The literal goes GPU. The other three are refused with named architectural reasons - each refusal cites a distinct hardware constraint surfaced via the dispatch info.

"fox" (literal)awaiting
[a-z]+ing (regex)awaiting
h?llo w*ld (wildcard)awaiting
"quik" (fuzzy)awaiting
0 / 4 patterns
See the same dispatch on five axes (Speed / Privacy / Cost / Resilience) → Or jump to nine sector applications →
Technical proof - 34 individual tests For deep-dive Q&A. Click to expand the per-library button rig.
Test rig - every individual claim, button-by-button

For deep-dive demos. 34 isolated tests grouped by library / patent. Use these for technical Q&A.

1 · Sort dispatch Adaptive multi-tier sorting

Multi-factor dispatch routing for sort workloads. Profiles each array and routes to the most suitable tier. Sync sort stays CPU; sortAsync adapts.

Idle.

2 · Compute dispatch Numerical compute with precision sufficiency

matmul / FFT / conv2d / solve auto-dispatch across tiers. Precision-sufficiency check before GPU; pipeline fusion keeps intermediates on-device.

Idle.

3 · Query dispatch Per-operator SQL routing

Each operator in a pipeline is scored independently. Consecutive on-device operators retain their intermediate; mixed pipelines pick the best tier per step.

Idle.