CAVS is a Rust core wrapped in a command-line toolkit, an HTTP origin and a streaming client — plus language SDKs for Go, Kotlin and Node, engine plugins for Godot (shipping) with Unity and Unreal on the way, and a SteamPipe-style build & update analyzer built into the CLI. Everything below is Apache-2.0 licensed and lives in one repository.
Core, SDKs, engine plugins and the desktop app now release on independent version trains. Every button below resolves to the latest published release of that product automatically.
The cavs / cavs-server / cavs-client binaries and the Rust crates.
Go, Kotlin and Node — versioned together with the core they bind to.
The Godot plugin as an installable addons/ zip. Unity and Unreal are on the way.
Core & SDKs share a version (the SDKs bind the core through a C ABI). Plugins and the desktop app version independently — a desktop-only change ships a desktop release without touching the core.
Package, inspect, verify, diff, apply, plan and benchmark — the whole offline toolkit and delivery planner in one binary.
A stateful HTTP origin with a route planner, and a native streaming client with a verifying, self-repairing cache.
The .cavs format, content-addressable store and CVSP protocol as a set of composable Rust crates.
Drop-in content delivery inside your game engine, over the shared Rust core. Godot ships today in pure GDScript; Unity and Unreal are on the way.
SteamPipe-style update estimates, pack-layout diagnosis, publish previews, disk I/O estimates and a local depot/branch workspace — inside the CLI.
Drive the same Rust core from your backend and build pipelines — analyze, preview, pack, plan, apply, verify, benchmark — no shelling out to the CLI.
The SDKs load the same compiled Rust core the CLI uses through a stable C ABI, and expose idiomatic APIs — so publishers, backend teams and CI/CD systems integrate CAVS programmatically instead of shelling out. One JSON contract, three ecosystems: analyze, preview, packDirectory, createPlan, applyPlan, verifyInstall, benchmark and estimateSavings.
cgo binding with context.Context cancellation, WithProgress events and typed *cavs.Error. Go 1.21+.
FFM (JEP 454) binding, AutoCloseable client, CompletableFuture async, kotlinx.serialization DTOs. Java 22+, Gradle & Maven.
Node-API binding, Promise-first, AbortSignal cancellation, progress events and full TypeScript types. Node 20+.
Every SDK carries the same operations and error codes; the native library ships per platform (linux / macOS / windows, x86_64 & arm64) with a SHA-256 checksum the loader verifies. Full references: Go, Kotlin, Node.
Content is split into chunks identified by their BLAKE3-256 hash; each unique chunk is stored once. The CLI packages releases, produces offline patches, plans delivery routes, manages the store and runs the reproducible benchmark suite. Every command is grouped below.
CAVS
cavs pack --raw <file> -o <out.cavs>cavs pack-dir <dir> -o <out.cavs>cavs unpack <in.cavs> -o <dir>cavs keygen -o <key>cavs signature export <build> -o <.cavssig>cavs preview <new> --against <.cavssig>cavs diff-plan <old> <new> -o <.cavsplan>cavs apply --old <dir> --plan <.cavsplan> --inplacecavs verify-install <dir> --against <.cavssig>cavs file <.cavs> · cavs ls <.cavs>cavs route-plan --installed <dir> --new <dir>cavs optimize-patch <old> <new> -o <.cavspatch>cavs apply-patch <.cavspatch> --memory-budget 128MiBcavs patch-policy --versions v1,…,vNcavs bench patch-policy --versions-dir buildscavs publish-dir <new> --previous <old> --out-dir <dir>cavs bench steampipe-style <old> <new>cavs analyze steampipe <old> <new>cavs analyze-packs · cavs analyze godot-pckcavs publish-preview <new> --previous <old> --routes allcavs io-estimate <old> <new>cavs plan-update --policy balanced --client-state …cavs optimize-layout <old> <new> --write-plan plan.jsoncavs workspace init · depot add · branch add · build createcavs branch promote / promote-preview / rollbackcavs depot analyze-sharing · cavs install-plancavs serve <workspace> --port 8990cavs build sign / verify / encrypt / decryptcavs store add / rm / gc / stat / verify / exportcavs info <.cavs> · cavs verify <.cavs>cavs manifest …cavs doctor · cavs test corrupt · cavs test apply-recoverycavs bench gen --size 1GiB --out dscavs bench suite --dataset ds --out resultscavs bench full-pipeline · butler-full · routescavs bench steampipe-cases --out resultsEvery subcommand has full --help. Without --raw, cavs pack treats inputs as video and segments them into CMAF/fMP4 via ffmpeg before packaging.
Serves one or more .cavs releases over HTTP/HTTPS. Negotiates the compact manifest, tracks per-session cache have-sets with a Bloom filter, runs the route planner, and exposes a Range-resumable bootstrap endpoint.
$ cavs-server game_v1.cavs game_v2.cavs \ --listen 127.0.0.1:8990
Reconstructs by streaming to disk with a persistent content-addressable cache — verify / repair / gc, a crash-safe resume journal, and retry with backoff. Peak RAM stays constant regardless of game size.
$ cavs-client fetch http://127.0.0.1:8990 game_v2 \ -o out/game_v2.pck --cache ./cache \ --stats-json stats.json
The delivery engine is a Cargo workspace. Libraries compose the format, store and protocol; three of the crates ship as the command-line tools.
| Crate | Kind | Role |
|---|---|---|
| cavs-hash | lib | BLAKE3-256 chunk identity, Merkle root, signature message |
| cavs-chunker | lib | Fixed-size and FastCDC chunking |
| cavs-store | lib | Dedup index + on-disk store (refcount + GC; loose or .cavspack packfiles with coalesced range reads) |
| cavs-format | lib | The .cavs binary format: writer, hardened reader, Ed25519 signing |
| cavs-proto | lib | CVSP wire protocol: manifests, sessions, binary batches, Bloom have-set, CAVS-E-* error taxonomy |
| cavs-manifest | lib | Manifest formats: compact binary v2 (CAVSMF2) + JSON v1 compatibility |
| cavs-cli | tool · cavs | Package / inspect / verify / reconstruct / store / doctor / bench |
| cavs-server | tool · cavs-server | Stateful HTTP/HTTPS origin (Range-resumable bootstrap) |
| cavs-client | tool · cavs-client | Native streaming client: cache verify/repair/gc, resume journal, backoff |
$ cargo build --release # binaries in target/release/ $ cargo test # unit + integration + end-to-end
Each plugin brings deduplicated, verified content delivery to its engine's native containers over the shared Rust core — the player downloads only the chunks that changed and the payload is reconstructed byte-identically (SHA-256 verified). Godot ships today as a pure-GDScript client; Unity and Unreal are on the way. Each has its own install & usage guide.
A 100% GDScript client — no GDExtension, no native binaries. Reconstructs and mounts PCKs with load_resource_pack(). Measured updates −67% to −70% vs the full PCK.
A C# CavsClient over CVSP for AssetBundles and Addressables, an editor post-process to package build output, and a verified runtime cache.
A C++ runtime client over CVSP for PAK / IoStore (.ucas / .utoc), a build hook to package cooked output, and alignment-aware packaging guidance.
Full guides: Godot, Unity, Unreal. The Godot plugin is the reference client today.
v0.9.0 makes CAVS a SteamPipe-style local build-update lab. Estimate a build transition under a public fixed-1MiB chunk model, diagnose the pack layouts that bloat updates (scattered churn, asset shuffling, distributed-TOC/offset cascades, global compression, metadata churn), preview every delivery route before release, and price the local disk I/O per device — entirely locally, uploading nothing. Every estimate is SteamPipe-style: a model from public documentation, never Valve's implementation. There is deliberately no separate steam-analyzer product.
# the numbers — fixed-1MiB model estimate $ cavs bench steampipe-style ./build_v1 ./build_v2 --out results/ # the diagnosis — findings with causes and fixes $ cavs analyze steampipe ./build_v1 ./build_v2 --out analysis.md $ cavs analyze-packs ./build_v1 ./build_v2 $ cavs analyze godot-pck old.pck new.pck # names the res:// paths behind the churn # the decision — every route measured, one recommended $ cavs publish-preview ./build_v2 --previous ./build_v1 --routes all $ cavs io-estimate ./build_v1 ./build_v2
| Same 64 KiB edit, different pack layout | SteamPipe-style estimate | CAVS .cavsplan | Diagnosis |
|---|---|---|---|
| Localized edit, stable layout | 1.00 MiB (97% reuse) | 131 KiB | OK |
| 4 KiB inserted at the front (everything shifts) | 32.88 MiB (0% reuse) | 7.4 KiB | asset_shuffling |
| Per-asset headers rewritten each build | 32.00 MiB (3% reuse) | 2.13 MiB | toc_churn |
| Same edit, TOC centralized (the fix) | 1.88 MiB (94% reuse) | 132 KiB | OK |
Deterministic 32-asset packs, reproducible with cavs bench steampipe-cases. Layout — not content — decides fixed-chunk update cost; the analyzer names the cause and the fix, and content-defined CAVS routes absorb the pathology either way. A ~3-byte edit in a 256 MiB pack still costs 512 MiB of local I/O unless the pack is split — cavs io-estimate flags exactly that.
cavs workspace init · depot add · branch add · build create — SteamPipe-like apps/depots/branches/builds as local metadata, with atomic branch promote / rollback and per-depot promotion previews. No accounts, no platform.
depot analyze-sharing reports shared bytes across depots (measured: windows ↔ linux 98.9%); cavs install-plan simulates what a player downloads by platform, language and ownership — with cross-depot chunk reuse (a demo owner with the full game: 0 B).
cavs serve exposes the workspace over local HTTP (branches, depot files with Range, chunks by hash, update previews) for plugin testing — dev-only by design. cavs build sign / verify / encrypt add release authenticity and optional at-rest encryption — not DRM.
Run CAVS against two versions of your build and compare full download vs update payload.
1 — Install
$ cargo install cavs-cli $ cargo install cavs-server $ cargo install cavs-client
2 — Pack two versions
$ cavs pack --raw game_v1.pck \ --profile auto --bootstrap -o game_v1.cavs $ cavs pack --raw game_v2.pck \ --profile auto --prev game_v1.cavs -o game_v2.cavs
3 — Serve
$ cavs-server game_v1.cavs game_v2.cavs \ --listen 127.0.0.1:8990
4 — Fetch & check stats
$ cavs-client fetch http://127.0.0.1:8990 game_v2 \ -o out/game_v2.pck --cache ./cache \ --stats-json stats.json # { "delivery_mode": "chunks", # "payload_bytes": 1719664, # "reconstructed_sha256_ok": true }
5 — Offline patch — no server (sign · preview · diff · apply · verify)
$ cavs signature export ./Build_v1 --raw -o build_v1.cavssig $ cavs preview ./Build_v2 --against build_v1.cavssig --changes-only $ cavs diff-plan ./Build_v1 ./Build_v2 -o update.cavsplan $ cavs apply --old ./InstalledGame --plan update.cavsplan --inplace --verify # apply : OK — 6 written, 38 unchanged (no-op), 2 deleted # bytes : 20.58 MiB — 19.00 from the old install, 1.58 from the plan
6 — Certify before release (v1.0.0)
$ cavs certify --old ./Build_v1 --new ./Build_v2 --profile release --out ./certification # Result: PASS — integrity, routes, regression, SteamPipe-style analysis # byte-identical output · recommended route: .cavsplan (2.26 MiB vs 126.89 MiB full) # exit codes: 0 pass · 1 fail · 2 warnings · 3 missing dep · 4 bad input · 5 internal
7 — Auto-route delivery (publish · policy · route-plan)
$ cavs publish-dir ./Build_v2 --previous ./Build_v1 --out-dir releases/ $ cavs patch-policy --versions v1,...,v10 --distribution shares.json $ cavs route-plan --installed ./InstalledGame --new ./Build_v2 \ --patch releases/v1_to_v2.cavspatch --profile low-memory # cavspatch 7.67 MiB ram 551.67 MiB [excluded] over the 128 MiB budget # chosen : cavsplan — 7.63 MiB over the wire, fits low-memory (40 MiB peak)