OpenAI Is Entering the Decision Model Market Jev Helped Expose

TL;DR

Is the OpenAI decision model public?

OpenAI released Decisions API in beta on October 6, 2026. The documented interface uses POST /v1/decisions with the gpt-6-luna model.

The API is available across supported OpenAI API regions. Regional processing is supported in the United States and Europe, including the EEA and Switzerland. The GPT-6 Luna model page lists the Free tier as not supported, so access begins on a paid API usage tier.

Decisions API belongs to the OpenAI developer platform. People searching for a ChatGPT decisions API are looking for this developer endpoint; OpenAI does not document it as a ChatGPT product feature.

Figure 1. Both services turn supplied context and declared questions into typed results. The diagram is conceptual because their request and response schemas differ. OpenAI and TypeSafe wordmarks are trademarks of their respective owners.

Clixlogix published its guide to the Jev AI decision model on September 21, 2026. Eight days later, OpenAI announced Decisions API at DevDay.

Figure 2. OpenAI presented Decisions API during DevDay 2026 alongside its broader developer platform announcements. Image: OpenAI DevDay 2026.

DevDay 2026 also included Codex expansions, security scanning, and other developer tooling updates. Decisions API is the announcement most relevant to teams already thinking about specialised decision models.

The timing brings decision models into a much larger conversation.

OpenAI initially described Decisions API as a service for classification, request routing, and agent action selection. The official Decisions guide now documents the product in detail, and the OpenAI developer changelog records its October 6 beta release with GPT-6 Luna.

This places OpenAI in direct competition with Jev for bounded decisions inside software and AI agents.

What OpenAI Decisions API does

Many software workflows require a choice from a known set of outcomes.

These situations run through most software systems:

• Support routing - A ticket goes to billing, technical support, account management, or an escalation queue.
• Transaction risk - A payment is classified as clear, hold, or block.
• Content moderation - A piece of user content is marked allow, warn, restrict, or remove against a defined policy.
• Agent tool calls - A proposed tool call is approved, denied, or sent for human review.
• Agent planning - A multi step agent picks its next step from a fixed set of tools or planning branches.

The same kind of bounded decision runs through the wider business stack:

• Sales - Inbound leads are qualified and routed to the right owner.
• Finance - Invoices are approved, held, or rejected before entering the payment queue.
• Compliance - Policy checks resolve to pass, fail, or review.
• Ecommerce - Product listings are assigned to a category before indexing.
• Insurance - Claims are triaged into automated processing, adjuster, or fraud review.

OpenAI Decisions API is designed for these situations.

The developer sends shared input and an array of questions to POST /v1/decisions. The input can be a string or user messages containing text and inline images. Each question is a predicate, choice, or score. Answers return in the same order as the questions.

A predicate estimates the probability that a stated condition is true. A choice selects from developer supplied string or Boolean values. A score evaluates the input against ordered levels and returns a probability weighted value that may fall between those levels. Independent questions can share one request. Decisions that depend on an earlier answer require separate requests.

The API accepts text and base64 encoded images supplied as data URLs. External image URLs, file IDs, audio, function calls, and non user message roles are not supported. A request can contain up to 128 images.

Table 1. OpenAI Decisions API and Jev at a glance

The interfaces now have clear semantic overlap, although their field names, schemas, and provider routes differ.

The OpenAI data controls guide lists Decisions API as available in all supported API regions. Regional processing is supported in the United States and Europe, including the EEA and Switzerland. The service supports Zero Data Retention and HIPAA use for eligible customers. The GPT-6 Luna model page currently lists no Free tier access, then 5,000 requests and 2 million tokens per minute on Build, 10,000 requests and 10 million tokens per minute on Launch, and 30,000 requests and 180 million tokens per minute on Grow. The Decisions documentation does not list a separate endpoint specific rate limit table.

Why fixed answers matter

The defined answer set is one of the most important parts of a decision interface.

A standard GPT-6 Luna request can already return schema constrained output containing a fixed set of values through Structured Outputs and a JSON Schema enum. Decisions API packages predicate estimation, fixed choice selection, and ordered scoring into a dedicated interface with probability distributions and confidence fields. Its practical value will depend on measured accuracy, calibration, latency, and cost compared with Luna using Structured Outputs.

A decision interface declares the available answers before the request is evaluated and returns an answer from that defined set. The result can be evaluated against a stable contract.

This creates several practical benefits.

1. Responses can be constrained to an approved set of outcomes.
2. Test cases can use the same answer set as production.
3. Accuracy can be measured consistently.
4. Individual decision types can carry separate thresholds where the provider exposes a suitable numeric signal.
5. A declared output contract can keep selections within the permitted set when the surrounding prompt changes, although the selected answer may still shift.
6. Applications can connect each outcome to an explicit action.

A fixed answer set also improves evaluation quality. A team can build a dataset with known outcomes and measure how often each model selects the correct answer. The same dataset can test Jev, OpenAI Decisions, rules, classifiers, and general language models.

The implementation question remains open

OpenAI now documents the interface in detail and identifies GPT-6 Luna as the model. The documentation does not explain how the decision behaviour is produced inside the service.

Several implementations are possible.

The service could use specialised training, constrained decoding, whole answer candidate scoring, a classification component, or a managed Luna request with a dedicated response contract. Each approach would have different implications for accuracy, calibration, latency, and cost.

This distinction matters because Jev presents itself as a dedicated decision model. TypeSafe describes Jev as using Reinforcement Learning for Calibrated Decisions (RLCD), along with an architecture designed to evaluate multiple typed questions efficiently.

If OpenAI uses a general language model behind a controlled interface, Jev may retain advantages that come from specialised training. If OpenAI has adapted Luna specifically for decision workloads, the competition becomes much closer.

Independent testing will need to establish whether the dedicated endpoint changes decision quality, probability quality, or latency relative to a standard GPT-6 Luna request.

A decision system needs a way to abstain

A fixed set of answers creates a difficult edge case. The supplied context may fit none of the available options.

Consider a support router with four destinations:

1. Billing
2. Technical support
3. Account management
4. Abuse review

A legal request or media enquiry falls outside that set. Forcing the model to choose one of the four creates a valid response with an invalid meaning.

A production decision service needs a defined way to handle this situation. Useful mechanisms could include:

1. An abstain result
2. A request for clarification
3. A human review option
4. A confidence threshold below which automation stops
5. An explicit none of these answers choice

OpenAI now documents a per question refusal. A refusal means the model declined that question, while other questions in the same request may still receive answers. It does not mean that none of the supplied categories fits the input.

For an incomplete answer set, the OpenAI Decisions guide recommends adding a fallback such as other and routing that result to a general review queue. It also recommends setting automation thresholds from labelled examples drawn from the application. Missing categories therefore remain an interface design responsibility even though the API can refuse a question.

This detail will strongly influence its suitability for safety checks, financial approvals, healthcare workflows, moderation, and destructive agent actions.

Figure 3. Decisions API can return a per question refusal. A refusal is distinct from an application defined fallback. Results below a validated threshold enter human review, while results above it can proceed to automation. Illustrative flow, not measured provider results.

A selected answer is only part of the result

Many low risk workflows can act on a selected answer alone. Higher risk decisions need additional information.

A routing system may need to know whether the preferred destination received 95 percent probability or 36 percent probability. Both calls could return the same selection, even though the appropriate workflow should differ.

The high confidence result may proceed automatically. The uncertain result may require human review.

Jev exposes probabilities as a central part of its interface, documented in both the OpenRouter guide to Jev and the Cloudflare Workers AI reference. Noul returns the probability of a true outcome. Choice returns the selected option, probabilities for the available options, and a confidence value. Score places the result on a declared scale and can include probabilities and confidence.

OpenAI now exposes comparable result types. A predicate answer contains a probability. A choice answer contains the selected value, a probability for every option, and a separate confidence value. A score answer contains the probability for every level, a confidence value, and a probability weighted numeric score. A question may instead return a refusal.

The published schema does not provide calibration evidence or a recommended universal automation threshold. OpenAI tells developers to use labelled examples from their own application and choose thresholds based on the cost of false positives and false negatives. Probability quality remains one of the most important points to test against Jev.

Calibration will matter more than confidence

A confidence value becomes useful when it reflects real outcomes across many similar cases.

If a model assigns probability 0.8 to an event across many comparable cases, that event should occur approximately 80 percent of the time. That property is calibration. A separate confidence score may describe how concentrated the answer distribution is without representing the probability that the answer is correct.

Calibration allows a product team to create meaningful automation policies. Decisions above a chosen threshold can proceed automatically. Decisions near the threshold can enter a review queue. Very uncertain decisions can stop safely.

A model can produce high confidence without being well calibrated. An OpenRouter evaluation of Jev on Banking77 found that its confidence scores were useful for ranking decisions, although they were not calibrated probabilities in that test. Teams should therefore evaluate the relationship between confidence and observed accuracy across their own data.

Jev presents calibration as a major product capability. OpenAI will need to show whether Decisions API provides comparable probability quality.

Figure 4. Probability, confidence, and calibration describe different properties of a decision. Values are illustrative and are not measured provider results.

Image support gives OpenAI a wider starting point

OpenAI has confirmed that Decisions API can receive text or inline images as context.

This expands the available use cases.

An ecommerce platform could classify a product listing using its description and images. An insurance application could route a claim using a written report and damage photographs. A browser agent could choose its next action using a screenshot. A moderation system could evaluate visual content against declared policy outcomes.

The Jev interface covered in our original analysis focuses on application state and typed questions. Its documented use cases, listed on the OpenRouter model page and Vercel AI Gateway, involve text based routing, scoring, moderation, verification, and tool selection.

OpenAI's image support gives it an immediate advantage for workflows where the decision depends on visual evidence. The endpoint allows up to 128 images in one request, using base64 data URLs with low, high, auto, or original detail. The quality of that advantage will still depend on image understanding accuracy, processing time, and the visual complexity of the workload.

Decisions API in action

OpenAI's launch demonstration shows how one unstructured sales enquiry can be evaluated across several business questions. The selected message is mapped into six fields: company type, team size, buying stage, requirements, timeline, and requested next step.

This reflects the API's ability to evaluate several independent questions against shared input. The resulting fields can update a CRM record, route the enquiry, select a response template, or create a follow up task. Application code defines the permitted values and decides what each returned answer triggers.

The demonstration reports 81 milliseconds of API processing for six decisions. OpenAI also describes the server side response as taking less than 100 milliseconds in the video. This is a vendor demonstration and does not establish a production latency distribution or an independent benchmark.

Figure 5. OpenAI's inbound sales demonstration maps one unstructured enquiry into company type, team size, buying stage, requirements, timeline, and a requested next step. The interface reports 81 milliseconds of API processing for six decisions. Screenshot: OpenAI, Introducing the Decisions API.

The same video demonstrates a repeated visual decision. The application sends a road frame as the model input and defines three permitted lane choices. Decisions API evaluates the position of the car and obstacles, then returns the selected lane. The application uses that result to update the simulated car's position before evaluating another frame.

This example shows how image understanding can feed a narrow action loop with declared outcomes. The screen reports 194 milliseconds of API processing for the displayed frame. The demonstration is a simulation and does not establish autonomous driving performance, production reliability, or safety critical control.

Figure 6. OpenAI's vision driving demonstration passes a road frame as model input and selects lane 2 from three declared choices. The interface reports 194 milliseconds of API processing for the displayed decision. Screenshot: OpenAI, Introducing the Decisions API.

OpenAI Decisions API pricing compared with Jev

OpenAI prices /v1/decisions at $0.10 per million input tokens, with no output token, cache read, or cache write charge. Long context input multipliers and regional processing premiums may apply.

The published price for Jev 1.13 is $0.042 per million input tokens on OpenRouter, with no charge for output tokens. Cloudflare publishes the same Jev pricing. OpenAI's listed input rate is about 2.38 times higher. Jev's listed rate is about 58 percent lower. That difference can matter for applications making large numbers of small decisions.

The price difference is now measurable. One billion input tokens would cost $100 through Decisions API and $42 through the Jev routes reviewed here, before regional premiums, retries, or provider specific charges. Actual cost per decision will depend on the amount of shared context and the number of requests required by the workflow.

A small price difference matters little for a few thousand decisions. It becomes significant when an agent platform, moderation service, support system, or marketplace evaluates millions of items every month. Teams should calculate the cost per successful decision. This calculation should include input, output, retries, failed requests, human review, and any additional call required to explain a result.

Whether Jev can defend its position through lower cost and higher speed, and whether OpenAI can neutralise that advantage through its own pricing and distribution, are the questions that will decide this comparison.

Speed is valuable when the decision sits in the execution path

Routing decisions often occur before an application can act. An agent must select a tool before using it. A support request must be classified before reaching the correct queue. A safety check must finish before an action receives approval. Every additional delay affects the user experience.

OpenAI describes Decisions API as 10 times faster than the Responses API. That is a vendor claim against another OpenAI interface, not a published benchmark against Jev, and the documentation does not provide an absolute latency distribution. Jev also positions low latency as a central capability. A useful comparison should measure:

1. Median latency
2. Tail latency
3. Performance under concurrent traffic
4. Timeouts and failed requests
5. Latency when several questions share the same context
6. Image processing time

Record the region, provider route, payload size, concurrency, retries, and whether requests are warm or cold. Run enough repeated requests to report p50, p95, and p99 latency. Record these controls alongside the measurements.

Average latency can conceal slow requests. Tail latency matters because repeated decisions can accumulate across an agent workflow. OpenRouter measured a 175 millisecond median and 270 millisecond p95 for Jev in one Banking77 evaluation. That test covered one dataset, one domain, one prompt design, one provider route, and one testing period, so teams should treat it as directional evidence.

Figure 7. OpenRouter's Banking77 evaluation covered one dataset and one published testing setup. This is platform published evidence.

OpenAI Decisions API vs Jev: which decision model fits?

OpenAI Decisions is the stronger starting point for teams that need inline image input, OpenAI data controls, or integration with the wider OpenAI agent ecosystem. Jev deserves the first test when raw input price, provider choice, and specialised decision training carry more weight.

OpenAI's entry creates serious competition for TypeSafe. OpenAI already has extensive distribution across its API products, Codex, and its agent ecosystem. Existing customers may prefer to add Decisions API through a provider they already use.

Jev still has several possible advantages:

• Specialised decision training - Jev is designed around bounded judgments and calibrated outputs. That focus may produce stronger probability quality for decision workloads.
• Lower headline input price - Jev's published input rate is $0.042 per million tokens, compared with $0.10 for Decisions API. Both list free output for these decision calls.
• Multiple integration routes - Jev is available through several providers, giving teams more than one way to reach the model without vendor lock in.
• Clear product identity - Jev has been presented from the beginning as a decision model. Its interface, terminology, pricing, and published evaluations are built around that purpose.

These advantages require validation with real workloads. OpenAI now has a beta endpoint, image input, published probabilities, broad regional availability, and enterprise data controls. Jev will need measurable superiority in cost, speed, calibration, accuracy, or portability.

Interface compatibility will affect competition

The decision model market will benefit from a common request format. Jev receives shared application state and a set of typed questions. Those questions can request a Choice, Score, or Noul result.

OpenAI's published schema has close conceptual matches: choice maps to a bounded selection, score maps to ordered levels, and predicate estimates whether a statement is true. The field names and response objects differ. OpenAI also restricts choice values to strings or Booleans and uses a distinct refusal object. Teams still need provider adapters even when the underlying decision definition is equivalent.

Development teams should avoid connecting business logic directly to one provider's response structure. A small internal decision interface can define:

1. Context
2. Allowed outcomes
3. Confidence
4. Abstention
5. Explanation requirements
6. Usage information

Each provider can then have its own adapter. This keeps evaluations fair and makes future switching easier.

How teams should evaluate OpenAI Decisions and Jev

A useful evaluation begins with a real decision from the product.

Define the decision precisely - List every permitted outcome and describe when each one should be selected. Add an abstain or review outcome where the available answers may be incomplete.

Build a representative dataset - Include common cases, ambiguous cases, rare events, incomplete context, conflicting evidence, and examples that previously required human judgment.

Establish the current baseline - Measure the rules engine, classifier, language model, or human workflow already making the decision.

Test the same cases across providers - Keep the context, allowed answers, and scoring rules consistent. Record every request and response.

Measure more than accuracy. A complete evaluation should include:

1. Accuracy
2. Calibration
3. Abstention quality
4. Median latency
5. Tail latency
6. Cost per decision
7. Failure rate
8. Human review rate
9. Performance after wording changes
10. Performance across text and image inputs

Beyond those ten, a rigorous evaluation should also:

1. Split into a development set for prompt and threshold tuning and a separate test set for reported results
2. Allow each provider's instructions and adapter to be tuned on the development set, then freeze them before testing
3. Report classwise precision, recall, confusion matrices, and the cost of specific error types
4. Evaluate probability quality with Brier score, log loss, reliability diagrams, and expected calibration error where applicable
5. Plot risk against coverage to show how accuracy improves as uncertain cases move to human review
6. Test text and image inputs separately, since Jev's documented interface accepts text while Decisions API accepts both

Requiring identical wording can favour one interface. The decision definition and scoring policy should remain equivalent, while provider specific formatting can differ.

Run in shadow mode. Send production cases to the decision model without allowing it to control the workflow. Compare its selections with the current system and actual outcomes.

Set automation thresholds. Define which results can proceed automatically, which require review, and which must stop.

This process produces evidence that can support a procurement and architecture decision.

What OpenAI's entry means for the wider market

OpenAI's beta release gives decision models greater visibility. Application teams now have a clearer reason to give bounded outputs a dedicated interface while using separate model calls for generated responses, planning, and explanations.

Other model providers and AI gateways are likely to explore similar interfaces. Development frameworks may begin supporting decision requests as a distinct operation. Evaluation products may add calibration and selective automation metrics. Common conventions could emerge around context, answer sets, probabilities, abstention, and usage reporting. The result could become a competitive market containing dedicated decision models, decision interfaces powered by language models, open models, and self hosted alternatives.

Conclusion

OpenAI is entering a market that Jev helped expose. Decisions API and Jev now solve the same class of problem from two directions. Decisions API is available in beta with GPT-6 Luna, a documented endpoint, three typed question formats, probability based outputs, inline image input, and input only pricing.

Jev provides a public decision interface, typed questions, probability based answers, a lower published input price, and multiple integration routes. OpenAI's distribution, image support, data controls, and agent ecosystem create pressure for Jev, while Jev's specialisation and provider portability give it a case to defend. Calibration, refusal and fallback behaviour, latency, and real workload accuracy will determine how the competition develops.

For development teams, the immediate task is to identify the repeated decisions inside their products and build evaluation datasets around them. Those datasets will make it possible to compare Jev, OpenAI Decisions, rules, classifiers, and future alternatives using evidence. The decision model market has moved from an emerging idea to a competitive product category.

The documentation now makes the competitive overlap clear. Controlled evaluations will show which service performs better for a given decision.

Build production decision systems with Clixlogix