Kev-0.5B: A Tiny Open Source Jev-like Decision Model

Kev-0.5B turns a small language model into a specialized decision engine. It accepts one document, called the state, and multiple closed-ended questions, then returns a probability distribution for each question without generating an answer token by token.

The open-source project combines a LoRA adapter and custom pointer head with Qwen2.5-0.5B. Its code, training recipe, and release files are available in the Kev GitHub repository. The Kev-0.5B model card documents the architecture, training data, intended uses, and reported evaluation results.

Kev is best understood as a compact research implementation of a Jev-like decision model, not a general-purpose chatbot. The model card labels Kev-0.5B as a superseded prototype retained for reference and reproducibility while newer Kev models continue the project.

Kev Uses an LLM Backbone Without Acting Like a Chatbot

Kev starts with the 494-million-parameter Qwen2.5-0.5B base model and freezes its original parameters. A rank-16 LoRA adapter modifies the transformer's attention and feed-forward projections, while a separate readout head converts selected hidden states into option probabilities.

Only about 9.3 million parameters are trainable: 8.8 million in the adapter and approximately 460,000 in the head. That is roughly 1.9% of the frozen backbone's parameter count.

Unlike a conventional classifier, Kev does not have one permanent set of output classes. Options arrive with each question, allowing the same head to evaluate binary questions, categorical choices, or ordered scores. The model card specifies between two and 255 options for supported question types.

A causal transformer still produces the hidden representations, making Kev an LLM internally. At the interface, it behaves more like a typed probabilistic classifier.

One Prefill Pass Handles Multiple Isolated Questions

Kev packs the document and all its questions into one token sequence. Conceptually, the input follows this structure:

<state> document
<q> question one <opt> option A </opt> <opt> option B </opt> <decide>
<q> question two <opt> option A </opt> <opt> option B </opt> <decide>

A custom block-causal attention mask controls how parts of the sequence interact:

1. The document is encoded as the shared state.
2. Every question can attend to the state and tokens in its own branch.
3. A question cannot see another question or its options.
4. Position IDs restart after the state for each branch.

This prevents answers from leaking between questions while preserving a shared representation of the source document. All branches are evaluated in the same model call, and Kev stops after the prefill computation. There is no autoregressive decoding loop.

Without decoding, Kev has predictable output shapes and avoids malformed JSON, explanatory digressions, or answers outside the permitted choices. The approach can also help when an application needs many independent decisions about the same document.

Additional questions are not computationally free. Every branch adds tokens, option representations, and attention work. Kev removes serial answer generation and cross-question attention, but latency and memory use still depend on the number and length of the branches.

A Pointer Head Produces the Probabilities

For each question, Kev takes the hidden state at the <decide> token and projects it from 896 dimensions to a 256-dimensional query. It also projects the hidden state at the end of every option, marked by </opt>, into a 256-dimensional key.

The pointer head calculates a scaled dot product between the decision query and each option key. A softmax over those scores produces a distribution whose values sum to one. Cross-entropy training pushes probability toward the labelled option.

Kev exposes three question types:

The trained readout produces these probabilities directly, without parsing generated text or inspecting a chatbot's written confidence claim. This gives downstream software a cleaner input, although a softmax value is not automatically a well-calibrated estimate of real-world correctness.

Option construction remains part of the model's behavior. Different wording or ordering can change the hidden states and, in turn, the distribution. If the correct answer is absent from the supplied options, Kev has no open-ended way to recover it.

TypeSafe Compatibility Does Not Mean Jev Equivalence

The project describes Kev as reproducing an architecture inferred for TypeSafe's Jev and implements TypeSafe's public /v1/systemone API contract. That compatibility applies to the request and response interface: software written for the contract can work with Kev's typed decisions.

There is no evidence that Kev uses TypeSafe's internal code, training data, weights, or exact architecture. The published results also do not demonstrate behavioral parity with Jev. “Jev-like” is therefore the more accurate description.

Kev provides an inspectable implementation for studying shared-state attention, isolated question branches, direct probability readouts, calibration, and API-level interoperability without access to a proprietary system.

LoRA Makes MacBook Training Practical, With Caveats

The model card reports FP32 training and serving through Apple's Metal Performance Shaders backend and describes the original checkpoint as laptop-trained. Kev can therefore run and be adapted on an Apple-silicon MacBook Pro without a discrete NVIDIA GPU.

LoRA is central to that feasibility. The backbone remains frozen while low-rank updates are trained across the attention projections and feed-forward layers. Kev uses rank 16, alpha 32, and 0.05 dropout across all 24 transformer layers.

The v0.1 release archive is about 38 MB because it contains the adapter, pointer head, tokenizer files, evaluation output, and training log instead of another full copy of Qwen. Users must still obtain the base model. At FP32 precision, 494 million backbone parameters alone require roughly 2 GB before accounting for activations, temporary tensors, the adapter, and training state.

The published evidence does not give a universal memory requirement, training time, or throughput figure for every MacBook Pro configuration. “Runs on a MacBook” does not mean “runs equally well on any Mac.” Training will require more unified memory than loading the model for inference.

The adapter and head use the Apache 2.0 license, as does the stated Qwen2.5-0.5B base. The datasets retain their respective licenses, which developers need to examine separately before redistributing derived data or deploying a retrained checkpoint.

The Training Mix Covers Six Classification Problems

Kev-0.5B was trained on approximately 13,000 examples assembled from Banking77, BoolQ, AG News, MNLI, SST-5, and Yelp Review Full.

The mixture covers intent classification, binary question answering, topic classification, natural-language inference, and sentiment or rating prediction. It demonstrates how the same typed interface can represent several established NLP tasks.

However, the data does not amount to broad instruction training. All six sources are English classification datasets, and the model card says calibration has only been evaluated on the training distributions. Performance remains uncertain on unfamiliar document types, specialist terminology, adversarial inputs, other languages, or newly constructed decision tasks.

Training used states of no more than 384 tokens and question branches of no more than 1,024 tokens. Serving permits up to 8,192 tokens per branch, while the underlying Qwen model supports a larger context. Support for longer input does not show that Kev will retain its reported accuracy or calibration far beyond the lengths seen during training.

The 79.9% Accuracy Is a Narrow Result

On a 1,350-question held-out split drawn from the same six training sources, the model card reports:

Expected calibration error compares confidence with observed accuracy across probability bins; lower is better. Temperature scaling adjusts the sharpness of the model's logits after training, reducing the reported ECE in this evaluation.

The results are self-reported and unverified. The evaluation does not establish accuracy on out-of-domain tasks, compare Kev directly with Jev, or show how performance changes with longer documents and reordered options. A mixed aggregate can also conceal large differences among the six source datasets.

The card explicitly marks Kev-0.5B as the original prototype and directs practical users toward the newer Kev-0.8B, Kev-4B, and Kev-9B models. The 0.5B checkpoint is most useful as a reproducible baseline for understanding the mechanism.

Where Kev's Decision Architecture Fits

Kev is best suited to controlled applications that already know the allowed outputs and need multiple independent judgments about one shared state. Examples include local API demonstrations, classifier research, calibration experiments, document-routing prototypes, and comparisons between direct probability readouts and generative prompting.

Its restrictions are equally clear. Kev cannot write a rationale, propose a missing category, quote supporting evidence, or hold a conversation. Its small backbone and limited training set constrain the reasoning it can perform, while its probabilities may become unreliable when inputs differ from the evaluation distribution.

The model card excludes production decisions affecting people, including credit, hiring, medical, legal, fraud, and moderation workflows. Typed outputs are easier to integrate into software, but a clean schema does not resolve bias, distribution shift, weak calibration, or the consequences of an incorrect high-confidence decision.

Kev also requires its custom masking, packing, pointer-head, and serving code. It should not be treated as an ordinary chat checkpoint that can be dropped into any text-generation pipeline.

Final Thoughts

Kev-0.5B is more compelling as an architectural demonstration than as a competitive AI model. It shows how a frozen, sub-billion-parameter LLM can become a typed decision system through lightweight adaptation, isolated question branches, and a trained pointer head. The model avoids decoding and returns bounded probability distributions that application code can consume directly.

Its reported accuracy is too narrow to justify production confidence, and the project has already moved to newer checkpoints. Kev-0.5B's lasting value is its inspectability: developers can examine how the state, masks, decision tokens, option representations, and calibration procedure work together on hardware suitable for local experimentation.