Does Colab preserve /content files after an idle-triggered runtime recycle?

Direct answer

No. Google Colab does not preserve files written to /content after an idle-triggered runtime recycle. When the free-tier VM is disconnected for inactivity and you reconnect, Colab provisions a fresh virtual machine with an empty /content directory. Google Drive data remains intact in the cloud, but the local mount point is gone.

Confirmed facts vs. inferred behavior

Confirmed: the hosted VM is ephemeral. After an idle disconnect, a reconnect receives a new backend instance. Local filesystem state—including /content—is cleared. Google Drive files survive because they live in cloud storage, not on the VM.

Inferred but not published: the exact idle timeout. Community observation suggests roughly 90 minutes for free tier and longer for paid tiers, but Google does not commit to a fixed number, and capacity, region, or account tier can shift the actual threshold.

Drive remount and VM reuse detection

Colab does not automatically remount Google Drive on reconnect. The mount point /content/drive disappears with the VM, so you must re-execute the mount command in the new session:

from google.colab import drive
drive.mount('/content/drive')

There is no supported API to detect whether a runtime reused the previous VM or provisioned a new one. A practical heuristic is to write a unique marker file on startup and check for it after reconnect:

import os, time
marker = '/content/session_marker.txt'
if os.path.exists(marker):
    print('Possible VM reuse or timeout not reached')
else:
    with open(marker, 'w') as f:
        f.write(str(time.time()))
    print('New VM or fresh /content')

Comparing hostname or /proc/self/cgroup across sessions is another informal check, but neither is guaranteed to be stable or documented.

Steps for this case

1. Treat /content as scratch space only. Move anything that must survive into /content/drive/MyDrive, GitHub, or cloud storage before the idle window closes.
2. Re-run drive.mount() at the top of every session; do not assume the mount persists.
3. If you need to verify persistence behavior empirically, write a marker file, note the hostname, leave the tab idle past the expected timeout, reconnect, and check whether the marker and hostname changed.

GPU assignment is also best-effort on reconnect; the new VM may have a different accelerator or none at all.