Skip to main content
POST
A decision model answers typed questions about an input and returns probabilities over a closed set of answers instead of generating text:
  • predicate: the probability that a statement holds;
  • choice: the chosen option, with the probability of every option;
  • score: a position on an ordered scale, with the probability of every level.
The request and response follow OpenAI’s Decisions API, so the OpenAI SDKs (openai-python 3.26.0 or later, openai-node 7.30.0 or later) work by changing only the base URL. The same route serves every decision model on Bud, whichever provider answers it: Bud translates the request for providers that speak the System One format. To send System One requests yourself, use POST /v1/systemone. model is the name of your deployment. A deployment serves this route when its model lists the Decisions API, which you can check with GET /v1/models?capability=decisions.

Decision models

A gpt-6-luna deployment created before your Bud release added the Decisions API does not serve /v1/decisions until it is redeployed. Deploying again adds the route; existing deployments are not widened automatically.

Headers

Body

Other top-level fields are forwarded to OpenAI and Azure unchanged, and dropped for System One providers.

Input

input is a string, or an array of items in the shape the Responses API uses. To decide about a structured record, send it as one input_json part:

Questions

  • instructions is required: a non-empty string, or an array of input_text, input_image and input_json parts.
  • name is optional. When set it must be non-empty and unique across the request, and the answer carries it back. An unnamed question is answered with "name": null.
  • Any other field inside a question, a choice or a level is refused with 400 unknown_parameter, and param names it (for example questions[1].choices[0].weight).

Response

confidence is the provider’s own figure, not the largest probability. Probabilities are each model’s own estimates: they are not comparable across models or providers, so set thresholds per model. Response headers carry the usual x-bud-* set, plus x-bud-decisions-provider-format (openai or system_one), which says which wire format answered.

Limits

The gateway checks every request against OpenAI’s limits, whichever provider will answer it: A provider with stricter limits is then checked before the call. A request over a provider’s limit is refused with 400 limit_exceeded, and the message gives the provider’s limit. It is not split into smaller requests.

Providers

OpenAI and Azure OpenAI

The request is forwarded as sent, with model replaced by the provider’s model name (on Azure, the deployment name). Images, prompt_cache_key, prompt_cache_options, safety_identifier and refusals all work as in OpenAI’s API.

System One providers

TypeSafe, servers added with the System One compatible provider, and other System One vendors in the catalog speak the System One format. Bud translates the request and the answers, with these differences:
  • No images. input_image parts in the input or in instructions are refused with 400 unsupported_input before the call.
  • Conversations become text. An input of messages or tool items is sent as a plain-text transcript, one block per item (user: …, assistant: …, tool_call …, tool_result …). Roles survive as text, not as structure. A string input, or a single user message holding a single input_json part, is sent as is.
  • Descriptions become text. Choice and level descriptions reach the provider as part of the option text; level probabilities are mapped back by index.
  • Cache and safety fields have no effect. prompt_cache_key, prompt_cache_options, safety_identifier and other top-level fields are not sent.
  • No refusals. System One providers always answer every question.
  • Bearer authentication only. The provider is called with Authorization: Bearer; a server that needs another header is not supported.
  • Usage is the provider’s input_tokens and output_tokens; cached_tokens, cache_write_tokens and reasoning_tokens are always 0.

TypeSafe

  • Models: jev-latest (currently jev-1.14.0), and the pinned jev-1.14.0 and jev-1.13.0. The response model is your deployment’s name, so deploy a pinned version when you need to know which one answered.
  • Up to 255 choices and 10 levels per question. TypeSafe sets no question limit of its own, so Bud’s 400 applies.
  • Context: 64K tokens per request and 32K per question. TypeSafe’s long-context mode is not used.
  • TypeSafe reports output tokens (about 20 per question) but does not charge for them: the catalog prices input tokens only (USD 0.042 per million at the time of writing), with output at 0.

Embedding Studio

Embedding Studio is not a System One server; Bud calls its decide API with its own adapter and returns the same response shape. The System One differences above apply, except authentication: Bud sends Embedding Studio’s own X-API-Key header.
  • Model: laya. Up to 400 questions, 128 choices and 10 levels per question; no images.
  • Priced per request, not per token. Embedding Studio charges per record whatever the number of questions (USD 0.002 in the catalog), and reports no token counts, so every usage field is 0. An Embedding Studio deployment is therefore priced per request only: a per-token price would cost every call nothing, and is refused. See Billing.
  • choice is the option with the highest probability, and score is the expected level index computed from the returned distribution. confidence is Embedding Studio’s own.
  • Abstention is not returned. Embedding Studio can mark an answer as abstained (with the set of options it could not separate, and a review route). The Decisions API has no field for that, so it is not passed back: you get the full distribution and can apply your own threshold. Embedding Studio projects (fitted heads) and templates are not reachable through Bud.
  • Errors keep Embedding Studio’s status, with its message cut to 512 characters. A spent account balance is returned as 402 provider_payment_required.

Billing

  • Cost is input tokens at the deployment’s input price (cached tokens at the cached-input price when one is set), plus output tokens at the output price. Decision models usually report no output tokens, or do not charge for them.
  • OpenAI counts cache writes inside input_tokens; they are billed at the input price.
  • A deployment without a price records no cost.
  • A per-request price applies only to a deployment that serves nothing but decisions. A deployment that also serves chat is priced per token, so a per-request provider behind it stays unpriced. A provider that reports no tokens (Embedding Studio) is priced per request only.
  • Every successful call counts toward the project’s usage limits. A call over a limit is refused with 402 before the provider is called.
  • Responses are not cached: identical repeated calls are sent to the provider and billed each time.

Guardrails

If the deployment has a guardrail profile, the input is checked before the provider is called: string input, input_text parts, input_json data, message text, and tool-call arguments and outputs. Question instructions are not checked. A blocked request returns the same error as a blocked chat request, and the provider is not called.

Not supported

  • Streaming (stream: true).
  • Request retries and fallback_models: a failed decisions call is not retried and does not fall back to another model.
  • box questions, and images on System One providers.

Errors

Errors use OpenAI’s error format; param names the field at fault when there is one.
400