Diogo AlmeidaCo-Founder & CEO

We needed a new class of models. The most accurate name we have come up with is system one models. The goal is for code to be the consumer. As opposed to large language models which are meant for autocomplete of the internet, or RLHF models which are meant to reply to text, Jev is designed to have its outputs directly consumed by code. Everything we do beyond the internals of the model is optimized for software. Jev is our first large programmable model. It is optimized for intelligence per dollar, which is where the name comes from, a reference to Jevons paradox. We are going all out on that tradeoff.

The spicy take is that I believe Yann LeCun is among the closest to reality in his criticisms of large language models. He has this famous slide about how LLMs are doomed as sequence length increases because the probability of an error grows monotonically. Mathematically obvious, yet empirically it does not hold. The reason is mode collapse. When you train with RLHF, the model stops covering the full distribution of possible answers and drops the minority cases to concentrate on what gets rewarded. This is exactly what GANs did when they started making blurry images instead of diverse ones. The model becomes hyperconfident. It needs to be miscalibrated in order to not go off the rails because errors are very easy to detect and subtle wrongs are very hard to spot. That miscalibration then warps the entire probability space of the model.

RHF is about a northstar: instruction following. DPO and all its descendants still pursue that same northstar. RLVR added a new direction: optimizing on benchmarks, tasks with programmatically verifiable outputs. RLCD is our new northstar: making models reliable for programmatic use. It is not about the algorithm. It is about the task. The task shapes everything. Each of those training directions has a distinct data shape, a distinct kind of behavior it surfaces. For us the task is calibrated decisions for software. That is what RLCD means.

Public benchmarks are extremely gameable. Even when labs try not to game them, they still do. Before the reasoning revolution, almost every lab had a team quietly collecting data that resembled popular benchmarks to inflate their numbers. That is just benchmarking with extra steps. The problem is that intelligence has a qualitative dimension. When we launched Jev, within two hours the bigger story was not the video but the reaction of developers saying this is actually usable. That is a vibe and trust signal. Long term, what matters is putting a model into your specific workflow, evaluating it for that workflow, and measuring against your own use case. Our job is to keep moving the nines of reliability so that trust builds over time. Public benchmarks are antithetical to that.

I am not opposed to safety as a principle. My position is that safety alignment is misaligned with users when applied to an API. For a first party product like ChatGPT, it makes complete sense. Maybe that company does not want to support certain types of content for their user base. That is fine. But in an API, a refusal is a type error. If you are a developer and your code dependency randomly refuses a query because a user sent a weird message, your software stochastically breaks. That is not a safety feature. That is an antipattern that comes from people who do not understand software. Refusals fracture the intelligence of the model every single time they are baked in. And every single time you overfit the model to some weird edge case to prevent refusals, you fracture it more.

Would I prefer our technology not be used to harm people? Obviously. Would I put my thumb in the scale for that? Yes, in some ways. But will I do it at the technological layer? Absolutely not. I think intelligence will be more like a database than a coworker. We do not ask databases to police their own downstream use. The first line of defense is that you are liable for what you build with any tool. We should give developers maximum power and trust that they are building things for good purposes. We obviously cannot even know what downstream tasks our API is being used for since it should be decomposed into small, isolated calls. That is a healthy boundary to maintain.

Calibration means that when the model says 80 percent confidence, it is actually right 80 percent of the time. This matters enormously for software because thresholding is how you control behavior. If the model is miscalibrated, your threshold is meaningless. You want similar inputs to produce similar outputs. We test this by putting unique IDs called nonces into prompts that are semantically identical and checking that the outputs are consistent. This is robustness, and it is where AI most frequently burns developers today. They think the model should be smart enough to automate a task, there is economic incentive to automate it, yet they cannot trust the output because the distribution is too jagged.

Function calling is a deeply antipattern interface for AI decisions. One very simple ask I always had was that for any function call you should get a calibrated probability for each option. Without that, the only way to control refusal thresholds, routing thresholds, or decision confidence is through begging in a system prompt. That is an insane interface for software engineers. Our three primitives, noul for boolean decisions, choice for structured selection like a switch statement on an enum, and score for sorting or thresholding, map directly to programming primitives. They are not new names for existing types. They are new concepts that give software engineers the ability to actually control and measure AI behavior programmatically.

Break everything down into its smallest semantic unit. Never ask one big question when you can ask ten small ones. For each piece of state you want to reason about, ask a separate, explicit, very structured question. This way every single call is evaluable, every failure is diagnosable, and every fix is durable because it lives in the structure of your code, not hidden in some context-rotting system prompt. If you find a situation where the model got something wrong, you add a new question to handle that case. The bug is now solved forever. It is like machine learning without the machine learning. And yes, it is more calls, but with a model like Jev the cost is not a barrier and the reliability gain is enormous.

We are going to keep shipping new shapes of intelligence. Jev is the first system one model. That is not the only category. Some things are not decisions. There will be other types that are equally machine native. Longer term, I think about this like the early internet. Think about what composability gave us in the two thousands. Creation was back on the menu. That is what we want to give software engineers again. AI should disappear into the background of software and make everything around you more delightful. The question that haunts me is how can AI solve millennium prize problems in mathematics but still not automate basic repetitive work that does not even take very smart people to do? The answer is the plug does not fit. We are building the plug.

When I first thought of this direction, I assumed that it was so obviously correct that Anthropic or someone else must already be pursuing it. I was wrong. I talked to other companies and figured out that starting a startup would be faster than convincing an existing lab to change direction. So we did it. I thought the whole project would take a week. I was unbelievably wrong and I apologize to everyone at OpenAI who I thought I was about to show up. But the reason I could not walk away is that if an AI winter happened and I had not done every possible thing I could to prevent it, I would have considered myself personally responsible, both for what RLHF did to the gap between AI promise and reality, and for not going all in on the direction I believed was where value was actually going to be created.

The bitterest lesson in AI is that the task you choose determines everything. It determines what data is valuable, what capabilities get surfaced, what kind of intelligence you can build. Algorithms and compute matter, but data matters more than both, and having the right northstar matters more than data. This has happened maybe two and a half times in large language model history. RLHF established instruction following as a northstar. RLVR made a slight edit toward benchmark optimization. And RLCD is our new task: making AI reliable for programmatic, machine-native use. Most researchers do not spend enough time asking whether the task they are optimizing for is actually the right one. That is the question that everything else depends on.

It really depends on why you want to do it. If you want to play around with research, the big labs are genuinely the best place for that. What I would push back on is starting a new lab just for its own sake. Most new labs I have talked to do not have a clear direction. They want money to run experiments. That destroys value. If you truly have a different northstar, a genuine new task you believe in, then absolutely start a company. But do not try to be a lab. Try to solve something real. Be driven by actual problems you want to see fixed in the world. That was the only thing that kept me going through two years of stealth while nobody believed what we were building was real.

More than half the people we had play with Jev before launch simply did not understand it. That was very scary for the non-technical members of the team. But we knew from the computational properties alone that this was going to be huge once the right people touched it. We intentionally targeted developers first because developers find the use cases, then everyone else FOSMOs in. The thing we did not fully anticipate was the rate limit problem. Signups are meaningless for a developer API. What matters is when people start hitting rate limits because they want to run it inside production loops in the background. When machines are calling your API continuously through the night, not just people trying queries, that is the real signal. We surpassed a trillion tokens per day within days of launch and it was not slowing down at night.