The cost of a decision: a language model vs Jev

Start with the list price, because it is the only figure that comes with no benchmark attached. TypeSafe's models page lists Jev at $0.042 per million input tokens, and output tokens are free [1]. DataCamp, an independent explainer, puts that input rate at 1/48th of GPT-5.6 Terra's $2.00 per million input tokens [2]. Divide 2.00 by 0.042 and you get 47.6, so the fraction holds. That is the whole of the public price list. Everything else on this page is a benchmark, and a benchmark is a claim by whoever ran it.

Three published comparisons, and who ran each

The first is TypeSafe's own. MarkTechPost reports the headline figure: Jev finished a workflow decision in 0.114 seconds for $0.000081, against GPT-5.6 Terra at 8.566 seconds for $0.013880, which TypeSafe states as "193.6x faster and 444.6x cheaper" [3]. Two qualifications travel with it. TypeSafe's own capabilities team wrote the workflows, and TypeSafe says it cannot prove the price is unsubsidised [3]. DataCamp reports a second TypeSafe workflow-level figure, $0.0004 per case for Jev against $0.0304 for Terra, from TypeSafe's internal evals [2]. The two TypeSafe figures differ by five times on Jev's side, which tells you the cost of a decision depends on how much text is in it.

The second is Openlayer's. Openlayer released jevals, an open library that runs agent evaluations and guardrails as one Jev request per trace, and published its own benchmark: a Ragas evaluation on GPT-4.1-mini uses six language-model calls plus embeddings per sample and costs $2.60 per 1,000 samples, taking 22 to 35 seconds for 20 samples; jevals on Jev uses one request per sample at $0.03 per 1,000, taking 0.8 seconds for 20 samples [4]. Openlayer built a product on Jev, so the benchmark is a builder's benchmark.

The third is LangChain's. LangChain tested Jev as a judge of agent output on five weather-agent cases, 100 repetitions per judge, 500 decisions per judge in total. The full run cost $0.34 with Jev and $28.17 with Claude Sonnet 4.6, and Jev's per-call cost was $0.00035 at 0.44 seconds per call [5]. The authors call the results "promising, but early" and say five cases cannot tell you why. LangChain also released an integration package for Jev, so this is a builder's benchmark too.

We are Reveneau, and we use Jev as the grader in our own eval suite. Our suite runs ten times faster than it did with a language model grading it. That is a statement about run time on our own suite, and it is the only first-party number on this page. We publish no cost figure of our own, because ours would be a builder's figure with the same qualification as the three above.

The arithmetic at one million decisions a month

One million is a useful volume because it is where a mid-sized product lands once a decision sits on every ticket, message or document. Here is each published per-decision price multiplied by one million, in dollars per month:

TypeSafe's benchmark: Jev $81, GPT-5.6 Terra $13,880. TypeSafe's internal eval figure via DataCamp: Jev $400, Terra $30,400. Openlayer's benchmark: Jev $30, Ragas on GPT-4.1-mini $2,600. LangChain's per-call Jev price: $350. LangChain's run total divided by its 500 decisions gives $0.056 per decision for Claude Sonnet 4.6, or $56,340 at a million; that division is ours, and the run total may include costs beyond the judge call, so treat it as an upper bound.

The spread on the Jev side, $30 to $400 a month, is the honest number. It comes from the size of the state each benchmark sent. The spread on the language-model side, $2,600 to $56,340, comes from which model each benchmark chose and how many calls it made per decision. Whatever pair you pick, the gap is between two and four orders of magnitude, and at this volume that gap changes product decisions. A feature that could afford to check one thing per message can afford to check thirteen: TypeSafe's own batching cookbook ran 13 questions against a 53,777-character document in one request for $0.000497, against $0.006090 for thirteen separate calls [6].

The arithmetic from the list price alone

If you distrust every benchmark, work from the list price and your own state size. A decision whose state is 1,000 tokens, which is a long support ticket, costs 1,000 tokens at $0.042 per million, or $0.000042. One million of those is 1 billion tokens, or $42 a month. A 10,000-token state, which is a long document, is $420 a month at a million decisions. Output is free, so the question count does not change the price [1]. The per-request limits are 64,000 tokens of context, with 32,000 for the state plus the longest question [1], so a document above that has to be split, and the arithmetic then multiplies by the number of pieces.

Do the same sum for the language model you use today with its list price and your real prompt length, including the system prompt and the output tokens, which are usually the expensive half. The result will be your own comparison, with no vendor in it.

The arithmetic at ten thousand decisions a month

Ten thousand a month is a small product or one feature of a large one. TypeSafe's benchmark figures give $0.81 for Jev against $138.80 for Terra. Openlayer's give $0.30 against $26. The saving is real and it is a few hundred dollars a year. Whether that is worth a migration depends on the engineering cost of the change, which for a feature that already works is usually more than a few hundred dollars. At this volume the case for a decision model is latency or consistency, and the next section is about that.

The arithmetic at ten decisions a day

Ten decisions a day is 300 a month. TypeSafe's benchmark gives $0.02 for Jev against $4.16 for Terra. Openlayer's gives one cent against $0.78. No arithmetic on this page produces a saving worth an engineer's afternoon at this volume. If the feature works today, leave it. If it does not work today, choose the tool on fit, using the sorting rule in which features are System One tasks, and put price last.

Latency is the second price

Cost per decision is one half of the bill. The other half is what a slow decision costs the user. TypeSafe reports Jev at 70 to 500 milliseconds end to end and compares that against 3 to 329 seconds for frontier language models in its own comparison [7]. Openlayer measured a median of 244 milliseconds and a 95th percentile of 371 milliseconds, meaning 95 of every 100 requests came back within 371 milliseconds [4]. LangChain measured 0.44 seconds per call against 2.16 to 2.83 seconds for the language models it tested [5].

The difference matters for one class of feature: a decision inside a request a user is waiting on. A moderation check before a message posts, a routing decision before a page loads, a validation before a form submits. A language model that takes three seconds cannot sit there without a loading indicator. A decision model that takes a quarter of a second can. That is a product capability, and it has no line in the cost table. For a decision that runs in the background overnight, latency is worth nothing and only the price applies.

Where the saving is real

The saving is real when three things are true at once. The decision repeats at a volume where the per-decision price adds up, which means tens of thousands a month or more. The decision fits the model, which means a fixed answer set and a text input. And the feature either does not exist yet or is being rebuilt anyway, so the migration cost is close to zero. When all three hold, the arithmetic above says the saving exceeds the cost of the change in the first month, and the latency lets the feature run where a language model could not.

The saving is also real in a place the cost table does not show: the checks you were not running. At $0.01 per decision a team checks one thing per message. At $0.0001 the same budget checks a hundred. That is why Openlayer's library ships 37 built-in evaluations that run in one request [4], and it is why our own eval suite grades more criteria per change than it did when a language model was the grader.

Where the saving is small

The saving is small at low volume, as the arithmetic shows. It is also small when the language model is doing more than deciding. If the same call that routes a ticket also drafts the reply, replacing the routing with Jev saves the routing cost and leaves the drafting cost, which was most of the bill. Split the call first, then price the halves.

And it is small when the migration cost is high. A feature with a year of tuned prompts, a labelled set built around a language model's outputs, and an escalation flow that reads the model's written reason is a feature where the reason itself is part of the product. Auditability when the model gives no written reason covers what happens to that reason, and it is not free to lose.

What to do with this page

Take your real monthly volume for one feature, multiply it by two figures from this page, one from TypeSafe's benchmark and one from a third party, and write both results down next to the engineering estimate for the change. If the smaller saving is larger than the estimate, run the two-week pilot and let the pilot's own cost per decision replace both figures. If it is not, close this page and keep what you have. The pillar guide has the rest of the decision, and LLM as judge for code review covers the special case where the decision is grading a code change.