Why Your Maya Rig Scrubs at 4 FPS — and What Cached Playback Actually Fixes

You open a hero character shot, drag the time slider, and Maya stutters along at a fraction of real time. The rig is not broken; it is just expensive. Every time change forces Maya to re-run the dependency graph — constraints, set-driven keys, blendShapes, skinCluster — from scratch, even when nothing changed since the last frame you looked at.

The useful takeaway: Cached Playback, introduced around Maya 2019, stores the results of that evaluation so repeated scrubs reuse cached values instead of recomputing them. On heavy rigs this is often the difference between unusable playback and smooth review. This post explains what it caches, how to read the timeline's red/blue contract, and where the trade-offs bite.

What Cached Playback actually caches

Classic Maya evaluation is stateless per time change: move to frame 48 and the graph evaluates as if it has never seen frame 48 before. Cached Playback adds a memory layer on top of the Evaluation Manager (Maya's modern evaluation architecture, which also enables parallel evaluation across CPU cores). The first pass through a frame range populates the cache; subsequent visits to those frames read stored values.

Two consequences follow. First, the first scrub after enabling it is not faster — that pass does the work and fills the cache. Second, the feature only helps with repeated viewing of the same range, which happens to be exactly what animators and reviewers do all day.

The red/blue timeline contract

Once enabled, the time slider shows a status band. Blue regions are cached and will play back from memory. Red regions are invalidated or unsupported and fall back to normal evaluation. This color contract is how you decide whether to trust what you are seeing.

Invalidation is granular. If you move a key on frame 60, only the affected downstream region turns red; the rest of the shot stays blue. The cache then repopulates lazily as you scrub over the red area again. Small tweaks do not force a full re-cache of the shot, which is what makes the feature practical during iteration rather than only for final review.

A worked example you can reproduce

Take a rigged shot — say 24 fps over roughly 120 frames with a skinned character. The procedure:

1. Check evaluation mode. In a Script Editor Python tab, run import maya.cmds as cmds; cmds.evaluationManager(query=True, mode=True). You want parallel in the result; Cached Playback is built on that architecture and parallel mode is the recommended pairing for interactive work.
2. Measure baseline. Set playback to "Play every frame" is not what you want here — use real-time playback and note the achieved fps from the playback speed readout (enable it via Display > Heads Up Display > Frame Rate). Scrub the full range and note responsiveness.
3. Enable Cached Playback in the Animation preferences (exact location varies by release — check your version's docs), then scrub the full range once to warm the cache. Watch the timeline turn blue.
4. Measure again. Same range, same readout. On a dense rig the difference is usually obvious without a stopwatch; the blue band is your evidence that frames are being served from cache.

You have not changed scene state, so there is nothing to roll back — toggling the preference off returns you to normal evaluation.

Trade-offs and limitations

Memory. Cached values scale with frame range and scene complexity. On long shots or dense rigs, RAM use grows accordingly. The preferences let you cap this — limiting the cached range or caching only animated values — which matters on 500-frame shots or memory-constrained workstations.

Unsupported nodes. Custom plugin nodes or unusual graph constructs can produce red regions that never cache. Benchmark with your actual production rig, not a primitive test sphere, or you will overestimate coverage.

Not a simulation cache. Time-dependent simulations — nCloth, Bifrost, dynamics — are not served by Cached Playback. Those still need explicit simulation caches (nCache, Alembic, or USD caches), which are a separate mechanism solving a different problem. Conflating the two leads to bad expectations: enabling Cached Playback will not make your cloth sim scrub faster.

Version drift. Preference names, toggle locations, and sub-options have shifted across releases since 2019. An early GPU-override option for cached playback existed, behaved driver-dependently, and was later removed — do not assume it exists in your build. Verify against your version's release notes before scripting around specific option names.

What to do Monday morning

Enable Cached Playback and parallel evaluation on one real production shot, warm the cache with a single scrub, and watch the timeline. If it goes mostly blue and playback smooths out, keep it on and set a sensible memory limit. If you see large red regions, identify the unsupported nodes before blaming the feature — the color band is telling you exactly where the cache cannot help.