OpenJev in your browser

openjev

Can we run something like Jev in your browser?
GitHub repo ↗

A live, local experiment
Decision model in your browser.
A local model can either read probabilities for your allowed options without decoding them, or write the same kind of distribution token by token. Pick a size, run both on your own GPU, and measure the difference.

browser onlyno backendyour timings1.56 GB model

celebrationThere is no waitlist! Just try it out ↓

MiniCPM5 2B is selected by default. On a phone or smaller device, switch to Qwen3 0.6B in the model box if needed.

00 / setupLoad the model once

Model

Qwen3 0.6B · recommended for phones and small devices
MiniCPM5 2B · recommended on desktop
Qwen3.5 4B · high-memory desktop

download load MiniCPM5 2B

Larger model. Loading may be slower or may not fit on some low-end devices.

Model performancehigher is better

ModelDownloadAuthoredPerturbedTypeSafe

Qwen3 0.6B639 MB44.0%52.8%40.7%
MiniCPM5 2B1.56 GB68.6%69.3%63.7%
Qwen3.5 4B3.01 GB81.3%76.6%84.5%
Published Jevhosted——88.3%

Native BF16 · TypeSafe: same 102-row subset · Jev: published result · browser builds are quantized

{{ icon }}{{ text }}

download / cache—starts only when you click load
model load—download and prepare
warmup—compile passes for both methods

Weights come from Hugging Face and remain in your browser cache. Inputs never leave this page. First load can take several minutes depending on the selected model, network and GPU.

01 / decisionGive it a real choice
play_arrow run both methods

Try an example
Account support
Email triage

StateA customer says a password reset succeeded, but every login attempt still returns “account locked”. Two unlock emails were requested and neither arrived.
Question
Allowed options

A
B
C

remove remove
3 / 20
add add

Both paths receive the same decision. One reads option probabilities directly; the other asks the model to write its option probabilities as JSON text.

your decisionstate + question + options
→
same local modelMiniCPM5 · 2B
↗↘

read logitsA…T probabilities
write tokens{options + probabilities}

02A / direct readoutChoice probabilitiesno decoding
Read the model’s choice logits and normalize only across the options you supplied.
waiting for a run

total—
input—
output1 readout

02B / generationJSON probabilitiestoken by token
Ask the model to estimate the same displayed-option distribution and write it as JSON. Watch every token arrive.
waiting for a run

first token—
total—
input—
output—

measured wall-time ratiorun it on your GPU
The methods run sequentially on the same loaded model so they do not contend for one GPU. Direct runs first, then generation.

What these numbers do—and do not—mean

Conditional probabilities. Direct scores are a softmax over only the displayed option tokens. They are not calibrated confidence and do not include every answer the model might prefer.
Local model tiers. The phone model trades accuracy for size. MiniCPM is the desktop default. The 4B option needs substantially more memory. None is claimed to match Jev.
Real local timing. Setup, warmup, prompt preparation, direct execution, first generated token and generation completion are timed with performance.now(). No canned results appear.
Quantized weights. The demo uses pinned GGUF builds through wllama. Quantization can change both quality and speed.

OpenJev / browser labGitHub repo · model · wllama

The OpenJev experiment details a method for running decision models locally within a web browser, allowing users to perform decision-making tasks directly on their GPU without requiring a backend. The core of the experiment involves comparing two distinct approaches for obtaining choices from a selected local language model: direct readout of probabilities versus token-by-token generation of the distribution.

The setup involves selecting a model based on device constraints, offering options such as MiniCPM5 2B, Qwen3 0.6B, or Qwen3.5 4B, with smaller models recommended for mobile devices and larger models for desktop systems. The process requires loading the model once, which includes downloading and preparing the necessary weights, a step that can take several minutes depending on the model and hardware. The system allows users to measure the performance of both methods sequentially, timing the entire process from setup and warmup through execution to generation completion to provide real local timing data.

The experiment contrasts two methods for decision output. The direct readout method involves reading the model's choice logits and normalizing them only across the supplied options to provide a probability distribution. In contrast, the generation method involves instructing the model to estimate the same option distribution and output it as JSON text, requiring the user to observe the arrival of each token. These methods are run sequentially on the same loaded model, ensuring that they do not contend for GPU resources.

The results highlight several important considerations regarding model performance and output interpretation. The direct scores derived from readout are conditional probabilities that are not calibrated confidence measures and may omit potential answers the model might prefer. The choice of model tier reflects a trade-off between accuracy and memory requirements, where the smaller models are suitable for phones and larger models are optimized for desktops. Furthermore, the measured wall-time performance accounts for all overhead, including setup, warmup, prompt preparation, direct execution, and the time taken for the first generated token and subsequent generation completion. The demonstration also notes that the results utilize quantized weights, specifically pinned GGUF builds, which can influence both the quality and the speed of the execution. Ultimately, the experiment aims to provide a benchmark for local model interaction by measuring the performance implications of these different output extraction strategies at the local level.