Ultralytics 8.4.160 fixes missed annotation cache updates, preserves optimizer state during OOM retries

Ultralytics released 8.4.160 on September 22, fixing an issue where training continued to use stale caches after data annotations changed, and adjusting the recovery process that automatically reduces batch sizes after an out-of-memory (OOM) error. The official GitHub release and PyPI package are both available. These changes affect the consistency of training data and state. [Release notes](https://github.com/ultralytics/ultralytics/releases/tag/v8.4.160), [PyPI release record](https://pypi.org/project/ultralytics/8.4.160/)

The cache issue has a straightforward trigger: change a class in a YOLO label file from 0 to 1 while keeping the file length unchanged. Earlier versions generated the cache key from file paths and the sum of file sizes, so an edited file could still match the existing cache. The contributor reproduced this with a single-image dataset: the second load still returned class 0. Only after applying the patch did the loader rescan the data and return class 1. [Patch details](https://github.com/ultralytics/ultralytics/pull/26283)

The updated shared function, `get_hash`, incorporates each file’s path, individual size, and nanosecond-resolution modification time before computing SHA-256. It checks file metadata rather than reading the full contents to compute a content hash. The official documentation now reflects this implementation. The change affects data caches for detection, depth, semantic segmentation, and other tasks that use the shared function. Existing caches will trigger a one-time rescan after the upgrade. [Function documentation](https://docs.ultralytics.com/reference/data/utils/), [Scope of the change](https://github.com/ultralytics/ultralytics/pull/26283)

Another fix in the same release addresses OOM retries during the first training epoch. Previously, rebuilding the data loader also rebuilt the optimizer, potentially discarding accumulated momentum, adaptive statistics, and even state restored from a checkpoint. The optimizer and learning rate scheduler are now created only if the optimizer does not already exist. After reducing the batch size, the process reuses the existing objects and recalculates the relevant weight decay coefficients. [Training state fix](https://github.com/ultralytics/ultralytics/pull/26284)

Both fixes still have clear limits. If a data synchronization tool preserves both file size and modification time, the cache can still miss content changes, requiring manual removal of the affected cache. OOM recovery still reruns the epoch; preserving the optimizer does not mean training can resume precisely at the failed batch. The contributor reported local validation using deliberately triggered OOM errors, but a maintainer later removed the dedicated regression test from the PR. [Cache limitations](https://github.com/ultralytics/ultralytics/pull/26283), [Retry behavior and validation record](https://github.com/ultralytics/ultralytics/pull/26284)

From an engineering perspective, teams that repeatedly revise annotations or resume training should use a known class change to confirm that the cache is rebuilt, and spot-check momentum and learning rates before and after an OOM error. Schedules should also account for the initial rescan so that the data-loading overhead after the upgrade is not mistaken for a regression in training performance. Determining which training artifacts may already have been affected by stale caches still requires checking data versions against run logs. Upgrading alone will not repair previously trained models.