Jev is TypeSafe’s AI decision model for classification, scoring, and routing. It returns typed answers that software can use directly, rather than generating text that your code must parse.
Eleven days after TypeSafe launched Jev, Allie Laabs was at CodeRabbit's San Francisco office for the first Jev hackathon, which we hosted with TypeSafe. More than 160 builders spent about four hours hacking on the model after Allie opened the day with a talk on how to think about Jev.
In this episode of The Merge, Allie explained what Jev does, how to spot where it belongs in your code, and the one habit she keeps having to teach coding agents.
TypeSafe is a lab of about 20 people, and it opened early access to Jev on September 15. According to Vercel, nearly 13% of paid AI Gateway teams were using it within 24 hours, the fastest adoption of any model in the gateway's history. TypeSafe Founder Diogo Almeida told VentureBeat that the company cleared 140,000 people from the waitlist in the first 36 hours. By September 20, the waitlist was gone and new accounts came with $5 in free credit.
Allie called the launch "one of the most bizarre experiences of my entire life," far beyond anything the team could have predicted. "Had we prepared for a launch this big, that would have been an irresponsible use of resources."
Figure 1. Source: Vercel. Redrawn from the published chart; values are approximate.
The expensive round trip through text #
To understand why developers picked Jev up so fast, start with Allie's complaint about how we use LLMs inside software today.
As an example, a program needs a decision, like which queue a ticket belongs in. Today, we turn the program's state into a prompt. The model writes text, then our code parses that text back into a value the program can branch on.
"We started in machine space and we ended in machine space," Allie said, "yet we did this extremely expensive bridge through text and through a human interface layer. Why?"
Jev skips the text. You send it a state, such as a ticket, a transaction, or a tool call, along with typed questions. It returns one of three answer types: a choice from a list you define, a score on a rubric, or a yes/no probability. There's no string to parse, and the model can't answer with an option you didn't allow.
| Answer type | What you ask | What comes back | | Choice | Pick one option from a list you define | The chosen option, a probability for every option, and a confidence value | | Score | Rate the state on a rubric you define | The score, a probability for every point on the rubric, and a confidence value | | Noul | Is this statement about the state true? | A probability between 0 and 1 |
TypeSafe lists the price at $0.042 per million input tokens, with output free, and reports response times of 70 to 500 milliseconds. Those are vendor figures, and the company is upfront that its latency tests ran close to its West Coast servers.
Figure 2. Source: TypeSafe’s Noul cookbook. Averages of 15 full 14-question calls per condition. Ratios show time and cost relative to TypeSafe; higher means more. Costs use historical price assumptions, not current billing.
"Jev is just the direct line," Allie said. "It's machine-to-machine intelligence."
Find the Jev-shaped problems #
Allie says the hardest part of teaching Jev is that it's a category-creation product. It isn't a better LLM, and it doesn't replace one. So she gives people two ways in.
The first approach is the easiest one. "If you have a classification-shaped problem in your software and you're using LLMs to do it, Jev is almost certainly a better drop-in," she said. That covers sorting emails, categorizing financial transactions, and scoring anything on a scale. Most early production users, she said, already had these problems and were solving them with a slower, more expensive tool. She calls them "Jev-shaped problems."
The second way is the one that excites her most, and it means putting down the LLM mental model entirely. Jev is almost an anti-language language model. To use it well, you have to think like a programmer again, in terms of switch statements, if/else branches, and routing decisions. TypeSafe calls each question a primitive because it wants developers to treat them as the smallest building blocks in their code. Allie finds it helpful to describe Jev as "a smart if statement or a smart switch statement … an intelligence-infused logic gate."
Anywhere your app needs to make a decision, Jev gets interesting. Think about every place in your code where logic branches. Maybe it's a regular expression that has grown past the point where anyone can read it. Maybe it's a feature you never built because the branching condition was impossible to write down. That's where Allie expects "a truly new path of code that couldn't exist before."
Engineers who've been designing systems by hand for decades will get this quickly, she said. For people who started building with coding agents, she suggests a simple exercise. Sketch the flowchart of your application's behavior, even if you've never read the code. At each branch, ask whether you could define the condition mathematically.
"If you were to try to sketch out a flowchart of behavior, and for one of them you're like, ‘well, this is more like a gut feeling’ … if it's this vibe, it should do that," she said. "That's probably a spot where Jev could work."
Ask everything up front #
One of the first things Allie wrote about in TypeSafe's docs, and a technique she used in her very first Jev project, is what she calls "speculative prompting." TypeSafe calls it speculative fan-out.
It runs against normal API habits. Usually, you only call an API when you need the answer. With Jev, you ask every question you might need in a single request, including ones that only matter if some other answer turns out a certain way.
Allie gave the example of a support ticket. "Is it a billing ticket? And then also ask, is it a refund request?" she said. "You're only going to care about the answer to that second one if the answer to the first one is true, but ask them at the same time."
This works because Jev answers every question in parallel and independently against the same state. Whether you send one question or 100, the answers come back in roughly the same time. An extra question adds a few cheap input tokens and almost no latency. A second call, on the other hand, means sending the whole state again and waiting for another round trip. "Oftentimes, if you do need to do another round trip and send the entire state again, [it] might actually cost you more," she said.
TypeSafe's parallel questions cookbook tests this on a 13-question briefing. Batching every question into one call was 12.2 times cheaper and 10 times faster than asking one at a time, and the answers didn't change.
Figure 3. Cost and total time for 13 questions against the same 53,777-character document, asked in one call or one question per call. Figures are from TypeSafe's parallel questions cookbook.
Coding agents still write it sequentially #
The catch is that coding agents don't know this yet.
"It's not intuitive to coding agents," Allie said. "They don't do it by default."
Most API code calls only what it needs, when it needs it, and agents write code the same way. So when Allie vibe codes a Jev project, she adds a cleanup step after the first pass. She tells the agent:
"Hey, if we are ever sending the same state to the TypeSafe API in different places, we should almost certainly be bundling those into one call up front.
"Pretty much always the agent is like, ‘oh yeah, we are doing that,’" Allie explained. She expects this to fade as decision models make their way into training data. "But right now we really need to hold the agent's hands."
That one sentence Allie keeps typing is really a code review rule, and you can write it down once so neither you nor the agent has to remember it. CodeRabbit picks up code guidelines from files like AGENTS.md, which your coding agent also reads. You can also add path instructions so every pull request that touches your Jev integration gets checked for it:
reviews:
path_instructions:
- path: "**/*.{ts,py}"
instructions: |
- Flag code that sends the same state to the TypeSafe API in separate
calls. Suggest bundling the questions into one request.
- Check that low-confidence Jev answers have a fallback path
(ask for more information, escalate, or route to a human).
- Flag untrusted text (user input, tool output, fetched content)
that reaches the Jev state for a decision that authorizes an action.
The last rule comes from TypeSafe itself. Its known-limitations page for Jev 1.13 warns that injected instructions or text written to argue for its own classification "can move the answer." A cheap decision is still a decision, and someone needs to check what feeds into it.
The wrong tool for plenty of jobs #
Allie doesn't pitch Jev as the answer to everything. She compares it to Docker and AWS Lambda. Both confused people when they came out, and now it's hard to work in infrastructure without knowing them.
"People know that regular expressions exist. It's the wrong tool for a lot of jobs. It's very much the correct tool for some jobs," she said. "When it is the right tool, it is the right tool."
For Jev to be there for everybody, it has to be cheap enough for everyone to try. Allie says TypeSafe gives every user $5 a month in free credits with individual builders in mind. Companies can put whatever they need into their accounts, but for plenty of people in the world, she said, even $5 would be too much. "At our prices, $5 is a lot of tokens," she said. "You can put something live in production for $5 a month for a lot of indie projects."
The use cases she's most excited about run in real time. She built a teleprompter that listens as you talk and removes each question from the screen once you've asked it. She's also seen developers at ElevenLabs feed live speech transcription into Jev to coach a speaker as they talk.
Watch the full episode of The Merge for more from Allie on generative UI, why she thinks it'll make software accessible to far more people, and what the launch has looked like from inside TypeSafe.