Trade-offs?

[jleni]

what are the tradeoffs around speed, disk usage, isolation, cleanup, and CI behavior?

[jleni]

kache trades a small, bounded per-compile overhead for large wins in reuse, disk dedup, and isolation without coupling. It pays off whenever builds repeat at all (worktrees, CI, incremental day-to-day work), which is almost always.

Speed

Warm hits skip compilation entirely, and restore is hardlink or reflink, so materializing shared bytes is near-instant on modern filesystems. Reuse spans worktrees and, with the remote cache, whole CI fleets and teammates.

The cost is modest and bounded: kache does a little extra work per compile to capture inputs precisely (a dep-info pre-pass for Rust, a preprocessor pass for C). On a first cold build that is a small tax, and it is repaid the moment anything is
built more than once. Since real workflows rebuild constantly, the warm-path savings dominate in practice.

Disk usage

This is one of kache's strongest wins. The store is content-addressed, so identical artifacts dedup across crates, across worktrees, and across machines, and reflink restore means shared bytes are not physically copied at all. On the filesystems
most people already run (APFS by default on macOS, btrfs, XFS, ZFS), N parallel worktrees stop costing N times the disk. That directly answers the dominant pain of agent fleets: running out of disk.

The store does hold blobs plus a small index, and on an older filesystem without reflink (for example ext4) restore falls back to a real copy. A size cap plus automatic GC keeps the whole thing bounded, so total footprint stays under control
without manual babysitting.

Isolation

Each worktree keeps its own ./target/ and feels completely independent, while the cache is shared transparently underneath. That is the property a shared CARGO_TARGET_DIR cannot give you: it serializes builds on a single lock and can hand back
stale artifacts across checkouts through mtime-based freshness. kache gives you the sharing without the coupling.

One deliberate tradeoff worth knowing: kache shares whole-crate artifacts rather than Cargo incremental fragments, so it turns incremental off. For the common case (parallel worktrees, CI, switching branches) that is a clear win. The one workflow
where native incremental can still edge it out is a very tight single-crate edit loop, and you can simply run that crate without the wrapper.

Cleanup

Cleanup is automatic and centralized. Instead of hand-managing N target directories, you have one store that GC keeps under a size cap, using an LRU plus size-weighted score with a grace period that protects builds in flight, and it sweeps orphaned
blobs on its own. A manual clean is there when you want it.

Today the policy is intentionally simple: one global pool governed by a max size. That is plenty for the common case, with finer-grained quotas (for example per language) as a natural next step.

CI behavior

CI is where the remote cache shines. An S3-compatible store (AWS, Ceph, MinIO, R2) shares artifacts across runners and between CI and local, and because kache normalizes paths and env, keys converge across machines, so a fresh runner can hit a
cache populated somewhere else entirely. It degrades gracefully: if the daemon is down it still caches locally, if the remote is unreachable it falls back, and a local-only mode covers CI with no remote at all.

Two things worth setting up deliberately. First, a cold ephemeral runner has an empty local store, so its value comes from the remote tier, which is exactly what the remote cache is for. Second, a shared cache is a shared trust boundary, so the
clean pattern is write from trusted branches and read-only for untrusted PRs. Both are easy to configure and standard for any shared build cache.