Why Clay Auto-Update Burned 20,000 Credits, and Every Other Setting That Wastes Your Balance

How the Burn Actually Happens

Clay bills per enrichment execution, and executions are triggered by more than you expect: new rows, yes, but with auto-update enabled, also column edits, formula changes that cascade, and re-imports that look like new data. A 5,000-row table with four enrichment columns is 20,000 executions per full pass, so one accidental full re-trigger equals the horror story. None of this is Clay being predatory, it is a powerful tool defaulting to freshness over frugality, and the documentation itself tells you to disable auto-update while building. The operators who get burned skipped the manual; the fix is settings plus sequencing.

The Cost-Ordered Table

WASTEFUL (discovery order)        COST-ORDERED
import 5,000 rows                 import 5,000 rows
enrich email     5,000 credits    dedupe (free)      -800
enrich phone     5,000            lookup own DB      -600 free hits
filter ICP       (too late)       free ICP filters   -1,400
dedupe           (too late)       → 2,200 survive
                                  enrich email       2,200 credits
                                  enrich phone       2,200
≈10,000+ credits                  ≈4,400 credits
+ auto-update re-runs...          auto-update: OFF

• •Sample runs are sacred: 10-20 rows end-to-end, eyeball every column, then scale. Errors found at row 15 cost 15 rows; found at row 5,000 they cost the table.
• •Fix errors surgically: filter to the affected slice and re-run only it, never the column. "Re-run column" is the single most expensive button in the product.
• •Your own history is a free provider: an HTTP lookup against your CRM or master database before the paid waterfall recovers every email you have ever bought once.
• •Verification goes last and only on rows that survived everything, feeding your normal waterfall rather than a premium in-Clay check on doomed rows.