Zero-Shot Time Series Forecasting Without Training a Model
8 min read · updated August 11, 2026
Zero-shot in text means the task was not demonstrated. Zero-shot in forecasting means something narrower and more useful: the weights were never fitted to this series, but the series itself is fully present in the prompt. Confusing the two leads to expecting the wrong things.
What zero-shot means when the input is numbers
When a language model answers a question zero-shot, the knowledge it uses came from pretraining. When a forecasting model forecasts your series zero-shot, essentially none of the knowledge it uses about your series came from pretraining, because your series was not in the corpus. Everything specific arrives in the context window at inference time. Pretraining supplied the prior — what series in general tend to do — and the context supplies the evidence.
That framing predicts the behaviour. Give a pretrained forecaster twenty observations of a noisy series and it will produce something close to a smooth continuation of the level, because the prior dominates. Give it six clean cycles and it will reproduce the cycle, because the evidence dominates. There is no fitting step and no learning rate; the only lever you have on that balance is how much history you pass and how clean it is.
It also explains why zero-shot forecasting is not the same problem as forecasting a product with no history. Zero-shot removes the training step, not the history requirement. A series with three observations gives a pretrained model almost nothing to condition on, and the forecast will be close to a flat continuation.
Scale is removed, shape is not
Every design in this family normalises the context before the model sees it, typically by dividing by the mean absolute value of the window. The forecast is then produced in normalised space and multiplied back. Two things follow.
First, absolute magnitude carries no information to the model, so a series in euros and the same series in cents produce identical forecasts up to the rescaling. Second, and less obviously, the normalising constant is computed from the context window, so a series whose level has changed sharply inside that window gets a scale factor that matches neither half. A series that ran at 100 for four hundred steps and then jumped to 900 for a hundred steps has a mean absolute value around 260, and neither regime is well represented after division. The practical consequence is that a recent regime change is better handled by shortening the context to the new regime than by passing everything you have.
There is a third consequence that catches people out on intermittent data. Dividing by the mean absolute value of a window that is mostly zeros produces a very small divisor, so the few non-zero observations are scaled to enormous normalised values, land in the outermost quantisation bins, and lose all resolution. A series of mostly zeros is the worst case for this family for that mechanical reason, before any argument about whether the pattern is learnable.
The context window is the real constraint
This is the constraint that decides most cases and it is arithmetic rather than judgement. One observation is one token in the tokenise-and-sample design, so a model trained with a 512-token context can see 512 observations. Count what your seasonality needs:
hourly, daily cycle period 24 2 cycles = 48 obs fits easily hourly, weekly cycle period 168 2 cycles = 336 obs fits daily, weekly cycle period 7 2 cycles = 14 obs fits daily, annual cycle period 365 2 cycles = 730 obs does NOT fit in 512 weekly, annual cycle period 52 2 cycles = 104 obs fits 15-min, weekly cycle period 672 2 cycles = 1344 obs does NOT fit in 512
Two full cycles is the minimum for a pattern to be visible as a repetition rather than as a single excursion, and three or four is what you want. The table says plainly which seasonalities a 512-observation context can carry and which it cannot. Daily data with an annual cycle is the common commercial case and it is on the wrong side of the line; so is any sub-hourly data with a weekly rhythm. Patch-based designs push the limit out because each patch of several observations is one position, which is the main practical reason to prefer them, but the same counting exercise still applies with the patch size divided out.
The failure: an unfamiliar period
Pretraining corpora are dominated by calendar rhythms, because most recorded series are generated by human activity on a calendar. The period that fails is the one that is not on the calendar and not in the corpus: a plant maintenance cycle every 47 days, a payroll rhythm on a 13-period fiscal year, a school timetable with a 10-day rotation, a fishing quota year, a tide-driven series whose period is 12.42 hours and therefore never lines up with an hourly sampling grid.
The mechanism of the failure is worth being precise about, because it is not that the model has never seen period 47. It is that the model has a strong prior for the periods it has seen many times, and with a context containing only two or three cycles of an unusual period, the prior wins. The visible symptom is a forecast that reproduces a weekly or daily rhythm the series does not have, or one that flattens into a drifting level and drops the cycle entirely. Both are the prior showing through thin evidence.
The 12.42-hour case is worse than the 47-day case and for a different reason. A period that is not an integer number of samples never repeats at the same offset, so no fixed-lag structure exists for any model to latch onto. That is a property of your sampling grid, not of the model, and the fix is resampling or an explicit harmonic term rather than a bigger model. Finding the period in the first place is the subject of detecting seasonality automatically.
Checking before you trust it
- Hold out the last h observations, where h is the horizon you actually need, and forecast them from the remaining history.
- Score the same holdout with seasonal naive — the value from one period ago — and with a naive random walk. These are free and they are the baselines a forecast has to beat to be worth its dependencies.
- Repeat across several origins rather than one. A single holdout on a seasonal series can land on an unrepresentative window and tell you almost nothing; see rolling-window evaluation.
- Compare per-series, not on the pooled average. A pretrained model often wins on the long, clean, strongly seasonal series and loses on the short and intermittent ones, and a pooled mean hides which of those your catalogue is mostly made of.