What Jev Actually Costs

The numbers on the page

TypeSafe publishes pricing for jev-1.13.0 plainly, which is more than many vendors do:

Output tokens being free is not a promotional rate. It falls out of the architecture: Jev cannot emit sequential data, so outputs are computed in parallel rather than decoded token by token. The usage object still reports output_tokens so you can see the shape of what came back; you are just not billed for it.

Four and two-tenths cents per million input tokens is aggressive. For comparison, that is a couple of orders of magnitude below what frontier chat models charge for input alone, before you account for the output side being zero.

The rate limits, and the warning attached

250,000 tokens per second and 1,200 requests per minute are generous ceilings. Divide them and something useful falls out: 1,200 req/min is 20 req/sec, and 250,000 tok/sec across 20 requests works out to roughly 12,500 tokens per request before the token ceiling binds. In practice, if your typical request is a few hundred tokens, the request-per-minute limit is what you will hit first, not the token limit. That changes the optimization: batching more questions into fewer calls helps you, and it is free anyway.

Exceeding either limit returns 429 Too Many Requests. TypeSafe's client SDKs retry with backoff by default and honor retry-after when present. Calling the HTTP API directly means implementing exponential backoff yourself, and the same applies to 529 Overloaded. Worth flagging: TypeSafe uses 529 for overload, not the conventional 503. If you have a generic retry wrapper keyed on 503, it will sail straight past this.

The four documented error codes are 401 (bad key), 422 (validation failure, with the offending field named in the body), 429, and 529.

Now the caveat TypeSafe prints in a warning box on the Models page, which deserves more attention than its placement suggests. The limits above can change without notice. The stated reason is that they are serving very large demand, and they will adjust as GPU capacity lands and more users are let in. Read plainly: these are not contractual limits on the standard plan. Do not architect a system whose viability depends on sustaining 1,200 req/min unless you have that in writing, which means a custom or enterprise plan.

The context budget is the real constraint

64k total per request, and 32k for state plus the single longest question.

That second limit is the one people design around incorrectly. It is not a state budget and not a per-question budget. It is the two summed. A large state paired with one verbose question carrying elaborate structured criteria can breach 32k while the total request sits comfortably under 64k.

So the shape you have room for is: a moderate state, plus many reasonably-sized questions. Not: a huge document, plus anything.

There is a second reason to keep the state small, independent of the limit. TypeSafe documents that accuracy falls as the state grows with content unrelated to the decision, and that unrelated detail acts as a distractor. Filtering in code before you send is not just a cost optimization; it improves answers. Their suggested fallback when you cannot filter structurally is to use a cheap Noul as a relevance gate first.

A worked example

Take a support triage pipeline handling 1,000,000 tickets a month, with the speculative fan-out from TypeSafe's own docs: one Choice for category, one Score for bug severity, two Nouls, one Score for frustration. Five questions in one call.

TypeSafe's published example of a five-question triage request reports input_tokens of 589. Round to 600 for arithmetic, and assume tickets similar in size to theirs.

1,000,000 requests × 600 input tokens  = 600,000,000 input tokens
                                       = 600 Mtok

600 Mtok × $0.042/Mtok                 = $25.20 per month

Output tokens (212 per request in the
docs' example, ~212M total)            = $0.00

About $25 a month to triage a million tickets across five dimensions each.

Two honest qualifiers. First, 600 tokens assumes short tickets; the criteria text is resent on every request, so a richer question set with long option descriptions shifts the per-request floor up. If your questions alone are 2,000 tokens of criteria, that is 2,000 tokens on every single call regardless of ticket length. Second, throughput: a million requests spread evenly over a month is about 23 req/min, comfortably inside the limits. A million in a day is roughly 700 req/min, which is inside the 1,200 ceiling but close enough that bursts will hit it.

The interesting part of that arithmetic is how the incentives sit. Adding a sixth question costs a few dozen input tokens and roughly nothing in latency. The dominant cost is the state, sent once per request. So the efficient design sends the state as few times as possible and asks as much as possible each time.

The claims versus the measurements

TypeSafe's headline benchmark claims, which should be read as vendor claims:

• 193.6x faster
• 444.6x cheaper
• 70-500ms latency

Independent measurement has landed elsewhere. Community medians have clustered around ~7x on speed and ~30x on cost. Both are far below the headline figures.

Neither set of numbers is fabricated. The gap is about the comparison baseline. A vendor benchmark picks the workload and the competitor, and 444.6x is achievable if you compare Jev's free-output pricing against a frontier model generating long structured responses on a task chosen to flatter the framing. Practitioners measuring their own workloads compare against whatever they were actually using, which is often a cheaper small model already doing classification, and against real end-to-end latency including their own network hops.

The right way to hold both: the direction is real and large, the magnitude is heavily baseline-dependent, and you should assume something like the independent medians until you have measured your own workload. A 7x speedup and a 30x cost reduction is an excellent result. It is simply not a 444.6x one, and a guide that repeated the headline unexamined would be doing you a disservice.

The latency range is the claim most likely to hold up for you, because it is an absolute number rather than a ratio. 70-500ms is consistent with the architecture: no autoregressive decode loop, one prefill pass over the state, parallel evaluation of the questions.

What you are not paying for: accuracy

Cost comparisons only mean something at matched quality, so this belongs in a cost post.

On TypeSafe's own four-workflow benchmark, Jev scored 67.8%. On the same benchmark: GPT-5.6 Terra 67.9%, GPT-5.6 Sol 74.1%, Claude Opus 5 73.1%.

Jev came last, by a hair against the cheaper GPT-5.6 tier and by five to six points against the frontier models. On TypeSafe's own benchmark. Publishing that rather than burying it is to their credit, and it clarifies what is actually on offer: parity-at-lower-cost, not superiority.

For most of what Jev is good for, that is the right trade. If you are routing ten million tickets, a five-point accuracy gap against a model costing orders of magnitude more is usually the correct business decision, especially when confidence gating lets you escalate the doubtful cases to the expensive model and recover much of the gap on the cases that matter.

But it does mean the framing "replace your LLM calls with Jev and save 99%" is incomplete. You are also accepting a quality delta, and you should size it on your own task before committing.

The strongest cost evidence remains LangChain's LangSmith evaluation: 500 agent-evaluation decisions, Jev matching human judgment on all 500, with 92-913x lower variance than the LLM-judge baseline, at $0.34 versus $28.17 for Claude. That is roughly 83x on cost, above the community median and below the vendor headline, on a task shaped exactly like what Jev is built for. It is the most credible single data point available, and the variance result may matter more than the price: an unstable judge makes regressions unreadable no matter how cheap it is.

The subsidy question

TypeSafe has been unusually candid here. They have acknowledged that they can't prove the pricing isn't subsidized.

That is the correct thing to say, and it is a real risk you should price in. The company launched September 15, 2026 with a $40M seed led by DCVC at a $200M valuation. $40M is a serious raise and a small one relative to the inference bills implied by "serving a very large volume of demand" at four cents per million tokens with free output. The rate-limit warning about waiting on GPU deals points the same direction: capacity is the binding constraint, and capacity is expensive.

Free output tokens are architecturally justified, and I do not think that part is a loss leader. Parallel computation over a fixed output space genuinely is cheap relative to autoregressive decode. The question is whether $0.042/Mtok on input covers serving cost at their current scale, and nobody outside the company can answer it.

What to do about it, in descending order of usefulness:

• Keep the integration thin. The API surface is three primitives and one endpoint. Wrapping system_one behind your own interface is maybe a day of work and it means a repricing event is a migration rather than a rewrite.
• Know your fallback. If Jev doubled in price, what runs instead? A small fine-tuned classifier for the high-volume path is a realistic answer and worth knowing the shape of.
• Model the 10x case. At $25/month, a 10x repricing is $250/month and you would not notice. If your model is $40,000/month, 10x is a budget event. The right amount of concern scales with your bill, not with the principle.
• Pin the version. jev-latest resolving to jev-1.13.0 today means a future release can shift the distributions your confidence thresholds were tuned against. Send the versioned ID and upgrade deliberately.

Free output changes how you architect

The practical conclusion is not "Jev is cheap". It is that the cost structure is shaped differently from every LLM API you have used, and the habits that were correct there are wrong here.

Under LLM pricing, output is the expensive half, so you minimize what you ask for. Under Jev's pricing, output is free and the state is the dominant cost, and the state is sent once per request regardless of how many questions ride along.

That makes speculative fan-out a rational default rather than a wasteful one. Send the questions you might need, and let your code discard the answers it does not:

category = response.answers["category"]
bug_severity = response.answers["bug_severity"]
refund = response.answers["refund_requested"]
 
if category.choice == "bug_report":
    if bug_severity.score > 1.5:
        escalate_to_engineering(ticket_id, severity="high")
    else:
        add_to_bug_backlog(ticket_id)
 
elif category.choice == "billing":
    if refund.noul > 0.7:
        route_to_billing_with_flag(ticket_id, refund_likely=True)
    else:
        route_to_billing(ticket_id)

On a billing ticket, bug_severity cost a few dozen input tokens and was thrown away. On a bug report, it saved a full round trip. Given that the round trip is 70-500ms of latency plus another full copy of the state at 600-plus tokens, the speculative question pays for itself well below a 50% hit rate. The arithmetic favors asking.

The rules of thumb that follow:

• Ask more questions per call, including ones you will probably discard.
• Send the state fewer times. Two calls against the same state is almost always a design smell; merge them.
• Keep the state tight. It is both the dominant cost and the dominant accuracy risk.
• Watch requests per minute, not tokens per second. For typical request sizes, req/min binds first.
• Retry on 429 and 529 with exponential backoff, and remember it is 529, not 503.