LiquidAI: d1-ultra

LiquidAI: d1-ultra is a model from LiquidAI, and it is the largest decision model the provider offers. It sits in the decisions category rather than the general chat category, which tells you what it is for: instead of producing conversational prose, it is built to return a choice. It is served as a System One endpoint, so you should think of it as a component you call to make a decision inside a larger system, not as an assistant you talk to.

The model accepts text and images as input, and its output modality is decisions. You send a state made up of text and images together with typed questions, and it returns a choice. The context window is 32,768 tokens, and the maximum output is 29,491 tokens. Because the inputs are typed questions over a state, the model is designed around structured calls rather than open ended prompting, and the images you include form part of the state the decision is made from.

The practical uses follow from that shape. Anywhere you have a situation that can be described in text and images and a set of candidate answers, d1-ultra can pick one. That covers classification and routing tasks, triage of incoming requests or tickets, selecting an action from a fixed set of options, and judging visual input such as screenshots or photos against a question you supply. It also suits pipelines where a later step needs a single decision rather than a paragraph of explanation, since the output is a decision and not free form text.

You call it through api14's OpenAI-compatible API using the model id "liquid/d1-ultra". Because the endpoint follows the OpenAI request format, you can use your existing OpenAI client libraries and point them at api14. The model lists no supported parameters, so plan on sending the model id and your input, and do not rely on sampling controls such as temperature or top_p being accepted. Check the live price table on this page for current rates before you commit to a high volume pipeline.

One limit to keep in mind is the context window of 32,768 tokens, which has to hold both your text and any images you include, so very large states will need to be trimmed or split. The output is a decision, so if you need generated prose, summaries or explanations, a text generation model will fit better. There is also no parameter surface to tune, so if your application depends on controlling randomness or length through request parameters, this model will not give you that lever.