All articles
Agent services6 min read

PredictionEngine: forecasts an AI agent can buy per call

Most forecasting tools assume a subscription, a dashboard and a person at the keyboard. PredictionEngine assumes an agent in a chat that needs one forecast now—and pays for exactly that one.

By GenesisPay Engineering Published Sep 29, 2026
A bright fintech dashboard showing a forecast curve with a shaded quantile band, a per-call price card and a paid status.

What PredictionEngine is

PredictionEngine is a forecasting API run by its own operator. It is a GenesisPay seller, not a GenesisPay product: GenesisPay handles the payment, PredictionEngine handles the forecast.

The model underneath is TimesFM 2.5, a 200-million-parameter time-series foundation model that Google Research publishes under the Apache 2.0 licence. TimesFM was introduced in the paper “A decoder-only foundation model for time-series forecasting”, presented at ICML 2024. Because it is pre-trained on a large corpus of real-world and synthetic series, it can produce a sensible forecast for a series it has never seen, without a model being trained for each customer.

PredictionEngine hosts the open model on its own infrastructure. It is powered by TimesFM; it is not a Google service.

What goes in and what comes out

A request is one univariate series and a horizon:

  • series — 32 to 16,000 numbers, oldest first.
  • horizon — how many steps to forecast, at most half the length of the series.
  • timestamps (optional) — one ISO timestamp per observation, strictly increasing and regularly spaced.
  • frequency (optional) — hourly, daily, weekly, monthly, quarterly or yearly, or detected automatically.
  • quantiles (optional) — any deciles from 0.1 to 0.9; the default is 0.1, 0.5 and 0.9.
  • past_covariates (optional) — other aligned numeric histories, such as promotions or temperature, that may help explain the series.

The response carries a point forecast, the requested quantile forecasts, a timestamp for each step, metadata.source and a usage block. The metadata.source field matters: during the beta, PredictionEngine answers with a clearly labelled simulated forecast if the model is unavailable, so an agent should check that field before presenting a result as real model output.

Validation is deliberately strict. Gaps in timestamps are rejected rather than silently filled, and a series needs at least two seasonal cycles—48 points for hourly data or 104 for weekly data, for example. An error is an error; it is never dressed up as a forecast.

What a forecast costs

The price follows the horizon, because a longer horizon is more work:

TierHorizonPrice per call
x11–24 steps0.05 USDC
x225–48 steps0.10 USDC
x449–96 steps0.20 USDC
x897–256 steps0.40 USDC

Each tier is its own x402 resource, and each accepts only its own horizon band. A cheap endpoint cannot be asked for an expensive forecast, and an expensive endpoint cannot charge for a cheap one.

People who prefer PredictionEngine’s web app can buy starter credits instead—50 credits for 2.00 USDC—and spend them on forecasts from uploaded CSV files. A web forecast costs one credit per column per tier unit, so both routes are priced from the same table.

How an agent pays from a chat

Once the GenesisPay connector is added to an assistant such as Claude or ChatGPT, the agent pays from an agent wallet that belongs to its user. Each call follows the same steps:

  1. The agent sends the forecast request and receives an HTTP 402 payment offer for that exact request.
  2. GenesisPay checks the offer—network, asset, amount and destination—and compares it with the wallet’s spending policy.
  3. If the payment fits, the wallet signs a single USDC authorisation for that amount, and the forecast comes back once the payment settles.

Every call is its own payment. There is no prepaid balance held by PredictionEngine and no subscription to cancel. The limits live on the GenesisPay side, where the agent cannot change them: by default 5 USDC per payment and 20 USDC per day, with an optional monthly cap and an allowlist. A payment above a cap pauses until the owner approves it in the dashboard; a destination outside the allowlist is blocked outright. At the default daily cap, an agent could buy up to 400 short-horizon forecasts, or 50 of the longest, before it has to ask.

GenesisPay design note: Spending policy is enforced on GenesisPay’s server, not in the agent’s prompt or SDK. An agent that misreads a price, or is talked into a larger purchase, still meets the same caps—and the owner, not the agent, decides what happens above them.

Where a probabilistic forecast helps

TimesFM is a general-purpose model, so the most useful questions are ordinary operational ones:

  • Demand — orders or bookings over the coming weeks.
  • Capacity — server load, support tickets or staffing needs.
  • Inventory — stock usage ahead of a reorder.
  • Pricing — expected volume around a planned price change, with the change supplied as a covariate.
  • Traffic — website visits or app sessions.
  • Energy — consumption over the next days.

An agent can also chain services. It might buy a monthly search-interest series for a keyword from x402Atlas, an independent service listed in GenesisPay’s external services directory, then ask PredictionEngine to project it forward. Search interest is not sales, but it is a reasonable early signal to reason about.

An outlook: models trained on market data

TimesFM is trained to be general. A separate line of research asks whether models trained specifically on financial market data do better on that data:

  • Kronos presents itself as a foundation model for the language of financial markets. It turns candlestick (K-line) data—open, high, low, close and volume—into tokens, and was pre-trained on more than 12 billion K-line records from 45 exchanges. Its smaller versions are released openly under the MIT licence; the largest is not. The paper was accepted at AAAI 2026.
  • Financial fine-tuning of TimesFM. Fu, Hirano and Imajo continued pre-training TimesFM on about 100 million points of hourly and daily price data and report better price-prediction accuracy than the base model.
  • A broader evaluation. Rahimikia, Ni and Wang found that generic pre-trained models underperform on daily excess returns, while models adapted to financial data show meaningful improvements.

For a service that already sells forecasts per call, such models are a possibility worth watching: in principle, a finance-specific model could sit beside TimesFM as a separate endpoint with its own price. That is an observation about the field, not an announcement—whether and how PredictionEngine adopts anything is its operator’s decision, and nothing here is a roadmap or a date. The reported results are also measured on historical data, which is exactly where the warning above applies most.

Primary sources

Check the original sources.

  1. 01PredictionEngine public price list (x402 tiers and starter credits)PredictionEngine
  2. 02TimesFM: code, model releases and TimesFM 2.5 notesGoogle Research on GitHub
  3. 03A decoder-only foundation model for time-series forecasting (ICML 2024)arXiv
  4. 04A decoder-only foundation model for time-series forecastingGoogle Research Blog
  5. 05TimesFM 2.5 (200M) model card and Apache 2.0 licenceHugging Face
  6. 06Kronos: A Foundation Model for the Language of Financial MarketsarXiv
  7. 07Kronos: open models, licence and fine-tuning disclaimersGitHub
  8. 08Financial Fine-tuning a Large Time Series ModelarXiv
  9. 09Re(Visiting) Time Series Foundation Models in FinancearXiv

Last source review: Sep 29, 2026. This is technical education, not financial or legal advice.