CAVS is a content-addressed delivery layer for game builds, Godot PCKs, asset bundles and binary releases. It reconstructs the original file byte-for-byte while downloading only the chunks a player is missing.
Point CAVS at two builds and it tells you what the update will cost, produces a verifiable patch, and applies it byte-identically. Use the CLI in a shell step, or the Go / Kotlin / Node SDKs to drive the same Rust core from your release service — no shelling out.
Prefer code? The same check from your backend:
CAVS
import { CavsClient } from "@orelvis15/cavs-sdk";
const cavs = new CavsClient();
const preview = await cavs.preview({
oldPath: "Build_v1",
newPath: "Build_v2",
});
if (preview.routes[0].networkBytes > budget) {
throw new Error("update too large");
}
cavs.close();
CAVS packages a release into content-addressed chunks, signs and verifies the manifest, serves only the chunks a client is missing, and reconstructs the original file byte-for-byte on disk.
For cold installs, CAVS can use a full bootstrap artifact when it is cheaper. The client then seeds its chunk cache from that install, so the next update is incremental — without any extra download.
cavs pack splits the release into content-defined chunks, hashes each with BLAKE3, stores a compact manifest, and optionally emits a bootstrap artifact.
At session open, the server compares the client's cache state with the manifest and picks the cheapest route: chunks, hybrid, plan, sidecar, bootstrap or no-op.
Missing chunks are served in binary CVSP batches. Packfile-backed stores coalesce nearby chunk reads into a few range reads.
The client verifies chunk hashes, streams reconstruction to disk, checks the final SHA-256, then atomically promotes the result.
The reconstructed file seeds the persistent cache — and the version already installed on disk is itself a source of verified ranges, so the next update reuses local bytes first.
Captured over real HTTP sessions using open-source Godot projects exported to PCK at two points in their git history. A player who already has the previous version downloads only the missing chunks.
Re-downloading the same version costs 0 bytes of payload. All reconstructions were SHA-256 verified and byte-identical.
A Rust core with a command-line toolkit, an HTTP origin and streaming client, a shipping Godot plugin, a SteamPipe-style build & update analyzer built into the CLI — and engine plugins on the way.
Package, inspect, verify, diff, apply and benchmark. The offline toolkit and the delivery planner in one binary.
A stateful HTTP origin with a route planner, and a native streaming client with a verifying, self-repairing cache.
A 100% GDScript client — no GDExtension, no native binaries. Reconstructs and mounts PCKs with load_resource_pack().
SteamPipe-style update estimates, pack-layout diagnosis (churn, shuffling, TOC, compression), publish previews across every route, disk I/O estimates and a local depot/branch workspace — all inside the cavs CLI.
One command answers "is this update ready to publish?" — byte-identical verification, route selection per client state, regression guard, Godot PCK checks and reproducible reports with CI-stable exit codes.
CAVS delivery for AssetBundles and Addressables, backed by the Rust core over a stable C ABI.
CAVS delivery for PAK / IoStore (.ucas / .utoc) containers.
CAVS packages releases once, stores chunks by content hash, negotiates compact manifests, chooses bootstrap or chunk delivery per session, verifies every piece, and reconstructs the original artifact atomically.
No. CAVS does not compress pixels like AV1, H.264 or HEVC. It deduplicates and delivers already-built content-addressed chunks. For single videos or ABR ladders, savings are near zero — and reported honestly.
Pairwise delta tools can produce smaller patches for one exact version pair. CAVS is designed for version streams: package once per release, serve many version jumps, reuse cache across versions, resume safely, and expose immutable CDN-cacheable storage.
Yes. Pass --previous-artifact and the client copies verified ranges straight from the old file, downloading only what changed — even with an empty chunk cache. Every copied range is BLAKE3-checked before it is written, and a corrupt old install safely falls back to the network.
Yes. cavs diff-plan produces a deterministic, BLAKE3-sealed .cavsplan, and cavs apply reconstructs it locally with the same verified staged model as the online client — byte-identical or it fails. preview, verify-install, file and ls complete the offline workflow.
Yes. CAVS reconstructs the final artifact byte-for-byte and verifies it with SHA-256 before promotion. Reconstruction is byte-identical or it fails — never halfway.
No. cavs bench steampipe-style and cavs analyze steampipe use a public fixed-1MiB model based on Valve's documentation — an estimate, never Valve's exact implementation, and every report says so. There is deliberately no separate "steam-analyzer" product: it is a CAVS command family for diagnosing update behavior before you publish.
Run CAVS against two versions of your game build: compare update routes, inspect why updates are large, certify byte-identical reconstruction and export a reproducible report — all locally, in minutes.
Have a Godot game with frequent PCK updates? Open an issue or start a discussion — real-world test cases are welcome.