Abstract
Every production LLM system that ships to real users runs at least one more model on top of the one that answers: a classifier deciding whether the request is safe to process and the response is safe to return. That second model is rarely free, and its cost is rarely visible in a token dashboard built around a single primary call. This post uses Anthropic's own published research on Constitutional Classifiers as a real, verifiable case study of what a safety layer costs and how that cost can fall by more than 20x without giving up coverage. In February 2025, Anthropic's first-generation classifiers cut jailbreak success from 86% to 4.4%, at a published cost of 23.7% additional compute on every request. In January 2026, the next generation held effectively the same defense rate at roughly 1% overhead. The mechanism was not a smarter model. It was a cascade: a lightweight first-stage check screens every exchange, and only the fraction it flags pays for the expensive second-stage classifier. That is the same architecture behind LLM cost routing, applied to the call that decides whether a request is safe rather than the call that decides which model should answer it. We use Anthropic's figures as the real anchor, and label everything else in this piece, cost projections, latency ranges, waste breakdowns, as illustrative and clearly marked.
Introduction: the model nobody puts in the token dashboard
Ask most engineering teams what their LLM bill is made of and they will describe one call: prompt in, completion out, billed at the rate card. Ask them what runs before that call, or after it, and the answer gets vaguer. A prompt-injection check. A PII scan. A content-moderation pass on the output before it reaches the user. An output validator that re-reads the response against policy. Some of these are a few lines of regex. A growing number of them are themselves LLM calls, because regex does not catch a jailbreak phrased as a translation request or a policy violation phrased as fiction.
That second model call is a real cost and a real latency addition, and it is close to invisible in most cost observability setups, which are built around "the request" as a single unit rather than the full request lifecycle. It matters more every quarter, not less: the same wave of agentic deployment that is driving up primary-model token spend is also driving up the number of places a safety check needs to run, because an agent with tool access and multi-turn state has more surface area to check than a single stateless completion.
This is not an argument against guardrails. Constitutional Classifiers exist because unguarded frontier models are jailbroken at unacceptably high rates, 86% success in Anthropic's own red-teaming before the classifiers shipped. The argument is that "add a safety check" and "add an expensive safety check to every request forever" are different engineering decisions, and most teams make the second one by default, then never revisit it.
Research question
Where does the added cost and latency of an LLM-based safety layer actually come from, and does the same escalation logic that cuts cost in model routing, cheap check first, expensive check only when needed, apply to the guardrail call itself without weakening the safety guarantee?
Methodology
This analysis combines two kinds of data, kept clearly separate throughout:
- Published, primary-source figures from Anthropic's two Constitutional Classifiers papers: the original system (Anthropic, "Constitutional Classifiers: Defending against universal jailbreaks," February 2025; arXiv:2501.18837) and the next-generation cascade (Anthropic, "Next-generation Constitutional Classifiers," January 2026; arXiv:2601.04603). These are marked published everywhere they appear.
- Illustrative estimates built to reason about cost and latency at scale, using stated assumptions about token counts, model pricing tiers, and request volume. These are clearly labeled illustrative and are not measurements of any specific production system, ours or anyone else's. Where a qualitative claim (encoder classifiers are meaningfully faster than generative ones) is well established but a precise universal benchmark number is not, we use representative order-of-magnitude figures rather than a false-precision number attributed to one source.
We modeled three guardrail architectures against the same base workload:
- Naive same-tier check. The safety classification is a call to the same model tier used for the primary answer, run on both input and output, with no escalation logic, every request gets the full check.
- Routed cascade. A cheap, small classifier screens every request. Only the fraction it flags escalates to a more expensive, more accurate check, mirroring the architecture Anthropic describes for its second-generation classifiers.
- Routed cascade with caching. The same cascade, plus deduplication of safety verdicts on repeated or near-identical content, such as templated tool outputs or repeated system-prompt boilerplate.
Results: what a real, published safety layer costs
Anthropic's own numbers are the strongest data point in this analysis, because they come from a lab with every incentive to make its safety system look cheap, publishing a number that shows it was not, at first.
The first generation of Constitutional Classifiers added 23.7% compute overhead compared to an unguarded model, in exchange for cutting jailbreak success from 86% to 4.4% in human red-teaming. Source: Anthropic, "Constitutional Classifiers". That is a real, meaningful tax: a quarter more compute on every single request, forever, to catch the fraction of traffic that was ever going to be a jailbreak attempt.
Eleven months later, Anthropic published a second generation that held effectively the same defense rate, no universal jailbreak found across more than 1,700 cumulative hours of red-teaming and 198,000 attempts, at roughly 1% compute overhead. Source: Anthropic, "Next-generation Constitutional Classifiers". The overhead did not fall because the classifier got dramatically cheaper to run per exchange. It fell because most exchanges stopped needing the expensive classifier at all: a lightweight first-stage check, built on activations the model already produces during normal inference, screens every exchange essentially for free, and only the exchanges it flags proceed to the costly second-stage classifier. Anthropic describes this explicitly as a two-stage, cascade design. As a side effect, the refusal rate on harmless queries, the tax users pay when a safety system is too trigger-happy, dropped from a 0.38 percentage point increase to 0.05%, an 87% reduction in over-refusals. Source: Anthropic, "Next-generation Constitutional Classifiers".
Read those two charts together and the finding is unambiguous: this was not a tradeoff between safety and cost. Anthropic did not accept a weaker classifier to make it cheaper. It restructured when the expensive classifier runs, and captured nearly all of the cost reduction from that restructuring alone.
Results: where the naive design spends its compute
If a cascade recovers almost all of the overhead, the naive always-on design must be spending most of its compute somewhere other than catching real threats. This part of the analysis is illustrative, built to reason about the shape of the waste rather than to measure one specific deployment.
The largest illustrative category, by a wide margin, is compute spent running the expensive classifier on requests a cheap first-stage check would have resolved just as confidently. This is the direct analog of Anthropic's own finding: the majority of traffic simply is not ambiguous, and paying full price to confirm that is the core inefficiency a cascade removes. The smaller categories, duplicate content re-checked from scratch and both directions checked at full cost when one calibrated pass would do, are the same waste patterns that show up in context compression and prompt caching for the primary model call, just applied to the classifier instead.
Results: latency, not just cost
Cost is one axis. For a user-facing product, the latency a guardrail adds on the request's critical path matters just as much, sometimes more.
A generative safety classifier, the Llama Guard family of models is the clearest public example, is itself a multi-billion-parameter model doing a full forward generation, not a lightweight lookup. Source: Inan et al., "Llama Guard: LLM-based Input-Output Safeguard for Human-AI Conversations," arXiv:2312.06674. Running that model on a request's input and then again on its output, serially, before the user sees a response, stacks two generation passes onto the critical path. Encoder-based classifiers, which score text with a single forward pass through a much smaller model rather than generating tokens, are reported in recent guardrail-benchmarking literature to run at a small fraction of that latency. The qualitative direction here is well established even where a single universal benchmark number is not: an encoder pass and a generation pass are different orders of computational work. This is also why free, high-throughput classifier endpoints like OpenAI's moderation API, sub-100ms and free for API users on the omni-moderation-latest model, are built as lightweight classifiers rather than full generative judges. Source: OpenAI, moderation API documentation.
Results: what this costs at scale
To connect the compute-overhead percentages to an actual bill, we modeled an illustrative company running 10 million requests per month on a Sonnet-class primary model, with a Haiku-class model available for classification.
The naive configuration, using the same frontier-tier model to classify both input and output on every request, a pattern that shows up whenever a team reaches for "just ask the model itself if this is safe" instead of routing the check to a dedicated small model, adds an illustrative 16.7% to the monthly bill. Routing that same check to a small classifier, with an 8% escalation rate to a frontier-tier review on flagged content, brings the overhead down to roughly 2%. Adding a cache layer for repeated or templated content shaves a bit more. The assumptions behind these numbers, token counts, pricing tiers, escalation rate, cache hit rate, are stated in the chart caption; change any of them and the dollar figures move, but the shape of the curve, most of the overhead disappears once the check is routed and escalated rather than run at full cost on everything, is the same shape Anthropic reported independently in its own published research.
Discussion: what this means for teams building guardrails
The guardrail tax is a routing problem wearing a safety costume. Every argument this blog makes about routing the primary model call, cheap model for simple requests, escalate only when a calibrated signal says to, applies with equal force to the call that decides whether a request is safe. The classifier does not need to be a frontier model to catch the overwhelming majority of traffic, because the overwhelming majority of traffic is not adversarial.
Escalation logic is what makes cheap safe. Anthropic did not simply install a smaller classifier and accept the tradeoff, that would be the same predict-and-hope failure mode as a prompt-only model router. It kept the strong classifier in the loop for the fraction of traffic that actually needs it. The lightweight first stage is not a replacement for the expensive check. It is a filter that decides when the expensive check runs.
Reducing over-refusal is a quality metric, not just a safety one. The 87% drop in false-positive refusals on harmless queries is easy to miss in a conversation about cost, but it is arguably the more important number for a production team. A guardrail that blocks legitimate requests has the same downstream cost as a router that ships a wrong answer: retries, support tickets, and users who route around the system rather than through it.
Serial input-then-output checks cost twice. If both checks are necessary, and for most policy surfaces they are, running them one after another on the critical path adds their full latency together. Whether they can run concurrently, or whether the output check can be skipped when the input check already cleared a low-risk classification, is worth testing against your own traffic distribution before assuming both must always run in sequence.
This does not replace your safety review process. A cascade changes when the expensive classifier runs. It does not change what the classifier is trained to catch, or substitute for red-teaming a policy surface before shipping it. Anthropic's own numbers came from over 1,700 hours of adversarial testing behind the architecture change, not instead of it.
Implementation guide
- Instrument the guardrail call as its own line item. Most cost dashboards collapse "the request" into one number. Break out input classification, output classification, and the primary generation call separately, in tokens, dollars, and milliseconds, before deciding anything needs to change.
- Check what tier your safety classifier actually runs on. If your prompt-injection or content check is a call to the same frontier model answering the request, or a full generative classifier on every message, you are very likely paying full price for a decision that a smaller model can make correctly on the majority of traffic.
- Add a lightweight first-stage filter ahead of the expensive check. It does not need to be a generative model. A small classifier or embedding-based signal that screens for the obviously benign case is the same shape of pre-filter that makes cheap-first model routing work.
- Escalate on a calibrated signal, not a hope. The exchanges that proceed to the expensive classifier should be the ones the first stage is actually uncertain about, not a fixed random sample. This is the same principle behind a verifier-gated cascade for model selection: read a signal from the content, then decide whether the cheap path is good enough.
- Cache safety verdicts on repeated content. Templated tool outputs, repeated system-prompt boilerplate, and common user phrasings do not need to be re-classified from scratch on every occurrence.
- Measure the refusal rate on harmless traffic, not just the catch rate on adversarial traffic. A classifier tuned only against red-team data will look great on a security scorecard while quietly costing you legitimate users.
- Track cost, latency, and both error rates together. A guardrail's false-negative rate (missed a real violation) and false-positive rate (blocked something legitimate) both have a cost. Optimizing one in isolation from the other, or from the classifier's own compute bill, produces a system that looks good on whichever single metric you chose to watch.
Conclusion
The lesson from Anthropic's own published research is not "safety classifiers are cheap now." It is that the same architectural principle behind LLM cost routing, cheap first, escalate on signal, applies to the layer that decides whether a request is safe to answer at all. A safety check does not have to run at full cost on every request to be effective. It has to run at full cost on the requests that need it, and Anthropic's own numbers show that a well-designed cascade can identify that fraction well enough to cut compute overhead by more than 20x while holding the same defense rate.
Most production guardrails today look like Anthropic's system in February 2025, not January 2026: a real, working safety check that pays full price on every single request because nobody has gone back to ask which fraction of that traffic actually needed it. That question, which calls are routine and which are genuinely ambiguous, is the same question a cost router asks about the primary model call. Nadir already answers it for model selection: a pre-classifier reads the request, confident routes ship from a cheap model immediately, and borderline cases escalate to a stronger model under a calibrated verifier. Applying the same discipline to the check that decides whether a request is safe, rather than only to the check that decides which model answers it, is the same engineering move, aimed at a different call.
Sources: Anthropic, ["Constitutional Classifiers: Defending against universal jailbreaks,"](https://www.anthropic.com/research/constitutional-classifiers) February 2025 ([arXiv:2501.18837](https://arxiv.org/abs/2501.18837)). Anthropic, ["Next-generation Constitutional Classifiers,"](https://www.anthropic.com/research/next-generation-constitutional-classifiers) January 2026 ([arXiv:2601.04603](https://arxiv.org/abs/2601.04603)). Inan et al., ["Llama Guard: LLM-based Input-Output Safeguard for Human-AI Conversations,"](https://arxiv.org/abs/2312.06674) arXiv:2312.06674. OpenAI, [moderation API documentation](https://platform.openai.com/docs/guides/moderation). Charts 1, 2, 3, and 4 combine these published figures with illustrative estimates built on stated assumptions, clearly labeled in each caption, and are not measurements of any specific production deployment.