Everyone is pointing these models at their content. We pointed them at policy.

TypeSafe released Jev on 15 September and opened it to everyone on the 20th. The internet spent a fortnight working out that it is a very good classifier. Around thirty open reproductions shipped. Then on 6 October OpenAI put its own Decisions API into public beta, which is how you can tell a category has arrived rather than a product.

They are decision models: you hand one a piece of content and a set of typed questions, and it answers them with probabilities instead of prose. People are pointing them at support tickets, listings, documents and moderation queues.

We support it too. But the interesting place to point a classifier, if you already run a gateway, is not at the content going past. It is at the policy deciding what happens to that content, because a policy is exactly a list of typed questions asked of a piece of content.

A new point on the triangle

Squidder has always let you name the model that judges your policies. It is a real decision, made deliberately: cost, accuracy and latency trade off differently depending on what you are governing, and different policies deserve different answers. Chat models remain the right choice for plenty of them.

What is new is what now sits beside them on the list.

A decision model is a different point on that triangle. It returns a value from a set you defined, so it cannot invent a category that does not exist in your policy or phrase a verdict your gateway cannot read. And it is trained specifically for calibration: that probability is the thing it was built to get right, which is a different guarantee than a general-purpose model makes.

The figures are what make it a genuinely different kind of component. On the vendors' own published numbers: answers in well under a second where a chat model takes several, a structured output error rate of zero because these models never write text at all, and input priced at $0.042 per million tokens for Jev and $0.10 for OpenAI's, both with output free.

Two of those compound with how the gateway asks. Every rule that applies to a request is sent together in one call, so a policy carrying twenty checks is one round trip rather than twenty. Price and latency are per call. Governing a request thoroughly costs about what governing it lightly does.

There is a second-order effect worth more than the first. "Does this look like an attack" is unbounded judgment over arbitrary text, and a frontier chat model is often the right tool for exactly that. "Does this match the thing I described" is a bounded comparison against a reference you supplied. You do not buy accuracy with a bigger model. You buy it by giving a better question to a model built for the question. System One models are built for the question.

You add one the way you add any other: pick a provider, supply a key, put it on an allowlist. That can be OpenAI's Decisions API, which most enterprises can reach under a contract and a data agreement they already have. It can be TypeSafe's hosted Jev. It can equally be one of the open reproductions (Laya, Kev and Von among them) running on hardware you own, under permissive licenses. If your content cannot leave the building, that last one is your path.

The two vendors do not speak the same dialect. Jev asks for a yes or no as a noul; OpenAI calls the same thing a predicate and wants the criteria written into its instructions. You should not have to care. You write the rule once, in plain language, and the gateway puts the question in whatever form the model you picked expects. Change your mind about the model and the rule does not move.

You name the judging model on the policy itself, not on each rule, so one model answers every check that policy holds. It applies to content policies, routing policies and tagging policies. And you can run it against your own content before you trust it: hand it a piece of text and the questions you mean to ask, and it answers them in front of you, with the probability on each and whether it crosses your threshold.

Decisions are a surface, so govern them like one

Your applications are going to start calling these models directly. At sub-second answers and single-digit cents a million tokens, a typed decision becomes affordable inside a loop: route this ticket, is this listing acceptable, which of nine things is the customer asking for. Work that was too slow or too expensive to ask a model about, per item, at volume, is now neither.

The traffic arrives whether or not anyone planned for it, carrying your content to somebody else's model, from code written in an afternoon because the call is cheap to make.

In Squidder, decision traffic is a surface of its own, alongside LLM, web and the agent protocols, with its own access switch. An application calling one meets what any other call meets: the model allowlist, your limits, and a row in the request log with its usage and its cost.

One detail for whoever owns the bill. Inspection cost lands on the application owner's bill as its own line, not absorbed into what they spent answering their users. The team deciding how much to inspect is the team that can read what inspecting costs them.

Getting started

Add OpenAI Decisions or TypeSafe as a provider with your key, or point Squidder at your own server speaking the open interface. Put the model on an allowlist, open the policy that holds the checks you care about, and name it as the judging model.

In a demo we will run it against a live policy together, your questions, your threshold, your content, so you leave knowing whether it belongs in your stack.