Running AI workflows in production just got cheaper with Jev

After two years of development in stealth, TypeSafe has released Jev, its first public model. With a novel architecture focused on cost-efficient, low-latency decision-making, Jev shows promise as a complement to LLMs in existing AI workflows.¹

How Jev came to be#

Diogo Almeida, TypeSafe's founder, co-authored the 2022 InstructGPT paper during his tenure at OpenAI. The paper helped establish reinforcement learning from human feedback (RLHF) as a way to make language models better at following instructions and producing responses that humans prefer.

During my time at Porter, we explored an AI use case during an internal hackathon: generating structured JSON that our backend could use to process orders. Using an LLM was overkill: we didn't need paragraphs, only a structured response containing decisions such as the order type and pickup and drop-off locations. We also had to ensure that every response was valid JSON before it reached the backend. The workflow was slow and expensive because we were paying for and waiting on text generation, formatting and validation.

TypeSafe's hypothesis is that AI-to-software interactions need a different interface from AI-to-human interactions. A model designed specifically for decisions could be faster, cheaper and easier to integrate. After two years of stealth development, the company has announced three innovations:

• A new architecture.
• A parallel sampler.
• Reinforcement Learning for Calibrated Decisions (RLCD).

Fun fact: the name Jev comes from the economist William Stanley Jevons, who formulated what became known as the Jevons paradox:

TypeSafe is banking on the idea that making machine intelligence 100× cheaper won't merely reduce bills, it could make millions of previously uneconomical background decisions viable.

A layman's guide to how it works#

For the rest of the blog, I'm going to use the example of how a customer-support ticket would work.

The LLM approach#

The customer's chatbot input:

“I was charged twice and need my money back.”

You ask an LLM to return:

{
  "department": "billing",
  "refundRequested": true,
  "urgency": 0.7
}

The LLM first tokenises the input and then generates the response sequentially, one output token at a time. Even when the required output is small and structured, the model still performs autoregressive text generation.

The Jev approach#

First, you need to understand the primitives:

With Jev, you provide:

• State: the customer message, order and refund policy.
• Questions: whether a refund was requested, which department owns it and how urgent it is.
• Allowed answers: the predefined choices or scoring scale.

Jev returns typed answers and probability distributions directly.²

Jev behaves less like a colleague writing an answer and more like a function evaluating several fuzzy conditions.

Once Jev returns its structured result, your code owns the action to take:

if (refundRequested > 0.9 && policySupportsRefund > 0.9) {
  approveRefund();
} else {
  sendForReview();
}

The model provides judgements, while deterministic code combines them into business behaviour.

Why Jev is faster and cheaper#

According to TypeSafe, at the time of writing:³

Now, how did they pull this off?

1. It doesn't generate explanations, paragraphs or arbitrary JSON one token at a time.
2. It selects among predefined outcomes instead of generating an open-ended sequence.
3. It evaluates multiple independent questions in parallel rather than producing their answers sequentially.
4. It is optimised for focused judgement calls rather than conversation, research or extended reasoning. In short, it avoids work that decision-making use cases do not need.

What it doesn't replace and its limitations#

Jev replaces some LLM calls, not the LLM itself.

It won't replace:

• Chatbots
• Code generation
• Research
• Multi-step reasoning

Its current limitations include:²³

• Text only: its model doesn't support images, audio or video currently.
• Predetermined output space: developers must define the possible outcomes.
• Atomic-question requirement: complicated judgements must be decomposed into smaller questions.
• Workflow engineering remains necessary: developers must define thresholds, fallbacks and escalation paths.
• Early product: production adoption and long-term reliability remain unproven.

Where I see Jev fitting into AI workflows#

The same ticket, two routers#

Both pipelines below receive the same tickets, offer the same routes and call the same downstream responder. Only the router changes, so the comparison isolates routing cost and latency. The numbers are assumptions you can edit, not measurements.