What changed, and when.

1. 2026-10-29

   Every figure stays free, and what explains or prescribes is locked on the server

   • The free report keeps every measured figure and draws the line at explanation: the cause of the curve, what its shape means, the plain-words explanation, the reason behind each use after the first, the fix steps after step 1, the prescriptions and the retest target are now withheld on the server and shown as a locked panel. No figure moved behind the unlock.
2. 2026-10-29

   Revision 2026.09.18

   Time in another tab no longer shortens path tracing, and more windows and devices can run the test

   • The stages pause while their tab is hidden, but the run's end was fixed at launch, so time spent in another tab came out of path tracing. The run now moves its end later by the time the tab was hidden, and the report says when path tracing still ran at its 20-second minimum. No figure is worked out differently.
   • Windows from 768px wide can run the test: under 900px the stage shows its readouts below the scene instead of beside it. A 2-in-1 laptop folded into tablet mode is no longer turned away; phones and small tablets still are.
   • A browser drawing graphics in software, with hardware acceleration off, is told so before the run with the steps to turn it back on, and the report labels it. The score is unchanged.
   • The CPU stage shows a still picture of a fire instead of playing a video, because decoding video uses the processor being measured. Measured on one laptop in three pairs of runs, the video cost about 5 to 6% of the sustained CPU figure and about 10% of the peak, so CPU figures and the score are not compared with reports from before this revision.
   • The launch control is announced as a button that starts the test, and only Enter or Space starts it from the keyboard. The first screen lists what to do before a run, including that it cannot be paused.
3. 2026-10-07

   Revision 2026.09.17

   The CPU stage measures the processor, not the browser's JavaScript engine

   • The CPU stage's kernel is now WebAssembly. The JavaScript kernel it replaces asked the browser for every sine and cosine, so part of what it measured was the browser's own engine, and the same processor could read differently in two browsers. The new kernel does the same work for each counted operation and works out its sine and cosine itself. The stage's length, windows, warm-up, decay and curve are unchanged.
   • Operations per second are on a new scale, so CPU figures and the score are not compared with reports from before this revision. A browser that cannot run WebAssembly falls back to the JavaScript kernel; the report says so and does not compare those CPU figures with WebAssembly runs. Measured side by side on one laptop, the CPU figure reads several times higher on the same machine, because the work no longer waits on the browser's own maths functions. The score's CPU scale moved with it, so the same machine scores much the same on either kernel; the figures themselves are not comparable across the change, and the scale stays provisional until it is confirmed on a desktop and in a second browser.
4. 2026-10-07

   The full report reads in your language to the end

   • The paid half now follows the language of the free half: the fix steps, the cause and its caveat, what else draws the same shape, the retest target, the graphics chip's curve beside the processor's, the battery note, the boost readings and the sensor-log confirmation are all translated into German, Spanish, French, Hindi, Japanese and Brazilian Portuguese. They are translated on the server, so nothing of the paid text reaches the page before it is unlocked, and the English report is unchanged. Every translation keeps the report's hedging: a shape is consistent with a cause, and a sensor log is what confirms one. The translations are machine-assisted and still await a native speaker's review. Nothing measured changes.
5. 2026-10-07

   The processor, graphics, glossary, guides, blog and diagnose hubs explain themselves

   • Each of the six hub pages now opens with a written introduction: what it holds, how to use it, a link to the test and to its most useful pages by name. Each closes with the questions a visitor to it asks, answered from what the site does. Counts in the text are read from the catalogue and the content index, so they cannot drift from the list below them. The site-wide share image is now withheld from search crawlers like the per-page ones, and stays open to link previews. Nothing measured changes.
6. 2026-10-07

   Revision 2026.09.16

   Each headline figure shows the spread inside its run

   • In the full figures table, CPU sustained throughput, GPU sustained frames per second, path tracing samples per second, memory bandwidth on all threads and on one, and the soft-shadow frame rates now carry a 95% interval in brackets, for example 42.4 M ops/s (41.6 to 43.2). It comes from a moving-block bootstrap over the stage's own windows, so the dependence between neighbouring windows is kept. Memory latency and the soft-shadow cost have too few values for that and show the range of what was measured instead. The intervals are in the exported JSON too.
   • The interval is the spread within this one run, not between runs or machines; on ten runs of one laptop only six of the ten CPU intervals contained the ten-run mean. The repeat runs remain the way to see run-to-run spread. No figure changed, and reports from before this revision are compared as before.
7. 2026-10-06

   A report saved offline sends itself from the background

   • A report that could not be sent for want of a connection is now sent by the site's service worker when the connection returns, even after the tab is closed, in browsers with Background Sync (Chrome, Edge). An open report page shows the link as soon as it is built. The page and the worker never send the same report twice; Firefox and Safari keep sending it from the page when the connection returns or on the next visit. Nothing measured changes.
8. 2026-10-06

   The free report speaks the run's language

   • A run started from a German, Spanish, French, Hindi, Japanese or Brazilian Portuguese page now shows its free report in that language: the answer, the run-quality notes, the curve, the plain words, every figure's label and note, the finding and fix titles, the bands and the comparison with an earlier run. Numbers keep their digits and take the language's own separators. The translations are machine-assisted and have not yet had a native speaker's review.
   • The paid explanations, the PDF and the emailed copy are still in English for now. Nothing measured changes.
9. 2026-10-05

   The live CPU readout uses the report's definitions

   • While the CPU stage runs, the line under the chart now reads the boost as a boost: Boosting while the cores hold their best level, then Boost ended, settling with how far below the boost they are. Once the 10 to 20 s settled level exists it shows the loss since the machine settled, measured as the report measures decay, so the figure at the end of the stage matches the report except for the final window, which the report leaves out. Nothing measured changes.
10. 2026-10-05

    A figure unlike this machine's earlier runs is a run-quality note

    • When this device remembers at least three earlier runs of the same machine in the same browser, measured the same way, the free report now notes any stage figure that reads far outside their usual spread, for example graphics reading 265 fps against an earlier median of 156. It says the run differed and asks for a repeat; it does not name a cause. The check runs in the browser on the runs it remembers, and nothing about them is sent anywhere. Nothing measured changes.
11. 2026-10-05

    The run comparison respects revisions, and the full report reads the boost apart from the settled decay

    • The before and after comparison on your own device now checks the revision each run was measured under. A figure whose meaning changed between the two runs, such as CPU decay before and after 2026.09.15, is shown side by side with the note that it was measured differently and is not compared. Runs saved before the revision was recorded are treated as older.
    • On a run that boosted briefly and then dropped once to a steady level, the full report now describes the opening step as the boost ending, which is normal on many laptops, and points the fix plan and the retest target at the settled decay. A step later in the run keeps its reading and suggests a sensor log to confirm it. Reports from before 2026.09.15 read as they did.
    • The landing pages in all six languages, the glossary, the guides, the test pages and llms.txt now describe CPU decay the way the report measures it: what the machine loses after its boost ends and it settles, with a short boost and one step down early in the run shown on its own as the boost step. They no longer count the boost as part of the loss, and the normal band reads under 8%, the edge the report uses. Nothing measured changes.
12. 2026-10-05

    Revision 2026.09.15

    A short boost reads as a step, and CPU decay is measured from where the machine settled

    • A laptop that runs at full boost for a few seconds and then drops in one move to a steady level is now named Plateau, then a step down. Before, a boost that short could miss the plateau the classifier needed, and the flat line after it was named by chance: ten runs of one laptop gave six names, and now eight of the ten give the same one.
    • CPU decay is now measured from the level the machine settled at after its boost, against the end of the run, and the boost is its own figure: how far above the settled level it ran, and when it ended. The report says it in plain words, for example that the machine ran at full boost for about 5 s and then settled 22% lower. CPU retention in the score and the decay bands read the settled decay, so a machine that boosts briefly and then holds steady scores higher on CPU retention than before.
    • Reports from before this revision keep their single decay figure, which included the boost, and are not compared with reports from after it.
13. 2026-10-05

    Confirm a curve with the companion, its readings on the report, and accessibility and privacy notes

    • The companion scripts have a logging mode. Started before a run, they write the processor frequency, performance and speed limit, a thermal zone and the power source once a second, as the operating system gives them, with nothing estimated. On an unlocked report, Confirm this curve lines the log up with the CPU curve and says whether a sensor event matches the step or the slide; it names a cause only when one does, and otherwise lists what else draws the shape.
    • A report gets a From the companion section when you add the companion file: battery design and full-charge capacity with the wear, drive health as Windows or SMART reports it, and the graphics driver and BIOS versions. It is measured data, so it is free, and a figure the file does not hold reads Not reported.
    • The motion and display tests say before they start that they are visual and what kind of thing they draw, and that a motion test can be left out. Status dots in the device lab carry a word as well as a colour.
    • The privacy page lists what is stored, for how long, and where no period is set yet. With your analytics choice, the record of a report's opening carries four coarse labels to measure whether the paid report helps.
    • Nothing measured changed, so the measurement revision stays 2026.09.14.
14. 2026-10-05

    The method as a specification, and a fingerprint you can check

    • The methodology page says how repeatable a run is, from ten Standard runs on one i5-1245U laptop on mains power: CPU sustained throughput varied by 2.8% from run to run, the overall score by 3.4%, memory latency by 5.8%, path tracing by 13.2%, memory bandwidth by 14.1%, and GPU frames per second by 21.2% (3.9% without one outlying run). The CPU curve's shape did not repeat on that machine, and the page says so.
    • The methodology page opens with a specification of every stage: the workload in general terms, its length, its warm-up, how it is sampled and what is left out, each read from the constants the stages run on. It adds the names of the curve shapes with a line on each, what the three confidence levels mean, the conditions that invalidate a figure, why the GPU stages render at a fixed resolution, and what a browser cannot see, with a link to the companion scripts for the part they can read.
    • The page no longer prints the score's weights and normalisation bounds. They are provisional and will be refitted; every measured figure the score is built from stays on the free report and in its export.
    • A saved report shows a short fingerprint, signed by this site over the run's measured figures, its measurement revision and the time it was stored. The verify page checks a report link or id against a fingerprint, or an exported file from a saved report, and says whether they match. A report edited after it was stored does not match.
    • Nothing measured changed, so the measurement revision stays 2026.09.14.
15. 2026-10-03

    Export your run's raw data, and the words stop naming a cause as fact

    • The free report has an Export data control. It saves the run as JSON, or each stage's windows as CSV: the timestamped CPU and memory windows, the ones left out for lost focus and why, the focus spans, each stage's spread, the run-quality notes, and the browser, operating system, renderer, isolation state and measurement revision. It is built in your browser from the run you just did and holds nothing from the paid report.
    • Pages, guides and answers that named throttling, heat or a power limit as the cause of a curve now say the curve is consistent with one, and that a sensor tool or the companion confirms which. A browser cannot read temperature, clocks or power, so the shape is evidence, not proof.
    • Nothing measured changed, so the measurement revision stays 2026.09.14.
16. 2026-10-03

    Revision 2026.09.14

    Memory and soft shadows leave out a lost focus, and the sustained write asks to keep its storage

    • The memory stage leaves out every bandwidth window that overlaps a time the window had no focus, as it already did for hidden time, and the report counts the time and the windows.
    • The soft shadow stage leaves out each one-second window without focus inside its segment. A segment that loses more than half of its windows takes its whole pair of segments out of the cost, which keeps soft and hard shadows balanced; the result says how many of the three pairs counted, and with none left the cost reads not measured.
    • The sustained write asks the browser to keep this site's storage as persistent when you press Start, never before. Some browsers answer silently and some ask you; it affects only this site's private store, and the files are still deleted at the end. The size is then worked out from the browser's figure after that request, and the result says whether storage was persistent. In a fresh Chrome profile the store had refused writes after 1.8 GiB while reporting 10 GiB free.
    • A run that kept its focus reads exactly as before. Reports from before this revision are not compared with reports from after it.
17. 2026-10-03

    Revision 2026.09.13

    The curve says what a shape is consistent with, a lost focus is left out, the GPU syncs in batches, and a ten-minute run

    • The report names the shape of the curve and what it is consistent with, never the cause: a step is consistent with a power limit expiring, a slide with heat building up. The full report lists what else draws each shape: a window that lost focus, after which the operating system can move the work to efficiency cores; a switch from mains to battery; a background scan or update.
    • The test records when the window loses focus. Every CPU window, GPU window and path tracing sample that overlaps a span without focus is left out of every figure, as hidden time already was, and the report says how long the window lost focus.
    • The GPU stage reads a pixel back once every few frames, about every 100 ms and never fewer than 4 frames, in place of after every frame, and divides each batch's time by its frame count. Reading back every frame measured the round trip through the browser's GPU process as much as the GPU, so the scored frame rate rises on fast graphics chips; the old per-frame figure is kept as the per-frame round trip, for information. The soft shadow stage does the same, and never lets a batch span its change of mode. Interleaved on the validation laptop on mains, the old method held the stage at 58 to 63 frames a second, the display's refresh, while the chip needed 4 to 5 ms a frame; the new one read 132 to 253. GPU raster figures from before this revision measured the refresh on machines like it and are not compared with figures from after. The table is in the validation notes.
    • Every stage with windows reports its run-to-run spread inside this run: the coefficient of variation of its own windows. It is spread within one run, not between runs.
    • A third run kind, Extended: the Deep run with ten minutes of CPU load, as Cinebench 2024 runs by default, sixteen and a half minutes in all and free like the others. Its curve is long enough to show a slow thermal slide and a maker's boost window longer than 100 seconds. The curve reader keeps bins of the same width on a long run, so 60 and 150 second runs read exactly as before.
    • Reports from before this revision are not compared with reports from after it.
18. 2026-10-03

    Revision 2026.09.12

    Soft shadows run a round minute in a light scene, and the standalone pages lose their second button

    • The soft shadow test, standalone and as stage 6 of the Deep run, is a 6 second warm-up and six 9 second segments in the same balanced order, 60 seconds in all, where it was a 3 second warm-up and six of 10 (63 seconds). The Deep run stays nine minutes; path tracing takes up the 3 seconds.
    • Its scene is drawn in the site's light theme: a light ground and sky, accent pillars. Only colours changed; the passes, the shadow map, the samples, the light, the geometry, the camera path and the resolution are the same. Interleaved on the validation laptop on mains, the hard-shadow rate did not move, but the soft-shadow rate read about 10% lower in this revision and its cost a few points higher. Colour costs no pass, and a build with the light scene on the old schedule confirmed it: the new schedule alone read about 10% lower on the soft-shadow rate and 7% on the hard one. The table is in the validation notes. Reports from before this revision are not compared with reports from after it.
    • The responsiveness test measures 10 seconds idle in place of 5 before its 30 seconds under load, 40 seconds in all. It is standalone and not part of the run.
    • The five standalone test pages (storage, recovery, responsiveness, WebGPU compute, soft shadows) no longer repeat their run button in a section of its own: the button at the top of the page opens the test.
19. 2026-09-30

    Revision 2026.09.11

    The floor holds still while a stage measures, and the graphics figures rise

    • The board of tiles behind the tool kept lighting its tiles under the stages, out of sight, and each lit tile repaints a large tilted layer every frame. That work competed with the stages being timed. It now holds still from the moment a stage starts measuring until the result, and moves again on the set-up and result screens.
    • Interleaved on the validation laptop with the old animation forced back on for half the runs, path tracing read 21 samples a second with the floor moving against 32 with it still, and the GPU raster stage scored 38 to 40 frames a second against 50 to 53. The graphics chip's time per path tracing sample barely moved, so the floor took the stage's time rather than slowing each sample. Earlier graphics figures on a chip of this kind were held down by about a third and a quarter.
    • The same check caught the standalone WebGPU compute test's own animated picture competing with its shader, which cut its figure from about 90 GFLOP/s to 10. That picture, and those of the storage, recovery and responsiveness tests, are now drawn from the measurement's own updates and never on a clock of their own. No stage's work changed. Reports from before this revision are not compared with reports from after it.
20. 2026-09-30

    Revision 2026.09.10

    Every pixel of the path tracing stage does the same work

    • The path tracing shader no longer stops a march at its first hit. The primary march runs 22 steps, the reflection march 10, the shadow cone 8 and the occlusion probe 6 taps on every pixel, sky included: a ray that has hit stands still for its remaining steps, and a sky pixel shades the far point of its ray and keeps the sky. The cost of a frame is now level across the course instead of following what the camera sees, which on an integrated chip whose clock chases its load had the per-sample figure wandering by a quarter between runs of one build.
    • So that the picture survives a short fixed march, the floor plane is met by arithmetic instead of stepped toward, the hit tolerance grows with distance and stays under half a pixel, and no step crosses a pillar cell. The scene, its materials, the ball, the course and the display pass are unchanged.
    • The counts were matched to the early-exit shader's mean cost by interleaved A/B on the validation laptop, so samples per second keeps its scale. The table is in the validation notes, which also say what the change did not do: on the laptop the run-to-run spread did not narrow, since both builds fell together as the machine cooled, so the clock following temperature is the larger part of that chip's wander. Reports from before this revision are not compared with reports from after it.
21. 2026-09-29

    Revision 2026.09.9

    The GPU curve has a shape too, and the threads say how evenly they ran

    • The GPU stage records its frame rate in each one-second window after warm-up, and the report classifies that series with the same bins, noise gates and classes as the CPU curve. A Standard run reads its 50-second pass; a Deep run reads its first 30-second loop, the one GPU retention is scored over. A frame rate sitting at a display-refresh or timer floor is not classified, because the curve is then the floor's, not the chip's.
    • The unlocked report shows the GPU shape beside the CPU shape, with its likely cause and the two read together: a GPU that steps while the CPU slides is two limits, both falling alike is more likely one shared one. The free half shows nothing new.
    • The CPU stage records each thread's rate per window and the report states the spread between threads, the coefficient of variation of the threads' mean rates, as information only. Processors with performance and efficiency cores widen it by design, so no verdict is drawn from it until it has been measured across such machines.
    • Nothing a stage runs changed and no score moved, but a result now carries two series it did not before, so reports from before this revision are not compared with reports from after it.
22. 2026-09-29

    Revision 2026.09.8

    The memory stage counts

    • The memory stage is scored. Its six-stream bandwidth is a sixth component of the score, with a small share, on the same logarithmic curve as the other performance components between provisional bounds: the floor sits below a phone or a single memory channel and the ceiling above a DDR5 laptop, with room for quad-channel and unified-memory parts. The bounds are reasoned from the runs recorded so far, not fitted.
    • The five earlier weights were scaled down by the same factor to make room, so their ratios to one another are unchanged.
    • Memory counts only when the stage ran fully. A stage that fell back or paused for a hidden tab is reported and left out, with its weight spread over the other five and the score marked partial, as for any other stage that did not measure. Latency and scaling stay reported, not scored, because both depend on the JavaScript engine as much as on the memory.
    • Reports from before this revision are not compared with reports from after it.
23. 2026-09-29

    Revision 2026.09.7

    The measurements say what they measure

    • The path tracing scene is stepped by elapsed time, not by sample count: the ball rolls 1.2 units a second on the stage's own clock, so a slow chip and a fast one trace the same course over the same seconds and only the number of frames differs. The stage keeps its name; the methodology page now says the work is a raymarched scene with one reflection bounce, cone-traced shadows and ambient occlusion, not a Monte Carlo path tracer.
    • The soft-shadow segments run in ABBA order (PCSS, hard, hard, PCSS, PCSS, hard) so a machine warming during the stage no longer flatters the soft mode, and the cost carries the spread between its three paired segments in place of the word exact.
    • The Deep hot re-test is a fixed 30 seconds that starts the instant path tracing ends, with no transition screen; path tracing absorbs the run's slack instead. The re-test is called matched inside the run's own noise gate, 2.5 times the larger sample jitter of the two stages and never under 1%, rather than a flat 1%.
    • The memory stage stops its clock while the tab is hidden and drops any bandwidth window that overlaps the hidden time; the globe behind it holds still while the phases measure. The screen stage records the raw median and the densest-cluster estimate beside its snapped rate and says whether they agree; its copy says it measures compositor delivery, not the panel.
    • The combined stage's CPU comparison is per thread, and the report says how many threads ran and that one was left for the frame loop; the GPU comparison is shown as measured rather than clamped at 100. The GPU result records which scene rendered, and the report says when it was not the primary; the sustained frame rate is printed beside the scored peak under its own name.
    • Scoring: GPU retention at a timer or refresh floor is left out rather than credited with 100, retention health is null when neither retention part counted, and every grade word carries provisional. One set of decay lines (8, 15 and 30 percent) serves the score, the reference bands, the plain words and the report, and the noise gate is one exported constant.
    • Copy corrected without changing a measurement: the GPU timing note (every browser times frames the same way; a timer query only adds a GPU-side figure), the live CPU tile (counted iterations, no assumed 68 operations each; the unsourced responsiveness tile is gone), the GPU load label (a frame-time class, not VRAM), the video stand-ins for a GPU stage or tracer that cannot run (every figure labelled an example, and the tracer's proxy reports null consistency instead of 90), the memory reading (how bandwidth scales, naming no hardware), and the validation notes (one hot re-test, not two).
    • Reports from before this revision are not compared with reports from after it.
24. 2026-09-29

    Revision 2026.09.6

    The path tracing picture is clean in every frame

    • The light in the path tracing scene is exact within each frame: cone-traced soft shadows and ambient occlusion in place of one random light sample per frame. The chrome ball carries a band in the site's blue that turns as it rolls, the pillars carry a lit ring, the gates glow, and the sky carries the accent.
    • The path tracing scene is a chrome ball rolling through a course of pillars and lit gates over a near-mirror floor, the camera following it, in the site's own palette. The course is fixed, so every machine traces the same scene.
    • Every frame of the path tracing stage is laid on the last by reprojection: the camera and the ball move deterministically, so each pixel of the previous frame is placed exactly on this one, and the picture converges across dozens of frames without smearing what moves. Each sample now carries its depth for that; the work per sample is otherwise unchanged.
25. 2026-09-25

    Revision 2026.09.4

    The path tracing stage rolls

    • The path tracing scene is a chrome ball rolling through a course of pillars and lit gates in a white studio, with soft shadows and reflections, in place of a still scene of two spheres. It advances one step per sample, so the ball rolls exactly as fast as the graphics chip can trace: the picture is the figure.
    • The per-sample cost of the new scene was matched to the old one on the same machine, so the samples-per-second scale holds. Reports from before this revision are not compared with reports from after it.
26. 2026-09-11

    Revision 2026.09.2

    Runs of a fixed length, and a deep run with seven stages

    • Both runs are a fixed length from launch to report: three minutes for the standard run and eight for the deep run. The last stage runs to the run's deadline, so a slow shader compile shortens it instead of lengthening the run.
    • The standard CPU stage is 60 seconds, past the 56-second boost window some boards use as well as the common 28-second one. The standard GPU stage is 50 seconds.
    • Path tracing runs over a fixed time, paced to about 150 samples, instead of stopping at 150 samples. The pause before it is gone, because a pause lets the machine cool.
    • The deep run has seven stages: the screen's refresh rate, frame pacing and late frames; two and a half minutes of CPU load; memory; the GPU pass looped three times; CPU and GPU loaded together; path tracing; and a hot re-test of the CPU against the cold stage.
    • Reports from before this revision are not compared with reports from after it.
27. 2026-09-07

    The scene in the window, the reading beside it

    • Every stage shows the thing under load in the window (the fire loop with a bar per core over it, a bar per stream for memory, the raster scene, the tracer resolving) and does the reading in the side pane: trace, readout, phase markers, tiles, checkpoints, what comes next.
    • Set-up is one screen: the processor, what the browser already detected, the kind of run. The fake graphics-probe animation is gone.
    • Every content page has a plain-text twin at its address plus /llms.txt for AI readers. Landing pages for seven audiences and seven symptoms. Pricing, FAQ, security, accessibility and this page.
    • Copy tightened across the site; the homepage no longer claims a contention class the classifier does not have.
28. 2026-09-07

    The report opens in plain words

    • Is the cooling good, what the machine is good for (everyday, coding, photo, video, gaming, AI), strengths and weaknesses, before any chart.
    • Apple M-series and Qualcomm Snapdragon X parts in the processor catalogue, 1,634 entries in all.
29. 2026-09-07

    Revision 2026.09

    The deep run

    • A three-minute CPU stage that reaches thermal saturation, with the settled level taken as the median of three windows and its spread stated, and the time to saturation.
    • The GPU pass looped three times with a worst-over-best stability figure in 3DMark's form.
    • The CPU stage pauses when the tab is hidden and the report says so. A run on battery, a single-core fallback and starved workers are flagged as run quality.
    • Validated on real hardware; the saturation gate scales with the measurement's own noise. Written up in the methodology.
30. 2026-09-07

    Validated on a real machine, and fixed what lied

    • The chunk ledger attributes worker work to 250 ms windows by overlap on a shared clock. Warm-up excluded from the peak; consistency and noise floor computed on one-second means.
    • The curve classifier became noise-aware: reversal and dip gates scale with the noise floor and confidence is capped when noise is high. Twelve real runs are the fixture.
    • Contention that quietly shares a core was shown not to be detectable within one run, and the site now says so instead of claiming it.
31. 2026-09-06

    A cause, not just a decay figure

    • The CPU curve is classified as held, a single step down, a steady slide, oscillating, erratic, dipped and recovered, or insufficient, with a stated confidence.
    • The paid half of the report is built from the class: the cause, the first fix and the retest target. The invented percentile and synergy figures were removed.
    • Before/after: the last five reports stay in the browser and a run on the same processor is compared curve over curve, with anything inside the run-to-run spread called no change.
    • Email a link back to your own report, where the deployment has it configured.
32. 2026-09-05

    Security and request guards

    • Signed report tokens, per-route rate limits, size-capped and field-validated bodies, a content security policy and the full set of security headers.
    • Analytics and error reporting proxied through this origin. Dependency fixes and a green browser suite.

A revision bump means two reports either side of it are not comparable; the report carries its revision. Corrections follow the corrections policy.