Valen: a Jev-like model that returns decision probabilities

Probabilities over candidates, not generated text

Valen, named 万澜 in the project, is a multimodal decision model inspired by Jev, and the slogan line is System One Model, now with vision. The input side is text, images and video, and the output side is decision probabilities. Concretely, the model evaluates the input against task instructions and returns probabilities over a set of candidates that the caller supplies. That is a different contract from what a chat model offers. A general purpose model is asked to produce a response, and you parse whatever comes back. Valen is asked to score a menu of options you already defined, which means the caller keeps control of the action space and the model keeps the ranking. The stated purpose is to give software a structured decision interface, and the audience is teams that want to train such a model themselves rather than call a hosted endpoint. The repository was open sourced on 2026-09-23 together with the Valen-preview-0923 model and its training data.

One repository holds implementation, data, training and evaluation

The layout tells you this is research code that is trying to be reproducible rather than a library with a stable public API. The top level contains the model implementation in valen/, data processing under data/, training configurations in configs/ with a train subdirectory for the SFT and experimental RLCD runs, an evaluation/ directory, a cookbook/ directory with notebooks, scripts/, docs/, tests/ and a history/ folder. The package configuration confirms the split, because setuptools is told to include the valen* and evaluation* packages. The README states that the repository includes the model implementation, data processing, SFT and experimental RLCD training, and inference and evaluation commands, with support for training on your own data. So the entry points you need for production use, inference and evaluation, sit in the same tree as the training pipeline, and the training configuration is where the SFT versus RLCD choice is made. A second language signal matters for expectations: the primary language of the repository is Jupyter Notebook, which fits a project whose documented usage examples are notebooks rather than a CLI with man pages.

Getting a model and running the API quick start

The documented route to a first result is the hosted API rather than a local install, and the README points at a notebook for it. On 2026-10-13 the project added API access to valen-preview-0923, valen-0-8b, valen-2b and valen-4b, and it tells users to see the API quick start notebook in cookbook/api_quickstart.ipynb for usage examples. The weights themselves are published on Hugging Face, with Valen-0.8B, Valen-2B and Valen-4B as the released model family from 2026-10-07, the training dataset Valen-Training-General-100k, and the evaluation sets VisualDecisionBench and Valen-Eval-Game. There is also a demo Space for trying the model in a browser, and from the same 2026-10-13 entry, ONNX and GGUF versions of the models are available, which matters if your runtime is not PyTorch. The project also publishes its own models under the Valen-Team organisation on Hugging Face. Nothing in the documentation states a token cost, a request limit, or the licence terms of the hosted endpoints, so treat the API as a demo surface until you read its own terms.

The dependency set is pinned exactly, which helps and hurts

The package metadata is unusually strict about versions, and the pins tell you a lot about what the code expects. Python 3.10 or later is required, and every core library is fixed to a single version:

requires-python = ">=3.10"
dependencies = ["torch==2.6.0", "torchvision==0.21.0", "transformers==5.4.0", "peft==0.18.1", "huggingface-hub==1.7.1", "httpx[socks]>=0.28,<1", "numpy>=1.26", "Pillow>=10", "av==16.1.0"]

Reading that list tells you the video path is handled by PyAV, images by Pillow, the model stack by transformers and peft, and that HTTP goes through httpx with SOCKS support, which is the dependency you would need for a proxy in a restricted network. The extras are just as deliberate. Tests use pytest, caption data and experiments pull in boto3, the experiments extra adds matplotlib, and model-formats installs the ONNX and GGUF tooling:

model-formats = ["onnx==1.19.1", "onnxruntime==1.23.2", "gguf==0.19.0"]

There is also a decision-index extra that installs a package straight from a git commit hash, which is convenient for reproducibility and a poor choice for long lived deployments. The upside of exact pins is that a working configuration can be reconstructed, and the downside is that every pin is also an upgrade wall you will have to move deliberately.

Training paths: SFT, experimental RLCD, and multi-GPU work

The training story has two labelled tracks. The configuration badge names them as SFT and experimental RLCD, and the README repeats that the repository carries SFT training and experimental RLCD training. The word experimental is doing real work there, since only the SFT path is described as the established one, and the badge itself labels RLCD as experimental. Training on your own data is supported, and the 2026-09-30 news entry records the infrastructure work that made that practical: Flash Attention 2 support, training across multiple nodes and GPUs, and improved GPU memory utilization during training. That entry is about throughput and memory rather than about model quality, and it is the only statement in the documentation about scaling, so the honest reading is that multi-node training works but the recipe for it is not written down here. The released training data is Valen-Training-General-100k, published with the preview model, which gives you a starting corpus rather than a recipe. If your own corpus is images and video with text instructions, you have the data format the project expects.

Evaluation is a first-class surface, with two benchmark datasets

The project ships evaluation code as a top level package and two distinct evaluation datasets, and that separation tells you how seriously the authors treat the decision interface. VisualDecisionBench was released with the 0.8B, 2B and 4B models on 2026-10-07 and is the benchmark for multimodal decision making. Valen-Eval-Game is a separate dataset aimed at the game tasks shown in the demo videos. The evaluation package configuration references two vendored pieces: an upstream jevbench component that carries its own LICENSE file, and a decision_index component that ships its own README and README_zh. That vendoring is not incidental, since the decision-index extra installs the same component directly from a pinned git commit. The practical implication is that the evaluation harness carries third party code and licence files inside the tree, and the extras for onnx and gguf exist so that the same models can be checked in the formats other runtimes use. The demo gallery gives a sense of the intended difficulty: Sokoban with a 13 step optimal solution, Frozen Lake with an 11 step safe route, a 22 step maze route, Lane Racer cleared in 10 steps, and Parkour Runner in 14 steps.

The project is young, unreleased and Apache-2.0 licensed

Two facts should shape any adoption decision. First, the repository publishes no GitHub releases, so there is no versioned artefact to pin your build to; the tags and the model releases on Hugging Face are the only versioning signals, and the last push was on 2026-10-16, with the newest model family published on 2026-10-07. Second, the licence is Apache-2.0, which permits use in proprietary products and requires that you keep the licence and notices, and the model weights and datasets on Hugging Face may carry their own terms that the repository does not restate. There is also a small inconsistency worth checking before you rely on the packaging: the project.urls section in pyproject.toml still points the repository and issue tracker at the Liuziyu77 organisation, while the code and the models live under Valen-Team. The documentation is also silent on a few things a production user would ask, including rollback, checkpoint naming, or what hardware a full training run needs, and there is a history/ directory in the tree that suggests the project keeps a record of its own past that is not explained in the README.

Editorial conclusion

Valen is worth evaluating if your application needs a scored decision from visual input rather than generated text, and if you can live with an exact dependency set and a research code layout rather than a packaged service. It is the wrong tool for general chat or document summarisation, since the output is a distribution over candidates you supply, and for teams that want a stable release cadence, because the repository publishes no GitHub releases and the last push was on 2026-10-16. Verify three things before committing: the licence obligations of the Apache-2.0 project, the exact version pins in pyproject.toml against the transformers and torch versions your environment already has, and the fact that the project.urls section in pyproject.toml still points at https://github.com/Liuziyu77/Valen while the code is published under the Valen-Team organisation. Then start with the cookbook/api_quickstart.ipynb notebook against valen-0-8b before committing to local training.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. README
4. Valen-Team/Valen on GitHub