Build cache for AI coding agents

One cache across developers, agents, and CI

A coding agent edits a package, runs checks, and opens a pull request. Another agent starts in a separate worktree, and CI validates the changes again. Each environment can repeat work that a compatible build has already completed. A shared remote build cache lets the build tool restore eligible outputs when the task inputs match.

Cachely provides the managed cache backend. Your existing build tool decides which tasks are cacheable and computes their keys. Agents invoke the same commands as developers; they do not need a separate cache integration. Read the remote build cache guide for how task hashing and output restoration work.

Unified means one managed service and workspace access model across supported tools. Each tool keeps its own keys and artifact format. It does not mean an Nx task can consume a Gradle cache entry. Cachely caches configured task outputs, not AI prompts, model responses, or agent memory.

Connect your existing build tool

Create a Cachely workspace, configure the remote endpoint, and supply credentials through your environment's secret mechanism. Apply the same non-secret build configuration in developer checkouts, agent environments, and CI. Keep tokens out of committed files and agent prompts.

• Nx setup and Lerna setup: configure cacheable targets and the native Nx remote cache variables.
• Turborepo setup: configure the remote endpoint, token, team value, and artifact signing where enabled.
• Gradle setup: configure HttpBuildCache and allow uploads only from trusted writers.
• Bazel setup: configure the HTTP remote cache and authenticated access.

Follow the CI setup guides for your runner. A fresh agent sandbox still needs the repository, dependencies, and a compatible toolchain. Remote task caching complements dependency caches and container layers; it does not provision that environment for you.

Verify reuse in a fresh worktree

This Nx walkthrough demonstrates the workflow without claiming a measured speedup. First complete the Nx setup, including its version requirements. Replace my-app:build with an existing cacheable target that declares its inputs and outputs. Use an isolated test workspace so the initial remote state is known.

1. Publish from a trusted build

On a clean checkout of a known commit, install the locked dependencies and provide a read-write token through your secret mechanism. Start with an empty local task cache and run the target. Confirm the build executes and uploads its output successfully.

npx nx run my-app:build

2. Restore from a separate worktree

From the same repository, create a fresh worktree at that commit. Install the same locked dependencies there and provide a read-only token for the same Cachely workspace. Ignored environment files are not copied by Git; supply the cache settings to this environment too.

git worktree add --detach ../cache-reuse-check HEAD
cd ../cache-reuse-check
# Install locked dependencies and supply the cache environment settings.
npx nx run my-app:build

Keep the local task cache empty for this check, including any custom shared cache directory. Confirm that Nx reports a remote cache hit and restores the expected outputs. A fast second run in the original checkout can be a local hit and does not prove remote reuse.

3. Change an input, then compare CI

Change a declared source input in the test worktree and run the target again. The affected task should execute; unrelated tasks can still reuse matching entries. A trusted CI build can publish outputs for the reviewed revision. A fresh agent environment at that revision can then repeat the remote-hit check. Access to a warm cache never removes the need to validate changed inputs.

Give agents the right cache access

Reserve write credentials for trusted builds. Give agent environments workspace-scoped read-only tokens when they are allowed to download those artifacts. Cachely enforces read-only access at the API; client flags alone are not the access boundary. Read-only tokens still grant access to output contents, so keep credentials out of sandboxes that must not read them.

Use the build tool's documented read-only mode where available and check its behavior on a cache miss or rejected upload. Withhold credentials from untrusted jobs that cannot safely access the workspace. See token setup and the security model for output review, isolation, and revocation.

Measure the work you avoid

Compare an uncached baseline, a trusted cache-populating run, and remote replay in a fresh environment. Record the commit, tool versions, runner resources, task hit counts, and total elapsed time for each run. Keep dependency installation and cache transfer time visible. Follow the benchmark procedure for repeatable measurements.

• Measure time until checks finish, alongside remote hit rate and estimated avoided task compute.
• Run multiple samples; a warm local cache or a different runner can distort the comparison.
• Do not interpret avoided task compute as the same amount of wall-clock time, token savings, or lower billing.

Reuse is less valuable when most inputs change, tasks are cheap, or downloading outputs costs more than rerunning them. Toolchain differences, absolute worktree paths, and undeclared environment inputs can also undermine reuse or correctness. Keep live-service and nondeterministic checks uncached unless their inputs and outputs can be modeled safely. Use the cache hit-rate guide to investigate misses without weakening validation.