# Jev: A Different Approach to AI Decision-Making > Source: > Published: 2026-09-24 17:14:22+00:00 For the last few years, much of the AI ecosystem has focused on making language models better at **generating and understanding language**. We built increasingly capable autoregressive models that generate text token by token. We added reasoning capabilities, tool calling, structured outputs, and increasingly large context windows. That approach is extremely powerful. But there is a problem when we use these models inside backend systems: **Sometimes the application doesn't need an answer in natural language. It just needs a decision.** For example: In these situations, generating a paragraph of reasoning and then parsing it into a boolean, score, or enum can be unnecessary overhead. This is the problem **TypeSafe AI's Jev** is designed to address. **Jev is a System One model designed to make fast, structured decisions that software can consume directly.** TypeSafe describes Jev as a model that gives up general-purpose string generation in exchange for structured outputs, parallel sampling, and calibrated probabilities. Jev is TypeSafe AI's first public **System One Model**. The name is inspired by the distinction between **System 1** and **System 2** thinking from Daniel Kahneman's *Thinking, Fast and Slow*. The basic idea is simple: **LLMs generate strings. Jev generates decisions.** Instead of asking a model: ``` "Read this support ticket and tell me what department should handle it, whether it is urgent, and how frustrated the customer appears to be." ``` and expecting a generated JSON response, you define the decisions your application needs. Conceptually: ``` Application State │ ▼ ┌─────────────────────────┐ │ Jev │ │ │ │ Evaluate typed │ │ questions in parallel │ └────────────┬────────────┘ │ ▼ Structured Decisions ┌──────────────────────┐ │ Choice │ │ Score │ │ Yes / No │ │ Probabilities │ │ Confidence │ └──────────────────────┘ │ ▼ Application Logic ``` The important architectural difference is that Jev is optimized around **structured decisions rather than arbitrary text generation**. TypeSafe describes its architecture as using a new model architecture, a parallel sampler, and a training approach called **Reinforcement Learning for Calibrated Decisions (RLCD)**. One of the most interesting concepts in Jev is its API model: **State + Questions → Typed Decisions** The **state** is the information the model needs to evaluate. It could contain: You then define the decisions your application wants the model to make. TypeSafe currently exposes three core primitives: `Noul` A yes/no question. ``` Does this request appear urgent? ``` The result includes a probability for the statement. `Choice` Select one option from a predefined set. ``` Which department should handle this ticket? billing technical_support sales general ``` The model returns a distribution across the available choices. `Score` Evaluate something on a defined scale. ``` How frustrated is the customer? calm slightly_annoyed highly_frustrated ``` The result includes a score and probabilities across the levels. These primitives are also used in TypeSafe's published workflow evaluations. Consider a traditional LLM workflow. You might ask: ``` Classify this ticket and return JSON. { "department": "...", "urgent": true, "priority": "..." } ``` Your application then has to deal with: With a typed decision model, the possible output space is defined ahead of time. ``` department ∈ { billing, technical_support, sales, general } ``` The model isn't being asked to invent the structure. The structure is part of the application. This creates a useful separation: ``` AI → semantic judgment Code → policy + business logic + side effects ``` That distinction is important. **Type safety does not mean semantic correctness.** Jev can still make the wrong classification. What the typed interface gives you is a constrained output space that is easier for software to consume and reason about. TypeSafe explicitly frames this as making AI more like a dependable software primitive, with confidence and probabilities available to the application. Traditional autoregressive language models generate output sequentially. ``` Token 1 → Token 2 → Token 3 → Token 4 → ... ``` For a task that ultimately needs: ``` "technical_support" ``` or: ``` true ``` generating a long textual response can be unnecessary. Jev takes a different approach, using parallel sampling for its structured outputs. TypeSafe reports end-to-end response times of approximately **70–500 ms** for Jev. Its current website also highlights a workflow comparison showing **193.6× faster** and **444.6× cheaper** for the particular System One workflows used in that comparison. These are TypeSafe's own benchmark results, not a universal guarantee for every workload. That's an important distinction. The useful takeaway isn't: "Jev is always 200× faster than every LLM." It is: **For the kinds of structured decision workloads Jev targets, avoiding autoregressive text generation can dramatically reduce latency and cost.** TypeSafe currently lists Jev at: **$0.042 per million input tokens** and states that output tokens are free because Jev does not generate traditional output text. This creates an interesting economics model for backend systems. Imagine an application processing millions of events: ``` Event ↓ Should we process it? ↓ Which workflow? ↓ What priority? ↓ Should a human review it? ``` If each decision requires a full generative LLM call, the cost and latency can quickly become significant. A specialized decision model can potentially sit in front of or alongside the larger model. I think about the difference like this: ``` Traditional LLM Input ↓ Reason ↓ Generate tokens ↓ Generate JSON/text ↓ Parse ↓ Validate ↓ Application logic ``` Versus: ``` Jev Input State ↓ Typed Questions ↓ Decision + Probability + Confidence ↓ Application logic ``` The second model is particularly interesting when the application already knows **what decisions it needs to make**. One interesting use case is deciding **which LLM should handle a request**. ``` Incoming prompt │ ▼ Jev │ ┌───┴────┐ │ │ Simple Complex │ │ ▼ ▼ Small LLM Frontier LLM ``` Instead of sending every request to an expensive model, a decision layer could evaluate the request and select an appropriate model. This is especially interesting in systems where model cost and latency matter. Consider a support platform receiving thousands of tickets. The application might need to determine: ``` Department? Urgency? Customer sentiment? Human escalation required? ``` Those decisions can be represented as typed questions. The surrounding application can then implement deterministic business rules: ``` if urgency_probability > 0.9: escalate_to_human() elif department == "billing": route_to_billing() else: continue_normal_flow() ``` The model provides the semantic judgment. The application retains control of the actual workflow. Another interesting area is using a fast decision model as a gate around an LLM or agent. ``` Agent │ ▼ Tool request │ ▼ Jev │ ├── Safe → Execute │ └── Risky → Human review ``` This pattern could be useful for decisions such as: The important architectural idea is that the decision model doesn't need to replace the agent. It can act as a **fast decision layer around the agent**. Low latency also opens possibilities for high-throughput classification. Examples include: The TypeSafe workflow examples currently include security incidents, agent trace observability, invoice processing, and customer service, which gives a good indication of the kinds of automation problems the company is targeting. This is probably the most important point. **Jev is not a replacement for an LLM.** If you need: you still need a generative model. Jev targets a different part of the architecture. A useful way to think about it is: ``` AI Application │ ┌────────────┴────────────┐ │ │ ▼ ▼ Generative LLM Jev │ │ Generate text Make decisions Write code Classify Explain Score Reason Route Verify Gate ``` In other words: **LLMs can generate the content. Decision models can determine what should happen next.** That distinction could become increasingly important as AI moves deeper into backend automation. | | Generative LLM | Jev / System One | |---|---|---| | Primary purpose | Generate language | Make structured decisions | | Output | Text / structured text | Typed decisions | | Sampling | Autoregressive | Parallel | | Best suited for | Chat, code, reasoning, generation | Classification, routing, scoring, verification | | Uncertainty | Often requires explicit prompting | Probabilities and confidence are part of the output | | Application integration | Parse and validate generated output | Consume typed decisions directly | | Latency target | Seconds for many frontier workflows | ~70–500 ms according to TypeSafe | The two approaches are complementary rather than mutually exclusive. For me, the most interesting part of Jev isn't simply the latency number. It's the **interface**. We've traditionally treated AI as something that produces text: ``` Prompt → Text ``` Jev proposes a different abstraction: ``` State + Questions → Decisions ``` That is much closer to how backend systems are already designed. Software is full of decisions: ``` if condition: do A else: do B ``` The problem is that some conditions are difficult to express with deterministic rules. ``` if customer_is_genuinely_frustrated: escalate() ``` The difficulty isn't the `if` statement. It's determining: **Is the customer genuinely frustrated?** That's where an AI decision model can potentially fit. The application owns the workflow. AI supplies the judgment. Jev represents an interesting direction in AI engineering: **not every AI problem needs a chatbot or a text-generating model.** Some problems are fundamentally about making small, repeated decisions inside software. For those workloads, a model that produces: ``` Choice Score Probability Confidence ``` may be a better abstraction than a model that generates paragraphs of text. Jev is still relatively new and currently available in early access, so there is plenty to learn about where this approach works well, where it doesn't, and how it behaves in production workloads. TypeSafe itself is actively asking developers to experiment with the model and report where it succeeds or falls short. But the underlying idea is worth watching: **What if the next evolution of AI isn't just better models that talk to humans, but models that make fast, structured decisions for software?** That is the interesting question Jev is exploring.