Jev by TypeSafe AI went live on September 15, 2026. Within a month, AWS, Microsoft, Cloudflare, OpenAI, Perplexity, Snowflake, Liquid AI and more than a dozen open source projects shipped models of the same kind. TypeSafe called its new class “System One models”. The market settled on a different name. Every follower calls its product a decision model, and the Hugging Face benchmark that ranks them is the Decision Index. A category that did not exist in August 2026 has a name, a shared request schema, a benchmark and a price point. A decision model is neither an LLM that writes text nor a classic machine learning model trained for one task. It sits between the two and complements both, which is why it spread so fast. This post looks at what shipped and how the variants differ. It explains why the request schema became the standard rather than any single model. And it draws the consequences for enterprise architecture. The category commoditized while it was still being born.
This is the fourth post in my series on Jev by TypeSafe AI. The first three cover how System One models like Jev change enterprise AI architecture, why Jev fits Apache Kafka and Flink better than LLMs, and Jev in workflow orchestration and process intelligence. This post includes the key concepts, so it stands on its own, while the detailed architecture patterns live in those three.
A decision model is a neural network that reads a piece of state and answers typed questions about it in a single forward pass. The state can be a support ticket, a Kafka event, a document or an image. It returns a probability for every allowed option instead of generated text. The questions come in three shapes:
The confidence value is part of the answer. This makes the result usable as a gate inside software. A decision with 0.97 confidence runs automatically, a decision with 0.6 goes to a second look, and the threshold lives in the workflow, not in the model.
TypeSafe calls this class “System One models”, after Daniel Kahneman’s fast and automatic mode of thinking, with LLMs cast as the slow System Two that reasons and explains. The name describes the design well. It did not become the category name. AWS ships a Decider, Microsoft ships Decision 1, Snowflake ships Snowflake Decision, and Hugging Face hosts the Decision Index. The inference servers vLLM and llama.cpp expose the request type under a systemone endpoint. Everyone still calls the thing a decision model. I use “decision model” for the category in this post and “Jev” for TypeSafe’s product.
The easiest way to place a decision model is next to the two kinds of AI most enterprises already run:
Decision models replace neither. They add a third option for the thousands of small judgments inside software. Those were too expensive for an LLM and too numerous to train a classifier for each. The LLM keeps the open-ended work, and a trained model keeps the high-volume cases where you own the labels and the last percent of accuracy matters. This complementary role is why the category spread through integration, streaming and workflow tools first, as the earlier posts in this series describe.
A new model category usually takes years to attract a second vendor. This one attracted a dozen in a month, because nothing about a decision model is hard to copy. The design is small. Take an existing open-weight language model, often from Alibaba’s Qwen family or a vendor’s own small model, and post-train it to emit calibrated probabilities instead of tokens. The interface is public: state in, typed questions in, probabilities out. And the economics are obvious. A decision costs a fraction of a cent and returns in tens of milliseconds. This creates demand in places where an LLM call was never an option, such as a Flink operator, an API gateway or a SQL function over a billion rows. TypeSafe named the model after the economist William Stanley Jevons for exactly this effect, where falling cost increases total demand. The paradox applied to the company itself. The cheaper the decision, the more decision models.
Five weeks separate the first decision model from a full vendor landscape. The timeline below shows who shipped what, and whether each model is a hosted API or open weights.
The launches group into clear waves. The dates and claims below come from the vendors’ own announcements.
More launches will follow, and this list will be outdated within weeks of publication. More projects already exist. InternLM published an Intern-Decision family, H2O.ai and Upstage shipped their own, and one model with 144 million parameters runs on a CPU. PostHog’s Jeeves reasons briefly before it picks. I stop the list here on purpose. The individual models matter less than the pattern: hyperscalers, AI labs, data platforms and open source all arrived within five weeks, and most of them arrived with a compatible interface.
The interface is the same across all of them, the products are not. The six dimensions in the picture below decide where a model fits in an enterprise architecture.
Each dimension changes where a model fits, and most enterprises will combine several variants rather than pick one.
A hosted API means the vendor runs the model. You send the state to it, pay per token and get new versions without operating anything. Open weights means the vendor publishes the trained model files. You run them on your own hardware or in your own cloud account, pay for compute instead of tokens and decide yourself when to upgrade. Jev, OpenAI’s Decisions API, Snowflake Decision, Microsoft-Decision-1 and Liquid’s hosted d1 sit behind a vendor API. Microsoft has not announced open weights and plans to rebase its model on its own and on OpenAI models later. Clef, Strands Decider, Perplexity’s decider, Liquid’s open d1 models and most of the research models ship weights you can run yourself. The lineage matters too. Many open decision models are post-trained from Alibaba’s Qwen models, which some procurement and compliance teams care about. Licenses range from Apache 2.0 to vendor-specific open licenses. For a regulated environment, open weights plus a local runtime turn the decision model into a component in your own data center or cloud account. No state goes to a model vendor.
Snowflake put the model inside a SQL function. It inherits the warehouse’s access controls, audit policies and governance, and the decision runs next to the data. Cloudflare put it on the edge network. Microsoft put it in Foundry next to its other models. OpenAI put it behind the same API developers already call. An embedded decision model wins when the state already lives in that platform. A standalone model wins when you want the best measured quality for a job and the freedom to run it anywhere. Most large enterprises will end up with both. This is one more reason to keep the call behind a stable interface.
Sizes run from a few hundred million parameters to 27B. The small ones answer in single-digit milliseconds on a consumer GPU, the large ones need a proper serving stack. Input started as text only. Several models now take images. Cloudflare’s Clef-omni and Liquid’s experimental d1-omni take audio as well, and Clef-omni also takes video. This opens inspection, call analysis and quality checks in manufacturing, logistics and customer service. Most dedicated decision models answer in one forward pass. OpenAI took a different route and runs its existing GPT-6 Luna LLM behind a decision interface, and PostHog’s Jeeves reasons briefly before it picks. Both trade latency for accuracy on hard cases. And a model can be generic or fine-tuned on your own labels for one task. Cloudflare’s RL platform offers the latter. A fine-tuned decision model is the “model you train yourself” from the first post of this series, built on a decision model backbone instead of from scratch.
The picture below shows the request schema every vendor adopted. The model sources sit on the left and the four places where a decision runs on the right.
The decisive move came from the fast followers, who did not invent a new interface but copied TypeSafe’s. Clef is API-compatible so existing Jev clients swap the endpoint and nothing else. Microsoft ships a compatible client. Snowflake uses the same three question types. Liquid supports the same three modes. vLLM, llama.cpp and Ollaya serve any open decision model behind the same request shape. The de facto standard of this category is TypeSafe’s request schema, and the model behind it is interchangeable.
The schema itself is small, which is part of why it spread:
This has happened before. The Chat Completions API became the standard for LLM access. Most inference servers and many competing model vendors speak it. The S3 API became the standard for object storage, and every storage vendor implements it. In both cases the first mover owns the interface, and the value is captured by whoever runs the workload cheapest and closest to the data. Decision models follow the same path, only faster.
Treat the decision model as a component behind a contract you own. Do not hardwire a vendor SDK into business logic. Put the call behind your own interface. Log the state, the question, the answer, the probabilities and the model version for every decision. Keep the thresholds and the escalation paths in the workflow, as the orchestration post describes. With that in place, a move from a hosted API to a self-hosted open model is a configuration change plus a re-validation. The same holds for a move from one vendor to another. Every vendor shipping a compatible interface is a reason to build for replaceability from day one.
Every vendor is the best on its own benchmark. Liquid AI claimed the first win over Jev on the Decision Index. Perplexity claims the top score on the next index version. Snowflake claims the highest score among 72 models on a subset of benchmarks its interface can run end to end. Cloudflare claims the lead on its own live benchmark site. All four claims can be true at the same time, because the index changes versions, each vendor picks the subset that fits its interface, and every number is vendor-run. I leave the scores out of this post on purpose. They change weekly and they would date the article faster than anything else in it.
Independent evidence is only starting to appear, and it points in a consistent direction. Narrow yes-or-no questions are already commodity, and small open models match the leader there. Frontier LLMs still beat decision models on accuracy for hard cases, at many times the cost and latency. Calibration differs a lot between models. It often needs a temperature fit on your own data before the confidence values mean what they claim. Practitioner tests show the leader ahead on many-way choices over messy inputs and on consistency of confidence across similar cases. The first adversarial benchmark for typed decision models shows another side effect of the design. A model that never generates text still returns a well-formed answer when it is manipulated, so an attack is harder to notice. And a label-flip critique made the rounds. Swap the meaning of the yes and no labels and accuracy collapses. The models follow the labels rather than the meaning behind them.
Benchmark scores do not transfer to your data. Run your own evaluation before you trust a confidence value. Measure accuracy on a labeled set from your own domain, calibration error, and the share of cases that clear your automation threshold. Add latency at the 99th percentile and cost per million decisions. Test invalid options, numbers and dates explicitly, since they are known weak spots across the category. Repeat the evaluation on every model version. Several vendors move their “latest” alias to a new version within days of a release. A decision model that silently changed under a fixed threshold is a production incident waiting to happen.
About three weeks after launch, TypeSafe announced an $870 million Series A at a $7.5 billion valuation, led by a16z. The company claims more than 1 million users within days of the release and says about a third of the Fortune 500 use Jev, without naming a customer. The one third-party data point so far comes from Vercel. It reports that Jev reached 35 percent of paid AI Gateway teams within two weeks, the fastest adoption of any model on the platform. OpenRouter’s decision-model leaderboard, ranked by routed requests, showed Jev ahead of OpenAI, Perplexity and Cloudflare in the first weeks. In the same three weeks, the request schema was copied, the model was cloned by two hyperscalers, and Microsoft matched the price to the cent. Jev 1.14 pushes into vision, bounding boxes and long context. This reads as the next primitive rather than a defense of the current one.
So where is the moat? What remains with TypeSafe is the first-mover brand and the calibration lead on messy many-way choices that practitioner tests still show. Add the integrations into developer platforms and workflow tools, the benchmark it defined, and the speed to expand into new question types. Whether that is worth $7.5 billion is a question for investors. For architects the message is simpler. The category will exist regardless of what happens to the company, because the interface already lives in the open source inference servers and in the hyperscalers’ catalogs.
The earlier posts in this series put decision models into the Trinity of Modern Data Architecture. Event-driven integration prepares the state. Process intelligence turns the confidence value into a workflow branch. Trusted agentic AI uses the model as a guard before an agent acts. The arrival of a whole category changes three things in how you plan that.
Decision models now run in four natural places:
Pick the deployment by where the state lives and what latency the use case needs, then pick the model with the best measured quality in that place. The compatible interface makes the second choice reversible. The first one is the architecture decision.
The confidence gate only works if the confidence is calibrated for your inputs. A model that says 0.9 should be right about nine times out of ten on your cases, not on a benchmark. Build the evaluation set before the first deployment, fit the threshold on it, and route everything below the threshold to an LLM or a person. The decision log then becomes the training data for the next round. Once a use case has enough volume, it also feeds a model you train yourself on your own labels.
For data that must not go to a vendor, the open-weight models and the local runtimes close the gap that existed in September. A decision model has 2 to 27 billion parameters, small compared to frontier LLMs. It runs on a single GPU behind vLLM or llama.cpp in your own data center or cloud account. It speaks the same request schema as the hosted APIs and is validated with the same evaluation set. The sovereignty question for decision models is no longer whether an option exists. It is which license, which base model lineage and which operations cost you accept.
The skeptics have a point, and it is worth stating plainly. A decision model is a packaged classifier with a good interface and good calibration, not a new form of intelligence. The packaging is the point, but it does not change what the model can do. Use an LLM when the answer is open-ended text, an explanation or a plan. Use a frontier LLM when accuracy on hard reasoning is the priority and cost is secondary. Or combine both: the decision model takes the first pass and the low-confidence cases escalate. Use rules when the logic is fixed and must be fully specified, as the first post discusses for DMN-style decision tables. Add guardrails and human review for adversarial input and high-stakes outcomes, because the first adversarial benchmarks show that typed answers can be pushed around without any visible sign. And test numbers, dates and ordinal scales explicitly, since every independent evaluation so far names them as weak spots.
For a buyer, the standard interface removes the lock-in argument from the vendor conversation. Negotiate on measured quality, price per million decisions, deployment options and data residency, and keep the option to switch in the contract. For a system integrator, the work moves from model selection to evaluation sets, calibration, threshold design and the escalation workflow, which is where the billable architecture work sits. For an investor, the market structure is already visible. The model itself is on its way to commodity pricing, set by the hyperscalers within four weeks. Value accrues in three places. The platforms that run the decision next to the data they already hold. The tooling for evaluation and fine-tuning on customer labels. And the orchestration layer that owns the thresholds and the decision log. A standalone decision model vendor needs a lead in calibration, integrations or new question types to justify a premium. TypeSafe’s $870 million round is a bet that this lead can be kept.
Jev started a category and lost the naming rights within a month. Decision models now sit as a third option next to classic machine learning models trained for one task and LLMs that generate text. They complement both rather than replace either. The market calls these models decision models and speaks TypeSafe’s request schema. It ranks them on a benchmark every vendor wins on its own subset. It prices them at the same fraction of a cent. For enterprise architecture the result is good news. A decision model is now a replaceable component behind a stable contract. It is available as a hosted API, as a SQL function, on the edge, in the stream and in the workflow orchestrator, and as open weights in your own environment. The work that remains is yours: pick the deployment, build the evaluation set, calibrate the threshold, log every decision and keep the escalation path in the workflow. The model behind the interface will change several more times. The architecture around it should not.
To follow this work across data integration, workflow orchestration, process intelligence, and trusted agentic AI, subscribe to the newsletter and connect on LinkedIn.
Kafka moves the events, but nothing coordinates what happens next. This post shows how Kestra…
The Industrial IoT Landscape Q4 2026 maps vendors and open source from edge to cloud…
Telecom has more orchestration standards than any other industry, and the maturity stops at the…
Jev by TypeSafe AI returns a calibrated probability instead of text. In a workflow that…
Jev by TypeSafe AI returns typed decisions with calibrated probabilities in a few hundred milliseconds.…
System One models such as Jev by TypeSafe AI answer typed questions with calibrated probabilities…