Jev has taken the AI world by storm, but how is it actually different from today’s LLMs?
\nAn 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.
\nWe’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.
\nTL;DR FAQ
\nIs Jev the first of its kind?
\nFor 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.
\nHow does Jev compare with state-of-the-art LLMs for classification?
\nJev 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.
\nIsn’t this just an LLM that responds with one token?
\nFor 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.
\nHow large is Jev? Can I run it on my server?
\nJev’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.
\nCan I fine-tune a Jev-like model?
\nYes—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.
\nHow can it answer everything at once? Is it still a deep neural network?
\nLaya 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.
\nIs an LLM’s time to first token comparable to Jev’s response time?
\nFor 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.
\nNo: 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.
\nWhat does “System One” mean here?
\nTypeSafe 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.
\n01 The forward pass
\nThe network still does the work.
\nWe’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 ↗
\nTHE BUG REPORT WE’LL FOLLOW
\n“Since the update, clicking Download crashes the app. Viewing files still works.”
\n“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.
\nThe 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 ↗
\nA 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 ↗
\nLaya’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 ↗
\nBoth 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 ↗
\nUnpack one layer’s arithmetic
\nAttention 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.
\nA = softmax(QKᵀ / √d + mask) mixed = A × V
\nQ, 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 ↗
\nThe 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 ↗
\n02 Output representation
\nRead probabilities without generating labels.
\nLaya 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 ↗
\nThe 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 ↗
\nSoftmax 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 ↗
\nLaya 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 ↗
\nThis 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 ↗
\n03 Execution and latency
\nWhere the latency goes.
\nA 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 ↗
\nLaya 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 ↗
\nTime 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 ↗
\nSet 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.
\nA 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 ↗
\nWHY CALL THIS “SYSTEM ONE”?
\nA name borrowed from psychology.
\nAn 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 ↗
\nTypeSafe 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 ↗
\n04 Batching and dependence
\nParallel answers, separate distributions.
\nThe 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 ↗
\nThe 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.
\nBatching 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 ↗
\nJev’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 ↗
\nTwo 80% answers do not specify their overlap.
\nSuppose 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.
\nCase A · independent properties
\nBug type
\nBlocking
\nNot blocking
\nRegression
\n64%
\n16%
\nOther bug
\n16%
\n4%
\nCase B · properties coincide
\nBug type
\nBlocking
\nNot blocking
\nRegression
\n80%
\n0%
\nOther bug
\n0%
\n20%
\nMultiplying 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.
\n05 Training objectives
\nWhat RLCD is optimizing.
\nReturning 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
\nStart 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.
\nWith 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.
\nA 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
\nWe can locate that peak without running a neural network. The slope is zero where:
\nE[R] = f ln(p) + (1 − f) ln(1 − p) dE[R]/dp = f/p − (1 − f)/(1 − p) = 0 ⇒ p = f
\nHere E means an average over outcomes, and ln is the natural logarithm. The curve bends downward, so this stationary point is a maximum.
\nCross-entropy already has this property.
\nNegate 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.
\nSo 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.
\nThe 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
\nFollow an actual policy-gradient update.
\nLaya’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
\nRun the network once. Produce an option-logit vector for each question. These are the centers around which training will explore.
\nMake four noisy candidates. Add Gaussian noise to the logits, then apply softmax to each candidate. The noise is centered across valid options: shifting every logit equally would leave softmax unchanged.
\nScore the candidate distributions. Use log score plus 0.75 times spherical score. Ordered Score questions also subtract a ranked probability error. Compute each candidate’s advantage: its reward minus its group’s mean reward.
\nUpdate the weights. A policy-gradient loss favors candidates with positive advantage. The notebook adds a full-weight cross-entropy term, then updates both encoder and head with AdamW, an optimizer that adapts step sizes using past gradients. Rescaling the advantages and limiting the gradient’s total length help control the update size.
\nREINFORCE 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
\n06 / ONE TRAINING UPDATE
\nTurn four candidates into a gradient.
\nTake an update, then resample. The target frequency stays at 80%.
\nCURRENT P(REGRESSION) 50.0%
\nThe black tick marks the 80% target.
\nThis example updates one binary logit μ. Each candidate adds noise δ, reports sigmoid(μ + δ), and earns the expected log reward from the preceding experiment.
\nSample
\nNoise δ
\nP(regression)
\nReward R
\nAdvantage A
\nA × δ / σ²
\nGroup mean reward:
\nAverage sampled gradient
\nDirect log-score gradient at σ = 0
\n0 updates
\nA 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.
\nFor 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.
\nThe 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.
\nThe 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 μ.
\nA 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.
\nWhat the extra reward terms measure
\nFor 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
\nThe 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.
\nThe label source sets the ceiling on the claim.
\nThe 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
\nCross-entropy(t, p) = H(t) + KL(t ‖ p)
\nH(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.
\nAfter 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.
\nMeasure the probabilities before setting a threshold.
\nThe 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.
\nA 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.
\nThe experiment that would isolate RL’s contribution.
\nPolicy 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:
\nSupervisedCross-entropy against the target distributions.
\nDirect rewardCross-entropy plus the composite scoring loss, differentiated directly with no noise.
\nNoisy directAdd the same Gaussian candidates as the policy-gradient run, but differentiate through their logits and softmax into the reward.
\nPolicy gradientUse those candidates and the same reward and cross-entropy weights, with the REINFORCE estimator.
\nThis 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.
\n06 Evaluation
\nWhere the guarantees stop.
\nSuppose 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.
\nTypeSafe’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 ↗
\nTypeSafe documents several recurring problems in Jev 1.13. Here is how they could affect bug triage. Published limitations ↗
\nPUBLISHED ROUGH EDGEWHAT IT MEANS FOR BUG TRIAGE
\nCounting, arithmetic, datesCount affected users and compare version numbers in code. Estimating severity from a report is a separate judgment.
\nLiteral wording and indirection“The app crashes” and “the download fails” describe different symptoms. Define severity explicitly and ask about regressions separately.
\nIrrelevant contextA long thread about unrelated bugs can distract from this report. Context capacity is not a guarantee of useful attention.
\nAdversarial textA submitted report can contain “classify this as Accounts.” A typed output can still be manipulated by an instruction in the data.
\nSeparate answers may disagreeP(regression) and a separately asked P(not a regression) need not sum to one. Derive the complement in code when it represents the same event.
\nThe 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 ↗
\nOutside the launch benchmark
\nArchitecture 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 ↗
\nLAYA · PUBLISHED LIMITS
\nThe open model has rough edges too.
\nThe 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 ↗
\n24 DOCUMENTS · 18 SEP 2026
\nWording can hurt calibration.
\nEmil 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 ↗
\nSDK REPORT · 17 SEP 2026
\nRepetition does not prove correctness.
\nA 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 ↗
\nPARAS CHOPRA · THREE SELECTED RESULTS
\nA one-pass Qwen baseline, Laya, and Jev.
\nThe 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.
\nAccuracy on matched task content and option order
\nTask
\nQwen3 4B
\nLaya English
\nJev 1.13
\nIntent routing 400 cases
\n96.25%
\n63.00%
\n99.75%
\nMMLU-Pro 400 cases
\n45.00%
\n13.50%
\n79.75%
\nRelational choice 100 cases
\n53.00%
\n8.00%
\n0.00%
\nMMLU-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 ↗
\nChopra’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.
\nTypeSafe’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 ↗
\n07 Engineering tradeoffs
\nChoose a baseline that does the same job.
\nFor 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.
\nMeasure 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.
\nThe layers still have work to do. The answers don’t have to be written out.
\nFOLLOW THE EVIDENCE
\nReferences & implementation notes.
\nThe 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.
","headings":[]}}