Caching
Drizz reuses how it resolved a step on a screen it has seen before. Cached steps run faster and cost less.
Drizz reuses how it resolved a step on a screen it has seen before, instead of resolving it again. Cached steps run in a fraction of the time and are the cheapest step category.
Platforms
Android · iOS
In the log
"Predicted Action drizzing fast ⚡"
Speed
A fraction of the time of an uncached step
Cost
Cached steps are the cheapest category; Vision AI the most expensive
Watch out
A UI change invalidates the cache for the screens it touched
Prerequisites
None. Caching is enabled per app by Drizz and requires no configuration in a test.
Behavior
Step resolves from cache
Logged as "Predicted Action drizzing fast ⚡", completes in a fraction of a second
Step does not resolve from cache
Logged with its normal step classification, completes in seconds
Cost, cached step
Cheapest step category
Cost, Vision AI step
Most expensive step category — see Billing & tokens
First run of a new test
No cache. Every step does full resolution
Second and later runs
A growing share of steps resolve from cache
After a UI change
The cache for the affected screens is invalidated. Those steps run uncached until it rebuilds over subsequent runs
Stale resolution after a UI change
A cached step can act on an element as it was on the previous version of the screen
Enabling
Per app, by Drizz. Steps that never resolve from cache after repeated runs indicate caching is not on for that package
Configuration in a test
None. Caching is not written into or enabled per test
If a cached step acts on stale UI
Re-run the test. The cache updates as the suite runs against the new UI.
Re-run once more.
If the step is still wrong on the third run, fix the description — see When a step fails.
Common mistakes
Benchmark a new suite on its first run
You measure the cold path
Estimate cost from the first run's usage
Cost drops once the suite is warm and steps resolve from cache
Raise a support ticket when the suite slows after a release
Expected. The UI changed and the cache is rebuilding
Rewrite descriptions to force a cache hit
Caching follows description stability. Write descriptions for clarity
Assume a stale cache when a step fails
Check the before-screenshot first. The description is the more frequent cause
Run the suite only before a release
Fewer runs, less of the suite cached
Next
Last updated: 6 August 2026
Last updated
Was this helpful?