Is K2 Horizon Open Source? Audit the Release

Is K2 Horizon open source? The practical answer is “partly, with meaningful variation by checkpoint.” IFM presents K2 Horizon as a fully open family, and several repositories already contain downloadable weights, configuration files, tokenizers, and model code. Yet the current release does not expose every promised training artifact for every size. Teams should audit the exact checkpoint they plan to use, not inherit a family-wide label from the IFM project page.

Define What Open Source Means Here

Weights, code, data, and recipes are separate layers

“Open” is not one switch. K2 Horizon open weights can support local inference without providing the code and data needed to recreate training. A stronger release includes executable training code, data or construction recipes, intermediate checkpoints, evaluation harnesses, logs, and license terms for each artifact.

IFM says its models and code use Apache 2.0 while datasets retain their own applicable licenses. That is a useful starting point, not the end of the audit.

A public model card is not a complete release

A model card can describe architecture, benchmarks, intended use, and a license identifier. It does not prove that every referenced artifact is downloadable or runnable.

As of September 11, 2026, the six principal model repositories expose weights and inference files. Their Hugging Face metadata generally identifies Apache 2.0, although the 0.9B README metadata also contains license_name: internal-only and license_link: LICENSE; the reviewed repository roots did not contain separate LICENSE or NOTICE files. Teams should record both facts and ask counsel how to preserve notices and document provenance. This is general information, not legal advice.

Audit the Current K2 Horizon Artifacts

Check each repository and model size

The K2 Horizon collection lists 375B-A23B, MoVA-36B-A4B, 32B, 7B, 3.7B, and 0.9B variants, plus FP8, GGUF, Uno, and dataset artifacts.

The 375B and 36B cards identify released final checkpoints while describing intermediate checkpoints, training data, and training code as future releases. The 32B model card identifies its current model as Stage 1 and says the final checkpoint and Stage 2 are still to come. The 7B and 3.7B cards state that intermediate checkpoints, training data or recipes, training code, and evaluation resources are released. The 0.9B repository provides a checkpoint, while its card still uses future language for training data, recipes, and code.

That status cannot be generalized across the family. Recheck it against the exact revision before deployment.

Separate available files from future commitments

IFM’s launch announcement promises an open training lifecycle, but promise and delivery belong in separate audit columns. The public IFM GitHub organization currently exposes three repositories. Uno contains working inference, training, and evaluation code for its adapter method. By contrast, xllm contains only a short README, license, and gitignore, while horizon-post-train remains a “stay tuned” placeholder. Neither is presently a complete K2 base-model training stack.

Public related datasets include TxT360-v2 and reasoning collections. Model cards also reference K2-Horizon-Pretrain-Data and K2-Horizon-Midtrain-Data, but those references were not publicly retrievable without authentication during this audit. The available evidence does not establish that the exact K2 Horizon training data is fully public.

Decide What the Release Enables

Reproducible inference and local deployment

For released checkpoints, the weights, tokenizer, configuration, custom modeling files, and examples are enough to begin self-hosted inference. Cards document Transformers, vLLM, or SGLang paths, and quantized artifacts exist for several sizes.

Reproducibility still depends on pinning the model commit, runtime and CUDA versions, precision, chat template, parser settings, context length, and generation parameters. Treat 32B Stage 1 as that named stage, not as the promised final model.

Research, fine-tuning, and derivative work

Released weights create a credible path for parameter-efficient tuning, controlled evaluation, and derivative checkpoints. The Apache License 2.0 generally permits use, modification, and redistribution subject to its conditions.

Full training reproduction is a different standard. Missing exact data bundles, incomplete base-training code, future checkpoints, and unclear links between evaluation outputs and model revisions can stop another team from rebuilding the published model.

Limits and Trade-Offs

Open artifacts still carry license conditions

Open access does not mean condition-free use. Model metadata, source repositories, dataset licenses, upstream dependencies, notices, patent clauses, and trademarks need separate review. TxT360-v2 uses a different license from several Apache-licensed reasoning datasets. Commercial derivative work needs an artifact manifest, not one copied K2 Horizon license label.

Missing pieces can block full reproducibility

The strongest current use case is local inference from a pinned released checkpoint. The weakest is exact end-to-end reconstruction of every family member. Until IFM publishes the promised K2 Horizon code, data or recipes, checkpoints, logs, and version mapping, teams should describe this as a mixed-completeness release.

FAQ

Does IFM accept external K2 Horizon contributions?

IFM’s public repositories expose pull-request and issue mechanisms, and Uno has received pull requests. No K2-wide CONTRIBUTING policy was found, so acceptance rules and contributor licensing should be confirmed with maintainers before substantial work.

Is K2 Horizon development tracked on a public roadmap?

No dedicated public roadmap was found. Model cards and launch materials contain future commitments, but they do not supply dated milestones, owners, or completion criteria. Track repository commits and card revisions instead.

Does IFM publish a process for reporting license violations?

No K2-specific process was found. IFM publishes a general contact address on its organization profile, but that is not a documented reporting and resolution policy.

Does IFM provide a security contact for model issues?

The reviewed repositories did not expose a SECURITY.md or model-specific vulnerability contact. Use IFM’s general contact channel to request a private reporting route before sharing sensitive details.

Are breaking model changes documented in release notes?

No centralized K2 changelog or populated GitHub release history was found. Hugging Face commit histories provide revision evidence, not structured compatibility notes. Pin commit hashes and run regression tests before updating.

Conclusion

K2 Horizon open source is defensible for accessible weights and parts of the surrounding stack, but not yet for a uniformly complete training lifecycle across every size. Self-hosting and derivative experiments are practical for released checkpoints. Exact reconstruction remains conditional on missing code, data, recipes, checkpoints, and change documentation. Audit the chosen revision, license trail, runtime, and dataset terms before adoption.

Previous posts: