Jev and the Rise of Decision Models: AI That Answers Your Code, Not You

A new kind of AI model cannot call tools, cannot search the web and cannot even talk, and that is exactly the point. Jev takes words in and gives back a decision, the kind of typed judgement a program can branch on without reading a paragraph first.

Why a decision is not an answer

At first glance Jev looks like a downgrade: no tool calls, no web search, no conversation. You type words into it, but what comes back is not words. It makes a decision instead of producing a long, drawn-out answer.

ChatGPT, Claude and similar large language models were built to respond to people in natural language.

The design line behind Jev fits in one phrase from the source: "Jev isn't talking to you. It's talking to code."

Fast judgement and slow reasoning: placing a task on the scale

Figure 1. The fast-to-slow spectrum: decision models occupy the System 1 end, handling high-frequency gut calls so that heavier reasoning models are reserved for complex queries.

The makers call Jev a system one model, a term borrowed from Daniel Kahneman's book Thinking, Fast and Slow. In the source's words, system two is slow, step-by-step reasoning, and system one is the instant gut call. Psychologists describe System 1 as intuitive, automatic and effortless, answering through associations, and System 2 as conscious, slow, deliberate and effortful. Kahneman took the two labels from earlier work by Stanovich and West.

The most useful idea for builders is about frequency: for Kahneman, System 1 handles normal decision making, while System 2, like a supreme court, checks in only on occasion.

The psychology also carries a warning: System 1 produces brilliant inspirations but also systematic errors. Researchers add that not every proposed trait of the two modes maps neatly onto two separate systems, so the split is a metaphor more than a wiring diagram. What counts as a fast task also shifts with expertise: computing 20 × 20 is effortless for a trained economist and effortful for many other people.

Figure 2. Jev’s three output shapes. Every response is one of these typed structures, making the result directly consumable by code without parsing prose.

Critics dismiss decision models as an AI-powered if statement, and the creator concedes they are "not exactly wrong." Example: "Is this support email angry?" passes the gut-call test, while "Why did churn rise last quarter?" fails it and belongs to a reasoning model.

The three response types and how to phrase a question

Jev is limited to three response types: yes or no with a confidence level, a choice among options you supply, and a score such as negative, neutral or positive.

Yes or no fits a gate: "Is this YouTube comment spam?" The reply comes with a confidence level; in the source's first demo, a real comment came back as about 92% true for spam.

Before writing a single prompt, agree on what each outcome means, which errors are costly, and when a person takes over. Template to adapt: Question "Does this message ask for a refund? Answer yes or no." State "the full message text, nothing else." Meaning "yes means a human from billing must reply within the day."

The quiet advantage is that changing the question costs nothing. With Jev there is no retraining: you simply ask a different question. Zero-shot models shine when you have no training data or your categories change constantly, because you can ship on day one and iterate on categories without retraining.

With plenty of labelled data, classifiers trained on that data beat zero-shot LLMs, especially as the number of categories increases. In low-resource settings the picture flips: prompting outperformed fine-tuning for binary and multiclass problems in one comparison. The mature path is to start with a model that needs no training, then graduate to a dedicated classifier once its predictions have built you a labelled dataset.

Running a first decision and testing it before you trust it

The quickest first contact is the Jev playground: the question goes in one box, the material to judge in a state box, and you run it. The result reads as a decision with a confidence level, and the JSON view shows exactly what your code will receive. A demo that looks right on one comment proves nothing, so the method below adds the step most people skip: checking the model against examples whose answer you already know.

🛠 How to — Build a yes/no or score decision call and check it against labelled examples

1. Write the question and the allowed outcomes, then note which error costs more and when a person takes over.
2. Collect a labelled test set from your own data; for comment spam, the public YouTube Spam Collection holds 1,956 real comments from five videos, each tagged spam or legitimate.
3. Run the question and one item of state in the playground, for example asking whether a YouTube comment is spam.
4. Open the JSON view and write down the fields your code will read: the decision and its confidence.
5. If you compare against a general LLM, force it into the same shape with a strict JSON schema so its replies are machine-readable too. text: { format: { type: "json_schema", "strict": true, "schema": ... } }
6. Run the whole labelled set, count false positives and false negatives separately, and check whether high-confidence answers are right more often than low-confidence ones.
7. Put the threshold and the fallback in ordinary code with explicit parameters, sending anything below the threshold to a person or a slower model.

The confidence number deserves suspicion until your test proves otherwise. A decision-oriented model with typed choices and scores does not prove that its scores are calibrated on your data.

Figure 3. Cascade versus pre-generation routing. The router decides model size before any generation occurs, avoiding the cost of the cheap model’s output on queries that will need escalation anyway.

Format and correctness are separate guarantees. Structured Outputs ensures a model always produces responses that follow your JSON schema, with no missing required key and no invented value outside the allowed list. Structured output enforces format, not correctness: a perfectly shaped wrong answer still flows straight into your branch.

Keep a cheap baseline in the comparison. YouTube comment spam is hard even for established methods because messages are very short and full of slang, symbols and abbreviations.

Routing and cost: when a cheap decision makes an idea viable

Cost decides which ideas ever get built. The creator wanted a live teleprompter that ticks off script bullet points as he speaks, but a conventional setup would have cost something like $30 an hour, too much to use for shows.

Example: a teleprompter that checks every few seconds whether the current bullet has been covered makes hundreds of tiny yes/no calls per show, and each one needs a single bit of answer.

Figure 4. Choosing the right tool. Decision models excel at typed, high-frequency judgements; deterministic code and full LLMs handle the cases where output cannot be reduced to a label or score.

Its cousin, cascading, runs increasingly larger models in sequence until a satisfactory answer appears. In the source's router demo, a decision call sized each prompt and sent "Explain BGP" to the medium model. Research favours deciding before generating: a lightweight pre-generation router beat the best cascade policy on four of five datasets, mainly because cascades pay for the cheap model's answer before any escalation.

On price and accuracy, the source ran its own benchmark of decision models on real YouTube comments. Jev came out the clear winner, with OpenAI's Decisions API a close second. Among the cloud options, Jev was also the cheaper one, the OpenAI decision endpoint being 2.4 times more expensive. Around the model, community projects make bigger promises, such as a claimed 40% reduction in coding-agent cost.

Tails matter: one study measured LLM p95 latency between 519 and 2048 ms, against roughly 124 to 207 ms for fine-tuned encoders. Give every candidate the same evidence and include ambiguous and out-of-scope inputs, or the comparison flatters whichever model saw the easy cases.

Pitfalls, and where the claims stop

The first mistake is expecting a chatbot: a decision model cannot call tools, search the web or explain itself in conversation. Investigation, comparing explanations and drafting belong to an LLM, whose conclusions in turn need evidence. Open-ended generation and synthesis across a large context still require a full model, because their output space cannot be listed in advance.

Deterministic code fits when the output can be computed exactly from the input, as in input validation, currency conversion, date arithmetic or configuration-driven routing. If your team can list all the classification logic in one meeting, start with rules and use their failures as future training data. Facts held in a system of record should be queried, never inferred by a model from wording.

Keep the model's role to producing a score or label, and implement thresholds, aggregation and business logic as tested, deterministic code with explicit parameters. That separation makes each part testable and replaceable, cuts unnecessary model calls and keeps the system explainable to an auditor.

The fourth mistake is reading every number as a measurement. The 40% cost reduction for a community coding-agent project is presented only as "the claim." A repository passing 1200 stars in two days measures attention, not accuracy.

The last trap is the sponsored example. The source is sponsored by Twingate, a secure remote access product described as opening no ports and giving a person, a device or AI agents access to only the exact resources you choose, free for home labs. That model is known as zero-trust access: nothing is reachable by default, and each identity gets only what it is explicitly granted.

Precedents, and where decision models are heading

The source draws a parallel with Docker and AWS Lambda, technologies that seemed strange when new and later became routine. AWS Lambda was announced on November 13, 2014, as a service that runs code in response to events, billed only for the requests served and the compute time used. It reached general availability on 2015-04-09. In the meetings that led to it, the word serverless did not yet exist.

What happened next is instructive: established companies, not only startups, jumped in quickly and found ways to build event-driven applications for critical internal uses. The pattern is a small, single-purpose unit, billed per use and triggered by code, that people only understand once they start composing it into larger systems.

The source's bet is that decision models may be in that early moment, before everyone realises what they can do. Early signals exist, such as fast community uptake of projects built around it.

Worth quoting

• A decision model is an if statement whose condition is written in plain language.

Key points

• A decision model returns a typed judgement for code to branch on, never prose for a person to read.
• Every Jev answer is yes/no with confidence, a choice among given options, or a score.
• Changing the question needs no retraining, which is the edge over a classic supervised classifier.
• Keep thresholds and business rules in deterministic code, and use plain rules wherever they can do the job.
• Treat claimed savings, star counts and sponsored demos as claims until you measure them yourself.

Explain it to someone

A chat model is a consultant who writes you a memo every time you ask something; a decision model is the bouncer at the door who just nods yes or no, and says how sure he is. You don't ask the bouncer to explain the club, and you still check now and then that he lets in the right people.

Test yourself

Q. Why is a schema-enforced JSON reply not enough to trust a classifier?
A. Structured output guarantees that every key and allowed value is present and valid, but it enforces format, not correctness, so the answer can be well-shaped and wrong.

Q. Why did a pre-generation router beat cascades in the research on LLM cascades?
A. Cascades pay for the cheap model's generation before deciding to escalate, while a router sends hard queries straight to the larger model and skips that cost.

Q. When should you keep a plain rule instead of any model?
A. When the output can be computed exactly from the input by a known procedure, such as input validation, date arithmetic or configuration-driven routing.

Open questions

• How should code handle the cases where the model's confidence is low or its decision is simply wrong?
• Does the claimed 40% reduction in coding-agent cost hold up under independent testing?
• Will decision models become standard infrastructure the way serverless functions and containers did?
• Are a decision model's confidence scores calibrated on a given team's own data, beyond the benchmark they were shown on?
• How well does the clean split between fast and slow thinking actually map onto real cognition, and therefore onto model design?

Go further

1. When to Use Rules, Decision Models, and LLMs — A clear table of when to use rules, decision models or LLMs, and what each candidate does not prove.
2. Structured model outputs — Official documentation on forcing a model to follow a JSON schema, with the exact setting to enable strict mode.
3. SE-ML | Separate Deterministic and Probabilistic Concerns — Engineering guidance on keeping thresholds and business logic in deterministic code around a model.
4. Is Escalation Worth It? A Decision-Theoretic Characterization of LLM Cascades — Research showing why routing before generation tends to beat escalating cascades on cost and quality.
5. Cost-Aware Model Selection for Text Classification: Multi-Objective Trade-offs Between Fine-Tuned Encoders and LLM Prompting in Production — Production comparison of fine-tuned encoders and LLM prompting on accuracy, latency tails and cost at a million requests.
6. UCI Machine Learning Repository — A public labelled set of real YouTube comments to benchmark any spam decision before trusting it.
7. Classification Systems: When to Use Rules, ML, or LLMs — A practical decision guide on rules, traditional ML and LLMs, including when to graduate from one to the next.
8. scholar.harvard.edu