12 Sep 2026 — This print includes gemini-3.1-pro-preview, whose Google Cloud billing predates the point where it was isolated to this project alone. Before that, a real, unexplained cost gap was found between Google's actual billed Gemini cost and this project's own computed cost on every day independently checked (2026-09-08 through 2026-09-10 -- 2026-09-08 far larger than the others, but the gap wasn't confined to that one day). This project's own per-token pricing was independently verified against Google's real published rates and confirmed correct, ruling out a calculation error on this project's side -- but the cause of the gap itself was never established, and Gemini's own real invoice cost for any day before isolation cannot be attributed to this project with confidence. Because that evidence gap cannot be reconstructed after the fact, this print will remain status: "provisional" permanently, not through neglect. See docs/methodology.md's Index governance (§7) for the general policy and the isolation fix that resolves this for prints going forward.
12 Sep 2026 — Correction to this print's own correction note above: that note framed the real-vs-computed Gemini cost gap around Google Cloud billing "isolation," implying a shared project or key might explain it. That's now confirmed wrong. The Gemini API key this project uses (siu-runs-prints, created 2026-08-30) has been dedicated solely to this project's SIU print runs since its creation -- no other Google Cloud project has ever used it. There was no shared-billing contamination to isolate, and moving it to its own dedicated project changed nothing that needed changing. The real gap -- a real ~2.7x cost spike on 2026-09-08 against every neighbouring day, and a persistent mismatch against the real, dated exchange rate found on every other day checked -- remains genuinely unexplained. This project's own per-token pricing was already independently verified against Google's real published rates and confirmed correct, so it isn't a calculation error on this project's side either. This print's status stays "provisional" for the honest reason that a real gap's real cause is still unknown -- not because a diagnosed shared-billing problem was found and fixed, which the correction note above incorrectly implied. See docs/methodology.md's Index governance (§7) for the current, corrected state of this investigation.
13 Sep 2026 — Correction to this print's own two prior correction notes above: the first attributed a real Gemini cost gap to shared Google Cloud billing; the second retracted that as wrong but said the true cause remained unknown. Both are now superseded -- the cause is confirmed, and it is two distinct, real bugs in this project's own code, both now fixed forward (commit 48ba69c). (1) RunRecord.usage.cached_input was captured by every provider adapter but never priced by this project's cost formula -- a real, unconditional gap, not specific to Gemini. For this print specifically: gemini-3.1-pro-preview: 81827 cached tokens, $0.016365; grok-4.6: 7168 cached tokens, $0.000004 -- together understating the published cost_of_production_usd ($1.3658) by $0.016369. This is not the hypothetical cache-adoption policy docs/methodology.md's sensitivity block already models (cachePolicyVariant) -- this cache use actually happened and was actually billed. (2) Separately, and the larger effect for gemini-3.1-pro-preview: the Google adapter (also the Anthropic and OpenAI adapters, structurally, though not yet triggered in practice for either) discarded a real, separately-billed API call's usage whenever Gemini's mandatory reasoning -- thinking cannot be disabled for this model -- consumed the whole completion budget and triggered an internal retry with a bigger one; only the retry's usage was ever recorded. This fires on nearly every gemini-3.1-pro-preview call, which is why Google's real per-day billed token counts (confirmed against the real Cloud Billing SKU breakdown) were consistently higher than this project's own recorded usage, including on ordinary days, and why 2026-09-08 specifically (and 2026-08-30, this project's first day) showed a real spike: this retry simply fired unusually often on those two days. Each affected run record's own deviations field carries the discarded call's real reasoning-token count; its real input-token count and full raw response were never saved, so this piece cannot be reconstructed precisely after the fact -- unlike (1) above, which is exact. Neither bug is corrected on this print's own signed cost_of_production_usd or dated_siu -- a published print's signed body is never edited -- so this print remains status: "provisional" permanently: bug (1)'s effect is now precisely known (above), but bug (2)'s cannot be fully reconstructed, so full retroactive reconciliation of this print isn't achievable. See docs/methodology.md's Index governance for the current, corrected explanation.
25 Sep 2026 — dated_siu previously rounded to a fixed 4 decimal places rather than 4 significant figures — found live and fixed the same day, 2026-09-25 (docs/methodology.md's Rounding section). At this print's price level that was too coarse to show real day-to-day movement. This print's signed body is never edited — the published figure (0.0142) stands. Recomputed from this print's own published basket_costs and weights (Σ weight × basket_cost, rounded under the corrected 4-significant-figure rule, reproducible by anyone from this print's own published figures alone), the real value is 0.01416.
25 Sep 2026 — Correction to this print's own rounding correction note above: that note's phrase "the real value is X" overstated what the recomputation shows. It restores rounding precision only — the precision a fixed 4-decimal-place rounding rule removed, recovered by recomputing Σ weight × basket_cost from this print's own published figures. It is not a claim that the recomputed figure is this print's true economic value. This print's own basket_costs are also affected by the reasoning-token and/or cached-input pricing correction disclosed elsewhere in these notes — usage that was under-priced before that fix landed — so the recomputed rounding figure is the unrounded version of a value already known to need that separate correction too, which this recomputation does not make. See docs/methodology.md's Rounding section for the general statement of this limit.
▲ +0.7% since 10 Sep 2026 — More expensive than the previous print.
Equal weighting, disclosed: basket costs span 4.4× across
the 6 qualifying constituents. 3 of 6 constituents
(50%) sit at or above the mean basket cost and together account for
74% of the summed basket cost Dated SIU is computed from — equal weighting still
gives each of them the same 1÷6 nominal share. Dated SIU therefore tracks the more
expensive end of the basket more closely than a demand-weighted index would. See the
methodology's Weighting section, and Frontier SIU / Commodity SIU, the tier prints published
alongside this one for exactly this reason.
Exchange-rate table
Model
USD / SIU
Spread to index
SIU per $1
claude-sonnet-5
$0.0237
+68%
42.1
gpt-5.1
$0.0092
-35%
108.6
gemini-3.1-pro-preview
$0.0217
+53%
46.0
grok-4.6
$0.0172
+21%
58.1
claude-haiku-4-5
$0.0078
-45%
128.6
gpt-5.4-mini
$0.0053
-62%
186.9
Floor & market spread
Not yet published — the floor needs a measured hardware-rental rate for the reference configuration, which this print does not yet include.
Sensitivity
The print recomputed under alternative cache and batch-discount policies, so the effect of those policy choices is stated rather than hidden inside one number.
Policy variant
Dated SIU
Delta
Applies to
cache-enabled: 40% of T2 input at 10% of input price
Dated SIU is an assessment of qualifying inference work under this basket version, model/provider configuration and quality gate — not a prediction of production agent costs, which vary with workflow design, tool reliability, retry policy and context handling.
Verify this yourself
Don't take this page's word for it — every value below is checkable independently. Read the steps, run one command, or have an agent read verify.json.
Remove exactly these five fields and keep everything else as published: signature, public_key, anchor, superseded_by, correction_notes. The last three are added after signing, which is why they cannot be part of the hash.
Canonicalise what is left with RFC 8785 (JCS): keys sorted, no whitespace, numbers and strings as JSON writes them.
Take the keccak256 hash of the UTF-8 bytes of that text (the original Keccak padding Ethereum uses, not NIST SHA3-256). Written as 0x and 64 hex digits, it equals the body hash above.
Plain Node 18 or later, nothing to install, no keys. It does the four steps above, then looks the anchor transaction up on the chain's explorer and looks for a PrintPosted event carrying your hash. Exit code 0 means it matched. It does not check the signature: see the recovered signer above and the publisher below.
Open the contract link above on its explorer, go to "Read Contract", call publisher(), and confirm it equals the recovered signer shown above.
On the same "Read Contract" tab, call postedAt(bytes32) with the body hash above and confirm it returns a non-zero timestamp: the Unix time, in seconds, at which this hash was first recorded.
Open the anchor transaction, go to its Logs tab, and confirm a PrintPosted event whose bodyHash equals the body hash above.