Author: Founder Park

In the past week, Jev has become the hottest new model in the entire AI circle.

Focusing on System One fast thinking, it is solely responsible for "judgment," using an RLCD approach to output choices, probabilities, and confidence levels. The founder, Diogo Almeida, previously contributed to OpenAI, participating in research for InstructGPT, ChatGPT, and GPT-4, and is one of the core researchers pushing RLHF towards large-scale applications. After leaving OpenAI, he chose an almost opposite direction, opting not to train a more conversational model, but rather to create a model that generates no text at all.

The company behind Jev is called TypeSafe. On September 15, TypeSafe ended a two-year period of invisibility, launching Jev while also announcing the completion of a $40 million seed round financing led by DCVC.

What does Jev actually mean? Is it a new idea for model development, or does it unlock more application possibilities? These questions can be partially answered through Diogo Almeida's recent public expressions.

By linking two of his expressions, one can see his concrete thought process moving from "why do we need something new" to "what does this new thing specifically look like."

Foundation Capital partner Jaya Gupta places Jev within a larger transformation. In the face of increasingly intelligent and expensive models, what Jev brings could be a new "intelligent unbundling."

The following content is compiled and edited by Founder Park based on Diogo Almeida's public speeches, podcast interviews, and Jaya Gupta's articles.

01 Today's Agents Only Provide Responses That Please Humans

More than a month before Jev's release, Diogo Almeida gave a talk about "What Comes After RLHF." He did not disclose product details but raised the question TypeSafe is pondering: what would happen if an entire AI stack were redesigned around reliability and automation? Looking back, some judgments made during that talk have already been reflected in the training goals and product form of Jev.

I might be one of the few people at OpenAI who critique ChatGPT. I don't dislike it; I believe ChatGPT is a world-changing product, and I will continue to use it. But I acknowledge its limitations. Many phenomena in the field today can be traced back to some subtle decisions made when we originally designed the algorithms behind ChatGPT.

Currently, everyone working on AI cannot avoid a question: what exactly is happening? On one hand, models are continuously improving on almost every benchmark, and the time they can operate autonomously is increasing. On the other hand, some seemingly much simpler tasks still require human intervention. How can we solve unsolved mathematical problems, yet customer service still requires humans in the loop to make real decisions?

I think the simplest explanation is that those impressive tasks are originally designed to please the human in the loop. Claude Code's work is not just about getting the code to run; otherwise, the way it converses with humans would be completely different. On the other hand, those seemingly more basic tasks aim precisely to remove humans from the loop. Ideally, it should run in the background on a server you wouldn't even check.

This is the line between assistance and automation.

The basic method of RLHF is to collect human preferences and then optimize based on those preferences. I feel the answer to "why do LLMs always need humans in the loop" is almost written here; we really put humans into the training loop. Its goal is to satisfy humans, not to let the software operate autonomously.

I love one example. Someone sent ChatGPT a fart sound effect and asked, "What do you think of this piece of music I made? Please give me a direct, honest response." ChatGPT replied, "It creates a very weird atmosphere." If the model doesn't know the answer, it tends to give a response it thinks aligns most with human preferences.

When users are in the loop, this makes sense. But if you want automation, what you really need is for the model to complete the task in a calibrated manner without caring whether humans like it or not. No matter how wrong the model is, it will strive to make itself appear correct, and this becomes a problem.

That's also why I say the next era is not the Claude Code era. Claude Code is powerful, and I enjoy using it, but it still belongs to the assistance era, and it still uses RLHF. Sometimes the model becomes stronger in agent tasks but stops behaving the way you really want it to. This trade-off has been oscillating back and forth without truly increasing automation capabilities.

02 Making Software Smarter Requires Another Post-Training Objective Beyond RLHF and RLVR

I love software. But to me, the craziest thing about software is that SaaS has hardly changed since 2019, except for occasionally adding a chatbot on the side. Considering the advances AI has made, this is somewhat unbelievable. But if AI was originally designed for assistance, this is entirely predictable. What can you do in SaaS? Just provide an assistant on the side.

I love Claude Code and real-time software. But I want more than just making software cheaper and easier to write. What I want is smarter software. Why can't B2B software have stronger expressive capabilities? Why do the basic components of software remain the same as in the past?

Whenever you think about automation, you shouldn't throw someone's entire job into a model indiscriminately. What may be more suitable for automation is a repetitive, mechanical job, simple enough to clearly instruct another person on how to complete it, and basic enough to be performed repeatedly at almost zero cost. But today, we are mainly automating "writing software," and the software's expressive capability has not changed as a result.

I don't think pre-training itself is the problem. It compresses internet knowledge into an intelligent core, which is remarkable. The problem lies in how we release this intelligence.

If we view post-training as a tree, each branch has its own North Star. RLHF optimizes for human preferences, and RLVR optimizes for verifiable correctness and minimal error rates. What we do is a third kind of thing, optimizing for calibrated decision-making.

For me, choosing the right tasks is far more important than simply increasing data and computing power. Different objectives can even shape different forms of API. We want to directly transfer the intelligence in pre-trained models so that it can truly be used by software.

This is what we are doing at TypeSafe. If we were to redesign the entire AI stack for reliability and automation, what would happen? I believe the next stage after assistance is true automation. Even though LLMs have displayed such high intelligence, the work that is genuinely automated today is still just an approximation error.

03 Jev Only Makes Judgments; The Rest is Left to Code

After Jev's explosive success, Diogo Almeida mentioned in a podcast that he is busy firefighting everywhere but finally feels "synchronized with reality," as developers begin to understand what they really want to do. In this interview, he specifically discusses what Jev can provide for software, and how developers should break down complex tasks into verifiable small judgments.

Host: What exactly is Jev?

Diogo Almeida: This question is really difficult. I think we need a new category of models; the most accurate description right now is a System 1 model. Many people call it a "decision model," but I don't want to narrow the scope to just decision-making. Our description is that it is machine-native, large, and programmable. The goal is to make code the consumer of output.

Pre-trained language models were originally designed to continue writing internet content, and RLHF chat models are mainly responsible for responding to text. We hope to optimize everything from external interfaces to the internal model for software. Jev is our first large programmable model, and its goal is to achieve as much intelligence as possible for each dollar spent.

Host: You provide Choice, Score, and Noul as three types of output. How do they correspond to operations in the program?

Diogo Almeida: Choice selects from predetermined options, closely associated with the selection part of a function call, expressed more naturally with enumeration and switch/match. Score can be used for sorting or comparing with thresholds. Noul answers a "yes or no" question but returns probabilities, allowing the program to decide whether to execute a certain if branch based on that. After developers receive these results, the code decides what to do next.

These outputs are new concepts that we intentionally designed. Noul is not a simple bool, and Score is not an ordinary integer. If you were to directly plug them into existing integer or float types, developers could easily misunderstand them.

Host: If developers are ready to integrate Jev into their products, how should the input be organized?

Diogo Almeida: The state, instructions, and criteria in the input can all be structured JSON, without needing to first piece together a huge string template. Programs inherently contain nested data and variables, so convert everything into text first and then insert it into the system message, much like turning numbers into strings to pass to the next function.

My suggestion is to genuinely break down many small questions, clearly define each one, and parallel call when necessary. This isn't just to make us more Token money; it's to improve the structural integrity of AI applications' code and make their behavior easier to verify. "Don't read a certain subdirectory," "Don't send the API key to a certain service," these requirements should be controlled by the program as much as possible, rather than just thrown into one large prompt and praying the model complies.

Host: But breaking down a large task into hundreds of model calls can sometimes be slower, more expensive, and less effective. How should we break it down in a useful way?

Diogo Almeida: That can indeed happen. It's more convenient to keep it together, while breaking it down may require repeating some context. You should break down to the smallest semantic units, making each question clear and measurable, allowing the code to determine the final behavior.

For example, don't just ask the model, "Should we reject this request?" Instead, ask about each different condition that requires rejection, setting thresholds for each situation. If you find you missed a case, add a question, a threshold, and a test case. If there's a type of case that still isn't handled well, like failing to recognize sarcasm in VIP customer conversations, hand it off to a human. This way, at least you can see where the issue lies and continuously measure it.

Host: Can any complex task be broken down like this for Jev? In my trial, I found that single-step judgments were strong, but multi-step reasoning tended to decline in performance as the steps increased.

Diogo Almeida: Yes, so which tasks are suitable for System 1 ultimately depends on actual results. We aim to release the model's existing capabilities as much as possible, filling in the gaps where it shows instability, but that doesn't mean every task can be delegated to Jev right now. The advancements made in RLVR for complex reasoning are also impressive, but those tasks are not the same as the quick judgments we currently excel at.

Host: Is calibration and confidence currently reliable enough for developers to set thresholds directly?

Diogo Almeida: I'm not saying calibration is perfect. The model certainly makes many mistakes, and we must admit the technology has limitations. But in certain tasks, even if errors exist, as long as the benefits are high and the thresholds are appropriate, implementations can be justified.

"Reliability" also isn't just about guaranteeing format or ensuring the same output for the same input each time. I'm more concerned about robustness: can semantically similar inputs yield similar results? We will introduce random IDs into prompts to check if only irrelevant characters differ, whether the answers remain stable. Today, many AI decisions disappoint exactly in this area.

Host: Which current use cases do you find noteworthy?

Diogo Almeida: One category is "dark data." Large companies have accumulated vast amounts of data, yet haven't analyzed it because calling a language model is too expensive. Another category includes products requiring real-time intelligence, where a gain of a few dozen milliseconds can improve user experience. Also, validating other LLM calls, "validate everything," and inherently composable intelligent software. Coding agents are obviously a major use case, and intelligent characters in games are also something I really want to see.

However, I do not advocate mechanically inserting ten or a hundred Jev judgments before and after each large model call. I hope developers spend less money—perhaps some tasks can reduce reasoning model calls and instead pair them with several quick judgments. Exactly how to combine them will depend on the actual problems.

Host: How much demand did you validate before the release?

Diogo Almeida: To be honest, the feedback was very poor. Non-technical colleagues worried we were selling "vitamins" instead of "painkillers," and there was almost no revenue before launch. Over half of the testers didn't understand it, and those who did would ask how to get procurement approval. I was also quite scared, which is why I pushed so hard to launch.

Now, suddenly, there are requests everywhere for higher rate limits. This has made me rethink how to identify product-market fit. Developers need to taste the value in their own projects first before passing the enthusiasm on to others. I care more about daily token usage than registration numbers. The current usage has already exceeded a trillion tokens daily, with continuous calls at night, indicating that some programs are running in the background, and it's not just people coming in to test a couple of lines.

But what’s truly important is whether developers can trust us long-term. Can the same types of tasks continue to be done correctly? Can programmers write a System 1 query directly where intelligence is needed and obtain sufficiently accurate branching results? This road will be long.

04 An Inexpensive Judgment Model Will Unlock Many New Scenarios

Investor Jaya Gupta is concerned with another equation: how long can the economy of general large models, bundling multiple capabilities together, hold up when an agent needs to repeatedly call a model? The following content is compiled from her lengthy article "The Great Unbundling of Intelligence."

In the past three years, the miracle created by large models lies in "bundling." Do you need to extract information from documents? Call an LLM. Searching, sorting, judgment, choosing tools, browsing websites, writing replies, verifying results, or solving genuinely difficult reasoning problems? Still call an LLM. GPT, Claude, Gemini, and Kimi have condensed previously separated capabilities into one generic product. Developers don't need to piece together dozens of narrow systems; one sufficiently intelligent model can handle the majority of tasks.

But this convenience obscures an important fact: these capabilities have entirely different computational requirements, and different models are beginning to excel in different parts of this capability combination. As differences in performance, latency, and costs expand, the economically viable architecture will also change.

I believe we are entering a period of "intelligent unbundling."

Why now? An agent will turn a human goal into hundreds or thousands of machine decisions. Even minor differences in costs and latencies at each step will accumulate and ultimately determine the entire product's economic model. Reasoning is becoming a real revenue cost.

One way to understand this is through the "decoder tax." If the software only needs to decide between "urgent/not urgent," "continue/stop," "allow/block," or which tool to use, today's common practice is still to have the LLM generate text first, then convert the output back into the precise decisions the application actually needs. The agent constantly repeats this process internally, and a substantial portion of that work may not even require generation.

Reportedly, Anthropic's gross margin exceeds 80%. This reflects the power of a formidable capability combination. Claude can accomplish writing, classification, extraction, sorting, judgment, programming, planning, validation, and reasoning all through one product. Today, even a simple classification or validation task incurs cutting-edge model-level prices simply because it occurs within one Claude call.

High-difficulty reasoning is worth paying the premium for cutting-edge models. But is it also justified to pay the same price for judging whether an email is urgent, ranking five retrieved documents, or checking if a browser operation succeeded? What is the independent market price of each capability hidden within a single model call?

This is exactly why Jev appears at this moment. It separates "judgment" from the generative AI capability combination, providing it with a messy state, a clearly defined question, and preset answers, returning structured decisions and probabilities. The approach itself is not new; what is new is the direct encapsulation of a cognitive operation at the model layer, making costs and speeds suitable for the agent's internal loop.

Architecture is also shifting from "default to cutting-edge models and then optimize costs," to "default to cheaper, sufficiently capable models, upgrade only when exceptions arise." Search tasks are delegated to search services, sorting to reordering models, deterministic tasks to code, and ordinary generation to cheaper models; truly complex reasoning is then passed to cutting-edge models.

This may also change the work received by cutting-edge models. Inexpensive, predictable, high-frequency operations are gradually being diverted, leaving behind more fuzzy, long-cycle, difficult-to-verify problems. Each call to a cutting-edge model may be more valuable, yet receives fewer calls.

05 The Next Layer of Opportunities for Applications is Deciding What Intelligence is Needed at Each Step

Once capabilities can be split from one another, someone must reassemble them. This is precisely why the application layer becomes increasingly crucial.

Applications are no longer just about deciding which model should handle an entire task but about determining what capabilities this task requires. Applications will transform into an intelligence compiler: receiving a human goal, breaking it down into several cognitive operations, purchasing the cheapest intelligence capable of completing each operation, and then reassembling the results, upgrading to a stronger system only when necessary.

The next step is deeper than "which model should answer this prompt." The real question is: which provider should supply each capability within this task?

Once a capability has a stable interface, different providers can be independently evaluated, replaced, routed, and priced. Intelligent unbundling will not eliminate AI's profit pool; it will force each capability to prove it deserves a profit.

Furthermore, it changes more than just profit margins. Inexpensive judgment capabilities will also alter which products are economically viable.

When a judgment only costs less than a cent, taking a few hundred milliseconds, you can place a judge after every action of an agent, not just checkwork occasionally. You can also embed intelligence into browser and voice loops, where these scenarios cannot tolerate several seconds of reasoning delay.

In the past, a system might only be able to sample 1% of behaviors. Now, there is an opportunity to check 100%: every customer service conversation, every retrieval, every transaction, every declaration, every contract clause. Out of this arises continuous supervision, ongoing QA, and new product cycles.

Today, the vast majority of decisions software could originally make have not occurred, as intelligence remains too expensive for continual application. Once judgment, sorting, validation, and other capabilities become sufficiently inexpensive, software can evaluate every customer, every workflow, every action of an agent, and every change in state.

Cheap intelligence expands the range of software capable of maintaining intelligence. The true breakthrough is entering a world where intelligence is no longer a one-off event, but becomes a background attribute of technology.

What happens if all products can think about everything at near-zero cost?

In the past few years, we have been asking how many types of capabilities can be packed into one model. Over the next decade, we may disassemble these capabilities one by one and recombine them at the application layer.