Equal-looking numbers in a price table can describe different costs. Reading the technical-data tool’s unit checks led me to explain the denominator before the number. This article introduces no current provider rate or product-price recommendation.
The denominator defines the comparison
Per-thousand and per-million token values are different rates even when their numerals match. The source work includes checks that establish a common basis. Before a ranking or a polished table, the maker should be able to explain which value was read with which denominator; a currency symbol alone cannot do that.
The new module accepts only per_1k and per_1m, normalizing to a per-million basis by multiplying per-thousand values by one thousand. Another unit fails instead of being guessed. This is a narrow rate comparison contract, not a model of every provider’s billing rules.
Read bounded decimal text exactly
Input is bounded unsigned decimal text. Decimal avoids using binary floating-point representation differences as a reason for a comparison outcome. Numeric objects, booleans, exponent notation and non-finite names fail. A narrow envelope makes the interpreted representation reconstructable.
Exact arithmetic does not verify the source rate: a mistranscribed value can still be well formed. Calculation representation and factual checking remain separate. A real feed needs review that original unit, date and conditions were transferred to the intended field.
Use equal-value and equal-numeral counterexamples
Synthetic point-zero-zero-two per thousand equals two per million. The normalizer may return the text two-point-zero-zero-zero, but evidence comparison uses Decimal equality and matches two. A formatting difference does not manufacture a different price.
The same numeral, two, represents different amounts when its units differ. Considering both counterexamples explains why values and units travel together. No actual company or current price appears, and the demonstration is not presented as a market-cost estimate.
Stop when the unit is ambiguous
A label such as tokens without a denominator is rejected. Continuing under a default could erase a real omission in the original material. The interface can expose that as review-needed rather than silently substituting a unit or zero.
The function parses no original prose. It compares caller-prepared values and units. Selecting the right source number and interpreting cache or batch conditions remain separate review tasks. A small conversion cannot certify the adequacy of a complete billing estimate.
Retain representation changes after normalization
Re-expressing the same value in another unit is not a price change, but it is a representation change. The new diff preserves representation fields separately from verification metadata. Establishing a common comparison basis should not erase the history of how a value was expressed.
This is an independent development beyond the source comparison’s ignored metadata. The original tool was not modified and no actual price feed was called. A question found in production records became public synthetic code, without changing the client project’s operating state.
Read the basis before trusting a table
The field package’s twelve tests cover normalization, ambiguous units, representation and metadata changes, and duplicate snapshots. Fresh extraction passed too. Its viewer reads fixed actual local outputs and does not refresh external prices.
Other comparison tables also tend to put units only in headings and omit them from data. I share a way to retain the pair and explain conversion. A different business must model currency, taxes and applicability with the same explicitness; visual completeness cannot supply conditions the code never received.