Model Licenses Change at the Execution Boundary

Selecting a time-series foundation model used to be described mostly as an accuracy problem. Compare benchmark results, identify a promising family, and try it on a held-out dataset. That remains necessary, but it is not sufficient to choose a deployable system. The artifact you execute and the place where you execute it can determine which uses are permitted and which operating contract applies.

TimesFM 3.0 makes that distinction concrete. The Google upstream repository separates its source-code license, downloaded pretrained-weight license, and authorized Google Cloud usage. Those are different paths to using a related forecasting capability. A directory that flattens them into one “open model” badge would omit information needed for an actual deployment decision.

Our TimesFM 3 research article focuses on the model's technical change toward native multivariate forecasting. This article asks a different question: after a checkpoint looks appropriate, what exactly are you entitled to run, and through which execution boundary?

#Four artifacts that should not share one license label

A repository can contain inference code, training code, examples, configuration, and model references. The license on that repository describes the source it covers. It should not be assumed to cover every pretrained checkpoint that its code can load.

A weight repository is another artifact. It can carry a separate license, access policy, or use restriction. Downloading it and running it on a laptop, browser, server, or third-party machine does not erase those conditions. A converted file is still derived from the same checkpoint even when the execution engine changes.

An exported graph introduces a third artifact. It may include the original weights together with preprocessing, postprocessing, shape constraints, or a different numerical precision. The export's distribution and runtime contract need to identify the source checkpoint and preserve applicable attribution. Its file format does not establish a new permission to use the model.

A hosted service is the fourth boundary. Its operator provides execution under a service contract, potentially with model-specific authorization. The service can have separate privacy, billing, access, reliability, and acceptable-use conditions. A user calling that service is not necessarily taking the same path as someone downloading the public weights.

Artifact	Question to answer	Evidence to keep
Source code	What code is covered by this license?	Repository revision and license text
Pretrained weights	What uses of this checkpoint are permitted?	Model revision and weight license
Exported graph	Which original model and transformations does this file contain?	Source revision, export code, checksum, attribution
Hosted execution	What service and model access does the provider supply?	Provider documentation, supported model contract, service terms

This is an inventory method. It helps identify the relevant documents and avoids inferring permission from an unrelated artifact. It does not replace the actual license or service terms.

#TimesFM 3.0 is the useful counterexample

Downloaded weights and authorized services are distinct execution paths with different documents to check.

Google states that TimesFM source code and pretrained weights through version 2.5 use Apache-2.0. TimesFM 3.0 downloaded pretrained weights are distributed under a separate non-commercial, non-production license. The checkpoint's license file is the primary artifact to read for that download path.

The same upstream documentation identifies an authorized Google Cloud route for commercial and production use. That distinction means a model comparison cannot stop at the family name “TimesFM.” Version, artifact, intended use, and execution provider all belong in the decision record.

A team evaluating 2.5 locally and a team evaluating downloaded 3.0 weights may therefore have different deployment constraints. A team using an authorized cloud service follows another operating contract. Describing all three as equivalent self-hosting options would collapse a distinction that the upstream project makes explicit.

It also affects browser execution. Browser inference is execution on the visitor's device; it is not a mechanism for bypassing checkpoint restrictions. Downloading weights into a tab changes device ownership and data flow, but does not turn a non-commercial checkpoint into an unrestricted commercial artifact.

The directory now represents TimesFM 3.0 with its specific weight-license label and upstream links. It does not advertise a validated TSFM browser graph for the model. That keeps the model comparison connected to the deployment choice rather than implying that every research checkpoint can be executed identically.

#A Hugging Face page is a discovery surface

The Hub is valuable because it brings model cards, files, revisions, licenses, implementation links, and execution options together. It is an appropriate destination from a model directory. It is not evidence, by itself, that a specific provider operates an endpoint for the checkpoint.

Hugging Face Inference Providers supplies a provider integration surface. Whether a selected time-series model is actually deployed must still be checked. A generic provider name or a related model in its catalog does not establish support for your model revision or forecasting task.

Dedicated deployment is another possibility. A custom inference handler can define how requests enter a model implementation and how outputs return. That is a deployment mechanism, not a statement that every downloadable checkpoint is permitted or inexpensive to operate through it.

For a time-series model, the handler may need to preserve cadence, missingness, covariate shapes, horizon limits, and probabilistic output labels. An endpoint that accepts a numerical array but returns a different task head is not an interchangeable forecasting service. Provider availability and numerical contract belong alongside the model's license record.

#The provider owns an operating contract

A browser demo and an external API expose different responsibilities. In the browser, the visitor's device supplies memory and computation. Assets download over the network, and local cache storage can retain weights. A failed model run must be reported to the visitor, who can change input, retry, or choose another execution option.

With an external provider, the service receives the inference request. The application needs to understand credentials, input retention, regional behavior where specified, usage limits, and failure responses. Price may depend on dedicated uptime, batching, request volume, or another provider-defined billing unit. None of those properties can be read from a model parameter count.

A comparison should therefore keep quality and execution cost in separate measurements. The same checkpoint can be tested locally for numerical behavior while an external endpoint is evaluated for cold starts, throughput, timeout handling, and operational fit. These measurements inform the deployment decision without pretending that the model has one universal latency or price.

Our local hosting guide describes the adapter work involved in family-specific execution. The additional lesson is that the adapter is also where service and artifact boundaries become visible. A shared request schema can improve developer experience, but it must not hide which model, rights, and compute path are actually being selected.

#Record the exact checkpoint, not only the family

A model-selection record should retain the repository, revision, license, implementation, intended use, and execution path. For exported artifacts, add the file checksum and the numerical validation evidence. For an external service, identify the provider's advertised model and the endpoint contract tested by the application.

The revision matters because a model repository can change. Its current default branch may contain updated configuration, files, or documentation that differ from an earlier evaluation. A screenshot of a license badge is less useful than a reference to the actual revision and text that were reviewed.

The intended use should be concrete enough to evaluate against those documents. “Try forecasting” is ambiguous. Internal experimentation, an end-user browser demo, a scheduled commercial job, and a production decision system can raise different conditions under a checkpoint's terms. Describing the use precisely helps identify which execution options need further review.

This record should also distinguish observed facts from unresolved questions. If a provider's model revision is not disclosed, state that uncertainty. If a Hub page has no provider mapping, do not present an assumed endpoint. If a community export has not been checked against upstream, do not present its performance or capabilities as established facts.

#Browser support adds a verification obligation

A browser option is attractive when it can provide local data handling and interactive forecasts without an operator-funded GPU backend. It nevertheless creates an artifact-delivery responsibility. The graph must be complete, numerically faithful, licensed for its distribution and intended use, and small enough for a reasonable device experience.

The browser model-contract article describes the validation process for Chronos-Bolt Tiny. Its export includes source attribution, an immutable weight revision, a file checksum, and reference cases. The browser artifact repository carries the upstream Apache license with the complete forecast graph.

That record is separate from a claim that every Chronos checkpoint runs in the browser. Tiny has a particular input and output contract. Other models can retain useful directory pages and external links while browser support remains unverified. A directory is more reliable when it makes those differences visible than when it fills every execution slot with an untested option.

#Keep benchmark evidence in its own lane

A strong benchmark result does not grant execution rights, establish a provider endpoint, or validate a converted graph. Conversely, permissive licensing does not establish forecast quality. Both dimensions belong in model selection, but they answer different questions.

The 2026 model toolkit organizes candidates by job. Add deployment constraints after that shortlist, then evaluate the exact artifact that can be used. This avoids spending an entire selection process on a checkpoint whose intended execution path is unavailable for the task.

For probabilistic decisions, verify output semantics as well. Median, mean, quantile bands, and sampled trajectories are not interchangeable. An external service's response or a browser export must preserve those meanings. The fact that a checkpoint is permitted for use does not make a mislabeled numerical result suitable for the decision.

#A directory can make the boundaries easier to inspect

The useful model page has two layers. The research layer describes the checkpoint, source evidence, tasks, architecture, and weight license. The execution layer lists what can actually run, through which artifact or provider, with which limits and supporting evidence.

For TSFM, one execution option is the validated browser forecast graph. Other options lead to upstream model cards and external provider or deployment information. TSFM no longer supplies a hosted forecasting API or backend GPU fleet, so former TSFM prices and service availability are not model specifications.

This structure keeps the decision honest: choose a model for the task, identify the rights attached to the artifact, verify the execution contract, and then evaluate the runtime. It lets new providers or exports join the directory without changing the identity of the underlying model or obscuring the conditions of the path the user selects.