Cloudflares Clef beat Jev on its own turf

When Cloudflare released Clef on October 1, its launch post carried a table of ten public benchmarks, seven of them led by a Clef model. The Hacker News thread passed 600 points in a day, and one of the first replies was six words long: “Public benchmarks are easy to cheat” (Traictory, Hacker News).

Fair. So we ran the test nobody could have trained for. Construct’s agent has about 40 small decisions written for a decision model, and every one of them was written around Jev: the prompts, the questions, and the thresholds, all built against Jev over the last two weeks. That is Jev’s home turf. We pointed the same requests at Clef and Clef-flash without changing a line, and scored all three against labelled cases.

Clef is Cloudflare’s open-weight decision model, a drop-in alternative to TypeSafe’s Jev. On 117 labelled cases across five of our production decisions, Clef reached the right outcome on 92.3% of calls using thresholds set for Jev, against 88.6% for Jev and 82.1% for Clef-flash. Both Clef models returned the identical probability on every repeated call, and Jev did not.

We build Construct, an AI employee with its own computer. Every number below comes from our own runs on October 4, 2026 (UTC): 117 cases, three calls each, three models, 1,053 calls in the main run, plus about 800 more in follow-up controls. Facts about the models themselves come from Cloudflare’s and TypeSafe’s documentation, checked the same day. The full method, confidence intervals and per-case results are in the paper: Compatible APIs, Incompatible Thresholds: A Drop-In Replacement Study of Clef and Jev on Decision Specifications from a Production Agent (PDF, 13 pages).

• Accuracy, drop-in: Clef 92.3%, Jev 88.6%, Clef-flash 82.1%, all on thresholds set for Jev. The gap between Clef and Jev is not statistically significant.
• Accuracy, own thresholds: Clef 93.2%, Jev 90.9%, Clef-flash 90.6%, with each threshold chosen on held-out cases.
• Repeatability: Clef and Clef-flash gave the same probability on all 351 calls each. The probability Jev’s decisions act on moved by up to 0.10, and 2 cases changed verdict.
• Code changed to swap models: one string.
• Failed calls: 0 of 1,053.
• Cost: $23 per million decisions on Jev, $35 on Clef-flash, $93 on Clef. The main run cost about five cents.

What are Clef and Clef-flash?

Clef and Clef-flash are decision models from Cloudflare: you send a state and a set of typed questions, and they return a probability for each allowed answer instead of generating text. Clef is a 27 billion parameter model built on Qwen3.8, and Clef-flash is a 9 billion parameter model built on Qwen3.5. Both are released under Apache 2.0 with weights on Hugging Face, both run on Workers AI, and both accept the same request format as Jev (Cloudflare).

If decision models are new to you: they are the fast, cheap judgment calls around a language model. Is this the same person? Does this email need a reply? Should this tool call wait for a human? TypeSafe calls the category System One models, after Kahneman’s fast, intuitive System 1. Our first post on Jev explains the idea and how we put one inside an AI agent’s memory.

Jev, Clef and Clef-flash compared, October 2026

A side-by-side comparison of the three classifier models available on Workers AI: TypeSafe AI’s Jev 1.13 and Cloudflare’s Clef and Clef-flash. All three handle the same question types (Choice, Score and Noul) and share a 64k token context window, and none of them charge for output tokens. The differences show up in openness and input support. Jev is closed and doesn’t publish its size, while both Clef models ship open weights under Apache 2.0, at 27B and 9B parameters respectively, and can also take images alongside text and JSON. On price, Jev is the cheapest at $0.042 per million input tokens, with Clef-flash at $0.09 and the full Clef model at $0.24. The last row lists the model ID you’d use to call each one from Workers AI.

Two details in that table matter later. Clef reads images, which Jev does not today. And the prices are per input token, so the model that counts fewer tokens for the same request closes some of the gap.

How we benchmarked Clef against Jev

We did not write a new test for Clef. We took five decisions that already exist in Construct’s code and ran each one’s real request builder and real interpreter, the same functions production calls.

The five production decisions in the benchmark

The five decisions the agent currently hands off to a classifier, along with the question each one answers, how many test cases we’ve built for it, and the confidence threshold it runs at today. Entity match checks whether a newly mentioned person, project or company is someone the agent already knows, and has the largest test set at 30 cases. Email triage sorts incoming mail into newsletters, receipts, spam, requests or things to keep. The memory extract gate decides whether a conversation contains anything worth saving, and it runs at a deliberately low threshold of 0.05 so that very little slips past it. Notification priority judges whether an automation notice is worth interrupting the user with a toast, and tool-call risk flags tool calls that should pause for the user’s approval before running.

Entity match is live in production. The other four are built and switched off, waiting on shadow data. Their thresholds were set by judgment with Jev in mind and have never been fitted to data, for Jev or anything else.

Swapping the model was the least interesting part of the work. This is the whole change:

// Before
await env.AI.run("typesafe/jev", { state, questions }, options);

// After
await env.AI.run("@cf/cloudflare/clef", { state, questions }, options);

Cloudflare says Clef is “fully Jev-API compatible”. On our requests that held: Choice, Score and Noul questions, JSON state, and the response shape all worked unchanged, and all 702 Clef calls returned valid answers.

The rest of the method, briefly:

• Cases: 117, all synthetic, weighted toward the edges of each decision. We drafted and labelled them with an AI assistant (Claude) before any of the three models saw them. No label came from Jev or Clef, and the labels have not yet been independently reviewed by a second person.
• Runs: each case three times per model, one call at a time, models interleaved so they shared the same network conditions, with the gateway cache skipped.
• Scoring: a call is correct when the production interpreter reaches the labelled outcome at the production threshold. We also report each model’s best threshold, found on the same cases, which flatters all three equally.
• Route: Cloudflare’s REST API through our AI Gateway, from a laptop. Fine for accuracy. Wrong for latency, which gets its own section.

Clef vs Jev accuracy: the results

Accuracy for each of the three models across all five production decisions, measured as the share of 351 calls that reached the correct outcome (117 synthetic cases run three times per model). The left group shows what happens if you swap a model straight into the current setup without retuning, keeping the thresholds that were originally set for Jev. In that drop-in case Clef scores 92.3% and Jev scores 88.6%, although Clef’s 3.7-point lead is small enough to fall within the noise of a 117-case test set. Clef-flash struggles most here at 82.1%, which suggests its confidence scores sit on a different scale from Jev’s rather than that it judges the cases worse. The right group lets each model use whichever threshold works best for it, and every model improves: Jev rises to 93.7%, Clef to 96.6% and Clef-flash to 94.9%. Clef-flash gains the most from retuning, close to 13 points, and ends up ahead of Jev. These right-hand numbers are an in-sample upper bound, since the thresholds were picked on the same cases they’re scored against, so real-world accuracy after retuning will likely land a little lower. Note that the vertical axis starts at 50%, which makes the gaps look larger than they are. Data comes from Construct’s bake-off on 4 October 2026.

Overall accuracy across five production decisions, 351 calls per model. Left: the thresholds configured today, set for Jev. Right: each model’s own best threshold, found in-sample.

With no retuning at all, Clef had the highest score of the three, and the highest or equal-highest on four of the five decisions, on thresholds that were set for a different model.

Accuracy by decision at the production threshold, with accuracy at each model’s own best threshold in brackets

The same bake-off broken down by decision, showing where each model wins and loses. The main figure in each cell is accuracy at the thresholds originally set for Jev, and the figure in parentheses is accuracy once that model uses its own best threshold. Bold marks the top score in each row at Jev’s thresholds. Clef’s overall lead comes mostly from entity match, where it scores 86.7% against Jev’s 72.2%, and from notification priority, where it gets every case right. Jev holds its own on email triage at 93.3% and ties Clef on tool-call risk and the memory extract gate. Clef-flash trails on almost every decision at Jev’s thresholds, with its weakest showing on notification priority at 75.0%, but retuning lifts it to 100% on three of the five decisions, including tool-call risk, where it ends up ahead of both other models. Entity match is the hardest decision for every model even after tuning, which makes it the most likely place to look for further gains. As with the overall chart, the parenthesised figures are in-sample, and each decision has only 15 to 30 cases, so a single case can move a score by three to seven points.

Drop-in accuracy for each model on each of the five decisions, using the thresholds originally configured for Jev, which are listed under each decision alongside its case count. This is the chart that shows where the overall numbers come from. Entity match is the clearest win for Clef, which reaches 87% while Jev manages 72%, and it’s also the one decision where Clef-flash beats Jev at 80%. Email triage tips the other way, with Jev on top at 93% and Clef-flash falling to 73%. The memory extract gate is close to solved for everyone, with Jev and Clef both at 100% and Clef-flash at 96%. Notification priority shows the biggest spread on the chart, since Clef gets every case right, Jev reaches 96%, and Clef-flash drops to 75%. Tool-call risk is a tie between Jev and Clef at 88%, with Clef-flash a few points behind at 83%. Read together, the bars show that no single model wins every decision, and that Clef-flash’s weak overall score comes mainly from two decisions where Jev’s thresholds suit it badly. Each decision has between 15 and 30 cases, so one case can shift a bar by roughly three to seven points, and the vertical axis starts at 50%, which makes the gaps look wider than they are. Data comes from Construct’s bake-off on 4 October 2026.

Accuracy per decision at today’s thresholds. Jev keeps email triage. Clef takes entity matching and notification priority.

The honest size of this result: Clef leads Jev by 3.7 points on 117 cases, with a 95% interval of -1.1 to +8.8 points. That is not statistically significant, and we would not stretch it into “Clef beats Jev”. Three of the entity cases are ones our product resolves in code before any model is asked (identical names, and names that differ only in case). Jev did worst on exactly those, and without them the lead shrinks to 2.0 points (92.1% against 90.1%). What we can say is narrower and more useful. Cloudflare’s public numbers predicted Clef would be at least as good as Jev on decision tasks, and on private prompts it had never seen, written for its competitor, it was not measurably worse.

Jev deserves its due here too. It won email triage outright, it never made a wrong merge, and it was perfect on the extract gate. This is a close race between two good models.

Is Clef deterministic?

Yes, on everything we sent it. We called each model three times with the same request for all 117 cases. Clef returned the same probability, to four decimal places, on all 351 calls. So did Clef-flash. To rule out a cache, we sent the same requests again with changes that do not touch the model’s input (a unique query string, reformatted JSON, reordered keys): same answers, a cache miss on every response, and a new inference ID each time.

How consistent each model was when given exactly the same input three times in a row. Each bar shows the largest change, across all cases in a decision, in the probability that the decision acts on. Clef and Clef-flash returned identical probabilities on every repeat call for every decision, so their bars sit flat at zero. Jev’s scores moved between runs on all five decisions, by as little as 0.03 on the memory extract gate and as much as 0.10 on notification priority. Most of that drift didn’t matter in practice, since the score stayed on the same side of the threshold, but in two cases it was enough to flip Jev’s verdict from one run to the next. A swing of 0.10 is large next to thresholds like 0.85 for notifications or 0.80 for tool-call risk, which means a case sitting close to the line could get a toast or a confirmation prompt on one call and not on the next. For an agent that makes these calls quietly in the background, getting the same answer to the same question is a big part of why its behaviour feels predictable, and on this test the Clef models were fully repeatable while Jev was not. Data comes from Construct’s bake-off on 4 October 2026, with 117 synthetic cases run three times per model.

Largest change in probability between three identical calls. Clef and Clef-flash sit at zero on every decision.

The probability each Jev decision acts on moved between identical calls by up to 0.10, and two cases changed verdict from one call to the next. Across every probability Jev returned, the largest move was 0.16, and 100 of the 117 cases came back with at least one number different. TypeSafe describes Jev as returning “similar answers for similar inputs”, which is a promise of consistency, not determinism, and a wobble of this size is consistent. But a decision layer acts when a probability crosses a line, so any wobble means a case near the line is decided by which call you happened to make.

Cloudflare’s post explains why Clef behaves differently: the decision step is non-autoregressive, with choices derived directly from the model’s internal representations and no text sampled along the way. We can confirm the practical result. For anyone who has debugged an agent that did something different the second time, this is the finding that matters most, more than a few points of accuracy.

Jev’s scores moved under the same version name

This one surprised us. On September 20 we calibrated our live entity matcher on Jev. Real matches scored 0.71 to 0.82, everything else scored 0.34 or less, and we put the merge threshold at 0.70, in the gap.

Two weeks later we asked the same three calibration probes again.

Jev’s probability for the correct match on the three probes our live entity matcher was calibrated on, measured two weeks apart while the model was served under the same version identifier, jev-1.13.0. The hollow circles are single calls made on 20 September, when all three real matches scored above the 0.70 merge bar, shown as the dashed line: 0.71 for “Dr. Priya Shah” against “Priya Shah”, 0.76 for “Priya Shah” against itself, and 0.82 for “atlas migration” against “Atlas Migration”. The filled dots and diamonds are means of 20 calls each on 4 October, one set through Workers AI and one set on TypeSafe’s own API with the version pinned, and the shaded band behind them covers the full range of those 40 calls. Every probe had moved well below the bar. The Dr. Priya Shah probe fell to 0.47 and 0.46, the identical-name probe fell to 0.42 and 0.43, and the Atlas probe fell to 0.60 and 0.61, and even the highest single October call, at 0.66, stayed under 0.70. The two routes land almost on top of each other, which points to a change in the model and rules out a quirk of how Workers AI serves it. Since the version string never changed, nothing would have warned us, and in production these matches would simply have stopped merging. This doesn’t mean Jev got worse across the board, only that a threshold calibrated on one day can quietly stop holding on another. The September baseline is one call per probe, so it’s less certain than the October means.

Jev’s probability for the correct match on our three calibration probes: one call on September 20, and the mean of 20 calls on October 4 through Workers AI and on TypeSafe’s own API with the version pinned. All were served as jev-1.13.0.

All three now fall under the bar. To be sure this was not a noisy afternoon, we asked each probe 20 more times: none of the 60 calls reached 0.70, and the highest was 0.66. Clef, asked the same 20 times, returned the identical number every time. The served version was `jev-1.13.0` both times, so the alarm we built to catch version changes stayed quiet. On this benchmark Jev still never merged two different people, which is the expensive mistake, but it made only 44% of the merges it should have. In production, a missed merge becomes a duplicate.

Get Ankush Singh’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

We do not know why the scores moved. Our first suspect was our own route: we call Jev through Cloudflare’s Workers AI, which cannot pin a version. So we repeated everything against TypeSafe’s own API with the version pinned to `jev-1.13.0`. Same result: none of 60 calls reached 0.70, and Jev’s answers still varied between identical calls on 104 of 117 cases. The route is not the cause. Three probes are still three probes, and our September baseline is one call each. We are not claiming Jev got worse in general. The lesson is about our own setup: a threshold is only as stable as the model under it, and a version string is not a guarantee. Open weights can change that, if you use them: a model you pin or host yourself cannot move under its thresholds. The hosted Clef alias we tested carries no version either, so we will re-ask these same probes on Clef in two weeks.

Entity matching: where the three models differ most

Entity matching is the decision where a mistake is permanent. A wrong merge fuses two real people in the agent’s memory, so precision matters more than recall. AI agent memory covers what that memory holds and how you can correct it.

A closer look at entity matching, the decision where the models differed most, scored at the production merge bar of 0.70 on 15 pairs that should merge and 15 that should not. The left group is recall, the share of true matches each model actually merged, and the right group is precision, the share of merges that turned out to be correct. Precision matters most here, because a wrong merge folds two different people or projects into one record and can’t be undone. Jev never merged anything it shouldn’t have, scoring 100% on precision, but it got there by being far too cautious and merged only 44% of the real matches, which fits with the drift chart showing its scores for true matches falling below 0.70. Clef and Clef-flash both caught 80% of the real matches, but they paid for it differently. Clef’s merges were right 92% of the time, while Clef-flash’s were right only 80% of the time, so roughly one in five of its merges joined two things that should have stayed apart. The footnote points to an easy fix for Clef: raising its bar to 0.80 still gave it 10 of the 15 correct merges, well ahead of Jev, with no wrong merges at all on this set. With only 15 pairs on each side, a single case moves these numbers by several points, so the 0.80 result is a promising direction to test further and not yet a settled setting.

Entity matching at the production threshold of 0.70: 15 pairs that should merge and 15 that should not.

• Clef caught the aliases this decision exists for: “Jose Garcia Marquez” against the accented spelling at 0.98, “Stripe, Inc.” against “Stripe” at 0.98, “I.B.M.” against “IBM” at 0.99. Its one wrong merge was “Acme” into a lone “Acme Corporation” at 0.78, a case reasonable people would argue about.
• At a 0.80 threshold, Clef made 10 of 15 correct merges and no wrong ones. That is our starting point for shadow mode, not a recommendation: it was picked on these same 30 cases, and “Acme” against “Acme Corporation” sits at 0.78, just under it.
• Jev is not worse at telling people apart. Drop its threshold to 0.50 and it makes 64% of the correct merges, still with no wrong ones, close to Clef’s 67% at 0.80. Its problem at 0.70 is that its scores moved, not that it lost the ability to rank the pairs.
• Clef-flash is quick to say yes. It matched “Acme Labs Europe” to “Acme Labs” at 0.76 and the bare concept “pricing” to “pricing model” at 0.89. For a merge, that is too eager. For a gate that only skips work, it is fine.
• All three refused a one-letter surname typo, “Mendelsohn” against “Mendelson”. Good. Those can be two people.

Thresholds do not transfer between decision models

If you take one thing from this post into your own migration, take this. A threshold is a property of a model and a prompt together. Move the model and the threshold is wrong, even when the new model is better.

The three models are not far apart in ability. Asked to rank our cases from “should act” to “should not”, all three do it well: on the four decisions we could measure this way, the ranking score (AUROC) is 0.93 or higher for every model and a perfect 1.00 on two decisions. What differs is the number each model attaches to the same judgment.

The most accurate threshold per model on two decisions, against the configured threshold

The two decisions where the configured threshold sat furthest from where the models actually work best, comparing the production bar with the threshold that gave each model its highest accuracy on the test set. On tool-call risk, all three models do best with a much lower bar than the 0.80 in production, ranging from 0.49 for Jev down to 0.22 for Clef. In practice that means the models were giving genuinely risky tool calls scores well below 0.80, so the current setting let some of them run without stopping to ask the user first, and lowering the bar would make the agent pause on those calls as it should. Notification priority tells a different story. Clef’s best threshold is exactly the configured 0.85, which is why it already scored 100% on that decision without any retuning, while Jev and Clef-flash both work best much lower, at 0.60 and 0.61. It’s notable that Jev’s own best sits so far from a threshold that was originally set for Jev, which fits the drift shown earlier, where Jev’s scores moved down under the same version name. These best values are picked in-sample on 24 cases per decision, so each one is better read as a point inside a range of thresholds that perform about equally well, not a precise setting to copy straight into production.

Clef-flash shows the effect best. On Jev’s thresholds it scored 82.1%. With thresholds chosen for it on held-out cases it scored 90.6%, level with Jev’s 90.9% on the same footing, and Clef stayed ahead at 93.2%. The 9B model was never bad at these decisions. It was being read with another model’s ruler.

The thresholds in the table were found on the same cases they are scored on, which is why the bracketed figures in the results table (96.6%, 94.9%, 93.7%) run higher than the held-out ones. Treat them as a direction and not as settings. The practical rule is simple: swap the model in shadow, log probabilities for a week, and set the threshold from that.

How fast is Clef? What we could and could not measure

Cloudflare reports a median of 209 ms for Clef and 38.8 ms for Clef-flash, against 524 ms for Jev. We are not going to confirm or dispute those numbers, because our harness was the wrong instrument.

We called all three models through Cloudflare’s REST API from a laptop. The fastest call we saw for any model was 340 ms, and for every model the floor sat between 340 and 384 ms. That floor is the path: authentication, the public API, the gateway, and the round trip. You cannot see a 38 ms model through a 340 ms window.

Latency per call through the REST API from a laptop, 351 calls per model. Not a production measurement.

How long each model took to answer, from the fastest call through the median to the 95th percentile, which is the time that all but the slowest one in twenty calls came in under. At their best the three models are close, with the Clef models edging ahead at around 340 to 350 ms against Jev’s 384 ms. The differences show up as you move toward the slow end. Jev is the most consistent of the three, since its typical call takes 454 ms and even its slow calls finish within 591 ms. Clef-flash matches Jev on the median at 449 ms but has a much longer tail, with its slow calls stretching past a second. Clef is the slowest overall, about 200 ms behind the others on a typical call and taking more than twice as long as Jev on its slow ones, at 1,262 ms. For most of these decisions that hardly matters, because email triage, memory extraction and entity matching all run in the background where nobody is waiting. It matters more for tool-call risk, which sits directly between the agent and the action it’s about to take, so an extra half-second on a slow call is something a user could actually feel. Clef’s accuracy and consistency gains come with a real but modest cost in speed, mostly at the tail.

For transparency, those are the raw numbers. On this path Clef-flash matched Jev at the median, Clef was slower, and both Clef models had longer tails, three days after launch. None of that tells you what a Worker sees when it calls the model through the AI binding, next to the GPU, which is how we call it in production. That measurement is next, and we will publish it here.

What does Clef cost compared with Jev?

What each model would cost to make a million decisions, worked out by multiplying the average number of input tokens per call by each model’s list price per million input tokens. Output tokens are free on all three, so input is the whole bill. Jev is the cheapest at about $23 per million decisions, Clef-flash comes next at about $35, and Clef is the most expensive at about $93. The gap is smaller than the list prices alone would suggest. Clef costs 5.7 times as much as Jev per token, but its tokenizer counts the same request as 387 tokens where Jev counts 541, which is 28% fewer, so per call Clef works out to roughly four times Jev’s cost. Clef-flash shares Clef’s tokenizer and ends up only about one and a half times Jev’s cost. In absolute terms all three are cheap, since even Clef comes to less than a hundredth of a cent per decision, and moving from Jev to Clef adds about $70 for every million calls. Whether that’s worth paying depends on what it buys, which the earlier charts answer with higher accuracy, fewer wrong entity merges and identical answers on repeat calls, set against a slower tail on latency.

Cost per million decisions at list price, using the mean input tokens each model counted for our requests.

Clef’s list price is 5.7 times Jev’s, which is the first thing the Hacker News thread did arithmetic on. Two things soften that.

First, Clef counted 28% fewer tokens than Jev for the same request: 387 per call against 541. Per decision, the gap is about 4 times, not 5.7.

Second, look at the unit. A million Clef decisions cost $93. All 1,053 calls in this benchmark cost about five cents. An agent that makes a thousand decisions a day spends about nine cents a day on Clef and two on Jev, next to a language model bill many times that. If you run billions of decisions a day, price it carefully, and look at Clef-flash at $35 per million. For everyone else, accuracy and repeatability are worth more than the difference.

Clef vs Jev: which decision model should you use?

Which decision model fits which job, based on our benchmark and each vendor’s documentation

The broader field is moving fast. Besides Jev and Clef there are open decision models such as Laya, Kev and OpenDecider, and Cloudflare’s own table includes several of them. We have only tested the three in this post.

What we are switching, and why Cloudflare makes it easy

Construct already runs on Cloudflare: Workers, Durable Objects, AI Gateway, and Workers AI for the small models. How our agents get computers we mostly do not pay for describes that stack. So Clef is not a new vendor for us. It is a new model ID on a binding we already call.

• Entity matching goes to Clef in shadow first, starting at 0.80. Jev keeps deciding while Clef’s answers are recorded beside it. The threshold we ship will come from that data, and we switch only if real traffic agrees with this benchmark.
• Background decisions default to Clef, each with its own threshold measured in shadow.
• Interactive decisions wait for the latency test. If Clef-flash is as fast from a Worker as Cloudflare reports, it is the natural fit for anything a person is waiting on.
• Clef-flash stays away from anything that merges or deletes until it has its own thresholds.

There is a quieter benefit. In our Jev post we said that decisions which read your conversations or email “wait for the paperwork”, because sending that text to another provider is a privacy decision. A first-party Cloudflare model keeps that text on the platform that already runs the rest of Construct, which removes the main reason most of our decisions are still switched off.

We are also watching Cloudflare’s new fine-tuning work, which it calls Reinforcement Learning for Calibrated Decisions. Our decision layer already records the label, the probability and what the product did for every decision, with no user text. That is close to the dataset such a system wants.

Read next: We put Jev inside our AI employee

How to try Clef

• On Workers AI: call `@cf/cloudflare/clef` or `@cf/cloudflare/clef-flash` through the AI binding or the REST API. The request is a `state` plus a map of `questions`, the same as Jev.
• Coming from Jev: change the model ID and keep everything else. Then re-measure every threshold.
• Self-hosted: the weights are at `Cloudflare/clef` and `Cloudflare/clef-flash` on Hugging Face under Apache 2.0.
• Read the probabilities, not the `confidence` field. It means different things on Clef and Jev, and on Jev it changed meaning between our September and October runs. Read `probabilities` and both models behave the same.
• Pace a REST benchmark. Cloudflare’s REST API throttled our token at roughly 90 calls a minute. The Workers binding is the route for real traffic.

Where Construct fits

Construct is an AI employee with its own computer: a workspace filesystem, long-term memory, a schedule, email, and workflows you can read before you run them. Decision models make the small calls around the edges, such as whether a person your agent just read about is one it already knows. Planning and writing run on general-purpose language models.

Two boundaries, stated plainly. As of this post, Jev still makes the live entity-matching decision and Clef has only run in this benchmark; this page will say when that changes. And the other four decisions in this benchmark are built but switched off in production until shadow data supports them.

If decision models are new to you, start with we put Jev inside our AI employee. For why small, repeatable judgments matter so much in long tasks, read your agent has a half-life. And if the category itself is new, begin with what is an AI employee.

Originally published at construct.computer