Making Decisions Instead of Generating Text

Anthus has spent the last several years building post-call quality analysis at industrial scale. After a customer-service conversation ends, our systems analyze the recording or transcript against a scorecard: did the representative resolve the request, follow policy, or leave something unanswered? We began with conventional ML models, then increasingly used LLMs when the work called for more nuanced language understanding.

LLMs brought a mismatch. They produce open-ended text; a QA scorecard needs a bounded decision and a usable measure of uncertainty. Making one behave like the other can feel like fitting a square peg into a round hole. We added constraints, fine-tuning, parsing, retries, confidence signals, orchestration, and human review to bridge the gap.

Jev points toward a new paradigm for making those classification decisions at industrial scale. Instead of fitting a text generator into that role, TypeSafe designed Jev to return typed decisions and probabilities directly. For post-call QA, that could change where the work sits: inside a model whose native output is a classifier, with the application still responsible for scorecards, thresholds, and review policy.

Our Plexus MLOps platform carries that work into production scorecards. Teams define criteria as scores, evaluate them against labeled examples, then feed expert corrections into a Feedback Alignment Optimizer that proposes and tests score changes against both recent feedback and a fixed regression set. It is a practical classifier data flywheel: each measured round gives the next one better evidence to work from.

That production background is why Jev is interesting to us. It isn't merely another model we could place inside the same wrapper. It makes the decision itself a first-class model interface and asks how much of that wrapper should exist at all.

We built classifiers around text generators

In production, that mismatch becomes a contract problem. A quality-assurance application needs a stable field such as YES, NO, or NA, along with enough evidence about uncertainty to decide whether software can accept the result.

Getting from one shape to the other takes work. A prompt defines the allowed labels. A parser rejects extra prose or malformed JSON. Retries recover some invalid responses. Fine-tuning improves performance on a particular scorecard. Orchestration records versions, handles failures, and decides when a person should review the case.

Token log probabilities sometimes gave us a confidence signal, but they were an awkward foundation for routing. In our own production work, some commonly used models returned tightly concentrated log-probability distributions that appeared certain about nearly every answer. Those numbers did little to separate routine cases from the ones a person should inspect. Newer reasoning models we have evaluated often don't expose token log probabilities at all. These are observations from our systems, rather than claims about every model or provider, but they show why a probability-aware classifier interface is materially different from extracting confidence from generated text.

We described an earlier version of that approach in Fine-Tuned Classification with Confidence. The details have evolved, but the operational lesson has held: classification quality lives in the whole system. The prompt, model, rubric, parser, threshold, evaluation set, and human review process all matter.

That system can work well. It also contains machinery whose main purpose is translating between a text generator and a classifier.

Jev moves the contract into the model

Jev's interface accepts shared state and a collection of questions. It exposes three decision shapes:

• Choice selects from defined options and returns a probability distribution.
• Score evaluates the state against a rubric.
• Noul returns the probability that a yes-or-no statement is true.

TypeSafe says Jev uses parallel sampling and a training method it calls Reinforcement Learning for Calibrated Decisions. Those are vendor descriptions of the model's architecture and training, rather than findings we have independently verified.

The interface still leaves the application in charge. Jev evaluates questions independently against the supplied state. Software has to express dependencies, apply business rules, record results, and determine what any answer is allowed to trigger.

The supplied playground example shows why the interface is appealing. It places a bank-call transcript beside several scoring questions. The visible run returns 99% yes for whether the representative thanked the customer and 91% yes for whether they identified whom they represented. A separate Choice question about successful handling returns YES 95%, NO 5%, and NA 0%.

That result is already shaped for a scorecard field, a review queue, or a business rule. The application doesn't have to extract a label from a paragraph.

The screenshot also includes a deliberately odd question about whether the representative followed a protocol for space aliens. The run returns NA 80% and NO 20%. The example makes a real rubric problem visible: if the requirement doesn't apply, the scorecard needs a distinct way to say so. Overlapping definitions of NO and NA will create disagreement no matter which model answers.

This remains one visible run without expert reference labels or independently measured latency. It demonstrates the programming interface. It says nothing conclusive about scoring accuracy.

Typed output solves one failure class

TypeSafe describes Jev as producing type-safe structured outputs and uses the phrase “zero hallucinations” for guaranteed schema matching. Read that claim at the schema level.

If the allowed outputs are YES, NO, and NA, a typed interface can prevent the model from returning a fourth category or wrapping the answer in prose. That removes parsing failures and makes integration simpler.

Task correctness remains a separate question. A model can return valid YES while misunderstanding the transcript. It can apply an ambiguous rubric consistently and still disagree with the business's experts. It can assign a high probability to the wrong allowed answer.

So the meaningful production guarantee is narrower and still valuable: the response conforms to the contract. Whether the decision deserves action has to be established through evaluation.

Probability needs an operating policy

The successful-call example displays 95% probability on YES and a separate confidence value of 93%. TypeSafe documents confidence as a statistic derived from the distribution across available choices or score levels. It isn't an observed accuracy rate.

For production use, we would test calibration against a held-out set with expert-adjudicated answers. Among decisions assigned about 90% probability, how often does the selected answer match the adjudicated result? Does that relationship hold for each question, client, transcript source, and language? Plexus's evaluation workflow likewise compares scorecard results with known answers and reports performance metrics.

The answer determines the operating policy. A well-tested threshold might allow routine results to pass automatically, send an uncertain middle band to human review, and require review for every high-consequence finding. Different scorecard questions deserve different thresholds. A missed greeting and a serious compliance issue carry different risks.

This is also where human feedback keeps its central role. Experts define the rubric, adjudicate disputed examples, examine failure modes, and improve the evaluation set. In Plexus, human-in-the-loop review turns those corrections into feedback for the optimizer. Their decisions create the data flywheel that makes the whole system more useful over time. Jev could simplify the model-facing interface inside that loop; it doesn't replace the loop.

Price and latency are claims to test in context

Anthus has spent tens of thousands of dollars per month classifying calls with LLMs. At that scale, a large drop in unit cost changes which scorecard questions are economical to run and how much of the call volume a quality team can cover.

In its launch announcement, TypeSafe lists Jev at $42 per billion input tokens, with free output tokens, and reports response times from 70 to 500 milliseconds. It also reports large speed and cost gains from its own workflow evaluations. These are vendor claims, based on TypeSafe's architecture, benchmark harness, and comparison method.

The published input rate is useful for a concrete hypothesis. A Jev request containing 10,000 billed input tokens, including its state and questions, would have a model charge of $0.00042. One million such requests would cost $420.

For comparison, consider a 10-question scorecard implemented as 10 separate GPT-5.4 mini calls. Assume each call receives the same 10,000-token transcript and context, then returns a short, 10-token label. At OpenAI's published GPT-5.4 mini rate of $0.75 per million input tokens and $4.50 per million output tokens, that scorecard uses about 100,000 input tokens and 100 output tokens: roughly $0.07545 per scorecard, or $75,450 for one million scorecards.

On those deliberately simple assumptions, the Jev model charge is about 180 times lower. A batched LLM prompt, cached input, different transcript length, or more output and reasoning tokens changes the math. So does transcription, storage, engineering, and human review. A cheap model decision can still create an expensive review queue if its threshold is poorly chosen.

The operational metric we care about is cost per accepted decision at a defined error tolerance. We would track that alongside calibration, tail latency, review rate, and human minutes. For an overnight scoring batch, latency may barely matter. For a result needed seconds after hangup, it may decide whether the feature works at all.

The names TypeSafe chose explain the bet. “System One” draws on Daniel Kahneman's distinction between fast, intuitive judgment and slower, deliberate reasoning in Thinking, Fast and Slow. TypeSafe acknowledges that System 1 thinking has a reputation for error, while arguing that models designed for bounded decisions can be made reliable enough for software.

“Every order of magnitude drop in the cost of intelligence unlocks orders of magnitude more use cases.”

— TypeSafe, “Introducing System One Models & Jev”

That is why TypeSafe named Jev for William Stanley Jevons, and why the launch connects to our own argument in The Year Coding Became a Commodity and The Content Paradox. In Maximize Value, Not Intelligence, we made the operational argument directly: the windfall isn't merely doing the same work for less. It changes which work becomes worth automating.

New model advances keep moving that boundary. A cheaper, faster model with a native classifier interface could move a complete post-call QA scorecard or decision flow from operationally impractical to routine. That is the exciting possibility in Jev: broader coverage, finer-grained questions, and useful decisions that were previously too expensive or awkward to produce at scale.

The word could matters. TypeSafe's price and latency figures make this a compelling workflow hypothesis, not an independently proven result. Whether Jev moves that boundary has to be tested on calls and scorecards we understand.

Put Jev against a scorecard we understand

The next step is a bounded comparison on work we understand well.

Freeze a production rubric and reserve calls with expert-adjudicated answers. Include easy cases, disputed cases, missing evidence, poor transcripts, and criteria that don't apply. Give Jev and the current classifier equivalent information. Version every question and model. Run both paths in shadow mode so the experiment can't affect customers.

Then measure error by question, probability calibration, tail latency, invalid-response rate, review volume, and total cost per accepted decision. The current stack should receive credit for the things it already does well. Jev should receive credit for any parsing, retry, or orchestration work its interface genuinely removes. TypeSafe's price, latency, and performance claims remain vendor claims until those measurements reproduce them on our workflow.

The likely result is mixed, and that would still be valuable. Jev may fit some scorecard items better than others. A generative model may remain stronger where the rubric needs richer context or an explanation. Human review may still be the right path for rare, consequential cases. A production scorecard can route each kind of decision to the path that handles it best.

Even a partial fit could move the operational boundary. If Jev's typed outputs, probabilities, cost, and latency hold up against expert-adjudicated calls, questions that were too expensive or awkward to run broadly could become routine. A complete scorecard could cover more calls, ask finer-grained questions, and reserve human attention for the decisions where it matters most.

That is why we're excited about Jev. We have already learned how to make text-generation models behave like production classifiers. Now we can test what becomes possible when classification is the model's native shape. If the evidence supports TypeSafe's premise, Jev could be a significant advance in the kinds of post-call work worth automating—the same operational boundary shift we have expected as intelligence becomes cheaper and easier to use.