← Beyond Brute ForceEVIDENCE / CONTEXT MATTERS
Measured results.
Clearly counted.
A result is most useful when you know the workload, the comparator and what was included. These are selected recorded studies, with their boundaries kept visible.
LATEST / TOKENHOLOFOLD · 20 OCTOBER 2026
300 fresh answers.
All exact. All local.
Supported requests completed exactly300 / 300zero model-provider calls
Boundary controls handled safely100 / 100zero false releases
The frozen current customer package completed all 300 supported requests with exact interpreted parameters and complete numerical results. All 100 boundary controls were handled safely. Local workers ran with network access denied. A separate diagnostic pass also returned 30/30 exact restarted results and 60/60 exact warm repeats.
This preregistered study covers one synthetic structured patch/statistics operation family: six groups of 50 supported requests and 20 boundary classes of five controls. Requests varied wording, clause order, coordinates, state and query. The 300 state-bound requests contain 275 distinct raw strings. Repeated-state and changed-state pairs test contextual consistency; they are not 300 unrelated applications.
All three routes, counted together
The conventional local route also completed the work with zero API calls and was faster in this study. It shares the numerical receiver but uses lighter original release checks. Both local routes therefore remain visible in the comparison.
The API route used GPT-5.6 Luna with a frozen structured-output prompt and the same numerical receiver. It withheld 63 supported requests and released eight boundary requests that should have been refused. Those outcomes remain in the results; they were not retried or counted as successful work. This describes the tested configuration, not the provider's best possible performance.
10.61× on mutually correct results
On the 237 supported cases answered exactly by both TokenHoloFold and the API route, median complete-process times were 130.686 ms and 1,386.661 ms: a 10.61× ratio of medians. The median of individual paired ratios was 10.64×. The other 63 cases remain incomplete in the API arm and are excluded from this timing comparison.
The API arm made 355 calls: 300 supported requests and 55 semantic boundary controls, with zero retries. Ordinary application checks rejected the other 45 controls before inference. TokenHoloFold and the conventional local route made zero provider calls.
Restart, timing and verification boundaries
What did the API comparison cost?
For the 237 supported tasks completed exactly by both routes, the API arm reported 89,528 input tokens and 8,295 output tokens. Using the rates frozen before testing gives an estimated US$0.02786–$0.03234 in provider charges. TokenHoloFold used zero provider calls for those tasks.
The entire comparison campaign made 355 calls, including controls and incomplete outcomes, with a frozen-rate estimate of US$0.04118–$0.04788. These are usage estimates, not invoices. The experiment ran both routes; it did not itself reduce a customer’s bill.
The conventional local route also incurred no provider charges. Net customer savings therefore need a matched evaluation against the best feasible existing route, counting local compute and other agreed incremental costs. The 50/50 licence shares that verified net saving once; token reduction and call avoidance are not billed as two separate savings.
Native warm response time had a 26.834 ms median over 60 diagnostic repeats; the conventional local median was 19.842 ms. These repeats are separate from the 300 fresh requests and are not used to enlarge the primary speed ratio. Five missing-descriptor controls produced the expected validation exception. Source, learned state and the frozen test deck remained unchanged.
The results support this bounded operation on the tested Mac. Customer workload coverage, total application costs and deployment compatibility are established in a scoped evaluation. This test did not measure representation-token reduction or energy consumption.
A new trial with its own measurement boundary
The older 90.02× result used a different candidate, a two-call provider workflow and a different timer. It is displayed below as the original achievement; it is not the speedup measured by this larger trial. The separate 95.05% representation-token study also keeps its own denominator.
Download the study summary →
Return to TokenHoloFold results →
HISTORICAL / 24 SEPTEMBER 2026
90.02×
paired-median latency advantage.
Exact results · native route32 / 32supported tasks
Provider calls per task2 → 0selected-context provider → native
The 24 September 2026 benchmark compared the native route with a selected-context GPT-5.6 Luna provider workflow across 32 tasks. Both paths returned 32/32 exact results. The paired-median latency ratio was 90.0223, rounded to 90.02×; 64 provider calls in the selected-context arm compared with zero on the native route.
Earlier local qualification · 25 September 2026
The 25 September qualification recorded 24.31 ms median and 26.46 ms p95 complete-request time. All 112 fresh validation checks passed, including 32/32 exact end-to-end results, with zero model-provider calls in the qualified local route.
The provider comparison and fresh qualification concern separate recorded candidates. Their figures are presented independently. A customer evaluation measures complete equivalent work, output quality and eligible cost in the customer's deployment.
Request-representation study · 95.05% fewer tokens
A separate 18-request study counted 59,064 tokens for the text-only exact-patch requests and 2,926 for their structured semantic-capsule representation using o200k_base. The reduction was 95.0461%, rounded to 95.05%.
This is a local count of those request representations. The compared answer-and-receipt projections were 4,034 tokens in both paths. Total provider invoice savings are measured separately in a customer evaluation; the request reduction and avoided calls are not added together as independent bill savings.
Watch Aeternum introduce TokenHoloFold →02 / GLYX ARCHIVE
46.8% smaller
than same-content ZIP.
GLYX archive + restoration record793.6MB The private candidate retained 793,564,456 bytes for 1,650,532,800 source bytes. The same-content ZIP used 1,490,471,935 bytes. All 742 selected files restored exactly.
Required reconstruction data was retained in the complete archive. A new runtime carrier of 68,152 bytes and an existing installation footprint of 51,749,173 bytes were recorded separately. Counting both conservatively gives approximately 845.4 MB, about 43.3% below the ZIP comparison. Backups, staging, the operating system and working memory are additional.
This is a private candidate test on a real-work library cohort, rather than a promise for every file or an installed-customer benchmark. Exact restoration and full retained-size accounting remain the basis for evaluation.
Explore GLYX Archive →
03 / SEED STATE OS · NATIVE HARDWARE
99.48% fewer
engine cycles.
Conventional scalar firmware2,523median engine cycles
Source-generated native dataflow13median engine cycles
The retained 3 October 2026 same-FPGA comparison used the same bounded selective-path function and preproduced witnesses. Median engine-cycle reduction was 99.4847% (99.5% to one decimal place), or 194.08× fewer engine cycles. There were 128 requests per arm: 256 total, 192 accepted and 64 correctly refused, with zero incorrect complete outputs.
This FPGA task including communication was measured separately
For this FPGA experiment alone, completion-driven timing included the engine, communication and verification. It recorded conventional median elapsed time of 2.9465 ms and native time of 2.331896 ms: a 1.26356× ratio. Serial-loop throughput was 475.07 versus 366.31 requests per second, a 1.29693× ratio. These measurements include the transport around this operation; creation of the preproduced input witnesses is outside the comparison.
This supports the stated hardware operation and service. Whole-application reconstruction, operating-system performance, energy and battery life require their own measurements.
Return to the achievement overview →
04 / SEED STATE OS · SELECTIVE GPU UPDATE
4,096× less work.
353–354× shorter GPU execution.
A retained matched Metal study used one deterministic tile-local structured workload on the same GPU with the same operator. One of 4,096 tiles changed; 4,095 retained tiles stayed applicable. Across 32 rounds, dispatched logical threads fell from 536,870,912 to 131,072. Logical work-accounting traffic fell from 12 GiB to 3 MiB. Both are 4,096× reductions; logical traffic is distinct from physical bus traffic and electricity use.
Operational update results
Primary GPU execution ratios of means were 353.4893× and 354.4632× for those two arms. All 120 trial results matched exactly across both studies. Twenty hostile controls were refused with exact fallback, with zero false accepts.
Operational timing covered event access, identity/path checks, updates, GPU dispatch and completion, output-path maintenance and work accounting. It used warm retained state: initial warm-state construction and the independent full-output evaluator (approximately 93–94 ms) were outside that timer. An integration requiring that evaluator on every request must include its cost. Compact-output consumers must support that contract or count later materialisation. The retained July 2026 study was reconciled into the current evidence record in October.
Explore graphics and structured-state applications →
RETAINED CPU STUDY / COMPACT ROUTE VALIDATION
2,668× shorter
CPU validation time.
The retained July repeat of the matched structured-route study recorded a 2,667.6440× ratio in mean process CPU time and a 2,678.4904× ratio in mean wall time. The original study recorded 2,547.8000× and 2,563.8484× respectively. Both studies used 96 compatible deterministic fixtures and 2,880 validation checks per arm across ten replay blocks; warmups were excluded.
The comparator parsed, rebuilt and hash-checked expanded payloads. The compact route validated compatible retained structure using an existing local atlas and receipts. In the repeat, mean CPU time per replay block was 1,259.6615 ms for expanded validation and 0.4722 ms for compact route validation. Atlas construction and provisioning are retained input dependencies outside this per-block timer. This measures qualified route validation, rather than whole-machine CPU relief or arbitrary computation.
05 / RETAINED STRUCTURE COLLECTION
62.83% fewer
collection cycles.
The 9 October 2026 capacity comparison used sixteen slots versus one slot of the same native algorithm on the same board. Twenty requests across four recurring structures used 211,272 → 78,528 cycles (62.8309% fewer). Eighty requests across sixteen structures used 845,112 → 314,112 cycles (62.8319% fewer).
The cycle boundary included lookup, miss qualification, exact computation and state commit. External transport, initial clearing, diagnostics and archive I/O were outside this timer. This measures the value of retaining multiple structures against a one-slot control. The optimised conventional comparison below is a separate test.
06 / OPTIMISED CONVENTIONAL COMPARISON
17.01% fewer
resident-active cycles.
Optimised conventional comparator188,610resident-active cycles
Native tested candidate156,524resident-active cycles
The 9 October comparison used an optimised RV32IM direct 16-slot retained-descriptor cache with hardware multiplication, equivalent current assertions and the same exact state/output contract. Aggregate reduction was 17.0118% over the 48-request task per arm. All 96 physical requests passed 290/290 correctness checks.
Resident-active timing included the first reset and frame clearing, resident input delivery, lookup, miss qualification, arithmetic, guards/state commit and full result capture. Diagnostic inter-request USB pauses, offline provisioning and archive I/O were excluded equally. This is a later workload-specific result, separate from the 13-cycle witnessed-path operation.
07 / RECURRING STRUCTURE & QUALIFIED REUSE
31.51% fewer
recurring producer cycles.
On 9 October, the same frozen hardware image executed 25 requests per arm with retained-transform nomination disabled and enabled. The twelve recurring requests used 222,070 → 152,088 producer-core cycles, a 31.5135% reduction. The complete mixed 25-request corpus used 504,567 → 401,550 cycles, a 20.4169% reduction.
Each new target was checked completely before exact reuse. These are physical producer-core measurements; output-consumer qualification and archival restoration were separate. Complete USB response was approximately 9.581 versus 9.547 seconds, so the producer result is kept distinct from end-to-end service performance. Benefits depend on recurring applicable structure; the cold subgroup did not share the recurring gain.
08 / GLYX & SEED STATE · EXACT PERSISTENCE
Exact records.
Qualified reuse.
Exact restoration of retained numeric bases and current native software readmission were qualified separately. The later 138-request batch retained 16,167 archive-and-pin bytes versus 16,679 for identity-only encoding: 3.0697% less. The optimised conventional transform also retained 16,167 bytes, preserving parity. Runtime storage was a separate 10,787,643 bytes.
Unchanged verified native readmission evidence was reused for all 138 requests. Hardware producer work, software/RTL output consumption and archive restoration have separate evidence boundaries. A full TokenHoloFold/GLYX/Seed State customer integration measures their combined latency, quality and retained dependencies together; component percentages are not added or multiplied.
See how the products connect →LATEST / ARCHIVE + SEED STATE · 17 OCTOBER 2026
More related versions.
Less retained data.
On one synthetic versioned-data workload, the accepted Seed State archive component retained 57.3% fewer logical bytes than trained Zstandard and 37.9% fewer than compacted Borg. Each arm retained 96 formation versions and 1,536 fresh versions; all 9,216 fresh full and selected-range checks passed.
Seed State completed this workload 6.75× faster than Borg including its separately measured post-run standard compaction. Zstandard completed it faster than Seed State. Logical archive reduction does not equal the physical-disk or cloud-invoice reduction: both storage boundaries are shown above.
Complete time includes formation, setup, requests, durable storage, reconstruction, verification, restart and final checks. Retained counts include archive, pin, dictionary, cache and security files. Runtime installation and shared laboratory costs are reported separately. This used warm OS caches and process restart. Borg's fine-grained archive/restore workload is not a general backup-throughput benchmark; Zstandard used one fixed trained dictionary without an additional cross-version deduplication layer.
Later bounded bookkeeping optimisation
A separate fresh 17 October run reduced total time from 89.41 to 71.37 seconds (20.2%) while retaining the same 32.45 MB. Its 9,216 fresh reconstruction checks passed. Useful-request latency was essentially unchanged; the gain came from bookkeeping. Trained Zstandard took 50.57 seconds and retained 75.95 MB in that run. This isolated candidate has not been adopted into a customer product.
These software studies extend the archive/state evidence. They do not replace GLYX's 742-file desktop cohort, the FPGA results or a complete three-product customer evaluation. Ratios from different runs are kept separate.
Compare product and combined licences →LATEST / GLYX COMPLETE OPERATION · 19 OCTOBER 2026
Faster complete operations.
The same exact archived content.
A private macOS engine study compared the existing GLYX engine, an isolation control and a candidate across six authored workloads. The 108 fresh worker runs comprised six repetitions of each workload in each of three arms. The unchanged native decision programme executed in every arm.
Four workloads met the preregistered improvement threshold of at least 5% lower median time and at least 80% faster paired trials. Structured records and multiple sections did not meet that threshold. These results describe the tested workloads, rather than a universal speed guarantee.
What the complete-operation timer includes
Archive input ingestion, native-worker preparation and teardown, full and selected-range restoration, exact checks, a fresh reader process and storage accounting. Parent-process startup, initial software-module loading and fixture construction are outside this operation timer and are included in the separately recorded complete-worker measurement. This engine comparison is separate from desktop interface and customer installation performance.
Exactness and working memory
All 1,656 exact-output checks and 15 controls passed. Seventy-two matched archive and decision comparisons agreed. The candidate retained the same archive sizes and native decision results.
The largest measured child-process peak was about 129 MB. Several baseline workloads peaked at about 34 MB; the structured-record baseline already reached about 129 MB. Parent-process memory was recorded separately, so these figures are not a combined whole-application peak. Working memory is distinct from retained archive storage.
A bounded, selectively activated version is a proposed next optimisation. Its selection cost, memory cap and complete-operation benefit have not yet been demonstrated. These GLYX results do not add a new measured speedup to Seed State OS or to the combined product stack.
Return to GLYX Archive →HISTORICAL CONDITIONAL ENERGY PROJECTION · 25 JULY 2026
Three assumed scenarios.
94.05% arithmetic average.
This is an illustrative historical model, separate from the measured CPU, GPU and FPGA results. It weights work, timing and byte-avoidance proxies by assumed non-overlapping baseline energy shares. Those shares were not measured or calibrated to a representative customer workload.
Projected saving = the sum of each assumed baseline energy share multiplied by its proxy reduction. The historical coefficients are GPU 99.7155%, CPU verification 99.7070%, disk writes 99.9263%, materialisation 98.6101% and unchanged overhead 0%. The unrounded scenario results are 89.716030%, 94.712345% and 97.714520%; their unweighted arithmetic mean is 94.047632%.
The mean describes these three assumed scenarios. It is not a statistical expectation or a confidence interval. Timing and avoided work do not directly measure electrical energy. The model assumes compatible retained state and a small change frontier. Setup, idle draw, transport and evaluator energy are not separately calibrated; the unchanged overhead share is an assumption. Stage speed ratios are not multiplied together.
These figures project energy for equivalent completed work. Average watts also depend on runtime and workload rate. Direct electrical measurement and complete deployment accounting remain necessary before claiming actual device-wide power, energy, bill or battery savings.
Return to Seed State OS →