POST /v1/systemone when you need a decision rather than prose: route a ticket, gate an
agent’s action, score a document against a rubric. Send a state (a string, or structured
JSON) and a map of typed questions; the response returns one typed answer per question,
with probabilities and confidence your code can act on directly.
The endpoint mirrors TypeSafe AI’s native System One API exactly. If you already use the
official TypeSafe SDK, point TYPESAFE_BASE_URL at https://api.impossibl.com and use your
impossibl key — no code changes.
Three models answer here: typesafe-ai/jev, convaiinnovations/laya and
supersoniclabs/julia-1. They take the same request and return the same shape, so switching
between them is a one-word change. OpenAI’s openai/gpt-6-luna-decisions answers the same
kind of question on its own wire, POST /v1/decisions — see
OpenAI Decisions below.
Evaluate a state
Question types
Every question has atype and instructions. instructions — and every criteria value —
can be a string or JSON structure (object or array) when the content is already structured.
Answers come back under the same ids you chose for the questions. Ask every question your
code might need in one request — they are evaluated in parallel and share one token budget.
Models and billing
Discover supported models withGET /v1/models: evaluation models have
output_modality: "evaluation" and endpoints: ["/v1/systemone"].
convaiinnovations/laya is free in both directions — we host it ourselves, so there is no
per-token cost to pass on. It still needs an API key and a funded account, and its calls still
appear in your usage with their token counts, at zero credits. Neither model charges for the
usage.output_tokens it reports. On /v1/systemone the
response model names the concrete version that answered — jev-1.13.0 from TypeSafe, and
laya-<version>/<checkpoint> from Laya, and julia-1/<revision> from Julia. Results and charges appear in the same
request log and usage ledger as other API calls.
Pinning a Jev version
Three ids serve Jev, on the same endpoint and at the same price:
The two rolling ids follow TypeSafe’s
jev-latest alias, so the answers behind them can
change when TypeSafe ships without any change on your side. The response model always names
the concrete version that answered (jev-1.13.0), as TypeSafe’s own API does — log it to know
which model produced a result, and pin that id once a result matters.
Choosing a Laya checkpoint
convaiinnovations/laya routes to one of Laya’s checkpoints for you, and it decides by
script rather than language. Text in a Latin script is treated as English, so Spanish,
Portuguese, French, German, Turkish and Vietnamese are all answered by the English
checkpoint; only non-Latin scripts — Japanese, Chinese, Cyrillic, Arabic — reach the
multilingual one on their own.
If your text is not English, send convaiinnovations/laya-multilingual instead. It pins the
multilingual checkpoint whatever the script, and it is the only way to reach those weights
from a Latin-script language. Everything else about it is identical: same endpoint, same
request, same price, same 8,192 budget.
The choice changes answers, so it is worth testing both on your own data rather than
assuming. On one fixed English question the two checkpoints returned P = 0.149 and 0.091.
Part of the budget is reserved for the question and its options rather than the state — about
1,000 tokens on Laya — so a long document plus a choice with many options can truncate before
the total is reached. Note also that a bigger budget is not a better decision: Laya’s encoders
were pretrained at 8,192, but its decision head was fine-tuned at 512/1024, so on long inputs
the extra context can dilute the signal rather than sharpen it.
Laya is smaller, cheaper and faster, and it is strongest when the label space is small; it
gets noticeably worse as a choice grows past roughly twenty options, and — this part
matters — its confidence stays high while it does. Measure both on your own labels before
gating anything on either one’s confidence.
Writing questions for Julia
supersoniclabs/julia-1 compares the options you give it, so the wording of each option does
most of the work. Give every choice option a short descriptive sentence (“Billing and
payment disputes, refunds”) rather than a keyword, and always send criteria on a noul:
noul falls back to the literal words
“false” and “true” and is close to useless. A choice takes 2 to 20 options, and a request
that does not fit the 8,192 budget is refused with 400 rather than truncated. Do not use it
to identify a language: it answers English for Portuguese and Spanish text with near-total
confidence.
OpenAI Decisions
openai/gpt-6-luna-decisions is GPT-6 Luna served through OpenAI’s Decisions API.
POST /v1/decisions mirrors that API exactly, so the official OpenAI SDK works by pointing
OPENAI_BASE_URL at https://api.impossibl.com/v1. Its wire differs from System One: an
input instead of a state, a questions array where each question carries a unique
name, and predicate in place of noul.
input can also be user messages with input_text and input_image parts; images must be
base64 data URLs. A question the model declines comes back as { "type": "refusal", "name": ... }.
Billing is input tokens only: 0.20 / M above, with
output, cache reads and cache writes free. OpenAI’s own validation errors (for example a
choice with fewer than two options) are returned as 400.
Limits
state and questions are required, and questions must hold at least one entry. The state
and all questions share the model’s token budget from the table above. A choice without
criteria, or a score with fewer than two levels, returns 400 before anything is sent
upstream.
Evaluation is non-streaming and uses the gateway’s provider credentials (there is no BYOK
path). Requests require an API key and sufficient credits. Sending an evaluation model to a
chat, embeddings or rerank endpoint returns 400 with the correct /v1/systemone or
/v1/decisions destination.