# Jev by TypeSafe: Machine-Native Decisions

> Published 2026-10-13T19:40:11.500Z on https://youblog.app/p/jev-by-typesafe-machine-native-decisions/
> Source video: https://www.youtube.com/watch?v=9Aato-NfjoU

Jev by TypeSafe is a calibration-first model for software decisions, built to output probabilities a program can act on. The claim rests on RLCD, a training objective for calibrated decisions, and the acknowledged limit is that this first release is closer to an early ChatGPT than a finished dependency.

## What Jev by TypeSafe Actually Is

Jev by TypeSafe is a model built to output calibrated decisions and probabilities rather than text, packaged with an API a developer calls from code. Diogo Almeida, co-founder and CEO of TypeSafe, described it on The TWIML AI Podcast in October 2026 as the company's first public release and an early research preview, not a finished dependency.

The interface is deliberately small. A caller supplies the possible decisions and the input, and the model returns a choice plus probabilities over the options. Almeida framed the probabilities as the real product: a business can attach its own cost to a wrong refund or a wrong escalation, where a chat model offers only a single confident pick.

TypeSafe positions Jev next to language models rather than inside them. Almeida said Jev is lower level than an LLM, does not model language, and is meant to be embedded in code the user owns. That design keeps business logic and thresholds on the developer's side of the API.

The name the field uses for this class is unsettled. Almeida accepts “decision models” as a public label but said TypeSafe avoided it internally because more than decisions fits the category. He declined to describe that additional use case, calling it a roadmap item.

The underlying intelligence is not trained from scratch. Almeida confirmed Jev is built on multiple open-weight models, chosen for different trade-offs, then rebuilt and retrained. TypeSafe did not pre-train a foundation model, and Almeida said the budget would not have supported competing with labs that do.

## RLCD and the Difference From Classifiers and Embeddings

RLCD, short for reinforcement learning from calibrated decisions, is the training objective TypeSafe uses to make Jev's probabilities trustworthy. Almeida described it as a class of algorithms that optimize for calibrated decisions, in contrast to RLHF, which he said optimizes human preference and trains models to write text people like.

Almeida argued that classifiers are the shape of usefulness in software, not an ML novelty, and that Meta and Google run on classifiers and regressors. His complaint is narrower: a logistic regression on top of embeddings inherits the intelligence of logistic regression and embeddings, and a small model inherits the intelligence of that small model.

That distinction is where TypeSafe claims its edge. Speed and cost follow from the shape of the model, and Almeida called both “bad things” in the sense that ideal latency is instant and ideal cost is zero. The claim TypeSafe is making is about calibration and reliability, which he said developers pay for and current models lose.

Almeida's criticism of RLHF and RLVR is that producing fluent text requires a mode-dropping loss, which he said destroys calibration. He cited the ChatGPT paper and early Anthropic calibration measurements as evidence that post-trained models ship with warped probabilities, while pre-trained models were better calibrated.

The customer-service over-refusal episode at OpenAI is his example of what missing calibration looks like in practice. A model that sometimes refuses and sometimes does not, with no threshold for a developer to tune, produces behavior Almeida called insane from an engineering standpoint, because the decision is blended into the text and cannot be adjusted.

## How Calibration Changes What Developers Can Build

Calibration turns a model's output into a number a program can act on, which is what separates a decision primitive from a chat response. Almeida said the internal and external Jev APIs are essentially the same, and that the company exposes the probabilities rather than a fixed threshold because it does not know a user's application costs.

His analogy is logit access. Giving developers probabilities is like OpenAI exposing logits so software can choose its own sampling algorithm instead of accepting a globally chosen behavior. The default behavior of a first-party product and the right behavior for a specific business are rarely the same thing.

The practical controls matter in workflows with money attached. A refund policy, an escalation rule, and a worth-this-customer calculation all imply different thresholds, and Almeida said developers today have no native way to express them except through system-message text that the model may ignore.

Almeida compared this to function calling with a logit bias for the function itself, and said no function-calling API should ship without that knob. He wants builders to get deterministic control over downstream behavior without praying to a prompt.

Almeida noted that most users never touch the probabilities, and predicted that hardcore engineering use will lean on them every time. A system that must decide whether to act, escalate, or wait can price each outcome only if the model provides a distribution rather than a verdict.

## The Evidence Behind Jev: Benchmarks, Claims, and Ownership

TypeSafe's performance claims for Jev come from TypeSafe, and the podcast offered no independent reproduction. Almeida said the models are more calibrated than RLHF models “as far as we can measure” but are not perfectly calibrated, and he predicted Jev would outperform early Anthropic calibration measurements without presenting a public comparison table.

The comparison he did make was qualitative and directional. Almeida guessed that RLHF models are very bad at decision-making and that TypeSafe's early models would be less capable than the largest RLVR reasoning models but better than non-reasoning RLHF models. He tied that estimate to where each training objective sits on a generality curve.

No published number, sample, or task set backs those statements in the interview. Anyone citing Jev's accuracy should treat the figures as vendor-reported until TypeSafe publishes an evaluation, and should not attach the company's calibration claims to unrelated benchmarks.

Almeida was explicit that Jev 1.13 is early. TypeSafe spent about two years in stealth before the release, and he compared the current model to an early ChatGPT. He invited developers to report dumb behavior, and said reliability work will continue for years, with each added nine unlocking more use cases.

The company's own framing matters for adoption decisions. Jev is positioned as a complement to an application's logic, not as a drop-in replacement for a chat model, and TypeSafe said a non-coder cannot use it productively because the probabilities only mean something once code consumes them.

## Agents, Harnesses, and What Changes When the Model Is Not an LLM

Almeida rejects the harness framing for Jev and says the user's own code is the harness. His distinction is that language models are used to write code, while Jev is meant to increase the power of code the developer already owns, which keeps business logic on the developer's side.

He made the same argument about agents. He attributes the jump in coding agents to a model and data change rather than a harness innovation, arguing that a powerful interface only works as well as the intelligence behind it, and that users abandon agents when reliability drops.

Tool calls are his clearest example of a wasted opportunity. Almeida said tool calls consume large amounts of context, are not always needed, and are called less often than native tools because models are overfit to their own harnesses. Logit biases on function selection are the control he wants, and he noted current APIs do not offer it.

The KV cache is his broader target in a blog post he titled around its cost. Almeida argued the append-only cache forces routing, subagents, and reordering to be inefficient, and asked how a coding agent would be designed if that constraint did not exist. He described hierarchical lookups inside context as one possibility.

This is an argument about architecture, not a shipping feature. Jev does not currently expose the agent controls Almeida describes, and he said hybrid systems are the likely path, with software taking over more of an agent loop over time as reliability improves.

## Where Jev Fits Beside Machine-Native Intelligence and Existing Autonomy

Machine-native intelligence, TypeSafe's term for models optimized for automation, is the thesis behind Jev rather than a product feature. Almeida said he has pitched the same idea for years, and that Jev is the first implementation of it rather than the final shape of the company's model line.

He contrasted it with end-to-end autonomy. Almeida cited Waymo's self-driving stack as a large engineering win built from decomposed, well-understood components, and argued that one model ruling an entire system is hard to debug when a part breaks. Zooming in on a component raises reliability, in his framing.

His criticism of current AI demos is that they fall back to human-in-the-loop work rather than automating the task. Almeida said that pivot is rational given how unreliable the models are, but that it does not produce a dependency a developer can call forever. He dated customer-service demos to around 2020 and noted the problem is still open in 2026.

This is where Jev's commercial pitch lives. Almeida said reliability, not intelligence alone, is what buyers want, and compared his goal to SQL: a primitive developers use without re-running an evaluation every time they write a query.

The comparison table below separates the entities in this conversation. It reflects what TypeSafe and the interview claim, not an independent evaluation of Jev.

## Jev, RLHF, and RLVR Compared

The table compares the three training objectives as Almeida described them. It is a summary of the interview's claims about optimization targets, not a measurement of model quality.

| Approach | What it optimizes | Typical output | Main limitation Almeida cites |
| --- | --- | --- | --- |
| RLHF | Human preference | Fluent text | Calibration degrades; decisions blend into strings |
| RLVR | Verifiable rewards | Reasoning traces | Benchmark-shaped gains; policies reward native tools |
| RLCD | Calibrated decisions | Probabilities over options | Early research preview; less capable than top reasoning models |

## What Jev's First Release Still Does Not Solve

Jev's early state is the first caveat, and TypeSafe states it plainly. The version discussed in October 2026 is an initial public release with no published evaluation, and its capabilities are estimated by its own co-founder rather than established by an independent study.

Counting is a concrete example Almeida gave. He said the model cannot count the letters in “strawberry,” and argued that limitation does not match most real work, which takes the shape of semantic judgments. That claim is his, and it should not be generalized into a statement about all calibration-first models.

Generalization remains the open question. Almeida said RLHF was the easiest objective to make general, RLCD is harder, and RLVR is harder still, which means a developer must judge whether a specific workflow falls inside what Jev has seen. No public tool from TypeSafe measures that yet.

The roadmap items Almeida mentioned are not shipped capabilities. He referred to earlier models that do not carry the reliability bar, a possible future publication on RLCD, and an ecosystem of higher-level abstractions for decision models. None of those should be described as available today.

Almeida's prediction about where the field lands is also a prediction. He said hybrids will add more logic over time as software replaces parts of an agent loop, and that the most valuable AI software will end up on rails. It is a thesis, stated as one.

## FAQ

- **What is Jev by TypeSafe?** Jev is a model from TypeSafe, released in October 2026, that returns a chosen decision plus probabilities over the options a caller supplies. It is built on open-weight models and retrained rather than pre-trained from scratch, and TypeSafe calls it an early research preview.

- **Is Jev just a classifier?** TypeSafe's co-founder rejects that description because the classifier question misses what the model optimizes for. Jev is trained for calibrated decisions, so the probabilities carry usable information, while a logistic regression on embeddings inherits only the intelligence of that stack.

- **What does RLCD mean?** RLCD stands for reinforcement learning from calibrated decisions, the training objective TypeSafe uses in place of RLHF. It optimizes the accuracy of output probabilities rather than the human preference for text, which Almeida said is what software needs to set thresholds.

- **How does Jev differ from RLHF models?** Almeida said RLHF is easy to make general but destroys calibration because fluent text requires overconfidence and a mode-dropping loss. Jev targets calibrated probabilities instead, at the cost of being much worse at generating strings.

- **Can Jev run as a standalone dependency?** TypeSafe says it requires code, because probabilities only matter when an application consumes them. Almeida argued that language models are poor standalone dependencies because their abstractions leak and they can fail arbitrarily, and Jev is meant to be embedded rather than run unattended.

- **Who makes Jev?** TypeSafe, an AI company founded by Diogo Almeida and co-founders, develops Jev. Almeida previously spent about four and a half years at OpenAI, where he worked on instruction following and the RLHF research behind ChatGPT.

- **Does Jev replace agent harnesses?** No. Almeida said he rejects the harness framing and expects users to write the surrounding logic themselves, with higher-level abstractions arriving later. Agent-related controls such as logit biases on tool calls are roadmap ideas, not shipped features.

- **Is Jev suitable for regulated workflows?** TypeSafe has not published the evidence needed to answer that question. Calibrated probabilities can support thresholds and review policies, but they do not by themselves prove accuracy, compliance, or fitness for healthcare, finance, or any regulated deployment.

- **How current is the information here?** This article reflects the October 2026 interview with TypeSafe's co-founder and the state of Jev at that first release. Anything about later versions, pricing, or published evaluations belongs to a newer primary source.

## From a 90-Minute Interview to a Written Article

The interview behind this piece runs about 90 minutes, and most of its value sits in the reasoning: why calibration beats fluency for software work, why reliability is the product, and where the first release falls short. That kind of nuance rarely survives as a video description.

If you have similar material sitting in a recorded interview, a talk, or a walkthrough on your channel, [Skala Blog](https://skalablog.com) turns it into a written article you can edit and publish. Paste a YouTube URL, let the transcript do the work, then keep the passages that carry the argument. For Brazilian developers who follow this kind of tooling closely, [CrazyStack](https://crazystack.com.br) is another place where these discussions show up, alongside commentary from Dev Doido do canal do youtube.

[Source video](https://www.youtube.com/watch?v=9Aato-NfjoU)