Jev: 8 real use cases for the fastest, cheapest model I’ve ever used | John Lindquist

Context

Claire Vo hosts How I AI, a show about practical AI workflows. Her guest is John Lindquist, who created egghead.io, a developer education platform, and is now building mega.dev, a program that teaches developers to do real work with AI agents. They walk through demos of Jev, a model from TypeSafe AI that returns structured decisions and scores instead of generated text. It matters to PMs because many product features are really classification and routing problems, and a model this fast and cheap makes some of them practical to build for the first time.

The Big Idea

Jev is a decision engine, not a chatbot. When a product has a limited set of possible actions, a fast and nearly free model that picks among them beats a big generative model on speed and cost.

John and Claire show that many things that look open-ended, like a web page or a chess game, boil down to a small set of choices. A model that scores those choices in milliseconds opens up work that used to be too slow or too costly to try.

Key Insights

Fast and free unlocks new work

• Cost: John says he made hundreds of demos and spent about 73 cents in total.
• Scale: Claire ran it over about 20,000 records and was charged 0.4 cents. John passed in five gigabytes of JSON for roughly 40 cents, and it finished in a couple of minutes.
• Why it matters: both of them describe data sets they would never have sent to an LLM because of cost or time. Discovery over that data is now cheap enough to be worth a look, so work that was "not high ROI" before is suddenly open.

Structured in, structured out

Claire's reminder is that Jev does not output text. It outputs decisions, scores and yes or no probabilities from a limited set of options. John adds the contrast: an LLM goes from unstructured text to unstructured text, while Jev takes unstructured sentences or data and returns structured data. That matters because people want to talk to apps in plain language, but apps run on functions and APIs. Jev sits in the middle and maps one to the other.

Chain small decisions like if-else

John's mental model for building with Jev is old-fashioned programming. Think of every condition in the flow, the places where something has to go into this bucket or that bucket, and make each one a Jev call. His voice to-do app does this in layers:

• First, check whether the dictated text is valid, fixing mistakes like a misheard "oat milk".
• Second, match it to a task in the list, using a confidence score.
• Third, match it to the operation to run, such as complete, remove or set low priority.

He built it backwards, starting from the final actions and then adding the dictation step. This chain also works as a loop while speech is still streaming in.

Jev is a very fast router

Claire's summary of the pattern: "Jev is a router." The same idea scales up:

• A single text box, like a command bar, can match a request to the right app, then the right tool, then the right action.
• If the text tells you the job, route as far down the user journey as you can in one go.
• The structure mirrors MCP setups where one layer picks which tool to use. You can stack as many layers as you want.
• Claire expects Jev-powered coding tools that pick the model and the tool in one fast step, then run the whole chain.

Constrained inputs are the sweet spot

John's rule: whenever you have constrained inputs interacting with apps, Jev is a good thing to reach for. Examples they give:

• A web page looks like an infinite canvas of pixels, but the DOM may have only about 10 clickable buttons. Picking one of ten is a decision, not a vision problem.
• Tetris is four shape options and about ten left or right moves.
• A game controller has a limited number of buttons, even if the game feels huge.

Anything that needs a creative open-ended answer is different. John says a screenshot question like "what might confuse a user on this page?" is a job for an LLM that can look at images, not for Jev.

Pairwise comparison for messy data

John calls this his favorite use. Jev compares records in pairs, decides if two entries are the same thing, and groups them into clusters.

• Examples: merging "Cedar Grove office products" with "Cedar Grove office", or "Ridgeway data" with "Ridgeway analytics". John also ran it over pull requests to group them by product area or theme.
• Control knob: a confidence score comes back with every match, so you can require, for example, 99% or higher before merging.
• Cheap checks on top: run a smarter model over a sample or the full result to verify it. You can also ask a cheap model to explain in a sentence why two records were merged, which gives you a quantitative match plus a qualitative reason.

Speed can win a game outright

John built a Blitz chess match with a one minute timer. Jev played white and a free, low-reasoning model on OpenRouter played black. Jev scored the possible moves, kept the top three, then looked at the replies to those and picked a move in under a second. His benchmarks showed Jev about 10 times faster per move and about four times cheaper. John notes this only holds in a limited-options game. Against deep, creative play with feints, a strong LLM could do better.

Latency wars are coming

Claire, drawing on her time as a young product manager running conversion tests, says speed always mattered in consumer experiences. She expects the focus on model cost to be joined by "latency wars". The faster the response, the more magic you can fake with something that feels like an if-else statement. Because Jev is 10x faster, you can also narrow the options first and then hand them to a smarter model.

Inefficient but affordable search

Claire's phrase is that Jev unlocks "efficient inefficiency". Mapping every route, ranking them and double-checking collisions feels wasteful, but it is accurate and now cheap. Instead of telling a big LLM to "think really hard" and return a plan, you evaluate and rank the whole option space quickly.

Mental Models & Frameworks

Jev as a router

• What: a model that takes input text and picks from a fixed set of targets, such as functions, tools, apps or actions.
• How: layer routers. The smallest tools sit at the bottom. Another Jev call above them picks which tool to use.
• When: the possible actions are known in advance and you do not know what the user will type.
• Contrast: use an LLM when you do not know what action you want, or when the task is brainstorming and creation.

Multi-step classification

John's fix when one pass is not good enough is to add another layer of classification, then another. Because the model is fast and free, an extra layer costs little. Over time, as data reinforces the flows you need, you can compress several layers into one. John says some critics tried a single pass, judged it not good enough, and gave up. He thinks the problem is often undefined classifications or weak APIs, not the model.

Check the type of decision

Claire's tip is to test different kinds of decision call. You might assume you have a yes or no question, then find you actually need a choice or a score. Her first idea of how to classify something was sometimes not the right one, so try other forms before blaming the model.

Windowed streaming text

For live voice, John says the app adds words one by one until it has enough information to take an action. It turns that text into the payload for a function call. Then the window is chopped off and a new one begins. Since each action is structured data, it can be stored in history, which makes undo possible.

Decision Principles

Principle: Reach for Jev first

• When: the set of actions is limited, even if it feels endless, such as an API, a data structure or a page of buttons.
• Why: John says this is where a decision model excels. Costs fall and speed rises, and he feels more in control because he knows all the options.

Principle: Reach for an LLM instead

• When: you do not know what the action should be, or the task is brainstorming or visual judgment.
• Why: John says LLMs are better at open exploration and at reading images. His example is asking what in a screenshot might confuse a user.

Trade-offs & Nuance

Fast, but not latency free

Claire warns that Jev is fast and efficient but not instant in every case. John tried live search over 4,000 YouTube comments. Scoring everything one by one is not truly fast, so he clustered groups of 30, 50 or 60 and scored those, which made "real time" search workable. Claire's advice is to study how others built fast search, including caching, before assuming it will be quick.

Early days, limited evidence

John has had the model only for a matter of days. He has not yet found something it did badly, but says he has not spent enough time to judge how smart it is. Both note the model will likely get smarter. Treat the demos as promising, not proven.

Common Mistakes

Mistake: Judging it on one pass

• Why it happens: people try a single classification pass, see weak results, and quit.
• Better approach: John adds a second and third classification layer. He also says people often skip defining the classes clearly or have APIs that are too thin to support good decisions.

Mistake: Treating it like a chatbot

John says it is "not a chatbot anymore". If you try to use it for open conversation, you miss what it is for. Put in data and sentences, and expect a fixed set of structured options back.

Practical Application

Add a command bar router

• Do: list your product's main tools and actions, and set up a single text input that routes to them using a decision model.
• Then: let the user say a compound request, like "go to the to-do app and mark all pull requests low priority", and route all the way down to the action.
• Why it works: it skips menus and navigation, and each step is cheap enough to run live.

Clean duplicate records with confidence scores

• Do: run pairwise comparison across a messy table, such as customer or company entries typed twice.
• Then: set a high confidence cutoff (John's example is 99%) and send borderline pairs to a smarter model or a person.
• Why it works: John says huge data sets can be merged in milliseconds, and each merge can come with a short explanation.

Turn a page into choices

Look at the clickable elements in a flow you want to automate. If a page has about ten buttons, ask which one to press next instead of asking a model to "use the browser". This turns a vague agent problem into a small decision.

Try a live speaker coach

John built a presentation coach. You paste your bullet points, click the microphone and talk. It listens and checks off each point as you cover it. Claire imagines speaker notes that tick off as you speak and even advance your slides. A PM giving a roadmap talk could use the same idea to stay on time.

Questions to Consider

• Which workflow in your product has a limited set of possible actions, like a menu of tools or a list of statuses, that a user currently reaches by clicking through several screens?
• What data set do you own, such as support tickets or user records, that you have never analyzed because sending it to an LLM would be too slow or expensive?
• If a decision model returned a confidence score for every duplicate-record match, what cutoff would you trust before merging, and who would review the borderline cases?
• Where does your product need a human-like creative answer, and where does it just need a quick pick from known options?

Bottom Line

Jev shows that a model that only makes structured decisions can be fast and cheap enough to run on every keystroke or every record. Use it as a router and classifier where the options are limited, stack more layers when one pass falls short, and keep a full LLM for open-ended or visual work.

Resources Mentioned

Tools & Products

People to Follow

John Lindquist

Creator of egghead.io, a developer education platform used by hundreds of thousands of working engineers. He is now building mega.dev with Theo, Kent and Angie, a program for developers who want to do real work with AI agents.

Claire Vo

Product leader and host of How I AI. She also runs ChatPRD and shares practical, screen-share-based AI workflows.

Notable Quotes

"It's not a chatbot anymore." (John Lindquist)

"Jev is a router, love it. Very fast router." (Claire Vo)

"Jev unlocks efficient inefficiency." (Claire Vo)

"It feels like the smartest function." (Claire Vo)