Liquid AI's d1-ultra: When an AI App Needs a Decision

Some AI tasks end with a choice: route a bug report, assign a category, or decide whether an image needs review. A paragraph explaining the answer may be useful, but it is not always the output the application needs.

Liquid AI's October 15 announcement of d1-ultra targets that narrower job. The company describes a model that accepts text, images, or both and returns probabilities for predefined answers. For application engineers, the useful question is whether that contract fits the task, and how to evaluate it without mistaking a probability for proof.

Define the decision before choosing the model

According to Liquid's announcement, d1-ultra answers one or more questions in a single forward pass without generating tokens. That is the vendor's description of its execution, not an independently verified account of the architecture.

The application supplies the decision space. Instead of requesting an unrestricted response, it specifies the question and the allowed form of the answer. A bug-report router, for example, could ask which component should receive a report. This is a hypothetical use case, not a tested integration.

That boundary takes design work. If the categories overlap, the model still has to choose among overlapping categories. If a valid outcome is missing, a constrained response cannot add it. Before evaluating the model, write down what each answer means and how the application should handle inputs outside those definitions.

Three answer types, three different meanings

Liquid's decision-model documentation defines three primitives:

• Noul returns a yes/no probability between zero and one.
• Choice returns a probability distribution over named categories.
• Score returns a probability-weighted position on an ordered rubric.

The distinction matters when defining the task. A yes/no question might ask whether a report contains enough information for review. A category question might route it to a component. An ordered rubric might rate how completely the report describes steps to reproduce a problem.

Those are different judgments, even when they use the same input. A completeness score should not quietly become a measure of urgency. An ordered rubric needs descriptions of what its positions mean; otherwise, a precise-looking score leaves too much room for interpretation.

The hosted d1 documentation describes one answer per question, keyed by its name. Noul returns a single probability. Choice and Score also include the full distribution and a confidence value. Treat these as documented response fields, not evidence that confidence will predict correctness on your data.

Read the request as a contract

The launch post's request example uses https://api.liquid.ai/decisions/v1/systemone with model: "d1-ultra", a state, named questions, and an optional images array containing a base64 data URL. This is a description of the published example, not a request exercised for this article.

For an integration review, inspect how those pieces relate. What information belongs in the state? Does each question describe one decision clearly? Can the application match every returned answer to the question it submitted? These checks help turn an API example into a specification for a particular task.

Deployment assumptions need the same care. Liquid's overview distinguishes hosted d1-ultra from the separately listed open-weight d1-3B and d1-omni-600M models. An open-weight base model does not establish that d1-ultra itself has downloadable weights. This article concerns the announced Liquid API, not a local deployment guide.

Count questions when estimating cost

One request does not necessarily mean one charge for its shared input. Both the announcement and the overview say each question is billed as its own prompt, including its text and all supplied images.

That detail belongs in the application design. If an image accompanies several questions, do not estimate the request as though the image were charged only once. Review whether each question is necessary for the decision the application will make.

The October 15 announcement quotes $0.042 per million input tokens and says there are no output tokens. That is the announcement's quoted launch price, not a verified current tariff or a promise about the final bill. A budget should use confirmed pricing and the intended question structure before it informs a purchase decision.

There is no basis here for calling the approach universally cheaper than a language model. The relevant comparison is the cost of handling the same task to an acceptable standard, including whatever review process you retain.

Evaluate the probabilities and the fallback

The available sources describe Liquid's product and intended use. They do not provide independent performance validation for this article. No API tests were performed, and no latency or accuracy result is being claimed.

A useful evaluation would start with representative labeled inputs and agreed answer definitions. Include ambiguous reports and images that do not give enough information to decide. Review errors by category rather than relying only on an overall result. A model that routes common reports acceptably might still need a fallback for an uncommon category.

Check whether probability estimates correspond to observed correctness on that evaluation set. Choose thresholds from the task's requirements and evaluation results, rather than assuming that a high number is sufficient. Define what happens below the threshold: human review, a request for more information, or no automated decision.

Start with one bounded task

Liquid's guidance recommends decision models for classification, routing, scoring, and triage. It recommends language models for free-form generation, conversation, summarization, code generation, and complex multi-step reasoning. That is intended-scope guidance from the vendor, not comparative proof.

For an initial evaluation, choose a task with a fixed answer space and an outcome you can check. Write the rubric first. Assemble labeled examples, define the fallback, and account for every question in the cost estimate. Only then compare the documented API contract with the application's requirements. The practical next step is a small, explicit evaluation plan, not a production commitment based on the launch announcement.