Jev: System One models for Prod, not God — with Diogo Almeida, CEO, TypeSafe AI
· Summarized
Key takeaways
- Jev is TypeSafe AI’s first “system one” or large programmable model, designed for code to consume directly rather than for human-facing chat.
- Diogo defines Jev’s primary optimization target as intelligence per dollar, while treating reliability—including consistent task performance—as more important than raw speed or public benchmark scores.
- TypeSafe rejects default safety refusals in a general-purpose API because unpredictable refusals can break software dependencies; Diogo believes product-level safety policies and developer-level responsibility belong above the core intelligence layer.
- Diogo argues that RLHF can cause mode-dropping and distorted calibration, making string-based language models overly conservative and poorly suited to decision-making.
- TypeSafe considers itself a data and task-design lab: its data team studies model failures and repairs them surgically for generality instead of simply collecting more user queries or gaming public benchmarks.
- Developers should decompose complex AI behavior into many explicit, structured, testable questions, using choices, scores, probabilities, and thresholds rather than relying on one giant system prompt.
- Diogo expects Jev to power dark-data analysis, coding agents, real-time applications, verification, computer use, and other composable software that can run continuously in the background.
- The launch convinced Diogo that the field can move toward an AI-driven economic revolution, but he says the difficult work is only beginning: future systems must turn intelligence into reliable, broadly useful infrastructure.
Summary
Jev’s launch leaves Diogo exhausted—but convinced AI’s direction has changed
The host opens by congratulating Diogo Almeida on launching Jev, saying it has taken over the timeline, and asks how he feels. Diogo answers, “Never been worse,” describing himself as a “ragged corpse” because he is acting as a technical CEO and fighting constant fires. Emotionally, however, he feels unusually aligned with reality: the AI field has seemed like a “carnival house of mirrors,” but this week people appear to understand that AI can be more than chatbots and that an AI-based economic revolution is back on the table. He emphasizes his gratitude to developers and explains why he prioritized a town hall for them over meetings with VIP investors. He says it felt wrong for the community not to receive his attention during the company’s most important moment. The host notes that TypeSafe’s Discord has reached 100,000 people and that Diogo’s Twitter presence has exploded since the launch. Diogo says the visibility was not a carefully engineered marketing campaign: the team was simply being genuine, goofy, and irreverent, while his platform team worked intensely to keep the service running.
Jev is a machine-native, programmable model optimized for intelligence per dollar
Asked to explain Jev, Diogo says TypeSafe is creating a new class of models whose most accurate current description is “system one models,” although the company has more terminology and research in reserve. He distinguishes them from pretrained language models designed to autocomplete the internet, RLHF models designed to respond to text and follow instructions, and RLVR systems that occupy a related but different space. Jev is designed for code to consume directly, which is why TypeSafe calls the interface type-safe. The model’s central optimization target is intelligence per dollar. Diogo says other systems might optimize for reliability, cost, calibration, or speed, but Jev is intended to sit on the frontier of intelligence per dollar, with the name itself referring to that goal. The broader objective is to integrate AI with software rather than treat AI as a coworker in a chat window. He describes Jev as a general cognitive core that can sit deep inside future software, including use cases the company did not train on directly. The host connects this to calibration: models should express their internal confidence rather than merely produce the answer most likely to satisfy a user.
Why Diogo says RLHF causes mode-dropping and makes language models bad decision-makers
Diogo argues that one neglected downside of RLHF is “mode-dropping,” borrowing an analogy from generative models: instead of covering the full distribution, a system drops minority modes and concentrates on common outputs. He connects this to Yann LeCun’s argument that language models become increasingly likely to make errors as sequences grow. Diogo says that argument appears mathematically obvious but does not describe empirical behavior because a calibrated, mode-covering model can produce occasional outliers, whereas a mode-dropping model becomes extremely conservative to avoid visibly wrong sequences. In his account, calibration is poisonous for long-form string generation when the model is being used for decisions. Subtle correctness is hard to observe, while an obvious error is heavily punished, so the probability distribution becomes distorted. He therefore thinks overloading string-based models with decision-making is a mistake. Asked whether LeCun’s JEPA-style world-model approach is the solution, Diogo declines to specify the internals, saying his approach is practical rather than committed to a particular architecture. He sees JEPA as promising research but says the important question is what can produce the largest real-world effect with available technology and resources.
Refusal belongs in a product like ChatGPT, not inside a general-purpose API
The host asks about Diogo’s opposition to “safety alignment” and TypeSafe’s decision not to make Jev refuse requests. Diogo clarifies that he is not opposed to safety as a principle, but believes safety alignment is often misaligned with API users. A refusal such as “I’m sorry, I can’t read DNA.py” is a type error when a model is functioning as a dependency inside software. If a downstream service refuses unpredictably, developers may not know why the dependency broke or what another user sent to it. He distinguishes capability alignment—doing what the developer wants—from safety alignment, which imposes another party’s instructions. He says safety alignment can make sense in a consumer product such as ChatGPT or Claude, where a company chooses the experience appropriate for its users, but is unacceptable as the default behavior of a general API. When challenged with the possibility of models being used to kill people, Diogo says companies can reasonably prefer not to support war-related uses, but believes the general-purpose technological layer is the wrong place to enforce that preference. Every special restriction fractures the model’s intelligence. He compares Jev to a database: the database should not decide whether downstream use is morally acceptable; developers and institutions should handle that responsibility.
TypeSafe’s real advantage is data, task design, and reliability—not benchmark scores
Diogo says TypeSafe is fundamentally a data lab rather than a model lab. He rejects training on users’ data because real-world usage has heavy biases and power-law repetition: overfitting to popular queries would make the model less useful for the futuristic, unexpected infrastructure people will build on top of it. He compares TypeSafe’s intended role to TCP beneath applications: a general infrastructure layer that must support many future abstractions. The data team’s work is not merely generating synthetic examples. Diogo describes people with taste examining the model’s cognitive core, identifying its “jaggedness,” and correcting failures surgically in ways that generalize across dimensions rather than patching a single example. He says the hardest and most important decision is choosing the right task or North Star. RLHF shifted models toward instruction following; RLVR shifted them toward benchmark-verifiable reasoning; TypeSafe’s RLCD direction is meant to make intelligence reliable for programmatic use. He refuses to compete through public benchmarks, which he considers gameable and often actively misleading. TypeSafe uses internal evaluations to compare models and ensure Jev is on the intelligence-per-dollar frontier, but does not want those evaluations to become an alternative incentive. In the long run, he says, developers should judge models on their own workflows, then build trust through measured reliability.
Jev’s API uses choices, scores, and nuels to expose decisions as programming primitives
The host turns to Jev’s API, which exposes three primitives: choice, score, and nuel. Diogo says “nuel” comes from Bernoulli probability and was deliberately made into a new term rather than simply calling it a Boolean. The three primitives are not ordinary programming types: a score is not an integer or float, and a choice is not merely a function call. TypeSafe prioritized conceptual clarity over making the objects look immediately familiar. He maps the primitives to familiar programming operations. A choice corresponds to an enum and can be hydrated into a function call; a nuel represents a probabilistic true-or-false decision and fits naturally into an if statement; a score supports sorting, thresholding, and greater-than or less-than comparisons. Diogo says the company expects to add more types that map to programming primitives. For production use, he recommends structured JSON rather than putting everything into a textual system prompt. State, instructions, criteria, and outputs should remain structured so programs can place each object where it belongs. He also urges developers to ask many small, explicit questions instead of one giant model call. A refusal policy, for example, should be decomposed into independent checks for the situations that matter, with thresholds and tests attached to each. This makes failures observable, fixable, and repeatable rather than buried in a prompt.
Robustness matters more than determinism, and model versions will move quickly
Asked why Jev has no seed and whether identical inputs always produce identical outputs, Diogo says determinism can be useful for some unit tests but is not his preferred North Star. He favors robustness: semantically similar inputs should produce similar outputs. One TypeSafe test is to add different UUIDs or nonces to an otherwise identical prompt and check whether the model’s answers remain similar. This matters because users are harmed when an AI system makes different decisions merely because irrelevant details changed. Diogo says determinism could be offered, but it would trade away some intelligence per dollar. The host warns that developers may worry TypeSafe will later quantize or alter the launch model to reduce GPU demand. Diogo responds that TypeSafe will not silently change deployed models, but also will not promise indefinite support for every version. The company expects to release new models quickly and may eventually offer a long-term-support model to avoid an ecosystem fractured across hundreds of versions. He also distinguishes uptime reliability from intelligence reliability. TypeSafe wants strong infrastructure uptime, but the deeper goal is that developers can trust the model to perform a task consistently enough that they do not need to try it first. Diogo says Jev is intended to remain on the intelligence-per-dollar frontier, while intelligence per second may be important for latency-sensitive applications but probably will not define Jev’s niche.
The launch exposed a large developer market: dark data, coding agents, and smart software
Diogo says the launch passed a key milestone when token usage remained high even at night, showing that machines—not only curious individuals—were calling the API. Signups matter less to him than sustained programmatic usage. A single power user running a loop can create more value than many people making isolated chatbot queries, and once a workflow becomes valuable, developers ask for much higher rate limits because software runs continuously in the background. He identifies several major use-case families. “Dark data” refers to large companies’ stores of data that are too expensive to analyze with conventional models; this and coding agents could generate the most volume. Real-time applications need intelligence in the loop and benefit from lower latency. A third category is verifying other LLM calls or software behavior. A fourth is “smart software”: systems that are intrinsically composable and can perform actions that were not previously practical. Computer-use demonstrations also excite him, especially voice-controlled computer operation, although he stresses that demonstrations must become reliable products. He is particularly interested in coding agents escaping the constraints of a single model and its KV cache. Today’s agents append state to one model context, which makes routing, subagents, compaction, and decomposition difficult. Diogo imagines agents sharing labeled state, searching task trees for relevant context, coordinating through richer memory semantics, and using parallel read-only or write-capable processes. He wants to publish design ideas on these patterns, subject to his team’s approval.
Diogo’s path from InstructGPT to TypeSafe—and the future he wants others to build
Diogo traces the company back to his work on instruction following. He had believed structured GPT-style models were extremely powerful because they could follow instructions, but he became concerned that their practical use was mostly copywriting and “slop” generation rather than economic automation. Working backward from an AI-based economic revolution, he asked whether the consumers of an AI API would ultimately be humans or code. He concluded that code would dominate, while the field was still optimizing for human-facing chat. He says he initially expected the project to take a week, then spent years pursuing it. After deciding that starting a company would be faster than trying to create the direction inside an existing lab, he contacted colleagues including Eric and Sasha, raised funding within roughly two weeks, and began working with people out of his apartment. Before launch, more than half of the people who tried Jev did not understand it; technical believers recognized its potential, but customers worried about procurement and whether it solved an immediate painkiller problem. The public launch changed that reaction dramatically. Asked what others should build, Diogo suggests intelligent games with dynamic NPCs and stories, and coding agents freed from KV-cache constraints. He wants developers to explore many forms of machine-native intelligence under a unified vision rather than copy Jev mechanically. His broader goal is an “AWS of intelligence”: reliable layers of intelligence that disappear into software, increase productivity, and eventually produce measurable total-factor-productivity growth rather than merely adding chat boxes to existing products.
Show notes
Tickets for AIE NYC now open, and apply for the invite-only AIE CODE. Join us! We have an unusual relationship with today’s guest: for years since coauthoring the InstructGPT paper, Diogo Almeida had been saying that API-available frontier models have ...
Follow this show on AudioBrevity and new episodes get summarized for you. Create a free account