LLM Subscription vs. Pay-As-You-Go: Calculating Equivalent Costs

    This article presents a neutral, reproducible framework for comparing LLM subscription plans with pay-as-you-go pricing. It explains how to normalize billing periods, convert weekly quotas into monthly equivalents, calculate effective per-tier prices, include cache hits and cache writes in weighted input costs, and calibrate estimates against real request distributions. It also provides a procurement decision framework for stable workloads, peak overflow, mixed-tier usage, and low-frequency experimentation.

    In model service procurement, the “price per million tokens” shown on a pricing page is often not the final cost. Subscription plans, quota packages, cache hits, cache writes, tiered quotas, and request distribution can all change actual spending. When a subscription advertises a high discount multiplier, dividing the monthly fee by the total available quota can overstate the benefit for every model. Conversely, looking only at pay-as-you-go unit prices ignores the amortized value of a subscription under steady load. This article provides a neutral, reproducible accounting framework for comparing the real cost of subscription plans and pay-as-you-go billing.

    1. Establish a Common Basis for Comparison

    To compare different billing methods, at least five dimensions must be aligned:

    1. Time dimension: Quotas may be measured weekly, monthly, or annually, and must be converted to the same period.
    2. Quota dimension: Total plan quota and per-tier available quota may differ and cannot be mixed.
    3. Input/output dimension: Input, cached input, and output prices differ significantly and should be calculated separately.
    4. Cache dimension: Cache hits, misses, and cache writes have different costs and must be weighted by request distribution.
    5. Load dimension: Steady high load and peak-and-trough load lead to different levels of plan utilization.

    Only when these variables are included in the same model are discount figures comparable.

    2. Core Formula: Subscription Equivalent Unit Price

    The essence of a subscription is a prepaid fee in exchange for usable quota over a period. If the plan grants quota weekly, first convert it to a monthly equivalent:

    1. monthly_equivalent_quota = weekly_quota * 52 / 12
    2. plan_multiplier = monthly_equivalent_quota / monthly_fee
    3. tier_equivalent_unit_price = tier_pay_as_you_go_unit_price / plan_multiplier

    For illustration, assume a plan costs 200 currency units per month and grants 1,600 currency units of quota per week. The monthly equivalent quota is approximately:

    1. 1600 * 52 / 12 ≈ 6933
    2. plan_multiplier ≈ 6933 / 200 ≈ 34.67x

    If a given tier has a pay-as-you-go input price of 5, an output price of 30, and a cached input price of 0.5, the equivalent prices inside the subscription are:

    1. equivalent_input_price ≈ 5 / 34.67 ≈ 0.144
    2. equivalent_cached_input_price ≈ 0.5 / 34.67 ≈ 0.014
    3. equivalent_output_price ≈ 30 / 34.67 ≈ 0.865

    These figures show that a subscription multiplier must be applied to specific tiers and specific billing items before it can be compared with pay-as-you-go unit prices. Applying the overall multiplier to all models ignores tier-specific quota limits.

    3. Tiered Quotas: Nominal Discounts Are Not Actual Discounts

    Many plans show an attractive overall multiplier, but some high-value models or high-quality tiers have separate quotas. In this case, calculate a tier-specific multiplier:

    1. tier_multiplier = tier_available_quota / monthly_fee
    2. tier_equivalent_unit_price = tier_pay_as_you_go_unit_price / tier_multiplier

    For example, if a plan costs 10 currency units per month and provides 60 currency units of total quota, the overall multiplier is 6x. If a high-quality tier has only 15 currency units of quota, its actual multiplier is only 1.5x. The equivalent input price for that tier should be adjusted by 1.5x, not 6x. Lightweight tiers that can share the total quota may still reach a 6x multiplier. Ignoring this difference mistakes a discount on some tiers for a discount on all tiers.

    An accounting table should therefore include at least these columns: tier name, monthly plan fee, total available quota, tier available quota, tier multiplier, pay-as-you-go input price, pay-as-you-go output price, cached input price, equivalent input price, and equivalent output price. Splitting by tier prevents an average multiplier from hiding actual costs.

    4. Cache and Write Costs: An Easily Overlooked Variable

    Input cost is usually not a single price. Requests can be divided into cache hits, ordinary input, and cache writes. If the service provides a cache write mechanism and its default policy may change input billing, the cache write ratio should be included:

    1. weighted_input_price =
    2. hit_rate * cached_input_price
    3. + miss_rate * ordinary_input_price
    4. + write_rate * write_price

    Where the write price may include a premium. Suppose ordinary input is 1, cached input is 0.1, the cache write premium is 25%, the hit rate is 50%, the miss rate is 30%, and the write rate is 20%. Then:

    1. weighted_input_price = 0.5 * 0.1 + 0.3 * 1 + 0.2 * 1.25 = 0.6

    If the cache write premium is ignored and costs are estimated only from ordinary input or cache hit prices, the result may be too low or too high. For subscription plans, also confirm whether cache write costs are included, whether cache hits are billed separately, and whether default policies differ. These details directly affect costs in high-concurrency, multi-turn, and long-context scenarios.

    5. Real-World Workload Costs: Calibrate with Request Distribution

    Unit price comparison is only the first step. Actual cost depends on the workload profile. It is advisable to sample one week of log data, aggregate input volume, output volume, cache hits, and cache writes by tier, and then multiply each by the corresponding unit price. Pseudocode:

    1. total_cost = 0
    2. for each request record:
    3. tier = record.model_tier
    4. input_cost = record.input_tokens * tier_equivalent_input_price
    5. output_cost = record.output_tokens * tier_equivalent_output_price
    6. cache_cost = record.cache_write_tokens * tier_write_price
    7. total_cost = total_cost + input_cost + output_cost + cache_cost
    8. output total_cost

    Different scenarios can lead to completely different conclusions. In lightweight interactive scenarios, output share is low and cache hit rates are high, so input cost carries more weight. In long-form generation scenarios, output share is high, so output unit price has more impact. In batch analysis scenarios, caching and batching can reduce unit cost. In experimental scenarios, request volume fluctuates widely, and pay-as-you-go pricing is more flexible. It is advisable to build at least three workload profiles—steady baseline load, peak overflow load, and experimental load—and calculate subscription utilization and pay-as-you-go overflow cost for each.

    6. Procurement Decision Framework

    After calculating equivalent unit prices and calibrating scenarios, use the following framework:

    • Stable high load: If the target tier quota within the plan can be continuously consumed and the cache policy matches, a subscription usually has a cost advantage.
    • Clear peaks and troughs: Use a hybrid model of “baseline subscription + pay-as-you-go peak overflow” to avoid long-term prepayment for peaks.
    • Mixed tiers: Use high-quality tiers for complex tasks and lightweight tiers for classification, summarization, routing, and similar tasks, and calculate discounts separately by tier.
    • Experiments and low frequency: Prefer pay-as-you-go billing to reduce the risk of idle prepaid quota.
    • Budget governance: Set tiered budgets, usage alerts, and a monthly recalculation process. Organizations can use general-purpose logging, monitoring and alerting, and budget management services to continuously observe call volume, cache hit rate, and cost trends.

    Also consider non-price factors such as rate limits, quota reset rules, model availability, price changes, and cache policy changes. Cost accounting is not a one-time spreadsheet; it is an ongoing process that changes with workload and billing rules.

    7. Conclusion

    To evaluate whether an LLM service is “cheaper,” do not look only at nominal unit prices or the overall discount. The right approach is to unify time and billing bases, calculate tier-specific multipliers, include cache hits and writes in weighted unit prices, and calibrate total cost against real request distributions. For technical teams, keep a reproducible accounting script and log sampling mechanism, and update the equivalent unit-price table weekly or monthly. This supports auditable, explainable, and continuously optimizable choices between subscription plans and pay-as-you-go billing.