When semantic judgment becomes cheap enough to put everywhere

Cheap, fast semantic judgment could become a standard tool in software.

What a System One model does

That’s what interests me about Jev, released in early access by TypeSafe AI on September 15. It takes text or structured state as input and returns structured answers. Unlike the models behind ChatGPT, Claude, and Gemini, it doesn’t generate prose.

My mental model for Jev is an open-book exam with multiple-choice questions. You provide the context, the questions, and the options. It evaluates them and returns probabilities rather than conversational text.

One of its primitives is called “Noul.” A conventional boolean gives you true or false. A Noul returns the probability of “yes.” Your code decides whether that probability is sufficient to act, gather more evidence, or ask a human.

LLMs can already perform these judgments. The economics and speed are what make Jev interesting.

What it costs and how fast it answers

Jev costs $0.042 per million input tokens, with no output charge. TypeSafe reports response times of 70–500 milliseconds. My own initial testing showed 200–300 milliseconds. TypeSafe’s launch announcement

For comparison, Claude Haiku 4.5 costs $1 per million input tokens and $5 per million output tokens at standard uncached API rates. Actual workflow costs depend on input length, output length, caching, and how many calls you need. Anthropic pricing

This is early-access pricing, so I wouldn’t build a long-term thesis around the exact rate. Haiku is also not the floor; cheaper small models exist from other providers. Nor are structured answers exclusive to Jev: generative APIs can also enforce output schemas. The question I care about is whether a model built for these decisions can deliver adequate accuracy at consistently lower cost and latency. Claude’s structured-output support

Three questions in a job-search pipeline

In a job-search pipeline I’m building, I’m exploring questions such as:

• Does an ambiguous job title justify fetching the full description?
• Do the location restrictions rule this candidate out?
• Does its hybrid policy fit the candidate’s constraints?

These look like simple classification problems until you encounter the language people actually use.

“Remote” might mean remote within a particular state. “Flexible working” might still require three days a week in an office. An office address might identify the employer’s headquarters without saying anything about where the employee must work.

Regex and heuristic rules can handle familiar patterns. They become harder to maintain as qualifications, exceptions, and conflicting statements accumulate. An LLM can interpret those nuances, but a generative call can introduce more cost and latency than a small decision warrants.

Getting the judgments right

It took only a few minutes to wire Jev into the pipeline. Getting useful judgments took testing and refinement. I’m still evaluating whether its accuracy is sufficient for each of these uses.

That work includes defining the question precisely, explaining what each label means, representing insufficient evidence, and choosing thresholds that reflect the consequences of being wrong.

For example, fetching an irrelevant job description wastes some processing. Skipping a suitable posting means the candidate may never see it. For the fetch decision, I would accept more unnecessary fetches to avoid missing promising jobs.

Jev also supports prompt engineering through instructions and descriptions of the available choices. We can explain exclusions, add examples, clarify boundary cases, and split a complicated judgment into smaller questions. For a work-arrangement question, that might mean distinguishing recurring office attendance from occasional travel and providing an “unspecified” option when the posting doesn’t say. TypeSafe’s guidance on structured instructions

A constrained answer can still be confidently wrong. The model can overlook a qualifier or interpret a label differently from how I intended.

Returning a valid value from a predefined list guarantees neither good judgment nor adequate evidence.

I’ve written before about verifying LLM-generated code before relying on it as a deterministic artifact. Jev’s typed answers make integration easier, but they don’t supply that verification step. We still need to check whether its decisions hold up against reviewed examples.

How the work divides

The division of work I expect to see more often is:

• Conventional code for deterministic operations.
• Semantic models for uncertain judgments.
• Generative models for strategy and synthesis.

These roles overlap. A generative model can classify, and a semantic model can contribute to a larger strategy. Agents and application code can choose the tool that fits each step.

In my piece on autoresearch, I explored how cheap verification makes repeated experimentation practical. Cheap judgment could expand automation in a related way, particularly where rules struggle to interpret unstructured information. The difference is that the judgment remains fallible, so the workflow has to account for its errors.

Jev’s capability is familiar. What changes is the number of places where using it might make economic and operational sense.

When semantic judgment becomes cheap and fast enough to call throughout a workflow, it starts becoming an ordinary building block of software. That is why I expect this pattern to spread.