fable puts several forecasting models behind one pipeline verb

The package is a framework, and the models are interchangeable parts of it

The fable package provides a collection of commonly used univariate and multivariate time series forecasting models, including exponential smoothing via state space models and automatic ARIMA modelling.

The important sentence is the one after that. These models work within the fable framework, which provides the tools to evaluate, visualise and combine models in a workflow consistent with the tidyverse.

So the package has two layers. The lower one is the models, and the upper one is the workflow that treats them uniformly. That upper layer is the actual product.

The problem it solves is one every forecaster hits. You have a time series and you do not know which of the classical methods will handle it, so you try an ETS, you try an ARIMA, you try a seasonal naive, and then you have three sets of forecasts and no principled way to compare them or combine them. The three scripts you wrote are three different pipelines with three different output shapes.

fable makes each of those a single call in the same pipeline, so the comparison is the default rather than something you assemble.

The project is R, GPL-3.0 licensed, with the last push on 2026-09-15. The releases are v0.5.0 from 2026-01-23, v0.4.1 and v0.4.0 both from 2024-11-28, and the lifecycle badge marks the package as stable. The homepage is fable.tidyverts.org and the package is on CRAN.

One call fits three models and forecasts from all of them

The example in the documentation is short and it demonstrates the whole idea in one pipeline.

``` r library(fable) library(tsibble) library(tsibbledata) library(lubridate) library(dplyr) aus_retail %>% filter( State %in% c("New South Wales", "Victoria"), Industry == "Department stores" ) %>% model( ets = ETS(box_cox(Turnover, 0.3)), arima = ARIMA(log(Turnover)), snaive = SNAIVE(Turnover) ) %>% forecast(h = "2 years") %>% autoplot(filter(aus_retail, year(Month) > 2010), level = NULL) ```

Read it in order. The data is aus_retail from the tsibbledata package, filtered to two states and one industry, so you have a single monthly series. Then the model call fits three models at once, each as a named argument.

ETS is the exponential smoothing model, with a box_cox transformation applied to Turnover with a parameter of 0.3, which is the standard way to deal with a series whose variance grows with its level. ARIMA is the automatic ARIMA, here on the logarithm of Turnover, so the multiplicative seasonality is handled on a scale where it behaves additively. SNAIVE is the seasonal naive, the benchmark that says the best forecast for a seasonal series is last year's value.

Then forecast with h = "2 years", which produces forecasts from every fitted model, and autoplot draws them.

The verb structure is what makes it readable. model fits, forecast predicts, autoplot draws, and the pipe carries the data through. Every model appears as a named argument to the same call, which means adding a fourth model is one more line rather than a new branch of code.

And the choice of models in the example is instructive in itself. The three are deliberately different in kind: a structural model with transformations, a statistical model fitted automatically, and a naive benchmark with no fitting at all. Running the naive one alongside the other two is the point, because it is the baseline you have to beat.

The transformations are part of the model, which is the right place for them

The one detail in that example worth expanding on is the transformation, because the placement is deliberate.

box_cox(Turnover, 0.3) is applied inside the ETS model specification, and log(Turnover) is applied inside the ARIMA specification. Neither is applied to the data before the model call. Each transformation is tied to the model it belongs to.

That matters because a transformation chosen for one model is not automatically right for another. A Box-Cox transform with a parameter of 0.3 stabilises the variance for an additive error model, which is what ETS is. If you had log-transformed the data once, upstream, and then fitted both an ETS and an ARIMA to it, you would have committed to one error model for both, and you would have lost the ability to compare them on the scale you actually care about.

Keeping the transformation inside the model specification also means the transformation is part of what gets fitted and evaluated. Whether the transformation improves the fit is a question the framework answers rather than a decision you make by hand before seeing any numbers.

This is the tidyverse idea applied to forecasting. The data stays in its original form and the transformation is a piece of the model, in the same way that a scale argument is a piece of the model in other tidyverse packages.

Combining models is where the framework earns its place

The feature list mentions that the framework provides tools to evaluate, visualise and combine models, and combining is the part that distinguishes this from a package of model implementations.

Evaluating means comparing models on the same footing, which the pipeline makes automatic because the models were fitted in the same call. Visualising means the forecast output is a data structure that autoplot understands, so drawing a comparison is a plot rather than a set of custom calls.

Combining is the interesting one, because it is what you actually want to do once you have several forecasts. There are well known ways to combine forecasts from different models, and the framework's job is to make that a step in the pipeline rather than a separate piece of code that has to know about the internals of each model.

The reason this matters for a forecaster is a practical one. A single model chosen in advance is a guess. Running several and combining them is a hedge, and the hedge is usually better than the guess, especially when you cannot tell from the data which model will win on this particular series.

And the benchmark model being part of the same call is what makes the hedge honest. A combination that beats the naive model is interesting. A combination that does not is not, and including SNAIVE in the same call is how you find that out before you ship the forecast.

The package description also covers multivariate models, so the same workflow applies when your series are related to each other rather than being one series at a time.

Installing and the toolchain it expects

There are two installation routes, and the difference between them matters for reproducibility.

The stable version comes from CRAN:

``` r install.packages("fable")

The development version comes from GitHub:

r # install.packages("remotes") remotes::install_github("tidyverts/fable") ```

which requires the remotes package, commented out in the snippet because you have to install it first.

Then there is the line that catches people out, and it is on its own: installing this software requires a compiler.

That is because fable is not a pure R package. The repository layout shows a src/ directory alongside the R/ directory, and src/ is where compiled code lives. The R directory holds the R code and the src directory holds the C and Fortran that it calls, and the compiler is needed to build that.

On a workstation this is usually invisible, since R will build it during installation. In a container, on a locked-down machine or on a platform without a toolchain, it is the step that turns a one-line install into an afternoon.

The repository is a standard R package layout with a DESCRIPTION file, a NAMESPACE, a NEWS.md for the changelog, the R/ and src/ source directories, tests/, vignettes/, man/ for the generated help pages, inst/ for package data, and pkgdown/ for the website. There is a _pkgdown.yml that configures the site, an .Rproj file for RStudio, a hex/ directory for the badge, and a cran-comments.md used in the CRAN submission process.

The README itself is generated from README.Rmd, which is the usual tidyverse arrangement so that the examples in it are run when the package is built and cannot silently go stale.

Where this sits against the alternatives in R and outside it

The comparison within R is with the forecast package, and it is the obvious one to raise.

The forecast package from Rob Hyndman is the other established name in R forecasting, and it is a different shape of thing. It is a large collection of forecasting functions, each with its own interface, and it predates the tidyverse pipeline style. Working with it means calling a function per model and handling the outputs yourself, which is precisely the friction fable removes.

The other comparison is with the specialist packages that fable sits on top of. The forecast package provides ETS and ARIMA implementations, and those are what fable wraps. The distinction is that fable is the layer where you compare and combine, not the layer where an algorithm is implemented.

Outside R, the comparison is with Python. There is a growing set of forecasting libraries in Python and the statistical modelling coverage is at least as broad, and for a team that is Python-first the argument for fable is weaker. But the tidyverse pipeline is genuinely good at this particular problem, because the model specification, the fit, the forecast and the plot are all verbs in one chain, and the data stays in one shape throughout.

The argument for the model catalogue being sufficient is worth making. The models fable provides are the commonly used ones, which is a deliberate scope choice. It is not a research platform for exotic state space specifications, and if your problem needs a method outside that catalogue, this is not where you will find it.

The documentation points at two places for learning. The pkgdown site describes all the models fable provides and how they are used, and the forecasting principles and practices online textbook provides an introduction to time series forecasting using fable, currently marked work in progress.

For help, questions about forecasting go to Cross Validated and questions about the package often find answers on Stack Overflow, with the tidyverse guidance being to include a minimally reproducible example.

Editorial conclusion

Adopt fable if you forecast in R and want to fit several models to the same data in one pipeline rather than in three separate scripts, since the value of the package is the shared workflow rather than any one algorithm. Skip it if you need a single specialised model for a specific problem outside the usual catalogue, and if you cannot install a compiler, because the documentation says installing the software requires one. Verify first which version you get, since the CRAN release is older than the GitHub development version, that the model you need is one fable provides, since the pkgdown site is the reference for the catalogue, and that your data is in a tsibble with regular time intervals, because the pipeline assumes a time index rather than a plain data frame.

Frequently asked questions

Official sources

1. License: GPL-3.0
2. Project website
3. README
4. Releases
5. tidyverts/fable on GitHub