kitops

Welcome to the v1.16.0 release of Kit! This release includes a couple new features, as well as a significant number of bugfixes. This release also addresses security advisory https://github.com/kitops-ml/kitops/security/advisories/GHSA-78cw-mw37-jmjg affecting the kit dev command. See the advisory for details.

Breaking Changes

KitOps v1.16.0 removes the kit dev command. We found that this command was not utilized often and updated rarely, while also not fully aligning with the goals of the project overall. For running LLM models locally, dedicated runtimes such as ollama and llama.cpp are a better choice.

New Features

kit skill command

This release adds a new command: kit skill. This is a simple command that can be used to teach an AI agent how to use the kit CLI by installing a SKILL.md file for installed agents on the system.

For more information, see kit skill --help, or the original PR by @youdie006: https://github.com/kitops-ml/kitops/pull/1252

Pack and push in one step

The kit pack command now has a new --push flag, which can be used to push each layer to a remote registry on the fly, rather than storing the ModelKit locally. This can help in storage-constrained situations by avoiding the need to store the entire ModelKit locally before pushing it to a remote registry. Note, however, that this implementation still needs to store each layer (temporarily) before uploading it, so some additional storage is required.

When the --push flag is included, the behaviour of Kit is similar to running

kit pack --tag myregistry.io/myorg/myrepo:tag .
kit push myregistry.io/myorg/myrepo:tag
kit remove --force myregistry.io/myorg/myrepo:tag

For more information, see the PR by @Hemanth-1354 in https://github.com/kitops-ml/kitops/pull/1243

Significant Changes

• feat: respect SOURCE_DATE_EPOCH for reproducible manifest digests by @ericsigurdson-dial in https://github.com/kitops-ml/kitops/pull/1225
• [BREAKING CHANGE] Remove kit dev command and LLM harness by @gorkem in https://github.com/kitops-ml/kitops/pull/1288

Bug Fixes

• Fixup duplicated default documented in pack command by @amisevsk in https://github.com/kitops-ml/kitops/pull/1230
• fix(dev-mode): use animationend for modal scroll lock by @AdeshDeshmukh in https://github.com/kitops-ml/kitops/pull/1220
• Print a warning when skipping symlinks during kit pack by @amisevsk in https://github.com/kitops-ml/kitops/pull/1238
• fix: return error on extra tag removal failure by @AdeshDeshmukh in https://github.com/kitops-ml/kitops/pull/1247
• fix: remove redundant double-close in HuggingFace download by @AdeshDeshmukh in https://github.com/kitops-ml/kitops/pull/1231
• fix: exclude OS-specific files from kit init Kitfile generation by @rishi-jat in https://github.com/kitops-ml/kitops/pull/1099
• fix: correct format verb errors in error messages and logging output by @AdeshDeshmukh in https://github.com/kitops-ml/kitops/pull/1221
• fix: use %w instead of %s for error wrapping in fmt.Errorf calls by @AdeshDeshmukh in https://github.com/kitops-ml/kitops/pull/1222
• fix: merge Prompts from referenced modelkits during Kitfile resolution by @AdeshDeshmukh in https://github.com/kitops-ml/kitops/pull/1232
• fix(git): check destination emptiness without full readdir by @AdeshDeshmukh in https://github.com/kitops-ml/kitops/pull/1141
• fix(skill): tolerate unparseable SKILL.md frontmatter in kit init by @gorkem in https://github.com/kitops-ml/kitops/pull/1239
• fix(pack): compare layer paths by path element, not string prefix by @rishabhsai in https://github.com/kitops-ml/kitops/pull/1280
• Drop empty trace log for license detection in Kitfile generation by @amisevsk in https://github.com/kitops-ml/kitops/pull/1274
• Fix color output handling in logs by @amisevsk in https://github.com/kitops-ml/kitops/pull/1285

Welcome to the v1.15.0 release of Kit! This release improves support for the CNCF ModelPack format, adds support for more options when packing ModelKit data, and adds support for MCP bundles.

New Features

Improved CNCF ModelPack support

Kit is now better at handling CNCF ModelPack artifacts. When working with a ModelPack that was not generated by Kit, Kit can interpret the fields normally found within a Kitfile from the ModelPack's configuration and annotations.

To use Kit to package artifacts in the ModelPack format instead of ModelKit, you can use the flag --use-model-pack for the pack command. Note that not all KitOps features are supported by ModelPacks currently.

Ultimately, you should be able to use ModelPacks with KitOps, regardless of how they were created. For example, the Docker CLI recently added support for creating ModelPacks, and those are now compatible with KitOps.

For more details, see PR #1202

Additional format and compression options for artifact layers

By default, Kit packages each layer (model weights, datasets, code, etc.) as an uncompressed tarball, which provides a good tradeoff in terms of usability, size, and speed. With KitOps v1.15.0, the following extra options are now available while packing ModelKits (or ModelPacks)

• Compression options: in addition to the existing --compression=gzip option, KitOps now supports using Zstandard compression via the flag --compression=zstd.

• Layer format options: instead of packaging files and/or directories as tarballs, Kit can now package single files as-is -- i.e. with no tar wrapper. The primary benefit of the raw format is that the layer DiffID (and digest, for the no compression case) match the actual SHA256 sum of the file on disk, making it easier to track which files are stored in which ModelKits.

  To enable raw layers, use the flag --layer-format=raw on the pack command, though note that this flag currently applies to all layers in the Kitfile.

These changes were added as part of improving ModelPack support; for more information, see PR #1202

MCP support in ModelKits

With Kit v1.15.0, the Kitfile now has a mcpServers section, which can be used to package MCP bundles (.mcpb) files in a new layer format. These bundles are a common way to distribute MCP servers, and adding them to the Kitfile allows for building automation and management around MCP servers specifically.

For more details on how MCP bundles are handled, see PR #1214

Bug Fixes

• Improve auth header handling for push operations by @amisevsk in https://github.com/kitops-ml/kitops/pull/1194
• Respect KITOPS_HOME in library config path by @puneetdixit200 in https://github.com/kitops-ml/kitops/pull/1189
• Add image manifest mediatype to manifests created by Kit by @amisevsk in https://github.com/kitops-ml/kitops/pull/1218
• fix: tolerate missing content in local list and remove by @gorkem in https://github.com/kitops-ml/kitops/pull/1217

New Contributors

• @puneetdixit200 made their first contribution in https://github.com/kitops-ml/kitops/pull/1189

Full Changelog: https://github.com/kitops-ml/kitops/compare/v1.14.0...v1.15.0

Welcome to the v1.14.0 release of Kit! We've added some exciting new features and improvements.

New Features

SLSA attestation generation for kit import

KitOps can now generate attestations when running kit import, saving information about what was imported. The new flag, --attestation-output, can be used to generate a SLSA Provenance v1 predicate for the import process, which can then be pushed alongside the ModelKit to your OCI registry (e.g. by using cosign)

For more information, see PR #1175 by @gorkem.

Support for remote ModelKit references for datasets

Version v1.12.0 added support for datasets stored in S3 buckets via the remotePath field. In version v1.14.0, we are extending the remotePath field to support ModelKit references in addition to S3 URLs.

To illustrate how this changes the behaviour of Kit, consider the Kitfile

manifestVersion: v1.0.0
model:
  path: my-model.safetensors
datasets:
- path: my-dataset/
  remotePath: docker.io/jozu/my-dataset:latest

• When packing this ModelKit, the contents of my-dataset/ will be ignored and not included as a layer in the manifest
• When pushing this ModelKit, only the layer generated for the model will be pushed, saving bandwidth and potentially storage.
• When pulling, the docker.io/jozu/my-dataset:latest ModelKit will also be pulled.
• When unpacking, if the --include-remote flag is provided, the contents of docker.io/jozu/my-dataset:latest will be unpacked into my-dataset/. This is similar to running kit unpack docker.io/jozu/my-dataset:latest -d my-dataset/.

This can be used to group multiple datasets together into one ModelKit for easier management, or to link datasets to model weights without requiring the datasets be pushed and pulled alongside the model.

For details on this change and more explanation, see PR https://github.com/kitops-ml/kitops/pull/1185

More control over output of kit init with --depth flag

With v1.14.0, the output of kit init can be adjusted slightly to include more or less information. Previously, kit init would analyze the files and directories in its target and attempt to group each based on whether it seemed like a dataset, model, code, documentation, or prompt element. With the new --depth flag, this process can continue into subdirectories of the target directory, adding more individual layers to the Kitfile before starting to group entries into whole directories.

This may be useful if a subdirectory contains many large files that ideally should not be included in a single layer. When the flag is not specified, it defaults to --depth=0, which is similar to how kit init behaved prior to this change.

For more details and examples, see PR https://github.com/kitops-ml/kitops/pull/1176

Significant Changes

• During kit init, the generation of a "catch all" code layer, that contains all other files in the directory has changed. You should only see a layer with path: '.' when there are more than 5 files in the base directory. Additionally, when a "catch all" code layer is generated, it no longer replaces all previously-generated code layers. To see the discussion around this change, see https://github.com/kitops-ml/kitops/pull/1176#discussion_r3268339692

• KitOps now sets the org.opencontainers.image.created annotation on manifests created when running kit pack. This means that re-packing a ModelKit will result in a different overall digest hash, though individual layers should retain reproducible digests (saving the need to re-push them). For more information, see PR https://github.com/kitops-ml/kitops/pull/1139 by @itniuma2026.

• Unpacking ModelKits as skills now supports auto-detecting more tools and agents. See PR https://github.com/kitops-ml/kitops/pull/1181 for more details

Bug Fixes

• Starting in v1.14.0, KitOps will be less intrusive with notif

Welcome to the v1.13.0 release of Kit! In this release, we've improved how KitOps handles ModelKits that contain AI agent skills.

New Features

Support for unpacking skills to agent directories directly

The kit unpack command now supports flag --as-skill. When specified, any skills within that ModelKit are automatically installed for any AI tools (e.g. Codex, Claude Code) that you have installed on your system. By default, Kit will install skills to all agents, globally.

To install skills only for a specific tool, e.g. Claude Code, specify the tool name as an argument for the --as-skill flag:

kit unpack <my-modelkit> --as-skill=claude-code

To install the skill to a local directory rather than globally, the --directory flag can be used to add skills only for the specified directory.

For more details, see PR https://github.com/kitops-ml/kitops/pull/1158

Full Changelog: https://github.com/kitops-ml/kitops/compare/v1.12.0...v1.13.0