Jev Model Explained: API, Pricing and What's New in 1.14

Updated October 24, 2026: added Jev 1.14, now served as jev-latest.

The Jev model is TypeSafe AI's System One Model: it takes a text or JSON state plus typed questions and returns typed answers instead of prose. Call it with model: "jev-latest" — now Jev 1.14 — at $0.042 per million input tokens, output free, 64K tokens per request.

That makes Jev useful for sorting support tickets, ranking search results, checking claims and gating risky actions. It does not replace a chat model, coding model, calculator or a deterministic business rule.

The Jev model explained at a glance

The official spelling is Jev, not an acronym written out as J-E-V. TypeSafe says it named the model after economist William Stanley Jevons. The “System One” label draws on the fast, intuitive System 1 described in Daniel Kahneman's Thinking, Fast and Slow.

What's new in Jev 1.14?

Jev 1.14 (jev-1.14.0) has been the stable release since October 14, 2026, and both jev-latest and jev-preview now resolve to it. The price and the default limits stay where they were; the news is two experimental features you switch on per request.

TypeSafe puts both new features behind “danger zone” headers. Send TypeSafe-Danger-Zone-Images: true to accept image assets and the new Box question type, which answers with coordinates in an image. Send TypeSafe-Danger-Zone-Long-Context: true to lift the window to 262K tokens per request and per question; it is off by default, so nothing changes unless you ask for it. TypeSafe's release post (checked October 24, 2026) says to use both at your own risk, and we have not tested either header through OmniaKey.

A request that pins jev-1.13.0 still works, and the default body is the same as before: state, questions, and an optional model. Switching back is a one-line change, so run your own cases on 1.14 before you move production traffic.

What does Jev actually do?

Think of Jev as a probabilistic semantic function:

unstructured or structured state
  + predefined questions and answer spaces
  -> typed decisions and probability distributions

An ordinary LLM is optimized to continue a sequence and generate strings. Even with JSON mode, your application still asks a generative model to compose an answer. Jev gives up free-form generation. The caller defines the available output shape first, and the model evaluates every question against the same state.

TypeSafe describes its training method as Reinforcement Learning for Calibrated Decisions (RLCD). Its objective is not merely to select an answer, but to produce probabilities whose confidence tracks accuracy across groups of predictions. Calibration is statistical: a probability of 0.8 should correspond to roughly 80% accuracy across comparable cases. It does not guarantee that one specific answer is correct.

Choice, Score, and Noul

Jev exposes three question types. They are the core of the API, not formatting options added after generation.

A Choice can contain up to 255 options. A Score accepts 2 to 10 descriptive levels. Noul has no separate confidence field because its 0-to-1 value is already the probability of “yes.”

Multiple questions in one request are evaluated independently and in parallel against the same state. That is useful when a workflow needs several signals, but it also means one answer does not automatically condition another. If question B depends on question A, your code should make that dependency explicit.

A Jev API request

This shortened example sends the request shape TypeSafe's docs show through OmniaKey. One support message is sorted into a department, a frustration level and an urgency flag in a single call.

curl https://api.omniakey.com/v1/alpha/search \
  -H "Authorization: Bearer $OMNIAKEY_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "state": "My payouts have failed for three days and I am losing sales. Please help now.",
    "model": "jev-latest",
    "questions": {
      "department": {
        "type": "choice",
        "instructions": "Which team should handle this?",
        "criteria": {
          "billing": "Payments, invoices, or refunds",
          "technical": "Bugs, outages, or integrations",
          "sales": "Pricing, upgrades, or new accounts"
        }
      },
      "frustration": {
        "type": "score",
        "instructions": "How frustrated is the customer?",
        "criteria": ["Calm", "Frustrated", "Very angry"]
      },
      "is_urgent": {
        "type": "noul",
        "instructions": "Does this message convey urgency?"
      }
    }
  }'

The response keeps the same question IDs. department returns one of the three allowed strings plus a distribution across all three. frustration can be fractional because it is the probability-weighted position across the supplied levels. is_urgent returns only the probability of yes.

The exact values will vary with the input, criteria, and model version. Your code, not the model, decides what probability is high enough to act on.

Jev versus an LLM and a classifier

Jev occupies a useful middle ground, but the differences matter.

Calling Jev “just a classifier” misses its request-time flexibility. Calling it “a faster LLM” misses that it cannot generate an explanation, draft an email, write code, or invent a new answer outside the options you supplied. Liquid AI's d1 models make the same kind of bounded decisions and also ship as open weights; see the Liquid AI d1 API review.

JSON mode is a different thing. JSON mode constrains the syntax of generated text. Jev constrains the answer space itself and returns the full distribution used for the decision. That is valuable, but only when the problem can be expressed as bounded questions.

Jev API pricing

TypeSafe lists Jev 1.14 at the same price as 1.13: $0.042 per million input tokens, or $42 per billion. Output is free “too cheap to meter,” although responses still report output-token usage.

These are arithmetic examples, not invoice measurements. They exclude retries, preprocessing, another model in a cascade, storage, engineering work, and any future pricing changes.

Jev context window and rate limits

Two limits apply at once: all state and questions together must fit within 64K tokens, while the state plus the single longest question must fit within 32K. More context is not automatically better. TypeSafe's own jaggedness guide says irrelevant detail causes accuracy to fall.

The published 250,000 tokens/s and 1,200 requests/minute limits are account limits, not a per-request speed promise. TypeSafe explicitly warns that they are changing dynamically during early access.

These are TypeSafe's direct limits. An OmniaKey account can have its own access, price and rate limits. For a complete request, response fields, Python/Node.js clients and error handling, use the Jev API integration guide.

How strong is the speed claim?

TypeSafe reports 70–500 ms end-to-end response time and says Jev can be 40–200x faster than frontier models on “System One shaped” queries at comparable intelligence. Its launch materials also highlight a workflow evaluation where Jev was 193.6x faster and 444.6x cheaper.

Those numbers are vendor results, not a neutral benchmark. TypeSafe discloses several important caveats:

1. The published latency runs were generally made from company laptops on the US West Coast, where the service was based.
2. The workflow tasks were made by TypeSafe's model-capabilities team, so selection bias may exist.
3. The reference answer averaged GPT-6 Astra and Fable 5.1, which can favor those model families.
4. Competing LLM calls came through OpenRouter and TypeSafe's structured wrapper.
5. TypeSafe calls the 193.6x and 444.6x results the high end of expected real-world gains.

The right conclusion is narrower: Jev's constrained output and parallel evaluation create a credible path to very low latency and cost for bounded decisions. They do not prove that Jev is 40–200x faster on every task, equal to a frontier LLM in general intelligence, or better at work that requires generation and multi-step reasoning.

“Zero hallucinations” needs a precise definition

TypeSafe markets Jev as unable to hallucinate. The defensible part is schema safety: a Choice answer cannot invent a fourth option, and the service should not return prose where your code expects a number. TypeSafe says this output matching is guaranteed by construction rather than measured empirically.

But a type-correct answer can still be semantically wrong. TypeSafe's own Jev 1.13 documentation lists failures involving:

• literal readings and missed implied intent;
• unreliable counting, arithmetic, dates, and numeric precision;
• multi-hop indirection;
• long state containing irrelevant detail;
• adversarial or prompt-injected content;
• contradictory instructions and criteria;
• probabilities that do not obey intuitive identities across separately phrased questions;
• any task that requires text generation.

So the practical claim is zero out-of-schema generation, not zero decision error. Production code still needs evaluation data, conservative thresholds, deterministic validation, and an escalation path.

Where Jev fits well

Jev is a strong candidate when all three conditions hold: the answer space is bounded, the judgment is semantic rather than mathematical, and another piece of software will consume the result.

It is a poor default for writing, summarization, code generation, open-ended extraction, exact arithmetic, date comparison, or long causal reasoning. Use normal code for exact logic and a generative or reasoning model when the output itself must be created.

A production checklist

1. Keep deterministic work in code. Parse dates, count items, calculate money, and enforce permissions without a model.
2. Ask atomic questions. Split “Should we approve this request?” into the independent facts that decision actually depends on.
3. Describe every limit. Add other or none when a Choice is not exhaustive, and write concrete Score levels.
4. Test on your own distribution. English is the primary training language; TypeSafe says other languages, including CJK scripts, are not equally accurate.
5. Calibrate actions, not just predictions. Use different confidence thresholds for reversible UI changes and high-impact automation.
6. Pin a version after tuning. jev-latest can move. Log the versioned response ID and migrate thresholds deliberately.
7. Escalate uncertainty. Send ambiguous cases to a person or a slower reasoning model instead of forcing a decision.
8. Measure accepted-task cost. Include retries, false decisions, human review, and downstream LLM calls, not only token price.

Is Jev available through OmniaKey?

Yes. Jev is live through OmniaKey as jev-latest, and that alias runs Jev 1.14 today: we pass it straight to TypeSafe, so a new release reaches you without a new integration. You do not need to apply for TypeSafe early access or wait for waitlist approval. Create a scoped key in the API Keys dashboard and use it immediately; the Jev 1.14 model page lists the current catalog entry.

Send the native Jev body to POST https://api.omniakey.com/v1/alpha/search. This is a dedicated Jev endpoint, not an OpenAI Chat Completions one, so keep the state and questions structure shown above. Our September 20 smoke test returned HTTP 200, the resolved model jev-1.13.0, typed answers, and token usage; the same request today resolves to jev-1.14.0. For open-ended coding and agent work, the coding-agent model guide covers the generative models that fit a different part of the stack.

Final verdict

The Jev model, explained in one sentence, is best understood as a new interface for semantic decisions, not as a universal replacement for an LLM. Its most compelling idea is simple: let a model handle fuzzy judgment, force the output into a type your program understands, expose uncertainty, and keep composition and exact logic in code.

The current API is unusually inexpensive on paper, and the architecture is designed for low latency. The model is also in early access, text-only by default, strongest in English, and openly listed as weak on math, dates, indirection, irrelevant context, and adversarial input. Treat the speed and intelligence comparisons as vendor claims until matched independent tests exist.

Frequently asked questions

Is Jev an LLM?

TypeSafe calls Jev a System One Model rather than an LLM. It understands natural-language state, but it does not generate free-form text. TypeSafe has not disclosed enough architecture detail in the sources reviewed here to independently settle how closely its underlying network resembles a conventional language model.

Can Jev replace GPT or Claude?

No. Jev cannot write, explain, code, or perform open-ended generation. It can complement a generative model by sending requests to the right place, checking outputs, scoring answers, or deciding when a slower model should run.

What do Choice, Score, and Noul mean?

Choice selects from a closed set and returns all option probabilities. Score places the state across 2–10 described levels. Noul returns the probability that a yes/no statement is true.

Does Jev really have zero hallucinations?

It cannot generate a value outside the declared answer type, which eliminates a major class of parsing and schema failures. It can still choose the wrong valid option or assign a misleading probability. Type safety is not semantic correctness.

How can I access the Jev API without a waitlist?

Create an OmniaKey API key, then send the native Jev request body to POST https://api.omniakey.com/v1/alpha/search with model set to jev-latest. No separate TypeSafe account or early-access approval is required.

How much does the Jev API cost?

TypeSafe lists Jev 1.14 at $0.042 per million input tokens, with output currently free. Direct prices and rate limits can change during early access.

Which version does jev-latest use?

Jev 1.14 (jev-1.14.0). jev-preview points to the same build right now, and jev-1.13.0 still works if you pin it in the request.

Does Jev support images or Chinese?

Text is the default: strings, JSON objects and arrays must ultimately contain text. Jev 1.14 adds image assets behind the TypeSafe-Danger-Zone-Images: true header, which TypeSafe marks experimental. Chinese and other CJK scripts are accepted, but TypeSafe says English is currently strongest and tells developers to test other languages on their own data.

Is Jev free to use?

The checked direct model price charges input tokens at $0.042 per million and makes output tokens free. Free output does not mean a free request. Trials, promotional credits and gateway billing have their own conditions; verify the account offer rather than assuming every user receives a free allowance.

How big is the Jev model in parameters?

TypeSafe's model page (checked October 24, 2026) lists context and input formats but no parameter count. The 64K and 32K figures are token limits, not numbers of model parameters. Do not infer weight size or local hardware requirements from them.

Primary sources

• TypeSafe: Jev 1.14 release post (checked October 24, 2026)
• TypeSafe: Introducing System One Models & Jev
• TypeSafe documentation: Introduction
• TypeSafe documentation: System One
• TypeSafe documentation: Models and pricing (checked October 24, 2026)
• TypeSafe documentation: HTTP API reference
• TypeSafe documentation: Confidence
• TypeSafe documentation: Jev 1.13 jaggedness

Prices, limits and the Jev 1.14 details were rechecked on October 24, 2026. The gateway smoke test stays dated September 20; this update is not a new paid test. Jev is changing quickly, so recheck the versioned model ID and account conditions before production use.