Hamilton Ulmer shipped prompt_jev() as MotherDuck SQL
Classification moves into the WHERE clause, with speed and cost numbers that are still the vendor's own.
Hamilton Ulmer launched prompt_jev(), a SQL function that runs Jev classification inside MotherDuck. It is live now, and the pitch for analytics people is that labeling and scoring stop being batch jobs you schedule and become something you do inline, including filtering on meaning directly in a WHERE clause during exploratory work.
it ran at 50x the speed and 1% the cost of comparable frontier models, with similar or better accuracy
The numbers come from MotherDuck. On a 100k row classification job, MotherDuck reported 40 seconds and $0.50 with prompt_jev(), against 32 minutes and $37 for the LLM it compared against, at what it calls frontier-LLM accuracy. Ulmer's framing of the same test set is roughly 50x the speed and 1% the cost of comparable frontier models with similar or better accuracy. Neither post names the specific frontier model, the classification task, or how accuracy was scored.
What is actually new here
The integration itself, more than the speed. Ulmer had a Jev plus DuckDB example running before this, and he was blunt about its quality, calling his original vibecoded extension excruciatingly inefficient and saying the reworked version was at least 20x to 40x faster, often more. That rewrite landed a day before the launch. So the path here was a rough community extension, a rewrite, then a first party SQL function.
The WHERE clause detail is the part worth sitting with. If a classifier is cheap and fast enough to put in a predicate, the shape of an analytics query changes, because you are no longer materializing a labeled column in advance and hoping your label taxonomy does not move. Ulmer's post explicitly calls out rerunning when your labels change as one of the workflows this makes affordable.
For people building on it
These are the vendor's own tests on the vendor's own workload, published alongside the product launch. The 50x and 1% figures are internal comparisons, not an independent eval, and nobody outside MotherDuck has reproduced them. Treat them as a claim about one classification job until someone else posts a run.
The cost figure is also the part most likely to move on you. $0.50 for 100k rows is the number for whatever those rows looked like, and classification cost scales with input length, so a table of short strings and a table of support tickets will not land in the same place. If you are sizing a bill, run your own 100k rows before you promise anyone a 99% saving. The writeup and tests are linked from Ulmer's launch post if you want to see what was measured.
my original vibecoded extension excruciatingly inefficient