Try a live demo of this fuzzy reference parser or download the code to run it yourself.
About Jev
Jev, released last month, represents a new kind of AI that’s fast, cheap, and smart enough to integrate into interactive workflows. Unlike frontier LLMs that can take multiple seconds to respond to a request, Jev responds in milliseconds and costs fractions of a penny. That speed comes with tradeoffs: rather than generate text, it’s designed to answer specific questions. It’s useful when you want to assess data at scale with specific questions that need basic intelligence—for example, extracting Bible references from text when those references don’t follow predefined patterns.
How Jev parses references smartly
Consider the text “John 3:16. Read verse 17.” You and I know that “verse 17” here means John 3:17. But it’s somewhat harder for traditional parser code to understand that. In this simple example, you could write a heuristic to decide that “verse 17” here is almost certainly John 3:17.
But imagine a more complex case: “John 3:16 connects to 1:1. But you really need to understand v17 to understand it.” Here you’d need some complex heuristics to figure out whether “v17” refers to 1:17 or 3:17. It’s possible to do—you can imagine creating complex sets of parser rules that make good guesses, using statistical co-occurrence data, or training a machine-learning model to figure it out.
Instead, now Jev can decide (spending 0.1 cents in about a second) that “v17” is 94% likely to refer to 3:17.
Jev considers questions in parallel to speed up computation. The parsing flow for this example needs four sequential round trips:
- Identify potential matching text segments (400ms).
- Choose books (200ms).
- Choose chapters and verses (200ms).
- Validate responses (200ms).
There’s a decent amount of complexity (or, as Sol 6.1 calls it, “speculative execution”) under the hood to balance cost and latency, but that’s the basic idea. You might think that steps 2 and 3 could be combined to save some latency. Doing so improves latency by 10% but doubles the dollar cost, which wasn’t a good tradeoff for me.
Jev correctly handles the “she is 2 cool” problem described in the parser’s readme, where “is 2” gets parsed as “Isaiah 2” under the default settings. Jev is smart enough to recognize context and to reject this naively plausible text.
It also handles references in non-English text. I doubt it supports the hundreds of languages that the parser understands, though I only tested a handful of major languages.
Comparing models
With so many model providers jumping on the Jev bandwagon, I benchmarked several different models (Cloudflare’s Clef, OpenAI’s Luna Decisions API, and Microsoft’s Decision-1), and Jev consistently won. All the others took much longer (45%-400% longer) than Jev and/or were much less accurate (about 40% pass rate, compared to Jev’s 92% on about 200 tests). Clef (not Omni) came closest, with a 77% pass rate. OpenAI’s Decisions API flat-out refused to return answers for half the test suite because of technical limitations in their current approach.
How you can use it
I’ve added this logic as an experimental plugin to my Bible Passage Reference Parser on Github. If you have OpenRouter or TypeSafe credits, you can try it out locally.
Alternately, you can try it interactively on a demo page.
The code (written by GPT 6.1 Sol) went through a lot of iterations at my direction to try to find the best balance of speed, cost, and accuracy. I don’t know that this approach actually hits the best balance of the three; conceptually, I’d prefer to do fewer server round trips. Jev-style models are so new that it’s hard to know what the best practices are.
It returns probabilities rather than certainties; the above sentence, for example, returns a 94% probability that “v17” refers to John 3:17. It returns all alternate readings it thinks are possible, along with their probabilities, so that you can decide what to do with them.
It actually returns two separate probabilities: (1) How likely is it that the text is a Bible reference at all? (2) If it is a Bible reference, what does it refer to?
In terms of calibration, which is a bit tricky to measure, Jev’s predicted probability matched its accuracy closely at scores of 0.8 and higher; below that, it vastly overestimated the probability of a citation: between 0.7 and 0.799, its mean predicted probability was 0.75, but the true citation rate was only 0.2. So, in my testing, there’s an abrupt change at 0.8.
It parses around 500 bytes per second, about three orders of magnitude slower than the local-only parser. That latency, plus the small-but-real financial cost, means that you should consider whether this added intelligence is right for your use case.
Why?
The deterministic parser is designed for interactive Bible applications, to handle text from users and convert it into structured input for a Bible application to do something with. It can work for other applications (such as scanning long content for Bible references), but it isn’t optimized for them (mostly because heuristics are both language-specific and add substantial code complexity).
A sprinkle of Jev extends this base functionality to a much wider array of use cases at a reasonable cost. For example, I estimate that parsing book-length content (80,000 words) for Bible references would cost around $10 if used naively (for example, to manage cost, maybe you could skip paragraphs without numbers in them).
Jev is a new way to think about applying AI to everyday problems. It’s good, fast, and cheap—which means it adds new capabilities to otherwise deterministic logic. TypeSafe’s description of Jev as “smart if-statements” fits well what it’s doing here: replacing hand-tuned heuristics with smatters of intelligence.