Every figure, explained

Every figure says what it was measured against, under what condition and in what unit.

Our mathematical algorithmic model, developed by Immanu, replaces the way systems decide what to touch when something changes. The same GPU, the same disk and the same processor do far less work, with the same answer, exactly.

It isn't an AI model, a vector database or hardware. It installs in the infrastructure you already have, and what you already run stays as it is.

Every measured figure is a floor: the conditions favor the rival.

Start Use the arrow keys or the space bar, or swipe.

How to read these figuresWhere each figure comes from

Every figure carries a label that says where it comes from.

Measured

We counted it in a test, against the rival in its standard form.

For example: 71× less recomputation on the GPU when a fact is corrected.

Derived

Calculated from measured figures, with the source or the assumption behind every factor in plain view; it was not measured in a data center.

For example: 2.9% to 15.8% of the world's GPU capacity would be freed if every GPU had it.

Projected

Adds an assumption about uses we did not measure against a rival; it holds under the condition stated next to it, is kept apart and is never added in.

For example: 590 thousand to 1.24 million GPUs in the rest of inference, if the same result holds in those uses.

Context · third party

A third party's figure, with its source; we didn't measure it.

For example: 12.5×: what Anthropic charges to rewrite the AI's memory, versus rereading it.

The figures don't add up across one another. Energy is a ceiling, not a guaranteed saving.

How to read these figuresAgainst what, and under what condition

And it says what it was measured against, and under what condition.

The state of the data

Changing data

The data changes during the test: it comes in, gets corrected, expires or is deleted, as in real use.

Static data

The data doesn't change during the test: the rival's best condition.

What is compared

Technique against technique

Compares only the way of deciding, in the same program.

System against system

Compares the whole system against the whole system, with the same changes.

Rival's behavior

Shows what the rival does when the data changes, without inventing a ratio.

How to read it

71×

For the same answer, the rival needs 71 times what our model needs, in the unit the figure states: tokens, bytes, work counted or time.

Floor

The test conditions favor the rival.

Ceiling: at most

At most: under the stated assumptions, the real value can be lower.

Does it work in AI? Does it beat the cache in AI servers? Does it affect model quality?

AI

71 times less recomputation on the GPU. More than 100 times less work in search. The same answers.

AIAI memory, on the GPU

71×

fewer tokens recomputed

When an agent corrects one fact halfway through a long document, our model recomputes 71 times less.

A language model keeps what it has already read in its KV cache (the memory where it stores what it has read), so it doesn't compute it again. After a correction, the standard rule in production recomputes everything that follows. Less recomputation is GPU freed up, with the same answers.

Tokens recomputed after one fact is corrected halfway through the document: the same test, at two lengths, each in its own panel

View as a table

document	rival	tokens recomputed (our model = 1)
32,000-token document	Prefix cache (vLLM, SGLang)	18×
128,000-token document	Prefix cache (vLLM, SGLang)	71×

32,000-token document

128,000-token document

Measured against: The prefix cache used by vLLM and SGLang, measured in llama.cpp and validated against its real server
Condition: Changing data · 128,000-token document · one fact corrected halfway · the same answers
Unit: tokens recomputed

Apple M4 Pro, 24 GB · Sep 28, 2026 · Qwen2.5-7B-Instruct-1M, an open model, with 4-bit weights · 11 questions after the correction.

AIAI memory · quality

The same

answers as recomputing everything

Recomputing far less didn't change the answers.

It's the first question every AI team asks: does quality drop? We measured what the user sees: whether each answer is right, and whether the corrected fact comes through.

correct answers per seed (each repetition of the test), the same as recomputing everything

3 of 3

times, the corrected fact comes through right

times less deviation than storing the AI's memory in 8 bits

Measured against: Recomputing everything, the reference answer; and storing the AI's memory in 8 bits
Condition: Changing data · 32,000- and 128,000-token documents · one fact corrected halfway · 11 questions afterward
Unit: correct answers, the corrected fact, and deviation from recomputing everything

Sep 28, 2026 · Qwen2.5-7B-Instruct-1M, an open model.

AIAI memory · the second rival

more than 3×

what CacheBlend recomputes, in multiples of ours

CacheBlend (U. of Chicago) matches the quality, but recomputes more than 3 times what we do.

It's the second rival in the same test. It ties on quality; the difference is how much it recomputes.

We measured its way of deciding in the rival's favor: its selection pass isn't counted against it. That's why the figure is a floor.

Measured against: CacheBlend (U. of Chicago), following its recipe
Condition: Changing data · the same GPU test · the same quality
Unit: tokens recomputed

AIAI memory · the server's option

Nothing

saved by the server's own reuse option

The server's own reuse option (llama-server --cache-reuse), with a change halfway through a 32,000-token document, saved nothing.

Besides the standard rule, we tried what the server itself already offers: it redid the same work as the prefix cache.

Measured against: llama-server's reuse option
Condition: Changing data · 32,000-token document · one change halfway
Unit: tokens recomputed

AIThe search that feeds AI

more than 100×

less work, with the exact same answer

The search that feeds AI does more than 100 times less work, with the exact same answer.

Before answering, the AI searches for documents filtered by customer, permission and date (RAG: retrieving documents before the AI answers), while those documents are corrected, deleted and expire. Our model works on top of the search engine, which stays untouched.

pgvector is offered by Amazon, Google and Microsoft.

Work to return the exact same answer, under three filter conditions

View as a table

filter condition	work (our model = 1)
exact pgvector · no filter	128.5×
exact pgvector · per customer	127.4×
exact pgvector · narrow filter	116.8×
Our model	1

Measured against: The application on exact pgvector, following its recipe: pgvector 0.8.6 on PostgreSQL 17.11
Condition: Changing data · 30,000 live documents, coming in and going out · the same 1,000 questions · the exact same answer
Unit: work counted (documents examined per question), no clock

Measured on a fixed sample of the searches, the same for every side · Oct 24, 2026.

AISearch · expiring documents

154×

less work than filtering out expired documents at query time

If documents also expire, the rival does 154 times our work in one mode, and 82 times in the other.

If the rival has two modes, we measure both, with what each one costs: filtering out expired documents on every query, or deleting them in a periodic sweep (removing expired documents every so often).

The rival's work in both its modes, in multiples of our model's

View as a table

rival's mode	work (our model = 1)
Filters out expired documents at query time	154×
Deletes them in a periodic sweep	82×
Our model	1

Measured against: The rival in both its modes: it filters out expired documents at query time, or deletes them in a periodic sweep
Condition: Expiring documents · up to 15,417 documents · no filter; per customer, 152× and 81×
Unit: work counted

Oct 24, 2026.

AISearch · the fast modes

All

of the correct answers, with our model

In their fast modes, the rivals leave correct answers out. Our model returns all of them.

A fast mode (an approximate index) is the usual way to speed up search, at the cost of exactness. Qdrant, in its normal mode, finds everything, but by scanning everything for each customer.

How many of the correct answers each one returns, in the same test

View as a table

who	share of the correct answers
Our model	all of them
FAISS (Meta), even knowing how many answers there are · depending on the filter	53.3% to 57.4%
Qdrant forced onto its fast index · narrow filter	41.1%
pgvector with its index and 10 results · depending on the filter	10.5% to 69.4%

Measured against: FAISS (Meta), Qdrant and pgvector with its index, each in its fast mode
Condition: Changing data · 30,000 documents · the same questions for everyone
Unit: share of the correct answers returned

This chart shows how much each one finds, not its work · Sep 28, 2026.

AISearch · small scale

expired documents kept, with our model

At small scale, up to 2,552 documents, the rival that doesn't rebuild keeps 778 expired documents. Our model keeps none.

An expired document that stays in the answer is information that's no longer valid, handed to the AI.

778

expired documents kept by the rival that doesn't rebuild

None

maintenance, with our model. pgvector's, emulated with its thresholds, ran more than 160 times.

Measured against: Each rival that doesn't rebuild; and pgvector's maintenance, emulated with its thresholds
Condition: Small scale, up to 2,552 documents · changing data
Unit: expired documents kept

Sep 28, 2026.

AISearch · what reaches the AI

18×

less text sent to the AI

With narrow filters, we measured 18 times less text sent to the AI than with a typical ten-result search with no threshold.

It's the text the search hands the AI so it can answer: what the AI has to read.

Text the AI receives, with narrow filters

View as a table

who	tokens delivered (our model = 1)
Typical 10-result search, no threshold	18×
Our model	1

Measured against: A typical 10-result search, no threshold
Condition: Changing data · narrow filters · 30,000 documents
Unit: tokens delivered to the AI

Sep 28, 2026.

AISearch · conversations per GPU

up to twice

as many conversations per GPU: 1.53× to 2.31×

With narrow filters and the AI's memory full, the math gives up to twice as many conversations per GPU, built on the measured 18× in tokens.

Each end of the range says where it comes from: the low end counts only the questions that have an answer; the high end counts every question, as in the test.

Conversations per GPU, with narrow filters and the AI's memory full

View as a table

end of the range	conversations per GPU (today = 1×)
today · 1×	1×
1.53×: counting only the questions that have an answer	1.53×
2.31×: counting every question, as in the test	2.31×

Measured against: The same typical search, no threshold (today = 1×)
Condition: AI memory full · narrow filters · built on the measured 18× in tokens
Unit: conversations per GPU

Context share from a published source (Cache-Craft) · assumptions in plain view · Oct 5, 2026.

Disk and catalogs

And on disk? With changing data or static data? Do the figures depend on the hardware?

Disk and catalogs

Beyond AI: 36.4 times less writing to disk, and large catalogs cross-matched 6.2 times faster.

Most figures are counts, which carry over from one machine to another; the clock appears only where we checked that the machine was quiet.

Disk and catalogsWriting to disk

36.4×

fewer bytes written

Our system, doing the work of SQLite and its application, writes 36.4 times less to disk.

SQLite is the database inside applications. We measured it as it's really used, with its write-ahead log (WAL, Android's default mode) and with its application, which queries again every round. This is system against system.

According to its website, SQLite runs on every Android, every iPhone and every Mac, in more than one trillion databases.

Bytes written to disk for the same answer, with the change spread out or in a single customer

View as a table

condition	bytes written (our system = 1)
SQLite and its application · change spread out	36.4×
SQLite and its application · change in a single customer	78×
Our system	1

Measured against: SQLite as it's really used (WAL), plus its application
Condition: Changing data · 1 GB database with 33.2 million real records from Gaia DR3 · 10 rounds · the same changes for both · the same answer in 11 of 11
Unit: bytes written, counted by the operating system

Apple M4 Pro, 24 GB · SQLite 3.51.0, Oct 23, 2026.

Disk and catalogsWriting to disk · another rival

14.6×

fewer physical bytes written

Against a rival that rebuilds its whole structure on every change, our system writes 14.6 times less in physical bytes.

It's another rival and another test: the batch process that rebuilds its structure every round.

20.0×

less writing, counted logical against logical

Measured against: Whoever rebuilds its whole structure on every change: a batch process
Condition: Changing data · real Gaia records · generated changes, the same for both · first round, measured on both sides
Unit: physical bytes written; and writing, logical against logical

Sep 28, 2026.

Disk and catalogsReading large catalogs

An astronomical potential

Scientific archives and data integration cross-match catalogs with billions of records, and every new release forces the cross-match to be redone.

In research, where ever more data is processed, that means cross-matching faster, with the same answer and on the same machine. We measured it with the entire Gaia catalog, from the European Space Agency.

What we measured with the Gaia catalog

6.2×faster than the Gaia Archive's official cross-match method, with the same answer
7.6×faster than HEALPix, astronomy's standard, with the same answer
10.55 sto be sure nothing is missing; comparing everything with everything would take 132 days of compute (derived)
11,881,062relationships: the same list returned by STILTS, LSDB and Q3C
868 and 911relationships lost and no longer valid, without warning, in the rival that doesn't rebuild when the data changes

Disk and catalogsReading large catalogs

6.2×

faster, with the same answer

With the entire Gaia catalog, 1.812 billion sources, we finish the cross-match 6.2 times sooner than the Gaia Archive's official method.

Scientific archives and data integration cross-match catalogs with billions of records, and every new release forces the cross-match to be redone. The test is astronomical; the question, what relates to what, belongs to the whole industry.

Cross-match time, in multiples of our model's

View as a table

who	time (our model = 1)
Gaia Archive's official cross-match method	6.2×
Our model	1

Measured against: The Gaia Archive's official cross-match method (ESA), implemented from its published method, in the same program
Condition: Static data, the rival's best condition · the entire Gaia DR3, 58 GB, more than the 24 GB of memory · structure already built on both sides · the same answer
Unit: time

The same memory: 427 vs. 425 MB · the same 58.28 GB read from disk by both sides · Sep 21, 2026.

Disk and catalogsReading large catalogs · the limit of the disk

119%

of the time it takes just to read the catalog

Almost at the limit of the disk: our model takes 119% of the time it takes just to read the catalog; the official method, 739%.

With the catalog on disk, larger than memory, no cross-match can take less time than reading it. That's the yardstick: how far each side lands from it.

Each side's time, against the cost of just reading the catalog

View as a table

who	time, as a % of just reading the catalog
Gaia Archive's official cross-match method	739%
Our model	119%

Measured against: The Gaia Archive's official cross-match method, and the cost of just reading the catalog
Condition: Static data · the entire Gaia DR3 · structure already built on both sides
Unit: time, as a % of the cost of just reading the catalog's 58 GB from disk

Sep 21, 2026.

Disk and catalogsReading large catalogs · another rival

7.6×

faster than HEALPix, with the same answer

Against HEALPix, astronomy's standard, we finish 7.6 times sooner.

Another run, another rival: the same entire catalog, under the same conditions. Each rival gets its own chart, because each one is a separate test.

Cross-match time, in multiples of our model's

View as a table

who	time (our model = 1)
HEALPix	7.6×
Our model	1

HEALPix: 5.6× if it's given help its library doesn't include.

Measured against: HEALPix, implemented from its definition
Condition: Static data · the entire Gaia DR3 · structure already built on both sides · the same answer
Unit: time

Sep 21, 2026.

Disk and catalogsReading large catalogs · certainty

10.55 s

to be sure nothing is missing, measured

Being sure nothing is missing: 10.55 s with our model, versus 132 days of compute comparing everything with everything.

Comparing everything with everything is how pgvector, hnswlib and FAISS prescribe checking it. Our side is measured, with the structure already built; the rival's side is derived: calculated, not run.

Being sure nothing is missing: measured versus derived

View as a table

who	time
Our model	10.55 s
Comparing everything with everything (derived)	132 days

Measured against: Comparing everything with everything, as pgvector, hnswlib and FAISS prescribe to check it
Condition: The entire Gaia DR3 · our model, with the structure already built
Unit: seconds, measured · days of compute, derived

Sep 21, 2026.

Disk and catalogsReading large catalogs · the answer

11,881,062

relationships: the same list

The same list returned by STILTS, LSDB and Q3C, three real astronomy tools.

Before counting who does less work, we require the exact same answer. On the entire Gaia catalog, the answer matches in full.

Measured against: STILTS, LSDB and Q3C
Condition: The entire Gaia DR3 · the same list
Unit: relationships

Sep 25, 2026.

Disk and catalogsReading large catalogs · when the data changes

868

relationships lost, without warning, by the rival that doesn't rebuild

When the data changes, the rival that doesn't rebuild loses 868 relationships and returns 911 that are no longer valid, without warning.

Whoever uses that answer has no way of knowing it's incomplete.

911

relationships no longer valid, returned without warning

Measured against: The rival that doesn't rebuild
Condition: Changing data · the entire Gaia catalog, one round of changes
Unit: relationships

Sep 25, 2026.

Disk and catalogsText search

974 to 1,026

relationships missed, without warning, when some 1,000 matching ones arrive during the lag

In SQLite, a text index that catches up every so often misses what arrived in between, and its answer gives no way to know.

Its answer looks exactly like one with nothing missing. Here we measured the rival: it's its behavior, not a ratio.

Measured against: SQLite's text index, caught up every so often
Condition: New records arrive · some 1,000 matching relationships · databases of 10 thousand to 1 million records
Unit: relationships missed, without warning

Sep 16, 2026.

Other usesFraud rules

5.46 to 28.66×

faster, depending on the window-and-amount combination

With a fraud rule over synthetic transactions, the cross-match finishes 5.46 to 28.66 times sooner, depending on the window-and-amount combination.

Fraud rules cross-match transactions against time windows and amounts, and today they're re-run in full on every batch. It measures how much faster the rule runs on data that doesn't change; this is not a comparison against fraud engines.

7.58×

on the default question: a 48 h window and amounts of USD 100

Measured against: The standard cross-match with its optimizer, in its best normal form
Condition: Static data, in memory · synthetic transactions: one year with 250,000 deposits and 50 million withdrawals · nine combinations of window and amount
Unit: time, on the clock

Energy

How does it improve the hardware? What does it mean in a data center, and worldwide?

Energy

If every GPU in the world had it, 2.9% to 15.8% of their capacity would be freed.

Nothing in this chapter was measured in a data center. Derived figures come from measured ones, with the source or the assumption behind every factor; projected figures add assumptions about uses we didn't measure against a rival, and they're kept apart, with their condition. Energy is a ceiling, not a guaranteed saving. The figures don't add up across one another.

MW: megawatt · MWh: megawatt-hour · TWh: terawatt-hour · PB: petabyte · PUE: how much energy the data center uses for every unit that reaches the compute.

EnergyWorldwide

2.9 to 15.8%

of the world's GPU capacity, derived from our measurements

If every GPU in the world had it, what derives from our measurements would free 435 thousand to 2.37 million GPU equivalents.

In the job it replaces, the ratio is large and measured. Across all the work of the world's GPUs the percentage is smaller, because a GPU also does work our model doesn't touch.

Base: more than 15 million H100 equivalents, according to Epoch AI (Jan 2026).

Share of the world's GPU capacity that would be freed: derived from our measurements

View as a table

scenario	share of world capacity
Cautious scenario (central figure)	2.9%
With factors already measured (ceiling)	15.8%

Measured against: The world's GPU capacity
Condition: Filtered search and mid-document edits · cautious scenario (a central figure) to ceiling
Unit: share of the world's GPU capacity

The projected part is kept apart and isn't added to this.

EnergyWorldwide

2.81 to 20.70

TWh of electricity a year, at most

In energy, the derived figure is a ceiling: at most, 2.81 to 20.70 TWh of electricity a year.

It comes from the capacity that's freed, with the source or the assumption behind every factor in plain view. It's a maximum, not a guaranteed saving: if the freed capacity is used to serve more demand, that energy isn't saved; it's one or the other.

1.25 to 9.21

million tonnes of CO₂ a year, at most

Measured against: The electricity and emissions of AI worldwide
Condition: If every GPU in the world had it · cautious to ceiling
Unit: TWh and million tonnes of CO₂, per year

EnergyThe projected part, kept apart

The projected part is kept apart: it depends on the condition stated next to it, and it isn't added to the derived figures.

These are two uses we didn't measure against a rival. Each one carries its condition, written next to it.

590 thousand to 1.24 million

more GPUs in the rest of inference, if the same result holds in those uses

314 thousand to 486 thousand

more GPUs in training, if it saves on its data what the disk already saves

Projected, under its conditions: % of the world's GPU capacity

View as a table

use and scenario	share of world capacity
Rest of inference · cautious	3.9%
Rest of inference · factors already measured	8.3%
Training · cautious	2.0%
Training · factors already measured	3.2%

Measured against: The world's GPU capacity
Condition: Each use, with its condition written next to it · cautious and with factors already measured
Unit: GPU equivalents, and % of world capacity

EnergyIn a data center

0.344 to 0.567 MW

freed from every MW of GPU in that regime

The same demand, with less infrastructure: of every MW of GPU working with narrow filters and full memory, 0.344 to 0.567 MW is freed.

That's grid connection, cooling and building you don't have to build. It applies to the share of the load that works in that regime.

Of every MW of GPU in that regime, the share that's freed

View as a table

end of the range	MW freed per MW of GPU
low end: counting only the questions that have an answer	0.344 MW
high end: counting every question, as in the test	0.567 MW

Measured against: A typical 10-result search, no threshold
Condition: AI memory full · narrow filters · the same demand · built on the measured 18× in tokens
Unit: MW freed per MW of GPU

EnergyIn a data center

3,287 to 7,645

MWh a year per MW, at most

For every MW of GPU in that regime, at most 3,287 to 7,645 MWh and 1,150 to 3,402 tonnes of CO₂ a year.

Each end says where it comes from: PUE runs from 1.09, Google's, to 1.54, Uptime Institute's; the grid, from the US grid (EPA) to the world grid (IEA).

Energy and CO₂, per MW per year: each on its own axis

View as a table

end of the range	per MW per year, at most
low: 0.344 MW freed and PUE 1.09 (Google)	3,287 MWh per year
high: 0.567 MW and PUE 1.54 (Uptime Institute)	7,645 MWh per year
low: US grid, 349.7 g per kWh (EPA)	1,150 tonnes of CO₂ per year
high: world grid, 445 g per kWh (IEA)	3,402 tonnes of CO₂ per year

Energy, per MW per year · MWh per year

CO₂, per MW per year · tonnes of CO₂ per year

Measured against: A typical 10-result search, no threshold
Condition: AI memory full · narrow filters · ceiling: at most · PUE from 1.09 to 1.54 · US grid, 349.7 g per kWh, to world grid, 445 g per kWh
Unit: MWh and tonnes of CO₂, per year

EnergyPer GPU

1,630 to 17,200

kWh per year for every GPU freed, data center included

Every GPU that's freed is worth 1,630 to 17,200 kWh a year, data center included.

It's the factor that turns freed capacity into energy. The range comes from power per GPU, 171 W to 1,275 W, and from PUE, 1.09 to 1.54.

Measured against: Every GPU freed
Condition: Data center included · power per GPU from 171 W to 1,275 W · PUE from 1.09 to 1.54
Unit: kWh per year

EnergyPer PB, reading

114.6 to 162.0

kWh less per PB cross-matched

When cross-matching large catalogs, each PB cross-matched uses 114.6 to 162.0 kWh less.

And emits 40.1 to 72.1 kg less CO₂, from the US grid to the world grid. With the same fleet, 6.2 times more cross-matches per hour.

Energy not spent for every PB cross-matched

View as a table

end of the range	kWh less per PB cross-matched
low: PUE 1.09	114.6
high: PUE 1.54	162.0

Measured against: Cross-matching a PB with the official method
Condition: Static data · structure already built · preliminary: it assumes a 400 W server and that energy follows compute time
Unit: kWh less per PB cross-matched

EnergyPer PB, writing

0.11 to 0.38%

of the day spent writing, with our system

Writing 36.4 times less: the disk spends far less of its day writing.

With a load of three full disk writes a day, this is the time the disk spends writing, from its fastest kind of write to its slowest.

4.0 to 13.6%

of the day, with SQLite

Where the disk's endurance is the limit and all its writes come from this load, it lasts up to 36.4 times more work. Direct electricity is the small part: 0.49 to 1.83 kWh per PB not written.

Measured against: SQLite as it's really used, plus its application (36.4×)
Condition: Three full disk writes a day
Unit: share of the day the disk spends writing

ContextContext · third party

12.5×

what it costs to rewrite the AI's memory, versus rereading it

Redoing work already has a price: Anthropic charges 12.5 times as much to rewrite the AI's memory as to reread it.

It isn't our figure: it's a third party's list price, and it applies only to Anthropic. It shows that redoing work already has a price.

According to its website, SGLang runs on more than 400,000 GPUs.

We did not measure it on frontier models; there, the impact is potential.

Measured against: Rereading the AI's memory
Condition: Anthropic's list price: writing to its 5-minute cache costs 1.25 times the input, and rereading, 0.1 times
Unit: price

How we testedThe eight rules of every test

How did you test it? Why believe these figures? How do I know you didn't tune the test until you won?

Before counting who does less work, we require the exact same answer.

Both sides must return exactly the same thing, and that answer is checked against a ground truth computed separately, from the written rule.

Exact same answerBoth sides return the same thing, checked against a ground truth computed separately.

Technique or systemEach figure says whether it compares the way of deciding or the whole system.

Standard documented formThe rival runs with its version, its recipe and its defaults.

Two modes, bothIf the rival has two modes, both are measured, with what each one costs.

Corrections in the rival's favorIf a setup put it at a disadvantage, it was corrected in the rival's favor before publishing.

Regime on every figureAgainst what, with what data, static or changing, and at what scale.

One cost, one verdictTokens, bytes, work, time and memory are measured separately. They're never added up.

One machine, the same dataBoth sides on the same machine, with the same sequence of changes, sealed before measuring.

How we testedThe prediction, before measuring

128.5×

measured, inside the range written beforehand

Before measuring search, we wrote down the range we expected. The figure landed inside it.

And the prediction protected the rival too: twice, an advantage that didn't match what we expected told us we were measuring it wrong, and we corrected it in the rival's favor.

Prediction written before measuring, and the measurement

View as a table

who	exact pgvector's work, in multiples of ours
Predicted beforehand	125.6× – 129.8×
Our model	128.5×

Measured against: Exact pgvector, following its recipe · no filter
Condition: Changing data · 30,000 documents
Unit: work counted

How we testedThe controls

A control that can't fail proves nothing.

Planted errors

On the GPU, the control that recomputes nothing answers with the stale fact, and fails, as it should. In search and in SQLite, the planted faulty versions fail. In a slice of the Gaia catalog, an error planted by hand stops the test with an error, instead of returning less.

Reproduce the previous run

On the GPU and in search, before measuring anything new, the same instrument repeats the previous measurement, and it must give exactly the same result: zero differences.

Repeat and publish the lower figure

The SQLite test gave 36.4×; the full repeat, 36.6×. We publish 36.4×, the lower one. In the Gaia cross-match, three runs were discarded by the machine control, even though one favored us.

How we testedThe review

A reviewer with veto power, and every figure as a floor.

A reviewer with veto power

Since Oct 21, 2026, a project reviewer who neither designs nor measures approves each test before it touches the machine, checks that each rival is in its standard form, and recomputes the figures from the raw data. Without that sign-off, the test doesn't run. Before that, an internal audit of each rival's code and data led to 11 corrections of figures or labels, all applied; no headline figure changed direction.

The life of a test

Prediction
Reviewer before
Planted errors
Reproduce the previous run
Measure
Reviewer after
Repeat
Publish the lower figure

Why every figure is a floor

With static data, the rival runs in its best condition.
What the rival doesn't pay for, like building its index, stays out of its count.

If the structure was built beforehand, on both sides, the figure says so.

MeetingLet's test it on your data

Write to me to set up a meeting.

We'll deliver the correct set, with its proof. Write to me with your name, company, role and what you'd like to evaluate: AI memory, search for AI, disk writes, or large-catalog cross-matching, and we'll set up a meeting. In your first message, please don't send data or details about your systems.

Write to me to set up a meeting Back to the website Start from the beginning

Every measured figure is a floor: the conditions favor the rival.

Our model · Exact · Provable