A genuinely useful, multi-library OSS time-series ecosystem with a machine-readable llms-full.txt — but the docs leak cross-library copy-paste into a flagship class reference, can't agree on how many models exist, and ship a nightly install command that fetches packages over plaintext HTTP.
1. NeuralForecast's core class reference describes a different library (critical)
Location: /neuralforecast/core.html
Problem: The canonical reference for the NeuralForecast class opens by naming the wrong class entirely: "The core.StatsForecast class allows you to efficiently fit multiple NeuralForecast models." In the same reference, both predict and cross_validation describe their return value as "DataFrame with insamplemodels columns for point predictions" — "insample" appears lifted from predict_insample and is wrong for an out-of-sample predict/cross_validation.
Consequence: This is the page a developer or coding agent reads to understand the primary entry point of the library, and it tells them they're using StatsForecast and that predict returns in-sample columns. An agent generating code against this contract will mislabel the object and mis-handle the returned frame; a human loses trust in the reference the moment they notice the class name doesn't match the page.
The fix: Regenerate the NeuralForecast docstring so it names core.NeuralForecast, and correct the predict/cross_validation return descriptions to say out-of-sample point-prediction columns (reserve "insample" for predict_insample).
2. Three different counts of how many NeuralForecast models exist (significant)
Location: /neuralforecast/docs/getting-started/introduction.html vs /neuralforecast/docs/capabilities/overview.html
Problem: The Getting Started "Model Collection" bullet enumerates ~13 models ("MLP, LSTM, RNN, TCN, DilatedRNN, NBEATS, NHITS, Informer, TFT, PatchTST, VanillaTransformer, StemGNN and HINT"). The capabilities/overview model table lists ~35, including many absent from that bullet (KAN, xLSTM, TimeXer, RMoK, SOFTS, TimeMixer, iTransformer, TSMixer, BiTCN, DeepAR, TiDE, TimesNet, TimeLLM, etc.). Other Nixtla copy advertises "more than 30 state-of-the-art models." The three numbers do not reconcile.
Consequence: A developer who starts at the introduction page — the natural entry point — believes the library ships ~13 models and never discovers KAN, iTransformer, TimeMixer, or DeepAR. An agent indexing the getting-started page builds an incomplete model registry and will refuse to emit valid model names that actually exist.
The fix: Make the overview model table the single source of truth and generate the introduction's "Model Collection" list from it (or replace the hardcoded list with "see the full model table"), so the count can't drift.
3. Nightly-wheel install command fetches packages over plaintext HTTP (significant)
Problem: The documented nightly install is pip install --extra-index-url=http://nixtla-packages.s3-website.us-east-2.amazonaws.com --trusted-host nixtla-packages.s3-website.us-east-2.amazonaws.com statsforecast. It points pip at a plaintext http:// index and adds --trusted-host, which suppresses pip's insecure-host error so the unencrypted fetch proceeds.
Consequence: Developers copy-paste a command that permits package downloads over an unauthenticated, unencrypted http:// channel — a classic MITM/supply-chain exposure where a network attacker can swap the wheel. Worse, it normalizes --trusted-host as a routine flag, training users (and agents) to suppress pip's security warnings as a matter of course.
The fix: Serve the nightly index over https:// (e.g. the bucket's HTTPS endpoint or a CDN) and drop --trusted-host from the documented command.
4. Same dataset, two different freq values across products (significant)
Problem: The NeuralForecast getting-started page forecasts the AirPassengers monthly series with freq='ME' (month-end), while the TimeGPT quickstart forecasts the same monthly dataset with freq='MS' (month-start). Same data, contradictory frequency string. (Per the evidence annotations, the StatsForecast quickstart also uses ME, but only the NeuralForecast page's ME and the TimeGPT page's MS are present in the scraped verbatim text.)
Consequence:ME and MS produce different date indices, so a developer or agent stitching an OSS example together with a TimeGPT example gets misaligned timestamps — off-by-one period boundaries that surface as subtly wrong forecasts rather than a clean error. Humans might catch it; agents won't.
The fix: Standardize the freq value used for the shared AirPassengers example across all quickstarts (OSS and TimeGPT), and add a one-line note on why month-start vs month-end matters.
5. API-key setup documents success but not failure (significant)
Problem: The page covers direct-key, NIXTLA_API_KEY env var, and .env configuration, and notes validate_api_key() returns True/False. It documents no error or failure behavior: there is no statement of what exception or status is raised on an invalid/expired key, on insufficient credits, or on rate limiting — only "ensure you have adequate credits by checking your Nixtla Dashboard."
Consequence: A developer cannot write correct error handling without knowing the exception type/status, and an agent that hits an expired key or a depleted credit balance fails with no documented contract to catch — turning auth/credit/rate failures into opaque tracebacks.
The fix: Document the concrete failure modes: the exception class or HTTP status returned for invalid/expired keys, insufficient credits, and rate limits, plus a short remediation for each.
6. The version-pin example pins a years-old release (minor)
Problem: The install warning advises pinning, with the literal example pip install statsforecast=="1.0.0". The project has shipped many releases since (active through late 2025), so the worked example installs an old version.
Consequence: The advice to pin is good and only bites someone who copies the literal 1.0.0, but a developer or agent that does so installs 1.0.0 — missing years of models, bug fixes, and API changes — then hits behavior that contradicts the rest of the current docs.
The fix: Use a current version in the example, or demonstrate the pattern without a stale hardcoded number (e.g. pip install "statsforecast==<latest>" referencing the latest release, or a >= floor with a recent version).
7. The hub mixes off-site commercial products with OSS libraries and offers no first step (minor)
Problem: The Nixtlaverse hub lists "Nixtla AI" and "TimeGPT" in the same card grid as the open-source libraries (StatsForecast, MLForecast, etc.) without indicating that those two are commercial offerings documented on a different site (www.nixtla.io/docs). The hub itself provides no install or getting-started entry point — only a list of libraries.
Consequence: A developer landing on the hub expects a unified OSS install path, then clicks "TimeGPT" and is silently moved to a separate commercial docs domain with a different package (nixtla) and API-key requirements — with no signpost that they've left the OSS ecosystem. There's also no obvious "start here," so the first action on the hub is ambiguous.
The fix: Visually label the commercial/off-site offerings (badge them and note the www.nixtla.io/docs domain), and add a short "getting started / pick a library" quickstart on the hub itself.
8. HierarchicalForecast is the only library that leads with uv (minor)
Location: /hierarchicalforecast/index.html vs sibling library index pages
Problem: HierarchicalForecast recommends uv as the package manager and leads its install with uv pip install hierarchicalforecast. Across the scraped index pages, plain pip install is the consistent baseline (StatsForecast, MLForecast, CoreForecast, DatasetsForecast all lead with pip; MLForecast also documents conda install -c conda-forge mlforecast). HierarchicalForecast is the lone library that fronts uv.
Consequence: A developer or agent installing several Nixtla libraries in one session hits an inconsistent install convention for one of them, and uv pip install fails outright if uv isn't installed — an avoidable speed bump unique to this package.
The fix: Lead with the same pip install hierarchicalforecast command as the rest of the ecosystem, and present uv as an optional alternative.
9. Spelling errors in library landing copy (minor)
Location: /statsforecast/index.html and /hierarchicalforecast/index.html
Problem: StatsForecast's index renders the heading "Sparse or Inttermitent" (DOM-confirmed via kernel render). HierarchicalForecast's intro verbatim text contains "Hierachical Forecast offers" and "temporal hierachies"; a third instance, "download hierarhical datasets," is flagged in the evidence annotation but is not in the scraped verbatim body, so verify it directly on the live page.
Consequence: These are low-impact but appear in headings and first-paragraph copy on landing pages, which dents credibility and adds noise to on-site/agent search indexing for the very terms ("hierarchical," "intermittent") users search on.
The fix: Spellcheck the index pages; "Inttermitent" → "Intermittent," "Hierachical"/"hierarhical" → "Hierarchical," "hierachies" → "hierarchies."
10. Performance highlights are a batch of unsourced claims (minor)
Location: /statsforecast/index.html (Highlights)
Problem: The Highlights list asserts "20x faster than pmdarima," "500x faster than Prophet," "4x faster than statsmodels," "1,000,000 series in 30 min with ray," and "Fit 10 benchmark models on 1,000,000 series in under 5 min" as a block, without per-claim benchmark conditions (hardware, versions, dataset) attached to each number.
Consequence: A developer can't reproduce or sanity-check the numbers, and an agent will happily repeat unqualified "500x faster than Prophet" as fact. Performance claims without conditions read as marketing, undermining the otherwise technical page.
The fix: Link each speed claim to a reproducible benchmark stating hardware, library versions, and dataset, or consolidate them into a single benchmarks page that the highlights reference.
11. CoreForecast reference shows copy-pasted example outputs and mismatched parameter tables (minor)
Location: /coreforecast API reference (as compiled into /llms-full.txt — verify against the live reference pages)
Problem: Surfaced from the compiled llms-full.txt (second-hand, flagged for verification): expanding_std, expanding_min, and expanding_max all display the same skipna=True output array([1., 1.5, 1.5, 2.33..., 3.0]), which is the expanding_mean result — min/max/std would differ. Separately, find_season_length(x, max_season_length) documents only x in its parameters table (missing max_season_length); LocalBoxCoxScaler lists method first in its signature but last in its parameters table; and some tables mark skipna as required while the signatures show skipna=False.
Consequence: A developer reading the expanding-window examples sees identical outputs for three different operators and can't tell what each actually returns, and an agent parsing the parameter tables either misses a real argument (max_season_length) or mis-orders/mislabels skipna defaults — producing calls that don't match the function signatures.
The fix: Regenerate the CoreForecast reference from source, re-execute the example cells so each operator shows its true output, and reconcile the parameter tables (argument order, missing params, and skipna default) with the actual signatures.
12. DatasetsForecast index has no conda path and no per-dataset descriptions (minor)
Location: /datasetsforecast/index.html
Problem: The install section shows only pip install datasetsforecast with no conda option (MLForecast, by contrast, documents conda install -c conda-forge mlforecast). The "Datasets" section is a bare list of names — Favorita, Hierarchical, Longhorizon, M3, M4, M5, PHM2008 — with no description of what each dataset is, its domain, frequency, or size.
Consequence: A developer scanning the index can't tell which dataset fits their task or how big it is without leaving the page to dig elsewhere, and a conda-based environment gets no documented install path for this one library while its siblings provide one.
The fix: Add a one-line description per dataset (domain, frequency, number of series) on the index, and either document a conda-forge install option or state explicitly that conda isn't supported for this package.
What they do well
A machine-readable llms-full.txt exists — a compiled, agent-friendly docs corpus that most doc sites still lack.
One consistent interface across libraries — the advertised sklearn-style .fit/.predict convention (StatsForecast, MLForecast, NeuralForecast) lowers the cost of moving between libraries.
Runnable quickstarts — MLForecast's quick-start works end-to-end, and the DatasetsForecast example shows real shapes/output, so the happy path is genuinely copy-pasteable.
Top 3 recommendations
Fix the NeuralForecast core.html class reference first — it names the wrong class and mislabels predict's return contract; it's the canonical API doc and the highest-leverage correction.
Establish a single source of truth for the model list and the freq convention — generate the introduction model list from the overview table, and standardize ME vs MS across every shared-dataset quickstart (OSS and TimeGPT).
Harden the install docs — serve the nightly index over HTTPS without --trusted-host, replace the ==1.0.0 pin example with a current version, and lead HierarchicalForecast with the same pip command as its siblings.
All evidence gathered and verified. The live coreforecast Expanding reference (confirmed at https://nixtlaverse.nixtla.io/coreforecast/expanding) shows the copy-pasted 1., 1.5, 1.5, 2.33 output 12 times, and NixtlaClient.plot runs offline (returns a Figure). I have everything needed to compile the report.
All six open-source library quickstarts were installed and executed end-to-end and PASS: StatsForecast (AutoARIMA), MLForecast, NeuralForecast (NBEATS/NHITS), HierarchicalForecast, DatasetsForecast, plus CoreForecast install. Where the docs show expected output, it matched exactly — MLForecast's MLForecast(...) repr, NeuralForecast's Seed set to 1 (×2), and DatasetsForecast's ((20631, 17), (13096, 17)). The freq='ME' usage flagged in the evidence works on the current releases.
The 5 FAIL rows are all on the CoreForecast Expanding reference (surfaced via llms-full.txt, confirmed live at /coreforecast/expanding). Root cause: the page documents a skipna parameter and skipna=True doctests that do not exist in any released CoreForecast (latest = 0.0.16), so every skipna=True line raises TypeError. Additionally the documented default outputs for expanding_std/expanding_min/expanding_max are copy-pasted from expanding_mean (actual results differ), and expanding_quantile(x, 0.5) raises RuntimeError at runtime rather than returning the shown array.
The 18 SKIP rows are environment/credential limited, not docs defects: TimeGPT forecast/validate_api_key calls (no NIXTLA_API_KEY provided — though the offline read_csv and plot snippets PASS); conda install ×3 (no conda); uv pip install (no uv); PowerShell $env: (no PowerShell); the StatsForecast git+/NeuralForecast dev-clone source installs (no C++ compiler / repo clone out of scope); and the statsforecast[extra1,extra2] illustrative placeholder. Note: the version-pin command pip install statsforecast=="1.0.0" PASSES (installs cleanly when shell-parsed) and the nightly-wheel command PASSES — but both carry doc-quality concerns noted below (a 2022 pin example; an insecure http:// index with TLS verification disabled).
Required credentials
NIXTLA_API_KEY — TimeGPT / Nixtla SDK (NixtlaClient). Not provided, so all key-dependent TimeGPT snippets were skipped. Docs use placeholders my_api_key_provided_by_nixtla, your_api_key_here, your_api_key only.
No credentials are required by any of the open-source Nixtlaverse library snippets.
No runnable code snippets (API reference text). The flagged "core.StatsForecast" copy-paste wording and the "insample" Returns text are documentation-accuracy issues, not executable examples.
expanding_mean(x) matches docs, but expanding_mean(x, skipna=True) → TypeError: unexpected keyword argument 'skipna'. Diagnosis: docs document a skipna param absent from released CoreForecast (latest 0.0.16). Suggested fix: ship the skipna API or remove skipna=True lines until released.
skipna=True → TypeError (param not released). Also documented default array([1., 1.5, nan, nan, nan]) is wrong — actual is [nan, 0.70710678, nan, nan, nan] (doc output copy-pasted from expanding_mean).
Default expanding_quantile(x, 0.5) raises RuntimeError: std::exception (not the shown array) on NaN input; skipna=True → TypeError. Suggested fix: correct NaN handling and align signature with shipped release.
Requires a valid API key (server call). Cross-product note: uses freq='MS' for the same AirPassengers data the OSS quickstarts forecast with freq='ME'.
forecast(h=36, model='timegpt-1-long-horizon') (+ its plot)