Developer comparison · reviewed October 14, 2026

OpenAI Decisions API vs Decide

Choose a model answer, a recorded action gate, or both. OpenAI Decisions API and Decide are separate products with different jobs. This comparison covers Decide Rulebook mode; other Decide modes have their own contracts.

Try the local integration recipe Build an agent action gate Read the Decide API reference

A model answer and an action verdict carry different authority

OpenAI documents predicate, choice, and score questions over supplied input. Answers include probabilities; choice and score answers also expose confidence. A choice can select an application route, but that selection should be evaluated against your own execution policy. OpenAI Decisions API guide.

Documentation comparison. No comparative latency, accuracy, or cost benchmark was run.
QuestionOpenAI Decisions APIDecide Rulebook mode
Primary jobOpenAI Decisions APIEvaluate model questions over text or image input.Decide Rulebook modeApply a versioned declarative Rulebook to supplied facts before software changes state.
RequestOpenAI Decisions APIPOST /v1/decisions: model, input, and questions.Decide Rulebook modePOST /api/decide: Rulebook, binding mode, action context, and inputs.
ResultOpenAI Decisions APIPredicate probability, selected choice, or score. Handle refusal.Decide Rulebook modeyes, no, or review, with a decision_record_v1 artifact and Rulebook lineage.
Application responsibilityOpenAI Decisions APICalibrate routing thresholds using labeled application examples.Decide Rulebook modeSupply trusted facts, verify the record and exact action binding, retain the evidence, and enforce the verdict.
When to holdOpenAI Decisions APIRefusal, an unknown answer, or a result below the application's validated threshold.Decide Rulebook modeMissing facts, unresolved binding, failed verification, no, review, timeout, or error. None permits execution.
Access and pricingOpenAI Decisions APIProvider API access and input-token pricing. Check current availability and rates.Decide Rulebook modeThe Decision API has an access-on-request path. The separate paid Runtime business pilot uses its own terms and interfaces. See current Decide offers.

Decide is an independent product. This page describes compatibility at the application boundary, not an official OpenAI integration or endorsement. Decide's API reference and Rulebook documentation are the sources for Decide claims.

Choose based on the work your application needs

Understand input

Classify an incoming message

If the task is interpreting a message or selecting a category, a model question can supply that answer. Evaluate the classifier with your own labeled cases before routing real work.

Enforce approved policy

Gate a proposed mutation

If an agent wants to assign a ticket, change access, or update a record, Decide Rulebook mode can evaluate the proposed action against explicit trusted facts. Your application still owns execution.

Use both when interpretation precedes a state change

A model may suggest “billing.” Your server can map that choice to a bounded ticket assignment, then check ownership, allowed targets, prohibited actions, and risk under an approved Rulebook. The model does not certify those checks for itself.

Try the model-answer-to-action-gate recipe

This local example turns a fictional classifier answer into a Decide Rulebook request for assigning a ticket. It makes no API calls, spends nothing, creates no Decision Record, and executes no action. The 0.95 confidence threshold is illustrative and needs calibration for your own application.

Download the request builder
Node.js · run beside the downloaded file
node --input-type=module <<'JS'
import { buildActionGateRequest } from './model-answer-action-gate.mjs';
const request = buildActionGateRequest({
  answer: {
    type: 'choice', name: 'department',
    choice: 'billing', confidence: 0.99
  },
  // Fictional server facts. Replace with fresh, authorized checks.
  trustedFacts: {
    prohibited_action: false, low_risk: true,
    target_allowlisted: true, owner_verified: true
  },
  proposal: { run_id: 'demo-1', ticket_id: 'ticket-1042' }
});
console.log(JSON.stringify(request, null, 2));
JS
  1. The builder accepts only the documented choice shape and an allowlisted department. Refusal, unknown category, and insufficient confidence throw a hold error.
  2. Trusted facts come from a separate server argument. Fields appended to the model answer cannot override ownership or policy facts.
  3. The generated Rulebook denies prohibited actions, approves only the bounded case with all required checks, and defaults to review.
  4. The selected department is included in the Rulebook inputs for record verification. The output is a request, not approval. Send it through the existing Rulebook API integration only after adapting and approving the policy.

Bind the exact operation before executing

Keep the ticket ID, proposed department, identity, policy version, and current facts together. Store the full returned record, verify its integrity and action binding, and recheck that the operation has not changed. A classifier answer, a local example, or a bare yes string is insufficient authority. See the caller enforcement guide.

Move from a local example to a verified integration

Application integration

Use the API and JavaScript SDK

Start with a bounded action, an approved Rulebook, and trusted server facts. Follow the documented authentication, idempotency, response, and hold paths.

JavaScript SDKAction gate guide
Evidence and replay

Verify before relying on a record

Retain the complete Decision Record, verify it against the appropriate trust material, and preserve the execution receipt separately.

Record verifierDecision API docs

The on-request Decision API and the separate paid Runtime pilot are different access paths. Downloading this example does not create an account, buy credit, or grant production API access.

Request Decision API accessReview current access and pricing