Guides / guardrail cost
What it costs to check every request, and why that share moves
A guardrail call costs what it costs regardless of the model it protects, so its share of the bill rises as your main model gets cheaper. Optimising to a smaller model makes safety proportionally more expensive. Culpa, a local-first LLM cost, margin, and forecast ledger, prices every call so the check and the answer appear as separate lines.
Why this happens
Screening requests before they reach the model, and sometimes screening the response on the way back, is now standard practice and it's almost always another model call. That call has a fixed cost: a short classification prompt, a very short answer, usually on the cheapest model available. In absolute terms it's tiny, which is why it rarely gets counted. In proportional terms it depends entirely on what it's protecting, and that's the part that moves. Against an expensive reasoning model the check disappears into the noise. Against a cheap model doing a simple task, the same check is a meaningful share of every request. The trap is the ordering. A team optimises cost by moving the main workload to a smaller model, wins a large saving, and leaves the safety layer exactly where it was, at which point the guardrail has quietly become one of the larger remaining line items and nobody has looked at it since it was written.
What this usually looks like
- You screen every request and the screening isn't in your cost model.
- Safety calls were sized against a model you no longer use for the main task.
- You check both the request and the response and count neither.
- Cost per call didn't fall as much as expected after a model downgrade.
- Nobody knows what share of your calls are checks rather than answers.
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 |
|---|---|---|
| Leaving safety calls out of cost per request. | Every protected request makes at least two calls, so per-request cost is understated. | Count the check as part of the request it protects, since that's exactly what it forms. |
| Not re-checking the guardrail after downgrading the main model. | The check's share rises as the thing it protects gets cheaper, and nobody revisits it. | Re-express the guardrail as a percentage of the call after every model change. |
| Screening input and output at the same depth. | It doubles the fixed cost, and the two directions rarely carry the same risk. | Decide each direction on its own risk, rather than symmetrically by default. |
| Screening every request identically. | Low-risk traffic pays the same as high-risk traffic for a check it rarely needs. | Route by risk where you can, and measure what the routing saves. |
Run this check tonight
- Work out what fraction of your calls are safety checks rather than answers.
- Express your guardrail cost as a percentage of the call it protects.
- Redo that percentage against the model you actually run today.
- Check whether you screen in both directions, and whether both are earning it.
One check, two main models
Illustrative example
A modelled safety check of 500 input and 10 output tokens on Claude Haiku 4.5, run once per request across a million requests a month. The protected call is a modelled 2,000 input and 500 output tokens, priced first on Claude Opus 5 and then on Claude Haiku 4.5. Rates are the price book's real figures effective 2026-07-02 and 2026-08-01. Token shapes and volume are modelled.
The safety layer never changed and its share went up five times. That's the whole point: moving the main workload to a cheaper model is usually the right call and it silently promotes your guardrail from a rounding error to a line item worth reviewing. Almost nobody re-runs this calculation after the migration that causes it.
Every number, with its confidence and source
| Figure | What it means | Confidence | Source |
|---|---|---|---|
| 2.4% against 12.2% | modelled share of a request taken by an identical safety check, on an expensive and a cheap main model | calculated | A modelled 500-input, 10-output check on Claude Haiku 4.5 at real rates of $1.00 and $5.00 per million costs $0.000550. A modelled protected call of 2,000 input and 500 output costs $0.0225 on Claude Opus 5 at $5.00 and $25.00, and $0.0045 on Haiku 4.5. $0.000550 / $0.0225 = 2.4% and $0.000550 / $0.0045 = 12.2%. At a million requests the check is $550.00 a month either way. Rates are published, token shapes and volume are modelled. |
What a generic answer can’t know
Which of your calls are checks and which are answers is a distinction only your application makes. A provider sees requests, and a bill sees tokens, and neither knows that two of them were one user action with a screen in front of it. Culpa prices every call and carries whatever identifiers you attach, so a guardrail call is tagged as one and cost per protected request becomes a sum rather than an estimate. That makes the useful questions answerable on your own traffic: what share of spend is defence rather than product, whether that share moved after your last model change, and which routes are paying for a check that has never once fired on them.
Questions founders ask next
How much do LLM guardrails cost?
Very little in absolute terms and a variable share in relative ones. A modelled 500-token check on Haiku 4.5 costs $0.000550 a request, which is $550.00 a month at a million requests. Whether that matters depends entirely on the model it protects.
Why did my safety cost become significant after I saved money?
Because the check's cost is fixed and the thing it protects got cheaper. The same $550.00 a month is 2.4% of a workload on Opus 5 and 12.2% of the same workload on Haiku 4.5. Optimising the main model raises the guardrail's share without touching it.
Should I screen responses as well as requests?
That's a risk decision rather than a cost one, but it does double the fixed overhead, so it's worth deciding deliberately rather than symmetrically. The two directions rarely carry the same risk profile, and pricing them together hides that.
Can I screen selectively?
Often, by routing on risk so low-risk traffic skips the deeper check. What makes that decision safe is measuring how often the check actually fires per route, which needs the check tagged as its own call in your cost data rather than folded into the request.
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.