How to Choose AI Subscription Tiers: Floating-Point Leakage, Quota Inference, and Compliance

1. Bottom line: what this article can and cannot do

Marketing multipliers are often just promotional framing. What really determines whether an AI subscription offers good value is usually not a phrase such as “the model is stronger” or “the multiplier is higher,” but two deeper dimensions:

• Short-window quota: how much you can use during a short burst.
• Long-period quota: how much you can reliably use over a longer period, such as a week or a month.

If a service converts an internal integer counter into a displayed usage value without rounding or formatting, the extra decimal places may expose an integer ratio that was meant to remain hidden. By using publicly visible displayed values, you can infer quota ratios between tiers and convert them into a comparable cost basis.

This article is about inference, not about reproducing official bills or obtaining unauthorized data. Any conclusion should be based on multiple samples, cross-validated carefully, and must strictly comply with the service terms. Avoid abnormal high-frequency sampling, and do not treat inferred values as official billing data.

2. Why unrounded floating-point values can leak quota ratios

Well-designed billing systems usually account for usage in integer “count units,” such as tokens, API calls, or credit units. When displaying usage, the system may convert those units into a percentage or ratio.

A typical display formula may look like this:

used ratio = used units / total units

If the developer forgets to round, format, or convert the result into a finite decimal, the frontend may receive an unusually long floating-point value, such as:

used ratio = 0.16327272727272726

Such a value becomes suspicious when it meets the following conditions:

1. The decimal part is unusually long, close to the effective precision limit of double-precision floating point.
2. The tail shows a regular repeating pattern, such as “2727…”.
3. Multiple samples have stable integer-multiple or simple-fraction relationships.

The key premise is that the displayed value comes from an integer ratio and has precision far beyond what is needed for normal display. When that premise holds, mature mathematical tools can recover the floating-point value into candidate simplest fractions.

3. How to recover the simplest fraction from a floating-point value

Method 1: Continued-fraction expansion

Given a floating-point number x, the goal is to find a rational number p/q with as small a denominator as possible, such that p/q is within the floating-point error range of x.

Python’s standard library provides this ability through Fraction.

from fractions import Fraction
def recover_fraction(x: float, max_denominator: int = 10**6,
                     tol: float = 1e-12):
    """Recover a candidate simplest fraction with denominator <= max_denominator."""
    frac = Fraction(x).limit_denominator(max_denominator)
    if frac.denominator <= max_denominator and abs(float(frac) - x) <= tol:
        return frac
    return None
leaked = 0.16327272727272726
r = recover_fraction(leaked)
print(r)  # Candidate simplest fraction, for example 449/2750

Important notes:

• Do not validate with float(frac) == leaked. Floating-point numbers are binary approximations, so two mathematically equal ratios may still have tiny rounding differences.
• Use tolerance-based validation instead, for example abs(float(frac) - x) <= 1e-12.
• max_denominator should be slightly higher than the estimated magnitude of the total units. If it is too small, the result will be a coarse approximation. If it is too large, floating-point noise may be fitted into a huge false denominator. You can scan across 10^2, 10^3, … 10^6 and observe when the result becomes stable.
• Python’s Fraction automatically reduces fractions. Therefore, the recovered denominator may not be the original total unit. For example, the original value may have come from 898/2750, but after automatic reduction it will appear as 449/1375.

Method 2: Stern-Brocot tree search

The Stern-Brocot tree contains every positive rational number, and every simplest fraction appears exactly once. Given left and right bounds a/b and c/d, the mediant fraction is (a+c)/(b+d). By repeatedly comparing the mediant with the target floating-point value and descending the tree, you can approximate the target value.

from fractions import Fraction
def stern_brocot_recover(target: float, max_denominator: int = 10**6,
                         tol: float = 1e-12, max_iter: int = 10000):
    ln, ld = 0, 1
    rn, rd = 1, 0
    for _ in range(max_iter):
        mn, md = ln + rn, ld + rd
        if md > max_denominator:
            break
        if abs(mn / md - target) <= tol:
            return mn, md
        if mn / md < target:
            ln, ld = mn, md
        else:
            rn, rd = mn, md
    cands = [c for c in ((ln, ld), (rn, rd)) if 0 < c[1] <= max_denominator]
    if not cands:
        return None
    best = min(cands, key=lambda c: abs(c[0] / c[1] - target))
    return best if abs(best[0] / best[1] - target) <= tol else None
print(stern_brocot_recover(0.16327272727272726))

This method requires three safeguards:

1. max_denominator: limits the maximum denominator to avoid unbounded search.
2. max_iter: limits the number of iterations to avoid infinite loops.
3. tol: the error tolerance must be larger than the rounding error magnitude of double-precision floating point. Otherwise, it may only fit noise.

For engineering use, Method 1 is usually preferred because it is shorter, relies only on the standard library, and produces results that are easier to validate.

4. How to avoid misjudgment from a single sample

A single floating-point sample may be coincidental. Therefore, cross-validation is necessary.

The requirement is not that “samples from the same source must recover the same denominator,” because Fraction automatically reduces fractions. A more reasonable requirement is: the recovered rational numbers should maintain simple proportional relationships.

For example, two samples from the same tier:

from fractions import Fraction
def recover_fraction(x: float, max_denominator: int = 10**6,
                     tol: float = 1e-12):
    frac = Fraction(x).limit_denominator(max_denominator)
    if frac.denominator <= max_denominator and abs(float(frac) - x) <= tol:
        return frac
    return None
def cross_validate(values, max_denominator: int = 10**6,
                   tol: float = 1e-12):
    results = []
    for v in values:
        r = recover_fraction(v, max_denominator, tol)
        if r is not None:
            results.append(r)
    if len(results) < 2:
        return None
    r1, r2 = results[0], results[1]
    ratio = r2 / r1  # Fraction automatically reduces
    # Simple integer or simple fraction: numerator not overly complex, denominator not too large
    if 0 < ratio.numerator <= 100 and ratio.denominator <= 10:
        return ratio
    return None
samples = [0.16327272727272726, 0.32654545454545454]
results = [recover_fraction(v) for v in samples]
print(results)              # [Fraction(449, 2750), Fraction(449, 1375)]
print(results[1] / results[0])  # 2
print(cross_validate(samples))  # 2

For the second sample 0.32654545454545454, the recovered value should be displayed as:

449/1375

rather than 898/2750, because Fraction automatically reduces fractions. Although the displayed fraction is different, the ratio between the two recovered fractions is still a simple 2.

Recommended three-step validation:

1. Ratio validation: the recovered fractions should be integer multiples or simple-fraction multiples of each other.
2. Public multiplier alignment: the ratios should be consistent, as much as possible, with publicly available model multipliers or tier multipliers.
3. Multi-sample validation: samples collected at different times, with different models, or after different operations should remain stable and repeatable.

5. How to estimate quota when only the used ratio is visible

Often, the leaked value is only a ratio, and the denominator is unknown. In that case, you can estimate the total units using the difference method and the least common denominator method.

Difference method

If there is no obvious consumption during a period, the difference between two sampled usage ratios multiplied by the total units T should approximately equal the integer number of units consumed during that period:

consumed units ≈ (r2 - r1) × T

If the consumption ratios across multiple intervals are close to simple integer ratios, those integer ratios can also help infer T.

Least common denominator method

Suppose the simplest fractions recovered from multiple samples are:

r1 = p1 / q1
r2 = p2 / q2
...
rn = pn / qn

If they all come from the same total units T, then the following should hold:

T × r1, T × r2, ..., T × rn are all integers

Ignoring floating-point noise, the minimum candidate total units can be estimated as:

T_min = lcm(q1, q2, ..., qn)

where lcm means least common multiple.

For example:

r1 = 449 / 2750
r2 = 449 / 1375

Although r2 has already been reduced, the least common multiple of the two denominators is:

lcm(2750, 1375) = 2750

Therefore, the original total unit can be inferred as a candidate of 2750. If the original unreduced form was 898/2750, automatic reduction still preserves a consistent proportional relationship.

Important: fraction reduction loses information about the original total units. Therefore, you should not simply treat the denominator of one recovered fraction as the total units. Instead, estimate it by combining multiple samples, proportional relationships, and denominator upper bounds.

Short-window quota estimation

For hourly sliding windows, you can sample as follows:

1. Shortly after the window resets, record a displayed value close to zero.
2. When usage approaches the bottleneck, record another displayed value.
3. The difference between the numerators of the two values approximates the number of credits or units consumed during that period.
4. If the model multipliers are known, you can further infer the total units of the window.

6. How to translate usage across providers into comparable credits

Different providers display usage in different ways. Some count requests, some count tokens, and some expose model multipliers. To compare subscription value, you need to convert everything into a common unit such as “credits” or “quota units.”

A general quota model usually includes three elements:

1. Short-period quota: for example, the usage cap of a 5-hour sliding window.
2. Long-period quota: for example, a weekly or monthly cap.
3. Model multiplier: consumption multipliers for different models, input tokens, and output tokens.

The lightest model is usually treated as the baseline 1x, and heavier models are charged at fixed multipliers. Under the same model, output tokens are usually more expensive than input tokens. Multipliers can be inferred from public pricing pages, model cards, or official documentation, and then used to convert actual token counts into credit consumption.

7. How to calculate the real value of each tier

Value can ultimately be expressed as “cost per million credits.” However, be careful with the cost basis: do not treat “single-window cost” or “weekly cost” as monthly subscription value.

Cost basis

Define:

• price: monthly price, in USD.
• cap_window: credits consumable in a single 5-hour window.
• cap_period: credits consumable in one week.
• W: number of 5-hour windows in one month.
• M: number of weeks in one month, usually about 4.33.

Then:

single-window cost = price / (cap_window / 1,000,000)
weekly cost        = price / (cap_period / 1,000,000)

These are only local cost views. To compare monthly subscription value, calculate monthly normalized capacity:

monthly window capacity = cap_window × W
monthly period capacity = cap_period × M
effective monthly capacity = min(monthly window capacity, monthly period capacity)
monthly normalized cost = price / (effective monthly capacity / 1,000,000)

For a simplified estimate:

W ≈ 144      # 30 days × 24 hours / 5 hours
M ≈ 4.33     # average weeks per month

Example

The following data is illustrative only and is used to demonstrate the formula:

Tier	Monthly price (USD)	Credits per 5h window	Credits per week	Single-window cost	Weekly cost	Monthly normalized cost
Basic tier	20	550,000	5,000,000	$36.36	$4.00	$0.92
Advanced tier	100	3,300,000	41,000,000	$30.30	$2.44	$0.56

Calculation process:

tiers = {
    "Basic tier": {"price": 20,  "cap_window": 550_000,  "cap_period": 5_000_000},
    "Advanced tier": {"price": 100, "cap_window": 3_300_000, "cap_period": 41_000_000},
}
W = 144
M = 4.33
for name, t in tiers.items():
    window_cost = t["price"] / (t["cap_window"] / 1e6)
    period_cost = t["price"] / (t["cap_period"] / 1e6)
    monthly_window = t["cap_window"] * W
    monthly_period = t["cap_period"] * M
    effective_month = min(monthly_window, monthly_period)
    monthly_cost = t["price"] / (effective_month / 1e6)
    print(
        name,
        f"Single window: ${window_cost:.2f}",
        f"Weekly: ${period_cost:.2f}",
        f"Monthly normalized: ${monthly_cost:.2f}"
    )

Conclusion: a higher tier only provides more quota in a mathematical sense when both its short-window multiplier and long-period multiplier are significantly higher than its price multiplier. If only the short-window multiplier is better, the tier is better suited for bursty high-frequency usage. If only the long-period multiplier is better, it is better suited for stable long-term workloads.

8. How to choose a subscription tier: six-step decision process

1. Sample: record displayed usage values at different times and with different models.
2. Recover: use continued fractions to recover candidate simplest fractions.
3. Validate: use multiple samples to check whether recovered fractions maintain simple ratios.
4. Align: convert ratios into a unified credit basis using public multipliers.
5. Calculate: compute single-window cost, weekly cost, and monthly normalized cost separately.
6. Decide: choose the tier with the lowest unit cost that can also meet your peak usage needs.

Sampling template

Sample time	Tier	Model	Displayed value	Recovered fraction (auto-reduced)	Ratio to first sample	Estimated total units T	Reconstruction error	Validation result
03-02 10:05	Basic tier	Lightweight	0.16327272727272726	449/2750	-	2750	≤1e-12	Pass
03-02 14:40	Basic tier	Lightweight	0.32654545454545454	449/1375	2	2750	≤1e-12	Pass

If the second sample were manually restored to an unreduced form, it might look like 898/2750. However, Python’s Fraction automatically reduces it to 449/1375. This does not affect the judgment, because the ratio between the two recovered fractions is still a simple 2.

Common mistakes

Common mistake	Correct practice
Comparing floats with ==	Use tolerance, for example abs(float(frac) - x) <= 1e-12
Drawing conclusions from one sample	Use multiple samples for cross-validation
Setting denominator limits arbitrarily	Scan across denominator limits and observe when the result becomes stable
Requiring reduced denominators to be identical	Check for simple ratios between recovered fractions instead
Ignoring output multipliers	Convert input and output credits using public multipliers
Looking only at monthly quota	Calculate short-window cost, long-period cost, and monthly normalized cost separately
Treating single-window cost as subscription value	Normalize by effective monthly capacity

9. Developer practices for reducing cost

If you want to engineering this approach, you can build your own quota dashboard:

1. Usage instrumentation: track tokens, API calls, and model types separately on the server and client sides.
2. Threshold alerts:
   • Trigger a warning when short-window usage reaches 70% or more.
   • Trigger a critical alert when short-window usage reaches 90% or more.
   • Send a notice when weekly quota remaining falls below 20%.
   • Trigger a critical alert when weekly quota remaining falls below 5%.
3. Model-tier routing: send simple tasks to low-multiplier models and reserve high-multiplier models for complex tasks.
4. Caching and deduplication: cache results for repeated requests and summarize or compress long contexts.
5. Batching and asynchronous execution: delay flexible tasks to off-peak periods to avoid short-window bottlenecks.
6. Read-only verification: check official bills or documentation in a read-only way first, and do not use inferred values for automated quota-limit decisions.
7. Dashboard visualization: display your own samples, recovered fractions, ratio relationships, and cost curves to make review easier.

10. Usage boundaries and compliance notes

• All conclusions are inferences based on publicly displayed values. They do not represent official data or official billing.
• Sampling frequency should be similar to normal human usage. For example, record one value after each manual operation. Do not construct abnormally high-frequency requests.
• Do not access unauthorized internal endpoints, and do not bypass quota limits.
• Do not use the inferred values for commercial arbitrage, account sharing, or quota circumvention.
• Keep only anonymized usage statistics in your dashboard. Do not store sensitive information such as account credentials or API keys.

11. Summary

Floating-point leakage becomes a clue because excessive precision exposes an integer ratio that should have remained hidden. Continued fractions and the Stern-Brocot tree provide recovery tools with denominator limits, tolerance validation, and failure returns. Cross-validation based on simple ratios across multiple samples reduces the risk of a single false judgment. Credit-based quota models and monthly normalized cost then turn inferred results into comparable subscription value.

When choosing a tier, do not look only at marketing multipliers. Combine them with your own usage pattern. Bursty heavy users should prioritize short-window capacity, while stable long-term users should prioritize weekly quota and monthly normalized cost. Only when sampling, validation, accounting, and alerting are fixed into a compliant process can “calculating clearly” truly turn into “saving consistently.”