Where does Burst cache compiled jobs?

In Library/BurstCache/ inside the project folder and a global cache in your OS temp directory. Stale entries can survive package updates because Burst keys by IL hash, which may not reflect dependent package changes.

How do I force a clean Burst recompile?

Delete Library/BurstCache/ from the project and the global cache (e.g., %LOCALAPPDATA%\Unity\BurstCache\ on Windows). In Jobs → Burst → Open Burst Inspector, you can also right-click a job and choose Force Compile.

Will deleting Library cause data loss?

No — Library is regenerated from Assets and Packages on next editor open. It’s safe to delete (and recommended for many cache-related issues). First open after deletion takes longer as Unity rebuilds the import cache.

Fix: Unity Burst AOT Cache Stale After Package Update

Quick answer: Delete Library/BurstCache/ and the OS-level Burst cache. Reopen the project. Burst recompiles from scratch using the new package versions.

After updating Unity.Mathematics from 1.2.6 to 1.3.0, Burst jobs in the project produce slightly different results than expected. The math library’s implementations changed; Burst is using the old compiled output. The IL hash key didn’t change because the user code didn’t change.

Burst Caching Layers

Burst stores compiled native code in two places:

Library/BurstCache/ — per-project. Keyed by IL hash.
OS temp cache — shared across projects on the same machine. e.g., %LOCALAPPDATA%\Unity\BurstCache\ on Windows, ~/Library/Caches/com.unity.burst/ on macOS.

The IL hash sometimes misses changes that came from package updates — Burst sees the calling code is unchanged and reuses the old binary.

Clean Recompile

Close Unity.
Delete Library/BurstCache/ from the project folder.
Delete the OS-level cache (Windows: %LOCALAPPDATA%\Unity\BurstCache).
Reopen Unity. First entry into Play mode triggers fresh compilation; allow extra time.

Force Recompile per Job

For a single job:

Jobs menu → Burst → Open Burst Inspector.
Find the job.
Right-click → Force Compile.

Quicker than wiping the whole cache when only one job is suspect.

Verify the Burst Build

In Burst Inspector you can inspect the assembly Burst generated for each job. If your code path includes math library calls, the assembly should reference the new versions’ symbols. A sanity check: a quick visual diff of the assembly before and after the package update.

For Shipping Builds

For final builds, set Burst’s build option Optimize For = Performance and Disable Safety Checks. Player builds use a different cache (Library/BurstCache/Player); also wipe this before final builds after major package changes.

Verifying

Run the affected job after clean recompile. Output should match the new package’s expected behavior. Add a unit test that pins one known input/output to detect future cache-staleness regressions.

“Burst’s cache key isn’t perfect across package updates. Wipe the cache after major math/collections updates.”

Add a CI step that wipes Library/BurstCache before release builds — eliminates “built with stale Burst” surprises in QA.