Know what your Gradle build cache stores before you size it

Knowing what Gradle puts in the cache tells you what you are paying disk for and which tasks stored nothing in our build. At FosterStack we prove everything, so here is how we proved it to ourselves: one real build, every entry counted, and the tasks that stored nothing.

The short answer

• Each compileJava task stored one entry.
• The compiled build scripts stored entries too, which is why there are more entries than compile tasks. On a Gradle home that had already compiled them, they were not stored again.
• The jar, classes, assemble and build tasks stored nothing in our run.
• The 13 entries from a four-module build took about 36 KB.

What we ran

The four-module build from Gradle build cache for a monorepo: core, util, api and app, each with 12 small Java classes and a Kotlin build file. Our first run used a project folder that still held build output from an earlier check; we repeated it, with the same 13 entries, from a clean copy and got the same results. We started a new, empty server and ran gradle build --console=plain --no-daemon -i once, with the local cache off and a new, empty Gradle home. The -i flag makes Gradle print a line each time it stores something. The build ended with BUILD SUCCESSFUL. The project has no tests, so there are no test entries here; for those, see Gradle test task FROM-CACHE.

The server's status page then said: 13 entries, 36,054 bytes. When we repeated the run, the entry count was the same and the size varied by a few dozen bytes (36,054 to 36,103 across our runs).

What the 13 entries were

These are the lines Gradle printed:

Stored cache entry for task ':core:compileJava' with cache key ...
Stored cache entry for Kotlin DSL script compilation (Project/TopLevel/stage1) with cache key ...
Stored cache entry for Kotlin DSL script compilation (Project/TopLevel/stage2) with cache key ...

What was not stored

These tasks ran and stored nothing: classes, jar, assemble and build for each of the four modules. In our other runs the jar tasks never printed FROM-CACHE either. In our builds you will see them run on every fresh checkout.

See it for your own build

Start from an empty cache, run your build once with -i, and count. We ran exactly this command, with the output saved, and it printed the same 13 entries:

gradle build -i | grep "Stored cache entry"

If your Gradle home has already compiled your build scripts, you will not see the script entries again: in a second run with the same Gradle home against a new empty server, only the 4 compileJava entries were stored, and the server held 4 entries and 11,425 bytes. The server's status page (/statusz) shows the entry count and the size in bytes. To see how it changes as you build, see monitor the cache with Prometheus and Grafana. To pick a size limit, see how big a server does a build cache need and how the size limit works.

If an entry you expect is missing

Look at why the hit rate is low and enable or disable the Gradle build cache. A task that stored nothing in your build, such as the jar tasks in ours, could not come from the cache.

Run on Gradle 9.8.0 with FosterStack Cache 0.2.1, macOS (arm64), Java 27.