Thirteen days is not much. Jev launched in mid-September. On October 1, Cloudflare released Clef, a model of the same kind with open weights and an API it says is compatible with Jev’s.

If you picked Jev last month to classify tickets or route requests, you now have an alternative. I am not telling you to switch. I am telling you to look at what switching would cost, because that is what this week exposed.

This is the follow-up to my post on Jev.

How Clef works

Cloudflare took a frozen Qwen model (Qwen3.8-27B for Clef, Qwen3.5-9B for Clef-flash) and added light adapters. Their announcement describes one read-through pass (the prefill), after which a small schema layer scores every valid answer at once. No text token is ever generated.

Think of a multiple-choice exam. You are not asking the model to write an essay. You are asking it to tick a box and say how sure it is.

The numbers, and who ran them

All of these come from Cloudflare, run on the Jev Decision Index, a test suite TypeSafe created. Across 43 benchmarks, the median decision took 209.3 ms for Clef and 38.8 ms for Clef-flash. Jev took 524.1 ms. That is about 2.5 times and about 13 times faster.

On accuracy, Clef scored 94.20% on BANKING77 against Jev’s 79.74%. Clef-flash scored 98.76% on BFCL against 95.75%. Jev won When2Call, 80.97% to 72.37%.

The Register adds three things the announcement does not stress. Cloudflare concedes Jev wins on agent-trace observability. Clef costs $0.24 per million tokens against Jev’s $0.042. And the weights are open, but Cloudflare confirmed to the paper that the training data is not public.

So nobody won outright. Which one fits depends on your task, and the only way to find out is to measure on your data.

The swap can be one line

Take pg-jev, the Postgres extension that exposes Jev as SQL functions: jev(), jev_prob(), jev_choice() and jev_score(). The service address is a configuration setting, jev.api_url, which defaults to TypeSafe’s endpoint. The README itself warns that row contents are sent to a third-party API.

Cloudflare says Clef is “fully API-compatible, so you can make the swap extremely easily.” In principle, pointing that setting at a Clef server would be the whole technical job. I have not tried it, so read that as my inference, not a result.

That is the shape you want: the vendor as a configuration value.

Compatible is not identical

There is a catch, and it is my reasoning, not a measurement. Suppose your code hands a case to a person whenever confidence falls below 0.7. That 0.7 was calibrated on Jev’s probabilities. Another model may give 0.7 to cases Jev scored at 0.5. Same format, different scale.

A compatible API therefore covers half of the swap. Revalidation is the other half.

What to pin down on your side

Three things, and none depends on which model you choose.

The contract comes first. Define in your own code the type of what you expect: one option from a closed list, plus a probability. The vendor hides behind a single function.

type Decision<T extends string> = { choice: T; probs: Record<T, number> };

interface Decider {
  decide<T extends string>(state: string, question: string, options: T[]): Promise<Decision<T>>;
}

Next, a set of test cases. Real cases from your operation with the correct answer already known, written by the people who run the work and not by the vendor. With that in hand, comparing Jev, Clef-flash and whatever ships next month takes an afternoon. Without it, it takes a debate.

Last, the thresholds. Store them as per-model configuration and recalibrate whenever you switch. They never live inside the code.

If your AI architecture lacks those three pieces, the model you chose in September is already part of your system rather than a component of it. In an enterprise architecture review, that would be my first test: swap the model in a staging environment and see how much breaks.

Measure what it would cost you to change models