The Short Answer
TypeSafe AI announced Jev on September 15, 2026: a decision model that returns typed, scored options instead of text, priced at $0.042 per million input tokens with output unmetered. It is not the first model built to judge — OpenAI's CriticGPT and Prometheus 2 both shipped in 2024. The enterprise question is who owns the rubric, and with ibl.ai you own all the code and the data.
A model that writes your code is a supplier. A model that decides whether your code is acceptable is a policy.
What is Jev, and is it really the first model built to judge rather than generate?
Jev is a decision model. It takes unstructured input and returns a typed structured value — an option, a score, a calibrated probability — instead of generating a string you then have to parse.
TypeSafe AI, co-founded by former OpenAI researcher Diogo Almeida, announced it in waitlisted early access and calls it the first of a class it names System One Models. The Register reported the company had raised $40 million before launch.
The "first model for evaluation, not generation" line circulating with the launch is wrong, and TypeSafe does not make it. Its claim is the narrower one: first System One Model.
Models built to judge rather than write have a documented history. OpenAI published LLM Critics Help Catch LLM Bugs on June 28, 2024 — the CriticGPT work, a critic model trained to find bugs in code, whose critiques were preferred over human-written ones in 63% of cases.
Prometheus 2, an open-source language model specialized in evaluating other language models, was submitted May 2, 2024. Reward models — which score rather than write — are older still, and are the scoring half of RLHF.
What is genuinely new in Jev is the shape, not the job: no autoregressive decoding at all, so a judgment arrives as a distribution over a type you defined.
What does Jev actually cost, and what does "193× faster" measure?
The pricing is unusual enough to be worth restating in the vendor's own units. Jev costs $0.042 per million input tokens, and output tokens are unmetered — InfoWorld describes them as "too cheap to meter."
Stated per billion tokens, that is $42 in, nothing out. There are no output tokens to bill because there is no decoding step to bill for.
The speed claim needs more care than the price does. TypeSafe advertises 40×–200× faster with end-to-end response times of 70–500 ms against several seconds for the frontier LLMs it tested.
The specific 193.6× faster / 444.6× cheaper figures are the peak of that range, and TypeSafe is explicit about where they come from: "we expect that these are on the higher end of real world gains."
Read the evaluation design, because it decides how much the number means.
TypeSafe's workflow evaluations use "the average of GPT-6 Astra and Fable 5.1 as the reference answer" — not human ground-truth labels — and the workflows were written by TypeSafe's own model-capabilities team, which the company notes leaves room for bias.
So the benchmark measures agreement with two other models' averaged opinions, on tasks chosen by the vendor.
That is a reasonable thing to publish and TypeSafe discloses it clearly. It is not the same as accuracy on your data, and an independent check on your own workloads is the only thing that is.
Was Jev deployed in enterprise code review within 24 hours?
Not in any form that a buyer should count. The launch is waitlisted early access, and neither TypeSafe's own post nor the InfoWorld or Register coverage names a customer or an enterprise deployment.
What does exist, within days of launch, is community work: jev-review, an MIT-licensed open-source project by an individual developer that scores Git diffs for correctness, security, reliability, compatibility and test coverage and routes them to reviewers.
Its own README calls it "an experiment."
That is a real signal, but about a different thing. It says the integration surface is small enough that one person can wire a judge into a review pipeline over a weekend. It does not say a regulated enterprise put one into production in a day.
The distinction matters because the hard part of deploying a judge is never the API call. It is agreeing on what "acceptable" means and being able to defend that definition later.
Why does a judge model matter more to an enterprise than another code generator?
Because generation has commoditized and judgment has not. Code assistants are now a crowded market of near-substitutes, and the switching cost between them keeps falling — which is the same pressure pushing coding agents out of the IDE and into standalone services.
Judgment is where the differentiation moved. Once a machine writes the first draft of everything, the scarce asset is a reliable, fast, cheap way to decide which drafts pass.
And the volume is the point. A judge that costs $0.042 per million input tokens and answers in under half a second can run on every pull request, every agent step, every outbound support reply — not on a sample.
That changes what the judge is. At sampling volumes it is a QA tool. At every-event volumes it is the control that determines what ships, and that is a governance object.
Who should own the rubric a judge model scores your work against?
You should, and this is the part of the launch news with the longest half-life.
A judge model does not have generic taste.
It has whatever rubric it was trained or prompted with: what counts as a security finding, how severe a missing test is, which compliance flags block a merge. That rubric is your organization's standards written down in a form a machine applies thousands of times a day.
Three consequences follow, and all three are ownership questions.
A rubric is a versioned artifact. If it changes, the same pull request gets a different verdict. Without version history you cannot explain why last quarter's review passed something this quarter's rejects.
A rubric needs regression tests. The eval-suite-first discipline that applies to agents applies with more force to the thing evaluating them — the same argument as measuring agent performance with real frameworks rather than vibes.
A rubric you cannot read is a standard you do not control. If your definition of "acceptable code" lives inside a hosted model you do not run, your quality bar is a vendor's roadmap item.
None of this is an argument against Jev. It is an argument that the judging layer belongs in the same category as your access-control policy: inspectable, testable, and yours.
How does ibl.ai let you own the judge and its rubric?
With ibl.ai you own all the code and the data. The same eval-suite-first discipline is how ibl.ai builds Memorare, its truth-seeking language model program: the tests exist before the model does.
The platform runs inside your own perimeter with full source code under a perpetual license, is model-agnostic across any LLM — so a specialized decision model can sit beside a frontier model in the same pipeline and either can be swapped out — is usage-based with no per-seat pricing, and you can deploy anywhere, from your own cloud to on-premise, GovCloud, or a fully air-gapped network.
Because the orchestration layer is yours, the rubric is a file in your repository rather than a setting in someone's console. Role-based access control and audit logging sit beneath every call, so who changed a scoring policy and when is a query, not a support ticket.
1.6M+ users across 400+ organizations run the platform this way, including NVIDIA, MIT, and Syracuse University.
ibl.ai is family-owned and operated from New York, NY.
Related reading: AI agent evaluation: frameworks for measuring agent performance — the discipline a judge model has to be held to · Cline's desktop app turns the coding agent into a service — why generation keeps commoditizing.
Sources: product description, pricing, the 193.6×/444.6× figures and the evaluation methodology from TypeSafe's launch post; pricing and latency also via InfoWorld; the $40M funding and launch coverage from The Register; prior evaluator models from LLM Critics Help Catch LLM Bugs and Prometheus 2; the community code-review project at jev-review.