I built the classifier tier in April. A model just shipped to be it.

A developer who built a three-tier classifier architecture in April — mechanical matching first, a model-based classifier for ambiguous residue, and a fallback underneath — argues that TypeSafe AI's newly launched Jev model, which returns calibrated probabilities over a fixed answer set instead of generating text, is a genuinely new category of purpose-built classifier machinery but should not be placed at the front door of a request pipeline. The developer contends that leading with a model means paying for judgment on inputs that required none, and notes that a metered classifier would reintroduce per-call billing into a system explicitly built to avoid it.

TypeSafe AI came out of stealth with Jev, a model that does not generate text. You hand it state and a typed question, it returns a calibrated probability over a fixed answer set. Nothing to parse, no invalid answer possible. My reaction was not "clever idea." It was "I have had that in production since April." That reaction is partly wrong and worth unpacking. What I will not claim: using a model as a classifier is not novel and was not novel in April. It has been ordinary since function calling shipped, and calibrated-label training sits in a research lineage older than any of this. Arriving somewhere independently is not arriving first. And Jev is a different category from what I built: I implemented a pattern with a general-purpose agent, they trained a model whose entire job is that pattern. Three things their approach has that mine structurally cannot: probabilities instead of labels, many questions about one state in parallel for nearly nothing, and latency appropriate to something sitting in the hot path. What I will defend is the integration shape, and it is not about who was first. Both patterns in their launch writeup lead with the model. Route every request through the classifier. Send every tool call through the classifier. The classifier is the front door. Mine has three tiers and the classifier is the middle one: source: "mechanical" | "classifier" | "fallback" Mechanical runs first and settles genuinely unambiguous cases with no model call. A large share of real traffic is not ambiguous; someone typing an exact pipeline name needs a lookup, not a judgment call. The classifier handles only the residue. A dumb fallback sits underneath so unavailability degrades predictably. The reason is not elegance. The cheapest call is the one you do not make, and the second cheapest is the one whose answer you can predict without asking. Leading with the model means paying for judgment on inputs that required none. A second benefit I did not appreciate at first: attributing which tier answered. "The classifier decided this" and "a pattern matched this" are different bugs with different fixes. One undifferentiated tier gives you one undifferentiated failure. The genuinely new thing in Jev is not asking a model for a typed answer. It is that the classifier finally has purpose-built machinery behind it. What I would push back on is putting it at the front. One caveat that cuts against adopting it, and worth answering before rather than after: my cost argument rests on no per-call metering, which is exactly what let me put a judgment call where a per-token bill would have discouraged one. A metered classifier reintroduces per-call billing into a system built to avoid it. Probably trivial at my volumes. Probably trivial is a thing to check.