How to Use Jev: Build Fast AI Decisions with TypeScript, Codex and Claude Code

A customer writes, “The payment went through, but my order still says pending.” Your application needs to decide where that message belongs before anyone writes a reply. Is this a billing issue, an order-status request, or something that needs investigation?

Jev, TypeSafe AI’s first System One model, is built for decisions like these. You send context and explicitly defined questions. It returns structured choices, scores, and probabilities that your application can use directly.

This guide walks through a small support-triage implementation, explains the three question types, and shows how to work with Jev from Codex and Claude Code. The production recommendations are engineering suggestions; the product details are grounded in TypeSafe’s documentation, checked September 20, 2026.

What is Jev, and where does it fit?

TypeSafe introduced Jev on September 15, 2026. The company describes a model architecture and parallel sampling system trained with Reinforcement Learning for Calibrated Decisions, or RLCD. Its goal is to produce useful decisions for software rather than open-ended prose.

That changes the interface. Instead of asking a model to write an explanation and extracting a label from the response, you define the possible answers first. Jev evaluates them and returns values your code can inspect.

Source: TypeSafe’s Jev launch announcement

My suggested division of work is simple: ordinary code handles exact rules and execution; Jev handles bounded semantic judgments; a generative model handles explanations, writing, and open-ended investigation. Start with one decision where mistakes are easy to observe and correct.

The three building blocks: Choice, Score, and Noul

Choice: select one answer

Use Choice when exactly one option should win: which department handles a request, which topic best describes an article, or which supported workflow fits an instruction. The response includes choice, probabilities for each option, and confidence.

A Choice can contain up to 255 options. Include an other or no-match outcome when your categories do not cover everything. Otherwise, the model must choose from an incomplete menu.

Reference: Choice

Score: place an input on a defined scale

Use Score for a degree of something, such as the impact of a reported problem. Define two to ten ordered levels with concrete descriptions. The returned score is a probability-weighted position and can fall between levels; it is not necessarily a whole number.

For a support queue, “cosmetic inconvenience,” “important workflow impaired,” and “core workflow unavailable” provide a clearer rubric than unexplained labels such as low, medium, and high.

Reference: Score

Noul: estimate whether a condition holds

Use Noul for a yes/no proposition. It returns a value from zero to one representing the probability of yes. There is no separate confidence field. A value near 0.5 indicates uncertainty about the proposition, not a moderate amount of the property.

Ask “Does the customer explicitly request a refund?” rather than combining refund intent, eligibility, and approval into one question. Those are different decisions.

Reference: Noul

Before you start: access, pricing, and limits

Get a TypeSafe API key from the dashboard. The launch announcement describes early access; check your account rather than assuming registration alone enables requests.

Create or manage your TypeSafe API key

At the time of writing, the model documentation lists jev-1.13.0 at $0.042 per million input tokens, with free output tokens. It accepts text, including text represented in JSON. The limits are 64K tokens across state and all questions, with a separate 32K limit for state plus the longest question.

Published throughput limits are 250,000 tokens per second and 1,200 requests per minute. TypeSafe explicitly says these may change. The jev-latest alias currently resolves to jev-1.13.0; pin a version when evaluating or deploying threshold-dependent behavior.

Current model IDs, pricing, and limits

For a rough budget, assume a complete request uses 2,000 billable input tokens. One million such requests would cost $84 at the listed input rate: 1,000,000 × 2,000 ÷ 1,000,000 × $0.042. This is an illustrative calculation, not a measured workload. Retries and larger questions increase usage.

Build a support-triage example in TypeScript

The following example uses the documented HTTP endpoint directly, which makes the request contract visible. It returns a proposed queue and a refund-intent flag. It does not execute a refund or contact a customer.

Use Node.js 20 or newer. In an existing TypeScript project, install tsx as a development tool if you do not already have a runner:

npm install --save-dev tsx typescript @types/node
export TYPESAFE_API_KEY="YOUR_TYPESAFE_KEY"

Keep the actual key in your server environment or secret manager. Do not commit it or expose it through a NEXT_PUBLIC_ environment variable.

type Department = "billing" | "technical" | "other";
type JevResponse = {
  model: string;
  answers: {
    department: {
      type: "choice";
      choice: Department;
      probabilities: Record<Department, number>;
      confidence: number;
    };
    refundRequested: { type: "noul"; noul: number };
  };
};

const apiKey = process.env.TYPESAFE_API_KEY;
if (!apiKey) throw new Error("Missing TYPESAFE_API_KEY");

const response = await fetch("https://api.typesafe.ai/v1/systemone", {
  method: "POST",
  headers: {
    Authorization: `Bearer ${apiKey}`,
    "Content-Type": "application/json",
  },
  signal: AbortSignal.timeout(10_000),
  body: JSON.stringify({
    model: "jev-1.13.0",
    state: {
      ticket: {
        subject: "Payment captured, order pending",
        message: "My payment went through but the order is pending. Please help.",
      },
    },
    questions: {
      department: {
        type: "choice",
        instructions: "Select the team best suited to handle ticket.message.",
        criteria: {
          billing: "Charges, payment status, invoices, or refund requests.",
          technical: "Software defects or integration failures unrelated to payment status.",
          other: "No listed team fits, or the request lacks enough information.",
        },
      },
      refundRequested: {
        type: "noul",
        instructions: "The customer explicitly asks to receive money back in ticket.message.",
      },
    },
  }),
});

if (!response.ok) {
  throw new Error(`TypeSafe request failed: HTTP ${response.status}`);
}

// A TypeScript assertion is not runtime validation.
// Add a runtime response schema before production use.
const result = (await response.json()) as JevResponse;
const department = result.answers.department;

// Illustrative threshold only: evaluate it on labeled tickets.
const minRoutingConfidence = 0.8;
const queue =
  department.choice === "other" ||
  department.confidence < minRoutingConfidence
    ? "manual-review"
    : department.choice;

console.log({
  model: result.model,
  proposedQueue: queue,
  confidence: department.confidence,
  refundRequestProbability: result.answers.refundRequested.noul,
});

npx tsx triage.mts

The code is an original tutorial example based on the documented API. It has not been exercised against a live TypeSafe account here. Your response values may differ; evaluate actual decisions rather than expecting a particular confidence number.

HTTP request and response reference

If you prefer the official SDK, install @typesafe-ai/sdk. Its TypeSafeClient reads TYPESAFE_API_KEY from the environment, and systemOne infers answer types from the question helpers. The JavaScript documentation includes the minimal client example.

Official JavaScript and TypeScript SDK

Why input design matters more than a clever prompt

The state field holds the material being evaluated. Named fields such as ticket.message, order.status, and policy make relationships easier to follow than a long concatenated prompt. Questions describe what to decide about that material.

Each question sees the same state but is evaluated independently. A question cannot use another answer from that same request. If the next judgment requires a newly fetched order record, first retrieve that record, then issue the next request with the needed evidence.

How to structure state

In the tutorial, the customer’s statement is evidence of what they reported. It is not proof that a payment settled. In a real implementation, fetch payment status from your database or provider before applying business rules.

Ask independent questions together

A triage workflow might need the department, urgency, refund intent, and whether troubleshooting steps are present. These can be evaluated in one request when they depend on the same evidence.

TypeSafe calls this speculative fan-out: ask potentially useful branch-specific questions up front, then consume only the relevant answers. A bug-severity result should be ignored when the request concerns an invoice. Additional questions still consume input tokens, even when they add little latency.

Pattern: speculative fan-out

Use confidence without confusing it with correctness

Choice and Score confidence summarize the shape of their probability distributions. A concentrated distribution gives higher confidence; a spread-out distribution gives lower confidence. A confidence of 0.8 is not automatically an 80% guarantee that your complete workflow is correct.

Treat the example’s 0.8 routing cutoff as a starting hypothesis. Label representative tickets, evaluate several cutoffs, and compare routing errors with the number of cases sent to review. Different categories may need different settings.

Understanding probability and confidence

I would initially run the classifier in shadow mode: keep the existing queue assignment, record Jev’s suggestion, and compare them with human-reviewed outcomes. This lets you learn whether the categories are useful before the model changes anyone’s workload.

How to use Jev with Claude Code

TypeSafe provides an official Claude Code plugin containing its integration skill. Install it from your terminal:

claude plugin marketplace add typesafe-ai/skills
claude plugin install typesafe@typesafe-ai

Inside Claude Code, invoke /typesafe:typesafe-ai. The skill helps the agent design questions and implement TypeSafe workflows; it does not automatically transfer Claude’s reasoning to Jev.

Official TypeSafe skill repository

How to use Jev with Codex

From your project directory, install the skill through skills.sh and select Codex when prompted:

npx skills add typesafe-ai/skills --skill typesafe-ai

Installation is project-local by default; add -g for a global installation. Ask Codex to use the TypeSafe skill. If it does not load, verify the selected agent and restart the session.

For updates, use npx skills update for a skills.sh installation. Claude Code plugin users can update the typesafe-ai marketplace and the typesafe@typesafe-ai plugin. Avoid installing duplicate copies through multiple methods.

Installation, invocation, and update instructions

Give your coding agent a concrete assignment

My suggested brief is to identify one repeated classification in the repository, define its inputs and allowed answers, and build a small evaluation set before integration. Ask the agent to keep question definitions together, implement a timeout and review fallback, and report mistakes by category.

For the support example, add examples with mixed billing and technical symptoms, messages without a clear request, and misleading customer assertions. Require the integration to return a recommendation rather than perform financial operations.

Building an integration versus calling Jev during agent work

There are two distinct uses. A coding agent can write application code that calls Jev at runtime. Alternatively, you can implement a script or tool that lets the agent ask Jev bounded questions during a task.

For the second approach, a candidate experiment is filtering retrieved documentation before the agent investigates an issue. Keep filenames, source links, and rejected-candidate counts visible so you can detect important evidence being filtered out. Any speed or cost benefit needs measurement across the complete task.

What Jev should not decide on its own

TypeSafe’s limitations page warns about counting, arithmetic, date comparisons, irrelevant context, indirect questions, and adversarial text. It also says Jev is not trained for text generation.

Compute totals and date windows in code. Keep authorization in your application. Use a generative model when the required result is a reply, explanation, or new code. A valid category can still be incorrect, and input designed to manipulate classification can influence the answer.

Documented limitations of Jev 1.13

For a bilingual product, I recommend evaluating Arabic, English, and mixed-language messages separately. TypeSafe identifies English as its strongest language; a successful English demo is not evidence of equivalent performance on your customers’ Arabic messages.

Read the launch benchmarks carefully

TypeSafe reports 70–500 ms response times and substantial cost advantages for decision workloads. Its headline 193.6× speed and 444.6× cost figures come from company-designed workflow evaluations, and the announcement describes those gains as likely near the higher end of real-world results.

Those evaluations use reference probabilities from Astra and Fable rather than independent ground-truth labels. The announcement also notes that measurements largely came from the US West Coast, near the service. Measure latency from your own deployment region and accuracy on your own tasks.

Benchmark methodology and caveats

A practical path from prototype to production

• Choose one bounded decision: start with a queue label or relevance flag.
• Write category definitions and a no-match outcome before collecting results.
• Build a labeled evaluation set, including ambiguous and misleading inputs.
• Compare against the current implementation on the same examples.
• Track end-to-end latency, billable input tokens, errors, and review volume.
• Pin the model and version your questions so regressions can be traced.
• Validate responses at runtime; handle service failures separately from uncertainty.
• For direct HTTP calls, implement bounded retries for transient failures and respect Retry-After on rate limits.
• Use review as the fallback when the service is unavailable or evidence is insufficient.
• Roll out gradually, with a way to disable model-driven routing.

For a NestJS backend, I would place the TypeSafe call behind a small service with a narrow input contract. A controller or worker can request a triage recommendation, while existing business services retain responsibility for updates and external actions. Use BullMQ if delayed processing fits the experience; use a bounded synchronous call only when the user actually needs the immediate decision.

The most useful first experiment

Pick fifty real, appropriately sanitized tickets. Write down which queue each belongs in. Include cases you disagree about, then clarify the category rules before tuning the model.

The question to answer is whether Jev reduces unnecessary work: fewer misrouted tickets, less time spent categorizing, or less unnecessary context passed to a larger model. A fast API response matters when it improves that complete workflow.

Jev makes a small unit of semantic judgment easy to call from software. The quality of the surrounding application still comes from choosing the right question, supplying the right evidence, and deciding what should happen when the answer is uncertain.