No items found.

OrionMoE-Small-v1.0: Rethinking How Tabular Models Spend Their Computation

A 37.7M-parameter Mixture-of-Experts tabular foundation model whose router is conditioned on a learned summary of the dataset. Its first version already competes with frontier tabular foundation models up to twice its size.

4 mins

OrionMoE-Small-v1.0 is the first model in Lexsi Labs’ OrionMoE family. It is a 37.7M-parameter tabular foundation model that classifies new rows in a single forward pass, with no fine-tuning. To our knowledge, it is the first tabular foundation model whose experts form the core of the backbone, with routing conditioned on a learned summary of the dataset. In its first version, it is the first MoE model to stand alongside frontier dense models. It rates within 31 Elo of TabPFN-3 on TabArena, above it on OpenML-CC18, and above Xiaomi-TabLDM on every suite where both are reported. Early access is open through the Lexsi API.

‍

Today we are releasing OrionMoE-Small-v1.0, the first model in the OrionMoE family of tabular foundation models from Lexsi Labs. It is an in-context classifier: given a labeled support table, it predicts the labels of query rows in a single forward pass, without updating its parameters. Its distinguishing component is a sparse Mixture-of-Experts (MoE) layer inside a dual-axis Transformer, whose router is conditioned on the feature token and on a learned dataset register computed from the support rows.

To our knowledge, OrionMoE is the first tabular foundation model whose experts form the core of the backbone and in which sparse expert routing is explicitly conditioned on a learned representation of the dataset.

It is also the first MoE tabular foundation model to stand alongside frontier dense models: in its first version, at 37.7M parameters, it rates within 31 Elo of TabPFN-3 on TabArena, above it on OpenML-CC18, and above Xiaomi-TabLDM, the only other MoE model in our comparison, on every suite where both are reported.

OrionMoE-Small-v1.0 · the first release in numbers
37.7M
total parameters, smaller than every medium and large model in the comparison
3 of 3
suites where it rates above Xiaomi-TabLDM (70M), the only other MoE tabular foundation model
+103
Elo above TabPFN-3 (53M) on OpenML-CC18 (1118 vs 1015)
1,379
Elo on TabArena’s small-dataset subset, ahead of TabPFN-3 (1,368)
Request early access →Read the technical report →Hosted Lexsi API · access by application
01
s

1. Motivation: tables vary, dense computation does not

In-context tabular foundation models such as TabPFN (Hollmann et al., 2025), TabICL (Qu et al., 2025), TabDPT (Ma et al., 2024) and LimiX (Zhang et al., 2025) have shown that a single pretrained network can be competitive across very different datasets. Most of them share one architectural property: the feed-forward transformations inside each block are dense and applied identically to every token, whichever feature or dataset it comes from. A new dataset changes the representations, through attention and context-dependent encoders, but not the computation applied to them.

The architectural gapToday a new dataset changes what the model represents, through attention and context-aware encoders. It does not change which transformations are applied.
Dense model with one shared pathway versus OrionMoE where each table picks its experts
Figure 1Same table shape, different computation. A dense model sends every table through one shared feed-forward pathway; OrionMoE lets each table select its experts.

Tabular data makes this a real constraint. Features can be continuous measurements, categorical codes, counts or ordinal quantities, with different distributions, missingness patterns and relationships to the target, and datasets differ in size, dimensionality and label balance. Context-aware encoders handle part of this by giving the same value different embeddings in different datasets. We hypothesize that the allocation of computation should depend on the data as well: different features and datasets may be better served by different learned transformations.

If we take that hypothesis seriously, at least three architectural directions open up. They are complementary rather than competing.

OrionMoE bet
Rethink representations
Build richer, distribution-aware encodings for categorical, numerical, missing and mixed-type data, rather than forcing every dataset through essentially the same encoding scheme.
Open direction
Make information exchange adaptive
Let the model decide how much to reason across rows, across features, or across groups of related variables, based on the structure of the task rather than a fixed pattern of attention.
OrionMoE’s central bet
Make computation conditional
Give the model a repertoire of learned transformations, and let it activate different ones for different features and different datasets, instead of applying one feed-forward network everywhere.

OrionMoE-Small-v1.0 places two bets: on the first and, centrally, on the third. Adaptive information exchange remains an open and promising direction that we expect to return to.

2. Heterogeneity is the domain, not the noise

Images share a grid. Text shares a vocabulary. Tables share almost nothing. One table mixes continuous measurements, categorical codes, sparse counts and missing values. Another, with the same number of columns, obeys entirely different statistical relationships. Consider the number 10: it might be an age, a count, a sensor reading, or an arbitrary label for a category. Its meaning lives in the column’s distribution, its relationships to other variables, and the labeled examples around it.

The value 10 in four columns: patient age, purchases last month, pump vibration and branch code, each with a different meaning
Figure 2The value 10 in four columns. Its meaning comes from the column’s distribution. Context-aware encoders give each occurrence a different embedding; OrionMoE also lets the router send it to different experts. Distributions are illustrative.

The field’s dominant response has been to adapt representations: encode each cell in the context of its column and its dataset, so that two identical values can mean different things. That is necessary, and OrionMoE invests heavily in it. But it may not be sufficient. When every dataset flows through the same dense transformations, a single set of weights must serve skewed and symmetric distributions, binary and high-cardinality features, ten-row and ten-thousand-row contexts, balanced and badly imbalanced targets. All of that diversity competes for the same shared capacity.

Our hypothesis is simple to state. If heterogeneity is the defining property of tabular data, a model should be able to adapt not only what it represents, but how it computes.

The hypothesisAdapt not only what the model represents, but how it computes.

3. Why Mixture-of-Experts, and why the router must see the dataset

A sparse MoE layer replaces one dense feed-forward network with a set of expert networks and a router that sends each token to a small subset of them (Shazeer et al., 2017; Fedus et al., 2022). The model gains a larger repertoire of transformations while evaluating only a few experts per token. In language models the router usually decides from the token’s own representation, which works because tokens carry broadly consistent meaning across inputs.

Tabular feature tokens do not. A router that sees a single token cannot tell whether it comes from a skewed column, a high-cardinality categorical, or a dataset with a rare target class. OrionMoE therefore asks its router a richer question. It conditions expert selection on two signals at once: the local representation of each cell, and a learned summary of the dataset derived from the labeled support examples. Two tokens with similar local representations can then be sent to different experts when they occur in different datasets, and tokens from different datasets with similar computational needs can share experts.

Two signals, one decisionThe router reads the cell’s own representation and a learned summary of the whole dataset, computed from the labeled support rows.
Token-only routing compared with OrionMoE dataset-aware routing, where a dataset register feeds the router
Figure 3Token-only versus dataset-aware routing. A token-only router decides from the cell alone; OrionMoE’s router also reads a dataset register built from the support rows.

4. How OrionMoE relates to prior MoE work in tabular learning

MoE has already been applied to tabular data. MixturePFN (Xu et al., ICLR 2025) uses a mixture of in-context prompters to scale TabPFN-style models to larger datasets. Xiaomi-TabLDM (2026) replaces the feed-forward layer of selected layers in its in-context predictor with MoE. MoE components also appear in task-specific tabular networks, for example as a projection head for masked-feature pretraining in MaskTab (2026). Table 1 compares OrionMoE-Small with the two in-context approaches. Of the three, OrionMoE-Small is the only one whose experts form the core of the representation backbone.

WorkWhere MoE is usedWhat the router seesAdaptation to a new dataset
MixturePFN
ICLR 2025
Copies of a TabPFN-style model, each specialized to one cluster of the training dataNon-learned: each test point goes to its nearest K-Means clusterFine-tunes one expert per cluster on the downstream data
Xiaomi-TabLDM
2026
In-context prediction stage only: sparse MoE replaces the feed-forward layer in selected layers of the ICL predictor; shared + top-K routed expertsThe row token’s own representation (linear router)None: in-context prediction
OrionMoE-Small
2026
Representation-learning backbone: sparse MoE replaces the feed-forward layer along the feature axis of the dual-axis blocks; shared + top-k routed expertsThe feature token, modulated by a learned dataset register, plus a dataset-level expert preferenceNone: in-context prediction
Table 1MoE designs in tabular in-context learning.

5. Inside OrionMoE-Small-v1.0

37.7M
Total parameters
Synthetic-only
Pretraining with extended O’PRIOR
In-context
No downstream gradient updates
Dataset-aware MoE
Sparse expert routing conditioned on dataset context

Most tabular foundation models adapt only their representations. OrionMoE-Small-v1.0 also adapts the computation applied to them: for every table, in a single forward pass, it selects which experts process each feature token. Three design choices make this possible:

01
Routing is conditioned on the dataset
The dataset register is updated by attention over the support representations. It rescales and shifts each token’s representation before the router scores it, and adds its own per-expert preference. These dataset-dependent terms are initialized conservatively, so routing starts out driven by token content and acquires dataset preferences during pretraining.
02
Experts shape the representations, not only the prediction
In Xiaomi-TabLDM, the MoE is confined to the final in-context prediction stage and routes row tokens; its feature-embedding and row-aggregation stages remain dense. In OrionMoE-Small, the MoE sits inside the representation-learning backbone, on the feature axis, so the choice of transformation is made per feature token while the representations are being built. This follows directly from the motivation that different features can require different transformations.
03
Routing is learned in pretraining and fixed at inference
Expert load is balanced with an adaptive selection bias rather than an auxiliary loss term, and no fine-tuning on the downstream dataset is required, unlike MixturePFN.
OrionMoE pipeline: labeled table and query rows in, dual-axis reasoning with sparse expert routing, class probabilities out
Figure 4OrionMoE-Small-v1.0 takes a labeled table and new rows to predict, reasons across rows and columns with distribution-aware encoding, dual-axis attention and sparse expert routing, and returns class probabilities for every query row in a single forward pass.

6. Do the experts specialize by dataset?

The most interesting question about a dataset-aware router is whether it uses the dataset at all. If routing collapsed to a few universal experts, or ignored the dataset register, the architecture would be MoE in name only.

It does not appear to. Across our routing analysis, expert selection is statistically associated with properties of the dataset: context size, dimensionality, class imbalance, and feature composition. Associations are measured as standardized effects between each characteristic and how often an expert is selected, and are tested with Benjamini–Hochberg correction for false discovery.

The patterns are distinct rather than uniform. One expert is selected more often as context size grows but less often as dimensionality rises, and is disfavored on binary-only and numeric-only tables relative to mixed-type ones. Another shows the opposite tendency on dimensionality and is favored on binary-only tables. A third becomes markedly less active as dimensionality increases. Different experts, in other words, appear to have settled into different statistical regimes.

Learned, not assignedNo expert was told which kind of table to handle. The preferences in Figure 5 emerged during pretraining.
Heatmap of association between dataset characteristics and how often each of five experts is selected
Figure 5Selected experts favor different dataset characteristics, a preference learned during pretraining and never assigned by hand. Each cell shows the standardized association between a dataset characteristic and how often the expert is selected: orange means the expert is chosen more often as the characteristic increases, blue means less often. For the two feature-composition columns, orange means the expert is favored on binary-only or numeric-only tables relative to mixed-type tables. Stars mark significant associations after Benjamini–Hochberg correction for false discovery.

These are associations, not mechanisms. They do not yet tell us what each expert computes, or how much of the model’s accuracy depends on this division of labor. But they are exactly the signature one would hope to see: a router that was given access to the dataset, and was never told what to do with it, learned to send different kinds of tables down different paths.

7. The evidence: a compact model in a field of larger ones

We evaluated OrionMoE-Small-v1.0 on five benchmark suites (TabArena, BeyondArena, OpenML-CC18, TALENT and BCCO) against recent tabular foundation models and established baselines. OrionMoE-Small-v1.0 is the first version of a new architecture, and it asks whether a backbone built on dataset-conditioned experts can stand alongside frontier dense tabular foundation models at a modest parameter budget. The results suggest it can. Figure 6 places every model by size and rating on each suite; Table 2 gives the full numbers, grouped by size.

Reading EloElo is estimated separately within each benchmark suite. Compare models within a column, never a rating from one suite with another.
Scatter plots of Elo against total parameters on TabArena, BeyondArena, OpenML-CC18 and TALENT, with OrionMoE-Small highlighted
Figure 6Elo against total parameters on each benchmark suite. At 37.7M parameters, OrionMoE-Small-v1.0 rates above TabDPT-1.3 (63M) on all four suites, above Xiaomi-TabLDM (70M) on all three where it is reported, and above TabPFN-3 (53M) on OpenML-CC18. Xiaomi-TabLDM is the only other MoE model in the comparison. Elo is computed within each benchmark and is not comparable across panels.
ModelParams (M)TabArenaBeyondArenaOpenML-CC18TALENT
Small models (<50M parameters)
Causilo36.11530126811701125
OrionMoE-Small MOE37.71320114911181024
TabICLv2281277108911211054
TabICLv1251072–768753
LimiX-16M161056–859872
Kumo-Tabular-Small281558–12411150
EXAONE-Tabular20.81515117610661040
Medium models (50–150M parameters)
Kumo-Tabular-Medium621726–13341265
TabPFN-3531351116610151021
TabDPT-1.363121510411061974
TabDPT-Turbo631090–952–
Mitra-v1631019–638616
Mitra-v2631533–980901
Xiaomi-TabLDM MOE701287–10831002
Large models (>150M parameters)
Kumo-Tabular-Large2151795–14471338
TabPFN-3.52201677134812311231
LimiX-2400176911881387–
TabFM408.7158312221372–
Table 2Elo ratings by model size on TabArena (N = 38), BeyondArena (N = 98), OpenML-CC18 (N = 48), and TALENT (N = 148). Higher is better; bold marks the best in each size group. Elo is estimated independently for each benchmark and cannot be compared across columns. A dash means unavailable results. Model size indicates total parameters.
Four findings stand out
Finding 01 · the headline
It is the strongest MoE tabular foundation model in the comparison
Xiaomi-TabLDM is the only other model in Table 2 built on Mixture-of-Experts, and at 70M parameters it is nearly twice the size of OrionMoE-Small-v1.0. OrionMoE-Small-v1.0 rates above it on all three suites where both are reported: TabArena (1320 vs 1287), OpenML-CC18 (1118 vs 1083) and TALENT (1024 vs 1002). It is the first MoE tabular foundation model to reach the level of frontier dense models such as TabPFN-3.
Finding 02
It competes with larger frontier models
OrionMoE-Small-v1.0 exceeds TabDPT-1.3, a 63M-parameter model, on all four suites in Table 2. Against the 53M-parameter TabPFN-3, it scores higher on OpenML-CC18 (1118 vs 1015), matches it on TALENT (1024 vs 1021), and stays close on TabArena (1320 vs 1351) and BeyondArena (1149 vs 1166). Parameter count alone does not establish runtime or memory efficiency, but these results show that a sparse, dataset-conditioned design can compete well beyond its size class.
Finding 03
It is strongest where data is scarce
On TabArena’s small-dataset subset (28 tasks), it reaches 1,379 Elo, ahead of TabPFN-3 (1,368) and TabICLv2 (1,316). Small datasets are where in-context learning matters most in practice, and where a model must extract the most from very little evidence.
Finding 04
It handles moderately skewed targets well
On TabArena’s imbalanced subset (16 tasks), it reaches 1,470 Elo, again ahead of TabPFN-3 (1,451) and TabICLv2 (1,368). Under extreme imbalance the picture is mixed: its TabArena rating falls to 1,166, while on OpenML-CC18, TALENT and BCCO its accuracy gap to the best baseline narrows as imbalance grows. It is suggestive that class imbalance is also one of the characteristics that expert routing tracks, though our experiments do not establish a causal link.

The table also shows clear headroom. Several models in our own size class, including Causilo, Kumo-Tabular-Small and EXAONE-Tabular, score higher on TabArena. This is version 1 of a new architectural direction, and we report the full picture because both what it achieves and how far it can still go are part of the result.

8. Beyond bigger Transformers

The familiar story of foundation models is a story of scale. Scale will keep mattering for tabular models too. But OrionMoE-Small-v1.0 points to a second axis of progress that has received far less attention: not how much computation a model has, but how it allocates that computation across the datasets it meets.

Tables are heterogeneous by nature, in their features, their distributions and the relationships that govern them. Perhaps the models that learn from them should be heterogeneous too: able to read a dataset, recognize the regime it belongs to, and route it through the transformations best suited to it.

OrionMoE-Small-v1.0 is our first step in that direction and, to our knowledge, the first MoE tabular foundation model to stand alongside frontier dense models.

Its competitive results at 37.7 million parameters, and experts that discovered dataset-dependent roles without being told to, make us confident the direction is worth pursuing seriously.

We do not think the next leap in tabular foundation models has to come only from larger or better-tuned Transformers. It may come from rethinking which computation each table deserves. If you work on tabular learning, foundation models, sparse architectures or real-world machine learning, we invite you to test that idea with us.

9. Early access

OrionMoE-Small-v1.0, the first release of the OrionMoE family, is available today through early access to the hosted Lexsi API. Researchers, developers and organizations can evaluate it on their own classification datasets, and we are especially interested in feedback from settings where tables are small, heterogeneous or imbalanced. Our research and benchmark findings are public in the technical report.

License note: OrionMoE-Small-v1.0 is accessed through the hosted Lexsi API and governed by the Lexsi Labs Source Available License (LSAL) v1.2, OrionMoE Edition, which is not an OSI-approved open-source license. Model weights and training code are not publicly distributed. Organizational evaluation and use carry additional conditions, and commercial exploitation and production deployment require separate permissions. Please review the full license before use. Questions: support@lexsi.ai.

The Lexsi Labs Team
Mohamed Bouadi
Research Scientist
Subscribe to Lexsi

Stay Up to Date With All the News & Updates

Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.