## TL;DR

Clear the stale bytecode cache and force a clean reimport so autoreload sees the new source.
Python is loading the old .pyc from __pycache__ instead of your edited .py, so autoreload 2 keeps serving the stale module.
Delete __pycache__, run %autoreload 2 again, and explicitly reimport the module.

```text
%autoreload 2 not picking up the edited module: stale bytecode cached
```

## Use this when

- Edits to a module have no effect even with %autoreload 2 active
- Restarting the kernel picks up the change but autoreload does not
- The .py timestamp is newer than the loaded behavior suggests

## Not for this skill when

- Autoreload crashes the interpreter - that is item 129
- The module fails to import at all - that is an import problem
- Changes apply but old objects keep old behavior - that is a stale-reference problem

## Steps

1. Confirm the staleness: check the module's __file__ and compare the __pycache__ timestamp against your edit time.
   Expected: the cached bytecode predates your edit.

2. Delete the stale cache: remove the __pycache__ directory next to the module (and any .pyc files).
   Expected: the directory is gone.

3. Re-enable autoreload cleanly: %autoreload 2 (after %load_ext autoreload if needed).
   Expected: the extension loads without errors.

4. Force the reimport: import importlib, then importlib.reload on the module, or delete it from sys.modules and import fresh.
   Expected: the new code is active.

5. Verify with a behavior probe: call a function whose output changed in your edit.
   Expected: the new behavior, proving the fresh module loaded.

## Tool compatibility

IPython 8.x, Python 3.9+

## Variant phrasings

### %autoreload 2 not picking up changes

Same fix applies: see the Steps section above.

### autoreload stale bytecode cached

Same fix applies: see the Steps section above.

### ipython autoreload not reloading edited module

Same fix applies: see the Steps section above.

## Why it happens

CPython caches compiled bytecode in __pycache__ keyed by source mtime, and autoreload 2 re-executes the module only when it detects a change. Clock skew, network filesystems, and editors that preserve mtimes can all make the cache look current when the source changed, so the old bytecode loads again. Autoreload trusts the import system, and the import system trusts the cache; deleting the cache breaks the chain and forces a genuine recompile from your edited source.

## Edge cases / pitfalls

- importlib.reload does not update existing objects created from the old module; recreate instances after reload.
- Some editors save via atomic rename, which usually fixes mtimes - check yours if staleness recurs.
- %autoreload 2 skips modules imported with C extensions; those always need a kernel restart.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_rVFWyenuBNVIcMoRCP7oBQ