Behavior of Bazel's --experimental_reduce_costs flag for low‑traffic remote HTTP cache usage

Enabling --experimental_reduce_costs does not reliably lower bandwidth for low-traffic builds that rely on a remote HTTP cache without introducing correctness risks. Bandwidth savings are typically observed only when incremental builds have stable action keys and sufficient request frequency to amortize cache misses.

Likely explanation

The flag attempts to skip uploading outputs already present in the remote cache, using action keys as the primary matching criterion. Which outputs are safely omitted depends on Bazel's internal heuristics and action key stability.

Confirmed facts

• Downstream actions that depend on omitted outputs may cause cache misses if the remote cache does not retain the corresponding artifacts, especially across build version upgrades.
• Empirical bandwidth savings vary; net cost reduction is observed only when the remote cache request rate exceeds a workload-dependent threshold, typically seen in large-scale incremental builds with stable action keys.

Uncertain / requires review

The exact criteria for what outputs are omitted under the flag are not fully specified and may change between Bazel versions. The bandwidth-saving threshold is not fixed; it depends on remote cache pricing, network costs, and build frequency, so savings may not outweigh recomputation costs in all scenarios.

Verification steps

1. Run two identical builds, one with --experimental_reduce_costs and one without, then compare remote cache request logs (e.g., from the cache server) for uploaded byte counts and hit ratios.
2. Use bazel test //... --experimental_reduce_costs on a representative incremental build suite and measure action key stability via bazel info action_keys if available.

If action key determinism across your build pipeline cannot be confirmed, the risk of cache misses may outweigh bandwidth savings. Please confirm whether your builds use stable, version-independent action keys.