Kev: Lightweight Local Decision-Making Model Based on Qwen3.5

September 21, 2026October 4, 2026

At a Glance

Values determined by this site’s code when the information was collected. Dates are JST.

What we checked ourselves

• Kev-4B: Gave 20 decision questions we wrote ourselves through llama.cpp’s /v1/systemone on our CPU-only server (3 threads, llama.cpp b11379): 18 correct in Japanese and 19 in English.

Details and conditions are in “Our Own Measurements” below.

Overview

“Kev," a lightweight decision-making model family built on Qwen3.5 that can be trained and run locally, has been released and is generating significant buzz in the open-source community. Designed with reference to the architecture of the closed decision-making model “Jev," Kev consists of models with 0.8B, 4B, and 9B parameters. It features the ability to simultaneously process different types of questions in a single request—such as “yes/no (noul)," “choice," and “score"—aiming to enable developers to handle custom decision-making tasks on their own PCs or servers.

Why It Is Gaining Attention

Currently, a phenomenon that could be called a “Jev explosion" sparked by the emergence of Jev is occurring among developers, with active attempts to reproduce similar structured decision-making processes in open source. Because Kev makes its training code and evaluation data public and adopts the Apache-2.0 license, which is friendly to commercial use, it serves as an ideal verification target for engineers considering practical local applications.

Discussion Points

In community discussions, multi-faceted opinions are being exchanged, ranging from sharp critiques of Kev’s technical approach to specific application destinations and operational concerns. The main points of discussion are summarized in the following three areas.

Definition of “Jev-like" and Validity of Training Methods

Technical discussions regarding the selection of the base model and the learning process are actively taking place among participants. In particular, whereas the original Jev is reported to be trained using RLCD, Kev is built based on a Qwen model trained via RLHF, raising the question of whether it can truly be called “Jev-like." Furthermore, severe opinions have emerged suggesting that projects simply placing a Jev-like API on top of existing LLMs misunderstand the essence of Jev. The true value of Jev lies in its unique training data and training methodology rather than its architecture, and concrete experiential accounts have been reported stating that when several open-source Jev-like models were actually tested on language tasks, their performance was significantly inferior compared to the original Jev.

Practical Use Cases in Business Automation

Many ideas have been shared about how this type of ultra-lightweight decision-making model can be useful in actual development and business processes. In addition to typical tasks such as automated ticket routing and customer frustration evaluation in customer support, proposals were made to utilize it for enforcing style guides and React component creation rules in front-end development. This is expected to automatically detect and correct UI/UX discrepancies and code duplication, significantly reducing the burden on developers. Furthermore, mention was made of the possibility of achieving high accuracy while suppressing computational costs compared to using massive models in spam email filtering.

Operational Constraints and Challenges of Local Execution

Discussions also touched upon realistic constraints when introducing decision-making models into practical operations. It has been pointed out that because these models lack “tool calling" capabilities to invoke external tools, the knowledge cutoff (outdated information) tends to become problematic. Therefore, operational concerns were indicated that continuous fine-tuning may be necessary to continue operating locally, or developers are forced to periodically migrate to newer models. In addition, alternative means such as “logan-markewich/jeff" and “bespokelabsai/nimble" were cited as competing projects when making or using Jev-like models, and discussions were held on where the merits of introducing a lightweight model dedicated to decision-making lie compared to the latency when running general-purpose LLMs (such as Gemma 4 12B) locally.

Community Reactions

Skeptical Perspectives on Training Methods and “Jev-ness"

Within the community, diverse opinions including severe viewpoints were exchanged regarding whether open-source decision-making models like Kev can serve as an alternative to the original Jev. One participant raised the question of whether the resulting model can truly be called “Jev-like," given that Jev is essentially trained via RLCD (reinforcement learning related methods), whereas the Qwen model on which Kev is based is trained using RLHF. Furthermore, there was a指摘 that projects constructing nothing more than a Jev-like API wrapper on top of existing LLMs miss the fundamental point. The view is that the reason Jev is special lies in its unique training data and training methods, and the architecture itself is merely a straightforward structure with a text encoder and parallel prediction branches. Negative user experiences were actually reported, stating that when multiple open-source Jev-like models were tested on language tasks, their performance was extremely inferior compared to the original Jev.

On the other hand, some participants questioned the difference between Jev and traditional classification neural networks, voicing requests for technical clarification on the mechanism itself, which receives text input and performs one-shot classification without additional training data. Lighthearted reactions were also seen, such as suggesting the name “Qev" since it is based on Qwen3.5, alongside interest in deployment requirements such as what specific specifications are demanded to run it locally.

Expectations for Application Potential in Business and Development Pipelines

Regarding the specific challenges that decision-making models can solve, numerous positive expectations and novel ideas were contributed. There were voices welcoming the direct link to simplifying internal routing logic, with expectations that decision-making models based on Qwen3.5 will contribute to business automation.

Particularly as an application to development workflows, a use case was proposed to enforce style rules and React component creation rules in front-end development. The concept is that if the model’s context window becomes larger, instead of relying on conventional style guides, decision trees could be built to automatically prevent UI and UX discrepancies and the duplicate creation of components. For engineers currently spending a significant amount of time on UI correction work, such decision-making models are perceived as an attractive solution.

Opinions examining applicability to spam filtering were also observed. Although 27B-class models are routinely used for spam determination to obtain high accuracy, high computational costs remain an issue, and discussions suggested that costs could be substantially reduced if they could be replaced by lighter decision-making models. Furthermore, interest regarding integration with agent technology was expressed, asking whether they can be incorporated into the internal judgment of coding agents or if they should be utilized in a completely different context.

Operational Cost, Maintainability, and Realism in Local Execution

On the operational side, discussions unfolded concerning concerns about the limitations specific to decision-making models and the significance of local operation itself. A major concern raised is the “knowledge cutoff" (degradation of information freshness) caused by the lack of tool-calling capabilities. Because external latest information cannot be dynamically retrieved, operational burdens were pointed out: self-hosting locally requires continuous additional training of the model, and even when using closed services, practicality cannot be maintained without continuously migrating to newer versions.

Regarding inference speed and model size, experimental examples were shared showing that even when a dense general-purpose model like Gemma 4 12B was run on an older local PC, it recorded sufficiently low latency (such as the early 200 milliseconds per step). This raised the question of where to find the substantive gain of introducing a specialized lightweight model when general-purpose models can achieve low latency by enhancing hardware. In addition, the existence of implementations such as “logan-markewich/jeff" and “bespokelabsai/nimble" was shared as preceding or similar open-source projects.

Overall, there is a positive reception that the boom sparked by Jev has caused many companies and developers to recognize that “their use cases might function well enough with System One-like decision-making models." As a result, prospects were discussed that movements to leverage open-source options like Kev or fine-tune with custom data to run models on private infrastructure will likely accelerate.

Our Own Measurements

Values we measured ourselves on our server (no GPU) by actually reading and running this model’s files — not figures copied from the model card. How we measure, and the results for every model: Our Measurements.

Decision-Model Evaluation on Our Own Tasks

We gave this model 11 situations with 20 questions that we wrote ourselves (yes/no, named options and ordered levels), through the /v1/systemone endpoint of llama.cpp’s llama-server (compatible with the TypeSafe API), once in Japanese and once in English. The two languages say the same thing and share the option names (such as billing). Each question states the rule to apply in the situation or the question so that it has a single correct answer; we checked every answer, and our code also re-computes the ones that depend on dates, amounts or times. The code decides right or wrong (yes when the probability of yes is 0.5 or more; for options and levels, the most probable one). These are not benchmark questions, and the result is not a general score of the model.

Conditions: Neoverse-N1, 3 threads, no GPU, llama.cpp b11379, Kev-4B-Q4_K_M.gguf (Q4_K_M), method kev, 4,096-token context. The time per decision is measured from sending one situation (1 to 3 questions) until the answer arrives, on a CPU — it is not a guide to GPU speed. The probabilities are scaled with the temperatures stored in the model file and, as llama.cpp notes, are not guaranteed to be calibrated.

This article is about a model family rather than a single repository. The figures below are for Kev-4B, the GGUF conversion of jaredpalmer/kev-4b by ggml-org, which we also measure as a reference for other decision models.

In Japanese it got 1 fewer right than in English (18 vs 19 of 20).

Other rows are other decision models measured the same way (“reference” rows are models we measure for comparison). Methods differ by model, and each model is measured with its own quantization.

Times marked (GPU) were measured on a cloud GPU and the others on our CPU, so the times cannot be compared across those rows; the numbers of correct answers can.

Answer to Each Question

The full text of every situation and question, with the reason for each correct answer, is on Our Measurements.

To Try the Same Thing

We started the official llama.cpp build with this command (the model file name is the one we downloaded) and sent each situation as below:

llama-server -m Kev-4B-Q4_K_M.gguf -t 3 -c 4096 -b 2048 -ub 2048 -np 1 --no-mmproj --host 127.0.0.1 --port 8080

curl -s http://127.0.0.1:8080/v1/systemone \
  -H 'Content-Type: application/json' \
  -d @- <<'EOF'
{
  "model": "lmw",
  "state": "Customer message: My card was charged twice for order #5521 yesterday. Please refund the duplicate charge.",
  "questions": {
    "route": {
      "type": "choice",
      "instructions": "Which team should handle this message?",
      "criteria": {
        "billing": "Payments, charges and refunds",
        "shipping": "Delivery and package tracking",
        "technical": "Bugs, errors and outages",
        "sales": "New purchases and quotes"
      }
    },
    "refund": {
      "type": "noul",
      "instructions": "Is the customer asking for money back?"
    },
    "outage": {
      "type": "noul",
      "instructions": "Does the message report that a service is down?"
    }
  }
}
EOF

What to Read Next

• Read the weekly roundup that covered this story → Open-Weight Models Weekly: The MiMo-V2.6 Family & Transformers GGUF Support

Sources

• https://github.com/jaredpalmer/kev/tree/main
• https://news.ycombinator.com/item?id=49783999

Update History

• 2026-10-03: Added our own measurements: decision-model evaluation on our fixed tasks.