Jev: Keep the Power. Cut the Overhead.

ELI5: give the computer buttons

Imagine an assistant with a blank page. It can write a plan, explain a bug, or produce code. That is what my main AI agents do.

Now imagine an assistant with three buttons: research, change code, or something else. You give it a request. It picks a button and returns numbers describing how strongly the evidence supports each option.

That second interface is Jev. You supply the situation and define the possible answers. It makes a bounded judgment. Your software decides what happens next.

A useful question is whether the next step needs new sources. Writing the research report remains a different job. Jev can help with the first; a generative model handles the second. The System One documentation makes that boundary explicit.

Why this landed on my desk

I run Claude Code, Codex and Grok Build with their strongest configured models and maximum reasoning settings. The cost problem is real enough to deserve engineering attention. Reducing capability by default is not the optimization I am looking for.

The direction in Astra × Fable: Full Power, Less Waste was to remove avoidable work around the models: repeated setup, oversized source loads and mechanical operations that ordinary code can perform. I Love Trios added the third agent to that environment. 3 AIs Hit the Limit documented what happens when shared account capacity runs out.

Jev raises a narrower, useful question: how many steps in that environment need a full generative-model call, and how many only need a well-defined decision?

This is a research guide and an integration proposal. I have not installed Jev into that setup or measured savings from it. The older projections in The Expensive Part Is Remembering were projections too. The current requirement remains maximum capability with evidence that an optimization preserves the result.

What Jev actually is

TypeSafe AI introduced Jev on September 15, 2026. Founder Diogo Almeida describes a model architecture, parallel sampler and training method called Reinforcement Learning for Calibrated Decisions, or RLCD. The stated training target is useful decisions with probabilities that reflect uncertainty. The name Jev comes from William Stanley Jevons; the System One label borrows the fast-thinking idea popularized by Daniel Kahneman. These are TypeSafe's product and research descriptions. Launch announcement.

The distinctions matter:

“Building a Harness with Jev” is LangChain's integration article. Jev is a component you can put inside a harness. It does not replace Claude Code, Codex or Grok Build merely because you install a package.

Nor is this the first time software has used machine learning to classify something. Spam filters, classifiers, rerankers and structured LLM outputs already exist. The interesting proposition is the combination: natural-language questions, a constrained answer space, explicit probabilities, low latency and a low published input price.

If a regular expression or an exact database lookup already answers the question reliably, use it. Jev becomes interesting where the branch depends on meaning.

Why giving up prose changes the economics

A generative model produces a sequence of output tokens. Even when the desired result is a small classification, the interface may involve generating structured text and, depending on the model and settings, additional reasoning. Constrained output already exists for LLMs; returning valid JSON is not a new invention.

TypeSafe's proposition goes further: train for the bounded decision itself and evaluate the answer probabilities in parallel. Its AI primer distinguishes RLHF, which uses human preference feedback, RLVR, which uses verifiable rewards, and its own RLCD decision objective. That explains the intended specialization; it does not prove an advantage on every task.

Input preparation, reading the supplied state and network travel still take time. Jev's design removes a kind of output work. The whole application still has to supply a useful problem.

Three primitives, three different questions

Every request contains state, the evidence to examine, and questions, the judgments to make. State can be text or structured text such as JSON. The caller defines what each question means.

Choice: which option fits?

Use Choice for a category or action selected from a finite set. For a software request, the options might be research, code_change, documentation and other.

Jev returns the selected option, a probability distribution over the options, and a confidence value. The current limit is 255 options. A larger taxonomy needs candidate filtering or multiple stages. Include an escape category when the list might not cover the input; otherwise a closed list still produces a winner. Choice reference.

An illustrative distribution of 0.80 research, 0.15 code change and 0.05 other means the model favors research. Those are example values, not a result I obtained.

Noul: is this proposition true?

Use Noul for a yes-or-no proposition: “Does this request require current external documentation?”

It returns the probability of yes. Near zero means a strong no; near one means a strong yes; near the middle means uncertainty. Noul does not have a separate confidence field. A value of 0.8 for “is urgent” describes the model's belief in that proposition. It does not mean the task is 80% urgent. Noul reference.

This is useful for independent flags: needs fresh sources, mentions a production incident, includes contradictory evidence. Your code can combine them.

Score: where does it sit on a rubric?

Use Score for ordered descriptive levels. A source-quality rubric could define “unsupported assertion,” “relevant but incomplete evidence,” and “direct evidence covering the claim.”

Jev returns a probability-weighted position on those levels. Three levels have indices 0, 1 and 2; the score can fall between them. The current API accepts two to ten levels and also returns the distribution and confidence. Score reference.

A score of 1 can describe certainty about the middle level or a split between the two extremes. Those situations deserve different treatment. Keep the distribution when the distinction matters.

A rubric also has to contain the meaning. Naming a question excellent_evidence does not explain what excellent means. Put the criteria into the instructions and descriptions.

Confidence is useful because you can do something with it

Choice and Score confidence summarize how concentrated their distributions are. That statistic is distinct from the probability attached to one answer. A confidence value of 0.9 should not be read automatically as “this decision is 90% likely to be correct.” Confidence documentation.

Calibration is another concept. Across a well-calibrated population of predictions assigned probability 0.8, the relevant outcome should occur roughly 80% of the time. A single answer is still fallible, and calibration on one workload does not establish calibration on yours. TypeSafe's machine-learning primer.

The engineering benefit is that uncertainty becomes an input to the program. You can route ambiguous cases to a stronger reasoning step, gather missing evidence, or retain the existing workflow.

There is no universal threshold that makes every action safe or every answer useful. Tune against the error you actually care about. A misplaced document in a shortlist and an incorrectly accepted production change have different consequences.

For a first experiment, I would prefer a question with an observable answer and a reversible consequence: whether a document belongs in a research shortlist, for example. That makes mistakes easier to label and the benefit easier to measure.

What a harness with Jev looks like

In Your Agent Doesn't Have a Model Problem, I separated the model from the program that operates it. Jev makes that distinction especially concrete.

The harness prepares a useful state, asks a bounded question, interprets the answer, selects a permitted next step and checks what actually happened. Jev only supplies the judgment in the middle.

Consider a request to investigate a failed build. Ordinary code already knows whether the build failed, which revision ran and which logs exist. There is no reason to ask a model to rediscover those exact facts.

Jev could classify the failure evidence into a known set of investigation paths, or rank candidate documentation for relevance. The selected full-strength agent then investigates and writes the fix. Tests and the required independent review still decide whether the change is ready.

The important optimization is where the decision happens. If the premium agent has already loaded the entire trace and reasoned through the routing question, calling Jev afterward adds a second opinion and more work. It may improve quality, but it has not automatically saved the first call.

To save work, the new component must eliminate a call, prevent unnecessary context loading, avoid a bad retry, or otherwise reduce a measured downstream cost. Drawing another box in the architecture does none of that by itself.

What LangChain already provides

The official TypeSafe integration exposes TypeSafeClassifier, a Runnable returning classification results rather than a chat response. It accepts text, JSON and LangChain messages. Its results separate choices, scores and nouls.

The experimental middleware adds two concrete patterns. ModelRouterMiddleware chooses from configured models using the latest human message and keeps that selection for the run. It is not an automatic reassessment after every tool result. AutoModeMiddleware checks the tools you list and refuses blocked calls through a tool error message. Human approval is a separate mechanism.

Those are useful building blocks for a custom application. They are not a switch that rewires every internal decision in three existing native coding programs. For my environment, the first integration point would be code I already control around the agents.

General-purpose products may use Jev to select a cheaper writing model for simple requests. My first trial would preserve the three maximum-strength workers and test the small decisions surrounding them.

What people are building

The early projects are interesting because they expose different places where a bounded judgment can replace a longer model interaction. They are also days-old demonstrations. Here is what their evidence actually shows.

Browser Use: choose an operation and an observed target. The open-source Jev Ultrafast project turns the page into an indexed set of DOM controls. Jev chooses actions and targets; another model writes text when a field needs it. Code checks whether the target is still valid before execution. Jev does not see screenshots in that normal loop.

Its recorded flight search took 7.073 seconds with 17 Jev requests. The performance report includes inference, typing and browser work in that clock, but excludes setup, initial navigation and the independent final verification. It is a search demonstration, not a completed ticket purchase or a broad browser benchmark. The architecture is more reusable than the stopwatch number.

Stagehand: another browser wrapper around the same idea. Kyle Jeong's September 17 post demonstrates Jev with Stagehand and reports a $0.001 task. That is a creator-reported example, not a cost guarantee for arbitrary websites.

Email triage: a natural first workload. Ryan Vogel reported trying 1,500 of his own emails. The post does not supply a labeled accuracy study. The use case is nevertheless clear: classify subject matter, whether a reply is requested and which queue should receive it. Generating the reply remains a separate step.

Computer use: perception still has to happen somewhere. Andrew Levin's macOS prototype combines OCR, accessibility controls and ordinary preprocessing with Jev's choices. Its large model-cost comparison concerns a narrow decision; the complete step includes capturing and interpreting the screen. That distinction matters when comparing it with a vision-capable agent.

MCP and CLI wrappers: useful packaging. Projects such as jev-mcp expose decision tools to agents. Its extraction pattern is revealing: code finds candidate strings, then Jev selects among them. It has not acquired free-form text generation. These are community integrations; check their ownership, data path and execution behavior separately from TypeSafe's model.

Fast trading decisions are also being demonstrated. Jarrod Watts showed Jev selecting trades on Monad/Kuru. A fast buy-or-sell decision demonstrates integration and latency. The post does not establish profitability or forecasting quality.

The strongest general use cases are less theatrical: queue routing, document relevance, repeated rubric evaluation and bounded decisions inside an existing workflow. They come with clear inputs, a finite answer space and outcomes you can check.

Jev as a judge: promising, with a small evidence base

LangChain's September 20 Jev-as-a-Judge experiment reports stable repeated evaluations and complete agreement with its human binary labels. The corpus contains five frozen weather-agent responses, each evaluated 100 times. That is five distinct examples, not 500 distinct tasks.

The published repository is valuable because it exposes the rubric and implementations. One continuous quality metric averages three Noul probabilities. The LLM comparators produce numeric ratings, so the variance comparison is not a clean experiment isolating model architecture alone. Jev's mean reported call cost was $0.00035 versus $0.00039 for Luna in that workload: a modest cost difference, despite a larger latency difference.

A broader first-party operator report comes from Nexus. On its 469-case comparative subset, Jev decided 58% of cases and made five errors among those 274 decisions. With the old rules handling abstentions, the total was 90 errors; the Sonnet-plus-rules version had 92. Much of the labeling used independent AI judgments and adjudication, with a separate human audit. Comparator thresholds and timing also had limitations.

That illustrates why coverage belongs beside accuracy. A system can look excellent on the cases it accepts while handing the hardest cases to something else. The useful comparison includes that fallback's errors, time and cost.

For my workflow, Jev could help screen traces or flag weak completion evidence for attention. It would not replace a required independent reviewer or turn a model's “done” label into proof that a task succeeded.

The price is small. The accounting still matters.

As checked on September 20, the direct TypeSafe model reference lists $0.042 per million input tokens, or $42 per billion, with output free. Both jev-latest and jev-preview currently resolve to jev-1.13.0. These are dated service details, not permanent guarantees.

Here is simple arithmetic at that input rate. Assume every decision uses 5,000 billed input tokens, including its questions and rubric.

These are calculated examples. They exclude retries, fallback models, browser infrastructure, integration work and the cost of correcting mistakes. A request with a long trace costs more than one with a short ticket.

For a workflow that previously called a frontier judge every time, the simplified comparison is:

Old model cost = N × frontier decision cost

New model cost = N × (Jev cost + fallback rate × frontier decision cost)

Then include infrastructure, retries, maintenance and error correction.

This only describes the work actually replaced. If decision calls represent 5% of total cost, even removing their entire cost cannot save more than 5% of the whole. If Jev is an extra check after the existing call, it initially increases cost.

My subscriptions introduce another distinction. A lower API-equivalent token valuation does not reduce a fixed monthly subscription charge. Less consumption might leave more allowance for useful work or postpone hitting a limit; that requires observation. Any Jev API calls add their own bill.

TypeSafe's launch headlines report roughly 194× faster and 445× cheaper results on selected workflows. The company itself describes those as toward the high end of expected gains. Its workflow evaluation site uses model-consensus reference probabilities and a particular comparison harness. Those figures do not measure my complete three-agent workload.

The metric I want is cost and elapsed time per accepted task at the same quality standard. Price per classifier call is one input.

Your first call, without building a new framework

The direct route uses a TypeSafe account and API key. Access availability is handled through its console. The quick start documents POST https://api.typesafe.ai/v1/systemone, authenticated with a bearer token.

For Python 3.10 or newer, the official SDK supports the following shape. This example is checked against the documentation; I have not run it against the live Jev service. Set TYPESAFE_API_KEY in your environment rather than putting a credential in the source.

pip install typesafe-sdk==0.7.0

from typesafe_sdk import Choice, Noul, TypeSafeClient

with TypeSafeClient(model="jev-1.13.0") as client:
    result = client.system_one(
        state={
            "request": "Find the official SDK retry documentation."
        },
        questions={
            "work_kind": Choice(
                instructions="Which category describes request?",
                criteria={
                    "research": "Find and read external sources.",
                    "code_change": "Write or modify application code.",
                    "other": "Neither category fits."
                }
            ),
            "needs_current_sources": Noul(
                instructions=(
                    "Does request require current external documentation?"
                )
            )
        }
    )

kind = result.answers["work_kind"]
print(kind.choice, kind.probabilities, kind.confidence)
print(result.answers["needs_current_sources"].noul)

The example prints judgments. It neither fetches the documentation nor launches another agent. That next operation belongs to your application.

The raw API response contains the answering model, named answers and usage. Log the returned model version. The response can report output-token usage even though outputs are free and Jev is not writing prose.

For a read-only preparation step, the surrounding control flow could look like this. This is pseudocode: the helpers and thresholds are supplied and tested by the application.

def prepare(request):
    enforce_existing_policy(request)

    route = exact_rule_for(request)
    if route is not None:
        return run_permitted_helper(route, request)

    try:
        answer = classify_with_jev(request, deadline=HELPER_DEADLINE)
        validate_answer(answer)
    except DecisionServiceFailure:
        return existing_full_strength_path(request)

    if answer.choice == "other" or not passes_validated_threshold(answer):
        return existing_full_strength_path(request)

    enforce_helper_policy(answer.choice, request)
    return run_permitted_helper(answer.choice, request)

The threshold represents evidence from evaluation, not an arbitrary constant. Response validation covers the expected schema, allowed choice and valid probability values. Both paths keep their existing verification requirements.

There are other access routes. OpenRouter lists typesafe/jev-1.13. Vercel AI Gateway exposes typesafe-ai/jev through the AI SDK's experimental evaluation interface. Cloudflare documents typesafe/jev. Check each route's schema, effective limits and pricing; a provider-specific decision interface is not automatically a chat-completions replacement.

The official agent skill teaches the integration patterns. Installing it does not create credentials, replace the planner or automatically intercept expensive calls. Use the model directly first, on one well-understood question.

Advanced: make the question set do useful work

The first design improvement is to ask independent questions together. Suppose a document needs relevance, freshness and evidence-quality judgments. Sending its entire body three times repeats work. A shared-state request lets several questions examine the same material. TypeSafe's parallel-questions cookbook demonstrates this pattern.

The independence has a consequence: one question does not see another question's answer. If the second decision requires a newly fetched document, it needs a new state. If all the evidence is already present, you may ask several possible branch questions together and let code use only the relevant result.

Browser Use makes this tangible by asking about possible operation-specific targets alongside the operation itself. The executor selects the compatible target. An answer produced for an unused branch does not authorize an action.

The second improvement is decomposition. “Is this research good?” compresses several judgments into one vague rating. Ask whether the cited source supports the claim, whether a date-sensitive claim has current evidence and whether two sources conflict. Combine those signals with explicit rules. TypeSafe describes this general approach in its patterns guide.

The third improvement is state design. Give the decision the evidence it needs, with provenance and enough surrounding context to avoid misleading fragments. A relevance classifier with no task definition is guessing. A completion classifier with no success criteria cannot know what completion means.

Shared state within a request should not be confused with a cross-request cache discount. Application-level reuse is possible, but the key must include every input that can change the answer: evidence, question, policy and model version. Reusing a decision after any of those changes creates a different problem from paying for a repeated call.

Finally, plan for abstention and failure as ordinary outcomes. A low-confidence decision, a timeout and an invalid request are different events. Keep them visible. The SDK retry controls support bounded retry behavior; the surrounding workflow still needs a fallback and an overall time budget.

Where it breaks, and what should stay in code

TypeSafe's own Jev 1.13 limitations page is essential reading. It documents weak counting and arithmetic, problems with date comparisons, literal interpretation, indirection and irrelevant context. Adversarial instructions inside state can influence answers. Related questions can also produce answers that are not logically consistent with one another.

Use ordinary code for totals, date ordering, exact membership, permissions and invariants. Use Jev where interpreting meaning adds value. Keep authorization separate from its assessment of an action.

The “zero hallucinations” claim has a narrow meaning: the answer is constrained to the declared schema. A valid label can still be wrong. A label named allowed does not establish that a caller has permission to perform the action.

Current direct-service limits allow 64k tokens across the state and all questions, with a separate 32k ceiling for the state plus the longest question. Input is text only. English is the strongest documented language; test the languages you use. Model aliases move, and rate limits can change. Model limits.

The managed service also adds a network dependency and a data destination. Open SDKs do not mean open model weights or local inference. TypeSafe says it does not train on customer requests; that is distinct from its enterprise zero-retention offering. Use the data-handling terms appropriate to the material being evaluated.

None of this makes the model uninteresting. It identifies the questions worth giving it and the responsibilities its caller still owns.

Where I would start with my three agents

My current configuration is Claude Code with Fable 5.1 at max, Codex with Astra at ultra, and Grok Build with Grok 4.6 at xhigh. Those are native settings on different products, not a universal reasoning scale or a guarantee about every backend execution.

I would leave the primary work and required independent reviews there. The candidate experiments sit around them:

My first choice would be optional research-source ranking. Mandatory procedures and required original sources would remain mandatory; Jev would only help select among additional candidates. It is a contained decision with a concrete failure to measure: omitting useful evidence.

The first pilot would run on a labeled replay set with the existing path retained. Separate cases used to tune questions from cases used to judge the result. Split related traces together so near-duplicates do not leak across that boundary.

Then run in shadow mode: record Jev's proposed decisions without letting them change execution. Measure false inclusions, false exclusions, uncertainty, latency and how often its suggestion would actually remove work. Include awkward and adversarial inputs, not only obvious examples.

Only after that would I enable one narrow, reversible path. Keep the same task-quality standard and record fallback work, corrections, retries and rejected outputs. Each decision record should identify the model version, evidence and policy versions, distribution, latency and eventual outcome. Compare cold starts with cold starts and resumed runs with resumed runs. A successful process exit is not an accepted result.

I would stop the experiment if integration overhead exceeds the work removed, or if quality loss merely pushes effort into repair. I would expand it if the full workflow completes the same work reliably with less consumption or delay.

The part worth being excited about

The practical opportunity is more places where software can make a small, context-sensitive judgment without waiting for a long generative interaction. That can improve routing, make evaluations affordable more often, and keep expensive reasoning focused on the work that benefits from it.

It can also lead to far more decisions being made. A cheaper call is an invitation to use it everywhere, which is why the Jevons reference fits. Efficiency per decision and lower total expenditure are separate outcomes.

For my setup, the next useful step is a measured experiment around one repeated decision. The three agents keep their capability. Jev has to earn its place by removing work while preserving the result.