Jev, Claude, and a Different Way to Think About AI in a Token-Based Economy
For the last few years, whenever we had a problem that required some form of intelligence, our instinct was almost automatic: send the context to a large language model and ask it what to do.
That approach made sense. Models such as Claude are remarkably capable because they can understand a situation, reason about it, explain their thinking, generate content, write code, use tools, and work through multi step problems. If the problem is open ended, that flexibility is exactly what we want.
But recently I started thinking about a different class of problems inside enterprise software.
A customer request needs to be routed to Billing, Shipping, or Technical Support. A transaction needs to be labeled Low, Medium, or High Risk. A workflow needs to Continue, Retry, Escalate, or Stop. A request needs to be Approved, Reviewed, or Rejected.
Notice what is different about these problems.
The choices already exist.
The system is not asking AI to invent an answer. It is asking AI to understand some messy, unstructured context and choose the most appropriate answer from a known set of possibilities.
That is what made TypeSafe AI's Jev interesting to me.
It also gave me a simple analogy that helped me understand the difference between a decision-oriented model such as Jev and a general-purpose model such as Claude:
Are we sometimes hiring a chef when all we really need is someone intelligent enough to pick the right item from the menu?
Jev Starts With the Menu
TypeSafe describes Jev as its first System One Model, designed around a simple idea: take unstructured state as input and produce typed, probabilistic decisions as output.
That is a very different starting point from a chatbot.
Imagine a support application has a customer message, account history, product information, previous interactions, and perhaps some transaction context. The application already knows which questions it needs answered: which department should handle the request, how urgent it is, and whether it should be escalated.
The possible answers are already defined.
Jev's job is to make the semantic judgment.
Conceptually, I think of it like this:
Application context → predefined decision space → semantic judgment → typed probabilities → software action
This is the important part. Jev is not primarily designed to compose a beautiful sentence explaining that a ticket probably belongs to Technical Support. If the software ultimately needs Technical Support with a confidence score, that structured decision is the product.
TypeSafe says Jev is built around typed outputs, a parallel sampling approach rather than ordinary autoregressive text generation, and a training approach called Reinforcement Learning for Calibrated Decisions. The goal is not simply to pick an answer, but to attach useful uncertainty to the decision.
That last part matters a lot in enterprise systems.
If a decision is made with high confidence, perhaps the application can continue automatically. If confidence is lower, another system can verify it. If confidence is very low, the request can be routed to a human.
I would still make one important distinction. A typed output does not mean the semantic judgment is guaranteed to be correct. Jev can still choose the wrong category. What the architecture gives us is a more constrained output space and a decision that is naturally easier for software to consume.
In other words, type safety is not the same thing as semantic correctness.
Claude Starts With the Problem
Claude begins from a much broader place.
Instead of saying, “Here are the choices; tell me which one fits,” we can give Claude a situation and ask it to figure out what should happen.
Using the same support example, I could simply ask Claude which department should receive the ticket, and it could answer “Technical Support.”
But I could also ask it to explain why, summarize the customer problem, propose troubleshooting steps, draft the customer response, determine whether the issue needs a Jira ticket, call an appropriate tool, inspect the result, and decide what to do next.
Now we are no longer talking about classification.
We are talking about reasoning, planning, generation, and possibly tool use.
That is Claude's strength.
So I do not see this as Jev being “better” than Claude or Claude being “too expensive.” They are designed around different kinds of work.
The distinction I find useful is this:
| Jev | Claude | |
|---|---|---|
| Question | Which predefined option fits? | Given this situation, what should happen? |
| Answer space | Bounded | Open |
| Primary role | Semantic decision | Reasoning and generation |
| Output | Typed decisions and probabilities | Language, code, structured output, tool calls |
| Best fit | Repeated bounded judgments | Complex, exploratory or generative work |
And this is where the restaurant analogy becomes useful.
Home Delivery vs. Buffet
Imagine I open a food-delivery application and the restaurant has three choices: Pizza, Burger, and Biryani.
I tell the system, “I want something spicy, vegetarian, and filling.”
The menu has already been created. The system does not need to invent another dish. It does not need to explain where biryani came from or write a recipe. It only needs enough intelligence to understand my preference and decide which existing choice is the best match.
Maybe the result is something like:
Biryani 82% — Pizza 14% — Burger 4%
That is how I think about Jev.
The intelligence is in selecting correctly from a bounded menu.
Now imagine that instead of ordering delivery, I walk into a buffet.
I might ask, “What should I eat?” But I could just as easily ask, “Build me a healthy plate,” “Compare these dishes,” “Suggest something I have not considered,” or “Take these ingredients and create a new meal.”
Now the answer space is much larger.
That is how I think about Claude.
Claude can certainly choose biryani. But it is capable of doing much more than choosing biryani. It can reason about the whole dining experience.
So for me:
Jev is intelligent selection from the menu. Claude can reason beyond the menu.
But Couldn't Claude Do the Same Thing?
This was my next question.
If Claude is already capable of understanding the request, why not simply give it a strict prompt, a schema, some few-shot examples, structured output constraints, or an Agent Skill and force it to return only Pizza, Burger, or Biryani?
Of course we can.
Claude can be constrained very effectively. Modern LLM applications already do this with system instructions, tool schemas, JSON outputs, guardrails, validators, and application logic.
But that changes the question from “Can Claude do it?” to “Is a general-purpose reasoning and generation model the right architecture for every bounded decision?”
We can hire a chef and tell the chef, “Do not cook anything. Just look at the three menu items and tell me which one I should order.”
The chef can absolutely do that.
The more interesting question is whether we needed the chef in the first place.
This becomes especially relevant when the same decision is being made millions of times inside an enterprise application.
The Token Economy Changes the Architecture Conversation
Generative AI has made us think in tokens. We send prompts, documents, conversation history, tool definitions, instructions, and other context into a model. The model processes those tokens and may produce reasoning, generated text, structured outputs, or tool calls.
For many tasks, that cost is worthwhile because we genuinely need the reasoning and generation.
But suppose a workflow is repeatedly asking only:
Approve, Review, or Reject?
Or:
Continue, Retry, Escalate, or Stop?
Or:
Billing, Shipping, or Technical?
If the final answer is always one choice from a small, predefined set, it is worth asking whether every one of those decisions needs to travel through a fully general generative architecture.
That is the idea I find more interesting than any individual benchmark or vendor claim.
Why pay for generation when the application does not need generation?
This does not mean “replace LLMs.” It means we should become more deliberate about where we use them.
And Sometimes We Don't Need AI at All
There is another boundary that is just as important.
If the rule is:
If the user is not authorized, deny access.
We do not need Jev.
We do not need Claude.
We need code.
If the rule is:
If retry count is greater than three, stop.
Again, use code.
AI becomes interesting when the outcome is bounded but the decision cannot easily be expressed as a clean deterministic rule.
For example, “Determine whether this supplier request represents Low, Medium, or High operational risk based on the description, previous activity, contract information, and current business context.”
The three possible outputs are known.
But choosing among them requires understanding meaning.
That is where I now find this simple architecture model useful:
Code = Rules
Jev = Judgment
Claude = Reasoning + Generation
I do not mean this as a rigid rule. I use it as a mental model.
If the decision is deterministic, code should handle it. If the possible answers are known but choosing among them requires semantic judgment, a decision-oriented model becomes interesting. If the problem requires exploration, explanation, planning, synthesis, creation, or dynamic tool use, a general-purpose reasoning model belongs there.
That is more useful to me than thinking only in terms of “small model versus big model.”
This Could Become Even More Important in Agentic AI
Agentic AI makes this distinction even more interesting.
Think about the questions an agent asks itself during execution:
Which tool should I use? Should I retry? Is this result relevant? Did the previous action succeed? Should I escalate? Is the request risky? Should I continue or stop?
Many of those questions have a bounded answer space.
They are runtime judgments, not necessarily open-ended generation problems.
Today, we often send every one of these decisions back through the same large reasoning model because that is convenient. But I am not convinced that mature agent architectures will continue doing that forever.
I can imagine a harness where different components do different jobs:
Code handles predictable control flow. A decision-oriented model handles repeated semantic judgments. Claude handles the difficult reasoning, planning, synthesis, and generation. Tools perform the actual actions. The harness manages how these pieces work together.
That looks less like “an LLM application” and more like mature software architecture.
Different components are optimized for different responsibilities.
The Real Question Is Not Jev vs. Claude
I would not design a system by asking, “Should I use Jev or Claude?”
I would start one level higher.
What kind of problem is this particular model call solving?
Can normal code solve it reliably? Then use code.
Are the possible outcomes already known, but selecting the right one requires understanding unstructured context? That is where a decision-oriented model such as Jev becomes interesting.
Does the problem require exploring possibilities, explaining something, writing, planning, synthesizing information, using tools dynamically, or generating something new? That is where a model such as Claude earns its place.
The first phase of Generative AI was about discovering everything large language models could do.
I think the next phase will be about learning when we do not need them to do everything.
As AI moves deeper into enterprise software, model intelligence will still matter. But architecture will matter just as much. We will care about latency, cost, uncertainty, reliability, observability, and how easily AI decisions compose with ordinary software.
The future may not be LLM everywhere.
It may be a combination of rules where rules are enough, judgment where choices are bounded, and reasoning where the problem is open.
Sometimes we really need the chef.
But sometimes the menu already exists.
We just need enough intelligence to choose the right meal.
Thanks
Sreeni Ramadorai
Top comments (1)
The Code/Jev/Claude taxonomy is the most useful framing here. Code for deterministic rules, a decision-oriented model for bounded semantic judgment, a general-purpose model for reasoning and generation. Treating these as distinct architectural components rather than just 'small model vs big model' is the right level of abstraction.
The type safety point is the sharpest observation: typed output is not the same as semantic correctness. Jev can still choose the wrong category. What the architecture gives you is a constrained output space and a decision that's easier for software to consume downstream — not a guarantee that the decision was right. That distinction gets lost in a lot of 'structured output' conversations.
The agentic use case is where this matters most. An agent's internal questions — which tool, should I retry, is this result relevant, should I escalate — often have bounded answer spaces. Routing those back through a full reasoning model on every step is convenient but not necessarily the right architecture at scale. A harness where code handles control flow, a decision model handles repeated semantic judgments, and the large model handles genuine reasoning problems is how mature agent infrastructure probably gets built.
At Black Label we think about this as the 'right tool for the call' question — every decision in an agentic loop has a cost and a latency profile, and the answer to 'should we use the big model here' shouldn't default to yes.