TypeSafe's Jev: faster, cheaper typed decisions than traditional LLM calls

Watch the full video about Jev

The hidden problem with LLM calls

We often use a large language model to make a simple decision: select an option, assign a score, classify content, or check a condition.

The workflow usually looks like this:

1. Build a prompt.
2. Send the context to the model.
3. Ask for a JSON response.
4. Parse the result.
5. Validate the schema.
6. Retry when the output is invalid.

It works, but it can be a huge machine for a small problem.

If you only need to select one villa from five results that have already been filtered, you do not necessarily need the model to write three paragraphs before returning an ID. If you need to assess fourteen editorial criteria, you also do not want to manage fourteen independent calls and fourteen potentially different response formats.

This is exactly where Jev positions itself.

What exactly is Jev?

Jev is created by TypeSafe. People associated with the project include Diogo Almeida, a former OpenAI researcher and co-author of the InstructGPT paper.

The core idea is straightforward:

• you provide a state as text or JSON;
• you ask one or more typed questions;
• Jev returns values that comply with the requested schema;
• the answers include probabilities.

The presented question types include Choice, Noul, and Score.

Jev is not positioned as another chatbot. It targets the points where an application needs to transform context into bounded judgments that code can consume directly.

A simplified representation

Here is the conceptual shape of a request. This JSON illustrates the mental model, not the exact signature of an SDK:

{
  "state": {
    "request": "A quiet villa for six people, close to the beach",
    "availableVillas": [
      { "id": "villa-12", "capacity": 6, "distanceToBeachKm": 0.4 },
      { "id": "villa-27", "capacity": 8, "distanceToBeachKm": 1.1 }
    ]
  },
  "questions": [
    {
      "id": "bestVilla",
      "type": "Choice",
      "options": ["villa-12", "villa-27"]
    },
    {
      "id": "requestFit",
      "type": "Score",
      "min": 0,
      "max": 10
    }
  ]
}

The response can then be consumed as application data:

{
  "bestVilla": {
    "value": "villa-12",
    "probabilities": {
      "villa-12": 0.84,
      "villa-27": 0.16
    }
  },
  "requestFit": {
    "value": 9,
    "probabilities": {
      "8": 0.18,
      "9": 0.67,
      "10": 0.15
    }
  }
}

The value is not the only useful part. Probabilities also let you implement control rules. If the first two options are almost tied, the application can request human validation instead of presenting the result as certain.

What Jev changes in an AI architecture

The right question is not, “Does Jev replace LLMs?”

The right question is, “Which part of this workflow truly needs open-ended generation?”

This separation matters.

Code should retain exact facts such as prices, availability, capacity, permissions, and contractual limits. Jev handles bounded judgments such as best option, fit, category, or score. The LLM remains useful when the system must produce language. A human takes over when an error could have significant consequences.

Three concrete use cases from Mike

VillaSlot: choosing among filtered villas

In VillaSlot, code first applies objective constraints. It can remove villas that are unavailable, too small, or over budget.

Jev does not replace this logic. It receives the already filtered list and chooses among the remaining options based on the traveler's request.

The distinction is essential:

• code establishes the valid candidates;
• Jev assesses their fit;
• the application uses the result or requests confirmation.

This avoids delegating a verification that code can perform exactly to a probabilistic system.

YouThumb: deciding after visual analysis

For YouThumb, an initial step analyzes the image. The output of that analysis becomes the state passed to the decision engine.

Jev can then answer bounded questions: which variant best matches the objective, what readability level is observed, or which option should be selected.

Vision extracts the context. Jev structures the judgment. Code orchestrates the workflow.

AgentsMail: fourteen questions in one call

In AgentsMail, Jev performs an editorial analysis using fourteen questions grouped into a single call.

The goal is not to predict Gmail's behavior. It is to assess the content against a defined framework: clarity, subject-line strength, consistency, CTA quality, and other editorial criteria.

Grouping the questions produces one structured output for the entire framework without building a chain of fourteen independent calls.

The performance claims

On its own workflows, TypeSafe reports performance of up to:

• 193.6 times faster;
• 444.6 times cheaper.

Those numbers are impressive, but they need the correct framing. They are vendor figures measured on TypeSafe's workflows, not independent benchmarks covering every model, workload, and use case.

Your actual gains will depend on factors such as:

• the model you currently use;
• the size of the state;
• the number of questions;
• call frequency;
• how much generative work you actually remove from the workflow.

The right approach is to test Jev on one precise task with your own traffic, then compare latency, cost, and operational quality.

The guarantee you should not misunderstand

Jev guarantees schema compliance. It does not guarantee that every answer is semantically correct.

That difference changes everything.

A value can be technically valid while still being wrong in substance. A selected option can belong to the authorized list and still be a poor choice. A score can fall inside the requested range without accurately reflecting the situation.

Probabilities are not proof of truth either. They help you measure and use the system's uncertainty.

A solid implementation therefore needs:

1. clean and sufficiently explicit states;
2. well-defined options;
3. confidence thresholds;
4. test sets that resemble production traffic;
5. human validation for sensitive decisions.

When Jev makes sense

Jev is especially relevant when the possible output is known in advance:

• selecting an option from a list;
• rating an item on a bounded scale;
• applying an evaluation framework;
• routing a request to a category;
• comparing candidates already validated by code;
• grouping multiple structured judgments into one call.

If you want to write an article, explain a concept, or run an open-ended conversation, a generative LLM remains a better fit.

A simple integration method

Start small:

1. Identify an LLM call whose output is already highly constrained.
2. Remove unnecessary data from the state.
3. Move exact rules into deterministic code.
4. Define the questions and their types.
5. Log values, probabilities, latency, and cost.
6. Compare results on real cases.
7. Add human validation when confidence is insufficient.

Do not migrate your entire architecture because of a marketing claim. Pick one workflow, measure it, and expand only if the result holds up in production.

Conclusion

Jev offers an interesting answer to a common problem: we sometimes use general-purpose LLMs to produce tiny, highly constrained decisions that are expensive to generate and parse.

Its role is clear. Code keeps the facts. Jev produces bounded judgments. The LLM generates content. Humans retain control of sensitive decisions.

The speed and cost claims deserve a serious test, without confusing TypeSafe's figures with independent benchmarks. Schema compliance should never be confused with truth either.

Watch the complete Jev demonstration

For weekly, practical analysis of AI, agents, and software development, join The Agentic Developer.