Liquid AI d1 Decision Model Lands on AI Gateway: No Text Generation, Just Structured Answers

AI Gateway welcomes a model with a completely different approach—Liquid AI's d1. It doesn't generate any text tokens; instead, it makes judgments directly on a shared state and outputs structured answers with probabilities, designed for classification, routing, and scoring scenarios.

What d1 Is: A Decision Model, Not a Generative Model

Traditional large models work by "input a prompt, output a piece of text," and then a program parses that text. d1 skips this step entirely. Its positioning is as a decision model: it receives a shared state and provides answers to predefined typed questions.

The answers themselves are structured—booleans, choices, or scores—and come with probabilities. This means callers get data that can go directly into downstream logic, eliminating fragile post-processing steps like regex matching or JSON parsing.

To illustrate with the original example: the state is "the customer service agent has issued a full refund to the customer," and the question is refunded: { type: 'boolean', instructions: 'Was a refund issued?' }, and d1 directly returns the result of this boolean field. There is no natural language output throughout the process, and thus no parsing ambiguity.

Shared state is the core concept in d1's calling paradigm, referring to a set of contextual data passed in by the caller, which can include text snippets, structured fields, images, and other types. Unlike generative models that concatenate state into a prompt and let the model freely interpret it, d1 treats state as input facts for reasoning and, together with predefined typed questions, determines the output format. "Typed" means that each question, when declared, is bound to a data type for the answer, such as boolean, choice, or score, and the model can only answer within that predefined type space. This approach turns "what the model outputs" from a soft constraint in the prompt into a hard constraint at the interface level. Callers can clearly define which information must be provided and which fields will be filled in when orchestrating the state, thereby coupling decision logic more tightly with business processes and reducing runtime uncertainty.

Visual Input: Asking Typed Questions About Images

d1 also supports visual input. You can pass images as part of the state and then ask typed questions about the image content, for visual classification, inspection, and scoring.

The official example reads a local PNG (square.png) and asks what color the square is: the state includes base64 data with image_url type, the question type is set to choice, and the candidate answers are red, blue, green. d1 returns the selected color and its probability.

This capability is valuable for scenarios like quality inspection, content moderation, and industrial visual sorting—previously, you'd need to train a separate classification model, but now you can use a unified decision interface.

The base64 encoding mentioned here is a method of converting binary data (such as image bytes) into a text string composed of ASCII characters. By encoding image files like PNG into base64, you can embed them as ordinary strings in state fields, transmitting them alongside text data through HTTP/JSON interfaces without additional file uploads or multipart forms. The image_url type field in the state typically accepts both remote image links and data URLs in the form data:image/png;base64,..., the latter being a common way to write inline base64 data. Note that base64 inflates size by about 33%, and inlining large images significantly increases request payload; in practice, it's often combined with compression or on-demand cropping to balance quality and transmission overhead.

Three Ways to Call

On AI Gateway, d1 is served under the identifier liquid/d1, with three access paths:

• AI SDK decision API: Called via experimental_decide (alias decide), passing model, state, and questions.
• OpenAI-compatible Decisions API: Suitable for teams with existing OpenAI call chains to migrate.
• TypeSafe-compatible API: For developers who prefer type-safe interfaces.

The original also notes that specific usage for Choice, Score, and Boolean question types can be found in the decision documentation, and model selection can be browsed in the available models list.

The OpenAI-compatible API means the server exposes capabilities according to OpenAI's interface conventions (request paths, field naming, response structure). Callers only need to replace the base URL and model identifier, and existing SDKs and logic for retries, streaming, error code parsing, etc., can largely be reused, resulting in low migration cost. The TypeSafe-compatible API emphasizes constraints at the type system level, typically generating or providing typed clients so that question fields, answer types, and return structures can be checked at compile time, reducing runtime failures from typos and type mismatches. These two paths coexist with the AI SDK decision API, essentially packaging the same decision capability into different access forms that developers are accustomed to. Teams can choose based on their existing tech stack without having to refactor the entire call chain just to use d1.

Engineering Convenience from AI Gateway

AI Gateway itself provides a unified model access point and tracks usage and costs. d1's decision calls appear in logs just like other model requests and are included in budget statistics.

For teams already managing multiple models on AI Gateway, this means they don't need to set up a separate observability system for d1. Cost attribution, call auditing, and quota control can all reuse existing processes.

What This Kind of Model Changes

From an engineering perspective, d1 represents a division of labor: generative tasks go to language models, judgment tasks go to decision models. Scenarios like routing, classification, and scoring don't need fluent text to prove the result is correct; they need low-latency, interpretable, and verifiable outputs.

The combination of structured answers plus probabilities also allows callers to do threshold control—if the probability is below a certain value, route to human processing; if above, execute automatically. This is an engineering interface that pure text generation models struggle to provide directly.

It's worth watching whether decision models can consistently outperform "small model + prompt engineering" in accuracy. The original article doesn't provide benchmark data, and actual performance still needs to be validated in specific businesses.

Getting Started

If you're already on AI Gateway, you can start testing directly with the liquid/d1 identifier. It's recommended to start with the simplest true/false questions, such as determining whether a ticket has been escalated or whether a conversation contains a refund promise, and then gradually expand to Choice questions with candidate options and visual input scenarios.

One-line Summary

Liquid AI d1 is a decision model that directly outputs structured judgments and probabilities, now available on AI Gateway.

Paragraph Summary

Liquid AI's d1 takes a different approach from generative models: it doesn't generate text tokens but, based on a shared state passed by the caller, directly provides booleans, choices, or scores with probabilities for predefined typed questions. The answers are structured data, eliminating fragile post-processing like regex matching or JSON parsing. d1 also supports visual input, allowing typed questions with candidate answers about images for scenarios like quality inspection, moderation, and industrial sorting. On AI Gateway, it's available under the identifier liquid/d1, with three calling methods: AI SDK decision API, OpenAI-compatible Decisions API, and TypeSafe-compatible API. Call records go into logs and are counted in budget statistics, reusing existing usage and cost tracking. The combination of structured answers and probabilities also supports threshold control, making it suitable for judgment tasks like classification, routing, and scoring, but whether its accuracy can consistently exceed small model plus prompt engineering solutions still needs real-world validation.