OpenAI Decisions API vs Jev: contracts, costs and migration

A decision API answers a bounded question without requiring your application to interpret a generated essay. OpenAI now documents a dedicated endpoint for that workload. Its guide currently calls the service a public beta and supports gpt-6-luna. Earlier launch coverage described a limited preview, so check the current documentation rather than carrying the launch status into a new integration plan. “Decision API,” “decisions API” and “OpenAI decision model” searches often point to the same product question. This guide covers them together so the important comparison is the contract your application needs, not a separate page for every wording.

OpenAI predicate questions ask about a proposition; Jev Noul provides the probability of true. Both can support a binary business rule, but your threshold remains a separate policy. Choice asks for a categorical outcome. Score evaluates an ordered rubric, and its value may be fractional rather than a selected integer level. Keep probability and confidence distinct, and do not assume that a probability threshold tuned for one provider transfers to another. A useful migration specification names the allowed outcomes, describes each boundary and states what happens when evidence is insufficient. That specification should be readable by your reviewer without referring to either SDK.

This original example follows the documented request shape. Send it from a server with an OpenAI credential after confirming access and current terms. It is not a JevModel request and has not been run as a paid test for this article. The named question uses an array of choices rather than Jev’s criteria object. Keep a review option for mixed or insufficient evidence. A successful HTTP response still needs answer validation before your program treats it as routing data.

curl --fail-with-body https://api.openai.com/v1/decisions \
  -H "Authorization: Bearer $OPENAI_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"model":"gpt-6-luna","input":"The export fails and the customer asks about a duplicate invoice.","questions":[{"type":"choice","name":"queue","instructions":"Select the next review queue from the evidence.","choices":[{"value":"billing","description":"Only a payment or invoice issue needs review."},{"value":"technical","description":"Only a software error needs review."},{"value":"review","description":"Multiple issues or insufficient evidence need human review."}]}]}'

The OpenAI guide describes an answer array identified by question name, including a refusal answer type. Choice probabilities are an array of value/probability pairs, with confidence as a separate field. Do not feed that structure into a Jev parser expecting an object keyed by question ID. Match names rather than trusting array position, verify that every required answer exists, and reject unknown labels. Missing answers, invalid distributions, refusals and upstream failures should lead to defined application outcomes. A refusal is not the same event as a low probability; log those conditions separately. Validate the adapter with saved illustrative fixtures before enabling live calls.

OpenAI documents text and image input for Decisions. Its image instructions require inline base64 data URLs rather than hosted image URLs or file IDs. That transport detail belongs in the adapter and payload validation, not in a model’s business categories. Avoid converting a media capability into an assumption that all three services accept the same image format or request size. JevModel’s current public API accepts its documented state and question shapes; it is not an OpenAI media gateway. For a production proposal, verify account access, current limits, retention settings and service status in the provider’s own documentation. A beta label should prompt a reversible rollout and a clear owner for future API changes.

The OpenAI guide checked on October 7 lists $0.10 per million input tokens and no output or cache-read/write charge for Decisions, with applicable regional and long-context premiums. That figure is direct provider pricing, not JevModel’s service catalog. Estimate using representative requests after question definitions and necessary context have been included. Then add retries, review effort and operational overhead. A cheaper request can create a more expensive workflow if it sends more cases to a person or makes more costly mistakes. Conversely, a provider with a higher unit rate may need fewer repeated calls. Record the pricing date and recheck terms before a purchase or rollout.

Freeze an independently labeled test set before choosing the provider. Include difficult examples that challenge your preferred model, not just its easiest demo. Run each candidate under the same taxonomy, then inspect automated coverage, wrong-route rate, review volume, latency and unavailable responses. Tune thresholds on separate examples. Report task-specific errors and explain which mistakes matter most to the workflow owner. Keep the current integration active while the candidate runs in shadow mode. Cut over only after the response adapter and accepted-decision results meet written requirements. Preserve a rollback that does not depend on changing customer records back manually.

That search phrase expresses a competitive claim, not an established technical result. A dedicated OpenAI endpoint creates another option for bounded decisions. It does not measure your Jev integration, settle your privacy requirements or demonstrate that existing classifications became wrong overnight. The useful question is narrower: can the alternative meet your task’s error budget and service constraints at a better complete cost? Keep Jev when its measured results and operating contract meet your needs; pilot another provider when it solves a documented gap. Use the generative model for the open-ended explanation and the chosen decision service for the bounded branch, while your own code retains permission to execute an action.