vLLM contributor Matt Mastracci opened a pull request that turns Google's DiffusionGemma into an open-source version of TypeSafe AI's proprietary Jev — a System One Model that returns calibrated, structured decisions from a single parallel diffusion pass instead of generating text token by token. His own framing: "We have Jev at home." Early live evals comparing the two directly show them roughly tied on accuracy, with the open-source version running on a single DGX Spark. It's a genuine, detailed piece of engineering — a real PR, a real code review surfacing real bugs, and a real head-to-head comparison — not just a demo claim.
TL;DR
| Question | Answer |
|---|---|
| What is it? | A vLLM patch giving DiffusionGemma Jev-like structured, calibrated decision output |
| Who built it? | Matt Mastracci, via vLLM PR #57250 |
| How does it compare to Jev? | Roughly tied on accuracy per live evals; not faster (API vs. local DGX Spark) |
| How does it work? | A fixed "diffusion canvas" denoised in one step, with logprobs read at specific answer slots |
| Capacity | Up to 85 questions in a single canvas at 3 tokens per question |
| Production-ready? | No — explicit WIP, unresolved merge conflicts, real bugs flagged in code review |
| Cheaper alternative mentioned | GLiNER2.5, reportedly 36x cheaper than Jev for a specific Browser Use task, runs locally |
What a System One Model actually is, and why this matters
TypeSafe AI's Jev, which explainx.ai covered at launch, established a real category: a System One Model returns a typed decision — a choice from a fixed set, a numeric score, a yes/no — computed as a probability over every possible answer at once, rather than sampled one token at a time like a conventional LLM. That architecture is the source of both Jev's speed advantage and its inability to generate free-form text — its output space is small and enumerated in advance, so it can compute a full probability distribution over every possible answer in roughly one forward pass.
Mastracci's PR shows the same capability isn't unique to Jev's specific proprietary architecture — it's achievable with an open, publicly available diffusion model (DiffusionGemma, Google's diffusion variant of Gemma 4) plus the right serving-layer changes to vLLM, one of the most widely used open-source LLM inference engines. That's a meaningfully different claim than "someone built a Jev competitor" — it's closer to "the underlying technique Jev demonstrated is generalizable and replicable by the open-source community," which has real implications for how defensible TypeSafe's specific product advantage actually is.
How the diffusion canvas actually works
The mechanism, per the PR's own description: fix a set of token positions on a "canvas" — a sequence the diffusion model denoises in a single parallel step rather than generating sequentially. A structured question format gets laid out in the system prompt (each question listing its allowed single-token answer labels), and the model fills in each answer slot simultaneously. Reading the logprobs at each specific answer position — rather than hoping the right answer token happens to rank in the model's default top-k output — gives both the model's chosen answer and a genuine confidence measure derived from those logprobs, which the PR uses to decide whether to re-sample a question when confidence is low (an "auto" policy: read once, and only re-read if the first read's entropy is too high).
The scale claim is concrete: because each question only needs about three tokens (an index, an answer placeholder, and a separator), the PR reports being able to pack up to 85 questions into a single diffusion canvas — a real capacity figure a developer can plan around, not just a proof of concept.
The head-to-head comparison
Mastracci ran live evals specifically comparing Jev against "DiffusionGemma as Jev" and posted the results directly: "Is Jev faster than DiffusionGemma? No ❌ (API vs DGX Spark). Is Jev smarter than DiffusionGemma? No ❌ (they're roughly tied!)." That's a genuinely fair framing — the speed comparison isn't apples to apples (a hosted API call versus local hardware you already own), but the accuracy comparison being roughly tied is the more interesting and harder-to-dismiss result, since it directly tests whether the open, replicable approach loses meaningful quality compared to TypeSafe's proprietary one. Published test results from the PR itself back this up with concrete numbers: 10/10 accuracy on programming-language classification, 9/10 on human-language classification, and strong (though not perfect) accuracy on visual grounding tasks like color, quadrant, and presence detection when tested against DiffusionGemma's multimodal vision capabilities directly.
What real code review looks like
This PR is worth highlighting specifically because the public review process is unusually substantive — a useful example of what rigorous open-source review actually looks like, not just a demo getting upvotes. Reviewer kvnloo flagged several concrete, credible issues: no regression test actually exercises the specific race condition (two concurrent requests corrupting each other's state) the PR claims to fix; the included example server spawns unbounded threads per request with no authentication or caps, meaning a single malicious or malformed request could exhaust the server; validation logic silently mutates the very parameters it's supposed to be checking, which the reviewer calls "a footgun"; and a step-count cap gets silently clamped to a maximum rather than rejected or logged when a caller requests something invalid, which could produce confusing, hard-to-debug behavior. The reviewer also specifically praised what the PR got right — accurately fixing the underlying race condition and handling slot-reuse memory hygiene carefully — which is what makes this genuine engineering critique rather than dismissive nitpicking. As of publication, the PR still has unresolved merge conflicts and a failing pre-commit check, confirming it's not yet ready to merge.
The bigger question this PR raises about Jev's actual moat
Stepping back from the specific technical details, this PR raises a genuinely important business question for anyone evaluating whether to build on TypeSafe's proprietary Jev long-term versus an open alternative: if a single vLLM contributor working largely alone can build a roughly-comparable-accuracy System One Model on top of an existing open model in what appears to be a matter of days, how defensible is Jev's specific technical advantage actually likely to be over time? The honest answer is genuinely uncertain in both directions. It's possible Jev's proprietary training data, its specific calibration methodology, or details of its architecture that aren't public deliver meaningfully better real-world reliability than this early-stage open patch — TypeSafe's own published comparisons (88.3% on the same benchmark set, versus this PR's roughly-tied results at smaller scale) suggest there's still a real gap at the top end. It's equally possible that, as has happened repeatedly with other proprietary AI capabilities this year, the open-source community catches up quickly once the underlying technique is understood, and Jev's practical moat ends up being more about polish, hosting convenience, and support than an unreplicable technical advantage. Either way, this PR is worth treating as a genuine data point in that ongoing question, not just a curiosity — the kind of open replication effort that tends to compress a proprietary technology's pricing power faster than most vendors would like.
Honest limitations
- Explicitly a work in progress — unresolved merge conflicts, a failing required check, and multiple unaddressed review comments as of publication.
- The accuracy comparison against Jev is one contributor's own informal eval, not a controlled, published benchmark with disclosed methodology.
- Real security and correctness issues remain open per the code review — an unauthenticated, unbounded-thread example server and an unfixed race-condition test gap, specifically.
- This requires real GPU hardware to run (a DGX Spark in the demonstrated case) — it's open source, but not free to operate at any meaningful scale.
What this means for builders
If you're evaluating TypeSafe's Jev or considering the System One Model pattern for structured, high-volume decisions (ticket routing, content moderation, guardrailing another model's output), this PR is worth tracking as a genuine open-source alternative rather than dismissing it as a toy clone — the underlying technique appears real and replicable, and roughly matching Jev's accuracy on a general-purpose open model is a meaningful result even in an unpolished, pre-merge state. The GLiNER2.5 comparison raised in the discussion is also worth a look for narrower, specifically-scoped tasks (like browser-use element classification), where a lighter, non-diffusion approach may be the more cost-effective choice than either Jev or this diffusion-based alternative.
Related on explainx.ai
- OpenJev: try Jev's trick yourself, free, in your browser — a second, independent replication effort with its own published (and less flattering) numbers
- Jev by TypeSafe AI: a 200x faster structured-output model
- What is a System One Model? AI explained
- Structured output and JSON mode: a prompting guide
- Google DiffusionGemma: 4x faster text generation
- IFM Uno: a lossless diffusion adapter for LLM speedup
- Dictionary: System One Model
- Primary source: vLLM PR #57250 · Matt Mastracci on X
This post is sourced to the public vLLM pull request #57250 and Matt Mastracci's own X posts, as of September 19, 2026. The pull request is explicitly a work in progress with open review comments and unresolved merge conflicts; benchmark figures and the accuracy comparison against Jev are the contributor's own reported, informal results.