mrkeyoor.com_
Wed 23 Sept 21:30 UTC
Open Source6 min read

SemIf Hits 4,027 Stars Before Its First Release

The open project skips answer generation and reads option probabilities from Qwen. Its own tests show a 5.21x speedup, plus limits that stars cannot settle.

SemIf picked up 4,027 GitHub stars between its September 16 creation and MrKeyoor's September 23 crawl, before publishing a single release. Its own evidence is more restrained than that rush of attention: on a selected 102-row comparison, an open 4-billion-parameter model reached 0.845 agreement with public reference answers, versus 0.883 for the closed Jev service that inspired it. The project's results document says plainly that this 3.8-point gap does not establish near-Jev capability.

That restraint is the reason SemIf is interesting. The repository turns a current AI product idea into code that a developer can inspect: give a model some state, a question and a fixed set of options, then read probabilities from the model's next-token scores without asking it to compose an answer. The output can feed an ordinary branch in a program. SemIf also commits its prompts, row-level predictions, model revisions and known failures, so its claims can be separated from the star counter.

A model call that writes no answer

Most structured model calls still generate text. Even when the requested result is a tiny JSON object, the model emits tokens one after another and the application parses them. SemIf takes a shorter route. Its method description says the direct scorer formats the state, criterion and two to 16 possible answers into a prompt, performs a forward pass with Qwen3.5-4B, then applies softmax only to the logits for fixed uppercase answer tokens. It does not decode an answer token.

Imagine a support system deciding whether a failed login belongs in account access or billing. The application supplies those two options and their descriptions. SemIf returns a probability for each one. It cannot invent a third queue because no third option exists, though it can confidently choose the wrong queue. The repository's README warns that its probabilities are conditional on the supplied choices, which makes an incomplete option set an application error the model cannot repair.

The design borrows the interface pattern from TypeSafe AI's closed Jev service. TypeSafe describes Jev as a fast model for typed probabilistic decisions, with claimed response times of 70 to 500 milliseconds and a price of $0.042 per million input tokens. Its launch post attributes those results to an undisclosed architecture, a parallel sampler and a training method called RLCD. SemIf does not reproduce any of those components. It uses available Qwen checkpoints to test how much of the interface can be recovered with ordinary model logits and cache reuse.

That distinction matters for developers comparing the two. SemIf is local code and an evaluation bundle, not an open clone of Jev's model. The repository was formerly named OpenJev and now identifies itself as an independent project unaffiliated with TypeSafe. The name change makes the boundary clearer, while the experiments show that the useful shape of the API does not require access to TypeSafe's weights.

The 5.21x result has a narrow denominator

SemIf's cleanest speed result uses the same frozen Qwen3.5-4B model, one owned input and 21 binary criteria on an RTX 3090. Reading the option logits directly took a median 1.023 seconds across three runs. Asking the model to generate a compact ordered JSON array took 5.332 seconds and 111 output tokens, according to the project's committed benchmark report. That makes the generated path 5.21 times slower in this test.

The comparison avoids an easy benchmark trick. The generated baseline produced only an ordered array of yes and no values, without keys or explanatory text. All three arrays were valid and identical. Yet their choices matched the direct scorer on only 18 of the 21 questions. SemIf therefore presents this as a systems comparison, not proof that generation and direct readout make equivalent judgments. A stricter minified-array prompt failed by repeating values until it hit a 128-token cap, and the project records that run as a failure instead of using it to enlarge the headline ratio.

Cache reuse creates the larger throughput gain. On a fixture containing 37 states with 21 criteria each, fresh direct scoring processed 777 decisions in 333.1 seconds. Reusing each state's prefix and evaluating its suffixes in parallel cut that to 38.8 seconds, or 20.03 decisions per second. Speed came with drift: six of the 777 argmax choices differed from the fresh path under BF16 execution. The method notes also say model loading and result-file writes sit outside the timing window.

Those numbers cannot be divided into TypeSafe's service latency. SemIf ran a different model on different inputs and hardware, without the network and endpoint work of a hosted API. The repository says as much. Its useful claim is local and testable: when one model must judge many questions against the same long state, avoiding output generation and reusing the prefix removes repeated computation.

Confidence needs its own data

A typed answer only solves the shape of the response. Whether a score of 0.8 deserves an automatic action depends on how the model behaves on the workload where it will run. SemIf's direct Qwen baseline reached 0.813 balanced accuracy on 144 project-authored rows and 0.637 on 256 WANLI natural-language inference rows. The different results rule out treating one benchmark as a general reliability figure.

The confidence problem is visible in the WANLI run. Before adjustment, the model's expected calibration error was 0.208. Per-workload temperature scaling reduced the out-of-fold figure to 0.069, with the fitted temperature stable across the five folds. The project's calibration report says the same treatment made only marginal changes on its authored and Every workloads because their starting error was already low. One global confidence fix would miss those differences.

Temperature scaling does not change which option wins. It changes how strongly the system states its choice, using labeled examples from the intended workload. For a developer, that separates two jobs that are often collapsed into one API response: the model chooses an option, while local evaluation determines when the probability is safe enough to bypass review. A valid enum and a calibrated threshold answer different questions.

SemIf's perturbation tests add another warning. Reversing option order produced 10 flips across 36 direct-scoring cases, even though accuracy on the variants remained relatively strong. Criterion wrappers caused nine flips. A system wired into account actions or security triage would need tests for wording and order, not only a passing schema check.

Local access ranges from a browser to a 3090

The main measured setup used Python 3.10, CUDA 12.8, BF16 execution and an RTX 3090. The reproduction guide pins the Qwen revision and records package versions, hashes and acceptance checks. Apple Silicon users have MLX and PyTorch MPS paths. A llama.cpp backend can run a quantized GGUF on CPU, with the warning that different evaluation paths may produce small numerical changes.

There is also a browser demo. The largest listed artifact is a 3.01GB Qwen3.5-4B quantization; smaller 1.56GB and 639MB options trade away accuracy. The published quality scores belong to native BF16 checkpoints, not those browser files. The project reports browser smoke tests for loading and completion, so the demo proves that the path runs in Chrome on supported hardware. It does not transfer the RTX 3090 timing or BF16 quality result to every laptop.

The packaging is still young. The repository showed 25 commits, 12 open issues and 14 pull requests when checked, while its Releases page remained empty. The GitHub API record lists an MIT license for the project code. Model weights stay upstream under their own terms; the Qwen3.5-4B model card lists Apache 2.0. A star is much cheaper than reproducing a GPU benchmark, and the repository has not yet gone through a tagged release cycle.

The next test belongs in an application

SemIf has already answered one useful question: developers can build a generation-free, typed decision path from open weights and measure it with committed artifacts. The unresolved part is whether it remains accurate, calibrated and faster inside somebody else's queue router, policy engine or agent monitor. Watch for a tagged release, independent reruns on different GPUs and reports built from real labeled workloads. If those arrive, the 4,027-star week will look like early attention to a practical primitive. If they do not, the repository will still be a well-documented experiment whose caveats aged better than its launch number.

We reviewed this

  1. browser — our honest review
  2. fresh — our honest review
  3. llama.cpp — our honest review

Sources

  1. SemIf repository
  2. SemIf phase 1 results
  3. SemIf method
  4. SemIf reproduction guide
  5. SemIf calibration report
  6. TypeSafe AI introduces Jev
  7. Qwen3.5-4B model card
  8. SemIf GitHub API record