How to Use JEV 1.13: From Customer-Service Triage to Agent Routing, a Hands-On Test of This Low-Cost Decision Model

How to Use JEV 1.13: From Support Triage to Agent Routing, Testing a Low-Cost Decision Model#

“A customer says their payment won’t go through, and it’s already affecting business. Who should this ticket go to? How urgent is it? How is the customer feeling?”

This is a common small task in AI products. You may ultimately need only three fields: technical, an urgency probability, and a sentiment rating. These fields determine which queue gets the ticket, where it ranks, and whether it needs priority human attention.

JEV 1.13 is well suited to this kind of clearly bounded decision. Give it context and criteria, and it returns a choice, probability, or score that your program can read directly.

There has been plenty of coverage of JEV lately: some pieces discuss “System One,” others focus on low cost and fast decisions, and some show how to connect it to an Agent workflow. For developers looking to get started, the key questions are which tasks it can take on and how to verify that it fits their business.

This article first explains the model, then walks you through a hands-on test in the [Crazyrouter JEV Decision Playground]playground, and finally provides a Python example you can call directly. The tests in this article were run through Crazyrouter on September 23, 2026; both successful requests and timeouts are included.

What Is JEV 1.13? Start with Its Three Output Types#

JEV is a decision model from TypeSafe AI. The company calls models in this category System One Models: they read the current state and quickly classify, judge, or score it, giving software a basis for actionable decisions.

Its input consists primarily of two parts:

• state: Contextual facts. This could be a customer support message, a document, or a JSON object containing order status.
• questions: The decisions you want the model to make. Each question specifies a type, instructions for making the decision, and any required options or scoring criteria.

The three core question types are:

You can include all three question types in a single request. For example, a support ticket can be assessed for “which department should handle this,” “whether it’s urgent,” and “sentiment level” at the same time. All three results can be used directly by your code.

JEV currently accepts text-based input, including objects and arrays made up of text; it does not directly accept images, audio, or video. Tasks such as writing replies, drafting articles, and generating code should still be handled by generative models. TypeSafe’s System One documentation clearly describes these capability boundaries.

Where Does It Excel? Making Small Decisions Worth Automating#

1. Results Go Straight into Your Program, with Less Interpretation and Conversion#

Suppose you define three departments: billing, technical, and sales.

JEV’s Choice result returns one of those options along with a probability distribution. Your program can read answers.department.choice directly and use the result to select a handling queue.

General-purpose large language models can also classify content using structured output. What makes JEV worth considering is that it puts typed decisions and probability outputs at the center of its interface and is optimized around these tasks.

For systems that process large volumes of messages, documents, or routing requests every day, this specialization has practical value: you can clearly define the classification result, review conditions, and actions to take.

2. Ask Multiple Independent Questions at Once#

A single piece of context often supports several decisions:

• What is the customer asking about?
• Is normal use affected?
• Does this need prompt attention?

TypeSafe’s official documentation says these questions are evaluated independently and in parallel against the same state. The application can therefore get multiple dimensions in one request and combine them in code.

One detail to keep in mind: questions in the same request are independent of one another. If the second step depends on the first answer, have your program read the first result before composing the next request.

3. Low Cost per Input, Suitable for Frequent Calls#

As of this verification, the reference pricing is:

Assuming a total of 1,000 input tokens per request, the input cost is about $0.000042** per request. At 100,000 calls, the input portion would cost about **$4.20.

This calculation uses the reference price. Context, questions, and criteria all count toward the input budget. Check usage in the response for the actual token count, and the usage logs for the final amount charged by this site. You can verify current prices in the Crazyrouter model list.

That means some small decisions that previously weren’t worth making a dedicated call to a large model for could now be added to a product: whether a document is relevant, which topic a piece of feedback belongs to, or whether a request should be handed off to a more capable model.

4. Use Probabilities to Design Handling Branches#

After JEV selects technical, your program can route the request directly if the distribution is highly concentrated. If several options are close, it can gather more information, try another model, or send the request to a person.

However, confidence is not the same as accuracy. It describes how certain the returned distribution is. A result of 0.91 does not mean the decision has been proven to be correct 91% of the time.

The “calibration” emphasized in the official materials must be evaluated against a set of samples with known answers. You should still choose thresholds using your own tickets and criteria. See the Confidence documentation.

Try It in the Browser Before Writing Code#

Open the JEV Decision Playground, or go directly to the Chinese Decision Workspace.

The page includes 12 editable scenarios:

For your first test, choose “Support Ticket Triage” and follow these steps:

1. Get a Crazyrouter API Token from the Token Management page and enter it in the workspace.
2. Keep the default scenario and read through the context and criteria for the three questions.
3. Click “Run Decision.”
4. On the right, review the department selection, probability distribution, sentiment score, processing time, and token usage.
5. Replace the context with your own text, run it again, and compare how the decisions change.

Submitting requests incurs real API charges; the fact that outputs are not billed does not mean the entire call is free. The page states that the token is kept only in the current page's memory and is not written to browser storage.

Running the default Chinese support ticket on the actual webpage produced:

• Department: technical, with a 0.94 probability.
• Urgency probability: 0.97.
• Frustration score: 1.01, corresponding to the three levels “calmly stating the facts / dissatisfied but restrained / extremely angry”.
• Page-reported duration: 0.70 seconds.
• Usage: 467 input tokens and 73 output tokens.

The actual returned version was typesafe/jev-1.13-20260917. This was the result of a real webpage call; probabilities and duration may vary when you run it again.

The page also provides “Preview request”, where you can view JSON, cURL, JavaScript, and Python examples. Once the scenario behaves as expected, copying the request into your own product is easier than starting from a blank codebase.

Change the context and see whether the judgment changes#

Running only the default example is not enough to determine whether the model is useful. A more meaningful test is to keep the evaluation criteria unchanged, replace the context, and observe whether the answer changes with the evidence.

We tested 6 different inputs through the same Decisions endpoint. The results were recorded as follows:

These results show several concrete points.

Customer-support classification can handle both topic and tone. Changing the context from “already affecting business operations” to “asking about pricing in advance, not urgent” changed both the department and the urgency probability.

RAG filtering can separate relevance from answerability. A passage may be highly relevant while still being insufficient to answer the question completely. In the example, relevance was close to the highest level, while the probability of being able to answer was 0.80. These two dimensions serve different purposes.

Low cost does not mean that calls cannot fail. The refund case with insufficient evidence produced no result, so we do not add a conclusion that “the model correctly chose to investigate”. Nor can we determine from a timeout alone whether the problem was with the model, the upstream service, or the network path.

This round included the initial test, two retries, and one webpage call: 9 requests in total, 6 successful responses, and 3 read timeouts. The reported upstream charges for the six successful responses totaled $0.000115962. This excludes settlement for the timed-out requests, which was not verified, and is not the complete amount actually charged to this site's account.

The sample was small, and the inputs were manually written demonstration cases. This is an onboarding and connectivity test; it cannot be used to calculate general accuracy or guarantee service stability.

How should “hundreds of times faster” and “no hallucinations” be understood?#

TypeSafe's official launch article states that, under its test conditions, end-to-end responses took 70–500 milliseconds. The homepage's claims of 193.6x speed and 444.6x cost advantage come from evaluations of specific workflows. The official material also explains that these gains are toward the higher end of what is seen in real applications, and describes how the internal workflows and reference answers were constructed.

These figures help explain the product's direction, but they cannot be applied directly to your network, data, or entire Agent workflow.

The successful Python calls in this test took 0.675–5.413 seconds; one webpage call displayed 0.70 seconds, and read timeouts also occurred. These durations include the call path from the local environment to the gateway and upstream service, so they are not the same metric as the model's own computation time. This test did not compare the speed of other models on the same questions.

“No hallucinations” also needs to be interpreted within its stated scope. The official explanation emphasizes that the output types and predefined answer space are constrained: if the candidates are three departments, the model will not arbitrarily generate a new department name.

A valid option does not mean that the option is necessarily correct. The model may still misclassify a billing issue as a technical issue, or produce a concentrated probability distribution around an incorrect judgment. Before deploying this in production, keep a test set with known answers, examine the error types, and then determine which judgments can be automated.

How can developers integrate it? Use the Decisions API#

This test confirmed the public model name jev-1.13 in Crazyrouter's /v1/models; the webpage uses typesafe/jev-1.13, which also ran successfully. Successful responses provide the parsed actual version.

The test used:

Site: https://crazyrouter.com
Endpoint: POST /api/alpha/decisions
Model: jev-1.13
Authentication: Authorization: Bearer <Crazyrouter API Token>

JEV uses a dedicated Decisions endpoint. It is not intended for calling /v1/chat/completions or /v1/responses after changing model to JEV. The endpoint returns synchronous JSON and does not use streaming output.

The following is the complete Python request used in the customer-support test. Install requests first, then configure CRAZYROUTER_API_KEY in the local environment:

import json
import os

import requests

payload = {
    "model": "jev-1.13",
    "state": "I have been trying to connect to Stripe for 3 days, but the integration keeps failing and we are losing sales. Please handle this as soon as possible.",
    "questions": {
        "department": {
            "type": "choice",
            "instructions": "Which team should handle this ticket?",
            "criteria": {
                "billing": "Payment, billing, or subscription issues",
                "technical": "Errors or integration failures",
                "sales": "Pricing or purchasing questions",
            },
        },
        "is_urgent": {
            "type": "noul",
            "instructions": "Does this message express urgency?",
        },
        "frustration": {
            "type": "score",
            "instructions": "How frustrated does the customer appear to be?",
            "criteria": ["Calmly stating the facts", "Dissatisfied but restrained", "Extremely angry or using strong language"],
        },
    },
}

try:
    response = requests.post(
        "https://crazyrouter.com/api/alpha/decisions",
        headers={
            "Authorization": f"Bearer {os.environ['CRAZYROUTER_API_KEY']}",
            "Content-Type": "application/json",
        },
        json=payload,
        timeout=(10, 60),
    )
    response.raise_for_status()
except requests.Timeout as exc:
    raise SystemExit("Request timed out; no judgment was obtained. Check the call record before deciding whether to retry.") from exc
except requests.RequestException as exc:
    raise SystemExit(f"Request failed: {exc}") from exc

data = response.json()
answers = data.get("answers")
if not isinstance(answers, dict) or not all(
    key in answers for key in ("department", "is_urgent", "frustration")
):
    raise RuntimeError("The response does not contain complete decision results. Check the service response.")

print(json.dumps(answers, ensure_ascii=False, indent=2))
print("Actual model:", data.get("model"))
print("Request ID:", data.get("id"))
print("Usage:", data.get("usage"))

The corresponding first API test returned the following key fields; level descriptions and part of the probability distribution are omitted:

{
  "id": "gen-dec-1790095587-mts183W9F0rPWFGshpnx",
  "model": "typesafe/jev-1.13-20260917",
  "answers": {
    "department": {
      "type": "choice",
      "choice": "technical",
      "probabilities": {"technical": 0.94, "billing": 0.06, "sales": 0},
      "confidence": 0.91
    },
    "is_urgent": {"type": "noul", "noul": 0.98},
    "frustration": {"type": "score", "score": 1.01, "confidence": 0.98}
  },
  "usage": {"input_tokens": 467, "output_tokens": 73, "cost": 0.000019614}
}

Two fields here are easy to misread:

Noul 0.98 is the probability of “yes.” If your program ultimately needs a Boolean value, you must set the threshold yourself. 0.5, 0.8, and 0.95 are all possible business choices; select one based on the cost of misclassification and validation samples.

Score 1.01 is the probability-weighted average of the level indices. The three levels in this example correspond to 0, 1, and 2, so the result is close to “dissatisfied but restrained.” Score can be a decimal and does not default to a percentage scale. See the official Score documentation for the precise definition.

Three Business Positions Worth Trying First#

Customer service intake: determine the department and urgency together#

Have JEV read the user's message and known order status, then output the handling department, the urgency probability, and the categories of information that need to be collected. Your program can use the result to build a queue, while a generative model or a human handles the response.

When writing options, distinguish their boundaries as clearly as possible, and reserve an “other” or “needs further verification” option for cases with insufficient information. The refund example is only a recommendation; actual refunds must be executed by your business system according to its rules.

After RAG retrieval: filter out passages that cannot support an answer#

After obtaining candidate documents, you can separately ask “Is this relevant?” and “Can it support the answer?” before deciding which passages enter the final generation context.

If there are many candidate passages, measure the additional cost and latency introduced by the filtering step itself. Whether it saves enough generation input, and whether it incorrectly removes important evidence, must be validated with business data.

Before an Agent tool call: choose the next handler#

Define available actions as Choices, such as “check an order,” “search the knowledge base,” “ask the user,” and “transfer to a human.” JEV selects an action, and the code executes the corresponding workflow.

It is well suited to this type of decision point. See the TypeSafe quickstart for integration methods and additional patterns, and consult the Crazyrouter API documentation for other models and interfaces.

Frequently Asked Questions#

Can JEV directly replace the primary model in Claude Code, Codex, or Cursor?#

No. It does not generate code, carry on continuous conversations, or output tool-calling workflows like a coding model. You can ask a coding Agent to write a classifier or router that uses JEV. The [official coding agents documentation]agents addresses this point specifically.

Does JEV support Chinese?#

The Chinese customer-service case, Chinese problem description, and Chinese RAG passages used in this test all produced valid results. However, these cases are not enough to establish its accuracy across all Chinese-language business scenarios. Domain terminology, long texts, and edge cases require separate testing.

Is the JEV online experience free?#

The Crazyrouter workbench sends real billable requests and requires an API Token from this site. The model's output price is zero, but input is still billed. Do not apply temporary free promotions from other platforms here.

Why does the API response include output_tokens while the output price is zero?#

Output-token measurement and output billing are separate concepts. This successful response included output_tokens, while the reference price for output was zero.

Is it okay to write only “take a look” in the input?#

You should provide enough context and clearly state what needs to be judged. For example, break “Is this customer a good one?” into “Does the customer have a purchasing plan?”, “Does the requirement match?”, and “Is the customer willing to schedule a technical evaluation?” Clearer evaluation criteria improve judgment and make testing easier.

Can I automatically execute every action when confidence is high?#

Do not rely on a single number. First validate the system with cases whose answers are known, then set execution conditions according to the cost of each action. The cost of an error differs between a classification label and an operation such as charging a payment or reserving a phone number, so their thresholds and review workflows should differ as well.

Does a timeout mean that no usage was incurred?#

Not necessarily. If the client did not receive a response, that does not prove the service did not process the request. Check the call and usage records. This report summarizes only the costs of requests for which a response was received; it does not treat timed-out requests as free.

Try It Now with Two Pieces of Your Own Text#

Open the JEV Decision Playground, run the default customer-service ticket first, and then change it to a “non-urgent, routine inquiry.” Keep the same evaluation definition and observe how the department, urgency probability, and sentiment score change.

Then select a set of cases from your real business that already have known answers: include clear, ambiguous, and easily confused examples. If it can reliably take over one category of judgment at an acceptable cost and latency, you have found a worthwhile place to integrate it into your product.

Sources and testing notes: This article was written based on TypeSafe's official releases and documentation, Crazyrouter's current model information, and API and online web requests made on 2026-09-23. The illustrations are screenshots of the actual pages and workflow diagrams. Official performance claims are identified separately; the small-sample results from this test are not intended as a general benchmark ranking.