Subscription LLM Billing Explained: Credits, Quotas, and Cost Control Practices

1. Starting from a Float with a Suspicious Decimal Tail

A usage dashboard for a subscription-based LLM product once exposed an unusual detail. Among the quota ratios returned to the frontend was a decimal with 17 significant digits, such as 0.16327272727272726. Display values should normally be formatted to two decimal places, so seeing a value this long usually means the server passed an unrounded intermediate calculation result straight through to the client.

A decimal that looks endless and non-repeating is often just the result of dividing two integers. In other words, with samples precise enough, you may be able to reverse-engineer the internal integer quota relationships. This is not an exploit. It is a classic case of side-channel inference: any derived field a system exposes implicitly leaks internal parameters.

Reproducing that reverse-engineering process takes only a few lines of code:

from fractions import Fraction
def recover(x: float, max_den: int = 100000, tol: float = 1e-12) -> Fraction:
    """Recover the simplest fraction from a float likely produced by rational arithmetic"""
    f = Fraction(x).limit_denominator(max_den)
    if abs(x - float(f)) > tol:      # Sanity check: the recovered value must reproduce the sample at high precision
        raise ValueError("Insufficient sample or the value is not a simple rational")
    return f
samples = [0.16327272727272726]
print(recover(samples[0]))   # -> Fraction(449, 2750)

Mathematically, this step relies on the continued fraction expansion. A float can be written as a0 + 1/(a1 + 1/(a2 + ...)). The convergents obtained by truncating it layer by layer are the rational approximations with the smallest error. An equivalent approach is a binary search on the Stern-Brocot tree:

1. Start from the interval (0/1, 1/1).
2. Repeatedly take the mediant, the fraction between two bounds formed by adding their numerators and denominators separately, and compare it with the target value.
3. Move left or right to shrink the interval, repeating until you find the fraction whose denominator stays within a given bound and whose difference from the original value is negligible.

Python’s standard-library Fraction.limit_denominator is an efficient implementation of this algorithm.

A single sample can have multiple solutions, so the standard engineering approach is to cross-validate across multiple samples. Collect several sets of ratios from different accounts and time windows, recover a rational for each, and then take the least common multiple or greatest common divisor of their denominators. The common integer base will soon surface. That is how a handful of unrounded numbers can leak a pricing strategy.

2. Compute Credits: Why Billing Skips Raw Tokens

Most subscription-based LLM products do not bill in raw tokens. Instead, they define an abstract metering unit, commonly called credits. The main reason is that raw token counts are hard for ordinary users to predict and cannot be compared across models. An abstract unit, by contrast, can capture several dimensions at once:

Billing dimension	Common approach	Design intent
Model tier	Light, standard, and flagship models are converted at different multipliers	Make the cost of using a stronger model measurable
Input vs. output	Output carries a significantly higher multiplier than input	Align with the underlying inference compute cost
Context length	Very long contexts are scaled up in tiers	Curb cost spikes from a single request
Cache hits	Discounted or nearly free	Encourage reuse and reduce repeated computation
Reasoning mode	Long chains of thought are billed as output	Keep reasoning overhead from spiraling out of control

As a result, how much users can actually consume should be expressed as weighted credits, not token counts:

Credits consumed per request = output_tokens × output multiplier × model multiplier
                             + input_tokens × input multiplier × model multiplier
                             - cache hit discount

As a rule of thumb, flagship models consume roughly 1.5–2× the credits of standard models, while light models consume about 1/5 of what flagship models do. These ratios usually stay aligned with the usage-based pricing of the underlying hosted services, so subscription quotas and on-demand bills can be reconciled in accounting terms. Understanding this conversion layer is a prerequisite for judging whether a plan is good value.

3. Two-Layer Quotas: Session Windows Plus Periodic Caps

Mainstream subscription plans rarely express a quota as a single number. Instead, they stack at least two layers of constraints:

1. Session-window quota (for example, a rolling 5-hour window) prevents short-term burst usage and keeps the shared capacity pool fair for everyone.
2. Periodic quota (for example, weekly or monthly) caps long-term consumption and serves as the anchor for cost accounting.

The key point is that the tighter of the two constraints applies. You can model effective capacity as follows:

def effective_capacity(hours_per_week, window_credits, window_hours,
                        weekly_credits):
    """Estimate the maximum credits actually usable in a week"""
    windows = hours_per_week / window_hours          # theoretical number of windows
    by_window = windows * window_credits             # limited by the session window
    return min(by_window, weekly_credits)            # take the tighter constraint
# Heavy user: 70 hours/week, 5-hour window with 3.3M credits, weekly cap of 41,666,700
print(effective_capacity(70, 3_300_000, 5, 41_666_700))
# ~4.62e7 -> the window limit is not the binding one; the weekly quota is the bottleneck

This also explains why the officially advertised “N× usage” often differs from real-world results. The advertised figure usually aligns with only one of the two constraints, or is calculated from an idealized period of full load. To check a plan yourself, the right approach is to collect multiple sets of real usage data and run a linear regression. Keep the input size fixed, vary the number of requests, and observe the slope and intercept of credit consumption. That lets you separate the model multiplier from any fixed overhead. You can then apply the continued-fraction method from the previous section to recover the integer quotas.

“Free” extra usage is usually not a business decision. More often, the ratio between the two quota layers was never strictly aligned with the advertised multiplier.

4. Engineering Lessons: Keep Derived Fields from Leaking Information

From the perspective of building a billing system, this case yields at least four actionable rules:

• Separate display precision from internal calculation precision. Accumulate internally with high-precision floats or rational numbers, and pass every outgoing field through a single formatting and rounding layer. Never return intermediate variables directly.
• Use an integer minimum billing unit whenever possible. Recording consumption in integer credits eliminates both floating-point accumulation error (for example, summing 0.1 many times does not produce exactly 1.0) and the possibility of rational reconstruction.
• Define one rounding policy and apply it consistently across the entire pipeline. Whether you round after aggregation (“sum first, then round”) or round each request and then sum produces different totals. Use the same rule in billing, limits, and audit logs, and retain raw values for reconciliation.
• Make billing operations idempotent. Interrupted streaming requests, client retries, and compensation for network timeouts can all cause duplicate charges. Use the request ID as a deduplication key, and handle timeout cases through a separate reconciliation process rather than a direct rollback.

In addition, usage aggregation needs a fixed time reference (UTC or a clearly defined local time zone) and must specify whether windows are sliding or fixed. Otherwise, users across time zones may see their quota “vanish out of nowhere.”

5. Choosing the Most Cost-Effective Plan

Picking a plan becomes a comparison of cost per unit of effective credit:

Effective unit price = monthly fee / (weighted usable credits × actual utilization)

Here, weighted usable credits means the total credits after converting the periodic quota. Actual utilization depends on your own work rhythm. Three rules of thumb follow:

1. Low-frequency, sporadic use. An entry-level plan plus pay-as-you-go billing is usually cheaper. The quota on an expensive plan tends to go to waste because the session window sits idle most of the time.
2. Long, continuous coding sessions. The bottleneck is the session window, not the weekly quota, so increasing window credits is more valuable than increasing the weekly cap.
3. Periodic peaks (such as concentrated refactoring or release weeks). Prefer a higher tier with a generous window quota to flatten the peaks. This is more economical than a long-term subscription with an additional on-demand package on top.

Here is an evaluation script skeleton you can apply directly:

PLANS = {  # name: (monthly fee, 5-hour credits, weekly credits)  -- replace with values from your own measurements
    "entry":  (20, 550_000,  5_000_000),
    "mid":    (100, 3_300_000, 41_666_700),
    "high":   (200, None, None),
}
def unit_cost(price, capacity, utilization=0.7):
    return price / (capacity * utilization)

To collect the data, log your actual credit consumption and concurrent request counts over a continuous period. Estimate the distribution of weekly consumption (P50 and P95), then plug the figures into the table above for comparison. Base the decision on your own load curve, not on the officially advertised multipliers.

6. Usage Governance for Teams and Enterprises

Individuals care about unit price; organizations care about predictability and attribution. At the engineering level, it helps to build four layers of capability:

• Collection and attribution. Tag the credits consumed by each call with project, team member, CI pipeline, and branch, write them to a logging service, and consolidate them into a unified data warehouse.
• Budgets and hard limits. Set periodic budgets for each team and project, trigger alerts as they approach the threshold, and automatically downgrade to a light model or reject new requests once the budget is exceeded. This keeps a single runaway workload from draining the shared quota.
• Model routing and fallback. Route simple tasks such as formatting, comments, and unit test completion to light models, and upgrade to flagship models only for complex reasoning. On failed retries, downgrade automatically instead of consuming more of the expensive credits.
• Prompt and context optimization. Trim system prompts, cut irrelevant context, enable caching for stable prefixes, merge bulk tasks into batch endpoints, and schedule them during idle quota windows.

Platforms such as Baidu AI Cloud typically provide usage dashboards, quota management, and monitoring alerts for their model services as well. Together with object storage for archiving call logs, these capabilities let you build your own cost attribution system. For exact metering rules, quota policies, and unit prices, always rely on the official documentation and bills of the service you choose. Do not carry over conclusions from third-party measurements.

7. Conclusion

What this 17-digit decimal reveals is less a leaked pricing strategy than three general engineering principles:

• The design of the metering unit determines how well users can understand their costs.
• Multi-layer quota constraints systematically deviate from advertised multipliers, so plan selection must be based on measured load.
• Any derived value exposed externally is an information-leakage surface, so billing systems should enforce precision convergence at the output layer.

For individual developers, the takeaway is to measure first, choose second, and match the quota to your actual rhythm. For teams, it is to turn attribution, budgets, routing, and prompt optimization into platform capabilities. When metering rules are transparent and costs can be attributed, choosing between a subscription and pay-as-you-go billing stops being guesswork and becomes a calculation you can actually run.