# Lob CLI

Lob is a separate, external tensor-native version-control system that Tensormorph anchors to (see [Merge Conflicts](/docs/compare-and-morph/merge-conflicts)) - it is not part of the `tmorph` CLI, and its own command reference is Lob's to document, not Tensormorph's. This page covers only how the two CLIs interact.

Where [`tmorph`](/docs/cli-and-automation/tensormorph-cli) operates on a checkpoint file directly, Lob's own CLI operates on weight history - commits, branches, and the structural conflicts that [Merge Conflicts](/docs/compare-and-morph/merge-conflicts) describes as needing resolution outside Tensormorph. If your work involves resolving a structural conflict or inspecting Lob history directly, that happens through Lob's CLI or a Lob-native tool, not through `tmorph`.

## Where the two meet

A checkpoint opened in Tensormorph carries a **commit pin** back to the Lob commit it came from (see [Hugging Face Models](/docs/working-with-models/hugging-face-models#addressing-a-model-by-revision) for the same addressing idea applied to Hub revisions). Scripting a pipeline that touches both tools typically looks like:

1.  Resolve or update history using Lob's own CLI.
2.  Materialize or check out the checkpoint at the commit you want.
3.  Hand that file to `tmorph index` / `tmorph validate` for the Tensormorph-side steps - see [Batch Inspection](/docs/cli-and-automation/batch-inspection) and [CI Validation](/docs/cli-and-automation/ci-validation).

## Related resources

-   [Merge Conflicts](/docs/compare-and-morph/merge-conflicts) - what Tensormorph does and doesn't do at the Lob boundary.
-   [Tensormorph CLI](/docs/cli-and-automation/tensormorph-cli) - the `tmorph` commands that pick up where a Lob checkout leaves off.
-   [Versions and Branches](/docs/hub-and-collaboration/versions-and-branches) - more on how Tensormorph addresses Lob-versioned checkpoints.