System One Models: Getting Typed Decisions Instead of Text from AI

For the past two years every AI API has rested on one assumption: you send a prompt, the model produces text, and you parse it. That assumption is right for chat. But most software does not chat; it decides. "Is this ticket urgent?", "Is this transaction risky?", "Which model should handle this request?" are questions that want a type, not a paragraph.

On 15 September 2026 a lab called TypeSafe opened early access to Jev and named the category "System One". The idea: the model does not write sentences, it answers your question with a typed, calibrated value. This article explains the three question types with real requests and responses, shares the numbers from our own production measurement, and shows how to build the same pattern today with models already in the Onysoft catalog.

The Problem With Classifying Through a Text Model

When you need to know whether a support ticket is urgent, the usual fix is to tell a chat model "answer only YES or NO". In production that approach has four well-known problems.

• Fragile parsing. The model sometimes continues with "Yes, because the customer...". JSON mode and schema enforcement mostly solve this, but the parsing layer stays your problem.
• Uncalibrated confidence. When you ask "how sure are you?", the "90% sure" you get back is not a probability; it is text about a probability. If you want to set a threshold, there is nothing underneath it.
• Cost and latency. You run a model that spends reasoning tokens to produce a one-word decision. At volume this line item becomes visible.
• Version drift. The provider updates the model, the same prompt returns a different tone, and your thresholds move silently.

The System One approach addresses all four by design: the output is already a type, the probability is already calibrated, and because no prose is generated the cost is bounded by the input.

Three Question Types: noul, choice, score

Jev exposes a single endpoint. You send a state and a dictionary of questions, and you get a typed answer for each. There are three types:

• noul — a yes/no question. The answer is a probability between 0 and 1, against criteria you define for true and false.
• choice — one of the options you define, returned with a probability for every option plus a confidence value.
• score — a point on a scale of described levels, returned with a fractional score, per-level probabilities and a legend.

A request looks like this:

POST https://api.typesafe.ai/v1/systemone
Authorization: Bearer KEY

{
  "state": "Help! My payouts have been failing for 3 days.",
  "model": "jev-latest",
  "questions": {
    "is_urgent": {
      "type": "noul",
      "instructions": "Does this report a blocking problem?",
      "criteria": {
        "true": "Work has stopped, money or access is lost",
        "false": "Informational or expected"
      }
    }
  }
}

The response is not text to be parsed but a number you can act on:

{
  "model": "jev-1.13.0",
  "answers": {
    "is_urgent": { "type": "noul", "noul": 0.92 }
  },
  "usage": { "input_tokens": 312, "output_tokens": 48 }
}

The point is that 0.92 was not extracted from a sentence; the model produced it directly. That is what makes if (urgent >= 0.8) meaningful.

We Measured It on Our Own System: Support Triage

We tested this against our own data. At Onysoft, support tickets are answered first by an AI assistant and escalated to a human when it cannot resolve them. On 16 September that flow failed for one customer: although the message explicitly said "I do not want an AI assistant", the assistant replied anyway and suggested the fault might be in the customer's code. The fault was in fact ours.

We put the same message through Jev with four typed questions:

Question	Type	Answer
Is the customer asking for a human?	noul	0.98
Ticket category	choice	technical fault (confidence 1.00)
Is it blocking?	noul	0.58
Dissatisfaction level	score	2.89 / 3 (confidence 0.89)

The call took 0.8 seconds and used 677 input tokens. A single threshold (asks_for_human >= 0.80) would have stopped that reply from ever being sent.

One example is not evidence, so we ran the same test over the last 12 real customer messages in our archive. Two were routed to a human (the ticket above, and a customer writing "can i talk to a human" at 0.97); the other ten stayed with the assistant. There were no false positives: a balance question, a "how are the models so cheap" question and a complaint about the site being Turkey-centric (dissatisfaction 1.79) all stayed below the threshold.

Total cost of the twelve measurements: 8,732 input tokens, about $0.00037.

Cost: Why It Is So Cheap

Jev lists at $0.042 per million input tokens, with output free. Free output looks odd until you remember the design: the model does not write sentences, it emits a few numbers.

Compare it with doing the same classification through a chat model. Say you classify a 700-token support message 1,000 times a day (21M input tokens per month):

Approach	Input per 1M	Monthly input cost
Typed decision model	$0.042	$0.88
Fast chat model (e.g. Gemini 3.8 Flash, Onysoft list price)	$1.125	$23.63 + output
Frontier chat model (e.g. GPT-6 Astra)	$15	$315 + output

That is a 27x to 350x difference. As decision volume grows this stops being a detail and becomes an architectural choice. For our own price comparison see the AI API cost optimization guide.

The published context limit is 64k tokens (state plus all questions) and the rate limit is 1,200 requests per minute. The documentation also carries an honest warning: English is the primary training language and other languages are less reliable. Our Turkish tests were accurate, but because of that warning we recommend measuring on your own data before going to production.

The Architectural Pattern: Confidence Routing

The real value of a typed decision is not the single answer; it is that control flow goes back to your code. The common pattern:

1. A cheap, fast typed model answers one narrow question with a probability.
2. If the probability sits at either extreme, your code decides and the work is done.
3. If it sits in the middle, the work escalates to an expensive reasoning model or to a human.

Our support gate works exactly this way:

$triage = TypeSafeService::triageTicket($customerMessage);

if ($triage["asks_for_human"] >= 0.80) {
    escalateToHuman("Customer asked for a human");
    return; // the AI never speaks
}

if ($triage["anger"] >= 2.5 && $triage["anger_confidence"] >= 0.70) {
    escalateToHuman("High dissatisfaction");
    return;
}

if ($triage["blocking"] >= 0.80) {
    raisePriority();
}

assistantReply();

Note the anger_confidence condition: even when the score is high, we do not escalate if the model is unsure of it. Being able to treat confidence as a separate axis is exactly what a text-generating model does not give you.

Related patterns: asking many narrow questions at once and filtering in code, routing an incoming request by intent, and decomposing a complex judgement into small scores whose weighting stays in your code.

When Not to Use It

These models do not replace chat models. Keep the line clear:

• They do not write text. The reply, the summary, the code still comes from a generative model. The typed model only makes the decision.
• Not for open-ended work. "Refactor this code" has no type.
• Question design is the work. Vague criteria produce vague probabilities. A good question is one where a human would give the same answer.
• Do not depend on a single output. An early-access model can change behaviour between versions; validate your thresholds with measurement and log them.

Building the Same Pattern on Onysoft Today

Typed decisions are a pattern, not a product. You can build it today with models already in the Onysoft catalog, without signing a separate provider contract. Since 14 September 2026 the response_format and tools parameters pass through Onysoft, so you can force a schema and get typed output directly.

curl https://api.onysoft.com/v1/chat/completions \
  -H "Authorization: Bearer sk-ony-YOUR-KEY" \
  -H "Content-Type: application/json" \
  -d \'{
    "model": "google/gemini-3.8-flash",
    "messages": [
      {"role": "system", "content": "You are a support ticket classifier. Fill the schema only."},
      {"role": "user", "content": "My payouts have been failing for three days."}
    ],
    "response_format": {
      "type": "json_schema",
      "json_schema": {
        "name": "triage",
        "schema": {
          "type": "object",
          "properties": {
            "blocking": {"type": "boolean"},
            "category": {"type": "string", "enum": ["technical", "billing", "account", "question"]},
            "asks_for_human": {"type": "boolean"}
          },
          "required": ["blocking", "category", "asks_for_human"]
        }
      }
    }
  }\'

This gives you the schema guarantee but not a calibrated probability: you work with booleans instead of thresholds. For most workflows that is enough, and it runs on one key, one balance and one invoice. See the documentation and the Playground for more.

A transparent note, and a solution: we have not added Jev to the Onysoft catalog and we cannot. The provider's customer agreement explicitly forbids offering the service to third parties as a standalone service. We do not resell the model, but that does not mean you cannot use it through Onysoft.

For exactly these cases we shipped bring your own key (BYOK). The contract stays between you and the provider; Onysoft is only the technical intermediary acting on your instruction. Usage is billed directly to your own provider account and nothing is deducted from your Onysoft balance. Your key is stored encrypted with AES-256-GCM and only its last four characters are ever returned.

# 1) Register your own key once
curl -X POST https://api.onysoft.com/v1/provider-keys \\
  -H "Authorization: Bearer sk-ony-YOUR-KEY" \\
  -H "Content-Type: application/json" \\
  -d \'{"provider": "typed-decisions", "api_key": "YOUR_PROVIDER_KEY"}\'

# 2) Send a typed decision request
curl -X POST https://api.onysoft.com/v1/decisions \\
  -H "Authorization: Bearer sk-ony-YOUR-KEY" \\
  -H "Content-Type: application/json" \\
  -d \'{
    "state": "My card was declined and I want to speak to a human.",
    "questions": {
      "asks_for_human": {
        "type": "noul",
        "instructions": "Is the customer asking for a human?",
        "criteria": {"true": "Yes", "false": "No"}
      }
    }
  }\'

The same arrangement covers the NVIDIA model catalog: call the standard /v1/chat/completions endpoint with an nvidia/ prefixed model id and the request is forwarded with your NVIDIA key. In our own measurement a typed decision returned in 0.6 seconds with no deduction from the Onysoft balance. You can list supported providers with GET /v1/provider-keys.

Summary

System One is less a new model family than a correction in how AI attaches to software: the model decides, the code controls the flow. In practice it changes three things: the parsing layer disappears, confidence becomes a measurable axis, and the cost per decision drops by two or three orders of magnitude.

In our own measurement a single threshold would have prevented a concrete customer failure we had this week. You can build the same pattern today with schema enforcement on Onysoft models, and if you need calibrated probabilities you can evaluate typed models inside your own application.

Update (20 September 2026): We measured this pattern head to head against a chat model on a real 446-model catalogue — cost, latency, the confidence axis and parse failures, with numbers: typed decision model or chat model?

To get started, create a free account and browse the catalog at /models.