Guides / llm burn forecast

What is an LLM burn forecast?

An LLM burn forecast projects your model spend forward from your own measured usage rather than from a rate card. A credible one carries a range and states its assumptions. Culpa, a local-first LLM cost, margin, and forecast ledger, forecasts deterministically from your ledger and stores every projection so its accuracy can be scored later.

Why this happens

Most LLM forecasts fail for the same three reasons. They extrapolate a total instead of the drivers underneath it, so a routing change invalidates them silently. They use the list rate instead of the effective rate, so they start about a quarter low. And they produce a single number instead of a range, which invites a false sense of precision that the underlying variance can't support. A forecast nobody scores afterwards never gets better either.

What this usually looks like

Your forecast is consistently under, and the miss is roughly the same percentage every month.
A launch or a routing change breaks the projection completely, because it was fitted to a total rather than to drivers.
Nobody records what last month's forecast said, so nobody can tell whether the method is improving.
The forecast is a single figure, so it can't express that a launch week has far wider variance than a quiet one.

Free, no card, no account

Run the free Cost Leak Scan

It shows your most expensive conversation before you install anything.

Run the free Cost Leak Scan Start 14-day trial

Mistakes that cost the most

Mistake	Why it hurts	Do instead
Extrapolating last month's bill by a growth percentage.	It bakes in the current model mix and cache behaviour as constants, and both change without warning.	Forecast the drivers separately, calls per user, tokens per call, and the mix, then price them at your effective rate.
Forecasting at the list rate.	Retries and discarded output are real spend the rate card never mentions, so the projection starts low and stays low.	Use your measured effective rate, which already includes whatever waste your system produces.
Publishing a single number.	It's read as a commitment, and the first miss destroys trust in every forecast that follows.	Publish a range with its assumptions written down, and widen it deliberately around launches.

Run this check tonight

Write down what you think next month costs before you compute it. The gap against the computed figure is worth knowing.
Check whether your forecast uses the list rate or your own effective rate. If it's the list rate, expect to run low.
Confirm the forecast decomposes into drivers you could change, rather than a single extrapolated total.
Find last month's forecast and compare it to the actual. If you can't find it, that's the first thing to fix.
Widen the range for any month containing a launch, and say by how much and why.

Forecasting a launch month from drivers, not from last month

Illustrative example

A product at 2,000 active users adding a launch expected to triple traffic for one week. Costs priced at GPT-5.4 real rates, $0.0025 per 1k input and $0.015 per 1k output. Usage per user is modelled from a steady-state month.

Steady state per user per month: 40k input, 8k output = (40 x $0.0025) + (8 x $0.015) = $0.10 + $0.12 = $0.22

Baseline month at 2,000 users = 2,000 x $0.22 = $440

Launch week triples traffic for 7 of 30 days = $440 x (23/30) + $440 x (7/30) x 3 = $337 + $308 = $645

Applying a measured effective rate 24% above list = $645 x 1.24 = $800

Range for the launch month = $700 to $950, widened because launch-week traffic is the least predictable input

$800 as the central figure, published as a $700 to $950 range. Forecasting the total from last month's $440 would have said about $530 and missed by a third.

Every number, with its confidence and source

Figure	What it means	Confidence	Source
$700 to $950	modelled forecast range for a launch month at 2,000 active users	estimated	Central figure $800, from driver-level arithmetic at real GPT-5.4 rates (price book, effective 2026-07-02) with a 24% effective-rate uplift. Shown as a range because launch-week traffic is the dominant uncertainty.
$0.22	modelled steady-state model cost per active user per month	calculated	(40 x $0.0025) + (8 x $0.015), GPT-5.4 rates per 1k tokens from the price book. Per-user token volumes are modelled.

What a generic answer can’t know

A forecast needs your usage curve per feature and per user, your real effective rate, and knowledge of what you're about to ship. None of that lives in a provider's billing data. It lives in your own request stream. Culpa reads it on your infrastructure, keeps your prompts and responses there, and counts the calls to run your plan.

Questions founders ask next

How far ahead can an LLM burn forecast be trusted?

One month is reasonable if your drivers are stable, and a quarter is a planning aid rather than a number to commit to. Anything further out is dominated by product decisions you haven't made yet, so widen the range accordingly.

Should a forecast be a single number or a range?

A range, always, with the assumptions stated. A single number gets read as a commitment and the first miss costs you credibility on every forecast afterwards.

How do I know whether my forecasting is getting better?

Store every forecast when you make it, then score it against the actual when the period closes. A forecast nobody scores can't improve, because nobody knows in which direction it's wrong.

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.

Base URLhttp://localhost:4545/v1Your traffic keeps flowing if Culpa ever stops.

Why the bill went up

Example dashboard

Calls 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

user_384report_generatorconv_91fprompt_v1894,220 tokens3 retries$6.81

Most expensive users

user_384$38.42

user_119$21.07

user_562$14.90

user_204$8.30

user_871$5.10

Next week forecast

Best$180

Median$240

p90$310

p99$395

Graded against reality. Accuracy shown as results land.

Run the free Cost Leak Scan Start 14-day trial

Keep reading

Sources: OpenAI API pricing. Last reviewed 2026-08-01. Plain text version.