Jev AI API Reference
Three question types, one typed answer, calibrated confidence on every response. The API surface is small because the model does exactly one thing.
Jev AI in one call, one typed value
A Jev AI request carries two things: the material to judge, and the shape of the answer. The response carries two things back: a value inside that shape, and a calibrated probability. There is no streaming, no partial output, no token accounting on the way out, and nothing to parse. If you have written code that retries a language model because it returned prose around its JSON, that code has no job here.
Choice
One option from up to 255Routing, classification, triage, picking a category or an action.
Example question: Which department should handle this support ticket?
Score
A position on a 2 to 10 level scaleSeverity ranking, quality grading, priority assignment.
Example question: How urgent is this incident, on a 1–5 scale?
Noul
A yes/no probabilityBinary gates, eligibility checks, policy and safety decisions.
Example question: Does this submission violate the content policy?
Working inside the Jev AI limits
255 options is a design constraint, not a bug
A Jev AI Choice can hold up to 255 alternatives. In practice, any taxonomy that large is already hard for a human to apply consistently, and the fix is the same one you would use for a person: split it. Route coarsely first — which of eight departments — then ask a second, narrower question inside the winner. Two calls in series still land well under a second end to end.
Scales of two to ten levels
A Score returns a position on a scale you define, with between two and ten levels. Resist the urge to use the widest scale available. Ten levels of severity means ten boundaries you have to define well enough that they are reproducible, and most teams cannot articulate the difference between a 6 and a 7 in their own words. Five is usually plenty; three is often better.
Probabilities, not booleans
A Noul question looks binary but does not return a boolean. It returns the probability that the answer is yes, which means the answer and its certainty are the same number. Where you put the cut is a product decision, and you can move it without touching the model — a stricter moderation policy is a threshold change, not a retraining run.
Jev AI latency and throughput in practice
70–500ms
Response Latency
$42
Per Billion Tokens
20–200×
Faster Than LLMs
$0
Output Token Cost
The 70 to 500 millisecond band is wide because the work scales with how much context you send, not with how much comes back — output is a single value in every case. A short classification with a paragraph of context lands near the bottom of that range; a long document with a ten-level scale sits nearer the top.
What that unlocks architecturally is inline placement. A judgement that takes several seconds has to be queued, which means a job runner, a status field, and a way to show the user that something is pending. A judgement that takes a fifth of a second can sit directly in the request path, and an entire layer of infrastructure stops being necessary.
It also changes how freely you call Jev AI. When each check costs a fraction of a cent and returns before a page finishes rendering, validating every step of an agent loop stops being an optimisation problem. The interesting constraint moves from budget to schema design — which is a much better place for it.
Two operational notes follow from that. First, retry logic looks different: there is no malformed response to recover from, so the only failures you handle are transport failures, and a plain exponential backoff covers them. Second, caching pays off more than you would expect — identical context against an identical schema is deterministic enough that a keyed cache in front of the call removes a large share of traffic in pipelines that re-evaluate the same items. Neither is exotic; both are worth wiring in before volume arrives rather than after.