Liquid AI d1 API: hosted or local?

Liquid AI d1 is worth evaluating when your application needs a category, a yes/no decision or a score. The hosted d1 API is priced at US$0.04 per million input tokens, with no generated output tokens. For local deployment, d1-3B handles text and images, while the smaller, experimental d1-omni-600M also handles speech. These are distinct deployment options; sharing a family name does not establish identical quality.

Start with the hosted API if you want to evaluate a workflow without operating a model server. Evaluate the open weights when offline execution, control over data movement or device latency matters. The lower token bill alone is a weak reason to self-host at this hosted rate.

What d1 does and where it fits

Liquid announced the hosted model on October 5 and the open checkpoints on October 7, 2026. The family produces typed decisions in a forward pass instead of writing an answer token by token. Its three question types are:

• noul: a yes/no question returned as a probability, such as whether a support ticket requests a refund.
• choice: a selection from named categories, with probabilities for the options.
• score: a probability-weighted position on an ordered rubric you define.

This fits ticket routing, search-result reranking and checks over text or images. It does not replace a model that must compose code, summarize a document or explain a decision in prose. Liquid's migration guide makes this bounded-decision distinction explicit. For another decision API, our Jev guide covers its separate integration contract.

Hosted d1 vs d1-3B vs d1-omni-600M

The 600M model card adds important limits: one request accepts images or audio, not both; with images, state and question text is cut to 896 tokens. Audio is a 16 kHz mono clip of up to 30 seconds, trained on English speaker–assistant requests. Do not treat that as verified multilingual speech accuracy or a transcription service.

Liquid reports 48.57 for d1-3B and 15.95 for d1-omni-600M on Decision Index 0.2.1, using its official scorer rather than leaderboard submissions. These vendor results support evaluating the larger model when quality matters; they do not establish that it wins every classification task. Nor do they measure the hosted d1 model's equivalence to either checkpoint.

What the $0.04/M hosted price actually buys

The hosted announcement's methodology quotes US$0.04 per million input tokens. The API documentation says each question is charged for its text and all supplied images. Several questions in one HTTP request therefore do not mean that a shared input is billed just once.

For a hypothetical 100,000 requests with 1,000 billed input tokens per question:

• One question each: 100,000 × 1,000 ÷ 1,000,000 × US$0.04 = US$4.
• Three questions each, each totaling 1,000 billed tokens: US$12.

These are token-charge calculations, excluding taxes and other charges. Actual question lengths and retries change the total; read usage.input_tokens rather than counting only the visible state text. usage.output_tokens remains zero even though the HTTP response contains JSON.

Images contribute ceil(ceil(width / 32) × ceil(height / 32) × 1.5) input tokens per image, per question. A 1024 × 1024 image adds 1,536 tokens, or US$0.00006144 at that rate, before text. Three questions about that image add 4,608 image tokens. This is an image-understanding charge, not an image-generation price or an OmniaKey quote.

Is local deployment cheaper?

Use a monthly budget instead of comparing “free weights” with a token rate. Include hardware depreciation or rental, electricity, engineering time, monitoring, license fees when applicable, and the cost of handling failed decisions.

As an explicitly hypothetical example, US$50 per month of local costs equals 1.25 billion hosted input tokens at US$0.04/M: 50 ÷ 0.04 × 1,000,000. At 1,000 billed tokens per request, that is 1.25 million requests. It is a billing comparison, not a hardware quote or proof that either local model matches hosted quality.

Local inference can still be the right choice well below that volume if connectivity, data boundaries or latency is the deciding requirement. Compare total operating cost divided by accepted decisions, while keeping errors and human review visible. A lower-cost wrong route is not a saving.

License and hardware checks before downloading

Both repositories use LFM Open License v1.0. Liquid's license guide describes free commercial use below US$10 million annual revenue and a separate commercial license above the threshold. At the boundary, confirm eligibility with Liquid against the actual license wording. Redistribution also has notice, attribution and modified-file requirements; downstream commercial users must evaluate their own eligibility. Read the d1-3B license and 600M license for the artifact you ship. “Open weights” does not mean unrestricted Apache-2.0 licensing.

For memory planning, parameter count × two bytes gives only 16-bit weight storage: approximately 6.24 GB for d1-3B and 1.174 GB for the 587M model, in decimal units. These are calculated storage amounts, not minimum RAM or VRAM requirements. Runtime buffers, activations, media processing and batching add memory; quantization changes both footprint and potentially decision quality.

The 3B model card reports a warm single-question call at 8 ms on RTX 4090 and 30 ms on Apple M5 Pro. For its 3.4K-token state, those figures become 102 ms and 640 ms. The RTX 4090 result uses compilation. These are vendor measurements with specific inputs, not cold-start times or an API latency promise. Liquid does not publish inference timing for the experimental 600M model in its card.

Calling the hosted API and running locally

The hosted contract uses POST /decisions/v1/systemone, rather than the Chat Completions schema. Set LIQUID_API_KEY to a key created in Liquid's console. The following example uses an English support request and sends a billable call when executed:

curl --fail-with-body https://api.liquid.ai/decisions/v1/systemone \
  -H "Authorization: Bearer $LIQUID_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "d1",
    "state": "Please refund the duplicate charge.",
    "questions": {
      "refund": {"type": "noul", "instructions": "Is a refund requested?"}
    }
  }'

Read the probability in answers.refund.noul; choose a threshold using labeled examples from your application. For images, the official API expects base64 image data rather than remote image URLs.

For local serving, install a current llama.cpp build with d1 decision support, then follow the official GGUF recipe:

llama-server -hf LiquidAI/d1-3B-GGUF:Q8_0

In a second terminal, call its local decision endpoint:

curl --fail-with-body http://127.0.0.1:8080/v1/systemone \
  -H "Content-Type: application/json" \
  -d '{
    "state": "Please refund the duplicate charge.",
    "questions": {
      "refund": {"type": "noul", "instructions": "Is a refund requested?"}
    }
  }'

To evaluate the smaller model instead, stop that server and use the 600M recipe:

llama-server -hf LiquidAI/d1-omni-600M-GGUF:Q8_0 -b 4096 -ub 4096

Its batch sizes must hold a whole question; the model card says to increase them for longer states, up to 16,384. These commands were checked against the official recipes, not executed for this review. Keep the model, quantization and runtime version in your evaluation record.

Which option should you evaluate first?

Hosted d1 is the practical starting point for a connected service with low or uncertain volume. d1-3B is the stronger local starting candidate for text/image decisions based on the published comparison. d1-omni-600M deserves a separate evaluation when speech or a smaller footprint matters and its experimental limits are acceptable.

For each candidate, use the same labeled tasks, category definitions and acceptance rules. Measure wrong routes, missed cases, p95 latency, peak memory and how often uncertainty needs a fallback. Recheck calibration on your own language and data: a probability-shaped output does not guarantee correct decisions under a new distribution.

OmniaKey's model catalog lists current gateway models and prices. This review establishes Liquid's own API and local options, not d1 availability through OmniaKey. For generation tasks alongside a decision model, compare the currently listed models separately.