Evaluating LLM Subscription Plans: Cost Analysis and Quota Reverse-Engineering

Choosing the “cheapest” LLM subscription is not a simple price comparison. The lowest list price may not have the lowest cost per unit of useful work, and a plan that costs twice as much may not deliver twice the volume. A reliable decision requires a common unit of measure, a split of each plan into peak capacity versus total quota, and an effective-cost calculation that includes details such as prompt caching. The method below is reusable.

1. Unify units: converting compute credits and tokens

Subscription LLM services often track usage with “compute credits” or similar units. Models, input vs. output, and cache reads/writes usually have different multipliers. The first step is not price—it is a conversion table that maps one request to standard credits.

Illustrative formula:

request_credits = input_tokens × input_rate × model_rate
                + output_tokens × output_rate × model_rate
                + cache_write_tokens × cache_write_rate
                + cache_read_tokens × cache_read_rate

Model rate is consumption relative to a baseline model; output rate is the billing weight of generated tokens versus input tokens. Only after converting to the same standard credits can you compare effective unit prices:

effective_unit_price = monthly_fee / monthly_standard_credits

Do not add tokens from different models as if they were equal, and do not treat marketing “Nx usage” as “Nx tokens.” Convert using your actual model mix and input/output ratio.

2. Reverse-engineer the quota denominator from high-precision displays

Some services show usage as high-precision decimals. If a value is the floating-point form of a rational p/q, continued fractions or a Stern–Brocot search can recover a small denominator q and thus the original quota.

Typical steps:

1. Collect several official usage display values.
2. Treat each decimal as a rational candidate and search for small-denominator approximations.
3. Cross-check with integer constraints and multiple samples.
4. Separate short-window quotas from long-period caps.
5. Compare price multipliers with quota multipliers.

Pseudocode:

function reverse_quota(x, maxDen):
    for q in 1..maxDen:
        p = round(x * q)
        if abs(x - p / q) < epsilon:
            yield p / q

This helps spot cases where price doubles but volume does not, or where advertised multipliers understate actual quota. Use only data shown in the official UI; do not probe without authorization. Account for rounding, truncation, unit switches, and display precision. Conclusions are more reliable when multiple samples agree.

3. Split plans into peak capacity and total cap

Subscriptions usually constrain both a short window and a long-period cap. The short window sets burst capacity; the long cap sets total work. Compute separately:

short_window_ratio = candidate_short_quota / baseline_short_quota
long_period_ratio  = candidate_long_cap / baseline_long_cap
price_ratio        = candidate_price / baseline_price

If price doubles but the long-period cap does not, the higher tier mainly buys peak capacity, not more total volume. Steady high daily usage with a flat peak often favors a mid tier; concurrent spikes, long-context batches, or short concentrated bursts can justify the higher peak. State the result as “better under this usage profile,” not as absolutely cheapest.

4. Cache billing can change the cost structure

Prompt caching is a major cost lever. A typical structure has cache writes, cache reads, and normal input:

C = N_write × P_write + N_read × P_read + N_normal × P_normal

When cache reads are free or cheap, highly repetitive long-context workloads drop in cost. Check hit conditions, TTL, write cost, and whether the subscription bills cache reads separately. If reads are unbilled, structure stable prefixes to raise hit rate—but do not assume unpublished rules; follow official terms.

5. A practical selection workflow

1. Build a usage profile: daily tokens, peak concurrency, context length, model mix, cache hit rate.
2. Convert historical requests to standard credits.
3. For each candidate: short-window fit, long-period fit, effective unit price, overage cost.
4. Sensitivity: ±30% volume and changes in cache hit rate.
5. Decide: the tier that meets peak and total constraints at the lowest effective unit price; otherwise consider a smaller model, request batching, or combined subscriptions.

Common mistakes: looking only at list price, treating advertised multipliers as linear, ignoring output and model rates, ignoring cache hits, and extrapolating from a single day. The cheapest plan is not the lowest price—it is the one with the lowest cost per unit of useful work under your real profile, without hitting the peak bottleneck.