# How to size an LLM cost plan > Size a metered plan from tokens, not requests. Your tier moves when prompts grow even if traffic holds flat. The sizing arithmetic, worked. URL: https://getculpa.com/how-to-size-an-llm-cost-plan Last reviewed: 2026-08-02 ## Answer Size a metered plan from your token volume rather than your request count, because a credit covers one call plus one per complete 10,000 tokens. Culpa, a local-first LLM cost, margin, and forecast ledger, meters on that basis, so your tier can move when prompts grow even while traffic holds perfectly flat. ## Why this happens Sizing goes wrong in a specific and repeatable way. A team counts requests, picks the tier that covers them, and treats the decision as settled. Then prompt sizes drift upward, which they always do, and the allowance depletes faster every month against traffic that never moved. The tier change arrives looking like growth and is really prompt creep. The fix is to size on the quantity the meter actually reads, and to re-run it whenever prompts change rather than whenever traffic does. ## What this usually looks like - Your plan was chosen from a request count and nobody wrote down the token assumption. - The allowance depletes earlier each month while traffic stays flat. - An upgrade is being discussed and nobody can say which variable moved. - Nobody has sized the heaviest feature separately from the average. ## Common mistakes - Sizing from request count alone. Why it hurts: The meter reads tokens as well as calls, so request count sets a floor and not the answer. Do instead: Compute credits per call at your real average token size, then multiply. - Sizing on an average that hides a heavy feature. Why it hurts: One long-context feature can consume more credits than everything else combined. Do instead: Size each feature separately and sum them. The total will surprise you. - Treating the sizing as a one-time decision. Why it hurts: Prompt sizes drift upward, so a correct sizing quietly stops being correct. Do instead: Re-run it whenever average tokens per call move, not whenever traffic does. ## Self-check - Pull call count and total tokens per feature for a full month. - For each feature, compute credits per call: one, plus one per complete 10,000 tokens. - Multiply by that feature's call count and sum across features. - Compare the total against the tier allowances and note your headroom as a percentage. - Recompute at your current prompt-growth rate to see when the tier changes. ## The same traffic, one tier apart (illustrative) An application making 400,000 calls a month, metered at one credit per call plus one per complete 10,000 combined tokens, against published allowances of 1,000,000 and 2,000,000. The token growth below is modelled. At 18,000 tokens a call: 1 + floor(18,000 / 10,000) = 2 credits 400,000 x 2 = 800,000 credits, which fits the 1,000,000 tier with 20% headroom Prompts grow to 25,000 tokens a call: 1 + floor(25,000 / 10,000) = 3 credits 400,000 x 3 = 1,200,000 credits, which no longer fits and needs the 2,000,000 tier Call volume never moved. The prompt did A 39% rise in prompt size moved this application a whole tier on flat traffic. Anyone sizing from request count would read that as growth and price the upgrade against a number that never changed. ## Cost figures Every figure carries its confidence and its source. No figure on this site is provider-reported. - 800,000 to 1,200,000 credits — modelled monthly credit demand for identical traffic before and after prompt growth [estimated] Source: 400,000 calls at 2 credits and at 3 credits, from the teardown arithmetic. A range because the token sizes and the growth are modelled. - 39% — modelled prompt-size increase that moved this workload a full tier at flat traffic [calculated] Source: 25,000 divided by 18,000 tokens per call, from the teardown arithmetic. ## FAQ Q: How do I work out which tier I need? A: Compute credits per call as one plus one per complete 10,000 combined tokens, multiply by monthly calls for each feature, and sum. Compare that total against the allowances rather than comparing your raw request count. Q: Why did my usage rise without more traffic? A: Almost always prompt growth. The meter reads tokens as well as calls, so a longer system prompt, a larger retrieved context or a more verbose response format all consume more credits at identical request volume. Q: Should I size on the average or the heaviest feature? A: Both. Size each feature separately and sum them, because one long-context feature can consume more than everything else combined, and an average across features hides exactly that. ## Sources - OpenAI API pricing: https://developers.openai.com/api/docs/pricing Run the free Cost Leak Scan: https://app.getculpa.com/scan?source=pseo&slug=how-to-size-an-llm-cost-plan&cluster=howto Machine-readable index of every guide: https://getculpa.com/api/pages Human-readable index of every guide: https://getculpa.com/guides Site overview: https://app.getculpa.com/llms.txt Privacy: Culpa runs on your infrastructure. Your prompts and responses never leave it. Culpa counts calls to run your plan, and it fails open, so if it ever breaks your app keeps running.