Cost-saving playbook

If your credit usage is climbing faster than your test count, you're probably leaving free wins on the table. This page is a checklist of concrete settings — every recommendation traces back to a specific toggle or mode documented elsewhere in the manual.

The two high-leverage levers

1. Leave Position Memory on for stable taps

Default is on; if you've turned it off, ask why. The toggle's own description spells out the right rule: "Only enable for elements with stable, fixed positions (e.g., navigation buttons)." Most taps in a typical test qualify.

See Position Memory.

2. Leave Assert Memory and List Bounds Memory on

Both default on. The downside of leaving them on for a non-stable target is essentially nil — a memory miss costs the same as having had memory off.

See Assert Memory & List Bounds Memory.

Audit checklist for existing tests

Run through any test that's costing more than you'd expect:

• Are all stable Tap steps' Position Memory toggles on?

• Are all Visual Assert steps' Assert Memory toggles on (unless the screen genuinely changes between runs)?

• Are all Scroll steps' List Bounds Memory toggles on?

• Is Run Count set higher than necessary on any Run Test step?

• Is self-healing set to Full Test when Per Step would do?

What about per-test cost analytics?

Per-test cost is available in both the Mavster macOS app and the web app's project analytics view. Use it to identify the highest-cost tests first — focusing the playbook on the top quartile of spend usually returns most of the savings.