Foundation models meet the spreadsheet: where TabPFN fits
A delivery team keeps a spreadsheet with one row per parcel: route, order value, weather, backlog and what happened during the journey. It wants to use past deliveries to help plan new ones. Should it start with a familiar statistical model, a tree-based model or a newer foundation model for tables such as TabPFN?
The rows and columns in that spreadsheet are tabular data. The prediction might be a category, such as late or on time; that task is called classification. Or it might be a number, such as minutes of delay; that is regression. Choosing between those questions matters more than choosing a fashionable model, because it determines what the system must produce and how we should judge the answer.
An ordinary model learns patterns from the records provided for a particular task. A foundation model has already been trained more broadly before it reaches that task. TabPFN’s earlier training uses many generated tasks to help it recognize useful patterns in new tables. When we use it for deliveries, we give it examples of deliveries and their outcomes so that it can make predictions for new rows. This process is often called in-context learning: it uses the task examples as part of the information available when making predictions. It is not the same as asking a chat assistant to look at a spreadsheet and offer an opinion.
Choose a version before choosing a machine
The Prior Labs model table lists TabPFN-3.5 base with up to 1,000,000 training rows and 20,000 columns. These are documented version limits, not a measured result from this page. Earlier versions have different limits. The 3.5 model weights use a non-commercial license; commercial use needs the appropriate agreement. The older v2 classifier model card describes its own Prior Labs attribution license and CPU/GPU requirements. Software and model-weight licenses must both be checked for the pinned versions.
The current hardware FAQ recommends an NVIDIA T4 or better for efficient use; CPU and Apple MPS support are intended for small datasets. Memory and prediction cost depend on rows, columns, model and caching. No hardware timings or accuracy comparisons are measured here.
Before comparing models, decide when the delivery team needs its answer. If the prediction is made as the parcel leaves the depot, remove anything learned only later, such as a refund or final delivery status. Then decide which records the model may learn from and which you will reserve for checking it. A reserved set is often called a holdout. If the team needs predictions next month, later deliveries make a more useful check than a mixture of old and new rows. If it needs predictions for new customers, those customers should not also appear in the records used to build the approach.
Start with a comparison simple enough that everyone understands it. For late/on-time classification, a majority-class baseline always predicts the most common outcome in the earlier records. If most deliveries arrive on time, that baseline always says on time. For delay minutes, a constant baseline always predicts a typical value, such as an average calculated from the earlier records. These are not proposed production solutions. They show how much value another model adds beyond a simple guess.
Then include stronger familiar methods. Logistic regression is a common model for a category such as late or on time; linear regression is a familiar starting point for a numerical outcome. A tree-based model divides records into groups according to their inputs. Boosted trees combine many trees, with later trees helping correct errors made by earlier ones. Comparing TabPFN with these methods on the same reserved deliveries is more informative than comparing it only with a weak baseline.
Different methods may need different preparation. One may handle missing values directly; another may need you to fill those gaps, a step called imputation. Some methods need categories converted into numerical form, called encoding, or numerical columns put on comparable scales, called scaling. Work out these steps using the earlier records and apply the resulting choices to the reserved records. Fairness means giving each model the same allowed information and comparable attention while choosing settings, not forcing every model through a preparation process that does not suit it.
Choose measures that fit the business decision. Accuracy is the share of correct answers, but it can be misleading when delays are rare. A model that always says on time may look accurate while missing every late parcel. Precision asks how many warnings turned out to be real delays. Recall asks how many of the actual delays the model warned about. A warning threshold is the point at which a model’s score becomes a warning; choose it using records available for model selection, not by adjusting it until the final test looks good.
If the model predicts probabilities, check calibration: whether those probabilities match how often the outcome happens. For example, among deliveries assigned a 30% chance of delay, roughly three in ten should actually be late over a suitable set of cases. For a minutes prediction, inspect the size of the errors and whether the most expensive delays are missed. Also measure how long predictions take and what computing resources they need. A small improvement in an offline score may not justify a system that cannot answer in time for the team to act.
Write the comparison before running it
Imagine the delivery team wants to compare several ways of predicting delays. First choose the question: should the model say whether a parcel will be late, or estimate how many minutes late it will be? Then choose who the predictions are for: customers already represented in the earlier records, or customers the model has never seen. The worksheet below turns those choices into a plan for a fair comparison. It does not run TabPFN or any other model.
Try changing Prediction target to delay minutes, then choose unseen customers under Who will be scored? The plan will suggest different ways to separate the records, different simple comparisons and different measures of error. The checklist lets you record what you have reviewed. Checking every box does not prove that the planned experiment has been carried out or that a model works well.
Loading the interactive example.
Choose the task and deployment setting
Your comparison plan
For delay minutes, a useful first comparison is a model that always predicts a typical delay from the earlier records. We can then ask whether more complicated methods make smaller errors. For unseen customers, the checking records must come from customers who were absent when the approach was built and chosen. Those choices follow from the intended use of the prediction, not from which model has the most impressive name.
Before running TabPFN, record the software version, the exact pretrained model file, its license, the hardware and the settings used to make predictions. Keep a record of which deliveries went into each group and save each model’s predictions. Use earlier records to prepare and choose the approach, then check the final choices on the reserved records. If the model cannot be run with the available resources, say so rather than assigning it an estimated performance score.
The worksheet runs locally. Existing site analytics remain enabled; inputs and derived results are masked for Clarity, and no custom events send these controls.
The worksheet helps write down the comparison, but the evidence will come from actually running it. Keep the same final checking records for every candidate, give model selection a documented budget, and retain the choices as well as the results. Review error patterns for the routes, customers and operating conditions that matter. Where possible, repeat the comparison with other suitable divisions of the data rather than selecting one unusually successful run.
Finally, review deployment as well as prediction quality. Check that the exact license permits the intended use, that the data can be handled through the chosen local or hosted route, and that someone knows what to do when a column changes or a service fails. TabPFN is a candidate to evaluate for a defined task. Its name, broad pretraining and reported results elsewhere do not establish that it will be the best choice for this delivery team.
Further reading
Prior Labs: Current version and practical FAQ