Choosing an integration

There are several ways into CAVS Node, and they compose. This page is the short path to the right one.

Decide by workflow

If your files…	Use	Why
live in a Git repository and change with your source	`cav` CLI + CAVS LFS agent	`git push` keeps working; you get chunk-level dedup and a browsable index for free
live in a Git repository but you can’t install extra binaries	Standard Git LFS	one `git config` line, no new software, object-level dedup
are produced by a training job or data pipeline	Python SDK	streamed hashing, verified downloads, retries, resumable uploads
are produced by a Node build or release script	TypeScript SDK	same contract, ESM + CJS, streaming
are produced by CI and published as build outputs	GitHub Action or CI recipes	no code, just a step
are handled by a language with no SDK yet	Plain HTTP	the whole flow is four calls
are shipped to end users or game clients	Engine SDKs	embed chunk-level delivery in your app; only missing chunks travel
need to trigger your systems when something lands	Webhooks	signed HTTP callbacks on push, release, quota and GC events

Both paths use the same repository and the same credentials. The difference is what happens to the bytes.

	Standard `git-lfs`	With `cavs-lfs-agent`
Extra software	none	the `cavs-lfs-agent` binary
Transfer unit	whole file	chunks
Dedup granularity	identical files stored once	identical chunks stored once, across versions
Push a 22 MiB file with 3 MiB changed	22 MiB	~3.3 MiB
Pull with the previous version cached	22 MiB	~0.5 MiB
Resume interrupted transfer	LFS retry	HTTP range resume per chunk
Per-object storage stats in the dashboard	logical only	logical and physical + chunk counts
Measured transfer benchmarks	no	yes
Best for	quick evaluation, locked-down machines	anything that changes repeatedly

They are not exclusive. A common shape is:

Git + agent for the assets that travel with your source: configs, small models, textures, sample data.
SDK or CI action for pipeline outputs that shouldn’t live in Git at all: checkpoints, big datasets, nightly build artifacts.

Both land in the same repository, both count toward the same usage, and both show up in the dashboard.

	Python (`cavs`)	TypeScript (`@cavsnode/cavs-sdk`)
Install	`pip install cavs`	`npm i @cavsnode/cavs-sdk`
Runtime	Python 3.9+	Node 18+ (global `fetch`)
Module format	—	ESM + CJS + `.d.ts`
Streaming upload / download	yes	yes
Directory upload	yes	yes
Verified download (oid check)	yes	yes
Retries with backoff + jitter	yes	yes
Injectable transport for tests	`Transport(client=…)`	custom `fetch`
Typed error taxonomy	yes	yes

Both implement the same wire contract, so you can mix them across a pipeline.

These appear in the SDK roadmap and contract documents. They are not live on the platform today — don’t build against them:

Feature	Status
Service accounts and `cavs_sk_` keys	not implemented server-side; use `cavs_ci_` machine tokens
Runs API (`/runs`, run→artifact lineage)	not implemented server-side; declare lineage with `/graph/edges`
`GET /resolve?uri=cavs://…`	not implemented server-side; resolve via repository + oid
MLflow, Kubeflow, Airflow integrations	roadmap
Go and .NET platform SDKs	roadmap — use plain HTTP
Azure Blob / native GCS for BYOS	roadmap — S3-compatible endpoints work today

Integrations overviewEvery supported integration, with its transport, credential type and telemetry headers.

CLI referenceInstall, configure and every cav command.

API overviewBase URL, auth, errors, rate limits, idempotency.