Decisions, Not Text: What a System One Model Changes About the Cost of AI in Claims

How Akhil Koduri Measured a Decision Model Against a Frontier LLM on the Same Claims-Triage Task, and What the Numbers Mean for System Design 

Open prototype, measured results. The prototype, test data and comparison code described here are open source at github.com/akhilkoduriak/jev-claim-processor [9]. All claims are synthetic. Figures come from runs on 24 September 2026 at published list prices unless noted otherwise. 

Most enterprise AI of the past three years has been built on one kind of model: one that writes. Ask a question, get a paragraph. For drafting, search and summarization, that is the point. But a large share of enterprise work is not writing at all. It is deciding—approve or deny, escalate or not, route here or there—at volumes where every cent and every second per decision is multiplied millions of times. 

Akhil Koduri, a Senior IEEE member, an independent researcher and PhD student focusing on Artificial Intelligence, set out to measure what changes when the model doing that work is built for decisions rather than text. Using Jev, the first “System One” model from TypeSafe AI [1], he built an insurance claims-triage prototype and ran it head to head against Claude Opus 5, one of the most capable generative models available, on the same task. 

A Different Kind of Model 

The name borrows Daniel Kahneman’s “System 1,” the fast, intuitive mode of human judgment [2]. Jev does not generate a response. A developer defines questions in advance, each with a fixed set of allowed answers, and Jev answers all of them against the supplied data in a single pass. Each answer comes back typed—a choice among named options, a position on a defined scale, or a yes/no probability—together with the probability of every option and a confidence value. TypeSafe lists the model at $0.042 per million input tokens, with output tokens free [3]. 

“In a claims workflow, nobody needs a paragraph about every claim. They need a decision the system can act on, and an honest signal of how sure it is. That is a different product from a text generator.”— Akhil Koduri 

Because the answer space is fixed, there is nothing to parse and nothing the model can invent outside the options. The engineering questions change accordingly: from how to constrain free text, to how to design good questions and what to do with each level of confidence. 

The Experiment 

Koduri’s prototype asks six questions of every claim: whether to approve it, deny it or send it for review; what type of care it covers; how medically necessary the treatment is; whether the price is typical for the service; whether the billing pattern looks unusual; and how urgently an adjuster should look. The test set is 46 synthetic claims spanning emergency care, chronic conditions, surgery, imaging, overbilling, frequent-claim patterns and very large claims. 

To keep the comparison fair to the generative model, Claude received exactly what Jev received: the same claim fields, the same six questions and the same answer options with their descriptions. It was required to reply with a strict JSON object and no explanation—the smallest output a generative model can give for this task—and it ran at a low effort setting suited to classification. The patient’s name was never sent to either model. 

What the Numbers Showed  

Table 1. Jev and Claude Opus 5 on the same 46 synthetic claims, 24 September 2026. Claude ran at a low effort setting and returned strict JSON with no explanation. Costs are published list prices [3], [6]; the reseller rate actually paid for Jev was roughly ten times list. 

At list prices, Jev cost about $43 per million claims against roughly $9,900 for Claude Opus 5, a gap of about 230 times, and it answered about four times faster. Two qualifications matter. Koduri reached Jev through a third-party endpoint that bills roughly ten times TypeSafe’s list price; at what he actually paid, the gap was closer to 23 times—still an order of magnitude. And Opus is the top tier of Claude’s lineup; a smaller model would narrow the gap. 

The structural reason for the difference shows in the token counts. Claude generated 74 output tokens per claim even with no explanation requested; Jev’s output carries no charge at all. 

“Measured at list price, the difference is two orders of magnitude. Measured at what I actually paid, it is one. I report both, because the first number is what gets shared and the second is what gets budgeted.”— Akhil Koduri 

Where the Engines Disagreed 

On decisions, the two engines agreed on 34 of the 46 claims. Every one of the twelve disagreements went the same way: Jev approved the claim and Claude sent it to a human for review. Claude never approved a claim that Jev held back. Rerunning 35 of the claims changed neither engine’s decisions. 

Koduri is careful about what this does and does not show. The test claims carry expected outcomes, but those come from his own rule-based baseline, not from adjudicated real claims. Against that baseline Jev matched 42 of 46 and Claude 38; Claude’s misses were routine claims it sent to review, while it caught two large surgical claims that Jev approved. Without ground truth, agreement tells an engineer where to look, not which engine is right. What it does reveal is that the two engines carry different risk postures—and in claims, where a wrongful denial and a wrongful approval carry different costs, that is a design input. 

Designing Around Confidence 

The more consequential finding is architectural. Jev’s confidence is not a self-reported number; according to TypeSafe’s documentation, it is computed from how concentrated the probability distribution is [4]. In one live test, Jev chose to approve an emergency claim with 69 percent probability but only 53 percent confidence, and the prototype’s policy rule—no automatic decision below 60 percent—sent it to review. That is the behavior a regulated workflow needs: a model that can say, in a form software can act on, that it is not sure. 

That points to a cascade rather than a replacement, a pattern TypeSafe calls confidence-gated routing [5] and one with precedent in research on LLM cascades [7]: 

Figure 1. Jev answers every claim in a single pass; a confidence gate and deterministic policy rules decide which claims proceed automatically and which escalate to an LLM or a human adjuster. 

• Jev on all volume — every claim receives six typed answers in a single pass, at a cost low enough to run on everything. 

• A confidence gate — high-confidence, routine claims proceed automatically; TypeSafe’s own guidance reserves automatic action for confidence above 0.9 [4]. 

• Policy rules outside the model — deterministic rules, such as review for any claim of $50,000 or more, apply regardless of which engine decided. 

• Escalation for the ambiguous tail — uncertain or high-stakes claims go to a generative model or a human adjuster, so expensive reasoning runs only where it adds value. 

“The goal isn’t to replace the LLM. It’s to stop paying LLM prices for decisions that don’t need an LLM, and to keep the expensive reasoning for the cases that do.”— Akhil Koduri 

What Comes Next 

The prototype is an engineering comparison, and Koduri is explicit about its limits. Forty-six synthetic claims is a small sample. The expected outcomes come from a rule baseline rather than adjudicated claims. Only one generative model and one effort setting were tested, and Jev was reached through a third-party reseller rather than TypeSafe’s own API. 

That scope defines the next steps: repeating the comparison against smaller Claude models and TypeSafe’s direct endpoint; measuring the cascade’s escalation rate and end-to-end cost on realistic claim mixes; calibrating confidence thresholds against adjudicated outcomes, since a model’s stated confidence cannot be assumed to be calibrated [8]; and settling the data-handling questions—residency, retention and protected health information—that any real claims deployment must answer before a single live claim is sent to an external model. 

“A cheaper decision is only worth having if you know when it’s wrong. Calibration against real outcomes is the work that turns this from a benchmark into a system.”— Akhil Koduri 

Why This Matters Now 

As AI moves from answering questions to making operational decisions, the unit economics shift. When a system makes millions of small decisions, cost and latency per decision stop being line items and become architectural constraints. Models built to decide rather than to write—typed, single-pass and explicit about their confidence—give engineers a new option for that layer of the stack. 

The question for enterprises is no longer only which model is most capable, but which decisions need that capability at all. Designing that answer into the architecture may matter as much as the models themselves. 

References 

[1] TypeSafe AI, “System One,” TypeSafe documentation. https://docs.typesafe.ai/concepts/system-one 

[2] D. Kahneman, Thinking, Fast and Slow. New York, NY, USA: Farrar, Straus and Giroux, 2011. 

[3] TypeSafe AI, “Models,” TypeSafe documentation (pricing). https://docs.typesafe.ai/models 

[4] TypeSafe AI, “Confidence,” TypeSafe documentation. https://docs.typesafe.ai/confidence 

[5] TypeSafe AI, “Confidence-gated routing,” TypeSafe documentation. https://docs.typesafe.ai/patterns/confidence-routing 

[6] Anthropic, “Pricing,” Claude Platform documentation. https://platform.claude.com/docs/en/about-claude/pricing 

[7] L. Chen, M. Zaharia, and J. Zou, “FrugalGPT: How to Use Large Language Models While Reducing Cost and Improving Performance,” arXiv:2305.05176, 2023. https://arxiv.org/abs/2305.05176 

[8] C. Guo, G. Pleiss, Y. Sun, and K. Q. Weinberger, “On Calibration of Modern Neural Networks,” in Proc. 34th Int. Conf. Machine Learning (ICML), 2017. https://arxiv.org/abs/1706.04599 

[9] A. Koduri, “jev-claim-processor,” GitHub repository, 2026. https://github.com/akhilkoduriak/jev-claim-processor