AI

I Tried TypeSafe's Jev. Maybe AI Doesn't Need to Talk So Much.

Jev wants to replace verbose AI responses with fast, typed, probabilistic decisions. I tested it, recorded the calls with AgenticLedger, and came away impressed by the concept, but with a few questions.

I Tried TypeSafe's Jev. Maybe AI Doesn't Need to Talk So Much.

Most of our AI applications are built around an odd assumption: if we want a model to make a decision, we first ask it to generate an answer.

Even when the decision is something as simple as approve, decline, or refer.

We send a prompt, the model generates tokens, and our software parses the response. Sometimes we even ask it to explain its reasoning, although all we really needed was a choice.

It's a bit like asking someone to write a paragraph every time you need a yes or no.

Then I came across TypeSafe AI's Jev.

The idea caught my attention immediately.

What if the model wasn't designed to have a conversation with us? What if it was designed to make decisions that software could consume directly?

I decided to try it and record the experiment using AgenticLedger, my open-source flight recorder for AI agents.

And I have to say, I like the direction TypeSafe is exploring.

Not because everything they're doing is entirely new. Some of it isn't. But because they're questioning an assumption we've largely accepted about how AI should fit into software.

Jev isn't trying to be another chatbot

Jev belongs to what TypeSafe calls System One Models, inspired by the fast, intuitive thinking described in Daniel Kahneman's Thinking, Fast and Slow.

The distinction is interesting.

Traditional LLMs are primarily designed to generate sequences of tokens. They're incredibly flexible. They can write, explain, summarize, reason, code, and have conversations.

Jev takes a different approach.

Give it some state, define the decisions you're interested in, and receive structured answers with probabilities.

Imagine a customer transaction that needs review.

Instead of asking an LLM to write an explanation and then extracting its decision, you might get something like:

approve: 0.85

decline: 0.06

refer: 0.09

That's much closer to what ordinary software needs.

Your application can decide what to do with those probabilities. Approve above a certain confidence threshold, send uncertain cases to a human, or apply additional business rules.

No need to extract a decision from a paragraph.

TypeSafe also describes a different model architecture, parallel sampling rather than conventional autoregressive text generation, and a training approach called Reinforcement Learning for Calibrated Decisions (RLCD).

That's where the proposition becomes more interesting than another structured-output API.

So what's actually novel here?

Let's separate the ideas that are genuinely interesting from those we've seen before.

Structured outputs aren't new.

We've had JSON mode, function calling, constrained decoding, classifiers, and schema validation for some time.

Asking a model to choose between predefined options isn't new either.

And neither are confidence scores. Traditional machine learning classifiers have returned class probabilities for decades.

Even building workflows around probabilistic decisions is familiar territory.

We've been doing that with fraud detection, recommendation engines, risk scoring, and other predictive systems.

So if Jev were simply an LLM wrapped in a JSON response with a confidence score, I wouldn't find it particularly revolutionary.

But that's not what TypeSafe claims to have built.

The more interesting part is moving structured decision-making into the model's fundamental design rather than treating it as a constrained version of text generation.

Jev is intended to produce typed decisions directly, with a model and sampling architecture optimized for that purpose.

And instead of merely adding a confidence field, TypeSafe says its training process explicitly optimizes for calibrated decisions.

That distinction matters.

A model saying it's 90% confident doesn't automatically make it trustworthy. If you collect 100 decisions made at 90% confidence, you'd ideally want roughly 90 to be correct.

That's calibration.

It's also something I'd want to verify independently before trusting those probabilities in an important application.

There's another claim worth examining: Jev's type-safe output guarantees.

That's useful. A system expecting one of three predefined choices shouldn't receive an invented fourth option.

But type safety isn't the same as factual correctness.

A perfectly valid approve decision can still be wrong.

Jev may eliminate entire categories of malformed output without eliminating errors in judgment.

That's a meaningful improvement, but we shouldn't confuse the two.

I put Jev through a small experiment

I ran Jev through a decision workflow and captured the calls using AgenticLedger.

The session in my recording used typesafe/jev-1.13.

Jev test session, AgenticLedger recording



50 captured calls | 159.3K recorded tokens | $0.0066 recorded cost

Yes, roughly two-thirds of a cent for the entire recorded session.

That immediately caught my attention.

The recorded session showed individual calls returning in roughly a tenth of a second. Two examples were 112 ms and 126 ms.

Of course, that's not a comprehensive benchmark. I wasn't comparing identical workloads across multiple providers, and my test doesn't establish relative model quality.

But as an initial hands-on experience, the latency and cost were encouraging.

The more interesting observation wasn't the speed.

It was what the model returned.

Same decision. Very different confidence.

Two consecutive calls in my recorded session produced these results:

Call #49

decision: approve (confidence 0.34)

approve 0.56 | decline 0.11 | refer 0.33

Call #50

decision: approve (confidence 0.77)

approve 0.85 | decline 0.06 | refer 0.09

Both returned approve.

But they weren't communicating the same degree of certainty.

In one case, the alternatives were much closer. In the other, approval was substantially more likely.

That is precisely the kind of distinction an automated workflow needs to consider.

A conventional application might see approve and simply move forward.

A probabilistic workflow could treat these cases differently, perhaps escalating the less certain decision.

The important point is that the business logic retains control.

The model supplies its judgment and uncertainty. The application decides what action is acceptable.

I should be careful about one detail: the recorded confidence values are separate from the displayed approval probabilities. Without examining their precise semantics and the original inputs, I wouldn't assume that the confidence value is simply the probability of the winning choice.

And these two outputs alone don't demonstrate calibration or correctness.

Still, they illustrate why I find this interface interesting.

A decision is useful. A decision accompanied by meaningful uncertainty could be much more useful.

The part I'm still skeptical about

TypeSafe reports impressive speed and cost improvements against conventional LLMs on its System One workflows.

Their published comparisons include claims approaching 194 times faster and 445 times cheaper.

Those are substantial numbers.

But benchmarks always deserve context.

TypeSafe's evaluations emphasize specific, structured decision-making workloads. The company also acknowledges limitations and methodological choices in its published results.

A specialized model should outperform a general-purpose model on some specialized tasks. That's part of the motivation for building one.

The question isn't whether Jev can answer certain questions faster than a frontier LLM.

It's whether those answers are sufficiently accurate, well-calibrated, and reliable for the decisions we actually need to automate.

And what happens when the state is incomplete, ambiguous, or misleading?

I'd also want to understand how calibration holds up across domains, how the model behaves under changing data distributions, and whether the cost advantage remains meaningful at the level of an entire workflow.

Those questions don't diminish the concept.

They're the questions that turn an impressive model demo into dependable software.

TypeSafe has already introduced experimental image, bounding-box, and longer-context capabilities in Jev 1.14, while explicitly warning that some of those features aren't yet at its production reliability bar.

I appreciate that distinction.

Maybe we need fewer chatbots and more intelligent functions

This experiment made me think about the way we're building agentic systems.

We're often trying to make LLMs do everything.

Understand the user. Plan the work. Retrieve information. Call tools. Evaluate results. Make decisions. Explain those decisions. Decide what happens next.

That's a lot of responsibility for one model interface.

But perhaps the better architecture is a combination of different kinds of intelligence.

Use generative models when we need language, exploration, synthesis, or open-ended reasoning.

Use specialized decision models where the problem can be expressed as structured state and a defined set of choices.

And use ordinary deterministic code wherever business rules and correctness constraints are explicit.

That strikes me as a more practical direction than turning every workflow into a conversation between AI agents.

We don't need a beautifully written paragraph to decide whether an invoice requires human approval.

We need the right decision, an honest representation of uncertainty, and an application that knows what to do next.

Jev is an interesting attempt to make that division of labor possible.

Whether it becomes a major category of AI infrastructure remains to be seen.

But I like the question TypeSafe is asking.

One more thing: I wanted to see exactly what happened

There's a second story behind this experiment.

While I was testing Jev, I was recording the calls through my own open-source project, AgenticLedger.

It's a local-first flight recorder for AI agents.

The idea is simple: if we're going to build software that lets AI make decisions and invoke tools, we should be able to see what happened.

Not just the final answer.

The individual calls, prompts, responses, timing, token usage, and cost.

During this test, AgenticLedger captured 50 calls in one session, showing 159.3K recorded tokens and a total recorded cost of $0.0066.

I could inspect individual responses, examine their sequence, and see how much each call cost.

The dashboard also provides session views, traces, flows, and replay capabilities for investigating agent behavior.

I originally built AgenticLedger around a simple belief:

The more autonomy we give software, the less comfortable we should be with black boxes.

Jev makes that idea even more relevant.

A system making decisions in milliseconds is impressive.

But speed and low cost also make it easier to embed thousands of decisions deep inside ordinary software, where nobody may notice a problem until much later.

That's why I think observability, replayability, and accountability matter alongside model intelligence.

Jev is exploring how to make AI decisions more suitable for software.

AgenticLedger is my attempt to make AI execution easier to understand and inspect.

Different problems, but ones that fit together naturally.

You can explore AgenticLedger at agentic-ledger.dev.

Where I land

I enjoyed experimenting with Jev.

I like that TypeSafe isn't simply trying to build another model that writes better answers. They're exploring what happens when we stop treating human-readable language as the default interface for machine intelligence.

Some of the ideas are familiar. Classification, probabilities, structured decisions, and workflow rules are hardly new inventions.

The novel proposition is bringing them together in a model designed specifically for that job.

Whether Jev delivers on its broader claims will require more testing than my small experiment.

But here's the thought I'm left with:

We spent years teaching machines to speak like humans. Perhaps the next useful breakthrough is teaching them when not to speak at all.

And when those machines start making decisions on our behalf, we should make sure we're recording what happened.

Not because we expect every decision to be wrong.

Because eventually, someone is going to ask why one was made.