System One models for enterprise AI: the four numbers that decide the design, and the one nobody published

What are System One models for enterprise AI, and what does one decide?#

A System One model answers a typed question with a value your code can branch on and a calibrated probability, at $0.042 per million input tokens. TypeSafe's System One concepts page defines them as "a class of AI models built to make fast, structured decisions that software can use directly". So the answer comes back under the id you chose. It arrives as a yes-or-no probability, a choice with its confidence, or a score.

Because the answer is a value rather than a paragraph, the call sits inside an if. Your code decides what happens next. So the question to ask of a workload is not whether a model can do it. The question is whether the answer is one of a set your code already knows.

For example, the API reference names three question types. So a noul returns the probability that a yes-or-no question is yes. A choice returns one option from criteria you wrote, with a probability for every option. A score rates the state along levels you define. In each case you name the question, and the answer comes back under that same name.

Then the daily bill follows from the price on TypeSafe's models page, at 2,000 tokens of state per document.

What does a typed decision layer save, and who has to be hired to run it?#

Say a support desk runs 20,000 tickets a day: that is 120,000 typed decisions for USD 1.68, and no machine-learning hire to keep it running. In this example each ticket carries about 2,000 tokens of state. It needs six decisions: queue, severity, product area, language, refund risk and duplicate. Batched into one call per ticket, that is 40 million input tokens a day. At TypeSafe's published $0.042 per million, the day costs USD 1.68.

For example, asked as six separate calls instead, the same desk re-sends the state with every one. Say the same volume again: the day then costs 240 million input tokens and USD 10.08. The work is identical. Only the shape of the request changed.

Therefore the outcome worth reporting upward is not accuracy. It is that the decision layer costs under two dollars a day at that volume. And it is that no specialist has to be hired to hold it, because the questions live in your own schema rather than inside a model. That matters, because expertise is what most firms say stops them.

What has to be in place before an enterprise can run one at all?#

Adoption tracks size rather than enthusiasm: 55.03% of large EU enterprises use at least one AI technology against 17% of small ones. Eurostat published those shares for 2025, with data extracted in December 2025. So the gap is about capacity rather than appetite.

So what decides whether this ships is not the model. It is three things a firm either has or does not have. First, a job already written as a decision, with the options named. Second, a schema somebody owns, because the questions live in your repository. Third, a queue a person watches, because some share of answers will land below the threshold by design.

TypeSafe's how-to-build page puts the same rule on the model's side: keep code in control and give the model narrow, structured decisions. When any of the three is missing, the work is not modelling work. Instead it is the ordinary work of writing down how a decision is already made.

In practice the schema is where the effort lands. Because the criteria are what the model reads, each option needs a description a stranger could apply. Boundary cases belong in the criteria too. When an answer looks wrong and you find yourself explaining what you really meant, the jaggedness page says that explanation was the missing half of the instruction.

Which enterprise jobs does a typed decision fit, and which ones does it not?#

Classification, routing, extraction, scoring and re-ranking fit; re-ranking a shortlist moved top-1 accuracy from 5% to 18% across 40 CLERC queries. TypeSafe's re-ranking cookbook reports that run, along with top-10 accuracy rising from 38% to 62% over the same 40 queries.

So a job fits when its answer is a value from a set the code already knows. Re-ranking is the clearest case. The candidates exist already, the model only orders them, and the ordering is checkable. In practice that is why it gains more than a paragraph about the candidates ever could.

The jobs that do not fit are the ones where the answer is open-ended, or where the value has to be computed rather than judged. Those come back later, in the exit.

Meanwhile routing is the other everyday case, and it is checkable the same way. The answer gets compared against what the desk actually did. So the log that measures the model also measures the threshold above it.

Why does asking thirteen questions in one call change the bill?#

The same thirteen questions over the same article cost USD 0.00609 as thirteen calls and USD 0.000497 as one, because the state is sent once. TypeSafe's parallel questions cookbook runs exactly that comparison over one article.

The reason is mechanical. Every call carries the whole state. So thirteen calls carry thirteen copies of the article, and one call carries a single copy. Because the questions themselves are small, cost follows how often the state is re-sent rather than how many questions are asked.

As a result, the first design decision is not which model to use. It is where the batch boundary sits: one call per document with every question attached, rather than one call per question. That boundary also decides whether you stay inside the published ceilings. Those sit at 1,200 requests a minute and 250,000 tokens a second, and the models page warns both can change without notice.

What does the same batching do to the clock a person is watching?#

Thirteen separate calls took 2.71 seconds and the single batched call took 0.27, which is the difference between a spinner and an answered screen. The same cookbook run reports both times.

Because batching removes twelve round trips as well as twelve copies of the state, the clock moves with the bill. So a screen that waits on a batch of decisions does not wait once per decision. It waits once. For anything a person is watching, that is the difference between an interface that feels broken and one that does not.

Where does the confidence threshold go, and how much human review does it buy?#

TypeSafe's own pattern routes anything below 0.6 to a person, acts on 0.6 and above for low-stakes work, and asks for confirmation up to 0.85. Above 0.85 on a high-stakes action, the pattern acts automatically.

But the bands are not a quality setting. TypeSafe's concepts page is explicit about why: calibration is measured across groups of predictions, and "it does not guarantee that an individual answer is correct". So a high confidence does not mean this answer is right. It means answers scored like it are right at that rate across the group.

Therefore the threshold is a staffing dial. Raise it and more work reaches the review queue. Lower it and fewer answers are checked. Because that queue is a real cost, pick the number after someone has agreed to watch it. Pick it after measuring what a 0.85 is actually worth on your own data.

Can the decision call run inside an edge request without blowing the budget?#

Waiting on the call costs no CPU time on Workers, so the real ceiling is the subrequest budget of 50 on Free and 10,000 on Paid. Cloudflare's Workers limits page states it plainly: "Waiting on network requests (such as fetch() calls, KV reads, or database queries) does not count toward CPU time."

So an edge runtime is a fine place for a typed decision, and the thing to count is calls rather than seconds. One batched call per request leaves the budget almost untouched. But one call per question, in a loop over a list, is how a Worker meets its ceiling.

Then check which copy of the model the Worker reaches. Cloudflare lists Jev in its own AI model catalogue under the id typesafe/jev, and that listing gives the model a 32,000-token context window rather than the 64k on TypeSafe's page. So the same call has half the room depending on the route it takes. The listing is also absent from the general Workers AI models index, which is where most people look first when choosing between Clef, Clef-flash and Clef-omni.

The same arithmetic settles where the call belongs. When a request needs one decision about the thing in front of it, the edge is the right place. When it needs a decision per row over a long list, that work belongs in a job with its own retries, not in a request a person is waiting on.

Which number is missing, and how do you measure it yourself?#

The calibration figure, which is the one number the bands rest on. TypeSafe publishes the price, the context budget, the rate limits and a latency range. It has published no expected calibration error, for any task family. No paper sits behind the training method either. Searched on arXiv by its own name on 20 September 2026, the method returns no results. The independent tracker systemonemodels.org states on its own pages that it is affiliated with no model vendor. It puts the gap in one line: "A vendor selling calibrated probabilities as its core property has published no calibration number for any task family."

So the gap matters because of where the bands sit. Confidence gating works only when an answer at 0.85 really is right about 85% of the time on the inputs you actually see. Because that rate has never been published, the threshold rests on the vendor's word until somebody measures it. The concepts page already grants the narrower point: calibration is a property of groups, not of the answer in front of you.

Therefore measure it before a threshold guards anything expensive. Log every answer with the probability it carried, and later the outcome that actually happened. Then bucket the answers by probability and compare each bucket's mean probability against the share that turned out right. A calibrated model tracks the diagonal, and a gap tells you which way to move the number.

In practice that is a week of logging and an afternoon of arithmetic, and it is done per question type rather than once. Calibration is not a global property of a model, so a distribution that is honest about ticket queues can drift badly on contract clauses. Redo it when the model version changes, because nothing in the price or the docs announces that the number moved.

Which pages do you implement from, and in what order?#

Five, in build order: the design rule, the request shape, the routing pattern, the failure list and the limits.

1. How to build with System One: code keeps control, the model gets narrow decisions.
2. API reference: the request shape, the three question types, the response and the error table.
3. Confidence-gated routing: the 0.6 and 0.85 bands, and what the code does in each.
4. Model jaggedness for jev-1.13: the published failure classes, which is the list your code refuses.
5. Models: the price, the request budget, the rate limits and the model aliases.

What is the smallest working example, and where does it refuse the model?#

Four steps in TypeScript: post the state with every question, read each typed answer and its confidence, branch on the bands, refuse what the model cannot do. Every field below comes from the API reference; the bands come from the routing pattern.

// 1. One request: the state once, every question attached (api.md).
const res = await fetch('https://api.typesafe.ai/v1/systemone', {
  method: 'POST',
  headers: { Authorization: `Bearer ${apiKey}`, 'Content-Type': 'application/json' },
  body: JSON.stringify({
    state: ticketText,
    model: 'jev-latest',
    questions: {
      department: {
        type: 'choice',
        instructions: 'Which team should handle this?',
        criteria: {
          billing: 'Payments, invoicing, refunds',
          technical: 'Bugs, outages, integrations',
          sales: 'Pricing, upgrades, new accounts',
        },
      },
      is_urgent: { type: 'noul', instructions: 'Does this convey urgency?' },
    },
  }),
});

// 2. Each answer comes back under the id you chose (api.md).
const { answers } = await res.json();
const department = answers.department;

// 3. Branch on the documented bands (confidence-routing.md).
if (department.confidence < 0.6) {
  await sendToHuman(ticket, department);
} else if (department.confidence < 0.85) {
  await askToConfirm(ticket, department.choice);
} else {
  await route(ticket, department.choice);
}

// 4. Refuse in code what the model does not do (jev-1.13.md).
const refundTotal = lineItems.reduce((sum, item) => sum + item.amount, 0);

Finally, step four is the one that is easy to skip. The jaggedness page for jev-1.13 says "Jev is not a calculator" and recommends implementing mathematical logic in code. It also records that the model does not count reliably, whether that is characters in a word or items in a long list. So the total above is added in code, and no question asks the model to do arithmetic.

The same page gives a second refusal, and it is easier to miss because nothing about it looks like a failure. Two related questions carry no arithmetic relationship to each other. Its worked example puts two nouls on one ticket, asking first whether the customer wants a refund and then whether they want anything else instead. The answers come back at 0.72 and 0.47, which sum to 1.19, and the page says there are many reasons those two numbers may not be directly comparable.

So ask the one question you mean, never a question and its mirror, and reconcile the pair in your own code when the logic needs them to agree. The page adds the third refusal alongside it: state the exact condition rather than one that needs interpreting, and put the boundary cases in the criteria. All three are refusals your code owes before the call, rather than repairs after it.

When is a hosted System One model the wrong tool, and what replaces it?#

When the state will not fit the published budget, when the job is arithmetic, or when the data is not allowed to leave your network. TypeSafe's models page publishes the first bound as 64k tokens per request, and 32k for the state plus the longest question.

Three jobs fail on the model itself, each for its own reason. A long contract with a long question fails on the budget. Then a refund total fails because the model is not a calculator. Finally a customer-facing paragraph fails because the answer is not a value from a known set. In each of those the honest move is a frontier model for the part that needs one. Keep the typed decision for the branch that follows. So a frontier model drafts the paragraph, and a typed call decides whether it is ready to send.

The third case is not about the model at all, and since 18 September 2026 it has an answer. Convai Innovations published Laya, a second model that answers the same three question shapes, as Apache 2.0 weights on Hugging Face rather than as a hosted API. So it runs on hardware you control, with no rate limit, no per-token bill and no request leaving the network.

But the two are not interchangeable, and what you save in access you pay in work. The English checkpoint leaves roughly 320 tokens for the state, against 64k on the hosted route. Its own model card calls it "a fast base to specialise, not a zero-shot decision engine". Untuned it scores 0.362 on the typed-decisions benchmark, against a 0.318 random baseline and a 0.461 majority-class baseline. The same card reports 0.766 once the checkpoint is fine-tuned on that benchmark's training split.

Then note which of the two publishes the missing number. Convai reports an expected calibration error of 0.466 as shipped, falling to 0.081 after fitting one temperature per question type. Its card tells you to do that fitting on your own data before trusting the probabilities. So the choice is which problem you would rather own. One route is an API key and a bill, with a calibration figure you derive yourself. The other is a model you keep, inspect and retrain, with the figure published and a fine-tuning job in front of it.

Where does this go from here?#

Four decisions are left before System One models for enterprise AI go in front of traffic. They are which workload to type first, where the call lives, who watches the queue the threshold creates, and whether the model runs on somebody else's hardware or your own. For the buy-or-not comparison against a frontier model, read TypeSafe AI Jev vs LLMs. For where a call like this belongs in a multi-step job, read Cloudflare Workflows for AI and what belongs at the edge.

For the work of having the layer built and governed, two pages help. The AI-augmented development page covers how the decisions get written down and reviewed. Then Cloudflare development covers where the call runs. Still, the vendor's own published pages are enough to build the first one without any of that.