How Do You Budget Tokens for a Lead Enrichment Workflow?

How much should a lead enrichment workflow spend on model tokens?

Set the budget per enriched lead, not per month. Work out what one record costs in input and output tokens, multiply by expected volume, and add a margin for retries. Then cap it in code. A per-record number tells you instantly whether a workflow is healthy, while a monthly bill only tells you after the damage.

Enrichment is where model costs sneak up on GTM teams. A workflow that summarizes a company website, classifies industry, and drafts a first line for outbound looks cheap in testing. Then someone points it at a list of forty thousand accounts, a retry loop misfires, and the invoice is the first alert anyone sees.

This is the budgeting method I use when I build enrichment automations, whether they run in Clay, n8n, Make, or a plain Python script calling the Claude API.

What is a token budget in an enrichment workflow?

A token budget is the maximum number of input and output tokens you allow per record, per step, and per run. It turns a vague worry about cost into a hard limit. Every model call in the workflow gets a ceiling, and the workflow refuses or flags records that would go over it.

Tokens are the units a model reads and writes. Providers price input tokens, the text you send, separately from output tokens, the text the model returns. Output usually costs more, so a step that writes long answers can cost far more than a step that reads a long page and returns one word.

A good budget has three layers. A per-call limit on output length. A per-record limit across all calls for that lead. And a per-run limit, so a list of fifty thousand rows cannot quietly turn into a bill nobody approved.

Why do enrichment costs get out of control?

Costs usually blow up for four reasons: sending far more text than the task needs, asking for long outputs, retrying failures without a limit, and running enrichment on records that should never have been enriched. None of these are model problems. They are workflow design problems.

A common waste in enrichment design is the full page dump. A step scrapes an entire homepage, with navigation, footer, and cookie text, and sends all of it to the model to answer one question about industry. A cleaned excerpt of the relevant section would answer the same question with a fraction of the input.

The second is enriching the wrong records. If your list includes companies outside your ideal customer profile, every token spent on them is wasted. Filter first with cheap rules, like employee count or country, and only send survivors to the model. I go deeper on ordering cheap and expensive steps in enrichment waterfall order, cost versus coverage.

How do you calculate the cost of one enriched record?

Add up each model step for one record: input tokens times the input price, plus output tokens times the output price, using your provider's current published rates. Sum the steps, then add a retry margin. That total is your cost per enriched lead, the number every other decision builds on.

Here is a worked example with real published prices and made-up token counts. Anthropic's Claude Haiku 5.5 page lists $0.10 per million input tokens and $0.50 per million output tokens for prompts up to 100,000 tokens. Suppose one step sends 2,000 input tokens and gets 300 back. That is $0.0002 for input and $0.00015 for output, or $0.00035 per record.

Run that step across 10,000 records and it costs about $3.50 before retries. Add a second step of the same size and you are near $7. The numbers are tiny per record, which is exactly why teams stop watching them, and exactly why a runaway loop can multiply them without anyone noticing.

Always pull prices from the provider's own pricing page on the day you build the budget. Prices change, and a budget built on an old number is a budget that lies.

Which model should each enrichment step use?

Match the model to the step. Classification, extraction, and short summaries rarely need a frontier model. A small, fast model handles them well and costs far less. Save larger models for steps that need judgment, like writing a personalized opening line or reasoning across several sources.

Anthropic positions Claude Haiku 5.5 for this kind of work. Its launch page describes it as designed for high-volume, cost-sensitive tasks and lists summaries and classification requests among its use cases. The same page says it costs around 75% less to run, on average, than Claude Haiku 4.5.

A price drop like that is a good moment to rerun your budget, not to stop thinking about it. Cheaper tokens make it tempting to send more text and ask for longer answers. My rule is to bank the savings first, then decide on purpose whether any step deserves a bigger budget.

Before you switch models, read the provider's migration notes. Anthropic's release notes for October 7, 2026 warn that code written for Claude Haiku 4.5 can break on Claude Haiku 5.5, for example when it sends sampling parameters like temperature. Test the new model on a small batch first.

How does prompt caching change the budget?

Prompt caching lowers cost when many calls share the same opening text, such as a long system prompt with your ICP definition and labeling rules. The shared part is read from cache at a much lower price. For enrichment, where thousands of calls reuse one set of instructions, caching can be a large share of the savings.

The Haiku 5.5 page lists cache reads at $0.01 per million tokens for prompts up to 100,000 tokens, a tenth of the regular input price. Anthropic's release notes also say that on October 7, 2026 it lowered prompt cache reads on Claude Sonnet 5.5 from $0.20 to $0.10 per million tokens.

To benefit, structure prompts so the stable part comes first and the record-specific part comes last. Put the instructions, label definitions, and examples at the top, then the company data at the end. If you shuffle that order on every call, the cache cannot help you.

How do you enforce the budget inside the workflow?

Enforce it in code, not in a spreadsheet. Set a maximum output length on every call, truncate inputs to a fixed size, cap retries at a small number, and keep a running count of tokens per run. When the count hits the limit, the workflow stops and alerts a human instead of continuing.

Most model APIs return token usage in each response. Log those numbers next to the record ID. That log becomes your cost report, your debugging tool, and your early warning system all at once. If one record suddenly uses ten times the normal tokens, you want to see it the same day.

In tools like n8n or Make, I add a simple counter in a data store or an Airtable table that each run updates. A filter step checks the counter before every model call. It is not elegant, but it means a broken loop stops at the budget instead of at the end of the list.

Should an agent or a fixed workflow run enrichment?

For budget control, a fixed workflow wins. A fixed sequence of steps has a predictable cost per record. An agent decides how many calls to make and how much to read, so its cost per record varies, sometimes a lot. Agents earn their place on messy research tasks, not on routine enrichment.

If you do use an agent, give it a hard ceiling on tool calls and tokens per record, and log every call it makes. Treat its budget as a range, not a single number, and watch the top of that range closely. The tradeoffs are laid out more fully in whether an AI agent or a fixed workflow should run your enrichment.

My preference is a hybrid. A fixed workflow handles the common case cheaply, and only records that fail a confidence check go to a more expensive agent or to a person. That keeps the expensive path small by design.

How often should you review the token budget?

Review it monthly, and also whenever something changes: a new model, a new price, a new prompt, or a much larger list. Compare actual cost per record with the planned number. A gap in either direction tells you something, because cheaper than planned can mean a step silently stopped running.

I keep the review short. One sheet shows cost per record by step, total runs, and the most expensive records of the month. The expensive records are where the lessons are, usually a giant page, a retry loop, or a record that should have been filtered out.

The same habit works for any model pipeline, not just enrichment. I use a similar structure for content work, described in a token budget for a Claude Code content pipeline.

What should you do next?

Pick your busiest enrichment workflow and calculate its cost per record today, using current prices from the provider's own page. Then add three guards: a maximum output length, a retry cap, and a per-run token limit that stops the workflow and alerts you. Those three cover most runaway bills.

Token budgeting is not about being cheap. It is about knowing what each enriched lead costs, so you can compare it with what that lead is worth. When the cost per lead is visible, you can spend more on the steps that improve pipeline and less on the steps that only fill columns.

If you want help setting up budgets and cost logging for your enrichment stack, reach out through pravinkumar.co. I build websites and the automations behind them for lead generation, and making those automations predictable is a big part of the job.