Jev vs OpenAI Decisions API: Technical Comparison & Engineering Guide

Introduction

On September 15, 2026, TypeSafe AI released Jev, branding it as a "System One Model." Two weeks later, on September 29, OpenAI announced a limited preview of the Decisions API at DevDay, and it reached general availability on October 22. A venture-backed startup defined a new category, and the platform giant shipped a comparable product to GA in just 37 days.

The author's team builds vertical AI agents and is evaluating these tools: what they solve, how they differ technically, how to choose between them, and which capabilities will be absorbed by the model layer versus where the remaining value lies for vertical applications.

1. What Problem Do They Solve?

Most software workflows calling models do not want free-form text. A support system needs "which team owns this ticket," an agent needs "which tool to call next," a moderation pipeline needs "risk level." For two years the standard pattern has been:

Write a prompt, have the LLM output JSON, then write parsing and validation code, retry on format errors.

Production engineers know the pain points of this chain:

Expensive: A three-way classification pays full reasoning-model prices.

Slow: Token-by-token generation means seconds per call.

Unreliable: Structured-output error rate is non-zero; models invent labels not in the option set, drop fields.

Confidence unusable: Self-reported "90% confidence" is typically overconfident and cannot serve as a threshold for automated execution.

Both Jev and Decisions API address this. Developers send context and a question together with a pre-defined set of possible answers; the model returns a typed decision with probabilities. The program branches directly on the result — no parsing step.

The flow changes from:

Chat model flow
Context → Prompt → Natural language explanation → Parse & validate → Program branch

Decision model flow
Context → Question + candidate answers → Typed decision → Program branch

TypeSafe calls Jev an "intelligent if statement," which the author finds accurate: it replaces those code branches you wanted to write as if but couldn't because the input is natural language and hand-written rules are too brittle.

2. Three Isomorphic Primitives

Placing the two offerings side by side reveals nearly identical abstractions.

Jev's API has only three question types:

Choice: Pick one from up to 255 options; returns the chosen option, per-option probabilities, and a confidence score. An explicit other option can represent "none of the above."

Score: Rate on a developer-described 2–10 scale; result can fall between levels (e.g., 1.4).

Noul: A yes/no proposition; returns a single probability between 0 and 1.

Decisions API at GA supports the same three answer types: Probability (maps to Noul), Choice, and Score.

Billing structure is also identical: only input tokens are charged; output is free. This follows from the product shape — output is just a label or a number, with no generation volume to meter. Both allow multiple questions in a single request. Jev processes them in parallel so adding a tenth question barely changes latency; Decisions API supports up to 400 questions per request.

The primitive convergence means the category boundaries have essentially settled: bounded decisions, pre-defined answer spaces, probabilistic output, input-only billing. For engineering planning, if the interface semantics map one-to-one, business code can target an internal "decision interface" and switching providers becomes low-cost — a point revisited in the integration section.

3. Where They Differ

Since the primitives are the same, differences concentrate on everything around them. The author organizes five dimensions.

3.1 Model Origin

TypeSafe positions Jev as a new model category, not a smaller LLM. Its training method is RLCD (Reinforcement Learning for Calibrated Decisions), optimizing probabilities against actual outcomes rather than human preferences. Diogo Almeida, who led RLHF and InstructGPT work at OpenAI, spearheads this. RLHF optimizes "do humans like this answer"; RLCD optimizes "does this probability match the true frequency of outcomes." The training objectives diverge sharply.

Decisions API's release notes say it uses "Luna intelligence." A DevDay report describes it as a specialized GPT-6 Luna version, and the GA announcement confirms it is based on GPT-6 Luna. From public information, it is a decision-oriented derivative of a general-purpose large model.

This difference affects two aspects:

Semantic understanding: The Luna-based version likely inherits the general model's strength in complex context, long instructions, and implicit intent.

Probability quality: Jev's training objective directly targets probability calibration. As of the author's research, OpenAI's public docs contain no technical details on calibration.

For systems that automate execution based on probabilities, probability quality matters more than a few extra points of classification accuracy. But this is an inference; final validation requires testing on the team's own labeled data.

3.2 Input Modalities

Jev currently supports only plain text: strings, JSON, or text arrays. No image, audio, or video.

Decisions API supported text and images in preview, and at GA added native integration with GPT-Live real-time voice.

OpenAI leads clearly here. Voice scenarios are extremely latency-sensitive: during a call you need real-time intent detection, emotion classification, escalation decisions. The traditional approach — speech-to-text then an LLM round — stacks latency unacceptably. Plugging a decision model directly into the real-time voice stream covers a class of use cases Jev cannot currently touch. Visual scenarios (product image moderation, document classification, screenshot judgments) similarly benefit.

3.3 Pricing

Jev: $0.042 per million input tokens ($42 per billion).

Decisions API: $0.10 per million input tokens.

Jev is roughly 2.4× cheaper. A third-party reseller, decisions-api.dev, sells Jev at 600 credits per million tokens; 10,000 credits cost $1, yielding $0.06 per million — higher than direct TypeSafe but still below OpenAI.

Both are orders of magnitude cheaper than general LLMs. The 2.4× gap rarely decides a deal unless decision volume is massive and the business is willing to maintain an extra vendor for that slice of cost. TypeSafe itself admits it cannot prove its pricing isn't subsidized. A freshly funded startup and a platform company both have incentives to keep early prices low, so current prices should not be treated as long-term planning anchors.

3.4 Speed

Jev self-reports 70–500 ms latency. Its homepage claims "193.6× faster, 444.6× cheaper" than LLMs on a workflow benchmark.

Decisions API's official claim is "up to 10× faster than calling Luna via Responses API." A DevDay demo showed ~150 ms for Decisions API versus ~1.6 s for a regular Luna call.

All numbers come from the vendors; conditions must be scrutinized:

TypeSafe's benchmark ran on the team's laptops on the US West Coast. The workflows were not in the training set but were built internally. The benchmark uses GPT-6 Astra and Fable 5.1 averages as the "correct" reference, inherently favoring those models.

OpenAI's "up to 10×" is an upper-bound statement; the 150 ms figure comes from a demo report. Neither is an SLA.

Side-by-side comparison is impossible. What matters is that both bring single-decision latency into the few-hundred-millisecond range, making them viable in synchronous request paths . Exact speed can only be measured with your own traffic.

3.5 Ecosystem Position

This dimension most impacts long-term selection.

Decisions API lives inside the OpenAI platform: same account, same billing, same permissions and compliance, native interoperability with GPT-Live and Responses API. For teams already deep on OpenAI, adoption adds almost zero overhead.

Jev is an independent vendor; its position is model-neutral. In a cascade architecture, Jev sits in front doing classification and routing, while the frontier model behind it can be from any provider. Its own benchmarks reference GPT-6 Astra and Fable 5.1 from two different vendors. For teams that do not want the decision layer and generation layer locked to a single platform, this has practical significance.

Conversely, the independent vendor risk is clear: the platform shipped a primitive-isomorphic, multimodal, similarly priced product in 37 days. Jev's survival depends on whether it can open a durable gap in calibration quality, speed, or certain vertical niches. This mirrors the exact challenge vertical agent teams face.

4. What Will Be Replaced

4.1 LLM Classification Calls

The first casualties are the myriad small judgments currently stuffed into LLM prompts. The author's own system has them: intent recognition, ticket triage, output compliance checks, tool-trigger decisions — each a full LLM call. Moving to decision models yields:

Cost drops to a fraction of the original.

Latency falls from seconds to hundreds of milliseconds.

Structured-output errors go to zero.

TypeSafe's claim of 0% type errors is the hardest to dispute. The answer space is pre-defined; pattern matching is guaranteed by construction — a single counterexample would falsify it. The engineering gain is equally concrete: JSON parsing, field validation, format-error retry logic — whole blocks of glue code can be deleted.

4.2 Traditional Text Classifiers

This deserves expansion because many teams have existing investments.

Classic text classification pipelines use logistic regression, GBDT, or fine-tuned BERT-style models. The cost lies mostly outside the model:

Every task needs labeled training data.

Changing categories means re-labeling, retraining, redeploying.

Long-tail categories suffer from data scarcity.

Each classifier is a separate asset requiring monitoring and periodic retraining.

Decision models excel at zero-shot and editability. Category definitions are natural language in the request; adding a category is a one-line config change. Jev's Choice lets you write a judgment criterion per option. Below is a request example from decisions-api.dev docs:

curl -X POST https://decisions-api.dev/v1/systemone 
  -H "Authorization: Bearer $DECISIONS_API_KEY" 
  -H "Content-Type: application/json" 
  -H "Idempotency-Key: support-ticket-1842" 
  -d '{
    "model": "typesafe/jev-1.13",
    "state": {
      "message": "I paid yesterday but still do not have access.",
      "account_status": "active"
    },
    "questions": {
      "department": {
        "type": "choice",
        "instructions": "Which team should handle this request?",
        "criteria": {
          "billing": "Payment, invoice, refund, or access after payment",
          "technical": "A product bug or service failure",
          "general": "A request that does not fit the other teams"
        }
      }
    }
  }'

Notice the billing criterion includes "access after payment." That cross-category boundary case — paid but no access — would require labeled examples in a traditional classifier; here it's a one-sentence addition to the definition. Business stakeholders can adjust classification boundaries without a full ML iteration cycle.

Traditional models won't disappear entirely. Three scenarios where they remain superior:

Structured numeric features: Inputs like transaction amount, frequency, device fingerprint — GBDT runs locally at sub-millisecond latency, near-zero cost, mature performance. Serializing them to text for a remote model adds no value.

Extreme QPS with stable categories: An already-trained, well-performing local classifier has limited migration upside.

Environments requiring full determinism and offline operation.

Thus: decision models replace "unstructured text + frequently changing categories + high labeling cost" segment of traditional classification. Numeric-feature risk models are out of scope.

4.3 Fragile Rule Engines

Many systems have a layer of keyword and regex rules for routing and filtering. They start useful, grow brittle with business changes, and eventually no one dares modify them. Where input is natural language and rules become fragile is exactly the "intelligent if statement" slot.

4.4 Confidence Calibration Work

Previously, getting usable probabilities from a classifier required an extra calibration pass. RLCD bakes this into model training. However, TypeSafe explicitly states calibration is a population property: over many predictions, higher confidence correlates with higher accuracy, but no single answer is guaranteed correct. So calibration verification remains — it just shifts from "do calibration yourself" to "verify the vendor's calibration holds on your data."

5. What Won't Be Replaced

Jev has no world knowledge; it only knows the state passed to it and cannot actively query anything. This caps the capability of any workflow built on it. The same applies to Decisions API: it judges solely on provided context and candidate answers. From this, four things decision models cannot absorb emerge.

5.1 State Construction

Model accuracy depends entirely on whether the input state contains the key facts. In the ticket example — "paid yesterday but still no access" — deciding between billing and technical requires knowing if payment cleared, if permission sync failed, if the user has prior similar tickets. These facts live in disparate business systems; assembling them into a concise state within tens of milliseconds is the application's job. The cheaper and faster the model, the larger the share of overall quality attributable to state construction.

5.2 Answer Space Definition

Choice options, Score scale descriptions, Noul propositions — all must be authored by developers. These definitions are domain knowledge:

How many categories in an insurance claim workflow, and where are the boundaries?

How many urgency levels in medical triage, and what action maps to each?

Which contract clauses count as high-risk in legal review?

General models won't decide this for you. Definition quality directly impacts results. The author's practice: write minimal state, ask a concrete question ("which team handles this request" beats "understand this customer"), change one condition at a time to isolate effects.

5.3 Outcome Data

RLCD uses actual outcomes to optimize probabilities, making outcome data the training core. The same holds for operators. After a decision, was it right? Was the ticket routed correctly? Was the refund approved? Was the moderation appeal upheld? These outcomes exist only in business systems. Whoever owns the closed-loop outcome data can evaluate models, set thresholds, detect drift.

5.4 Actions and Responsibility

Decision models emit judgments; execution lives in application code. High-stakes operations — permission checks, payment mutations, account closure — should remain guarded by deterministic, auditable rules, as both vendors advise. Threshold setting, error ownership, regulatory explainability are business responsibilities the platform will not assume.

6. Vertical Agent Positioning

Returning to the author's core question: as models become more specialized, faster, cheaper, and more vertical, does the vertical agent layer still have value?

First, the trend. Specialization is already happening. Jev and Decisions API are a concrete example: a "bounded decision" form factor split out of general chat models, dropping price and latency by one to two orders of magnitude. Expect further splits — dedicated extraction models, ranking models, modality-specific judgment models. Each split pushes what was previously implemented in the application layer via prompts and glue code down into the model API.

So "AI will replace all other capabilities" is half right. It will replace generic cognitive operations — classification, scoring, extraction, generation — and the engineering glue around them. It will not replace the four items from Section 5: state, definitions, outcome data, actions and responsibility.

If a vertical agent's value is "our prompts are tuned," "we wrote JSON parsing and retry logic," "we fine-tuned a classifier," that value will be consumed quickly. The 37 days from Jev launch to Decisions API GA is a rough speed reference for platform absorption of such capabilities.

If the vertical agent's value lies in these three things, cheaper models amplify its worth:

Integrating the industry's hard-to-reach systems.

Accumulating the industry's decision definitions and outcome data.

Owning execution and accountability.

Jev's name comes from economist Jevons, invoking Jevons paradox: as decision cost falls, decision demand explodes. In the author's business, once a single decision costs two orders of magnitude less, places that previously could only afford sampled checks or a single judgment at a critical node can now judge at every step, asking ten questions per step. Decision points multiply; each new point needs state, definitions, thresholds, and execution. That work lands on the vertical application layer.

TypeSafe's own situation proves the point. It matches the platform on primitives, lags on multimodal, has only a 2.4× price edge. Its defensibility rests on hard-to-copy factors like calibration quality. Vertical agents face the identical question: what can't be replicated in 37 days?

7. How to Integrate Into Existing Systems

The author distills six engineering integration patterns.

7.1 Place It in the Decision Layer

A common architecture is a three-tier cascade:

Decision model handles classification and routing at low cost.

Deterministic code handles what it can.

Frontier models take only the few complex tasks.

Benefits: expensive LLM calls drop; a clear, auditable boundary appears between "machine-decided" and "needs human." Decision models do not generate — chat, code generation, reasoning explanations are outside their scope. Their architectural position is a layer in front of LLMs, not a replacement.

7.2 Set Thresholds Per Action

Don't set a single system-wide accuracy threshold. Instead, set thresholds per action based on error cost:

Cheap read-only decisions: auto-execute at high confidence.

High-cost decisions: require confirmation.

Low confidence: escalate to human or fall back to a full reasoning model.

This requires first labeling every action type in the business with its error cost. No model can do this work, and the author considers it the highest-leverage investment.

7.3 Fan-Out Questions

Both APIs support multiple questions per request with free output, so ask every potentially useful question upfront and let code decide which answers to use. A single support ticket request can simultaneously ask:

Which team handles it (Choice).

Customer dissatisfaction level (Score).

Whether the customer explicitly demands a refund (Noul).

Code then combines answers with ordinary if logic. The design key is to decompose questions finely. A vague "how should this ticket be handled" is worse than three to four atomic, individually evaluable questions. Fine-grained questions enable per-question validation on labeled data and independent threshold tuning.

7.4 Guardrails

Decision models can guardrail other models' outputs: check if a generated reply promises something it shouldn't, leaks sensitive fields, or drifts off-task. Previously, using one LLM call to check another doubled cost, forcing many teams to sample. Decision model pricing makes full-volume checking feasible.

7.5 Abstract a Decision Interface

Because primitives are isomorphic, business code should target an internally defined decision interface: question types, option definitions, returned probability structure. The underlying adapter swaps Jev or Decisions API. This yields three benefits:

Run A/B comparisons on the same sample batch.

Switch providers if one changes pricing or availability.

Route text scenarios to one vendor, voice/image scenarios to the other.

7.6 Build an Evaluation Set First

Before go-live, evaluate on labeled historical examples, recording four metrics:

Misroutes.

Missed escalations.

Response latency.

Human review cost.

Simultaneously verify probability calibration on your data: does the 0.9-confidence bucket actually achieve ~90% accuracy? Both sources emphasize probability ≠ measured accuracy ≠ authorization for auto-executing high-risk actions.

One engineering detail: every logical request should carry a unique Idempotency-Key to avoid duplicate model calls on retry. This is required by decisions-api.dev and should be adopted in custom call chains.

8. Who Needs It

By business traits, suitable scenarios share three characteristics:

High decision frequency.

Known, bounded answer set.

Input is primarily unstructured text (or, for Decisions API, also images and voice).

Typical businesses meeting all three:

Support & ticketing systems: categorization, triage, routing, escalation decisions.

Content platforms: moderation, risk grading, violation typing.

Agent products: next-action selection, tool routing, guardrail checks on generated output.

Information extraction & scoring: lead scoring, document type identification, field presence checks.

Real-time voice scenarios: in-call intent detection and handoff decisions. Currently only Decisions API covers this directly.

By enterprise traits, teams with a high proportion of "classification-style" calls in their LLM bill benefit fastest. If most calls are "make GPT output a label," migration ROI is immediate. Next are teams maintaining a zoo of traditional text classifiers that require re-labeling and retraining every time the business tweaks a category.

By role, three groups use it:

Platform & backend engineers: replace glue code and rule engines.

ML engineers: reassess which legacy classifiers are worth keeping.

Business operations & strategy: category definitions become natural-language config, letting them directly shape decision boundaries — but they also own definition quality.

Unsuitable scenarios:

Low-frequency decisions where LLM vs. decision model cost difference is negligible.

Generation-heavy workloads.

Open-ended questions with no pre-enumerable answer space.

Questions requiring the model to fetch external knowledge to decide.

9. Summary

Jev and Decisions API use nearly identical three primitives and the same "input-only" billing to carve "bounded decision" out of the prompt layer into a standalone model category. The 37 days from Jev's launch to Decisions API GA illustrates how fast the platform can absorb such capabilities.

What can be copied in 37 days is a feature; what cannot be copied in 37 days is a moat.

Prompt tricks, JSON glue code, and dedicated text classifiers will be the first consumed by the model layer. State construction, answer-space definition, outcome data, and action responsibility will grow more important as decisions get cheaper, because the cheaper the model, the more valuable the state you feed it.

As single-decision cost drops, decision points multiply. Every new decision point adds more state, definitions, thresholds, and execution that the business must own.

For vertical agent teams, whoever holds the outcome data holds the thresholds; the cheaper decisions become, the more expensive it is to ask the wrong question.

Models answer; businesses ask. Hand the if to the model; keep the consequences in code.