$ man clay-wiki/credit-system

Clay credits are consumed when you use enrichment providers, AI columns (Claygent), and certain native integrations. Each provider costs a different number of credits per row. Simple enrichments (Apollo person search) cost 1-2 credits. Heavy enrichments (Claygent web research) cost 3-10 credits depending on the model and complexity. Formulas cost zero credits. HTTP columns cost 1 credit for the column execution plus whatever the external API charges. Credits are the unit of cost in Clay. Every architectural decision — waterfall depth, table structure, enrichment order — either saves or wastes credits. Understanding the credit system is understanding the economics of your pipeline.

PRO TIP

If the time spent avoiding credits exceeds the credit cost, use the credits. This is my core principle. I've watched people spend 3 hours trying to avoid a $5 enrichment run. That's not efficiency — that's false economy. Use credits to prove and test your workflow. Get the flow working. Validate the output. Confirm the pipeline produces qualified leads. Then optimize. Optimization means: replace native integrations with direct API calls where the API is cheaper. Replace AI columns with formulas where the transformation is deterministic. Replace waterfall providers with single-provider calls where coverage is adequate. But you can't optimize what you haven't built yet. Build first. Optimize second.

PATTERN

I used to run a 6-provider email waterfall (Apollo → Hunter → Clearbit → RocketReach → Prospeo → Dropcontact). Best case: 1-2 credits. Worst case: all 6 providers run — 8-12 credits per contact. Then I added MX-based routing and realized the waterfall logic made no sense. I was burning credits chasing marginal coverage gains on emails that bounced anyway once routing kicked in. My philosophy now: skip the waterfall entirely. Go single-provider — Prospeo or LeadMagic. Check MX records instead of stacking validation providers. Qualify persona before running the email lookup — if the title doesn't match a buyer tier, don't look for their email at all. Single-provider + MX routing gets the same deliverability at a fraction of the cost. The waterfall is a concept worth understanding, but I don't recommend using one.

PATTERN

Many enrichment providers offer both a Clay native integration (costs Clay credits) and a direct API (costs API credits billed separately by the provider). The math often favors the API at scale: Native Apollo in Clay: ~2 credits per enrichment. Apollo API via HTTP column: 1 Clay credit for the HTTP call + Apollo API pricing (often cheaper per call at volume). The break-even depends on your volume and your Clay plan. At low volume (<1,000 enrichments/month), native is simpler and the cost difference is negligible. At high volume (10,000+), the API route saves significantly. But the API route requires setup — HTTP column configuration, JSON parsing, error handling. That's the tradeoff: simplicity (native) vs. cost efficiency (API).

ANTI-PATTERN

The biggest credit drains I see: (1) Enriching company data on a contact table instead of an account table — 50x credit waste on large accounts. (2) Running email lookups on contacts who don't match any persona tier — you're paying to find emails for people you'll never contact. (3) Running Claygent on tasks a formula could handle — name merging, title normalization, domain extraction. (4) Re-enriching contacts that already have data — always add a condition: only enrich if the target column is empty. (5) Not deduplicating before enrichment — you're enriching the same company or contact multiple times. Fix the architecture and you fix the credit waste. Most credit problems are architecture problems.

PRO TIP

These Clay features cost zero credits and should be your first line of defense: Formulas — natural language transformations, merging, classifying, scoring bins. Lookup columns — pulling data from other tables without re-enriching. Filter conditions — preventing enrichment columns from running on rows that already have data or don't qualify. Sculptor — quick table queries and deduplication (low or zero credit). Manual column edits — sometimes a human scan is faster than an AI column for 50 rows. Maximize free features before spending credits. Every formula that replaces an AI column saves 2-10 credits per row across your entire table.