Skip to content

Capability · Decisions

A label and a probability, not prose.

Typed decisions from a non-autoregressive model: send a state plus a map of typed questions and get one verdict per question, each with a calibrated probability, out of a single forward pass. Swiss-hosted, general traffic only.

POST /v1/decisions

What you get

Built for regulated workloads

This is what you reach for instead of paying a chat model to act as a classifier. A decision request carries a state — free text or any JSON — plus a map of typed questions, and each question comes back as a label or a number with a calibrated probability and a confidence, from one encoder forward pass. Nothing is generated, so there is no completion to parse, no JSON mode to coax, and the answer to a choice question is always one of the labels you supplied. Served from Switzerland on our own hardware, general (non-PHI) traffic only, and pinned by model rather than picked up by auto traffic in any other region.

01 · Typed

Three question types

choice picks one of your labels and returns the full probability distribution over them. score returns a probability-weighted level against an ordered rubric you define. noul answers a yes/no question as a calibrated probability between 0 and 1. Up to 32 questions about one state, each answered independently.

02 · Calibrated

A number you can threshold

Every answer carries probabilities and a confidence, so you can route on a threshold instead of on a sentence — auto-handle above 0.9, queue for review below it. A chat model asked for the same label gives you prose (or JSON if you are lucky) and no honest distribution behind it.

03 · Batched

One round trip, one pass

Send up to 64 decisions in a single requests array (512 questions in total) and the upstream shares one forward pass across them. An entry it cannot answer comes back as an error inside results and is not billed.

04 · Price

Per encoder input token

Billed on the upstream’s own usage.input_tokens — there are no output tokens to pay for, because nothing is generated. The state is re-encoded once per question, so an N-question decision costs roughly N× that state’s tokens; that is how the model meters, and matching it is why the rate is per token rather than per question.

05 · Swiss

Self-hosted, one region

The decision host runs on our own Swiss GPU hardware and serves exactly one region, so there is no cross-border failover to inherit: a non-CH request is refused rather than answered elsewhere. Every response names the backend that answered in x-phi-upstream-backend.

06 · PHI

General traffic only

The host is reached over a tunnel whose TLS-terminating middlebox is not a PHI boundary, so X-PHI:true returns phi_blocked and there is no PHI-eligible decision host to fail over to. This is a deployment limitation, not a claim about the model — do not send protected health information here.

Availability & pricing

Where it runs, what it costs

Every route is pinned to a region, PHI stays on resident hosts, and the PHI gate is enforced per call. Prices mirror the live /v1/pricing rate card.

RegionProviderModelTierPrice
CHLayalaya-multilingualGeneral$0.06 / 1M
CHLayalaya-englishGeneral$0.06 / 1M
CHLayalaya-typed-decisionsGeneral$0.06 / 1M
EU / US / other—decisionsNo routeno_route
Any—decisions (PHI)No routephi_blocked

Priced per 1M encoder INPUT tokens. There is no output price because nothing is generated — and because the state is re-encoded once per question, an N-question decision costs roughly N× that state’s tokens. The three checkpoints are the same price; an unpinned call gets the multilingual one. Swiss-hosted, general traffic only. Full rate card at /pricing and GET /v1/pricing.

Try it

A real call, end to end

One state, three typed questions, one round trip. Each answer carries its own probability distribution — nothing is generated, so there is no prose to parse.

Residency & gating

  • Switzerland only. The decision provider has exactly one region, so a request with any other X-Region returns no_route (422) rather than being served from somewhere else.
  • General traffic only: X-PHI:true returns phi_blocked (403), by construction — the self-hosted host is not a filed PHI sub-processor, and there is no PHI-eligible decision model to fail over to.
  • Pin-only by design. No region’s auto traffic for chat, embeddings or any other task can land on a decision model, and a decision request is never answered by a chat model.
  • No state, question or answer is ever logged or persisted by the gateway — the same stateless posture as every other endpoint.

Good to know

  • · The context window is the budget for ONE question (instructions + options + state): 1,024 tokens on laya-multilingual and laya-typed-decisions, 512 on laya-english, and the laya alias publishes the smallest of its backers (512). A longer state is truncated, not rejected.
  • · Caps: 32 questions per decision, 64 options per question, 65,536 characters of state, 64 decisions and 512 questions per HTTP request. A malformed question is rejected with our own 400 naming the question id and field, before it costs a GPU round trip.
  • · If the host is saturated it answers 503 upstream_overloaded with Retry-After — nothing was computed and nothing is billed. Retry shortly.
  • · A response carries x-phi-input-tokens (the billing unit) and x-phi-questions (informational — how many questions were answered).
curl
curl https://cloudsitus.com/api/v1/decisions \
  -H "Authorization: Bearer $PHI_API_KEY" \
  -H "X-Region: CH" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "laya",
    "state": "Ticket 8812 — I ordered the wrong size and nobody called back.",
    "questions": {
      "intent": { "type": "choice",
        "instructions": "What does the customer want?",
        "criteria": { "refund": "wants money back",
                      "exchange": "wants a different size",
                      "status": "asking where the order is" } },
      "urgency": { "type": "score",
        "instructions": "How urgent is this ticket?",
        "criteria": ["routine", "reply today", "escalate now"] },
      "angry": { "type": "noul", "instructions": "Is the customer angry?" }
    }
  }'
response
x-phi-routed: laya-multilingual/CH/general
x-phi-input-tokens: 214
x-phi-questions: 3
x-phi-upstream-backend: local
x-phi-cost-micro: 9
{ "answers": {
    "intent":  { "choice": "exchange", "confidence": 0.7742,
                 "probabilities": { "refund": 0.2913, "exchange": 0.6482,
                                    "status": 0.0605 } },
    "urgency": { "score": 1.4271, "confidence": 0.6218 },
    "angry":   { "noul": 0.8734, "confidence": 0.8734 } },
  "usage": { "input_tokens": 214, "output_tokens": 0 } }
Is this a chat model?
No. It is non-autoregressive: a bidirectional encoder with a typed decision head that emits a label or a number plus a probability, and generates no text at all. There is no completion, no streaming and no prompt engineering to get JSON out of it. When you want prose, use /v1/chat/completions.
Why not just ask an LLM to classify?
You can, and for a one-off it is fine. The difference shows up in production: a decision model answers with a distribution over the labels you defined, so you can set a threshold and measure it; it cannot answer with a label you never supplied; and it costs input tokens only, because it generates nothing. Triage, routing, consent checks and red-flag detection are exactly this shape — a label plus a number, at volume.
Can I use it on protected health information?
No. The decision host is self-hosted and reached over a tunnel whose TLS-terminating middlebox is not a PHI boundary, so X-PHI:true returns phi_blocked and nothing fails over. That is a deployment limitation rather than a property of the model; until the host is filed as a PHI sub-processor, keep PHI on the PHI-eligible chat and embedding routes.
What does a yes/no question return?
A noul question returns the probability that the statement holds, between 0 and 1, plus a confidence. You choose the threshold. Pass criteria with true / false descriptions when the question needs steering, or omit criteria entirely.
Why is it billed per input token and not per question?
Because the state is re-encoded once per question: a 3-question decision over a long state genuinely encodes about 3× that state’s tokens. Billing on the reported usage.input_tokens means you pay for exactly the work done, whatever the state’s length — a flat per-question price would misprice long states several-fold.
Which checkpoint answers my call?
An unpinned call (model omitted or auto) resolves to the multilingual checkpoint, the broadest-coverage one. Pin laya-english or laya-typed-decisions by id to choose deliberately; laya is the alias for the multilingual row. A pinned model is honoured or refused, never substituted.

Ready when you are

Put decisions in production — without giving up your data.

Spin up a key in minutes. The residency and PHI posture above arrives unchanged.

Prepaid credits from $10 · No subscription · No data retained