Reverse-Engineering Compute Quotas From Floating-Point Usage: How to Choose the Right AI Coding Subscription

Introduction: A Decimal That Should Have Been Rounded

Before some new versions of an AI coding service were released, a user casually checked the web-based usage record and found an unusual entry:

Weekly usage: 0.16327272727272726

It was not 0.16, nor 16.33%, but a floating-point value with 17 significant digits. For a human, it looks meaningless. For a machine, it carries a lot of information. In this article, this kind of service is referred to as “the service,” and the data source is referred to as “third-party observed records.”

The finding shows one important point: what really determines whether a subscription is worthwhile is not the multiplier shown on the marketing page, but the actual structure of the metering system.

1. Why Floating-Point Values Leak Billing Rules

First, let’s explain why this number appears. The reason lies in the difference between two metering philosophies.

• The billing side records exact ratios. Billing systems usually record usage with integers and then convert it through multipliers. These multipliers are often written as simple fractions, such as 3/5, 5/1, or 5/3. The benefit is that when usage is aggregated across models, it can be added exactly and reconciled without error.

• The display side lacks rounding. The system stores usage as IEEE 754 double-precision floating-point values. If the display layer outputs the value directly, the fraction is restored as the decimal approximation of a binary floating-point number, exposing the unrounded tail.

A simple reverse check can be done:

print(0.16327272727272726 * 1650)  # 269.4
print(0.16327272727272726 * 2750)  # 449.0 (if the output is 448.99999999999994, this is floating-point rounding and can be ignored)

The denominator 1650 corresponds to a lightweight model with a multiplier of 1.5. The denominator 2750 corresponds to a heavy-load scenario with a multiplier of 5. Two things can be confirmed:

• The internal accounting of the service is exact.
• The display layer only performs format conversion and does not truncate precision.

2. Recovering a Fraction From a Decimal: Continued Fractions and Rational Approximation

“Restoring a decimal to its simplest fraction” is a classic problem in number theory. The standard tool is continued-fraction expansion. For any real number x, repeatedly taking the integer part and then taking the reciprocal of the fractional part produces a sequence of coefficients:

x = a0 + 1 / (a1 + 1 / (a2 + 1 / (a3 + ...)))

If the expansion is truncated at the k-th layer, the result is the k-th convergent, written as p/q. It is the fraction closest to x among all fractions whose denominator does not exceed q. A floating-point number itself is a rational number whose denominator is a power of 2, so this method can be executed exactly on a computer.

From an algorithmic point of view, it is similar to performing a binary search on the Stern-Brocot tree: start from the boundary fractions 0/1 and 1/0, repeatedly take the mediant fraction, and decide whether to move left or right based on where x falls.

A practical implementation expands the coefficients step by step, checks the error at each step, and chooses the term where the error is smaller than floating-point precision and the denominator is as small as possible:

def recover_fraction(x: float, eps: float = 1e-12, max_terms: int = 30):
    """Use continued fractions to recover the simplest fraction from a float. Returns (numerator, denominator, number of expansion terms)."""
    a, p0, q0, p1, q1 = [], 1, 0, 0, 1
    for _ in range(max_terms):
        a_i = int(x)
        a.append(a_i)
        p, q = a_i * p0 + p1, a_i * q0 + q1
        if q and abs(x - p / q) <= eps * max(1.0, abs(x)):
            return p, q, len(a)
        p0, q0, p1, q1, x = p, q, p1, q1, 1 / (x - a_i)
    return None
# Note: In Python 3.6+, Fraction(x).limit_denominator(n) from the standard library can also perform a similar approximation.
print(recover_fraction(0.16327272727272726))  # (449, 2750, 5)

To verify whether the recovered result is truly the source value, the standard method is a round-trip test: convert the recovered fraction back to a floating-point number and check whether it is bit-for-bit identical to the original value:

print(float(449 / 2750) == 0.16327272727272726)  # True

The successful recovery shows that 449/2750 is indeed the source of this floating-point value.

In a billing context, the two factors of the denominator 2750 both have clear meanings:

• 2750 = 11 × 250: 11 is the number of 5-hour windows that occur in a 55-hour billing cycle, which corresponds to the number of windows in a working week. After aligning the numerator 449 with this cycle, it exactly equals 269.4 × 5/3, which means it is converted into the quota caliber of a mid-tier model using the multiplier 5/3.

• 2750 = 5 × 550: This is the result of converting input usage into quota at 1/5 of the output price.

Conversely, 461.36 × 6/5 = 553.632 ≈ 2750/5, which shows that the high-tier quota is also converted using the same ratio.

A single floating-point value can only provide clues. To make the conclusion reliable, multiple samples need to be aggregated, and the recovered denominators need to be consistent with each other.

This example also confirms a practical conclusion about floating-point numbers: a double-precision floating-point number with a 53-bit mantissa and about 15 to 17 significant decimal digits can, at most, exactly represent fractions whose denominators do not exceed 10^15. As long as the business denominator falls within this range, it can be losslessly recovered from the output value. High precision does not mean strong protection.

3. The Metering Model: A Prerequisite for Understanding Plan Value

Third-party observed data reflects that the metering model of this kind of service consists of four parts. This is also a fairly common design approach for subscription-based AI coding tools in the industry.

1. Unified metering unit. All consumption is converted into the same type of credit. Whether it is called credits, compute units, or tokens is not the key point. What matters is that the system records internally with integers or exact fractions, avoiding errors when aggregating across models.

2. Model multipliers. The stronger the model, the more consumption per unit of time. Reverse-engineering from observed data shows that the mid-tier model is 5/3 of the lightweight model, the mid-tier to heavy model ratio is about 1/1.67 ≈ 3/5, and the heavy model is 5 times the lightweight model. This is consistent with the API pricing logic of mainstream services, where model capability is graded: lightweight models are good at classification, rewriting, and completion, while heavy models handle architecture design and complex debugging.

3. Modality multipliers. Generating a piece of text consumes more compute than understanding a piece of text, so output is billed at 5 times the input. This is a common industry practice. Its direct consequence is that, for the same long context, each additional generated reply consumes significantly more than reading it once.

4. Dual-layer time-window rate limiting. A short-term window, such as every 5 hours, prevents instantaneous spikes. A long cycle, such as a week, controls total usage. The actually available amount is the smaller of the two.

The observed data is as follows:

Tier	Monthly fee (USD)	5-hour quota (10k credits)	Weekly quota (10k credits)	Weekly quota ÷ 5-hour quota
Entry	20	55	500	9.09
Advanced	100	330 (6×)	4166.67 (8.33×)	12.63
Flagship	200	Officially stated 20×	Incomplete in the source data	—

The most important finding in the original analysis is in the weekly quota data: the advanced tier’s long-cycle cap is 25/3 ≈ 8.33 times that of the entry tier, exceeding the nominal 5× multiplier. The short-term window quota reaches 6×. This “extra capacity” is likely intentional. Users with long sessions often organize their work by day, and a 5-hour window is not enough to support a complete deep task. Higher tiers effectively place more capacity into the long cycle.

4. Recovering the Unit Price: How Many Credits Do You Get per Dollar?

Cost-effectiveness should start from “how many credits you get per dollar.” When calculating this, two points matter: the tighter of the two windows determines the actual limit, and it is not enough to look only at the cap; you also need to see how much can actually be consumed in daily use.

For this reason, define three metrics:

• Nominal available amount = min(5-hour quota × 55/5, weekly quota), which is the maximum number of credits that can be consumed in a billing cycle.

• Actual available amount = Σ min(hourly real demand, hourly amortized cap), where the hourly amortized cap takes the smaller of the two window limits.

• Effective unit price = monthly fee ÷ actual available amount.

The “hourly amortized cap” is intuitive: each window can consume at most 1/5 of the quota, so the hourly usage should not exceed 1/5 of the quota; averaged over a week, the hourly usage should not exceed 1/55 of the weekly quota. Whichever cap is hit first is the one that matters.

Substituting the observed data:

Metric	Entry	Advanced	Advanced ÷ Entry
Nominal available amount (10k credits)	500	3333.33	6.67×
Amortized hourly cap (credits)	9090.91	75757.58	8.33×
Nominal available amount per USD	25	33.33	1.33×
Amortized hourly cap per USD	454.55	757.58	1.67×

After dividing the quota by 5 and converting it into “hourly compute,” the entry tier and the advanced tier are 10,000 and 60,000 credits, respectively. Dividing by the monthly fee, the unit cost ratio between them is exactly 5:3, or 1.67×, which matches the model multipliers.

The discount in unit price is equivalent to jumping to the next model tier. Upgrading from entry to advanced is equivalent to reducing the unit price to 3/5. Upgrading from advanced to flagship is approximately 1/1.67 based on the nominal multiplier. This tiered pricing structure makes the critical points precisely calculable.

The following code can further simulate the actual cost under different usage intensities:

def effective_cost(hourly_demand, price=20.0, window_credits=5.5e5,
                    weekly_credits=5.0e6, window_hours=5, bill_hours=55):
    """Estimate the actual cost per unit of quota. hourly_demand is credits per hour."""
    hours = min(
        hourly_demand * bill_hours,
        window_credits * (bill_hours // window_hours),
        weekly_credits,
    )
    bottleneck = (
        "short-window" if hourly_demand * window_hours > window_credits and hours < weekly_credits
        else "weekly" if hours == weekly_credits and hourly_demand * bill_hours >= weekly_credits
        else "not hit"
    )
    return round(hourly_demand * bill_hours / hours, 2), bottleneck, round(hours / hourly_demand, 1)
for d in (10_000, 15_000, 30_000, 60_000):
    print(d, effective_cost(d))  # (demand, (unit-cost premium, bottleneck, available hours))

The output is as follows:

10000 (1.0, 'not hit', 50.0)
15000 (1.22, 'weekly', 33.3)
30000 (1.82, 'short-window', 18.3)
60000 (3.64, 'short-window', 9.2)

Based on this, it is possible to judge which tier of the service is the most cost-effective:

1. Low- and medium-intensity users should choose the entry tier. When demand does not exceed about 9,091 credits per hour, or about 45,000 credits over 5 hours, neither window will hit the cap. Assuming a common request consumes about 2,000 credits, this is equivalent to about 23 requests in 5 hours, or less than 5 requests per hour. For a monthly demand of about 270,000 credits, the entry tier would reset the quota every 1.1 months, averaging about 2.70 USD per month, which is the lowest entry threshold among the three tiers.

2. Heavy users should prefer the advanced tier. When demand is between 9,091 and 15,152 credits per hour, the actual available amount just uses up the 5 million cap. The entry tier’s overflow is wasted, while the advanced tier provides 33% more credits per dollar. If demand continuously exceeds 15,152 credits per hour, the entry tier cannot even fill its weekly cap, and the advanced tier’s unit-cost advantage becomes even larger.

3. The flagship tier cannot be judged by nominal multipliers alone. If the short-term window quota is scaled proportionally to about 11 million, while the long-cycle cap is scaled by the same multiplier of about 1.67, such users can use at most 220,000 credits per hour. They would hit the weekly cap after about 19 hours, leaving nearly half of the quota idle. Conversely, if the measured long-cycle cap is also scaled by about 1.67, or if usage is intermittent and the short-term window is rarely hit, the unit cost can drop to about 3/5 of the entry tier. Therefore, high-intensity “all-round” users will find the flagship tier the most cost-effective, while users with short burst usage may pay more and receive less.

5. Validate Pricing With Your Own Usage Data

The model above is based on limited third-party observed samples. A more reliable approach is to perform a cost accounting exercise on your own real traffic:

from collections import defaultdict
MODEL_RATE = {"lite": 1.0, "mid": 5 / 3, "heavy": 5.0}  # Multipliers relative to the lite model; can be calibrated with observed data.
IN_TO_OUT = 5                                              # Output multiplier relative to input.
def to_credits(model: str, in_tok: int, out_tok: int) -> float:
    """Convert token usage into unified compute units using model multipliers."""
    return MODEL_RATE[model] * (in_tok + IN_TO_OUT * out_tok)
def profile(records, bill_hours: int = 55):
    """records is a list of (timestamp, model, input tokens, output tokens). Produces a weekly cost profile."""
    weekly, peak = defaultdict(float), defaultdict(float)
    for ts, model, i, o in records:
        u = to_credits(model, i, o)
        week, win = ts // 604800, ts // (5 * 3600)
        weekly[week] += u
        peak[(week, win)] += u
    totals = sorted(weekly.values())
    p95 = totals[int(len(totals) * 0.95)] if totals else 0.0
    top5 = sum(sorted(peak.values(), reverse=True)[:5]) / max(1, len(weekly))
    return {"weekly average": sum(totals) / max(1, len(totals)), "weekly P95": p95, "weekly top-5 window average": top5}

After obtaining the profile, follow the order of “estimate intensity, choose the tier, and finally calculate the unit price”:

• Estimate intensity: During 5 days that represent normal working days, record the converted credit consumption per hour and calculate the median and P95.

• Choose the tier: Use the median demand to determine whether the long cycle will hit the cap. The two key thresholds are 9,091 and 15,152 credits per hour. Use the peak demand to determine whether the short-term window will be maxed out. Users whose median demand does not exceed 9,091 and whose peak does not exceed 91,000 credits are fine with the entry tier. Users whose median demand is between 9,000 and 15,000 and whose peak frequently maxes out the short-term window are likely paying beyond their actual usage and should consider downgrading. Users whose median demand continuously exceeds 15,000 credits per hour will hit the entry tier’s weekly cap, so upgrading is worthwhile.

• Calculate the unit price: Compare the effective unit price of each tier under your own profile, and convert the difference into a model multiplier to judge whether the upgrade is worthwhile.

If a team collaborates with multiple accounts, the advanced tier can also be used as a “resource pool” for unified scheduling:

def feasible(demand_mid, demand_peak, accounts=1,
             window_credits=3.3e6, weekly_credits=4166.67e4):
    """Check whether a given number of accounts can carry the team's demand."""
    return (accounts * weekly_credits >= demand_mid * 55
            and accounts * window_credits >= demand_peak * 5)
# (median demand, peak demand), unit: credits per hour
for m, p in ((20_000, 30_000), (20_000, 60_000), (50_000, 80_000), (60_000, 150_000)):
    print((m, p), sum(feasible(m, p, n) and n or 0 for n in range(1, 10)) or "more accounts")

The output is as follows:

(20000, 30000) 1
(20000, 60000) 2
(50000, 80000) 4
(60000, 150000) 8

A team’s real demand is often “medium in total volume but very high at peak,” which means the short-term window is hit first. This is the dividing line between buying one higher tier, such as the flagship tier, and opening several advanced accounts. For example, in the third group, 2 flagship accounts can satisfy the total volume but not the peak demand; at least 4 accounts are needed to remove the bottleneck. In such scenarios, pooled scheduling can smooth out the “waves” of the short-term window and is usually cheaper than simply upgrading.

Usage data collection can rely on general cloud capabilities: use a logging service to centrally store and retrieve call records, use monitoring alerts to set quota threshold notifications, and use cost-analysis tools to account by project. For example, these capabilities can be combined on Baidu AI Cloud to build a monitoring and attribution dashboard for subscription quotas.

6. Checklist and Pitfalls

Finally, let’s organize the conclusions above into a checklist that can be followed directly.

1. Check the raw data first; do not trust nominal multipliers. Pay attention to unrounded values returned by the API, use the continued-fraction method to recover the denominator, and then compare it with the cycle length and modality multipliers. If the numerator and denominator are integers and the decimal tail is very long, there is often an exact fraction hidden behind it.

2. Use integers or fixed-point numbers for internal billing. Amounts and quotas should not use floating-point numbers. For external display, keep two decimal places or use integer percentages. The server side can also add a layer of protection, for example:

import math
def mask_usage(x: float, digits: int = 2) -> float:
    """Round usage before external output to avoid recovering the exact fraction."""
    return round(math.floor(x * 10 ** digits + 0.5) / 10 ** digits, digits)

3. Bill by bottleneck, not by nominal value. First calculate the unit price as the monthly fee divided by the actual available amount, then multiply by the multiple by which demand exceeds the cap.

4. Usage has “leverage.” The heavier the context carried by a request, the more consumption it causes. Optimization methods, in order of priority:

• Clean up sessions regularly and keep only necessary context.
• Build an index for long documents first, then retrieve by paragraph.
• Use prompt templates for repetitive tasks to reduce the number of round trips.
• Break large reasoning tasks into smaller steps and verify them step by step, avoiding repeated rewrites after one-shot generation.
• Assign read-only tasks to lightweight models and complex reasoning to heavy models.
• Deterministic work that can be handled by scripts or regular expressions does not need to be given to the model.

5. Let model multipliers influence coding habits. Because output is priced at 5 times input, letting lightweight models read more and write less, while letting heavy models read less and write precisely, is often more effective than simply compressing prompts. You should also estimate the token limit in advance to avoid the model repeatedly rewriting an entire file.

6. Watch billing versions. When metering rules change, resample and recalculate. The presence of an unrounded tail is itself a signal worth monitoring.

7. Prioritize compliance. Control costs under the premise of automation, and do not use methods such as bypassing rate limits or opening multiple accounts to evade usage restrictions. Follow the terms of service and the security norms of the organization.

7. Conclusion

Back to the original question: how should this kind of subscription be purchased most cost-effectively? The answer is not in the advertised multipliers, but in the real structure of the metering model, namely the four parameters: model multiplier, modality multiplier, short-term window, and long cycle.

A set of unrounded floating-point values leaked the exact fraction 449/2750, and also revealed several practical conclusions:

• Upgrading from the entry tier to the advanced tier directly reduces the unit price to 3/5.
• The portion exceeding the long-cycle cap is directly discarded.
• When the short-term window hits the cap, you pay for capacity that cannot be fully used.
• A higher tier is not necessarily cost-effective for users with short burst usage.

The correct path to saving money is to first measure your own usage profile, then calculate how many effective credits you actually get per dollar.