Jev use cases work best when the model owns one narrow judgment and your code owns the workflow. Give it the text needed to answer a question, define the allowed answer shape, then validate and act on the result. The examples below are application designs, not independently measured benchmarks.
What can you build with Jev?
1. Support ticket classification
Input: A customer says their payment integration keeps failing.
Model decision: Choice: choose billing, technical, sales, or needs_review.
Application action and boundary: Route the ticket to a queue, while retaining a manual review path. A complaint can span two teams: define the primary-team rule or ask separate questions.
2. Content moderation
Input: A comment and a short, explicit community policy.
Model decision: Noul: estimate whether the comment violates a particular rule.
Application action and boundary: Send uncertain cases for review; record which rule was assessed. Quotation, sarcasm, and adversarial text can change the judgment. Do not treat a model score as the entire moderation policy.
3. Sales inquiry relevance
Input: An inquiry plus the product’s documented target use cases.
Model decision: Score: assess fit using ordered descriptions such as unrelated, partial fit, and direct fit.
Application action and boundary: Prioritize an inbox for human follow-up. Missing context is not proof of poor fit; avoid inferring personal characteristics or letting a score determine eligibility.
4. Search result reranking
Input: A query and a passage already retrieved by your search system.
Model decision: Score: assess how directly the passage answers the query.
Application action and boundary: Sort candidates in code, with a separate relevance question per passage when helpful. Jev does not fetch the documents, and a long irrelevant state can reduce accuracy.
5. Citation support checking
Input: A claim and the exact source passage being cited.
Model decision: Choice: supported, contradicted, or not enough evidence.
Application action and boundary: Flag weak citations before a generated answer is shown. This checks support within the supplied text; it does not prove that the source itself is true.
6. Agent and tool routing
Input: A user request, available tool descriptions, and application context.
Model decision: Choice: choose an allowed tool, ask for clarification, or take no action.
Application action and boundary: The application checks permissions and arguments before execution. A model choosing a tool never grants permission to run it. Include an explicit route for unsupported requests.
How do you choose the question type?
Use Choice for mutually exclusive alternatives, Score for ordered descriptive levels, and Noul for a yes/no criterion. For example, one ticket can produce a department Choice and a separate urgency Noul. Keep the two decisions separate instead of forcing urgency into a department label.
What should stay in code?
Authentication, exact arithmetic, date comparison, document retrieval, and side effects belong in conventional code. Define an allowed output set and verify it before acting. Save the response model ID and evaluate a labelled sample of your own data before choosing thresholds. A confident answer can still be wrong.
How should you estimate cost?
Measure usage.input_tokens on representative calls, including your actual questions. Multiply the mean by expected request volume and the current input-token rate. An illustrative 1,000-token request costs $0.000042 at the checked rate; 100,000 such requests cost $4.20, excluding the rest of your application.
Continue reading
Overview · Pricing · Get started · Limitations