If Gradle is taking up space on C:, inspect its user cache before deleting anything. Gradle normally removes old cache entries itself; when you need space now, you can stop its processes and remove a chosen cache folder, provided you can download dependencies again. Your project source files are in a different location.
Find which Gradle folder is large
Open File Explorer and enter %USERPROFILE%\.gradle in the address bar. This is the default Gradle User Home on Windows 10 and 11. If you set the GRADLE_USER_HOME environment variable, open that location instead. In File Explorer, right-click caches and select Properties to see its size; repeat for wrapper and daemon before deciding what to remove.
The caches folder mixes several kinds of reusable data. modules-2 holds downloaded dependencies and their metadata. Folders named build-cache-* hold reusable task outputs when the local build cache is enabled. Numbered folders such as caches\<version> contain data tied to a Gradle version, while other shared cache names and their numbers can change between Gradle releases. Do not assume every numbered folder is obsolete.
wrapper\dists contains Gradle distributions downloaded by project wrappers. daemon contains daemon state and logs. These are different from the dependency cache, so a large wrapper folder will not shrink when you clear modules-2.
Also check the project directory you are building. Its .gradle folder stores project-specific state, and build contains generated outputs. Deleting the global cache will not remove those directories. Conversely, the Gradle clean task usually removes build outputs for the project; it is not a general command to empty %USERPROFILE%\.gradle\caches.
Let Gradle do its routine cleanup first
Gradle already cleans unused entries from its caches and old wrapper distributions periodically. The exact retention depends on the Gradle version and any cache settings in your environment. If the drive is not urgently full, finish a normal build and let its scheduled cleanup run instead of repeatedly removing everything.
This matters because cached dependencies avoid another trip to a remote repository, and generated outputs can save build work. Deleting them does not remove your source code, but the next build may take longer and use the network. If you build while offline, or depend on a private repository you can no longer reach, keep the downloaded dependencies until access is restored.
You can read the current layout and cleanup behavior in the Gradle directory guide. Check it when you see an unfamiliar folder name rather than relying on a fixed list from an older Gradle release.
Stop Gradle before removing a cache
Finish the current build, close your IDE and its Gradle integration, then open Command Prompt in the affected project's folder. If that project includes the Gradle wrapper, run:
gradlew.bat --stop
If you use an installed Gradle instead of a project wrapper, run gradle --stop. Gradle says this stops daemons started by the same Gradle version as the command, so another project using a different version may still have a daemon. Close those projects too. If Windows reports that a cache file is in use, leave it alone and check for a remaining Gradle or IDE process rather than forcing the deletion.
Stopping a daemon does not delete build data. A later build can start a new one. If a build was interrupted, rerun that build after cleanup and inspect its normal error output before removing anything else.
Clear the local build cache when outputs are the problem
In File Explorer, open %USERPROFILE%\.gradle\caches and look for a folder named build-cache-1 or another build-cache-* folder. Check its Properties so you know whether it is actually the space you need. With builds and daemons stopped, select that folder and press Delete. Use ordinary Delete so Windows sends it to the Recycle Bin; do not use Shift+Delete.
This removes reusable task outputs, not your project source. The next build may regenerate outputs and take longer. If the build needs something you removed and you have not emptied the Recycle Bin, restore that folder from there while Gradle is stopped, then retry. The cache may grow again as you continue building; clearing it is a one-time space recovery step, not a permanent size limit.
If the folder is absent or small, deleting it will make little difference. Move on to the actual large location instead of clearing unrelated caches by habit.
Clear downloaded dependencies only when you can fetch them again
For a large dependency cache, open %USERPROFILE%\.gradle\caches and inspect modules-2. Before deleting it, confirm that your network and every required repository, including private ones, are available. Then stop builds and daemons as above, select modules-2 in File Explorer, and press Delete. Keep it in the Recycle Bin until a normal project build succeeds. Do not delete the entire .gradle user home: it can also contain configuration, initialization scripts, downloaded JDKs, and wrapper distributions.
The immediate risk is a failed or slower next build while dependencies are downloaded again. An offline build cannot resolve a required artifact that is no longer cached. If the next build fails because a repository is unavailable, stop Gradle and restore modules-2 from the Recycle Bin, if it is still there. If you permanently removed it, reconnect to the required repositories and rerun the build. A cached artifact is not a substitute for keeping access to your project's dependencies.
If your goal is to check for updated dependencies rather than free storage, use gradlew.bat --refresh-dependencies from the project folder. Gradle rechecks dependency metadata and artifacts; this flag does not mean “delete every cached file.” The Gradle dependency caching guide explains the distinction and the effect of --offline.
Keep project cleanup separate
For a project you can rebuild, gradlew.bat clean from its root is the usual first step for generated build outputs. It runs the project's clean task, so review any project-specific behavior before using it. This does not target the shared user cache. If the project has its own large .gradle directory, close Gradle first and inspect it separately; its state will be recreated as needed, but your next build may lose incremental work.
If you use several developer tools, measure them independently. An npm cache or pip cache will not change when you clean Gradle. A drive scan can show which directory is actually growing before you trade a working cache for a small amount of space.
Reviewing Gradle caches with AiCleanDisk Pro
AiCleanDisk Pro includes Gradle among its developer cache cleanup items, which are behind “Show all items.” You can inspect the item's risk level and confirm before cleaning; files go to the Recycle Bin by default where the cleanup method permits it. Scanning the system drive and auto clean outside the AI category are free. Moving folders and AI analysis require a license, currently sold as a one-time purchase. Start with the manual folder check above if you only need to clear a specific Gradle cache; the home page describes the app's broader scan and cleanup options.