Timestral vs Prophet: a workflow comparison, not a leaderboard.

What is the difference between Timestral and Prophet in one paragraph?

Timestral is a family of open time-series foundation models from Mistral AI, designed for zero-shot probabilistic forecasting. You give it a history and it returns a median, an 80% band and 21 quantiles without training a model. Prophet is an open-source additive trend/seasonality model that you fit on a Python or R data frame; it returns a point forecast plus an uncertainty interval and lets an analyst inspect the trend and seasonal components. The first is a hosted model call; the second is a modeling workflow you own.

How does Timestral produce a forecast?

Timestral has already learned transferable temporal patterns from a large corpus. At inference time you provide the series, a horizon and optionally several related columns. The model does not update its weights. In the studio, the CSV can contain an optional date column and up to eight numeric columns, with at least eight rows and a 2 MB limit. The UI exposes a horizon from 1 to 36 steps; the API accepts 1 to 1,024.

The output is probabilistic. The studio shows the median and the 80% band by default, and the downloadable CSV contains all 21 quantiles. The model supports a context of up to 32,768 time steps, which is enough for years of hourly data or decades of monthly data. Mistral reports CPU inference numbers of roughly 10 ms for the 5M model and 140 ms for the 209M model on an eight-thread CPU for a one-day-ahead forecast from three weeks of 15-minute data. Those are vendor numbers; the public demo’s latency also includes a shared queue and network.

How does Prophet produce a forecast?

Prophet fits an additive model to your series. The existing comparison on this site describes it as an additive trend/seasonality model for analyst-driven series with clear trend and seasonality. You supply a data frame in Python or R, fit the model, and receive a point forecast plus an uncertainty interval. The fit is per series, so forecasting many series means many fits and your own orchestration around them.

The advantage is transparency. A classical model exposes its components, which makes it easier to defend a number in a planning review. The cost is that the model only knows what you fit it on: new patterns, structural breaks and long-range dependencies have to be handled by the data you provide or by refitting. The model comparison guide makes the same point about classical baselines: they are cheap, interpretable and surprisingly hard to beat on short, stable series.

Which one gets you to a first forecast faster?

Timestral. The browser studio needs no account: paste a CSV, choose a horizon and run the forecast. The public demo is free while the Hugging Face Space is available, and the email report also needs no account. A first result can arrive in minutes.

Prophet needs an environment before it needs a forecast. You install the library, prepare a data frame, fit the model, inspect the components and plot the result. The setup is measured in hours, and the first forecast is only the start of the workflow. If your team already has a Python data stack, that cost is lower; if not, it is the real barrier.

Which one returns a range you can plan with?

Both return uncertainty, but not in the same shape. Timestral returns 21 quantiles per step; the studio shows the median and the 80% band, and the CSV contains every quantile for downstream calculations. Prophet returns a point forecast plus an uncertainty interval. For a planning decision, the important question is not which interval looks wider; it is which interval is calibrated. Measure 80% coverage on a holdout: the share of actuals that fall inside the band should be close to 80%.

A model that reports a narrow band and misses it is worse than a model with a wider, honest band. The published guide to the 21 quantiles explains how to read the output without treating the median as the whole forecast.

How do they handle seasonality, holidays and related series?

Prophet is built around trend and seasonality, which is why it is a good fit for analyst-driven series with a clear pattern. If the business calendar is the dominant signal, an explicit trend/seasonality model is a natural starting point, and a human can inspect whether the fitted components match what the business expects.

Timestral learns patterns from the history you provide and can use up to eight related numeric columns. That helps when the series are genuinely related — load and temperature, sessions and ad spend, production and vibration. It is not a causal model. A promotion, a price change or a one-off shutdown is not in its weights; you have to encode those as covariates or handle them outside the model. The multivariate guide covers the covariate traps.

What does each cost in practice?

Timestral is metered: one successful forecast costs one credit, and a failed call is refunded. The entry one-time pack is $9.90 for 10 calls. The lowest self-serve annual tier is $639 for 6,000 calls, or about $106.50 per 1,000 calls. The monthly tiers start at $9.90 for 20 calls a month. The full table is on the pricing page.

Prophet has no license fee. The cost is the environment, compute, monitoring, the person who maintains the model and the engineering time to turn a notebook into a service. For a single analyst running one forecast a month, that cost is real but small. For a production pipeline, the fully loaded cost of ownership is usually larger than the per-call price of a hosted API; for a very high volume with a stable model, the opposite can be true. Price the whole workflow, not the license.

Which one is easier to run behind an API?

Timestral ships the API. Create a key, send a POST with a CSV and a horizon, and receive a task id, the median and 80% band rows, and a URL to the full 21-quantile CSV. The contract documents authentication, error codes, credits and refunds. The call is synchronous; large batches use client-side concurrency limits. The API overview and the API reference are the source of truth.

With Prophet, the API is yours to build. That is an advantage if you need custom preprocessing, custom regressors or a private data path. It is a cost if you only wanted a forecast endpoint. The existing software comparison puts it plainly: an open library is a strong choice when you have a Python team, need full control and can own the infrastructure.

When should you choose Timestral?

• You can export the series to CSV and need a probabilistic forecast today.
• You want a median and a range rather than a single number.
• You want the same forecast behind an API without building a model-serving stack.
• You need a zero-shot baseline before investing in a custom model.
• You have several related series and want to forecast them together.
• You need a second opinion on an existing planning number at a transparent per-call price.

When should you choose Prophet?

• You have a Python or R team and an existing data pipeline.
• The series has a clear trend and seasonal pattern that a human should be able to inspect.
• You need to defend the components of the forecast in a planning review.
• You want full control over preprocessing, regressors and the fitted model.
• You need a private data path and can own the infrastructure.
• Your volume is high and the model is stable enough that per-call pricing is the wrong shape.

How do you test both on your own data?

Use the same history, the same horizon and the same series for both tools. Hold out the last 12 periods, forecast them, and compare the forecasts with what actually happened. Repeat across around 20 series or 20 rolling windows so one lucky series does not decide the choice. Score the median with MASE and RMSE, score the interval with 80% coverage, and record latency and cost next to each result.

Then apply the simplest-model rule: if Prophet is within a small margin of Timestral, prefer the model your team can own and explain. If Timestral is clearly better and the per-call price is small relative to the decision, prefer the model you do not have to operate. The evaluation guide has the metric definitions, and the benchmark shows a worked example with per-series results rather than a single average.

Can you use both together?

Yes. A common pattern is to use Prophet as the transparent baseline and Timestral as a second candidate, then choose per series or per horizon. An ensemble is also possible, but measure whether it beats the best single model after costs. Two models that disagree are useful information: the disagreement usually points at a structural break, a missing covariate or a series that neither model understands.

The combination is also a low-risk migration path. Run both in parallel for one planning cycle, compare the forecasts with the actuals, and only then retire one of them. That is cheaper than rewriting a pipeline around a model choice made from a demo.