Jev vs Decisions API vs BAML Compared

Jev vs Decisions API vs BAML compared comes down to one question: do you need a probabilistic switch statement, or a full agent? Jev is a decision model that returns confidence probabilities for a fixed set of options instead of free text, and it fits classifications, boolean checks, and narrow scoring while it fails at compaction, model routing, and long-horizon agent work.

Jev vs Decisions API vs BAML: Which Decision Model Fits

Jev vs Decisions API is a comparison of two hosted decision-model interfaces, with BAML as the self-hosted alternative that constrains any model you already use. A decision model takes unstructured input plus a defined set of options and returns probabilities per option as type-safe JSON, which is a different contract from a general chat model that returns free text.

That contract is the whole point. An LLM output is text you must parse and validate; a decision model output is a fixed shape your code can branch on. The trade is depth: a decision model sees a narrow context and behaves like a switch statement, so it works when a human could make the call from a glance.

Tool	Role	Output contract	Best fit	Main limit
Jev	Hosted decision model	Type-safe JSON with per-option probability	Cheap batched classification, ranking, scoring	No image input
Decisions API (OpenAI)	Structured-output layer on GPT-6 Luna	Same three request buckets	Vision classification, routing checks	Higher input price per million tokens
BAML	Open-source constrained-output library	Schema-typed class you define	Any model, any provider, strict types	You supply the model and infra

Support for the Jev announcement and its request shapes comes from the Jev official announcement, and the three-bucket comparison is drawn from OpenAI's Decisions API documentation. BAML's schema-first approach is documented in the BAML repository. The structural framing also follows Dev Doido do canal do youtube, who covers decision-model tradeoffs in Portuguese.

What Jev Actually Returns, and the Three Request Types

Jev returns a probability for each option you define, not prose, and it does so in three request shapes: choice, predicate, and score. Each shape produces the same type-safe JSON envelope, so your parsing code does not change between them.

The choice request gives the model a list of options with descriptions and returns a confidence per option. A support email classifier with the categories billing, technical, sales, and ambiguous is the canonical example: you can read off which category won and how confident the model was.

The predicate request, which the transcript also calls the null probability, answers a yes/no question. You supply a statement and the model returns the percentage chance of true and false. A filter asking whether a message is urgent, with the criteria spelled out as explicit urgency versus no time pressure, is a straightforward predicate call.

The score request is the least obvious of the three. You give an ordered rubric, such as zero for calm and neutral, one for frustrated but civil, and two for angry or hostile, and the model returns a position on that scale with a confidence value for it. Sentiment triage on inbound tickets is the obvious application.

All three support batching. One request can carry several questions at once, so two predicate checks and one score check can return together. Input tokens are billed for every question; output tokens are not charged.

Why Jev Fits Classification, Ranking, and In-Product Search

Jev fits any decision a person could make from narrow context, which is why classification, ranking, and command-palette search are its strongest uses. The model does not need to understand your whole system, only the option set you hand it.

A command-K menu is the clearest product example. Given roughly 23 navigation destinations and a query like 'cancel my subscription,' a decision model can rank 'Manage payments' first even though the query shares no literal tokens with that page title. A substring search would return the wrong order or nothing at all.

The same call handles feature search. Typing 'remove' surfaces remove-background; typing 'upload' surfaces the image-upload entry. The application code then sorts by returned probability. There is no agent loop and no multi-step reasoning behind the result, just a sort over probabilities.

Inbox classification follows the same pattern. An email client can tag and route messages with a single narrow call instead of a full agent pass, which changes the cost per classified message rather than the quality of the sort.

The limit is context size. A decision that needs deep analysis across a 32k window, or that depends on external state the model cannot see, is outside what a narrow switch statement can resolve.

The Two Viral Jev Use Cases That Break Production

Jev compaction and Jev model routing are the two widely shared patterns that do more harm than good, because both need context the decision model does not have. Each looks reasonable in a demo and degrades silently in production.

Jev compaction breaks prompt caching

Compaction by scoring tool calls and dropping the irrelevant ones edits the message history. On Anthropic models, changing history and tool calls invalidates the prompt cache, which forces a full re-read of the context at input plus cache-write rates. The savings from dropping a few tool calls can be smaller than the cache miss they cause.

The second problem is selection quality. A narrow model checking a read-file call cannot tell whether that file mattered; it sees the operation type, not the reason. A model-driven compaction pass sees the surrounding task and keeps what mattered. An engineer on the Hermes agent project reported that a decision-model compaction trial removed the tool calls from the agent history outright, which means the same result was reachable by deleting them in code.

Jev routing misreads task cost

A router that asks Jev where a request should go is answering a question that needs environment state. 'Go check my email' sounds trivial, but the actual cost depends on whether the environment needs custom connectors, computer use, or a multi-step path. The router cannot see any of that.

Sending a request to a cheaper model that runs longer can cost more than sending it to a capable model that finishes quickly. A stronger model completing a task in about five tool calls can beat a near-free model that loops without finishing. Sticker price is not cost per task.

Model routing remains a hard engineering problem that needs far more context than a single decision call supplies.

Jev vs OpenAI Decisions API: Price, Speed, and Vision

The OpenAI Decisions API and Jev share the same three request buckets, so the practical differences are price, latency, and image input. OpenAI's version exposes predicate, choice, and score under its own naming; the underlying behavior is the same shape of contract.

Price is the widest gap. Jev input runs about four cents per million tokens against roughly ten cents for the Luna-backed version cited in the video, so the OpenAI path is over twice as expensive on input. Both charge nothing for output tokens.

Speed runs the other way in the tested examples. The OpenAI implementation came back around twice as fast as Jev. Treat that as a measurement under one setup rather than a general rule; latency will vary with batch size and load.

Vision is the deciding capability today. The OpenAI Decisions API runs on GPT-6 Luna, which accepts images, so you can classify a picture or scan a page. Jev does not take image input. Vision classification therefore requires the OpenAI path, at least at the time of the video.

Document-type and driving-state examples appear in both, which supports the idea that image support, not the decision contract, is the current differentiator.

Where BAML Fits and When a Full LLM Is the Better Call

BAML is the self-hosted route: it constrains any model you choose to a schema you define, so you keep provider flexibility and pay only your model's rates. It has offered strict structured outputs since before the decision-model releases, and it works across providers rather than through one vendor endpoint.

The trade is operational. With BAML you own the prompt, the model choice, and the infrastructure, and you get type-safe output every call in exchange for that work. With a hosted decision model you get the contract and the pricing model from the vendor and give up the ability to swap the underlying model.

A full LLM with reasoning and tool calls remains the right choice when the decision depends on state outside the prompt. That covers long-horizon agent work, multi-service orchestration, and anything needing more context than a narrow model can hold.

Pick by the shape of the decision: a switch statement for narrow calls, a schema library for provider freedom, and a full model when reasoning or tool use is the actual requirement.

FAQ

• What is a decision model? A decision model returns a probability for each option you define rather than free text. Jev and OpenAI's Decisions API both follow this contract, which makes their output type-safe JSON that code can branch on directly.

• Is Jev cheaper than OpenAI's Decisions API? On input tokens, yes: Jev is about four cents per million against roughly ten cents for the Luna-backed version cited in the video. Both charge nothing for output tokens ($0 per output token on both paths), though the OpenAI path measured faster in the demonstrated examples. (Source video)

• Can Jev do computer use? It can handle a short, well-defined computer-use path such as booking a flight, where each step is a narrow choice. Long-horizon orchestration across many tabs and services needs a full model with broader context.

• Should I use Jev for agent compaction? No. Editing tool-call history to drop entries invalidates the prompt cache on Anthropic models and can remove calls that mattered, so the cost per request can rise while the retained context gets worse.

• Does Jev replace BAML? They solve overlapping problems from different directions. Jev is a hosted decision endpoint with fixed request shapes; BAML is a library that constrains whichever model you already run, which keeps provider choice with you.

• What is the best first Jev use case? In-product search ranking is the fastest visible win. Handing a command menu its full destination list and sorting by returned probability improves results on queries that share no literal tokens with the target page.

• Does Jev support image input? Jev does not accept images as of the video's coverage. Vision classification requires a vision-capable model, which is why OpenAI's Decisions API on GPT-6 Luna covers that case. (Source video)

• How many decisions can one Jev request carry? A single request can batch multiple questions, such as two predicate checks and one score check, and return them together. You pay input tokens for each question and no output tokens ($0 per output token). (Source video)

• Is Jev a good model router? Routing needs environment state that a narrow decision model cannot see, so it tends to send tasks to cheaper models that run longer. A capable model finishing in about five tool calls can cost less per task than a near-free model that loops.

• When should I skip decision models entirely? Skip them when the decision needs deep analysis over a large context, tool calls against live systems, or state spread across many services. Those are full-LLM problems, not switch-statement problems.

Source video