Jev Pricing and API GuideCost, Limits, Examples and Use Cases (2026)

Jev pricing has frontier models sweating: $0.042 per million input tokens, and output tokens are free. That is almost 48 times cheaper than GPT-6 Sol and about 95 times cheaper than Claude Opus 5.5 on input alone, and Jev answers in 70 to 500 milliseconds.

The catch is that Jev never writes a word. TypeSafe built it to make decisions, not text: you send it text or structured data, and it returns a Choice, a Score or a yes/no probability called Noul, ready for your code to act on.

It will not write your month end report. It could make the thousand small calls behind it.

🧸 Explain Jev like I’m 5 ↓

Jev pricing and API: the short answer

What Jev actually is

Most frontier AI models are built around text generation. Even when developers use them for classification or routing, the underlying system is still producing tokens and then being constrained into a structured format.

Our live AI leaderboard lists Jev in its Decision models tab, beside comparable classification and moderation APIs.

Jev starts from a different interface. You provide a state, which can be text or structured text data, plus one or more typed questions. Jev returns values and probability distributions that code can use directly.

For an accounts-payable workflow, the state might include an extracted invoice body, vendor name, purchase-order status and known duplicate candidates. The program could ask three separate questions:

• Choice: Is this an invoice, credit note, statement or something else?
• Noul: Does this document appear likely to be a duplicate?
• Score: How severe is the review exception under a defined three- or five-level rubric?

The software can then route the result using ordinary code.

🧸 Jev explained like you’re 5

Think about a computer looking at information about a box of toys. A general helper such as ChatGPT or Claude can do many different things with that information. It can tell a story about the toys, explain what they are, answer a new question, or write something for you. Jev has a much smaller job: you give it the information, tell it what kinds of answers are allowed, and ask it to make one small decision.

The useful part is that Jev stays inside the answer rules you set. If the allowed toy labels are Car, Ball, Teddy and Something Else, it should not suddenly answer “banana” or write a paragraph.

But staying inside the rules does not mean Jev must be correct. If the object is really a teddy and Jev chooses Ball, “Ball” is still a valid allowed answer. The answer has the right shape, but the decision is wrong.

That is the basic idea behind Jev: a fast decision helper for software that already knows the possible shape of the answer. ChatGPT and Claude are broad helpers you can ask to create or explain many different things. Jev is built for the smaller moment where the software needs a bounded choice, score, or yes/no probability.

Jev is not simply a small chat model with JSON mode. TypeSafe exposes an answer space before inference, and Jev returns probabilities over that answer space. Its public documentation describes a new model stack, a parallel sampler and a training approach called Reinforcement Learning for Calibrated Decisions (RLCD). Public material does not disclose enough architectural detail to independently reconstruct the model, so claims about its internals should stay within what TypeSafe has actually published.

Why TypeSafe calls it a System One model

The name is inspired by the “System 1” idea popularized by Daniel Kahneman: fast, intuitive judgment rather than slow, deliberate reasoning. TypeSafe’s own documentation says Jev works best when each question asks for one specific judgment that a knowledgeable person could make quickly with the right context.

If the problem requires several independent considerations, TypeSafe recommends splitting it into several narrow questions and combining the results in code.

The product name has a second reference. TypeSafe says Jev is named after economist William Stanley Jevons and Jevons paradox, the observation that efficiency improvements can increase total demand for a resource. The company’s argument is that drastically cheaper machine judgment could make developers use far more of it.

How this differs from JSON mode and structured outputs

General-purpose LLMs can already return JSON, call tools and follow schemas. That is useful, and for many low-volume workflows it may be all you need. The difference TypeSafe is selling is deeper than the response format.

A normal LLM still has a general text-generation engine behind the schema. The developer asks that engine to express its answer through a constrained interface. Jev is built around the bounded decision interface itself. The allowed answer set, ordered rubric or yes/no proposition is part of the question definition, and the result is intended to be consumed directly by code.

That changes the engineering trade-off. With a general model, the same endpoint can classify a document, explain the decision, draft the follow-up email and write code to fix the workflow. With Jev, the classification can be the whole job. If an explanation is required, another component has to produce it.

This is also why raw token-price comparisons can mislead. A lower Jev price does not automatically mean a cheaper replacement for an LLM call if the LLM call was doing several jobs at once. The useful comparison is narrower: identify the decisions in your existing workflow that can be expressed as Choice, Score or Noul questions, then compare the cost, latency and error rate of that decision layer.

For finance teams, that separation can be healthy. Exact calculations remain in code, bounded judgment sits in a decision model, prose stays with a writer model or person, and approval rules remain visible. It gives each component a clearer responsibility and makes failures easier to test.

How the Jev API works: Choice, Score and Noul

TypeSafe currently exposes three question primitives. They look simple, but their boundaries are important.

Source: TypeSafe Primitives.

Choice: pick one option

A Choice question asks Jev to select from a fixed list. This is useful for document type, routing destination, exception category or a candidate account code.

If the list might not cover every case, TypeSafe recommends including something like other or none_of_the_above. That matters because a bounded answer space is only useful if the real-world input is allowed to fall outside your preferred categories.

For example, an invoice-processing system might offer invoice, credit_note, statement, purchase_order and other. Jev returns the selected option and a probability distribution across the allowed options.

Score: rate against an ordered rubric

Score is for an ordered scale where each level has a defined meaning. You might use it for exception severity:

1. No issue
2. Minor discrepancy
3. Needs review
4. Significant control issue
5. Stop processing

The output is a position along the rubric plus the probability distribution and confidence. This is not the same thing as free-form numeric regression. The levels are defined in advance, and the model evaluates the state against those ordered levels.

Noul: probability of yes

Noul asks a yes/no question and returns a probability from 0 to 1. Examples include:

• Does this document appear to be a duplicate?
• Does the narrative indicate an employee reimbursement?
• Does the extracted memo suggest a personal expense?
• Does the cited source support the claim made by another model?

A value near 1 means strong probability of yes, near 0 means strong probability of no, and near 0.5 means uncertainty between the two. A 0.5 Noul does not mean “medium severity”. If you need severity, use Score.

Why atomic questions matter

Every question in one Jev request sees the same state and is evaluated independently. TypeSafe recommends sending narrow questions together when they share the same state, then combining the answers in code.

That can be useful in finance because real workflows often have several independent checks. An AP document can be classified, checked for duplicate risk, scored for review severity and routed to a queue without forcing one giant prompt to reason through everything at once.

Here is a simplified Python example:

from typesafe_sdk import Choice, Noul, Score, TypeSafeClient

state = {
    "invoice_text": extracted_text,
    "vendor_name": vendor_name,
    "po_status": po_status,
}

with TypeSafeClient() as client:
    result = client.system_one(
        state=state,
        questions={
            "document_type": Choice(
                instructions="Classify invoice_text by document type.",
                criteria={
                    "invoice": "Supplier invoice",
                    "credit_note": "Supplier credit note",
                    "statement": "Supplier statement",
                    "other": "None of the above",
                },
            ),
            "duplicate_risk": Noul(
                instructions="Does the state indicate a likely duplicate invoice?"
            ),
            "review_severity": Score(
                instructions="How serious is the accounting review exception?",
                criteria=[
                    "No meaningful exception",
                    "Minor discrepancy",
                    "Needs accountant review",
                    "High-risk exception",
                ],
            ),
        },
    )

The current quick start uses POST https://api.typesafe.ai/v1/systemone, and TypeSafe’s Python SDK package is typesafe-sdk. See the official quick start for the current request schema.

Jev pricing: the $0.042 number is real, but compare the right thing

TypeSafe’s Models page currently lists Jev 1.13 at $0.042 per million input tokens, or $42 per billion input tokens. Output tokens are not charged. On 30 September 2026 the same page lists 100,000 tokens per second and 40 requests per second. That is a lower token ceiling than the 250,000 tokens per second it showed when we first published this guide, but a higher request ceiling: 40 a second is 2,400 a minute, against 1,200 before. TypeSafe says the limits are adjusting with demand and can change without notice, and offers higher limits on custom and enterprise plans.

ReconScribe’s current GPT-6 Astra vs Claude Fable 5.1 comparison lists a $10 per million fresh-input rate for both models. Comparing that price line alone:

$10 / $0.042 = 238.1

So Jev’s published input-token rate is about 238x lower than a $10/M fresh-input rate.

This is a price-line comparison, not an equivalent-workload comparison. Jev does not produce general prose, code or open-ended reasoning output. If your workflow still needs those capabilities, a general model may remain part of the system.

Worked example: 100,000 decisions a month

Suppose an application processes 100,000 items per month and sends roughly 1,000 input tokens per item. That equals 100 million input tokens. At $0.042 per million tokens, the Jev input charge is $4.20.

That figure excludes OCR, storage, retries, observability, databases, other models, taxes and human review.

Worked example: one million decisions a month

One million calls at 1,500 input tokens each equals 1.5 billion input tokens. At the published rate, that is $63 in Jev input charges.

Again, the important budgeting question is how much of your workflow can genuinely stay inside bounded decisions.

Is Jev really 40x to 200x faster and 40x to 400x cheaper?

TypeSafe’s launch post reports 70 to 500 ms end-to-end response time and says Jev can be roughly 40x to 200x faster for System One-shaped queries at comparable intelligence levels.

Its workflow evaluation is even more dramatic. TypeSafe says the 193.6x faster and 444.6x cheaper figures shown in its marketing come from its own workflow tests.

Those numbers should not be repeated without the caveats TypeSafe publishes itself. The company says:

• its workflows were created by members of its own model-capabilities team, so some bias may exist;
• reference probabilities use an average of GPT-6 Astra and Claude Fable 5.1 outputs;
• LLM baselines are run through TypeSafe’s own System One wrapper;
• published latency tests were generally run from West Coast laptops close to the service region;
• the company cannot yet prove that current pricing is not subsidized, because long-term sustainability has not been demonstrated;
• the 193.6x and 444.6x workflow results are on the higher end of what it expects in real use.

Source: TypeSafe’s launch post.

What early independent tests show

Independent evidence is still very young because Jev only launched on 15 September 2026.

On 19 September, Baader Agency reported running Jev over 275 internal documents containing about 2.624 million input tokens. It reported roughly 30 seconds wall-clock time, an $0.11 bill and no request errors. The authors also made an important distinction: agreement with existing internal tags is not automatically the same as ground-truth accuracy.

Also on 19 September, TrueStandard published tests showing how strongly the speed multiple depends on workload design. A one-decision comparison was around 1.7x versus one fast model, while a batched six-judgment workflow against a sequential reasoning baseline was around 100x.

The speedup belongs to the workload shape and the baseline, not to the product name alone.

For a single classification call against a fast, inexpensive model, the improvement may be modest. For a workflow that currently makes several sequential calls to a slower reasoning model, batching many independent decisions against one shared state can change the economics far more dramatically.

What you could build with Jev AI

The more useful question is where a bounded decision layer can sit inside software you already use. The examples below are practical design patterns, not claims that each workflow is already running in production.

The recurring pattern is simple: Jev decides, code acts, and a general LLM writes only when generation is actually needed. In finance, the same split can put Jev after OCR and normalization for document classification, exception routing or claim verification, while exact arithmetic, tax logic and statutory rules remain deterministic.

“Zero hallucinations” needs one important correction

TypeSafe markets Jev around type safety and says its structured output design prevents hallucinated output types. Its launch post also includes the nuance needed to interpret that correctly: the zero value in its hallucination plot is not an empirical measurement of factual correctness. TypeSafe says schema matching is guaranteed.

Consider an invoice classifier with four allowed values: invoice, credit_note, statement and other.

Jev should not return banana, an invented fifth category, malformed JSON or a paragraph instead of the required type. That is a real reliability benefit for software.

But the model can still choose invoice when the document is actually a credit note.

This difference matters in accounting systems. A type-safe error can still post a document to the wrong queue, select the wrong candidate category or miss a duplicate. Confidence thresholds, deterministic checks and human review still matter.

Where Jev could fit in accounting and finance

The most interesting Jev use cases for finance are not calculations. They are fuzzy semantic decisions that sit between data extraction and deterministic business logic.

A practical architecture looks like this:

PDF or email -> OCR / extraction -> deterministic normalization -> Jev decisions -> deterministic rules -> optional writer model -> human approval where risk or uncertainty requires it

That division of work keeps arithmetic and statutory logic in code while using AI where rules become brittle.

Invoice and accounts-payable triage

After a document has been converted to text, Jev could help answer questions such as:

• Is this an invoice, credit note, statement or supporting document?
• Does the document appear likely to be a duplicate?
• Is a purchase-order mismatch material enough to require review?
• Which review queue should receive the exception?
• Does the document appear to relate to a known vendor?
• Is the exception low-risk enough for straight-through processing?

Jev is text-only at launch, so a scanned invoice still needs OCR or document extraction first. It does not replace the parser.

Amount checks should also stay deterministic. Invoice totals, GST amounts, quantity extensions and tolerance calculations are better handled by code because they are exact rules, not fuzzy judgments.

GSTR-2B and reconciliation exceptions

GST reconciliation is another area where a bounded decision layer could be useful after deterministic matching has done the obvious work.

Code can first normalize GSTINs, invoice dates, invoice values and tax amounts. Jev could then help classify exceptions that require semantic judgment:

• Does this invoice-number variation plausibly refer to the same document?
• Does the exception look like a vendor follow-up, booking issue, eligibility review or timing difference?
• Does the narration support a likely credit note?
• Is the exception ambiguous enough to send to a reviewer?

The statutory calculation and filing decision should remain in reviewed rules and code. Jev’s confidence is useful for routing, not for delegating the legal tax position.

For a deterministic reconciliation starting point, see ReconScribe’s GSTR-2B reconciliation Excel template and GST reconciliation demo.

Bank-to-books coding

After a bank parser has extracted a clean transaction line, Jev could pick from a bounded candidate set such as bank charges, software subscription, travel, payroll, vendor payment, customer receipt, tax payment or needs review.

The candidate list matters. Asking Jev to pick from the whole chart of accounts without context is a different and harder problem than asking it to choose between five plausible accounts supplied by existing rules.

A strong workflow could use deterministic filters first, Jev second, then an accountant for low-confidence or high-value exceptions.

Agent guardrails and LLM verification

Jev may also be useful around other AI systems. A general model can draft an accounting memo or audit comment. Jev could separately judge bounded questions such as:

• Does the cited source support this specific claim?
• Does the response contain a prohibited disclosure?
• Does the generated journal-entry explanation satisfy required criteria?
• Does the message contain a prompt-injection pattern?
• Should this output be escalated for human review?

This is closer to a control layer than a writing layer.

ReconScribe’s AI prompts for finance can still be useful for the generative part of a workflow. Jev would sit beside that model when the next step is a bounded decision.

Jev vs general-purpose LLMs

The point is not to choose a universal winner. The models are shaped for different jobs.

Good fit vs poor fit in a finance workflow

Where Jev is the wrong tool

Jev becomes a poor fit when the answer cannot be specified in advance as a bounded decision. That includes:

• drafting emails, memos, policies or board commentary;
• summarizing a document into free-form prose;
• writing or modifying code;
• open-ended research;
• creative generation;
• problems where the valid answer space is unknown before inference;
• arithmetic and reconciliations that deterministic code can calculate exactly;
• image, audio or video input at launch;
• workflows that require a detailed natural-language explanation from the same model.

There are also current production limits to consider. TypeSafe’s Models page lists a 64k-token request budget, with a 32k budget applying to the state plus the longest individual question. English is the primary training language, and TypeSafe says other languages are not expected to perform equally well.

The jev-latest alias can move when a new stable model is released, so teams that calibrate confidence thresholds should consider pinning jev-1.13.0 and retesting before upgrading.

Data handling

TypeSafe’s current Models documentation says customer requests and responses are not used to train Jev. It separately points to zero-data-retention options for enterprise customers.

Those are not the same statement. Do not assume every account has zero retention. Before putting confidential client or employee data into any new AI service, review the current DPA, contract terms, retention settings and security controls that apply to your account.

A practical test before putting Jev in production

Jev’s price makes it easy to run a proof of concept. The harder part is designing the test correctly.

A finance team should start with one narrow workflow and build a labelled evaluation set from real historical cases. For example, take 300 previously reviewed AP exceptions and define the questions before testing:

1. document type;
2. duplicate-risk indicator;
3. review severity;
4. routing category;
5. whether a human must review.

Then compare Jev’s outputs against independently reviewed labels. Do not tune thresholds on the same records you later call the test set.

For Choice and Score, inspect the probability distributions, not only the top answer. For Noul, test several confidence thresholds. A workflow might auto-process above 0.98, route 0.70 to 0.98 to a normal review queue, and send lower-confidence cases to a specialist, but the correct thresholds depend on the cost of each error.

Also measure the whole workflow:

• OCR or extraction cost;
• Jev input cost;
• retries and failures;
• latency;
• false positives and false negatives;
• human-review rate;
• cost of mistakes;
• fallback model cost;
• engineering and monitoring overhead.

A model that costs almost nothing per token can still be a bad automation if it creates expensive review work or systematic errors.

What to take seriously about Jev today

Jev is one of the more interesting model launches for software automation because it is willing to give up a capability most AI products treat as mandatory: generating strings.

That trade creates a clean interface for a specific class of work. If the application already knows the possible answers and needs a fast probability-weighted judgment, Jev’s architecture and published pricing deserve testing.

The strongest claims are the narrow ones:

• the current input-token price is exceptionally low;
• TypeSafe exposes typed decision primitives instead of free-form generation;
• questions over the same state can be evaluated together;
• the model is designed for bounded, high-volume semantic judgments;
• schema-constrained output removes malformed or invented output types.

The claims that need more time are broader:

• how well calibration holds across many industries and languages;
• how accuracy compares with strong task-specific baselines;
• whether early pricing remains sustainable;
• how the service behaves under long-running production load;
• how much end-to-end savings survive once OCR, fallbacks, human review and writer models are included.

Jev does not need to replace GPT or Claude to matter. If it can cheaply absorb the narrow decision calls that are currently being sent to general-purpose models, that alone could make it useful.

Frequently asked questions

What is Jev AI?

Jev is TypeSafe AI’s first public System One model. It takes text or structured text state plus typed questions and returns bounded decisions with probabilities that software can use directly.

Is Jev an LLM?

TypeSafe positions Jev as a System One model rather than a conventional text-generating LLM. It does not expose free-form generation as its interface. Public documentation describes a new architecture and training stack, but does not provide enough detail for an independent architectural reconstruction.

How much does Jev cost?

As checked on 21 September 2026, TypeSafe lists Jev 1.13 at $0.042 per million input tokens, or $42 per billion. Output tokens are not charged. Current pricing is on the TypeSafe Models page.

Is there a free Jev API?

TypeSafe does not list a free tier. Output tokens cost nothing and input costs $0.042 per million tokens, so small tests cost very little. Jev launched in early access with a waitlist on 15 September 2026. Since 27 September TypeSafe says it is open to everyone, so you can create an account without waiting.

What are the Jev API rate limits?

The TypeSafe Models page lists 100,000 tokens per second and 40 requests per second for Jev 1.13 (checked 30 September 2026), and says the limits are adjusting dynamically and can change without notice. Higher limits are available on custom and enterprise plans. The context length is 64k tokens.

What are Choice, Score and Noul?

Choice selects one option from a declared set. Score rates the state against an ordered rubric. Noul returns the probability that a yes/no proposition is true.

Does Jev really have zero hallucinations?

TypeSafe can guarantee schema matching, so Jev should stay inside the answer type you declared. That does not guarantee factual correctness. A schema-valid answer can still be the wrong choice.

Is Jev faster than GPT-6 Sol or Claude Opus 5.5?

TypeSafe reports very large gains on System One-shaped workflows, including a 193.6x workflow result, but says that figure is on the high end. Early independent tests show the multiplier varies sharply by workload. A single classification can show a much smaller advantage than a multi-step workflow collapsed into one batched Jev request.

Can Jev process invoices and bank statements?

It can evaluate extracted text and structured state. It does not accept image input at launch, so scans and PDFs still need OCR or another extraction layer first.

Can Jev replace GPT or Claude?

Not for general writing, coding, research or multimodal work. It may replace some narrow classification, scoring, routing and verification calls inside a larger system.

Should finance teams use Jev for tax calculations?

Use deterministic code and reviewed rules for exact arithmetic and statutory logic. Jev is better suited to fuzzy semantic judgments around those rules, such as classification, exception routing or review gating.

What can you build with Jev?

Good candidates are workflows where the possible answers are known in advance: document classification, exception routing, severity scoring, claim verification, content filtering, browser-agent next-action selection and tool or model routing. Jev makes the bounded decision, then code executes it or escalates it. Use a general-purpose LLM when the workflow needs open-ended writing or research.

Related reading

• Claude Opus 5.5: benchmarks, pricing and how it compares
• GPT-6 Astra vs Claude Fable 5.1: Benchmarks & Pricing
• AI Prompts for Finance
• GSTR-2B Reconciliation Excel Template
• ReconScribe Finance Automation Demo
• GST Reconciliation Demo

Sources

• TypeSafe: Introducing System One models and Jev
• TypeSafe docs: Models (pricing, limits, aliases)
• TypeSafe docs: Introduction
• TypeSafe docs: Quickstart
• TypeSafe docs: Primitives
• TrueStandard: Is Jev really 193x faster?
• Baader Agency: Jev, the first three days