Bazel 7.0 --max_idle_secs Default Reduction: Tuning for Mixed CI and Developer Environments

Context

Bazel 7.0 lowered the default --max_idle_secs from 10800 to 1800 seconds, aiming to reduce idle memory and CPU consumption in sporadic CI or developer environments. This change accelerates server shutdown, which lowers baseline resource costs but increases cold-start latency for the next build because the analysis cache and persistent workers are torn down. The --nokeep_state_after_build flag (now default) further discards the analysis cache after each build, compounding re-analysis time.

Goal and Constraints

The objective is to identify a configuration strategy that balances idle-server cost against developer-perceived latency across a mixed fleet: shared CI runners that may sit idle for hours between jobs, and developer laptops where interactive builds benefit from a warm server. Persistent workers for Java, Scala, and Kotlin keep language servers alive across builds, but aggressive server shutdown can negate their warm-start benefits. Remote caching and remote execution can amortize cold-start costs, yet introduce network egress and storage fees that may exceed local build costs for very low traffic.

Open Questions

1. What --max_idle_secs values have teams adopted for shared CI runners versus developer workstations, and what metrics guided those choices?
2. Does enabling --keep_state_after_build alongside a longer idle timeout meaningfully reduce re-analysis time without inflating idle memory beyond acceptable limits?
3. At what traffic threshold does remote execution become cost-effective compared to tuning local server idle behavior for low-traffic workloads?