Bifrost's /v1/decisions: one API for decision models across eight providers

Bifrost added /v1/decisions with TypeSafe's Jev in September. With v2.3.1, the same endpoint now serves decision models from eight providers, plus any self-hosted decision model you add as a custom provider.

Decision models score defined outcomes and return probabilities directly, rather than generating free form text like language models. Following TypeSafe's release of Jev, enterprises are adopting them for content classification, request routing, and anomaly detection.

Native decision models are available through POST /v1/decisions from TypeSafe, OpenAI, OpenRouter, Perplexity, Cloudflare, Azure, Databricks, and Ollama. These models can also serve as classifiers in the Complexity Router.

Bifrost also supports Jev's image inputs and the experimental box question type from Jev 1.14, which is currently available only on jev-1.14.0.

Typed answers through /v1/decisions

The unified API supports three question types:

Type	What it returns	Example use
Predicate	The probability that a statement is true	Assess whether a request requires a change to a public API
Choice	A selection from the options you provide	Classify a task as simple, medium, or complex
Score	A position on an ordered rubric	Rate the depth of review a proposed change needs
Box	A single bounding box around the object you describe in an image	Locate the error banner in a screenshot

A predicate returns a probability rather than making the application's threshold decision for it. A score can fall between rubric levels. These distinctions let you decide how each answer translates into an action. Box requires jev-1.14.0 and is a TypeSafe primitive only.

One request format across all Decision model providers

Provider APIs can represent judgments differently. Bifrost handles those conversions behind a shared request and response structure.

A request contains an input and a questions array. Each question declares its type, instructions, and any choices or score levels it needs. You can also name questions to make their answers easier to identify.

Set BIFROST_BASE_URL to your gateway's URL, then send a classification request:

The request returned the following response.

The model selected the task complexity as "complex", assigning it a probability of 0.99, compared with 0.01 for medium and 0 for simple. The response also identifies the model version that answered and reports token usage.

Answers follow the question order. Probability distributions and confidence appear when the model supplies them. Here, confidence is 0.98, a separate provider-defined summary of the distribution; it should not be read as the same quantity as the selected option's probability. Your application can use the selected option and its probability to decide what happens next.

Text, structured data, and image inputs

The unified API accepts plain text, structured JSON objects, and message arrays under the input field. Message content can contain input_text and input_image parts, so an image capable decision model like Jev, clef-flash or gpt-6-luna can evaluate text and images in the same request. Image parts use image_url for a base64 data URL or an HTTPS URL; Ollama requires base64 images.

For image based decisions, use the unified payload with a model that supports images, such as an appropriate OpenAI, Cloudflare, Perplexity, or Ollama decision model.

TypeSafe's Jev accepts images as an experimental "danger zone" feature (jev-1.13.0 and jev-1.14.0). TypeSafe advises that models, Jev included, perform worse on images than on text alone, so we recommend avoiding production usage and keep each question as simple as possible.

See the Decisions quickstart for complete requests, input formats, and the provider image-support table.

Keep your existing TypeSafe or OpenAI payload

Bifrost also provides integration routes that preserve TypeSafe's and OpenAI's native request and response formats. Existing clients can keep their payload shape and point to the corresponding integration base URL:

Route	Request format	When to use it
POST /v1/decisions	Bifrost's unified input and questions array	A consistent format across decision providers, including image inputs on supported models
POST /typesafe/v1/systemone	TypeSafe's state and named questions map	An existing TypeSafe payload or SDK, with its base URL set to ${BIFROST_BASE_URL}/typesafe
POST /openai/v1/decisions	OpenAI's native Decisions API format	An existing OpenAI Decisions payload or SDK, with its base URL set to ${BIFROST_BASE_URL}/openai/v1

If your application already sends state and a question map to TypeSafe's /v1/systemone, it can retain that body and use Bifrost's /typesafe/v1/systemone route. The named map remains the native TypeSafe format; its deprecation applies to the earlier map form on Bifrost's unified /v1/decisions endpoint.

The integration routes can also reach other supported decision providers when the model name includes a provider/ prefix. The route determines the payload format; the selected model determines the input capabilities. OpenAI's integration retains its native image-input format as well.

Choose the provider that fits your deployment

Bifrost supports native decisions through these providers:

Provider	Example model
TypeSafe	typesafe/jev-latest
OpenAI	openai/gpt-6-luna
OpenRouter	openrouter/~typesafe/jev-latest
Perplexity	perplexity/pplx-decider-v1.1-27b
Cloudflare	cloudflare/@cf/cloudflare/clef-flash
Azure	azure/microsoft-decision-1
Databricks	databricks/ai_decide
Ollama	ollama/tev1:0.8b

Once a provider is configured, switching to another supported decision model changes the model field while retaining the request structure. Ollama lets you use locally pulled System One models through the same gateway endpoint.

It is important to note that a shared API does not make every model interchangeable. Input capabilities, confidence fields, and classification behavior can differ. Evaluate a new model against representative inputs before using it for the same application decisions.

Native decision support also applies to specific models, rather than every chat model a provider serves. For models without a native decisions endpoint, Bifrost offers optional decision to Responses emulation through the compatibility setting convert_decision_to_responses. That conversion is opt-in with default off.

Add self-hosted decision models as custom providers

Decision model support extends to custom providers too. Add a custom provider, select the base format Typesafe and enable Decisions under allowed request types. TypeSafe compatible and OpenAI compatible endpoints can use their respective base formats.

For example, self-hosted Laya and Nimble servers expose TypeSafe's System One API. Add them with TypeSafe as the base format, then call models such as laya/english or Bespoke's nimble/nimble-latest through v1/decisions. They can also serve as Complexity Router classifiers.

See the self-hosted decision-model guide for setup, model listing, and authentication options. Both of these self-hosted integrations are text-only; if you run their System One models through Ollama instead, use Bifrost's built-in Ollama provider.

Use decision models in the Complexity Router

The Decisions API is useful when your application explicitly needs a judgment. The Complexity Router uses that same capability inside Bifrost to help classify incoming requests and route them to the most relevant model.

With the decision-model classifier, Bifrost evaluates the latest user task and assigns it to a Simple, Medium, or Complex complexity tier. Routing rules can then use that tier to select a model:

For example, you could send straightforward tasks/user requests to a faster, smaller and cheaper models like GPT 5.6 Luna or Haiku 5.5 and route work involving complex constraints to a model suited to deeper reasoning like Opus 5.5. The classifier chooses the tier; your configured routing rule chooses the model that answers the request.

TypeSafe's Jev is the default decision classifier. You can select a supported decision provider and model as well. You can also customize each tier's definition, signals, and examples to match your workload.

Keep decisions inside the gateway workflow

Decision requests use configured provider credentials and can include cross-provider fallbacks. For example, a request can start with TypeSafe and try Cloudflare or OpenAI if the first attempt fails. Keep input compatibility in mind when selecting the fallback models.

Bifrost records decision usage, and decision-model classification costs are included in routing cost accounting. That makes the classification step part of the operational picture when comparing serving strategies.

Try it

Start with the Decisions quickstart to make your first request, or configure a classifier in the Complexity Router. Both use the same native decision model support, whether the judgment is needed by application code or by the gateway's routing rules.