Jev vs LLMs: when to use TypeSafe AI.

A quick comparison

Both columns describe current, documented capabilities. Schema validity -- whether a response parses into the shape you asked for -- is a separate question from decision correctness -- whether the value inside that shape is the right one. Neither approach solves the second problem for you.

Sources: Introduction, Patterns, and Confidence. LLM structured-output behavior described here reflects OpenAI's and Anthropic's current publicly documented features, not a claim about every provider.

One task, two approaches

Take the same support message from the message-routing recipe and route it to one of the same five departments two ways.

Approach 1: an LLM with a bounded structured-output schema

A JSON Schema with an enum constrains the department field to one of the five allowed values. In strict mode the provider guarantees the response validates against that schema -- application code does not need to defend against a string outside the enum. It does not by default return a probability or confidence alongside the choice.

// Illustrative example using OpenAI's Structured Outputs (Responses API).
// The department list mirrors the same five categories used in the Jev example below.
import OpenAI from "openai";

const openai = new OpenAI(); // reads OPENAI_API_KEY

const message = "Hi, I was charged twice for my subscription this month. The two charges show up on my card statement on the 3rd and the 4th. Can you refund one of them?";

const response = await openai.responses.create({
  model: "gpt-6-astra",
  input: [
    { role: "system", content: "Classify the customer message into exactly one department." },
    { role: "user", content: message },
  ],
  text: {
    format: {
      type: "json_schema",
      name: "department_routing",
      schema: {
        type: "object",
        properties: {
          department: {
            type: "string",
            enum: ["billing", "account", "technical", "sales", "other"],
          },
        },
        required: ["department"],
        additionalProperties: false,
      },
      strict: true,
    },
  },
});

// Structured Outputs guarantees the JSON matches this schema -- no retry-on-parse-failure loop needed.
const message_ = response.output.find((item) => item.type === "message");
const content = message_?.content[0];
const { department } = content?.type === "output_text" ? JSON.parse(content.text) : { department: null };

// Your code decides what to do with the parsed value -- same shape of decision as the Jev example,
// but no probabilities or confidence come back with it.
if (department) {
  console.log("Route to " + department);
}

Approach 2: Jev with the Choice primitive

This is the exact file used by the TypeScript guide and the message-routing recipe, so it can never drift from what those pages show. Every Choice question returns a probability per department and a derived confidence value alongside the winning choice, without a schema to author.

// Recipe: Route a message — classify a customer message into a department with Jev.
// Requires Node.js 20+ and TYPESAFE_API_KEY in the environment.
//   npm install @typesafe-ai/sdk
// Generated from the same code path as the live example on /recipes/message-routing;
// see scripts/generate-recipe-examples.mts. Not executed against the live API by this guide.
import { choice, TypeSafeClient } from "@typesafe-ai/sdk";

const client = new TypeSafeClient(); // reads TYPESAFE_API_KEY, defaults to jev-latest

const message = "Hi, I was charged twice for my subscription this month. The two charges show up on my card statement on the 3rd and the 4th. Can you refund one of them?";

const { answers } = await client.systemOne({
  state: message,
  model: "jev-latest",
  questions: {
    department: choice(
      "Which department should handle this customer message?",
      {
        billing: "Charges, invoices, refunds, payment methods, subscription costs",
        account: "Login, password, profile, permissions, closing or changing an account",
        technical: "Bugs, errors, outages, integrations, something not working",
        sales: "Pricing questions, plan comparisons, upgrades, purchasing for a team",
        other: "Anything that does not fit the departments above",
      },
    ),
  },
});

const { choice: result, probabilities, confidence } = answers.department;

// Your code decides what to do with the answer.
if (confidence < 0.5) {
  console.log("Unsure. Route to a person.", probabilities);
} else {
  console.log("Route to " + result + " (confidence " + confidence.toFixed(2) + ")");
}

Both snippets end at the same kind of decision point: application code branches on a typed value. The LLM version needs an enum and a parse step to get there safely; the Jev version gets a fixed shape plus a probability spread it can use to decide when to defer to a person, with no schema to author. Both are illustrative walkthroughs of request shape, not measured results -- this guide invents no confidence value for the LLM example, since producing one would need explicit prompting and still would not be the same kind of distribution-derived statistic Jev returns.

Is Jev just another way to get structured output?

At the application boundary, yes, there is overlap: both approaches can hand your code a typed value it can branch on. Where they differ is design intent. TypeSafe's introduction frames the problem this way: general-purpose LLMs “are designed to produce text for humans to read,” so using one for a decision your code consumes means “coercing a text-generation system into outputting structured decisions, then parsing the results back into something your code can depend on.” Jev is built the other way around -- the primitives (Choice, Score, Noul) are the interface, and TypeSafe documents patterns like sending many questions, including speculative ones, against one shared state in a single call.

What we will not claim here: TypeSafe does not publish the exact internal architecture behind Jev, and this guide has no independent way to verify it. Vendor marketing has described the approach in terms like parallel generation, but that is a vendor characterization, not something this guide can confirm or restate as fact -- and it is a different claim from saying Jev cannot be wrong.

Confidence and probability outputs are also easy to over-read. TypeSafe's confidence documentation describes it as a statistic derived from the shape of the probability distribution, not a guarantee that the chosen answer is correct; calibration, where TypeSafe discusses it, is qualified as a group-level property rather than a per-answer promise. A high confidence value and a correct answer are correlated at best, not the same thing -- for either approach.

Which tasks should you consider?

A rough sort, not a rule. Many real systems combine more than one of these in the same request path.

Cost and latency: how to compare fairly

Input size, how many questions you ask per call, which model you compare against, and how many retries or fallbacks your code performs all move the number more than the choice of Jev versus an LLM does on its own. Comparing a single Jev classification call against a long reasoning-model response and calling the difference a general speed advantage is not a fair test -- it mostly measures that the two calls were asked to do different amounts of work.

As of TypeSafe's published pricing on 2026-09-20, Jev bills $0.042 per million input tokens, with output tokens free. A single Choice call like the one above sends roughly a hundred to a few hundred input tokens (the message plus the department descriptions) and returns no billed output -- at that pricing, ten thousand such calls cost well under a dollar in TypeSafe usage alone. A comparable LLM structured-output call adds a system prompt and a JSON Schema to the input, and bills a small amount of output for the JSON payload, at that provider's own per-token rates. This is an illustrative walkthrough of the calculation, not a benchmark this site has run -- pricing, rate limits, and model choice all change the real number, so re-derive it with current prices and your own token counts before budgeting.

Before trusting any comparison, including this one, check:

• A representative set of labeled examples from your own traffic, not a handful of easy cases.
• Task quality on those examples -- not just whether the response parsed.
• End-to-end latency as your application experiences it, including retries.
• Cost per completed workflow, not cost per call -- a cheap call that fails often is not cheap.
• How often either approach falls back to a person or a default, and what that costs.

When you should keep your current approach

• Deterministic rules already solve the problem correctly -- a model adds cost and variability without adding accuracy.
• The application needs generated text, not a decision -- that is squarely an LLM's job.
• The decision needs substantial reasoning, multiple steps, or context that is not fully supplied up front.
• Your existing quality and cost are already acceptable -- “different” is not the same as “better” for your workload.
• The migration effort outweighs a benefit you have not yet demonstrated on your own data.

Short FAQ

Can Jev replace ChatGPT?

No, not as a general assistant. Jev does not generate free text and is not a conversational product -- it answers typed questions over context you supply. It can replace the specific LLM calls in your application that are really bounded decisions, while a general-purpose LLM (or a product like ChatGPT) keeps handling open-ended conversation and writing.

How is Jev different from LLM structured outputs?

LLM structured outputs constrain a text-generation model's response to a schema you define per call. Jev's primitives are the interface itself, with a fixed response shape per primitive and, for Choice and Score, a probability distribution and confidence value included by default. See the comparison table above.

Can Jev make mistakes?

Yes. A valid, schema-matching response is not the same as a correct one. TypeSafe documents that Jev can select the wrong option from an allowed set, and describes known weak spots such as arithmetic, dates, and long irrelevant context. Treat any single answer as a judgment to weigh, not a fact.

Can I use Jev alongside an LLM?

Yes -- this is a common shape, not an exception. A typical pattern is an LLM drafting a reply or summary, then Jev checking a bounded property of that output (see the reply-checker recipe), or Jev routing and scoring a message before an LLM ever sees it.

Sources and verification

• Introduction -- what Jev is and how System One models differ from text-generation LLMs.
• Quickstart -- first-request shape, also covered in this site's getting-started guide.
• Primitives: Choice -- request/response shape for the routing example above.
• Confidence -- how it is derived, and why it is not a correctness guarantee.
• Patterns -- Speculative Fan-Out, Confidence-Gated Routing, Composite Scoring, and Intent Routing.
• Models -- pricing and limits cited in “Cost and latency” above, retrieved 2026-09-20.
• Introducing System One Models & Jev -- TypeSafe's own launch post; its performance comparisons are vendor-run and workload-specific, which is why this guide does not restate them as general speed or cost claims.
• OpenAI's Structured Outputs documentation -- syntax for the LLM example above, checked September 2026.

Jev Guide is an independent resource, not affiliated with or endorsed by TypeSafe AI. Both code examples on this page are illustrative: the Jev example is type-checked against the pinned SDK but not executed live, and the LLM example is unexecuted pseudocode checked against provider documentation. Neither example's output values are measured results. Reviewed against the sources above in September 2026; TypeSafe's pricing, rate limits, and model lineup can change without notice -- check the official documentation for current numbers before budgeting.