# Liquid AI d1.1: Pricing, API Access and What Changed

Liquid's updated decision model keeps the $0.02 input price, but the useful comparison starts with what your application needs to decide.

By Paras Madan | 2026-10-24


Liquid AI released d1.1 on October 23, upgrading its hosted decision model for classification, routing and scoring at $0.02 per million input tokens. It is available through Liquid's API and Console. For developers paying a language model to choose between known options, this is a more specialised alternative worth evaluating.

In its [launch announcement](https://x.com/liquidai/status/2113678429040304354), Liquid says d1.1 improves decision quality over d1 and moves closer to d1-ultra while running with lower latency. Those are the company's comparisons, not independently verified results presented here.

The more useful question is where a decision model belongs in an application. A support system may need a long answer for a customer, but deciding which queue receives the message is a much smaller task. The two steps do not necessarily need the same kind of model.

## d1.1 pricing compared with d1 and d1-ultra

Liquid's announced d1.1 input price matches the earlier d1 rate. The reduction is relative to d1-ultra, not a newly halved d1 price.

| Model | Price per million input tokens | Output-token charge |
| --- | --- | --- |
| Earlier d1 | $0.02 | None |
| d1.1 | $0.02 | None |
| d1-ultra | $0.042 | None |

The [public pricing page](https://www.liquid.ai/pricing) still labels the lower-priced tier d1; the d1.1 announcement supplies the new model's price. At these rates, 100 million billed input tokens cost $2 on d1.1 versus $4.20 on d1-ultra, before any other application costs.

There is an important billing detail in the [decision-model overview](https://docs.liquid.ai/lfm/models/decision-models): **each question is charged for its input, including supplied images**. Asking three questions in one request does not mean paying for the shared material only once. Combining questions can reduce network round trips without reducing the bill in the same proportion.

That matters more than it first appears. A pipeline that classifies a message, scores its urgency and checks a separate condition has three decisions, even if the developer sees a single API call.

## How the d1.1 API works

The [hosted API documentation](https://docs.liquid.ai/lfm/models/d1) identifies `d1.1` as the default hosted model. Requests go to `https://api.liquid.ai/decisions/v1/systemone`, with a model name, context in `state`, and named questions in `questions`.

The model accepts text and images. Python and TypeScript SDKs are documented for text, but image requests currently require direct HTTP calls because the SDKs do not yet support them. Images must be encoded in the request; remote image URLs are not accepted.

Liquid provides three answer types. `Choice` selects among named categories and returns their probabilities. `Noul` answers a yes-or-no question with a probability. `Score` evaluates an ordered rubric rather than writing a free-form explanation.

The model returns these decisions without generating output tokens. For a routing step, your application can use the chosen category directly instead of generating a sentence and extracting the department name from it.

Liquid's announcement says OpenRouter and Vercel support for d1.1 is coming. Availability of the earlier d1 or d1-ultra on those platforms should not be confused with availability of this release.

## What to test before replacing an LLM call

Liquid's [migration guide](https://docs.liquid.ai/guides/decision-model-guide) makes the useful boundary explicit: decision models suit tasks where the possible answers are known beforehand. Drafting the customer's reply, explaining a complicated issue or planning several steps still requires a different capability.

For a support router, start with historical messages whose correct queues are already known. Compare wrong-queue rates, ambiguous cases and response times against the current system. A cheaper call offers little benefit if it sends enough requests to the wrong team to create another manual sorting step.

Probability outputs also need testing. A confident result is not automatically a correct one, and thresholds that worked with the previous model may behave differently after an upgrade. Keep a fallback for uncertain cases rather than treating every returned category as permission to act.

The interesting shift is that the routing layer can become cheap enough to evaluate separately from the model doing the main work. **The real saving depends on keeping the decision narrow**: selecting the right next step without asking a general-purpose model to compose an answer that nobody will read.

I'm Paras. I work at the intersection of AI, engineering and distribution.

I help technical founders turn product updates and engineering decisions into clear stories developers can understand and share.

[Book a 30-minute call](https://cal.com/paras-madan/30min).