{"slug": "my-take-on-jev", "title": "My Take on Jev", "summary": "TypeSafe AI released Jev on September 15, 2026, a \"System One\" model that returns typed answers with probabilities instead of generating text, according to a blog post reviewing the model. The post's author argues Jev addresses three problems with using autoregressive LLMs as application primitives: inefficiency of unstructured text as a machine communication protocol, uncalibrated confidence signals, and nondeterminism. In the post's routing example, Jev returned \"cancellation\" with confidence 0.9 and probabilities of 0.05 for status_check, 0.92 for cancellation, and 0.03 for complaint.", "body_md": "[← Back to Blog](https://sunbeams.ai/blog)\n\n# My take on Jev\n\nMy take on Jev? Love it as the first in a new class of models that allow us to build LLM applications more efficiently and at lower cost. I see this as a first step, and I expect other new model types that we can use programmatically.\n\nIf you need a quick overview, this one is nice:\n\nAnd here’s the quick background: Jev is the first model from TypeSafe AI, released on September 15, 2026. They call it a “System One” model, which is a model designed to make quick decisions, based on the concept of System One (“fast”) thinking described in Daniel Kahneman’s book *Thinking, Fast and Slow* (great book btw, but a little too long).\n\nThe model does not generate text. Instead, you send it some state plus typed questions, and you get typed answers with probabilities.\n\nFor example, here’s a query:\n\n```\n{\n  \"model\": \"jev-latest\",\n  \"state\": \"Hi, I signed up last week and I want to cancel before my card gets charged.\",\n  \"questions\": {\n    \"query_type\": {\n      \"type\": \"choice\",\n      \"instructions\": \"Which category is an appropriate match for the user query\",\n      \"criteria\": {\n        \"status_check\": \"Customer is asking about the state of an order, ticket, or account\",\n        \"cancellation\": \"Customer wants to cancel a subscription, order, or service\",\n        \"complaint\": \"Customer is unhappy with a product or experience and wants it addressed\"\n      }\n    }\n  }\n}\n```\n\nand a response:\n\n```\n{\n  ...\n  \"query_type\": {\n    \"type\": \"choice\",\n    \"choice\": \"cancellation\",\n    \"confidence\": 0.9,\n    \"probabilities\": {\n      \"status_check\": 0.05,\n      \"cancellation\": 0.92,\n      \"complaint\": 0.03\n    }\n  }\n}\n```\n\nCurrently, the AI applications we build use LLMs as a primitive because they provide something that our old programming primitives (data structures, control flow, functions) can’t: they can work with natural language inputs, and they make it pretty easy to put together an agent that “figures things out” with some instructions and access to a set of tools. The workflows that an app supports don’t need to be programmed one at a time. All this is pretty cool.\n\nBut, LLMs (the ones we’re all familiar with, with an autoregressive loop that does next-token prediction) are also kind of insane to use as primitives for applications:\n\n1. **They are very inefficient:** unstructured text ends up being the communication protocol between machines. Take a prompt to power an agentic router, which may look something like:\n\n```\nYou are an assistant that routes user queries to the appropriate category.\nHere are your options: \n- Status check\n- Cancellation\n- Complaint\nHere is the user query: {query}\nRespond in json with the following format: {\"query_type\": ...} and nothing else.\n```\n\n You get a response from your LLM that you now need to parse and map to expected format and types, you need to handle type errors, you need to retry when you don’t get the expected format. That’s a lot of overhead!\n2. **They don’t give a sense of certainty:** you have no trustworthy information about whether it was a close call between “Cancellation” and any of the other options. You can pull logprobs from most APIs, but those numbers aren’t calibrated, so they’re not very meaningful. You end up doing a bunch of calibration and testing to see how reliable this routing prompt is. Or just hope it sort of works.\n3. Not to mention, **they are nondeterministic!** We are trying to build reliable software on top of a primitive that gives us different results every time, and we don’t have any guarantees around consistency.\n\nSo, LLMs are a stopgap for many decision tasks, and there are many aspects that can be improved!\n\nI love that Jev introduces a new class of models that can be used as (better) programmatic primitives.\n\nTo go back to the routing example above, we send a `choice` query as input to Jev. There is no need to parse structured outputs, and we get guarantees around our response format and types, no need to manage that! The model can’t return anything outside the options that have been defined. In addition, the probabilities are (intended to be) calibrated and consistent, so although they can drift slightly between calls, the idea is that when the probabilities are high, they are more reliable for control flow. It’s also fast and cheap because output is not generated autoregressively and is very short.\n\nIt’s a step towards what I expect to be other new classes of models that will behave more favorably as primitives in our applications.", "url": "https://wpnews.pro/news/my-take-on-jev", "canonical_source": "https://sunbeams.ai/blog/jev-new-class-of-models/", "published_at": "2026-09-25 13:44:42+00:00", "updated_at": "2026-09-25 14:02:44.096358+00:00", "lang": "en", "topics": ["large-language-models", "ai-products", "ai-agents", "developer-tools"], "entities": ["TypeSafe AI", "Jev", "Daniel Kahneman", "Thinking, Fast and Slow"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/my-take-on-jev", "markdown": "https://wpnews.pro/news/my-take-on-jev.md", "text": "https://wpnews.pro/news/my-take-on-jev.txt", "jsonld": "https://wpnews.pro/news/my-take-on-jev.jsonld"}}