Shieldstral: accuracy is settled, packaging decides

What Shieldstral is, in one pass

My job at eesel is integrations and API plumbing, so with any model launch my instinct is to skip past the chart and read the serve command. Shieldstral shipped on 4 August 2026: open weights, policy-adaptive, multimodal safety classifier, Apache 2.0.

The interface is where it gets interesting. You send a fixed system prompt, then a user message carrying three tagged blocks. <Instruct> holds your context and how strict you want it, <Query> holds a single yes-or-no question, <Document> holds the content itself. From there the model card asks for one token with logprobs=True, softmaxes the yes and no logits against each other, and treats anything above 0.5 as a violation. That is the whole thing. No taxonomy to learn, and no retrain when you want to point it somewhere else, which puts it closer in spirit to custom AI models than to a fixed classifier.

A few specifics worth getting straight, since the marketing and the metadata do not quite agree:

• Size. It is marketed as 3B and the canonical id is mistralai/Shieldstral-1.0-3B, but the Safetensors block further down that same page says 4B. Built on Ministral-3-3B-Base-2512, with a native Pixtral vision encoder.
• Context. Trained to 32k. Mistral says 256k is theoretically supported, then tells you to stay inside the training range anyway.
• Hardware. 16GB of VRAM at BF16, and a single vllm serve line on vLLM 0.26.0 or newer.
• Licence. Apache 2.0 and ungated. No form to fill in, nobody asking for a legal name or an organization field.
• Uptake. 14,236 downloads in the first month. The GGUF quants came from the community, from noctrex, and not from Mistral.

If open weights are why you clicked, the wider map lives in best open source AI agents and open source chatbot platforms.

The model-level walkthrough, the interface quirks, what breaks in week one: that all sits in the Shieldstral review. This piece is about the decision around the model.

The chart everyone screenshots, read properly

Mistral published four charts. The one that travelled is text safety, aggregated over 13 benchmarks in 45 languages.

The headline reading is the tie: 84.9 for a 3B model, 84.9 for GPT-OSS-Safeguard at 20B. Real engineering result, and Mistral is entitled to it.

The more useful reading is the bracket around it. Shieldstral 84.9, GPT-OSS-Safeguard-20B 84.9, Qwen3Guard-8B 84.0, Nemotron-3.5-Content-Safety 83.3. That is four labs and four sizes, from 3B up to 20B, landing inside 1.6 F1 points of one another.

Below that group the field does open up, so this is not a case of "all guard models are the same": PolyGuard-Qwen-7B 82.1, WildGuard-7B 79.5, OmniGuard-7B 77.4, LlamaGuard-4-12B 69.1, ShieldGemma-9B 54.7.

Among the models you would actually shortlist, though, the accuracy question is closed. And Shieldstral does not sweep the rest of Mistral's own charts either, which is worth saying plainly, since Mistral is the one who published them:

That last row surprised me. Policy adaptability is the thing Shieldstral is named for, the plain-language-question interface being the whole pitch, and on Mistral's own measurement of it the model lands third. Which is not bad. It is just not the differentiator the framing implies.

So if accuracy is settled, what actually picks the guard

Four axes, roughly in the order they bite you in a real deployment.

Who runs the GPU. The big one, and Shieldstral's weakest spot. Hugging Face states flatly that no inference provider deploys the model, and there is no Shieldstral row anywhere on Mistral's rate card. The moderation model Mistral will actually serve you is Mistral Moderation 2 (mistral-moderation-26-03), which is free. So the real choice here is not "cheap open model versus expensive API". It is "your GPU versus somebody else's, for free either way."

Whether the verdict comes with a reason. Shieldstral emits a single token. GPT-OSS-Safeguard emits a full chain of thought, with a low/medium/high effort dial on top. Nemotron keeps its <think> block behind an enable_thinking flag. And LlamaGuard-4 gives you a bare unsafe plus a category code at max_new_tokens=10. Same job on paper, four fairly different debugging experiences.

Whether you can write your own policy. Developer-authored policies work on Shieldstral and GPT-OSS-Safeguard. Qwen3Guard and LlamaGuard-4 ship fixed taxonomies instead, and Nemotron manages both from one checkpoint. The hosted APIs are almost all fixed: OpenAI's endpoint gives you 13 categories and no policy field at all.

Whether the licence lets you ship. Worth a check, even if nobody in the launch threads bothered raising it. Apache 2.0 and ungated covers Shieldstral, GPT-OSS-Safeguard and Qwen3Guard. LlamaGuard-4 sits under the Llama 4 Community License behind an access-request form that wants a legal name, a date of birth and an organization. Nemotron comes under OpenMDW v1.1 plus Gemma's terms of use, an unusual pairing to route past legal.

Which guard fits what you are blocked on

Pick whatever is actually stopping you, and see what survives it.

The packaging table, all in one place

This is the artefact. Every cell below comes off the vendor's own model card or rate card, checked on 18 August 2026.

Two things jump out of that table that the F1 chart hides. Shieldstral has the fewest downloads of any open model on it, by roughly 13x against LlamaGuard-4. That is a distribution problem and not a quality one, and it is almost certainly the missing endpoint. The second thing: Nemotron-3.5-Content-Safety, sitting 1.6 points behind on text safety, is the only open checkpoint on the table handing you a free hosted endpoint, an optional reason, custom policies and a fixed taxonomy all at once.

The bill nobody models: one call per policy

Here is the cost mechanic that catches people out, and it appears on no chart.

Shieldstral's <Query> block holds one yes-or-no question. One policy, one forward pass. Moderate against six policies and you are making six calls for a single piece of content. Somebody on the launch thread had worked this out on day one:

"It sounds like it is. You have a set of moderation policies and then you evaluate the model 1 time per policy if it is violating it. Then you combine the results into a score you use for taking actions off of."

charcircuit, Hacker News

Mistral does document a shortcut. List your categories inside <Instruct>, then ask one broad question. Six calls collapse into one, but so do six answers, so you no longer know which policy tripped. Fine for a blunt gate. Less useful once you are building ticket classification or any reporting on top of it.

Set that against a fixed-taxonomy model that returns all of its categories from one pass, and the packaging difference turns into a straight multiple on your compute bill. Same trap as reading a token price without checking the billable unit underneath it, which is why OpenAI API pricing and Anthropic API pricing are both worth reading unit-first.

The hosted APIs are the baseline any self-host has to beat

Any time "just run the open model" comes up, this is the number I want in the room:

"OpenAI's moderation API is multi-modal and free with no strings attached in a way that truly boggles the mind.

I've put easily over a billion requests (>$100,000 by typical moderation API pricing) through it over the last few years for $0.

I think it's a severely underappreciated offering, but I also don't bother pushing it too hard because who knows when the party will end lol."

BoorishBears, Hacker News

A billion moderation calls at real production volume, for nothing. Any argument for standing up your own classifier has to clear that bar first. The OpenAI moderation API really is free, and Mistral Moderation 2 is too.

And the paid hosted options are not expensive either, so long as you read the unit and not the price:

Watch the rounding on both of the paid options. A 7,500-character document counts as 8 records on Azure, not 7.5. Guardrails, meanwhile, bills on top of the model's own token cost when it runs inline: AWS's own worked example puts Guardrails alone at $0.90 per hour for a chatbot, before any inference at all.

So the honest framing for self-hosting is not cost. It is control, and data residency. The launch thread got there too, and named the exact buyer:

"Any company with a customer support chat is a potential user of this model, any large company may be interested in getting a mistral installed set-up for handling without needing to send client info over the web."

pebbly_bread, Hacker News

That matches what I hear on sales calls. One buyer had an internal security review as a hard gate before any trial, and what they wanted was written assurance that ticket data carrying credit-card details and passwords never left their environment. Nobody in that conversation asked what the model scored. They asked where the data went. Same instinct sits behind Zendesk security and compliance questions, and behind the GDPR checks that come up in every enterprise review.

The counterweight, from someone who has actually built a large moderation pipeline:

"Back when BERT was the edge, a policy-adaptive model like this one from Mistral would have been an incredible cold-start solution. Most sites never have the massive volume nor budget needed nor skillset needed before you can train domain-specific models that outperform OOTB solutions."

rancar2, Hacker News

Volume, budget, skillset. That is the real bill for a self-hosted guard, and not one of those lines shows up on a rate card.

The reason gap cuts both ways

The missing reasoning trace was the loudest complaint on launch day, and the review post covers it at model level. What is worth adding here is that it is not straightforwardly a bug.

If you are moderating user-generated content at scale, a stated reason becomes a liability surface:

"Rejection reasoning is also a liability and can be extremely legally risky. If you're the company, you don't want a user to win a lawsuit against you just because a judge disagreed with the exact reason you banned someone."

ranger_danger, Hacker News

For anything customer-facing in Europe the pressure runs the other way:

"There are quite a lot of instances where under GDPR, you have the right to have incorrect information about you corrected. I also think you have the right to appeal a decision to a human."

tomjen3, Hacker News

So the reason axis is not a case of "more is better". It is "match it to who has to answer for the block." A spam gate on signups wants a silent score. A support queue, where some agent ends up writing "we blocked your message because", wants a trace, or at least a documented human path sitting behind it. Same design decision as human handoff in chat support and escalation management, and it is worth writing down before launch instead of after the first complaint. The GDPR side of it is not optional in Europe.

And the deployment reports here are real rather than theoretical. TNG Technology Consulting put the reasoning-capable option in front of a live agent:

"Utilizing TNG's substantial experience with guardrailing LLMs, a straightforward approach with gpt-oss-safeguard-20B as the guardrail model succeeded right away."

TNG Technology Consulting, X

Where a guard model helps a support queue, and where it does not

This is the part I most want support teams to get right, because I keep watching people conflate two gates that have nothing to do with each other.

A guard model answers: is this content safe to process. It is good at that. Abuse on inbound messages, self-harm signals that need a human immediately, a policy check on an outbound draft before it sends, screening image attachments too. Real jobs, all of them, and a 3B classifier does them cheaply enough that you can run it on every single message. The ecommerce version of this is in safe moderation filters, with the prompt-side equivalent in support triage templates.

What a guard model does not answer: does my AI actually know this. That is retrieval confidence, an entirely different signal. Nothing in Shieldstral's score tells you whether your knowledge base covers the customer's question, or whether the past-ticket history holds a good precedent, or whether the draft reply is about to hallucinate a policy. Passing a safety check and being answerable are unrelated properties of a ticket. Which is also why AI support QA has to look at the answers rather than at the flags.

Deals get lost on the second gate, not the first. The clearest version of that objection I have heard came from a CX lead at a DTC brand handling around 7,000 tickets a month. They would not buy an AI that replies to everything, because auditing 7,000 "sorry I don't know" replies costs more than the automation saves. What they wanted was an AI that answers only what it is confident about and quietly leaves the rest alone. A confidence threshold problem, then, not a moderation one, and no guard model on the table above solves it.

The other thing I would flag from experience: the "build our own" instinct gets a lot stronger the moment good open weights exist. A mid-market customer who churned put it bluntly in a reply to our founder, saying they would move to a cheaper tool for now, and long term would just build their own, because that is so possible now with AI. They are right that it is possible. What they were underrating is that the model was never the hard part.

The hard part is ticket ingestion, routing, tagging, escalation rules, then six months of tuning after launch.

Measuring whether any of it worked is its own project on top, which is what containment rate is for. Same maths as any open source support stack decision.

What I would actually run

Straight answers, by situation.

• You want a guard today with the least work. Nemotron-3.5-Content-Safety. Free hosted endpoint, an optional reason, custom policies and a fixed taxonomy out of one checkpoint, 128K context. It sits 1.6 F1 points behind the leaders and that gap will not show up in your logs.
• A human has to explain every block. GPT-OSS-Safeguard-20B, where the reasoning trace is the product. It fits 16GB despite the 20B label.
• Your problem is image attachments. Shieldstral. It leads Mistral's multimodal chart at 83.8, and this is the one case where the score itself is your reason to pick it.
• You just want abuse and self-harm off your queue. OpenAI's moderation endpoint. Free, hosted, done in an afternoon. You outgrow it the day you need a policy its 13 categories do not cover.
• Data residency is a hard gate. Shieldstral or Nemotron on your own metal. Budget the ops time honestly rather than the GPU price.

Shieldstral is a serious piece of engineering that happens to be hard to adopt right now. A hosted endpoint from Mistral would change that overnight, and since Mistral Moderation 2 already sits on the rate card, it reads more like a question of when. Until then, tied for first on the chart and last on hosting is an odd place to be.

If you are surveying the wider lineup, Mistral pricing and Mistral alternatives cover the rest.

Two other open families worth tracking on this axis: Qwen and Gemma 4, both shipping guard variants alongside their chat models.

eesel for the gate that actually decides

eesel is not a guard model, and I would not pitch it as one. What it does is the second gate in that diagram: deciding which tickets your AI should answer at all, and quietly leaving the rest to a human.

The concrete difference: you get to see the answer before committing. eesel runs a simulation over your own historical tickets, so you get a real read on which ones it would have handled well and which it would have handled badly, from your actual queue rather than a benchmark. That is what every buyer with a safety worry ends up asking for. Kim Simpson at Gridwise put the outcome this way, in a permissioned review:

"In the first month, eesel is resolving 73% of our tier 1 requests... results quickly during our 7-day trial."

Free to try, no call needed, and it connects to your helpdesk inside a few minutes. From there the useful next steps are ticket triage, and tracking a real deflection rate instead of a demo number.

If you are earlier than that and still mapping the category, AI teammates and best AI agents give the wider view.

And routing for SaaS covers the plumbing under all of it.