OpenOneRec: recommendation recast as sequence modelling with itemic tokens

Why generative recommendation needed a benchmark and a pipeline

The project positions itself as an open source framework intended to bridge the gap between traditional recommendation systems and large language models. The README argues that while generative recommendation has shown promise, existing models often struggle with isolated data silos and a lack of reasoning capabilities.

That is a specific pair of complaints. Silos mean a model trained on one domain cannot generalise, and missing reasoning means the model cannot explain or justify a recommendation. Both are addressed by turning recommendation into a language-shaped problem, which is what the rest of the repository implements.

Three pieces come together. RecIF-Bench is described as a recommendation instruction-following benchmark containing 100 million interactions from 200 thousand users across heterogeneous domains: short video, ads and product. OneRec-Foundation is a family of models at 1.7B and 8B parameters built on the Qwen3 backbone, with Standard versions trained on an open source dataset and Pro versions that add a hundred-billion-token industrial corpus from Kuaishou. The third is the full-stack pipeline, including data processing, co-pretraining and post-training, which the README says is open-sourced to ensure full reproducibility and to support scaling law research in recommendation.

The audience is therefore two-fold: applied engineers who want a recommendation model, and researchers who want to study how recommendation scales.

The news section dates the public release to 2026.1.1, when the technical report, the models on Hugging Face and the RecIF-Bench dataset with its evaluation scripts all became available.

RecIF-Bench organises eight tasks into four capability layers

The benchmark is the more interesting half for most readers, because it defines what the models are supposed to be good at.

The design principle is to assess the synergy between instruction following and domain specific recommendation. Tasks are arranged into four layers of increasing difficulty. Layer 0 is semantic alignment, covering item understanding. Layer 1 is fundamental prediction: short video recommendation, ad recommendation, product recommendation and label prediction. Layer 2 is instruction following, with interactive recommendation and label-conditional recommendation. Layer 3 is reasoning, which is recommendation explanation.

The layering is the point. A model can top the ranking metrics and still fail to follow an instruction, and a model can follow instructions and be useless at ranking. Layer 3 is measured with an LLM score rather than a retrieval metric, which reflects that an explanation is judged rather than counted.

The data spans three domains, described as short video for content, ads for commercial, and product for e-commerce. Those are the operating conditions of a large consumer platform, and the benchmark's value for an outside researcher depends entirely on whether those three resemble their own traffic.

The dataset and the evaluation scripts are open-sourced, so the benchmark can be run rather than only read.

Itemic tokens bridge the modality gap

The methodological core is a representation decision. The README describes the framework as reframing recommendation as a general-purpose sequence modelling paradigm, and the first step is treating items as a distinct modality.

Items become tokens through what the README calls Itemic Tokens, derived from hierarchical vector quantization. The effect is that the language model can process interaction history as a cohesive context sequence, the same way it processes words, instead of receiving a list of opaque identifiers it cannot reason about.

This is where the claim about reasoning comes from. If the model reads a user's history as text-like context, it can attend to relationships between items in a way that an ID lookup table cannot express. It is also where the collaborative signal enters, because the quantization is learned from interaction data rather than assigned arbitrarily.

The training recipe is described in three stages for pre-training and post-training. Pre-training integrates collaborative signals through Itemic-Text Alignment and Full-Parameter Co-Pretraining, meaning the item representation and the language model are trained together rather than the item side being frozen.

Post-training then proceeds in three numbered stages. Stage 1 is multi-task supervised fine-tuning for basic instruction following. Stage 2 is on-policy distillation, described as restoring general reasoning performance that the recommendation fine-tuning may have disturbed. Stage 3 is reinforcement learning to enhance recommendation capabilities.

The ordering is the interesting engineering judgement. General purpose reasoning is treated as something that gets damaged by task tuning and has to be put back, rather than as a property the fine-tuning preserves.

Four checkpoints and two different data budgets

The model zoo is small and readable, which makes the comparison between variants straightforward.

OneRec-1.7B and OneRec-8B use the Qwen3-1.7B and Qwen3-8B backbones respectively and are the standard versions trained on open source data, about 33 billion tokens. OneRec-1.7B-Pro and OneRec-8B-Pro are the scaled-up versions with expanded datasets, about 130 billion tokens, which the introduction attributes to a hundred-billion-token industrial corpus from Kuaishou.

So the Pro variants are not a different architecture. They are the same two sizes trained on roughly four times the tokens, with the difference being the inclusion of proprietary industrial data that outsiders cannot reproduce. That distinction has direct consequences for anyone planning to use this work.

The open data versions are the ones you can retrain and extend. The Pro versions are the ones whose reported numbers you cannot independently reproduce, because a large part of their training corpus is not distributed. The README is not hiding this, and it is stated in the model table rather than in a footnote, but the two are easy to blur together when they are quoted as a family.

All four are available on Hugging Face, and the series is described as enhanced with Itemic Tokens for modality alignment and trained through a multi-stage protocol.

Reading the results table honestly

The README reports state-of-the-art results across RecIF-Bench tasks against baselines SASRec, TIGER and LC-Rec, and the table is worth reading rather than skimming.

OneRec-8B-Pro is the best column almost everywhere: Recall@32 of 0.0369 on short video, 0.0964 on ads, 0.0538 on product, 0.0235 on label-conditional recommendation, an AUC of 0.6912 on label prediction, 0.3458 on interactive recommendation, and the highest LLM scores on item understanding and recommendation explanation.

But the smaller standard model does not sweep the board. Against LC-Rec, OneRec-1.7B is lower on ad recommendation, 0.0707 against 0.0723, lower on product recommendation, 0.0360 against 0.0416, and clearly lower on interactive recommendation, 0.1941 against 0.2394. The 8B standard model recovers and passes LC-Rec on those tasks, 0.3032 on interactive recommendation.

So the pattern is that the instruction-following layer, layer 2, is where the model size and the Pro data matter. On the plain ranking tasks, a well-tuned traditional baseline is in the same range as the small model.

That is a more useful reading than the headline. Generative recommendation is not obviously beating the classical baseline at ranking; the claim is about what it can additionally do, such as follow an instruction or explain a decision, where SASRec and TIGER have no score at all in three rows.

Cross-domain transfer on the Amazon benchmark

The second results table tests the silo problem directly, on the Amazon Benchmark across 10 datasets, and the README reports an average 26.8 percent improvement in Recall@10 over the second-best method with zero-shot or few-shot transfer.

The per-domain numbers back that up, with OneRec-Foundation using text-augmented itemic tokens ahead of all three baselines in every domain listed. Baby goes from 0.0344 for the best baseline to 0.0513, Beauty from 0.0764 to 0.0924, Cell Phones from 0.0883 to 0.1036, Grocery from 0.0790 to 0.1029, Health from 0.0616 to 0.0768, Home from 0.0293 to 0.0390, Pet Supplies from 0.0612 to 0.0834, Sports from 0.0418 to 0.0547, Tools from 0.0438 to 0.0593 and Toys from 0.0549 to 0.0953.

Two things are worth flagging. First, the absolute numbers are small in every domain, which is normal for Recall@10 on sparse retail interaction data and means the practical headroom over a well-tuned baseline is modest even where the relative improvement is large. Second, the metric note says the result uses OneRec-Foundation with text-augmented itemic tokens, which is a specific configuration and not necessarily identical to the default itemic token setup used elsewhere.

For an outside team, this table is the most directly actionable part of the README, because it is the one that uses public datasets rather than Kuaishou's own traffic.

A repository laid out as a pipeline, with gaps in the instructions

The top level listing reads like the stages of the pipeline itself: benchmarks/, data/, pretrain/, tokenizer/, verl_distillation/ and verl_rl/, plus assets/ for the figures. The two verl_ prefixed directories indicate that distillation and reinforcement learning stages are separate components rather than flags inside one training script, which is the right shape if you want to run the stages independently.

What the repository does not contain is an installation guide. There is no pip install line, no environment specification and no quick start in the README, so there is nothing to quote for a first run. The README points instead at the pieces: the models on Hugging Face, the RecIF-Bench dataset and evaluation scripts, and the arXiv paper linked as the technical report at arXiv 2512.24762.

The licence has a similar split. The README badge reads Apache 2.0 and the badge is what a reader sees first, but the repository's own licence metadata records the value as unknown, and no LICENSE file appears in the top level listing. If your process checks licence fields, the field will come back empty.

On maintenance, the repository is not archived, the last push was on 2026-05-18, and it publishes no GitHub releases. Version identification therefore comes from the model names and the paper rather than from tags, and the pipeline code is versioned only by commits.

Editorial conclusion

Adopt OpenOneRec if you are working on generative recommendation and want both a benchmark and a training pipeline to reproduce, since RecIF-Bench, the data processing, co-pretraining and post-training code are all in the tree, and the 1.7B model is small enough to study on a single accelerator. Do not adopt it if you need a serving-ready recommendation stack or a production-grade licence position, because the README publishes no installation instructions, no deployment path and the repository records its licence as unknown even though the badge shows Apache 2.0. Before you start, verify two things: which model you want, since the Standard versions are trained on about 33B tokens of open data while the Pro versions use roughly 130B tokens including Kuaishou's industrial corpus, and whether RecIF-Bench covers the domains and tasks your own system is judged on, since the eight tasks are fixed.

Frequently asked questions

Official sources

1. Issues
2. Kuaishou-OneRec/OpenOneRec on GitHub
3. README