Jev pricing: what $0.042 per million tokens really costs

Jev pricing is $0.042 per million input tokens with output tokens free, which means the most expensive single call you can physically make — one that fills the model's entire 32,000-token context window — costs $0.001344. For a support triage workload of 500,000 messages a month, the worked example below lands at $18.90. The interesting question is not whether that is cheap. It is which part of your bill it actually replaces.

Jev pricing in one line, and where it is published

Two independent places list the same price, which is worth checking before you plan around it.

Item	Figure	Where we read it
Input tokens	$0.042 per million	TypeSafe launch post and OpenRouter
Output tokens	Free — $0.00 per million	Both, "too cheap to meter"
Context window	32,000 tokens	OpenRouter listing for Jev 1.13
Released	18 September 2026	OpenRouter listing for Jev 1.13
Measured P50 latency	0.26 s	OpenRouter, best provider, one week
Availability, last 3 days	99.88%	OpenRouter

OpenRouter's listed price does not differ from the vendor's own: both say $0.042 in and $0.00 out, as of 23 September 2026. That matters more than it sounds. Resellers often carry a margin, and a matching price is a small signal that the published rate is the rate. OpenRouter's measured 0.26-second P50 also sits inside the 70ms-500ms end-to-end range TypeSafe claims for itself, measured by someone other than TypeSafe.

Two constraints bound the bill from above. The 32,000-token context window caps a single call at $0.001344, and output being free means a request's cost is fully determined before you send it. There is no runaway-generation failure mode to budget for, because there is no generation.

What 500,000 support decisions a month actually cost

Here is one workload, worked end to end. Every figure below is arithmetic on $0.042 per million input tokens; the assumptions are ours and are stated so you can substitute your own.

• 500,000 inbound support messages a month.
• One request per message, carrying four questions: a Choice for the department, a Score for frustration, and two Nouls for urgency and refund intent.
• State of about 600 input tokens — the message plus the order record it refers to.
• Question block of about 300 input tokens for all four questions and their criteria.
• 900 input tokens per request. No output tokens are billed.

Line item	Tokens per month	Cost
State — 500,000 x 600 tokens	300,000,000	$12.60
Questions — 500,000 x 300 tokens	150,000,000	$6.30
Output tokens	0 billed	$0.00
Monthly total	450,000,000	$18.90

That is $0.0000378 per message, or 3.8 cents per thousand messages, for four judgments on each one. It is also why TypeSafe's docs can say that asking a question you might not need is close to free: a fifth question adds perhaps 80 tokens to each request, which is $3.36 a year across this entire workload.

Scale it however your volumes run. Cost per million decisions is linear in request size, so one table covers every case:

Input tokens per request	Tokens per million decisions	Cost per million decisions
300	300M	$12.60
900 (the example above)	900M	$37.80
2,000	2,000M	$84.00
8,000	8,000M	$336.00
32,000 (context limit)	32,000M	$1,344.00

The lever you control is the shape of the request, not the rate. Because the question block is re-sent on every call, a workload that asks four questions in four separate requests pays for four copies of the state — and the state is two thirds of our example's tokens. TypeSafe's docs put a number on this: batching 13 questions into one call is 11.5x cheaper and 9.6x faster than 13 separate calls, with no change in the answers. That ratio is the difference between $18.90 and something that looks like a real line item, and it is a code-review rule rather than a pricing negotiation. The docs note that coding agents fall into the one-question-per-call habit more readily than people do, which is worth knowing if an agent wrote your integration.

A useful cross-check on the published rate comes from TypeSafe's own Doom demo, where they describe an engineer worrying about making roughly 10 queries a second at a cost of about $7 an hour. At 36,000 queries an hour and $0.042 per million tokens, $7 implies calls in the region of 4,000 to 5,000 input tokens each — entirely plausible for a serialised game state, and consistent with the price they publish.

Jev pricing against a frontier LLM, with the arithmetic shown

The only fair comparison uses prices you can read. We used the same 450 million input tokens and assumed 150 output tokens per call for the structured decision block, because an LLM has to generate its answer where Jev does not. Both LLM rates below come from their OpenRouter listings, read on 23 September 2026.

Model	Posted rate (in / out)	Monthly cost, same workload	vs Jev
Jev 1.13	$0.042 / $0.00	$18.90	—
GPT-5.6 Terra	$2.00 / $12.00	$1,800.00	95x
GPT-6 Astra	$10.00 / $50.00	$8,250.00	437x

Give the LLM its best case as well. Terra posts a cache read rate of $0.20 per million tokens, and the 300-token question block is identical on every call, so it is exactly the kind of prefix prompt caching exists for. Cache the questions and Terra's input falls from $900 to $630, taking the month to $1,530 and the multiple to roughly 81x. Jev has no published cache discount, and needs none: there is nothing left to discount.

Where TypeSafe's 444.6x comes from

TypeSafe claims 444.6x cheaper and 193.6x faster than LLMs, with end-to-end response times of 70ms-500ms against 3 to 329 seconds for frontier models. Those are the vendor's own numbers from the vendor's own workflow evals, and the launch post is careful about what they mean. It says the reference answers are the average of GPT-6 Astra and Fable 5.1, that the workflows were built by its own model capabilities team so "some bias could exist", and — in its own words — that "we expect that these are on the higher end of real world gains".

Our arithmetic says the same thing from the other direction. A flagship-tier comparison lands at 437x on posted prices; a mid-tier one lands at 95x, or 81x with caching. A multiple in the 400s is what you get by comparing against the most expensive models available. It is not wrong. It is just not the number you should put in a business case, because the model you would otherwise have used is almost certainly not a flagship — TypeSafe itself picked GPT-5.6 Terra for its side-by-side demo, calling it "the most comparable at intelligence to Jev on average".

One more detail that cuts the other way: the launch post states the LLMs in its evals run through a System One wrapper that constrains them to structured decisions, which "tends to be slower and more expensive than giving decisions without probabilities". Our comparison assumed the LLM needs no extra input tokens to be forced into the same shape. In practice it would need some. Plan on two orders of magnitude and you will not be embarrassed either way.

The costs that never appear on the token bill

A $18.90 line item makes the token cost a rounding error, which means the decisions that matter are all somewhere else.

• Jev replaces classification spend, not generation spend. If your router classifies with Jev and still answers the customer with an LLM, the reply is where the money goes. The saving is real but it is scoped to the branch, which is the argument we set out in when a decision model beats an LLM.
• The escalation queue is the real variable cost. Every answer below your confidence threshold becomes a person's work. A system that automates 60% of volume has a human bill an order of magnitude larger than its token bill.
• You stop paying for malformed answers. With an LLM you pay output tokens for a response that fails validation and pay again on the retry. TypeSafe claims type errors are mathematically impossible for Jev because the schema match is guaranteed — a claim that, as the launch post notes, one counter-example would falsify.
• There is no exit to self-hosting. Jev is not open source and cannot be run on your own hardware, and OpenRouter lists a single provider for it with no routing alternatives. That is a different risk profile from the open-weight options we covered in LLM cost optimization.
• The price is early-access pricing. TypeSafe says so itself: it "can't prove it isn't subsidized", will "need the long-term to prove the sustainability" of the pricing, and expects it to go down rather than up. Treat that as a stated expectation, not a commitment.

When Jev pricing saves you nothing

If your classification volume is a few thousand calls a day on an already-cheap model, the annual saving is smaller than the integration. Build the thing that is broken instead.

If the output needs to be prose, Jev cannot produce it at any price — it returns typed values, not strings. If a single Choice needs more than 255 options, if a request needs more than 32,000 tokens of context, or if the input is an image or audio, it is outside what the model accepts. And if the judgment genuinely requires multi-step reasoning rather than one fast decision, a cheap wrong answer is the most expensive thing on this page.

There is a last irony worth planning for. TypeSafe named the model after William Stanley Jevons, explaining that it expects machine intelligence to follow coal: steam-engine efficiency raised demand rather than lowering consumption, and "every order of magnitude drop in the cost of intelligence unlocks orders of magnitude more use cases". If a decision costs $0.0000378, your team will start putting decisions in places it would never have considered — and the bill that grows will be the volume, not the rate. That is the number to model when we scope AI engineering work around a decision model, and the one worth arguing about now.