How Do You Cap AI Token Spend in a Make Scenario?

How do you stop a Make scenario from burning through your AI budget?

Put the limits in the scenario itself. Filter records before they reach the AI step, trim the text you send, cap AI calls per day with a counter, and skip records that already have an AI result. Then alert yourself when the counter gets close to the limit, so overspend shows up in hours.

Make is a great place to add an AI step to a revenue workflow. Summarize a form submission, classify an inbound lead, draft a first reply, tag a support ticket. The scenario works on day one, everyone is happy, and then a webhook fires far more often than expected, or a field starts carrying whole email threads instead of one line.

That is when AI cost stops being a rounding error. The fix is not to avoid AI in automations. It is to design the scenario so that cost is bounded by the scenario's logic, not by luck.

How does Make charge for AI steps?

It depends on the connection. Make's help center says that with your own AI provider connection, such as OpenAI or Anthropic Claude, credits are based on operations and you pay the provider directly for tokens. With Make's AI Provider, you pay Make for credits based on both tokens and operations.

That distinction changes where you watch the bill. If you bring your own OpenAI or Anthropic key, Make shows you operations, but the token spend lands on your provider account. If you use Make's built-in provider, token use shows up as Make credits. Either way, the same thing drives the cost: how many times the AI step runs, and how much text goes in and comes out.

Make's documentation is direct about what increases token usage: more interactions, longer prompts, larger files, and longer responses. It also gives a rough rule of thumb, that 1 token equals around 4 characters of English text. I use that estimate when I sketch a budget before building, because it turns a vague worry into a number you can reason about.

Pricing and rate tables change, so always check Make's current credits page and your AI provider's pricing page before you set a budget.

Why do AI costs spike in automations in the first place?

Costs spike because automations multiply small mistakes. A trigger that fires on every update instead of every new record, a field that suddenly holds a long email thread, or a retry loop that reruns the AI step can each turn a cheap workflow into an expensive one within a day, with no human noticing.

The three causes I watch for are volume, size, and repetition. Volume is the trigger firing more often than you planned. Size is the input growing, such as a notes field that someone starts pasting full call transcripts into. Repetition is the same record being processed again and again, often because an update in one tool triggers the scenario that writes back to it.

That last one is the most dangerous, because it can loop. The AI step writes a summary to the CRM, the CRM update fires the trigger, and the scenario summarizes the record again. Every run looks valid on its own. Only the pattern is wrong.

I covered the same pattern for enrichment tools in my guide on capping Clay credit spend per lead. The logic carries over directly: decide what one record is worth, and design so no record can cost more than that.

How do you filter records before they reach the AI step?

Add a filter on the route into the AI module so only records that need AI judgment pass through. Check for the fields that matter, such as a real company domain or a minimum message length, and block test submissions, internal emails, and records that already carry an AI result. The cheapest token is the one you never send.

In practice, this filter does more work than any other control. For a lead classification scenario, I would let a record through only if it has an email on a business domain, a message long enough to classify, and an empty AI classification field. That last check alone stops the write-back loop described above.

It also helps to handle the easy cases without AI. If a form has a dropdown for company size, route on the dropdown. Save the model for the free text field where judgment is actually needed. Plenty of "AI lead scoring" scenarios are really a handful of rules plus one genuinely fuzzy question.

Put the filter as early as possible in the scenario. Every module that runs before the filter still costs operations, even if the record is dropped later.

How do you limit how much text you send to the model?

Trim inputs before the AI step. Cut long fields to a fixed number of characters, strip email signatures and quoted replies, and send only the fields the prompt actually uses. Then keep the response short by asking for a fixed format, such as one label or a two sentence summary, instead of open-ended text.

Text functions in Make can handle most trimming. Cutting a field to its first couple of thousand characters is usually plenty for classification, and using the 4 characters per token estimate, you can see roughly what that means in tokens before you ever run the scenario.

The output side matters just as much. A prompt that says "summarize this lead" invites a long answer. A prompt that says "return one of these four labels and nothing else" keeps responses tiny and makes the result easier to route on. If your AI module offers a setting for maximum response length, check Make's app documentation for that module and set it deliberately.

Finally, choose the model by the job. A short classification does not need the most capable model your provider offers. Test a smaller one first and upgrade only if quality is not good enough.

How do you set a daily cap on AI calls in Make?

Keep a simple counter that the scenario reads and updates on every AI call. Store today's date and a call count in a Make data store or a spreadsheet row, check it before the AI step, and route records to a holding queue once the count hits your limit. Reset the count when the date changes.

This is the control that turns "it might get expensive" into "it cannot cost more than X per day." The logic is short. Before the AI module, read the counter. If the stored date is not today, reset the count to zero. If the count is below your limit, run the AI step and add one. If it is at the limit, skip the AI step and send the record somewhere a human or a later run can pick it up.

The holding queue matters. A cap that silently drops records is a lead routing bug waiting to happen. I would rather have twenty leads waiting in an Airtable view tagged "AI cap reached" than twenty leads that simply vanished.

Pick the limit from your real volume. Look at how many records the trigger produced over the last few weeks, add a margin, and set the cap there. The cap should almost never fire. When it does, it is telling you something changed upstream.

How do you get alerted before the bill arrives?

Send yourself an alert when the counter crosses a threshold below the cap, such as 80 percent of the daily limit, and another when the cap is hit. Post it to Slack or email with the count and the scenario name, so someone can check whether volume grew for a good reason or something is looping.

Alerts are what make the cap useful. Without them, the cap protects your budget but hides the problem. With them, you find the broken trigger the same morning.

I also like a weekly summary for any scenario with an AI step: total runs, total AI calls, records held by the cap, and the largest input processed. It takes a few minutes to build and it makes trends visible long before they become invoices. If a scenario runs on a schedule, pair this with a heartbeat check, so you also know when it stops running entirely.

Before any of this goes live, test it with fake records, including a deliberately huge one and a deliberate duplicate. My walkthrough on testing a Make scenario with fake leads shows how I set that up.

When should you move the AI step out of Make?

Consider moving it when one scenario is doing heavy, repeated AI work at high volume, such as processing every record in a large table or generating long content. At that point, a dedicated pipeline with batching, caching, and clearer cost tracking may serve you better, while Make keeps doing the routing and integration work it is good at.

Make shines at connecting tools and moving data between them. It is not the only place AI work can live. For content pipelines, it is often cleaner to run the model work in a separate process and let the automation tool handle triggers and delivery. I explained that approach in my piece on budgeting tokens for a Claude Code content pipeline.

For most revenue workflows, though, the AI step stays small: classify, summarize, extract. Those belong in Make, with the guardrails above. Moving them out adds a system to maintain, and that has its own cost.

What should you do next?

Open your Make scenarios that contain an AI module and check four things: is there a filter before it, are inputs trimmed, is there a daily cap with a holding queue, and does anyone get alerted when volume jumps? Fix the filter first, because it usually removes the most waste for the least effort.

Then write down the budget. One line is enough: this scenario may run the AI step up to N times a day, with inputs no longer than M characters. Once that line exists, every control above is just a way of enforcing it.

If you have AI steps running inside Make, Zapier, or n8n and you are not sure what they cost or what happens when they break, reach out. I build and maintain automations behind revenue teams, and putting cost guardrails in place is part of every build. Let's chat.