Timestral: Forecast AI Media Demand with a Clean Backtest

Mistral lists four sizes: 5M, 28M, 123M and 209M parameters. The family supports multiple related series, past-only and known-future covariates, up to 32,768 historical steps and 21 output quantiles. The current 209M documentation labels it Public Preview. Mistral reports strong zero-shot benchmark results; those results do not measure your application’s traffic.

• Mistral launch and benchmark scope
• Timestral 209M documentation

Pick a decision before picking a model size. For example: how many new product-image requests should the review team expect next week? A forecast of arrivals can help schedule review work. It cannot, by itself, predict provider queue latency, how many images will be accepted, or whether an account has sufficient balance.

Begin with one stable workflow and one time interval. Combining one-second video requests, long clips and still images into a single cost series hides changes in the work mix. Forecast the quantity that informs the decision, then calculate spending using the relevant current price and settings.

Keep a request ledger in your application with the submission time, workflow, requested settings and eventual task outcome. Count a retried delivery notification once. Keep a deliberate new generation attempt separate from a repeated event about an existing task. These choices determine whether the series represents customer demand or infrastructure activity.

Review a daily chart before fitting anything. Explain abrupt changes such as a new integration, a pricing change or a missing log collector. Keep the explanation beside the dataset. If the business process changed, a long history can be less representative than a shorter, consistent window.

Timestral’s repository accepts NaN as missing data. Do not silently fill an outage with zero just to produce a rectangular array. Choose a documented treatment for that interval and use the same treatment for the baseline and candidate model.

• Input shapes and missing-value behavior

The official package runs on CPU or GPU and loads weights separately. Its source code uses Apache-2.0; the weights have a Modified MIT license. Read the terms attached to the checkpoint you select. The example below is an original synthetic shape fixture, not observed SJolt traffic or a completed inference run.

import numpy as np
from timestral import TimestralForecaster

# Twelve invented weeks; repeated values make the fixture easy to inspect.
weekly = [12, 18, 20, 17, 24, 9, 7]
context = np.asarray(weekly * 12, dtype=np.float32)[None, None, :]
assert context.shape == (1, 1, 84)  # series, variates, time

model = TimestralForecaster.from_pretrained("mistralai/Timestral-5M")
result = model.forecast(context, prediction_length=7)
median = result.median[0, 0]
upper = result.quantile(0.9)[0, 0]
print({"median": median.tolist(), "q90": upper.tolist()})

• Official installation, forecast API and checkpoint options
• Official 209M model card

Running this code downloads weights unless the chosen files are already cached. Record the package revision and checkpoint revision for a real experiment; the repository documents a revision argument for pinning. We checked the example’s syntax and fixture shape without installing the package or loading a model.

The array has one series, one target variable and 84 daily observations. A seven-step horizon therefore means seven days. If you instead supply hourly observations, the same horizon means seven hours. Record the interval alongside the array; the variable name alone cannot establish it.

Choose several historical cutoffs. At each cutoff, supply only observations and plans that existed then, forecast the next seven days, and compare with the held-out values. Advance the cutoff and repeat. Keep tuning decisions outside the final evaluation period so that the final score remains useful.

Use a seasonal baseline: for each next-day prediction, reuse the value from the same weekday one week earlier. On the deliberately repeating fixture above, that baseline is exact. That makes the fixture useful for testing your data plumbing, but unsuitable for demonstrating a model advantage. Replace it with real held-out periods before drawing a quality conclusion.

Measure absolute error on the daily count and on the weekly total. Separately measure how often an upper quantile is exceeded. A 90th-percentile forecast is intended to leave about 10% of outcomes above it under appropriate calibration; it is not a maximum or a service guarantee. Review coverage across enough cutoffs and across busy and quiet periods.

Do not add seven daily upper quantiles and call the result the weekly 90th percentile. Dependence between days matters. If weekly staffing is the decision, evaluate the weekly quantity directly or use a documented joint forecasting method. Keep any rounding or clipping of count forecasts consistent across evaluation and use.

SJolt’s generation API supplies task IDs and status queries for work your application submits. Keep those operational records separate from the forecast. Pending work remains pending even if yesterday’s forecast predicted a quiet day, and a forecast never confirms that an output file exists.

• SJolt media API and task status
• A spreadsheet ledger for media tasks and budgets
• Current model pricing

Create a weekly planning view with predicted arrivals, actual arrivals and review capacity. Let a person approve staffing or spending changes. Continue recording rejected assets and deliberate regeneration attempts so that a growing revision rate is visible instead of being mistaken for new customer demand.

Keep the first deployment small: one workflow, a fixed horizon and a recurring comparison against the seasonal baseline. If the candidate does not improve the decision, retain the simpler baseline. No Timestral endpoint, native connector, latency result or forecast accuracy is claimed for SJolt in this guide.