Guides / size an llm cost plan
How to size an LLM cost plan
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.
Free, no card, no account
Run the free Cost Leak Scan
It shows your most expensive conversation before you install anything.
Mistakes that cost the most
| Mistake | Why it hurts | Do instead |
|---|---|---|
| Sizing from request count alone. | The meter reads tokens as well as calls, so request count sets a floor and not the answer. | Compute credits per call at your real average token size, then multiply. |
| Sizing on an average that hides a heavy feature. | One long-context feature can consume more credits than everything else combined. | Size each feature separately and sum them. The total will surprise you. |
| Treating the sizing as a one-time decision. | Prompt sizes drift upward, so a correct sizing quietly stops being correct. | Re-run it whenever average tokens per call move, not whenever traffic does. |
Run this check tonight
- 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 example
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.
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.
Every number, with its confidence and source
| Figure | What it means | Confidence | Source |
|---|---|---|---|
| 800,000 to 1,200,000 credits | modelled monthly credit demand for identical traffic before and after prompt growth | estimated | 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 | 25,000 divided by 18,000 tokens per call, from the teardown arithmetic. |
What a generic answer can’t know
A plan table can't size itself against your workload, because the answer lives in your own token profile per feature and in how fast your prompts are drifting. Both are facts about your code. Culpa measures them on your infrastructure, keeps your prompts and responses there, and counts the calls to run your plan.
Questions founders ask next
How do I work out which tier I need?
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.
Why did my usage rise without more traffic?
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.
Should I size on the average or the heaviest feature?
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.
On your infrastructure
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.
How Culpa works
Find the culprit. Not just the total.
Your dashboard shows what you spent. It stops short of who spent it. Culpa shows the conversation, the user and the feature behind it.
Your prompts stay local.
Culpa runs on your own infrastructure. What you send to a model reaches us at no point.
Every dollar has a name.
Follow any charge to the conversation, the user, the feature and the customer behind it.
See the bill before it lands.
Cost your next feature before you ship it. You get the likely bill and the worst case, at best, median, p90 and p99.
Three steps to your first answer.
Change one base URL.
Or drop in the Python or TypeScript library.
Find your most expensive conversation.
In the first session, not the first week.
Cost your next feature before you ship it.
Why the bill went up
Example dashboardCalls traced
418,209
across 3 projects
Spend this week
$378.41
+ $182 vs last week
Failed calls
312
74% retried, and you paid for all of them
+ $182 this week traced to one culprit
Spend over 14 days
Most expensive users
Next week forecast
Graded against reality. Accuracy shown as results land.
Free, no card, no account
Run the free Cost Leak Scan
It shows your most expensive conversation before you install anything.
Keep reading
Sources: OpenAI API pricing. Last reviewed 2026-08-02. Plain text version.