In the last week of September 2026 a new kind of model went from curiosity to category, and it did so quietly. It doesn't write. You give it a situation and a typed question, and it hands back a probability. Is this invoice a duplicate? 0.91. Which of these four tools should the agent call? Option C, 0.74. Should this refund go through without a human? 0.38, so a person gets it.
Within about two weeks four serious players were shipping one. TypeSafe AI had launched the original. Then OpenAI, Amazon, Cloudflare and Liquid AI all followed. Most coverage treated this as a speed and price story, and the numbers are wild. I think the bigger story sits underneath. These models finally give a clean answer to a question executives have been arguing about for three years, which is when to build vs buy AI. My answer is that you buy the part that talks and build the part that decides. The reason is a single number that no vendor can sell you, because it doesn't exist until your own losses produce it.
A model that refuses to talk
Start with what happened, in order.
TypeSafe AI, a San Francisco lab co-founded by Diogo Almeida, Erik Gafni and Sasha Sheng, released Jev in September. InfoQ's write-up describes how it works. A caller sends a state plus a set of typed questions, and Jev answers all of them in one parallel pass with a probability distribution and a confidence value. Input costs $0.042 per million tokens. Output is free, because there is no output in the usual sense. TypeSafe quotes 70ms to 500ms end to end. Vercel added it to its AI Gateway on day two and reported that it reached nearly 13% of paid teams within 24 hours, twice the share of the GPT-5.6 family.
On September 29, at DevDay, Sam Altman mentioned a Decisions API almost as an aside. TechCrunch reported that it gives OpenAI's Luna model a predefined set of options to choose from, and quoted Altman: "By focusing the model on that choice, we can make it extremely fast." It shipped as a limited preview.
On October 1, AWS's Strands Labs open-sourced Strands Decider 2B. Techstrong reports roughly 1.9 billion parameters built on Qwen3.5-2B-Base, with the language head torn off and a scoring head of about a million parameters bolted on. Median latency is 115 ms on a single Nvidia RTX 3090, a gaming card. TechCrunch's account says Amazon distinguished engineer Marc Brooker built a homebrew version after seeing Jev, and it briefly ranked first in its size class before Amazon engineers cleaned it up for release. His description of the use: "they make a perfect decider for a workflow step."
The same day, Cloudflare released Clef and Clef-flash, its first models trained in-house by the Workers AI team. According to Cloudflare's changelog, Clef is 27B and Clef-flash is 9B, both Apache 2.0 on Hugging Face. Clef-flash posts a median latency of 38.8 ms against 524.1 ms for Jev in Cloudflare's own runs. The same page mentions a reinforcement learning fine-tuning service for tuning Clef on your own workloads, open for now through a design partner program.
On October 15, Liquid AI released d1-ultra. GIGAZINE's summary gives a score of 65 on the Artificial Analysis Decision Index against 57 for Jev 1.14, and a calibration error of 1.5 points against Jev's 2.7.
So that's five decision models in about a month, from a startup, a frontier lab, two infrastructure giants and an edge-model company. When the people who own the pipes start shipping the same small thing, the thing has become a component.
Where the build vs buy line moved
For three years the build vs buy AI debate has been framed badly. The "build" side meant training a foundation model, which almost nobody should do, or a sprawling internal platform that collapsed under its own integration work. The "buy" side meant renting a general model through an API or a SaaS seat and hoping your prompts held up. Executives were choosing between a moonshot and a subscription, and most of them sensibly picked the subscription.
The consensus that formed was a hedge. A typical piece from InfotechLead in October 2026 describes CIOs going "hybrid": buy standardized AI, build differentiated AI. That's correct and useless, the way "buy low, sell high" is correct and useless. It never says where the seam is.
Decision models put the seam somewhere you can point at. Every agentic workflow, every automated process, every AI feature in your product is made of two kinds of work. One kind produces language: drafting the email, summarizing the contract, writing the code, explaining the denial. The other kind produces a verdict: approve or escalate, route left or right, flag or pass, pay or hold. Until September those two jobs were done by the same model in the same call, so the decision lived inside a paragraph of generated text and nobody could price it, test it or own it separately.
Now they come apart. The verdict has its own model, its own API, its own latency budget and its own cost line, which is close to zero.
Buy the generation
Generation is a frontier problem. Writing a good contract summary in 44 languages takes scale, and the labs are spending tens of billions to stay ahead of each other on it. Your edge in prose is small and shrinking every quarter. Whatever you build here is a depreciating asset with a competitor who resets the market twice a year. Buy it, keep two vendors wired in, and spend your attention elsewhere.
Build the threshold
The verdict is where your business actually lives. A bank's appetite for false positives on fraud isn't a fact about language. It comes out of that bank's chargeback costs, its regulator, its customer base and how much it hates angry phone calls. A logistics firm's decision to reroute a truck depends on contracts with specific shippers. These choices are your policy, and in the old setup your policy was buried inside a vendor's generative model, expressed as a prompt that said something like "be conservative with refunds."
A decision model makes the policy explicit. It returns 0.62. You decide what 0.62 means. Armin Ronacher, CTO of Earendil, told TechCrunch that the design "delegates the hallucination problem a little bit to the user." He meant it as a caution, and it is one. It's also the most important line anyone wrote about these models this month, because the problem being handed back is a business problem that never belonged to the vendor.
Calibration is local
Every vendor in this category leads with calibration. Liquid says that when d1-ultra reports 90%, it should be right about 90% of the time. Cloudflare trained Clef with a Brier loss for the same reason. The pitch is that you can finally trust the number.
Read the fine print on the Strands release. Techstrong notes that Decider's confidence scores were calibrated on a separate set of short classification examples, so developers should validate them on their own workloads. Strands is telling you plainly what everyone else implies. A probability is calibrated against some distribution. The vendor's 80% means "right 80% of the time on our evaluation set." It means nothing yet about your invoices, your claims queue or your support tickets.
This is the structural point, and it's why build vs buy now has a real answer. Calibration only exists relative to outcomes. The outcomes that matter are yours: which flagged transactions turned out to be fraud, which escalated tickets actually needed a human, which auto-approved refunds came back as abuse. A vendor can sell you a well-shaped instrument. It can't sell you the readings, because the readings are produced by your customers behaving in your markets over your history.
Suppose you run an insurance claims operation and you wire a decision model in to fast-track simple claims. Say the vendor's model reports 0.85 confidence on a batch, and on the vendor's benchmark 0.85 really does mean 85%. On your book, where claim types skew toward water damage in older housing stock, that same 0.85 might mean 71%. You won't find out from the vendor's dashboard. You'll find out from your loss ratio, about two quarters later.
So the asset worth building is the loop that makes the number honest. In practice that means four things. You need labeled outcomes flowing back from the decisions the model made. You need a fine-tuning or recalibration pass on those outcomes, which Cloudflare is now offering as a service and which Strands makes possible because the weights are open. You need thresholds set by the people who carry the losses. And you need a record of which version of the model and which threshold made each call, so you can change one without silently changing the other.
None of that is exotic engineering. Brooker told TechCrunch that building a model in smaller markets costs hundreds or thousands of dollars, and that he doesn't expect frontier labs to dominate the space. A 1.9 billion parameter model that runs on a gaming card is something your existing data team can fine-tune this quarter, with no new hires.
The clone wars are a pricing signal
Almeida joked on X about the start of "clone wars" when OpenAI announced its version. He's right, and executives should read the clones as a forecast.
When a capability gets cloned by OpenAI, AWS and Cloudflare inside three weeks, the base model is headed toward free. Jev already charges nothing for output. Strands Decider costs nothing at all if you run it yourself. Clef weights are Apache 2.0. The price of a generic decision is collapsing to the cost of electricity, which tells you the generic decision isn't where anyone will make money.
Almeida's own bet says the same thing in different words. He told TechCrunch that TypeSafe's moat is the synthetic data it creates, and a week earlier said: "Intelligence is the hard part, and my North Star is always pushing the intelligence-per-dollar Pareto curve." Of the cloners he said "they might be underestimating the difficulty of making the models actually smart." He may be right about general intelligence per dollar. That race belongs to the vendors, and you can ride it by switching models whenever a better one ships. Clef was built to follow the same System One interface as Jev, so moving an existing integration means changing an endpoint and a model name. That kind of portability is what you'd expect from a commodity.
The flip side is that the decision logic specific to your firm can't be cloned, because nobody else has the outcomes that trained it. Your competitors can buy the same Clef you buy. They can't buy your three years of resolved fraud cases.
There's also a sharp cost argument for doing this now. TechCrunch reported on a hackathon demo by Shapor Naghibzadeh, who leads the startup QueryStory, that used Jev to check each agent action against its assigned task. It blocked high-confidence bad actions, flagged the uncertain ones for review and let the rest through. The comparison in that article was $2.94 to monitor with Jev against $372 with a frontier LLM. At that ratio, checking every action an agent takes becomes a rounding error, and that changes which agent deployments are even worth considering. The checker still needs to know what "bad" means in your shop, though. That knowledge has to come from your side.
What the numbers don't say
The skeptics have good points, and they make the case for building stronger.
The headline speedups are inflated. InfoQ cites an OpenChamber analysis of 12,759 launch tweets that found user-reported speedups with a median of 7x, against the 193.6x headline. Cost savings had a median of 30x. Seven times faster and thirty times cheaper is still a big deal, but it's an engineering improvement. It doesn't change what's physically possible.
The "can't hallucinate" claim is overstated too. A Hacker News commenter quoted by InfoQ pointed out that Jev can't emit an invalid type but can emit a completely wrong valid value. That's true. A decision model will tell you with great confidence that a fraudulent invoice is clean, in a perfectly formatted probability. Structure doesn't make it correct. It only makes it measurable.
The models also have hard limits. TypeSafe's own documentation for jev-1.13, per InfoQ, flags unreliable counting, arithmetic and date comparison, and advises keeping the maths in code. The Techstrong piece is blunter about Strands: "Decider cannot write code, summarize documents, carry on a conversation, or excel at complex reasoning tasks." On the hard tier of JevBench it scored 50.5%.
Every one of these weaknesses points the same way. If the confidence scores drift, you need your own outcome data to catch it. If the model can be confidently wrong, you need thresholds set by people who understand what a wrong answer costs. If it can't do arithmetic, you need your engineers to decide which parts of the decision run in deterministic code and which run in the model. None of those jobs can be handed to a vendor. A vendor can make the model better on average, and only you can make it correct for your business.
A sequence, in plain order
Here's how I'd run it if I were sitting in your operating seat this month.
First, inventory the verdicts. Go through every AI-touched workflow and pull out each point where the system makes a choice with consequences. Most firms will find that their "AI assistant" deployments contain dozens of buried decisions: whether to escalate, which template to use, whether a document is complete. Write them down as typed questions. That list is your decision surface, and today almost all of it lives inside prompts nobody reviews.
Second, find where the outcome data already exists. Some decisions resolve fast and leave a record: a ticket gets reopened, a payment bounces, a shipment arrives late. Others resolve slowly or never. Start with the fast, recorded ones, because that's where calibration can actually happen. A decision you can't score later is one you shouldn't automate yet.
Third, run a cheap model in shadow. Put Strands Decider or Clef-flash beside the existing process and log its probabilities without acting on them. Suppose you shadow a refund queue for six weeks. At the end you'll have a calibration curve for your own data, and you'll know whether the model's 0.8 is your 0.8. That costs almost nothing, given the prices above.
Fourth, give the threshold to the person who owns the loss. Your fraud lead or claims director should set it, with the curve in front of them, and it should be reviewed on the same cycle as any other risk limit. The threshold is a policy instrument. Treat it like a credit limit, with a named owner and a change log.
Fifth, retrain on your outcomes, then keep switching base models. Once the loop exists, the base model is replaceable. When Liquid ships something better, or Cloudflare's fine-tuning service opens beyond design partners, you swap the backbone and re-run calibration on the same outcome set. Your asset is the labeled history and the loop that uses it, and no vendor's release cycle touches that.
Buy everything on the generation side. Pick two frontier providers for drafting, summarizing and coding, contract for flexibility, and refuse multi-year lock-in on anything that writes paragraphs.
Why this is a design job
This is the part where most companies will go wrong, and they'll go wrong by shopping.
The natural response to a hot model category is procurement. Someone runs a bake-off between Jev, Clef and Decisions API, picks a winner on a benchmark, signs a contract and calls it a decision strategy. They'll have bought a fast, cheap, well-calibrated instrument tuned on somebody else's world, then wired it to thresholds nobody owns. It'll work in the demo. Six months later it'll be quietly approving the wrong 15% of something, and the first person to notice will be the CFO.
The value in this shift comes from the architecture around the model: separating verdicts from prose across your workflows, the outcome pipelines feeding calibration, the governance that ties every threshold to a named owner, and the versioning that keeps a model swap from turning into a policy change. That design work cuts across finance, operations, risk and engineering. It's hard to do from inside any one of them, because each sees only its own decisions. It also has a deadline. Once these models show up in every vendor's product, which at this pace means months, your verdicts will default to whoever ships the product, and your risk policy will be whatever their threshold happens to be.
Agor AI Advisory does this design work. We map the decision surface, separate what to buy from what to build, set up the outcome loops, and hand your team a system it owns and can change without calling us. The vendors will keep competing on whose model is smartest per dollar, and that's good for you. Your own eighty percent has to be built in-house, starting while the instruments are still cheap and your competitors are still reading benchmark tables.
Sources
- TechCrunch, "OpenAI's Jev clone could help the frontier lab stop its swarming agents," September 30, 2026
- TechCrunch, "Amazon releases its own Jev clone as decision models flood the web," October 1, 2026
- InfoQ, "TypeSafe AI Releases Jev: a Decision-Only Model That Returns Typed Probabilities Instead of Text," October 2026
- Cloudflare Changelog, "Introducing Clef: Cloudflare's first open-source decision models, now on Workers AI," October 1, 2026
- Techstrong.ai, "AWS Explores Decision Models With Strands Decider 2B," October 2026
- GIGAZINE, "The decision-making model d1-ultra has been released," October 16, 2026
- InfotechLead, "Build vs Buy AI in 2026: Why CIOs Are Choosing a Hybrid Strategy," October 2026