AI Coding Tools Filling Up Local Disk? A Guide to Managing Four Types of Cache

First conclusion: A full disk is usually not because the tool is “too large,” but because four types of local assets have accumulated

If your AI coding assistant fills the system drive after a few weeks of use, the cause can usually be traced to four types of manageable local assets: model and index caches, extension/plugin directories, inference and context data, and diagnostic logs and temporary files. They share one common trait: they must exist, but they cannot exist indefinitely. They need lifecycle management, not simple deletion.

Another important point is that whether the disk gets filled depends on where the tool writes session records and project files. When the system drive is running low on space, you may see issues such as being unable to create new sessions, being unable to save project files, slower completions, or even process crashes. If the tool’s working directory is already on a data drive, the impact is much smaller.

I. Comparison of the four main sources of disk usage

Disk usage source	Typical content	Common growth reason	Can it be cleaned?	Risk level
Model and index caches	Model weights, vector indexes, codebase embeddings	Stored by version/hash; old versions are not automatically evicted	Yes, but keep only the most recently used versions	Medium: deleting the wrong files can cause re-downloads and index rebuilds
Extension/plugin directories	Plugin dependencies, runtimes, resource bundles, leftover old versions	Accumulates as the number of plugins and versions grows	Prefer uninstalling or downgrading plugins rather than manually deleting directories	Medium-high: manual deletion may corrupt plugins and prevent them from starting
Inference and context data	Conversation history, context snapshots, completion statistics, session replay data	Strongly related to session length and codebase size; grows quickly with frequent use	Can be cleaned after archiving	High: may contain business code and sensitive information
Logs and temporary files	Diagnostic logs, crash dumps, temporary caches, stack files	Lack of rotation policies	Safe to clean; prioritize these	Low: but losing them removes historical troubleshooting evidence

Actual paths vary significantly across tools and operating systems. For example, Windows commonly stores data under %LOCALAPPDATA% and %APPDATA%, while macOS commonly uses ~/Library/Application Support and ~/Library/Caches. The JSON field names in this article (cacheDir, logDir, workspaceStorage) and the YAML rules are only structural examples, not universal standards. Always refer to the official documentation, settings UI, or official environment variables of the tool you are using.

II. Locate the issue first: quantify before taking action (read the risk warning first)

Diagnosis and remediation are two different actions with different risks. Commands such as du, df, and find should only be used for viewing and statistics. Before performing any deletion, move, or cleanup, complete the following four steps:

1. Close the AI IDE / coding assistant processes to avoid runtime caches being locked or corrupted.
2. Confirm the paths: know which directories belong to the tool and distinguish tool caches from your own project source.
3. Back up necessary configurations: save copies of settings files, API keys, custom index parameters, and similar items.
4. Do not delete runtime caches that are currently in use, such as the current session directory or active index files.

Linux / macOS locating approach:

# View only: subdirectory sizes in the current directory, sorted by size
du -sh ./* 2>/dev/null | sort -rh | head -20
# View only: overall disk usage
df -h
# View only: hidden directories (AI tool data is often stored in dot-prefixed directories)
du -sh ~/.[!.]* 2>/dev/null | sort -rh | head -20

Windows PowerShell example (also view-only):

# View remaining space on each drive
Get-PSDrive -PSProvider FileSystem | Select-Object Name, Used, Free
# Measure larger subdirectories under AppData
Get-ChildItem "$env:LOCALAPPDATA" -Directory |
  ForEach-Object {
    $size = (Get-ChildItem $_.FullName -Recurse -File -ErrorAction SilentlyContinue |
             Measure-Object -Property Length -Sum).Sum
    [PSCustomObject]@{ Path = $_.FullName; MB = [math]::Round($size / 1MB, 1) }
  } | Sort-Object MB -Descending | Select-Object -First 20

If the tool supports custom data directories, you can move regenerable data to a separate volume (example structure):

{
  "cacheDir": "D:/ai-tools/cache",
  "logDir": "D:/ai-tools/logs",
  "workspaceStorage": "D:/ai-tools/workspace"
}

III. Governance strategies: from reactive cleanup to proactive control

1. Directory planning and storage separation

Core principle: keep only the operating system and core programs on the system drive; put regenerable caches and logs on a separate volume. This way, even if caches grow, they do not block normal writes on the system drive. Backup and cleanup also gain a unified entry point. During migration, first close the processes, copy the complete directory, verify content integrity, then change the configuration, and finally delete data from the old location.

2. Cache governance and lifecycle management

• Set a retention policy for model caches and keep only the most recently used versions.
• Export historical sessions, archive them to cold storage, and then clean up local copies.
• Turn repeated manual cleanup tasks into executable scripts.

When cleaning old logs, use a two-step process: preview first, then delete.

# Step 1: preview matching results and confirm paths and file scope (no deletion)
find /path/to/logs -type f -mtime +30 -print
# Step 2: execute deletion after confirmation
find /path/to/logs -type f -mtime +30 -delete

Make sure to replace /path/to/logs with the real log directory. Do not run deletion against the tool root directory or project directories. Also, do not clean runtime caches that are currently held by running processes.

3. Cloud offloading and hot/cold tiering

Move large, infrequently accessed data, such as historical conversations and old models, to cloud storage, and keep only hot data locally. A common approach is to use object storage for archives and a logging service for centralized collection of runtime logs. However, there are two important considerations:

First, archived conversations and code may contain business logic, secrets, or personal information. Before uploading, confirm data classification and compliance requirements, enable encryption in transit and at rest, and configure least-privilege access policies.

Second, the cost model is not limited to storage fees. It also includes request counts, restore traffic fees, and retention periods. Cold archives are suitable for data that is rarely accessed. Historical sessions that need frequent review are more economical if kept locally or in standard storage.

4. Make monitoring and alerting routine

Proactive control is better than after-the-fact remediation. It is recommended to configure tiered thresholds with clear actions:

# Example: tiered disk usage rules
rules:
  - name: disk_usage_warn
    condition: disk_used_percent > 80
    action: notify_channel("dev-alert")      # Log and remind; no automatic cleanup
  - name: disk_usage_high
    condition: disk_used_percent > 90
    action: notify_channel("dev-alert") + daily_digest
  - name: disk_usage_critical
    condition: disk_used_percent > 95
    action: notify_channel("dev-alert", "oncall") + cleanup_hint

Additional recommendations: adjust thresholds based on machine specifications, such as lowering them to 75/85/92 for small-capacity system drives; to avoid false alerts, add conditions such as “sustained for N minutes” or “two consecutive samples”; do not let the monitoring system automatically perform deletions. Automatic cleanup should be limited to clear log directories and should retain the most recent N days of data.

IV. Frequently asked questions

• Disk usage is still high after cleanup? This is often because indexes are being rebuilt, old-version caches still exist, or the main usage is in another path. Rerun directory statistics, sort by size, and confirm the real source.
• Old caches cannot be deleted and the system says the file is in use? This means the process is still running. Close the tool and its background services, then retry. On Linux/macOS, you can use lsof +D directory to find the process using the file. On Windows, you can use Resource Monitor to locate the handle.
• The tool reports missing data after migration? Check whether the configuration field names are recognized by the tool, or switch to official environment variables. Also confirm read/write permissions and available disk space on the new path.
• Cloud archiving increases costs? Prioritize reducing archive frequency, shortening retention periods, keeping frequently reviewed data locally, and cleaning redundant snapshots with no access records.

V. Deployment checklist

1. Separate: decouple data directories from the system drive and manage them on a separate volume.
2. Quantify: first locate the major sources of usage through statistics, then start cleanup.
3. Tier: keep hot data local and move cold data to the cloud, balancing performance, compliance, and cost.
4. Safety: preview, back up, and close processes before deletion; never operate on source code directories.
5. Routine: use tiered disk usage alerts to drive daily maintenance; do not perform automatic deletion.

Teams and enterprise environments can document directory standards, retention policies, alert thresholds, and compliant archival requirements into a unified operations standard, enabling consistent management across multiple endpoints and members. Understanding why these tools consume space allows you to use AI coding capabilities well while keeping them under control, so AI coding is not held back by disk bottlenecks.