Jev alternatives

SemIf

No new model — just read the option logits

Quick answer

SemIf is the right choice when you already host an open-weight model and want typed decisions without training anything. It reads option probabilities off the logits in one prefill — no output tokens, no JSON parsing, no retries. Measured agreement with Jev on an aligned 102-row subset is 0.845 against Jev’s 0.883, so it is a real but not equal reproduction.

SemIf trains nothing. It takes a frozen open-weight model you already host, declares your options, and reads their probabilities straight off the logits instead of letting the model write an answer. It is the clearest expression of the "reproduce the pattern, not the weights" school — and its methodology is the most careful of the small projects, because its README leaves the published-Jev column empty rather than guessing.

Read the logits

No new weights. Intercept the model right before it answers and read the probability of each option instead of letting it write.

Search aliases

SemIfsemifSemIFSemIf-OpenJevOpenJev (legacy name)

Key specs

Licence
MIT
Author
Theo Lee
Backbone
Frozen Qwen3.5-4B — nothing is fine-tuned
Size
~3.01 GB quantized (Q4 GGUF)
Latency
1.023 s for 21 binary criteria on an RTX 3090 · 5.21x faster than generating the same answers as JSON
Wire format
Its own fixture harness; not a /v1/systemone server
Install
See repository

SemIf against Jev

SemIf’s README is unusually disciplined: where it has no comparable Jev figure it prints a dash rather than an estimate. The agreement numbers below come from a 102-row subset that both systems answered.

SemIf against JevSemIfJev
Modal agreement with published Jev0.845 on a 102-row aligned subset0.883
Authored decision set0.8130.965
Output tokens per decision0 — probabilities are read, not written0
Training requiredNone; reuse a model you already serveClosed weights, RLCD-trained
Latency, 21 decisions1.023 s direct logits vs 5.332 s via generated JSONHosted API round trip

When SemIf is the right choice

Use SemIf when you already pay for GPU capacity to serve an open LLM and want to stop paying twice — once to run the model and once to have it write JSON you immediately parse back into a branch. Reusing one long state across many criteria pushed throughput from 2.33 to 20.03 decisions per second in the project’s own measurement, which is the whole argument in one number.

When to walk away

Do not expect a drop-in service: SemIf is a readout pattern with fixtures, not a `/v1/systemone` server, so integrating it means adopting its harness. Do not use it for questions that need real reasoning either — it reads the next-token distribution of a 4B model, which caps how much multi-hop work it can do. And treat its probabilities as uncalibrated until you have fitted a temperature on your own held-out slice.

Adopting SemIf in three steps

01Stand up a frozen open-weight model on hardware you already have — the project’s reference run is a single RTX 3090 with Qwen3.5-4B.
02Declare your options and read their logits in one prefill, instead of asking the model to emit a JSON array of answers.
03Verify agreement on your own labelled set. The published 0.845 figure comes from a 102-row aligned subset; your domain may agree far less.
python / readout, not generation
# SemIf does not generate an answer. It scores the options.
#
#   direct logit readout : 1.023 s, 0 output tokens  (21 criteria)
#   autoregressive JSON   : 5.332 s, 111 output tokens
#
# Typical integration: keep your existing inference server,
# declare the option set, and read the restricted softmax.
options = ["safe", "injection", "jailbreak"]

probs = read_option_logits(
    model=serve("Qwen/Qwen3.5-4B"),
    state=untrusted_input,
    question="What kind of payload is this?",
    options=options,
)

decision = max(probs, key=probs.get)
if probs[decision] < 0.85:
    decision = "human_review"   # never ship an uncalibrated threshold
The win is structural: a model that never writes an answer cannot invent a fourth option, and there is nothing to parse or retry.

SemIf questions people actually ask

Is SemIf the same thing as OpenJev?

It used to be. SemIf was formerly called OpenJev, and today the name OpenJev is so crowded — at least seven unrelated repositories use it — that the project renamed. Always say SemIf, and never write about bare "OpenJev" without naming the author.

Does SemIf need any training?

No. That is the entire point. It reads the probability the model already assigns to each option token, so the quality ceiling is whatever the frozen base model can express. If zero-shot agreement of 0.845 against Jev is not enough for your use case, the fix is a better base model or a fine-tune, not more SemIf.

Why is reading logits faster than asking for JSON?

Because the expensive part of generation is producing tokens. Reading 21 option probabilities costs one prefill; asking the same model to write a JSON array of 21 answers cost 111 output tokens and 5.332 s against 1.023 s in the project’s measurement — a 5.21x difference on identical decisions.

What hardware does SemIf need?

The reference setup is one RTX 3090 holding a 4B model in BF16. There is also a llama.cpp CPU backend, MLX and MPS support for Apple Silicon, and a WebGPU demo that runs in a browser tab, so a GPU is convenient rather than mandatory.

Sources

Every comparison number on this page is a third-party published figure or a read of a public repository — not a benchmark we ran. We have not tested TypeSafe Jev itself, and its customer agreement forbids using its outputs to build similar products.