Falcon-TST is a family of three time series foundation models, not one

Three models, three different training regimes

The repository description is Official implementation of Falcon-TST, and the README makes clear that the name covers a family rather than a single checkpoint. Falcon-2.0, released in August 2026, is a univariate encoder-only time series foundation model based on ORBIT, which the README expands as Omni-Range Bootstrap Incremental Training, and it came with a technical report on arXiv and its own API documentation. Falcon-X, released in June 2026, is a multivariate time series foundation model designed for heterogeneous variate modeling through a shared latent prototype space and dual-dependency modeling, again with an arXiv paper and a separate API page. Falcon-1.0, available on HuggingFace since October 2025, is a hierarchical mixture-of-experts model that integrates patch-wise expert specialization with sample-wise hierarchical routing. The top-level layout mirrors that split, with falcon1, falcon2 and falconx directories, plus a LEGAL.md and a LICENSE file. The comparison the README highlights is a MASE measurement on the GIFT-Eval benchmark, with results shown as an image.

Falcon-2.0 through the client API

The pip package is falcon-tst, and the importable client is FalconClient.

pip install falcon-tst

The example shows a quantile forecasting call with a NumPy context tensor, a mask and an explicit model name.

import numpy as np
from falcontst import FalconClient

# Prepare inputs
batch_size = 32
context_length = 512
prediction_length = 96

context = np.random.randn(batch_size, context_length)
input_mask = np.ones_like(context)

client = FalconClient()
result = client.quantile_predict(
    context=context,
    prediction_length=prediction_length,
    model_name="Falcon-2.0",
    input_mask=input_mask  # 1 = observed, 0 = missing
)

print(result)

Two details matter for anyone using this in production. The first is that the call returns quantiles rather than a point forecast, which is what the method name means and is the right interface if you need prediction intervals. The second is the input_mask, where 1 means observed and 0 means missing, so the model can handle gaps in the history rather than requiring a clean contiguous series. The model_name argument is passed as a string, so the same client object can address different checkpoints, and the README points to falcon2/README.md for the detailed API usage, parameters and output format.

Falcon-X and the multivariate difference

Falcon-X uses the same package and the same client, and the same installation command applies.

pip install falcon-tst

The example differs in two ways: the shape naming changes to B, L, H, and the call passes is_multivariate=True.

import numpy as np
from falcontst import FalconClient

# Prepare inputs
B, L, H = 32, 512, 96
context = np.random.randn(B, L)
input_mask = np.ones_like(context)

client = FalconClient()
result = client.quantile_predict(
    context=context,
    prediction_length=H,
    model_name="Falcon-X",
    input_mask=input_mask,  # 1 = observed, 0 = missing
    is_multivariate=True,
)

print(result)

The design goal behind Falcon-X is the part that matters for a practical decision. Heterogeneous variate modeling through a shared latent prototype space means that variables with different units, scales and behaviours are brought into a common representation rather than being treated as interchangeable channels, and dual-dependency modeling handles the dependencies between variates and within a variate separately. That is what makes it a different model rather than a flag on the same one, even though the client call looks nearly identical. The detailed API usage, parameters and output format are in falconx/README.md.

Falcon-1.0 and the HuggingFace route

The first model takes a different path. Instead of the client, it loads through the HuggingFace transformers library, and the README lists the dependencies as Python >= 3.8, PyTorch >= 2.0.0 and transformers == 4.40.1, with that last one pinned exactly rather than to a range. The checkpoint identifier is ant-intl/Falcon-TST_Large on HuggingFace.

import torch
from transformers import AutoModel

# Load pre-trained model (when available)
model = AutoModel.from_pretrained(
    'ant-intl/Falcon-TST_Large',
    trust_remote_code=True
)

# Prepare your time series data
batch_size, lookback_length, channels = 1, 2880, 7
time_series = torch.randn(batch_size, lookback_length, channels)

# Load the model and data to the same device
device = torch.cuda.current_device() if torch.cuda.is_available() else 'cpu'
model = model.to(device)
time_series = time_series.to(device)

# Generate forecasts
forecast_length = 96
predictions = model.predict(time_series, forecast_horizon=forecast_length)

print(predictions)

Two things stand out. The call uses trust_remote_code=True, which means the model repository ships its own Python modelling code that the transformers library will execute, and the comment on the load says when available, which suggests the released weights may not always be present in the expected form. The example also uses a much longer lookback than the other two, 2880 steps with 7 channels, and it handles the device explicitly, moving model and data to the same device with a CPU fallback when CUDA is not available.

Where Falcon-TST is the wrong tool

Three limits. The first is that this is an inference repository, not a training one. The acknowledgements thank the authors of Megatron-LM, Chronos and GIFT-Eval, and the README says the work builds upon open-source datasets and methodologies from the research community, but what is published here are model definitions, checkpoints and API documentation. If your requirement is to fine-tune a time series foundation model on your own data, this repository does not document how to do it. The second is the dependency pinning. Falcon-1.0 requires transformers == 4.40.1, an exact version from before most of the current transformer ecosystem, and an application that already depends on a newer transformers will not be able to run both paths in the same environment. That is a real constraint rather than a preference, and it is worth checking before you plan to serve all three models from one deployment. The third is the licence ambiguity. The README badge and the license section both state Apache License 2.0, but GitHub records the licence identifier as a custom one it cannot classify, so the LICENSE file is the authority and it is worth reading before a commercial deployment. There is also no GitHub releases list, so the version history of the API is not visible from the repository.

How it compares with the alternatives

The README itself points at the two references that matter. Megatron-LM is credited, which tells you about the training stack the models were built with, which suggests large-scale model training played a role in how these models were built. Chronos from Amazon Science is credited as well, and and the README highlights a MASE comparison that includes it. GIFT-Eval from Salesforce AI Research is credited because it is the benchmark used for the MASE comparison the README shows, which is what makes the numbers comparable to other published models rather than self-reported. So the honest framing is that Falcon-TST sits in the same category as Chronos, differs from it in training regime, with ORBIT incremental training for Falcon-2.0 and hierarchical mixture-of-experts routing for Falcon-1.0, and is evaluated on a benchmark the community already uses, and the documentation is thin on the training side because the training code is not what this repository publishes.

Editorial conclusion

Adopt Falcon-TST if you need a forecasting foundation model you can call from Python with a small client API, since Falcon-2.0 and Falcon-X both expose quantile_predict through the same FalconClient. Skip it if you need the training code rather than the weights, since the repository ships inference examples and API documentation, not a training pipeline. Before you commit, check the licence file yourself, because the README says Apache 2.0 while GitHub records a licence it cannot classify, and decide whether you need the univariate or the multivariate variant first.

Frequently asked questions

Official sources

1. ant-intl/Falcon-TST on GitHub
2. Issues
3. README