Context Windows, Model Scale, and the Cost of More Capability

Kronos makes two constraints visible that are easy to blur together: how much history the generator can see, and how much capacity a checkpoint has to process that history. This chapter treats context length, frequency, forecast horizon, model size, and sampling budget as one workload decision rather than as isolated specifications. The aim is not to choose a universal “best” Kronos model, but to understand which conditions a comparison must hold constant before a larger model or a longer history can be said to help.

Context is a time budget, not just a number

A context window counts tokens, and in Kronos each token represents one K-line observation. A limit of 512 therefore means that the step-by-step generator can use at most 512 represented bars in its active window. It does not mean that the model remembers 512 days, 512 hours, or a fixed amount of real-world time. The clock covered by those bars depends on the sampling frequency.

At a five-minute frequency, 512 bars describe a relatively short market interval. At a daily frequency, the same count spans much longer. A lookback of 100 bars has the same ambiguity. The numerical setting is identical, but the market history it supplies changes with the bar length. A forecast horizon must be interpreted in the same way: predicting 24 future bars means one thing for five-minute data and another for daily data. Context, lookback, frequency, and horizon are therefore coupled decisions.

This is not just a presentation issue. Suppose a user wants a forecast covering one trading day. At one frequency, that horizon may require many bars and leave relatively little room for history inside a fixed context. At another, it may require only a small number of bars while the same context reaches much farther into the past. The model is being asked to solve different temporal problems even when the API receives the same integer pred_len. A comparison that ignores this relationship can mistake a change in time aggregation for a change in model capability.

Kronos adds five timestamp-derived features—minute, hour, weekday, day, and month—to the token representation. These features give the model an explicit calendar coordinate for each observation, which can help it distinguish recurring temporal positions. They do not turn a short context into a long one. A model can know that a bar occurred on a particular weekday while still lacking older market tokens that have fallen out of the active window.

During autoregressive inference, the predictor maintains a rolling buffer. It initially places as much of the encoded history into the buffer as the context permits. As each future token is generated, it is appended. Once the buffer is full, the oldest token is shifted out before the new token is added. This permits a horizon longer than the active context, but it changes the information available to later steps. The generator sees a moving recent history, not an unlimited transcript of every observed and generated bar.