Guides / llm cost for 100 users
Working out what a given number of users costs
Cost for a user count is one bundle priced once and multiplied, so the useful number is cost per user rather than the total. The total moves for two different reasons and won't tell you which. Culpa, a local-first LLM cost, margin, and forecast ledger, prices every call and attributes it to the user who made it.
Computed in your browser, in exact decimal
The per-user figure is the one to watch. A total that rises tells you nothing on its own, because it moves when the unit gets dearer and when there are simply more of them, and those need different responses.
Rates come from Culpa's price book, effective 2026-07-02. Every figure is computed in exact decimal rather than floating point, which is why totals here match an invoice to the cent. Cost is calculated, not provider-reported: it prices the tokens you enter at a published rate.
Why this happens
Sizing a user count is arithmetic, and the arithmetic isn't where this goes wrong. What goes wrong is which number gets tracked afterwards. A total is the product of two things, cost per user and how many users, and once multiplied together the result can't say which one moved. A month that rises 20% looks identical whether you gained a fifth more customers, which is good, or your existing ones each got a fifth more expensive, which isn't. Keeping the per-user figure visible separates them at no cost. The second thing worth knowing before multiplying: users aren't interchangeable. Usage is skewed almost everywhere, so an average user is a construct and the top decile can cost many times the median. Multiplying an average by a headcount gives a number right in aggregate and wrong about everyone, which matters the moment you use it to price a tier.
What this usually looks like
- You report total AI spend and not spend per user.
- A monthly rise can't be split into more users against dearer users.
- Your per-user estimate came from an average nobody checked for skew.
- Tier pricing was set from a headcount multiplication.
- Nobody knows what your most expensive decile of users costs.
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 |
|---|---|---|
| Tracking the total instead of the per-user figure. | The total moves with headcount and with unit cost, and the two need opposite responses. | Report both, always together, so a movement can be attributed. |
| Multiplying an average by a headcount. | Usage is skewed, so the average describes nobody and understates the expensive tail. | Multiply by segment, or at least price the top decile separately. |
| Sizing a plan from the arithmetic alone. | A plan meets real users, and real users cluster at both ends of the distribution. | Check what share of users would exceed the plan's budget before setting it. |
| Assuming per-user cost holds as you grow. | New cohorts often use the product differently from the ones you measured. | Re-measure per-user cost by cohort rather than assuming the first one generalises. |
Run this check tonight
- Work out your real cost per active user for last month.
- Multiply it by your user count and compare against the actual bill.
- Rank users by spend and see what the top decile costs against the median.
- Check whether last month's rise came from headcount or from cost per user.
One user, then a hundred, then a thousand
Illustrative example
A modelled user consuming 500,000 input and 100,000 output tokens a month, priced on Claude Haiku 4.5 at its real rates of $1.00 and $5.00 per million from the price book effective 2026-07-02. The same user is then priced on Claude Sonnet 5 at its real introductory $2.00 and $10.00. Rates are published, the per-user token volumes and the user counts are modelled.
The last line is the one worth keeping. A total that went from $100.00 to $200.00 could be a hundred new users or a model change, and the total alone won't distinguish them. Per user, the two look nothing alike.
Every number, with its confidence and source
| Figure | What it means | Confidence | Source |
|---|---|---|---|
| $1.00 per user per month | modelled cost of one user at 500,000 input and 100,000 output tokens on Claude Haiku 4.5 | calculated | 500,000 input at $1.00 per million is $0.50 and 100,000 output at $5.00 per million is $0.50, giving $1.00, using the price book's real Claude Haiku 4.5 rates effective 2026-07-02. At 100 users that comes to $100.00 and at 1,000 users $1,000.00. The same user on Claude Sonnet 5 at $2.00 and $10.00 costs $2.00. Rates are published, the per-user token volumes and user counts are modelled. |
What a generic answer can’t know
Which user made a call is your fact. A provider sees a key and a model, and if every user shares a key it sees one very busy customer. That makes cost per user an application-level join, recorded at call time or not available at all. Culpa records the user alongside the customer, feature and run, prices each call from a versioned price book in exact decimal, and keeps the ledger on infrastructure you control. That turns the questions this page raises into queries: what the median user costs against the top decile, whether a rise came from headcount or from unit cost, and which cohort's per-user cost is climbing. Set it against what those users pay and the same multiplication reports margin rather than spend.
Questions founders ask next
How much does an LLM feature cost for 100 users?
Price one user, then multiply. In the modelled example a user consuming 500,000 input and 100,000 output tokens costs $1.00 a month on Claude Haiku 4.5, so 100 users is $100.00 and 1,000 is $1,000.00. The calculator above takes your own volumes.
Why track cost per user rather than the total?
Because a total is two numbers multiplied together and can't say which one moved. A 20% rise looks the same whether you gained users or your existing users got more expensive, and those call for opposite responses.
Is an average user safe to multiply by?
In aggregate yes, about individuals no. Usage is skewed nearly everywhere, so an average describes nobody and understates the expensive tail. It's fine for sizing a bill and misleading for setting a plan limit.
Does per-user cost stay flat as we grow?
Often not, because later cohorts use the product differently from the ones you measured first. Re-measure per-user cost by cohort rather than assuming the earliest number generalises to everyone who arrives after it.
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.
Keep reading
Sources: Anthropic pricing. Last reviewed 2026-08-05, rates effective 2026-07-02. Plain text version.