Jev has taken the AI world by storm, but how is it actually different from today’s LLMs?
An LLM already computes probabilities. It can already classify text. The interesting change is which distribution the system exposes, how much sequential work it removes, and what training rewards. Those are three separate engineering questions.
We’ll follow the tensors through a decision model, compare its execution with token generation, then derive the training objective. Jev’s implementation is private; Laya’s published code gives us a concrete reference for the mechanisms. Claims about Jev are identified where the implementations differ.
For direct classification, no: BERT-based models already returned label probabilities without generating text. Jev combines typed decisions, parallel inference, and calibration-focused training; Laya is an independent open decision model, not Jev’s released architecture.
Jev can be competitive, but there is no established accuracy lead over frontier LLMs. In one 150-passage test, Jev and Haiku scored 66%, while Sonnet scored 71.3%; Jev responded faster.
For one classification, a non-reasoning LLM can return a single label token and expose candidate probabilities immediately. Jev bundles several decisions and their distributions; the meaningful differences are training, calibration, and serving efficiency.
Jev’s size is undisclosed, with no public weights to self-host; Chopra’s ~30B estimate is unverified. Laya’s English model runs locally with 421M parameters (learned weights): calculated weight storage is 0.84 GB at 16-bit or 1.68 GB at 32-bit, plus runtime memory.
Yes—Laya and Kev publish trainable implementations, though Jev itself currently has no customer fine-tuning. Train on labeled reports, calibrate probabilities on separate data, and test on untouched reports; matching the interface does not guarantee matching Jev’s quality.
Laya uses a deep transformer to score all supplied options together, without generating one answer before the next. Its layers still run sequentially; Jev’s exact architecture is private, so Laya illustrates a working approach rather than a confirmed reconstruction.
For a single label token with no hidden reasoning, time to first token is approximately time to a useful answer. Jev returns completed decisions, so compare complete-response latency for equivalent outputs; neither design guarantees a lower waiting time.
RLCD means Reinforcement Learning for Calibrated Decisions: TypeSafe’s training approach for Jev, aimed at probabilities that match observed outcomes. Laya’s independent recipe scores sampled probability distributions and updates the network toward better-scoring candidates; Jev’s full training recipe is not public.
No: supervised classifiers can learn probabilities without Reinforcement Learning for Calibrated Decisions (RLCD). Either approach needs calibration checks—among reports assigned an 80% regression probability, roughly 80% should be confirmed regressions on fresh data.
TypeSafe borrows the psychology term for fast judgments within predefined answer choices, such as routing a bug report. It describes the intended task; arithmetic, indirect instructions, and adversarial text can still cause mistakes.
We’re building a tool to triage bug reports. It reads a report and estimates the affected component, the severity, and the probability that the bug is a regression: something that worked in an earlier version and broke after a change. Jev accepts the report as text. Supported inputs ↗
“Since the update, clicking Download crashes the app. Viewing files still works.”
“Since the update” suggests a regression, but investigation has to confirm it. We’ll use that distinction when we get to training: the report is the evidence available to the model; the confirmed outcome is what we score its prediction against.
The open reference model, Laya, uses a ModernBERT-large encoder in its English checkpoint: 28 transformer layers, with a 1,024-number vector at each token position. Two more transformer layers prepare those vectors for scoring. The computation still passes through a deep neural network before producing any answer. Encoder configuration ↗ Laya model card ↗
A vector is a list of numbers. Each layer updates the vectors in two steps: attention mixes information between token positions, then a feed-forward network transforms the numbers at each position. The next layer starts with those updated vectors. Below, four small layers let you watch this happen. Transformer paper ↗
Select part of the sentence.
See how context changes its vector.
This small network computes attention and vector updates with hand-set weights. A shortened report stands in for the input. Here, each word and the period stand in for a token. Select any of them to inspect its vector. Laya uses wider vectors and alternates local and global attention. The “both directions” setting here shows full attention.
Laya’s encoder is bidirectional: a position can use context on either side. That will matter when an option marker appears before the report it needs to judge. A causal language model blocks attention to later positions. Switch between the two settings and inspect “The” while replacing “download” with “preview.” Only the bidirectional version lets that later edit reach the first word. Bidirectional representations ↗
Both settings can process the known input positions together within a layer. Layer 3 still has to wait for layer 2. In the published Laya configuration, most encoder layers attend within a local window; every third layer uses the full input, starting with the first. “Parallel” does not mean skipping those layers. Layer layout ↗
Attention first makes three versions of each position’s vector: a query, a key, and a value. A query is compared with the keys to decide how much weight each position gets. Those weights are used to mix the value vectors.
Q, K, and V are rectangular arrays of numbers—matrices. The superscript T swaps rows and columns; d is the query vector’s length. A dot product multiplies matching numbers and adds the products. Softmax turns scores into shares that sum to one. A mask uses a prohibitive score at forbidden connections. Then the feed-forward block applies two learned matrix transforms with a nonlinear function between them. Residual additions preserve the incoming signal; normalization controls its scale. You can see these operations in a production transformer implementation. Llama layer implementation ↗
The little model has one attention head, meaning one set of these comparisons. Laya’s encoder has 16 heads per layer, each working on a different projection of the vectors. The four-layer display keeps the arithmetic small enough to inspect. Attention dimensions ↗
Laya puts a [MASK] marker before every option. After the layers have processed the sequence, it gathers the vectors at those markers. Each vector has had access to its option and the surrounding input. This is how “Downloads” and “Preview” get their own scores, even though the labels were supplied with the request. Sequence construction and scoring ↗
The head is the part that turns those vectors into answers. Laya uses the same small network for every marker: normalize its 1,024 numbers, apply a linear layer, pass through a smooth nonlinear function called GELU, then reduce to one score. That score is a logit. All marker vectors can go through this scorer together. DecisionModel ↗
[B, L, 1024]28 layers
1,024 numbers per position
[B, L, 1024]Add a learned type vector.
Process the sequence again.
[B, K, 1024] → [B, K]The same scorer maps each
1,024-number vector to 1 logit.
[B, K]One probability per option.
Format the answer in code.
A tensor is an array of numbers with named axes: B is the batch size, L the input length, and K the number of options after padding. The scorer collapses each 1,024-number marker vector to one logit. [CLS] and [SEP] boundary tokens are omitted above.
Adjust one internal score.
Watch every probability change.
Since the update, clicking Download crashes the app. Viewing files still works.
A logit is an unbounded score.
A probability is between 0 and 1.
To keep the arithmetic visible, this example gives each option three numbers and uses one shared weight vector: w = [1.0, 0.5, 1.6]. Multiply matching entries, then add them. The slider changes the selected option’s vector. Laya’s scorer has the extra nonlinear layer shown above.
Every option uses the same weights. The vectors carry what differs between the options.
The numbers are set up for this exercise. They are not model predictions about the report. “Use Laya’s saved T” loads the rounded value for this question type and option count from its English checkpoint.
Softmax raises e to each score and divides by the total, giving shares that sum to one. Raise the Downloads logit: Preview’s probability falls even though its own score hasn’t changed. For Score, code takes the weighted average of the numbered levels. For Noul, it returns the probability assigned to “yes.” Answer conversion ↗
Laya also divides the logits by a fitted temperature, T, before softmax. A larger T spreads the probabilities more evenly without changing which option wins. Try its stored values: about 1.76 for a three-option Choice, 1.25 for this Score, and 1.98 for Noul. This is a numerical adjustment after the network has finished. Stored temperatures ↗
This also explains why new labels don’t require a new “Downloads neuron.” The labels arrive as text, the encoder builds a vector for each marker, and the scorer reuses its weights. Earlier systems such as FIRST read candidate scores from an LLM’s first-token logits. There are several working ways to get numerical decisions out of a language model. FIRST ↗
A text-generating LLM processes the prompt first. This is prefill. Its output layer gives the scores for the first new token. Once that token is chosen, the model feeds it through the layers to get the next one. This dependency on earlier output is what autoregressive means. A KV cache keeps the earlier attention keys and values so they don’t have to be rebuilt at every step. Inference and caching ↗
Laya stops after scoring the markers. Its code calls the network once for the batch, then uses ordinary arithmetic to format the answers. Jev’s launch describes the same outward behavior: probabilities returned together, with no generated text. Laya’s forward call ↗ Jev’s launch ↗
Try one output token.
Then ask for a longer response.
This calculator assumes 60 ms combined network/queue overhead, 80 ms prefill per 1,000 input tokens, 15 ms per additional output token, and the adjustable decision overhead. Both paths share the same prefill purely to isolate the output mechanism. First-token readout/delivery is absorbed into prefill; final formatting/delivery is absorbed into the displayed costs. Linear prefill scaling and fixed token intervals are teaching simplifications, not fitted measurements.
Real model sizes, accelerators, caching, question length, batching and congestion change all of these numbers. The four small layer marks illustrate serial depth; they do not resolve per-layer timings. Speculative decoding can accept several proposed tokens per verification pass; hidden reasoning can add work before the first visible token. This diagram depicts basic autoregressive decoding.
Adjustable example timings. The assumptions are listed above; measured results appear later in the article.
Time to first token (TTFT) ends when the first output token reaches you. End-to-end latency ends when the whole response arrives. If the first token is “{”, the software is still waiting for the fields inside it. Jev’s advertised 70–500 ms measures the complete response. Timing definitions ↗ Jev’s reported range ↗
Set the output length to one. If that token is the complete label you need, the LLM is done at TTFT. In this example it finishes before the decision model, whose extra processing is still running. Longer generated answers leave more work to avoid. For a real comparison, measure both systems until the result is usable by your code.
A schema can constrain an LLM to valid JSON, and requests can be batched. Those are useful baselines. The practical question is how long each implementation takes for the same job, with the same input and required answers. Structured outputs ↗
An engineer may recognize a familiar crash report at a glance. Finding the cause can take a sequence of tests: reproduce it, compare versions, inspect the failing code. Psychology uses System 1 for automatic impressions and System 2 for deliberate thought. Kahneman treated them as ways of describing mental activity. Kahneman’s lecture ↗
TypeSafe borrows System One for its decision models. Earlier AI papers used the analogy differently: Tree of Thoughts called ordinary LLM generation System-1-like, then added search to encourage deliberation. The name tells you what kind of work the authors have in mind; it won’t tell you how many layers the network has. TypeSafe’s usage ↗ Tree of Thoughts ↗
The affected component, severity, and regression probability can be estimated from the same bug report. Laya builds one input sequence for each question, including a copy of the report in each. It pads the sequences to the same length and sends them to the model as a batch: several rows evaluated in one call. Batch construction ↗
The rows use the same network weights, but their attention stays within the row. The component question can read its own options and copy of the report. It cannot read the regression question’s wording. This isolation comes from the batch dimension, with no special cross-question attention mask.
Select a row.
Add questions or reduce capacity.
The separate input rows follow Laya’s source. The capacity slider illustrates what happens when a batch is too large; it is not a Laya setting. The inspected runtime attempts one batch and can fall back to CPU on an accelerator memory error.
Batching fills more of a GPU’s arithmetic units at once. It can improve throughput even while the request takes longer. Laya’s published English-checkpoint timings on a T4 rise from 39.5 ms for one question to 158.6 ms for ten. That is more answers per second, but more waiting for the complete call. Reported batch timings ↗
Jev’s documentation says it ingests the state once. Laya’s batch code repeats it. A causal transformer can save work by caching a shared prefix. In Laya’s bidirectional encoder, however, the report also attends to the question and options. Its vectors can therefore differ from row to row. Jev’s state handling ↗ Shared-prefix research ↗ Laya’s batch inputs ↗
Suppose P(regression) = 0.8 and P(task blocked) = 0.8. Both of these joint distributions have those same marginals—the probabilities for each property on its own.
| Bug type | Blocking | Not blocking |
|---|---|---|
| Regression | 64% | 16% |
| Other bug | 16% | 4% |
| Bug type | Blocking | Not blocking |
|---|---|---|
| Regression | 80% | 0% |
| Other bug | 0% | 20% |
Multiplying 0.8 × 0.8 assumes independence. The marginals alone only bound the overlap between 60% and 80%. If a workflow needs the probability of a blocking regression, ask about that combination directly and validate the prediction. Evaluating questions together does not supply a joint probability model.
Returning a probability is easy: apply softmax. Making that probability useful is a training problem. TypeSafe calls its approach reinforcement learning for calibrated decisions, or RLCD. Its public description specifies the goal, but gives no loss function or optimizer to inspect. We can still work through the mathematics and examine a published implementation. TypeSafe’s training description
Start with 100 comparable bug reports. Investigation later confirms that 80 are regressions. A model that always chooses “regression” gets 80 correct. Reporting 80% or 99% doesn’t change that accuracy. If we instead sample an answer from its probabilities and reward a correct sample, we create a different incentive: the model earns more by always sampling the more common answer.
Try reporting 80%, then 99%.
Switch between the objectives.
Exact expected rewards for a constructed binary problem. The dashed line marks the actual frequency. The plot’s vertical scale changes with the objective; compare the location of the peak. Log reward diverges at the endpoints, so the curve stops just short of them.
With f = 0.8, rewarding a correct sampled answer gives 0.2 + 0.6p. Its best report is p = 1. That is a good policy for maximizing correct actions, but a bad estimate of how often the event happens. The distinction is between learning what to do and learning how likely an outcome is.
A strictly proper scoring rule makes the true probability the unique best report in expectation. Log score rewards the log probability assigned to the outcome that occurred. A confirmed regression contributes ln(p); a bug confirmed not to be a regression contributes ln(1 − p). Average over the group and the optimum moves to 80%. Proper scoring rules
We can locate that peak without running a neural network. The slope is zero where:
Here E means an average over outcomes, and ln is the natural logarithm. The curve bends downward, so this stationary point is a maximum.
Negate that log reward and you have binary cross-entropy, a standard supervised classification loss. You can differentiate it directly and update the network by backpropagation: carrying derivatives backward through the layers to calculate how each weight should change. If the model’s logit is μ and p = sigmoid(μ), the loss gradient is simply p − f. At p = 0.5 and f = 0.8, gradient descent pushes the logit upward.
So calibrated probabilities do not inherently require reinforcement learning. The important questions are what the targets represent, which objective is optimized, and how the fitted model behaves on fresh data. An LLM’s next-token loss estimates the distribution of text; a classifier’s loss estimates labels. Both use cross-entropy, but they are predicting different things.
The population optimum is also not a guarantee about a trained network. Limited data, model capacity, optimization, and a change in the input distribution can all leave it miscalibrated. Neural classifiers trained with cross-entropy are known to need calibration afterward. Guo et al., 2017
Laya’s public typed-decisions fine-tuning notebook makes the implementation concrete. It starts from an existing checkpoint and uses target probability vectors from the dataset. This is a separate training recipe we can inspect, rather than evidence of Jev’s internal algorithm. Pinned training notebook
REINFORCE is the gradient estimator behind this update. It asks how changing the network would change the probability of sampling a candidate, then weights that direction by the candidate’s reward. Subtracting a baseline makes the comparison relative to nearby candidates. A candidate can have a negative reward and still have positive advantage. Policy-gradient mechanics
Take an update, then resample.
The target frequency stays at 80%.
This example updates one binary logit μ. Each candidate adds noise δ, reports sigmoid(μ + δ), and earns the expected log reward from the preceding experiment.
| Sample | Noise δ | P(regression) | Reward R | Advantage A | A × δ / σ² |
|---|
Group mean reward: . Subtract it from each reward to get A. The last column combines that advantage with the direction in which the sample moved.
A one-parameter illustration of REINFORCE, with four samples, a group-mean baseline, log reward, and a step size of 0.5. It omits the notebook’s composite reward, advantage normalization, cross-entropy term, and AdamW. Initial noise values are fixed; resampling uses a seeded Gaussian generator. The slider bounds limit updates.
For Gaussian noise, the gradient contribution is A × δ / σ². A sample that moves right and does better than its neighbors pushes the center right. A worse sample on the left also pushes it right. Backpropagation carries the combined signal through the scoring head into the encoder’s weights.
The two gradients in the experiment need not match. One uses four noisy candidates and a shared baseline; the other differentiates the unperturbed log score exactly. With nonzero noise, the sampled objective averages rewards around the current logits. That is a different objective from scoring only the distribution used at inference. A proper reward alone therefore does not prove that the deployed model is calibrated.
The expected sampled objective is J(μ) = Enoise[R(sigmoid(μ + noise))]. The score-function estimator differentiates the sampling density, treating each sampled z as fixed. In the notebook, detaching the sampled center and evaluating reward without gradients does this explicitly. The gradient still flows through the log-density calculation into μ.
A group mean includes each sample’s own reward. For independent samples, that scales the unnormalized estimator’s expectation by (G − 1)/G, where G is the group size. The notebook also normalizes advantages, so this should not be described as an exact unbiased gradient of the unsmoothed score. The demo leaves normalization out to expose the arithmetic.
For target distribution t and predicted distribution p, the spherical term is (t · p) / ‖p‖: a dot product divided by the vector’s length. The ranked term compares cumulative probabilities along ordered levels. A prediction two levels away then incurs more error than a neighboring prediction. The source clips log probabilities at −9.21, so its implementation is not the unrestricted textbook log score. Reward function
The 0.75 spherical weight comes from the fine-tuning notebook; the reusable reward function defaults to 0.5. Neither number is a published Jev hyperparameter.
The fine-tuning code reads full target distributions from gold fields, rather than collapsing them to winning labels. The dataset describes teacher-generated reference probabilities. Matching them trains the model to reproduce those references; it does not establish that 80% predictions will occur 80% of the time in your production data. Dataset construction
H(t) is fixed once the target is chosen. KL measures the mismatch between target and prediction. Minimizing this loss makes p approach t—including any errors in t.
After training, the notebook fits a temperature by minimizing cross-entropy again, this time with the network frozen. Only the scale of the logits changes. That is the T slider from the readout experiment. Exploration noise σ changes the candidates considered during training; temperature T changes the reported probabilities afterward.
The next experiment separates the probability estimate from the application’s decision. First minimize probability error on a group of resolved bug reports. Then try a different release’s reports without changing the forecast, or change the threshold for routing a report to the regression queue without retraining anything.
Minimize the error.
Then change the routing threshold.
A constructed set of 100 outcomes using squared probability error. Reports at or above the threshold go to the regression queue; the rest get general triage.
A constant 80% forecast can be calibrated across this group while telling us nothing about which individual report is a regression. Calibration and discrimination are different: we want reliable probabilities and useful separation between easy and difficult cases. Check both, including the subset the application actually accepts.
Policy gradients are useful when reward comes from a discrete action or an external evaluator whose derivatives are unavailable. Here the scoring formula permits direct differentiation, so that is a useful control. Keep the backbone, head, training data, and compute budget fixed. Compare these training runs, with the same held-out temperature fitting for each:
This is an ablation: change one ingredient at a time to see what it contributes. The middle comparison tests exploration noise; the last tests the gradient estimator. Compare accuracy, log loss, squared probability error, and the fraction of cases accepted at a fixed error rate. The code shows how an RLCD-style system can be trained. These controlled results would tell us whether the sampling-based update improves it.
Suppose a new report concerns notifications, but our component list only contains Downloads, Preview, and Accounts. The model still has to distribute probability across those choices. Add an “Other” option if the application needs one. Restricting the labels makes the output predictable; it doesn’t make the list complete.
Change the outcome.
Keep the evidence and rule fixed.
“Since the update, clicking Download crashes the app. Viewing files still works.” Our routing rule sends failed-download reports to Downloads. Allowed values: Downloads, Preview, Accounts.
Preview is an allowed component, but the report says viewing files still works. Our routing rule sends this bug to Downloads. A type check cannot discover that mistake.
Made-up outputs to separate two checks: whether the label is allowed and whether it fits the evidence.
TypeSafe’s launch says Jev cannot hallucinate. A Choice result can’t invent a category outside the supplied list. It can certainly pick the wrong one. The example above sends a download failure to the wrong component, even though the output passes a type check. LLM schemas can constrain the format too. Launch claim ↗ Schema constraints ↗
TypeSafe documents several recurring problems in Jev 1.13. Here is how they could affect bug triage. Published limitations ↗
The options can affect one another, too. In Hume’s Jev probes, adding an extra option changed the relative probabilities of existing ones. Laya gives us a concrete reason to watch for this class of behavior: the option text shares a sequence, so attention can change an option’s vector when the list changes. That explains a risk in Laya; it doesn’t identify the cause of Hume’s Jev result. Option-list experiment ↗
Architecture inspection cannot establish model quality. Laya’s benchmark tables also combine results from different checkpoints and experiments. Its Jev numbers come from other people’s tests, with different prompts and sample sizes. The high typed-decisions result belongs to a separately fine-tuned checkpoint. Laya’s benchmark notes ↗
The English checkpoint budgets 512 tokens per question, including options and state. Long option lists squeeze the descriptions; the repository recommends staying below about 20 choices. Its benchmark report also says the shipped probabilities are overconfident and that temperature fitting helps. Those are reasons to test a model on your own bug reports, even when its architecture is easy to inspect. Benchmark details ↗
Emil Lindfors’s Norwegian document experiment found that adding qualifiers reduced agreement on argument labels from 89% to 86%, and worsened the calibration metric. His reference labels were model-generated, not settled human ground truth. First-hand report ↗ · Code and predictions ↗
A developer reported the same disputed routing result over 100 runs of a quickstart example. One overlapping-category case is not an error rate. The issue is closed, and the report does not establish current behavior. Original issue ↗
Alex Kim tested passages from two versions of blog drafts. Jev matched Haiku’s accuracy with about 1.4× lower median latency. Sonnet scored better on accuracy and calibration. These are the author’s pipeline measurements, not model-only timings or a general ranking. Method and results ↗
The local Qwen prototype used unchanged pretrained weights stored at 4-bit precision and read label probabilities in one pass. Jev ran through OpenRouter; these reported accuracies come from reused public and synthetic tests, with unknown pretraining overlap.
| Task | Qwen3 4B | Laya English | Jev 1.13 |
|---|---|---|---|
| Intent routing 400 cases | 96.25% | 63.00% | 99.75% |
| MMLU-Pro 400 cases | 45.00% | 13.50% | 79.75% |
| Relational choice 100 cases | 53.00% | 8.00% | 0.00% |
MMLU-Pro tests academic knowledge and reasoning. Relational choice uses information in one option to select another; the gist provides neither exact prompts nor raw outputs to diagnose Jev’s failure. The result does not establish how its options are processed. Full comparison and caveats ↗
Chopra’s post estimates about 30 billion Jev parameters from accuracy and latency. That remains unverified: neither measurement identifies model size, and the timings compare local Laya with remote Jev on different hardware.
TypeSafe’s headline gains, 193.6× faster and 444.6× cheaper, came from four workflows. The LLM wrapper had to produce probability estimates, and the reference answers were averages from two larger models. TypeSafe says those gains are likely toward the high end. For bug triage, the useful test would be the same reports, component choices, severity rubric, and confirmed outcomes on each system. Benchmark setup ↗
For bug-report triage, compare the decision service with a supervised encoder and a generative model constrained to a short label. Match the reports, component options, severity rubric, and required probabilities. A one-token classifier and a model producing a paragraph are doing different amounts of work; their latency gap does not isolate an architectural improvement.
Measure complete-request p50 and p95 latency—the median and the time under which 95% of requests finish—at the same concurrency. Then measure decision quality and accepted-case error after calibrating on separate data. Jev’s useful contribution has to survive that comparison: less waiting or lower cost at the quality your application needs.
The layers still have work to do.
The answers don’t have to be written out.
The sliders use small models with hand-set numbers. External benchmark results are credited to the people who ran them. We inspected the source and configuration; we did not rerun the trained models or those benchmarks.