Build caching on Agentic Pipeline

Agentic Pipeline caches your build in two tiers, and you enable neither of them. A run that lands on a warm executor reuses the previous run's clone, node_modules, local turbo cache, and Docker layers with no configuration at all. On top of that, the platform runs a managed turborepo remote cache that gives you turbo hits across machines, so an unchanged package never rebuilds even on a cold executor — it switches itself on for any repo the platform sees running turbo.

Legend: the green caches are on by default on any warm executor; the yellow remote cache turns itself on for turbo repos and adds turbo hits that survive landing on a different, cold machine.

The two tiers at a glance

Cache	Scope	Default	You configure
Clone	Warm executor (per repo)	Automatic	Nothing
node_modules	Warm executor (per repo)	Automatic	Nothing
Local .turbo	Warm executor (per repo)	Automatic	Nothing
Docker layers	Warm executor (machine-wide)	Automatic	Nothing
Managed turbo remote cache	Cross-machine (per repo)	Automatic for turbo repos	Nothing

Automatic warm-machine caches

Executors are pre-warmed and keep a persistent per-repo workspace between runs. When your run is dispatched to a machine that has already run your repo, four things are already on disk and get reused:

• Clone — the working checkout already exists, so the run fetches only new commits instead of cloning from scratch.
• node_modules — your installed dependencies survive between runs (the workspace is cleaned but node_modules is preserved), so a warm install is a near no-op.
• Local .turbo — turborepo's on-disk cache directory persists, so unchanged tasks are restored from cache on that machine. This is turbo's standard local filesystem cache; it only helps when your run lands on the same warm executor that built before.
• Docker layers — the executor's buildx layer cache is machine-wide, so an image build reuses layers whose inputs did not change.

None of this needs a recipe change or any setup — it is how the platform runs every repo. Warmth varies run to run (a fleet-scaling event or a first run on a fresh machine is "cold"); confirming caching below shows how to read the warmth of any run.

:::note The local .turbo cache is not the remote cache The automatic .turbo tier is turbo's local filesystem cache, tied to one warm machine. The managed turbo remote cache below is a separate tier that stores turbo artifacts centrally so hits work across machines. A repo benefits from both at once, and neither needs configuring. :::

Managed turbo remote cache (automatic)

The managed remote cache speaks turborepo's own remote-cache protocol, so your existing turbo run <task> picks it up with zero recipe changes. When it is enabled for your repo, the control plane injects TURBO_API, TURBO_TOKEN, and TURBO_TEAM into the job environment at dispatch; turbo reads those natively and starts pushing and pulling task artifacts to the platform. The payoff: an unchanged package restores from cache even on a cold executor that has never built your repo, because the artifacts live centrally rather than on one machine.

What the platform guarantees:

• Per-repo isolation. Artifacts are namespaced by your repo slug. One repo can never read or poison another repo's cache.
• Signing is platform-managed. The managed cache only accepts signed artifacts, and turbo enables signing solely from remoteCache.signature: true in your turbo.json — there is no environment switch for it. You do not have to add it: the executor sets that field in the run's own working copy at run start, for that run only. Nothing is committed to your repo and your turbo.json on disk is untouched. The one case the platform leaves alone is a turbo.json that does not parse as JSON — fix the file and the cache turns itself on.
• Excluded from sandbox runs. An untrusted sandbox recipe never receives the cache token.
• Bounded artifacts. Each cached artifact is capped at 100 MB — generous headroom over any real JS/TS build output.

Turning it on (you don't)

There is no enable step. The platform decides, per repo, from what it already knows: once one of your completed runs shows the repo has a turbo.json, the next dispatch injects the cache credentials and your existing turbo run calls start using the remote cache. Nothing to add to .slipstream.json, no token to manage, no request to file. A brand-new repo is picked up after its first completed run.

Two config keys exist, and both only ever turn caching off — they are kill switches for platform operators, not settings you need:

slipstream.turbo_remote                      # fleet-wide, defaults to 1
slipstream.turbo_remote.<owner>/<repo>       # per repo, wins over the fleet key

Setting either to 0 stops managed caching (the per-repo key wins in both directions, so 1 there keeps one repo running while the fleet key is off). Your runs keep working either way — they fall back to the automatic warm-machine caches above.

:::warning Do not set TURBO_TOKEN yourself The managed token is injected for you. If your recipe hardcodes TURBO_TOKEN (for example TURBO_TOKEN="$SOME_OTHER_TOKEN" turbo run build), that value overrides the injected managed token and breaks the managed cache — turbo will authenticate against the wrong cache and get zero managed hits. Leave TURBO_API, TURBO_TOKEN, and TURBO_TEAM unset in your recipe; the platform owns them. If your recipe still carries a hand-set TURBO_TOKEN from a previous self-hosted setup, remove it. :::

Availability

Live and serving the fleet. Two platform-side secrets gate the whole feature — the shared cache token and the fleet signing key — and if either were ever missing the cache would go dark (injecting nothing) rather than fail your runs. The one repo-side condition left is a turbo.json the platform cannot parse: it refuses to touch a malformed file, so that repo stays on local caches until the file is valid. slipstream_onboard reports that case with the exact repair.

Confirming caching is working

Cache warmth is measured per run and surfaced in three places, so you can prove a cache is doing its job rather than assume it:

• Per-run cache split. Every run carries a cache field with a warmth signal per layer — clone, node_modules, turbo, docker — each warm, cold, or na (not applicable, e.g. turbo on a repo with no turbo.json, or docker on a run with no image build). It appears on the runs API and as cache tiles on the dashboard run view. A second run of the same commit should read mostly warm.
• Recipe insights rollup. slipstream_recipe_get with insights returns a cache_layers rollup — a hit percentage and sample count per layer across your recent runs — so you can see cache effectiveness as a trend, not just one run.
• Turbo's own output. For the remote cache specifically, turbo logs cache hit, replaying logs (or cache miss) per task in the stage output; a warm second run should show hits for unchanged packages.

If the automatic turbo layer reads warm on a same-machine rerun, the managed remote cache is what carries those hits across to a cold machine too.

Coming next

A cache-hit-rate telemetry view for consumers — today the hit/miss/store counters are platform-side and surface through platform health rather than as a per-repo report you can read yourself.