We Put Jev Beside the LLM, Not in Charge

The short version

Jev did not replace our main language model. We plugged it into ShipSite as a small decision layer for the awkward little judgments that sit between clear rules and full-blown generation. The main model stayed put. The product flow stayed put. Sensitive permissions stayed out of Jev’s reach.

That distinction matters because the conversation around Jev has been loud. Some people called it the end of LLMs. Others read “no hallucinations” and assumed it meant “always right.” A few saw a new label wrapped around the same old idea.

I prefer to judge a tool by the code around it. So this is an English adaptation of a first-hand ShipSite integration report: what Jev is, what we actually connected, what the acceptance tests showed, and where we drew the hard line.

So what is Jev, exactly?

TypeSafe AI launched Jev on September 15 as what it calls a “System One Model.” The name borrows Daniel Kahneman’s familiar shorthand: a traditional generative model does the slower, deliberate work of System Two, while Jev is meant to make fast, narrow judgments.

The practical difference is simpler than the label. When you ask a regular LLM whether a message is a complaint or a question, it still works through a text-generation interface and eventually gives you something like a JSON string. Jev takes an unstructured state plus a typed question and returns the decision itself: a choice, a score, or a yes/no probability.

Choice and Score can include a probability distribution and a derived confidence value. Noul does not include that confidence field. None of those numbers is a business accuracy guarantee. They describe the model’s answer distribution; your own labeled examples still have to tell you whether the decision is good enough.

The reported price is $42 per billion input tokens, or $0.042 per million, with no output-token charge because Jev does not generate a long answer. The integration described here used the `jev-latest` route and locked the production test to the `jev-1.13` family.

Why the idea caught fire

The appeal is easy to understand. Modern AI products spend a lot of money asking a full language model to make tiny decisions: is this a bug or a feature request? Is this page about a product? Should this search result be checked first?

Those decisions are often buried inside an agent or an automation pipeline. They happen frequently, they need a bounded answer, and they do not need a paragraph back. Yet the usual solution is to start a full model, tune a prompt, hope the JSON parses, and wait hundreds of milliseconds or a couple of seconds.

The engineering argument for Jev is that the decision space is narrow enough to optimize. A restricted set of possible answers can make the decoding path very short. That is useful even if the neural network underneath is not magically new.

The phrase “hallucination-free” needs a firm translation into engineering language. A model can return a perfectly valid member of `['bug', 'feature']` and still choose the wrong one. Type safety protects the shape of the answer. It does not protect you from a bad judgment.

Jev and a normal LLM solve different jobs

A normal generative LLM is built for writing, long reasoning and multi-step planning. You give it a prompt and context, then consume a stream of text or parse a generated JSON object. More output usually means more work.

Jev is built for a bounded decision. You describe the state, define the answer type and give the application a value it can switch on directly. The code can consume a native choice, score or probability instead of extracting a value from prose.

That change in interface has a useful side effect: it forces you to write down the decision you were previously hiding in a vague prompt. Once the categories and boundaries are explicit, you may discover that a plain rule handles the easy cases and Jev only needs to see the ambiguous remainder.

Where we connected it in ShipSite

We kept the integration deliberately boring. Jev sits behind two small assist paths, and neither path is allowed to execute an action.

The first path handles vague site-change requests. If someone says “make the background white,” the existing rules can identify the intent. Only requests that stay ambiguous after the deterministic checks are sent to Jev. It returns a hint such as “style change” or “copy change.” The interface may show that hint, but it never turns the label into a code-execution instruction.

The second path labels search-term candidates during research planning. ShipSite can produce up to 24 long-tail candidates at a time. A local CLI helper sends the leftover cases to Jev in a batch and tags them as competitor, informational or transactional terms. Those tags only influence later ordering.

The rule is straightforward: use code first. Length checks, regular expressions, prefix matches and known dictionaries run locally. Jev sees only the samples that survive those checks and still need a semantic judgment.

The guardrails were the feature

The integration was safe enough to merge because the model was boxed in. The assist flag was limited to one internal account and named test workspaces. External users and production tenants never entered the path.

The main model was not replaced. Authentication and permission checks were not replaced. Payments, deletion, production approval and other sensitive flows never called Jev. Inputs containing credentials or private text were dropped before any network request. If the feature was off, the credential was missing or the caller was outside the allowlist, the number of outbound calls was zero.

The timeout was fixed at 1,000 milliseconds. A timeout meant “fall back,” not “retry until it works.” The local adoption threshold was 0.9, but that was our policy cutoff, not a claim that Jev is 90 percent accurate. Anything below it went back to the old logic. A separate `JEV_DECISION_MODE=off` switch could disable the cloud path globally.

The test budget was capped at $5 for 30 days, with only the Jev 1.13 family enabled and no automatic top-up. When the budget ran out, the fallback stayed in charge.

if deterministic_rule_matches(input):
    return existing_result
if sensitive(input) or mode == "off":
    return fallback()
answer = jev_decide(input, timeout_ms=1000)
if answer.confidence < 0.9:
    return fallback()
return display_only_hint(answer)

What the tests did — and did not — show

The release checks reported 42 out of 42 new tests passing, 134 out of 134 upstream regression tests passing and 6 out of 6 independent QA probes passing. Full Node tests, type checking, the build and production smoke tests also passed for the release described in the source report.

For model behavior, the offline run used 48 frozen synthetic examples. Forty-five labels matched the expected type. Two low-confidence results were safely rejected, and one very short input was filtered before it reached the model. That is a useful safety story, not a production accuracy number.

A follow-up API acceptance run had 22 model-eligible examples match and two examples diverted by deterministic rules. The report also makes a valuable admission: no natural ShipSite workflow had produced a real hit yet. There was no attempt to turn a test run into fake production traffic.

Those details are why I would keep the results in context. They show that the integration and its fallbacks behaved as designed. They do not establish how Jev performs on your customer data.

Good fits, bad fits

Jev is a good candidate for branch routing, early semantic cleanup, lightweight intent hints and bulk labeling of things such as search terms or ticket titles. In each case, the answer space is known and the next step can be inspected.

It is a poor fit for code generation, long causal reasoning, writing, email drafting or multimodal output. It should never be the final authority for a payment, a database drop or a production permission change. A 0.99 confidence value cannot replace a deterministic business rule where the cost of a mistake is high.

And if a regular expression or dictionary solves the problem cleanly, keep the rule. Adding a network dependency because a model is new is not an architectural improvement.

The takeaway

Every so often, the AI world packages a useful local improvement as a total paradigm shift. Jev is more interesting when you keep the claim smaller. Many high-frequency decisions do not need a full generative model. Pulling those decisions into a cheap, low-latency, typed component could become a practical building block for agent systems.

It is still not a cure-all. A valid type does not remove blind spots, and millisecond latency does not replace deliberate reasoning.

If your system is spending its budget on thousands of tiny intent, routing or labeling calls, Jev is worth a sandbox experiment. If you want it to write the content or own the keys to your core business, it is the wrong tool. Write the rules first, test the ambiguous remainder, and keep the model behind a switch you can turn off.