Skip to main content

What It Does

Every Workspace ships with a two-layer cache so repeated work against remote backends (S3, GDrive, Slack, …) hits local state instead of the network:
  • Index cache. Listings and metadata. The first directory walk hits the API; subsequent ones serve from the index until the TTL expires.
  • File cache. Object bytes. The first read streams from origin; later pipelines read from cache.

Stores

Each layer is a pluggable store with two built-ins:
  • RAM (default): in-process, zero setup, 512 MB file cache and 10-minute index TTL. Best for single-process apps and notebooks.
  • Redis: shared across workers, processes, and machines. Best for serverless, multi-replica services, or for cache state that survives restarts.

Eviction & Limits

The two layers are bounded differently: Raising the file limit keeps more bytes warm at the cost of memory; lengthening the index TTL serves listings longer between API walks at the cost of staleness.

Miss/Hit Lifecycle

Relationship To Snapshots

The file cache is exactly what a snapshot serializes: ws.snapshot() writes the cached bytes for every touched path into the tar, and Workspace.load() restores them into the file cache so a replayed run reads from local state. The index cache is not snapshotted; it rebuilds lazily after load.