TabFM, TabPFN, and TabICL: Do Tabular Foundation Models Replace Classical Machine-Learning Models?

How TabPFN, TabICL, and TabFM change model selection, and why classical methods remain relevant.

TabPFN, TabICL, and Google’s TabFM challenge classical models on tabular data. What does this mean for model selection, interpretability, operations, and teaching?

Why this development matters for data science

Public debate about AI mainly revolves around language, images, video, and chatbots. In my work and teaching, however, I mostly encounter tabular data: customers, transactions, deliveries, diagnoses, credit applications, machine states, or invoices. For many data scientists, tables remain the core of daily work.

The immediate reason for this article is Google’s announcement of TabFM on June 30, 2026. Google describes TabFM as a zero-shot foundation model for tabular classification and regression that uses training examples as context and produces predictions without dataset-specific fine-tuning or hyperparameter search (Kong and Das 2026). TabFM is therefore not an isolated case, but another indication that foundation models are becoming a relevant model class for tables as well.

I use the term foundation model here for a model that has been pretrained on many different tasks and then uses this pretrained knowledge for new datasets. TabPFN, TabICL, and TabFM change the usual modeling workflow: instead of training a model from scratch for each dataset and then generating predictions, a pretrained model is supplied with labeled examples as context.

In my view, tabular foundation models will therefore not simply replace classical machine-learning models. They do, however, change what counts as a good baseline, meaning a simple or established comparison model, how quickly first usable models are available, and which skills data scientists need for a justified model choice.

Why tables are difficult

A pixel has largely the same technical meaning across different images. A word can be processed in many texts with the same tokenization. A table column is different. The value 42 may mean age, revenue, temperature, or an arbitrarily encoded category. Columns have no universal semantics, and their order usually carries no natural meaning.

There is also heterogeneity within a dataset: numerical, categorical, and ordinal features, missing values, outliers, different scales, and highly imbalanced target variables. Many tables are small to medium-sized. They often do not arise from a clean research design, but as by-products of historically grown processes. A feature may change its meaning after a system migration; an apparently good predictor may contain information from the future.

This combination makes deep learning difficult to use. Neural networks are particularly useful where large amounts of data and reusable structure across datasets are available. With tables, sample sizes are often smaller, and the relevant relationships change from dataset to dataset. In a large benchmark study, tree-based models outperformed the deep-learning methods studied there on typical medium-sized tabular datasets; the authors discuss, among other factors, uninformative features and irregular target functions as possible reasons (Grinsztajn, Oyallon, and Varoquaux 2022). This finding does not apply to every task, but it helps explain why new neural architectures long failed to generally outperform classical methods on tables.

Why classical models have dominated for so long

Classical methods cover different requirements. Linear and logistic regression provide transparent baselines. Decision trees and random forests can capture nonlinearities and interactions (Breiman 2001). Gradient boosting combines many simple learners step by step into a model with lower prediction error (Friedman 2001). XGBoost, LightGBM, and CatBoost have developed this basic idea further in computational and algorithmic terms (Chen and Guestrin 2016; Ke et al. 2017; Prokhorenkova et al. 2018). AutoML systems additionally automate parts of model selection, hyperparameter tuning, and ensemble construction.

These models remain relevant. From a practical perspective, they benefit from established implementations in R and Python, and trained models can be deployed comparatively easily in many environments. For linear models, coefficients are directly interpretable under the respective model assumptions; for tree models, efficient model-specific explanation methods exist. A trained model can also be stored and often executed with low latency for new individual observations.

Classical baselines also have an important control function. If a complex model only slightly outperforms a logistic regression, that is relevant information about the additional value of the complexity. If even a simple model varies strongly across different samples, the data basis and evaluation design should be checked first.

What tabular foundation models do differently

Tabular foundation models move a substantial part of learning into pretraining. They are trained on many tasks before use, in the case of TabPFN, TabICL, and TabFM mainly on synthetically generated tables. The goal is not only to solve one prediction problem, but to learn a transferable strategy for new tabular tasks.

For a new dataset, the model receives the labeled training rows and the unlabeled test rows as context. This procedure is called in-context learning: the model uses the examples contained in the context for the new task without adjusting its weights through an optimizer. Predictions are produced in a forward pass through the neural network. The familiar fit() method may still appear in a Scikit-learn interface, but then it primarily prepares the context and loads the model. Christoph Molnar describes this shift as a move from “train and predict” to “pre-train and learn in context” (Molnar 2026a).

It is important to note that expensive training has still taken place. It has merely been shifted into upstream pretraining. The new dataset then becomes part of the computation at runtime. This explains both the fast adaptation to new tasks and some operational limits.

Figure 1: From dataset-specific training to a pretrained model with in-context learning

TabPFN as an example of prior-data fitted networks

TabPFN stands for Tabular Prior-Data Fitted Network. The basic idea is to generate many synthetic datasets from specified data-generating processes and train a transformer to predict the respective missing target values. In this way, the model approximately learns an algorithm for tabular inference rather than only the parameters of one specific dataset.

The version published in Nature in 2025, now usually called TabPFNv2, supports classification and regression as well as categorical and missing values. The study evaluates datasets with up to 10,000 rows, 500 features, and ten classes, and reports better results in this evaluation range than the tuned classical baselines included in the comparison (Hollmann et al. 2025). For regression, the model outputs a distribution over target values, not only a point estimate.

Development has continued since then: the official documentation lists newer model generations with higher size limits (Prior Labs 2026a). These vendor statements are relevant for practical tests, but they do not replace independent evaluation. Licenses also differ by version. According to the project documentation, the weights of TabPFNv2 can be used commercially with additional attribution; newer weights are partly subject to non-commercial terms or require a commercial agreement for production use (Prior Labs 2026a). It follows that licensing has to be checked separately for each model version.

The approach is also accessible from R. The tabpfn package integrates the Python model into familiar formula, recipes, and tidymodels workflows (Kuhn 2026). For experiments, this substantially lowers the entry barrier; the Python runtime, model weights, and hardware requirements remain part of the technical dependencies.

TabICL: in-context learning for larger tables

TabICL follows the same basic idea, but approaches scaling differently. The architecture first processes column and row information so that compact row representations are produced, and then performs in-context learning on these representations. This is intended to make computation more manageable for larger tables.

The ICML 2025 paper studies classification, describes pretraining on synthetic datasets with up to 60,000 rows, and applies the model to datasets with up to 500,000 rows. On 200 classification datasets from the TALENT benchmark, TabICL was on par with TabPFNv2 in the reported experiments and was systematically faster; on 53 larger datasets, it outperformed TabPFNv2 and CatBoost in that evaluation (Qu et al. 2025). These results apply within the described benchmark protocol. Whether they transfer to a specific corporate dataset has to be tested separately.

Since then, the project has documented TabICLv2 with classification and regression as well as optional fine-tuning. The corresponding report is currently a preprint, and project statements should be read accordingly (Qu et al. 2026; SODA, Inria 2026). The contrast with TabPFN is also organizationally interesting: the TabICL project provides code and weights under a permissive license. This already shows that “foundation model” does not denote a uniform operational or licensing category.

TabFM: Google’s zero-shot model for tables

TabFM is the most recent prominent addition to this model family. Google Research presents the model as a zero-shot approach for tabular classification and regression. Zero-shot does not mean here that the model works without examples in a strict sense. Instead, the labeled training rows are passed to the model as context; the model weights themselves are not adjusted for the concrete task (Kong and Das 2026).

Architecturally, TabFM combines elements already known from TabPFN and TabICL. According to Google, the model first processes tables with alternating row and column attention, then compresses each row into a dense representation, and finally uses a transformer over these compressed row representations for in-context learning (Kong and Das 2026). The model card on Hugging Face also states concrete limits of the released version: classification is designed for up to ten classes, memory use scales with the number of context rows, and behavior on very wide tables is not fully characterized (Google Research 2026a).

TabFM also follows a pattern in its training data that shapes this model class. Google states that TabFM was trained entirely on hundreds of millions of synthetically generated datasets, dynamically produced with structural causal models (Kong and Das 2026). This choice is plausible because real corporate data is often proprietary, sensitive, or difficult to use under licensing constraints. At the same time, it means that the quality of the synthetic prior is a central part of the model. For practice, this means that a good benchmark position does not automatically show whether the synthetically learned regularities fit a specific dataset.

The published performance numbers are relevant, but they are not yet an independent consensus. Google reports an evaluation on TabArena with 38 classification and 13 regression datasets between 700 and 150,000 rows. The standard version of TabFM produces predictions in a single forward pass; an ensemble variant adds, among other components, crossed features, SVD features, non-negative least-squares weighting, and Platt scaling for classification (Kong and Das 2026). The variants should therefore be read separately: the simple TabFM version represents the actual zero-shot experience, while the ensemble version already moves back toward additional modeling logic.

For production use, release conditions and infrastructure also matter. The code is available on GitHub under the Apache 2.0 license, but the model weights on Hugging Face are under a non-commercial TabFM license; the repository also notes that TabFM is not an officially supported Google product (Google Research 2026b, 2026a). In addition, depending on context size, latency requirements, and backend, such models may depend on GPU or other accelerator resources, or become economically sensible only with them. Google also announces an integration into BigQuery via AI.PREDICT (Kong and Das 2026). In my view, this combination makes TabFM a useful occasion for discussion: the technical development is moving closer to everyday data platforms, while licensing, support status, hardware requirements, and independent evaluation still need to be checked carefully.

Interpretability and operations

Tabular foundation models can achieve high predictive performance without extensive tuning. For production use, however, predictive performance alone is not sufficient. Inference time, calibration, robustness, privacy, monitoring, reproducibility, license conditions, and the question of whether a decision can be explained to affected people or domain experts are also relevant.

An important difference lies in the cost structure. A classical model can be expensive to train and tune, but then provide individual predictions cheaply. For a tabular foundation model, pretraining is outsourced; adaptation to the concrete dataset mainly consists of providing the training examples as context. For prediction, however, this context has to be processed. Molnar describes this as a reversal of inference economics (Molnar 2026b). This affects not only live operation, but also explanation methods that call the model many times.

Hardware thus becomes part of model selection in a way that benchmarks can easily hide. TabFM provides installation paths for JAX on CPU or GPU and PyTorch on CPU or GPU; the model card also states that memory use grows with the number of training rows because they are processed as context (Google Research 2026b, 2026a). For TabPFN, the recommendation is more explicit: the current documentation recommends a GPU for good performance, states that older GPUs with about 8 GB of VRAM can be practical, and notes that CPU use is mainly sensible for small datasets up to roughly 1,000 observations; for some large datasets, 16 GB of VRAM are mentioned (Prior Labs 2026b). TabICL automatically selects the inference device between CUDA and CPU, supports Apple Silicon via mps, but also recommends a GPU for larger datasets. For TabICLv2, the project gives an example of 50,000 rows and 100 features in under ten seconds on an H100 GPU; even larger datasets can be processed through CPU and disk offloading, although accuracy and runtime then have to be checked separately (SODA, Inria 2026).

An independent study, although based on older model versions, makes this point concrete. Bansal and Gangwani compare TabPFN 1.0 and TabICL-base with XGBoost, LightGBM, and random forest on an NVIDIA T4 GPU, and measure runtime, CPU RAM, and GPU VRAM in addition to accuracy. In their experiments, tree methods require no VRAM resources, while TabICL requires about 9 GB of VRAM and substantially higher latency on a Higgs-100k task; TabPFN achieves comparable accuracy on other tasks, but requires up to 4 GB of VRAM and does not process the full Higgs-100k task (Bansal and Gangwani 2025). These numbers cannot be transferred directly to TabFM, TabPFN-3, or TabICLv2. They do show, however, why hardware costs should not be treated as a side issue.

Table 1: Comparison of typical hardware and operational considerations

Model class / model	CPU use	Role of GPU or accelerator	Limitation
Linear models, random forest, XGBoost/LightGBM/CatBoost	often sufficient	optional for very large training runs or specific GPU implementations	tuning and feature engineering remain dataset-specific
TabPFN	according to the documentation, mainly sensible for small datasets	recommended for good performance; larger datasets may require 8–16 GB VRAM or hosted inference	context size and model version determine memory use and limits
TabICL / TabICLv2	possible; the device can be selected automatically	recommended for larger datasets; H100 example for 50,000 × 100 in under ten seconds	offloading can enable larger data, but shifts runtime and accuracy questions
TabFM	CPU and GPU backends documented	depends on backend, context size, and latency requirements	memory use grows with context rows; weights currently non-commercial

Model-agnostic methods therefore do not disappear. Permutation feature importance, SHAP, partial dependence, accumulated local effects, and surrogate models only require access to predictions in principle and remain applicable (Molnar 2022). But their costs and pitfalls do not remain the same. Many of these methods rely on repeatedly calling the same predictor under systematically changed inputs. For classical models, this is often cheap after training: a linear predictor, a random forest, or a gradient-boosting model can usually generate many predictions with little additional infrastructure. For tabular foundation models, by contrast, the context often has to be processed again; depending on model, context size, and hardware, an explanation can become noticeably more expensive than a single prediction. Shapley-based methods are a particularly clear example because exact values are combinatorially expensive and approximations also require many model calls (Lundberg and Lee 2017; Sena and Azevedo 2026).

This does not mean that transparency is impossible for tabular foundation models. There are first approaches intended to reduce the additional compute cost. ShapPFN integrates a Shapley-like additive decomposition into a PFN-like model and reports much faster explanations than KernelSHAP on standard benchmarks with similar explanation fidelity (Sena and Azevedo 2026). ExplainerPFN takes a different route and estimates feature attributions without direct access to a target model by pretraining a foundation model itself for Shapley value estimation (Fonseca and Stoyanovich 2026). KernelICL, in turn, makes the relationship between in-context learning and kernel regression explicit and produces predictions as weighted averages over training labels (Miftachov, Charron, and Valentin 2026). These papers show that interpretability is an active research topic. For practical model selection, however, they should not yet be equated with the established transparency of simple models or the mature tools for tree ensembles.

Correlations also continue to make interpretation more difficult. A surrogate first explains the behavior of its approximation, not automatically the inner mechanism of the foundation model. Batched implementations or specially trained explanation heads can reduce runtime; they do not turn a post-hoc explanation into a causal statement (Rundel et al. 2024; Molnar 2026b).

The following matrix summarizes these criteria qualitatively and conceptually. It contains no benchmark scores and describes typical tendencies, not guaranteed properties of a specific product or model version.

Table 2: Qualitative assessment of typical selection criteria for three model classes

Criterion	Linear/logistic models	Random forest and boosting	Tabular foundation models
Initial model quality	understandable baseline	often good results, partly with tuning	often good results with little tuning
Dataset-specific training	low	medium to high	low; pretraining is externalized
Inference costs	usually low	usually low to moderate	context-, batch-, and hardware-dependent
Interpretability	direct under assumptions	usually post hoc or tree-specific	mostly post hoc, often inference-intensive
Deployment	simple	established	weights, runtime, accelerator needs, and license have to be checked
Small data	often suitable starting point	often competitive	target area of many current models
Large data	usually manageable	usually manageable	depends on model version and architecture
Stakeholder explanation	comparatively easy	medium	tends to be more demanding

Do they replace classical models?

Tabular foundation models can take over parts of the previous modeling routine. If a usable baseline emerges quickly without extensive tuning, the value of a long manual hyperparameter search decreases. On small and medium-sized tasks, TabPFN, TabICL, and TabFM can therefore become regular comparison models. Molnar also notes that the prediction errors of such models may be comparatively weakly correlated with those of other methods, which makes them interesting for ensembles (Molnar 2026a).

They will not fully replace classical models in the foreseeable future. Logistic regression may be more appropriate when a small number of effects need to be communicated transparently. CatBoost or LightGBM may be more suitable when low single-prediction latency, simple on-premise deployment, or large-scale inference are central. A foundation model may be unsuitable despite a better average benchmark position if its license excludes the intended use, probabilities are poorly calibrated, or the data structure differs from the evaluation protocol.

It should also be noted that not every analysis is purely about prediction. Causal questions, parameter estimation, uncertainty communication, and scientific explanation require their own designs and assumptions. High predictive accuracy does not automatically answer, for example, which intervention would cause a change.

In my view, tabular foundation models therefore do not replace domain engagement with the data. They can take over part of the modeling routine, but not problem definition, data checking, or the justification of a decision.

What benchmarks can show, and what still has to be checked

TabArena is an important step because the benchmark is actively maintained, provides standardized protocols and stored predictions, and can incorporate new model versions (Erickson et al. 2025). Such a living benchmark is more informative than a static table whose implementations and model states age. At the same time, Molnar emphasizes that TabArena covers a curated selection of small to medium-sized IID tasks, and that an Elo ranking counts wins, not automatically their practical relevance (Molnar 2026c).

TabBench V2 is a current example of this more differentiated view. Neuralk describes the benchmark as an open evaluation suite for 189 OpenML classification tasks from different domains; compared methods include tabular foundation models, gradient-boosted decision trees, and tuned neural networks (Neuralk 2026). In the evaluation, modern tabular foundation models win a large share of comparisons against strongly tuned tree ensembles. Based on the same results, however, Molnar points to recognizable areas in which other model classes are ahead: for smaller to medium-sized tasks with few categorical features, the results tend to favor tabular foundation models; for smaller tasks with many categorical features and for larger binary tasks, boosting methods remain strong; for large, multiclass, or imbalanced tasks, tuned neural networks can be advantageous (Molnar 2026d). The important qualification is this: TabBench V2 considers classification, IID datasets from OpenML, and at most about 150,000 rows. Linear or logistic regression models are not included as simple baselines in this summary. The rules are therefore useful heuristics, but not general laws of model selection.

This boundary becomes even clearer in BeyondArena, a 2026 preprint on a broader benchmark for tabular foundation models. In addition to classical IID tasks, it considers temporal and grouped splits, very small to larger datasets, high dimensionality, text features, and high-cardinality categorical features. The authors report that current tabular foundation models are strongest mainly on small to medium-sized IID tasks, whereas classical tree methods and deep-learning models continue to dominate on non-IID, large, or high-dimensional tasks (Purucker et al. 2026). This does not mean that tabular foundation models are overrated. It means that the type of benchmark substantially influences which model class appears to lead.

Figure 2: Candidate model selection path based on the benchmark findings discussed

Benchmarks like these help with model development and systematic comparison. For a concrete model decision, however, they are only the starting point. A serious evaluation should at least:

• include a simple and a capable classical baseline,
• perform preprocessing and hyperparameter selection inside the resampling loop,
• respect groups, time, and dependencies in the split,
• check for leakage from data preparation and data-generating processes,
• consider several suitable metrics including calibration,
• measure runtime, memory, latency, accelerator needs, and costs under realistic conditions,
• examine robustness under missingness, drift, and relevant subgroups,
• and clarify licensing, privacy, and deployment before making a recommendation.

A good average rank therefore does not yet answer whether a model works reliably under the conditions of a concrete credit application, a specific machine, or a new cohort.

Consequences for data-science practice and teaching

When models deliver good results without extensive tuning, part of the work shifts. Data scientists may need less time for routine hyperparameter searches. In return, problem definition, data quality, leakage checks, evaluation, interpretability, deployment, monitoring, governance, and communication become more important.

For teaching, this means that classical methods remain part of the curriculum. Students need to understand linear and logistic regression, decision trees, random forests, and gradient boosting. They also need knowledge of cross-validation, metrics, feature engineering, overfitting, leakage, and baselines in order to evaluate new models. Without this foundation, one can operate a programming interface, but not make a defensible model decision.

There is also a new comparative competence: students should evaluate a transparent regression, a well-tuned boosting model, and a tabular foundation model under the same clean protocol. They should be able to justify why a small metric gain warrants additional latency or poorer explainability, or why it does not. R and Python are not competing camps here: R offers a clean evaluation logic through tidymodels, while Python currently provides more direct access to many foundation models. Professional practice needs to connect both.

My conclusion

Tabular foundation models have become a relevant model class. The published results on TabPFN and TabICL as well as Google’s release of TabFM justify evaluating them as an additional baseline for suitable tabular tasks (Hollmann et al. 2025; Qu et al. 2025; Kong and Das 2026).

In my view, this does not imply a replacement of classical machine-learning models, but a more demanding model selection process. Transparent statistical models, well-tuned tree methods, AutoML, and pretrained foundation models should be compared under a common evaluation protocol that fits the task.

The decisive question is therefore not which model class is best in general. The decisive question is which method is appropriate for the concrete task, the available data, and the operational and legal constraints. TabFM makes this question more current, but not simpler.

References

Bansal, Aayam, and Ishaan Gangwani. 2025. “Light-Weight Benchmarks Reveal the Hidden Hardware Cost of Zero-Shot Tabular Foundation Models.” https://doi.org/10.48550/arXiv.2512.00888.

Breiman, Leo. 2001. “Random Forests.” Machine Learning 45: 5–32. https://doi.org/10.1023/A:1010933404324.

Chen, Tianqi, and Carlos Guestrin. 2016. “XGBoost: A Scalable Tree Boosting System.” In Proceedings of the 22nd ACM SIGKDD International Conference on Knowledge Discovery and Data Mining, 785–94. https://doi.org/10.1145/2939672.2939785.

Erickson, Nick, Lennart Purucker, Andrej Tschalzev, David Holzmüller, Prateek Mutalik Desai, David Salinas, and Frank Hutter. 2025. “TabArena: A Living Benchmark for Machine Learning on Tabular Data.” In Advances in Neural Information Processing Systems: Datasets and Benchmarks Track. https://papers.neurips.cc/paper_files/paper/2025/hash/1697e3fb412da11dc9488249f9e7bbc9-Abstract-Datasets_and_Benchmarks_Track.html.

Fonseca, Joao, and Julia Stoyanovich. 2026. “ExplainerPFN: Towards Tabular Foundation Models for Model-Free Zero-Shot Feature Importance Estimations.” https://doi.org/10.48550/arXiv.2601.23068.

Friedman, Jerome H. 2001. “Greedy Function Approximation: A Gradient Boosting Machine.” The Annals of Statistics 29 (5): 1189–1232. https://doi.org/10.1214/aos/1013203451.

Google Research. 2026a. “TabFM 1.0.0 (PyTorch).” https://huggingface.co/google/tabfm-1.0.0-pytorch.

———. 2026b. “TabFM: Tabular Foundation Models.” https://github.com/google-research/tabfm.

Grinsztajn, Léo, Edouard Oyallon, and Gaël Varoquaux. 2022. “Why Do Tree-Based Models Still Outperform Deep Learning on Typical Tabular Data?” In Advances in Neural Information Processing Systems, 35:507–20. https://proceedings.neurips.cc/paper_files/paper/2022/hash/0378c7692da36807bdec87ab043cdadc-Abstract-Datasets_and_Benchmarks.html.

Hollmann, Noah, Samuel Müller, Lennart Purucker, Arjun Krishnakumar, Max Körfer, Shi Bin Hoo, Robin Tibor Schirrmeister, and Frank Hutter. 2025. “Accurate Predictions on Small Data with a Tabular Foundation Model.” Nature 637: 319–26. https://doi.org/10.1038/s41586-024-08328-6.

Ke, Guolin, Qi Meng, Thomas Finley, Taifeng Wang, Wei Chen, Weidong Ma, Qiwei Ye, and Tie-Yan Liu. 2017. “LightGBM: A Highly Efficient Gradient Boosting Decision Tree.” In Advances in Neural Information Processing Systems. Vol. 30. https://proceedings.neurips.cc/paper_files/paper/2017/hash/6449f44a102fde848669bdd9eb6b76fa-Abstract.html.

Kong, Weihao, and Abhimanyu Das. 2026. “Introducing TabFM: A Zero-Shot Foundation Model for Tabular Data.” Google Research. June 30, 2026. https://research.google/blog/introducing-tabfm-a-zero-shot-foundation-model-for-tabular-data/.

Kuhn, Max. 2026. “Tabpfn: Prior-Data Fitted Network Foundational Model for Tabular Data.” https://tabpfn.tidymodels.org/.

Lundberg, Scott M., and Su-In Lee. 2017. “A Unified Approach to Interpreting Model Predictions.” In Advances in Neural Information Processing Systems. Vol. 30. https://proceedings.neurips.cc/paper_files/paper/2017/hash/8a20a8621978632d76c43dfd28b67767-Abstract.html.

Miftachov, Ratmir, Bruno Charron, and Simon Valentin. 2026. “Interpretable Tabular Foundation Models via in-Context Kernel Regression.” https://doi.org/10.48550/arXiv.2602.02162.

Molnar, Christoph. 2022. Interpretable Machine Learning: A Guide for Making Black Box Models Explainable. 2nd ed. https://christophm.github.io/interpretable-ml-book/.

———. 2026a. “The Rise of Tabular Foundation Models.” Mindful Modeler. January 13, 2026. https://mindfulmodeler.substack.com/p/tabular-ml-is-about-to-get-weird.

———. 2026b. “The Interpretability Tax on Tabular Foundation Models.” Mindful Modeler. March 24, 2026. https://mindfulmodeler.substack.com/p/tabular-foundation-models-break-the.

———. 2026c. “TabArena Explained.” Mindful Modeler. March 31, 2026. https://mindfulmodeler.substack.com/p/tabarena-explained.

———. 2026d. “When Trees Still Beat Tabular Foundation Models.” Mindful Modeler. June 23, 2026. https://mindfulmodeler.substack.com/p/when-trees-still-beat-tabular-foundation.

Neuralk. 2026. “TabBench V2: The New Version of the Open Evaluation Suite for Tabular Classification.” June 3, 2026. https://www.neuralk.ai/post/tabbench-v2-the-new-version-of-the-open-evaluation-suite-for-tabular-classification.

Prior Labs. 2026a. “TabPFN Models: Capabilities, Limits, and Availability.” 2026. https://docs.priorlabs.ai/models.

———. 2026b. “TabPFN: Foundation Model for Tabular Data.” https://github.com/PriorLabs/TabPFN.

Prokhorenkova, Liudmila, Gleb Gusev, Aleksandr Vorobev, Anna Veronika Dorogush, and Andrey Gulin. 2018. “CatBoost: Unbiased Boosting with Categorical Features.” In Advances in Neural Information Processing Systems. Vol. 31. https://proceedings.neurips.cc/paper/2018/hash/14491b756b3a51daac41c24863285549-Abstract.html.

Purucker, Lennart, Andrej Tschalzev, Nick Erickson, Gioia Blayer, David Holzmüller, Alan Arazi, Alexander Pfefferle, Mustafa Tajjar, Gaël Varoquaux, and Frank Hutter. 2026. “Beyond IID: How General Are Tabular Foundation Models, Really?” https://doi.org/10.48550/arXiv.2606.30410.

Qu, Jingang, David Holzmüller, Gaël Varoquaux, and Marine Le Morvan. 2025. “TabICL: A Tabular Foundation Model for in-Context Learning on Large Data.” In Proceedings of the 42nd International Conference on Machine Learning, 267:50817–47. Proceedings of Machine Learning Research. https://proceedings.mlr.press/v267/qu25d.html.

———. 2026. “TabICLv2: A Better, Faster, Scalable, and Open Tabular Foundation Model.” https://doi.org/10.48550/arXiv.2602.11139.

Rundel, David, Julius Kobialka, Constantin von Crailsheim, Matthias Feurer, Thomas Nagler, and David Rügamer. 2024. “Interpretable Machine Learning for TabPFN.” In Explainable Artificial Intelligence, 465–76. Springer Nature Switzerland. https://doi.org/10.1007/978-3-031-63797-1_23.

Sena, Luan Borges Teodoro Reis, and Francisco Galuppo Azevedo. 2026. “Real-Time Explanations for Tabular Foundation Models.” https://doi.org/10.48550/arXiv.2603.29946.

SODA, Inria. 2026. “TabICL: Official Implementation.” https://github.com/soda-inria/tabicl.