The published numbers
Input tokens: $0.042 per million, listed by TypeSafe as $42 per billion. Output tokens: free. Rate limits: 250,000 tokens per second and 1,200 requests per minute. Context: 64k tokens per request, of which state plus the longest single question can use 32k.
Latency and speed multiples come from the launch post, not the pricing page, and they are vendor claims. TypeSafe reports 70ms to 500ms end to end for Jev against “3 to 329 seconds” for frontier models, and describes the model as “40x-200x faster for the same levels of frontier intelligence.”
Why output is free
There is barely any output to charge for. A Choice answer is one option name, a probability per option and a confidence value. A Noul answer is a single number. Even a call carrying ten questions returns a few hundred bytes.
This changes what your bill responds to. With an LLM, a verbose answer costs more than a terse one. With Jev, the only lever is how much text you send: the state plus the wording of your questions. Asking more questions about the same state costs almost nothing extra, since the question text is short and the state is charged once.
That fact is what makes speculative fan-out practical. TypeSafe’s pattern docs describe sending many questions in one call, “including speculative ones,” and letting your code decide afterwards what was relevant. Questions run in parallel, so adding more “typically doesn’t add any latency to the response.”
Working out your own cost
Count input tokens, multiply by $0.042 per million, ignore output entirely.
Take support ticket triage. A ticket body plus the customer’s plan and order history comes to roughly 400 tokens of state. Five questions with descriptive criteria add another 300 tokens. Call it 700 input tokens per ticket.
At 100,000 tickets a day, that is 70 million input tokens, or 70 x $0.042 = $2.94 per day. About $88 a month at 30 days.
At 1 million calls a day: 700 million tokens, 700 x $0.042 = $29.40 per day.
Check the rate limits before the bill. 1,200 requests per minute is 72,000 per hour, so 100,000 tickets spread over a day sits well inside it, while the same volume arriving in a two-hour window does not. On tokens, 1,200 requests per minute at 700 tokens each is 14,000 tokens per second against a ceiling of 250,000.
The other lever is state size, and it pulls twice. Trimming irrelevant context cuts the bill, and TypeSafe’s build guidance says it improves answers too, since accuracy falls as unrelated content grows in the state. Sending a whole 30-message thread when the last two messages carry the decision is the common version of this mistake.
What the speed claim is measured against
The launch post’s comparison runs Jev against frontier models on System One tasks. What it does not include is a named model list, per-task numbers, hardware, region, concurrency, or whether the frontier baselines were reasoning models spending test-time compute.
That last point explains most of the spread. A 3-second baseline and a 329-second baseline are not the same workload; the second looks like a reasoning model on a long chain. Quoting a 40x to 200x range across both ends is fair as a range and imprecise as a number for planning.
Sean Goedecke’s write-up puts the mechanism plainly, and it is a claim about the technique rather than about Jev specifically: a model that produces all outputs in one pass avoids the decode loop entirely, and “since LLMs ingest all input tokens in parallel, this is way faster than generating the entire structured output.” He adds the cost of that design: “Not being able to use test-time compute at all is a big disadvantage.”
As of 18 September 2026 no independent latency or accuracy benchmark for Jev had been published. Every multiple in circulation traces back to TypeSafe’s own evaluations.
Why independent numbers matter here
Two specific reasons, beyond the general one.
The comparison chooses the task. A model class defined by the tasks it is good at will look excellent on a benchmark of those tasks. TypeSafe’s own jaggedness page lists where Jev 1.13 does badly: arithmetic, counting, date comparison, multi-hop indirection, large states full of irrelevant detail. None of that appears in a latency headline, and some of it is exactly what a classification workload contains.
Latency is a distribution, not a range. “70ms to 500ms” says nothing about the shape between those ends. For anything user-facing, the number that matters is p99 under your concurrency with your state sizes, and that is not a number a vendor can publish on your behalf.
Measuring it yourself before you design around it
Send your real state, at your real length, with your real question count. Latency scales with input, and a 400-token ticket is not a 20,000-token contract.
Record the full distribution rather than an average, and record it under the concurrency you expect rather than one request at a time. Compare against the alternative you would actually deploy, which for classification is usually a small LLM or a fine-tuned encoder rather than a frontier reasoning model.
Then track accuracy alongside it. A model that answers in 90ms and is wrong 8% of the time costs more than a slower one if every error becomes a support escalation. Confidence-gated actions are how that cost gets contained, and the comparison guide covers where each option wins.
FAQ
How much does Jev cost per request?
Multiply your input tokens by $0.042 per million and ignore output, which is free. A 700-token call costs about $0.00003. At 100,000 calls a day that is roughly $2.94 daily, or about $88 a month. State size is the only real lever on the bill.
Are output tokens really free?
Yes. TypeSafe lists output at $0, which is workable because a System One answer is a typed value and a probability distribution rather than generated prose. The consequence for design is that asking more questions about the same state adds almost nothing to either cost or latency.
Is Jev really 200x faster than an LLM?
TypeSafe claims 40x to 200x versus frontier models, with Jev at 70ms to 500ms and baselines at 3 to 329 seconds. Those figures come from the vendor’s own evaluations, and the model list, hardware and task mix are not published. No independent benchmark existed as of 18 September 2026.
What are Jev’s rate limits?
250,000 tokens per second and 1,200 requests per minute. For a workload averaging 700 input tokens per call, the request limit binds first: 1,200 requests per minute consumes about 14,000 tokens per second, well under the token ceiling. Large states flip that around, since a 20,000-token document sent 1,200 times a minute would exceed the token limit instead.
How do I reduce my Jev bill?
Cut the state. Send only the context the current questions need rather than an entire conversation or document. TypeSafe’s build guidance recommends this for accuracy as well, since unrelated content in the state acts as a distractor and degrades answers.
Does asking more questions cost more?
Only the token cost of the question text itself, since the state is charged once per call. All questions in a request are evaluated in parallel, so latency stays roughly flat as you add them. That combination is what makes speculative fan-out worth doing.