OpenAI Decisions API on Vercel AI Gateway: Setup and Limits

Since 7 October 2026, OpenAI's Decisions API has been available through Vercel AI Gateway at /v1/decisions, according to Vercel's changelog entry. The OpenAI Decisions API is OpenAI's interface for asking a model typed questions about a shared input. It returns structured answers (a probability, a selected option or a rubric score) instead of generated text. On AI Gateway it keeps OpenAI's request and response format, so an existing OpenAI SDK integration switches by changing the base URL, credentials and model ID.

What Vercel added to AI Gateway

OpenAI defines the API; Vercel adds the routing. The gateway endpoint answers with any decision model it hosts, not only OpenAI's. The models include openai/gpt-6-luna-decisions for OpenAI's GPT-6 Luna Decisions model, plus Jev, Liquid d1 and Laya from other providers. GPT-6 Luna Decisions is a separate model from openai/gpt-6-luna, which generates text.

Requests through the gateway also accept AI Gateway providerOptions, so you can require zero data retention, restrict which providers serve the call, or add a decision fallback. Per the AI Gateway decision documentation, decisions are not available through Chat Completions, Responses, or the Anthropic-compatible and Cohere-compatible endpoints.

Which question types does the OpenAI Decisions API take on the gateway?

The endpoint takes three question types: a yes/no predicate, a choice and a graded score. Each question needs a type and instructions, and the answers come back in question order. A choice question also suits tagging a shopper's query by intent before it reaches AI search, rather than asking a chat model to label it in prose.

A question name is optional, and an unnamed question comes back with name: null, but names must be unique within a request. Choice values can be strings or booleans; a string and a boolean with the same text, such as true and "true", can't both appear in one question. If the model declines a question, that answer comes back as a refusal in its position and the others are answered normally. The request is still billed for its input.

A worked example: triaging a store's support tickets

Take a store whose helpdesk receives a ticket saying a package arrived with a broken screen and the customer wants a refund. The OpenAI-compatible Decisions API documentation uses this ticket to show three questions answered in one call: whether the customer reports a damaged item, which queue should take it, and how urgent it is.

import OpenAI from 'openai';

const openai = new OpenAI({
  apiKey: process.env.AI_GATEWAY_API_KEY,
  baseURL: 'https://ai-gateway.vercel.sh/v1',
});

const decision = await openai.decisions.create({
  model: 'openai/gpt-6-luna-decisions',
  input: 'The package arrived with a broken screen. I want my money back.',
  questions: [
    { type: 'predicate', name: 'damaged',
      instructions: 'Does the customer report a damaged item?' },
    { type: 'choice', name: 'queue',
      instructions: 'Which team should handle this ticket?',
      choices: [
        { value: 'billing', description: 'Refunds and payments' },
        { value: 'shipping', description: 'Delivery and damaged items' },
      ] },
    { type: 'score', name: 'urgency',
      instructions: 'How urgent is this ticket?',
      levels: [{ label: 'low' }, { label: 'medium' }, { label: 'high' }] },
  ],
});

The response lists the answers in question order, along with the model that answered, token usage and gateway routing and cost metadata. Trimmed to the model, answers and usage, the documented example looks like this:

{
  "model": "openai/gpt-6-luna-decisions",
  "answers": [
    { "type": "predicate", "name": "damaged", "probability": 0.95 },
    { "type": "choice", "name": "queue", "choice": "shipping",
      "confidence": 0.81,
      "probabilities": [
        { "value": "billing", "probability": 0.19 },
        { "value": "shipping", "probability": 0.81 }
      ] },
    { "type": "score", "name": "urgency", "score": 1.3,
      "confidence": 0.62,
      "probabilities": [
        { "value": 0, "label": "low", "probability": 0.08 },
        { "value": 1, "label": "medium", "probability": 0.54 },
        { "value": 2, "label": "high", "probability": 0.38 }
      ] }
  ],
  "usage": { "input_tokens": 96, "output_tokens": 0, "total_tokens": 96 }
}

The routing code reads three typed fields: probability on the predicate, choice on the queue question and score on the urgency question. A score is the probability-weighted average of the level indexes, starting at 0, so 1.3 sits between medium and high. The confidence and probabilities fields appear only when the answering model returns them, so treat them as optional.

One way to wire it: the helpdesk posts each new ticket to a small serverless function that makes this call and writes the answers back as ticket tags. Nothing in that path parses a text completion. The same shape works inside an agent: before an agent built on ACP, MCP or UCP completes a checkout, a predicate can ask whether the request needs a human first.

SDK versions you need

Decision calls need a recent client, or a plain HTTP request to the gateway.

The AI SDK names its yes/no type boolean and keys questions by name in an object, while the OpenAI-compatible endpoint uses predicate and an ordered array. Pick one shape per codebase rather than mixing both, so the routing code reads one format.

Limits and behaviour to plan for

Validation errors use the OpenAI error format and set param to the field that failed. Errors from routing, billing or the model provider use AI Gateway's format, where param can carry details such as the model ID. Log both shapes, because a retry policy that only reads one can misclassify the other.

What should you do next?

Decision models were previously called evaluation models, and nothing breaks if you leave existing calls alone. experimental_evaluate and gateway.evaluationModel() still work as deprecated aliases with the same request and response shapes, and /v1/evaluate still answers. Move to /v1/decisions when you want the OpenAI SDK surface, and do it one decision at a time.

1. Find one decision you make with a prompt and a parser. Ticket routing, review moderation and a refund rubric are typical candidates.
2. Upgrade the client to the minimum version in the table above.
3. Point it at the gateway: base URL https://ai-gateway.vercel.sh/v1, your AI Gateway key and a decision model ID.
4. Check CI for stale API keys before relying on OIDC.
5. Add a fallback only where an uncertain answer needs a second model, and budget for the second billed stage and its latency.

If the ticket tags should trigger in-store actions, our Shopify Flow AI automation patterns cover that step. If the decision feeds an agent, the Shopify MCP server guide covers the commerce tools that agent calls next. When you want the routing built and tested against your own tickets and catalogue, our ecommerce development team can scope it.