Fan-out: why asking Jev many questions at once is cheaper
TypeSafe’s documentation puts it in one line: Jev ingests the state once and evaluates every question against it in parallel. That sentence is worth money, and most Jev cost calculators ignore it entirely.
The maths
You are billed for input tokens: the state plus the question definitions. So for one item with S state tokens and N questions of Q tokens each:
N calls → N×(S + Q) = N×S + N×Q
The difference is (N−1)×S. You pay for the item’s own tokens once instead of N times. When the state is large relative to a question — which is the normal case, because a support ticket is long and “is this urgent?” is short — this dominates the bill.
A 500-token item with 60-token questions
| Questions | One call | N calls | Saved |
|---|---|---|---|
| 1 | 560 tok | 560 tok | 0% |
| 2 | 620 tok | 1,120 tok | 45% |
| 4 | 740 tok | 2,240 tok | 67% |
| 8 | 980 tok | 4,480 tok | 78% |
| 16 | 1,460 tok | 8,960 tok | 84% |
At four questions you are already cutting the bill by roughly 70%. At sixteen it is over 85%. You also make (N−1) fewer requests per item, which matters against the 1,200 requests-per-minute limit far more than it matters against the token limit.
Where it stops
Two ceilings. The whole request — state plus every question — must fit in 64k tokens, and the state plus the single longest question must fit in 32k. TypeSafe also documents accuracy shifting as the state grows, so a giant state with thirty questions bolted on is not automatically the right answer. Batch, then measure.
TypeSafe calls the aggressive version of this speculative fan-out: including questions you might not need, because the marginal cost of one more question is just its own tokens, and branching in your own code afterwards is free.
Put your own numbers into the calculator →
Behaviour and limits from docs.typesafe.ai/models, checked 2026-09-21.