Granite TimeSeries FlowState R1

What Granite TimeSeries FlowState R1 does

Granite TimeSeries FlowState R1 is IBM's open-weight release of FlowState, a foundation model for numerical time-series forecasting. It is designed for data such as measurements collected hourly, daily, weekly, or monthly, rather than for conversation, text generation, image analysis, or general-purpose reasoning.

The model performs zero-shot forecasting: it can generate predictions for a new series without being fine-tuned on that specific forecasting task. This makes it useful for testing a forecasting approach across many related datasets or for establishing a baseline before investing in supervised training.

FlowState is distributed as open weights under the Apache 2.0 license. The checkpoint is intended for local or self-managed deployment, and the supplied research does not document a hosted IBM token-pricing API for this model.

Why its architecture is different

FlowState combines a state-space-model encoder with a Functional Basis Decoder. The encoder converts the historical observations into a compact representation of their temporal behavior. The decoder then represents the forecast through learned functions, producing values over the requested prediction range.

In practical terms, the model is built to adapt to the sampling rate of the input series instead of requiring a separate model for every time scale. A scale factor communicates the temporal characteristics of the data. Users can also vary the amount of historical context and the forecast length within the model's supported operating range.

• State-space encoder: provides an efficient representation of temporal patterns.
• Functional Basis Decoder: supports continuous forecasting over the requested horizon.
• Scale-aware operation: helps the same checkpoint handle different sampling frequencies.
• Probabilistic forecasts: returns multiple forecast quantiles rather than only one point prediction.
• Zero-shot use: supports forecasting without task-specific fine-tuning.

R1 versus the r1.1 revision

The model's naming requires some care. The current Granite checkpoint is called Granite TimeSeries FlowState R1, while the model card describes an r1.1 revision with several changes. The loader must explicitly receive revision="r1.1" to select that update; if no revision is supplied, the default resolves to version 1.0.

According to the supplied model documentation, r1.1 increases the pretraining context from 2,048 to 4,096 time steps, adds synthetic pretraining data, improves the S5 layer with output gating, optimizes hyperparameters, and uses a larger multilayer-perceptron layer. The model card reports 18.5 million parameters for r1.1, while repository checkpoint metadata lists approximately 9.07 million parameters for the available default model entry. These figures refer to different documented checkpoint or revision contexts and should not be treated as a single definitive parameter count.

Inputs, outputs, and documented limits

FlowState consumes numerical time-series tensors with context, batch, and channel dimensions. It does not accept natural-language prompts as its primary input. The output is a forecast tensor containing multiple quantiles, allowing applications to represent uncertainty around the expected future values.

The 4,096-step figure describes the r1.1 pretraining context, not necessarily a guaranteed maximum for every combination of context, channels, and forecast horizon. The research also does not provide a maximum output-token value; that concept is not directly applicable to this numerical forecasting model.

Sampling rates and scale factors

The scale factor should be selected according to the sampling frequency and seasonality of the series. IBM's documented examples include 0.25 for 15-minute data, 0.5 for 30-minute data, 1.0 for hourly data, 0.46 for weekly data, and 2 for monthly data. The appropriate value for daily data depends on whether the series has a weekly cycle.

These values are starting points rather than universal guarantees. IBM recommends testing scale factors when the dominant seasonal pattern is unclear. Forecast quality may decline when the requested horizon extends beyond approximately 30 seasonal cycles, so very long-range forecasts should be evaluated carefully rather than assumed to be reliable.

Strengths and trade-offs

FlowState's clearest strength is its focus on time-scale flexibility. A single compact checkpoint can be evaluated on series with different sampling frequencies, which may simplify experimentation across operational, financial, scientific, or industrial datasets. Its relatively small architecture can also make local inference and prototyping more practical than using much larger time-series foundation models. The model card reports strong zero-shot results on public forecasting evaluations; that is a provider or model-documentation claim, not an independently verified result here.

The trade-off is specialization. FlowState does not provide text generation, embeddings, tool calling, web search, structured conversational output, image or audio processing, or general reasoning. Its documented task scope is currently zero-shot forecasting. The editorial capability ratings supplied for this database are intended to describe its role as a forecasting model, not to suggest that it competes with language models for coding or reasoning.

Speed and cost also need to be interpreted in context. The model is small and open-weight, which can reduce the hardware and usage cost of self-managed experimentation, but actual performance depends on the deployment environment and workload. There is no hosted per-token price to compare with commercial language-model APIs. Operating the checkpoint locally still requires suitable compute, storage, monitoring, and engineering effort.

Pricing, license, and availability

No hosted API price is documented for Granite TimeSeries FlowState R1 in the supplied research. The practical pricing model is therefore self-hosting: the weights are available under Apache 2.0, while users provide the infrastructure required for inference and integration. Apache 2.0 generally permits commercial use, subject to the license terms.

The associated open-source repository is provided without an obligation from IBM to provide enhancements, updates, or support. Teams that require a managed endpoint, contractual support, or a service-level commitment should verify whether a separately offered IBM product or another forecasting service meets those requirements; the supplied sources do not establish that this checkpoint is available as a managed watsonx model endpoint.

When to choose this model

FlowState is a reasonable choice when the central problem is forecasting regularly sampled numerical data and the team wants an open-weight model that can be tested without task-specific fine-tuning. It is particularly suitable when:

• the data is numerical and regularly sampled;
• forecasts are needed across different temporal resolutions;
• probabilistic quantiles are more useful than a single point estimate;
• local or self-managed deployment is preferred;
• the team wants a compact zero-shot baseline before building a specialized forecasting system; or
• the forecast horizon is within a defensible range of the series' seasonal cycles.

Another option may be more appropriate when the application needs supervised fine-tuning, broader time-series tasks, natural-language interaction, multimodal input, tool use, or a documented hosted API. A general language model is also a poor substitute when precise numerical forecasting is the primary requirement, while a task-specific forecasting model may be preferable when the domain has enough labeled history to justify specialized training.

Practical loading guidance

When evaluating the model, first confirm which revision is being loaded. Use revision="r1.1" when the updated checkpoint is intended; otherwise, the loader may use version 1.0. Prepare the numerical tensor with the expected context, batch, and channel dimensions, choose a scale factor that reflects the sampling frequency, and request a forecast horizon that is supported by the available context and seasonal structure.

Evaluation should compare more than one scale factor when seasonality is uncertain. It should also test the quantile forecasts for calibration and coverage, not just compare average point accuracy. Because the model is zero-shot and specialized, performance on a particular business or scientific series should be measured against simpler baselines and any domain-specific model before production use.