Last updated: May 2026
Table of contents
- The 30-second answer
- What a credit (or operation) actually is
- The August 2025 rename, and why it matters
- AI modules use credits differently — and that’s where bills jump fastest
- Why your bill is higher than expected
- How to cut your credit usage
- How to find your worst offenders in Make
- Before and after: a real optimization example
- Quick reference: what counts as 1 credit
- Make plan tiers and credit allocations
- Frequently asked questions
- Sources
You opened your Make.com bill this month and it was higher than you expected. Maybe a lot higher. You logged into the dashboard to figure out why, and the dashboard told you that you’d used a certain number of credits. But every tutorial you’ve ever read, every YouTube video, every forum post, every screenshot you’ve seen, talks about operations. So which is it? Did you get billed for operations or credits? Are they the same thing? Did Make change something? Did you miss an email?
You got billed for credits. Credits replaced operations as Make’s billing unit in August 2025. For most non-AI workflows the math hasn’t changed — only the word has. The rest of this article walks through what counts as a credit, why this month’s number is higher than you guessed, and what to fix.
Quick aside if you’re scenario-shopping: if you want to estimate a scenario’s credit cost before you build it, the free Builder’s Companion Kit includes an Operations Cost Estimator that does exactly that.
The 30-second answer
In August 2025, Make renamed its billing unit from operations to credits. For standard, non-AI modules, 1 operation equals 1 credit — the practical math is unchanged. For some AI and advanced features, credits are consumed dynamically based on factors like token count, file size, page count, or processing time, so the simple “one module run equals one credit” rule doesn’t always hold.
You can use either word in conversation and people will know what you mean. Make’s dashboard, billing screens, and current docs all say “credits” now. Most third-party tutorials, the Make community forum, Reddit threads, and the back-catalog of YouTube videos still say “operations.” That mismatch is the source of half the confusion.
The reason your bill is higher than expected almost never comes down to Make changing prices. It almost always comes down to one of six scenario-design patterns that quietly multiply how many credits each run consumes — plus, if you’ve started using AI modules recently, those have their own dynamic billing rules. The rest of this article walks through both.
What a credit (or operation) actually is
An operation is one module run inside one scenario execution. For standard non-AI modules, that’s also one credit. If your scenario has five modules and runs once, you used five operations/credits.
The textbook example: a scenario that watches a Google Sheets row, formats the data, and sends a Slack message. That’s three modules. Each time it runs, you use three credits. Run it a hundred times in a month, you used three hundred credits.
The reality is messier, because Make’s modules don’t all behave the same way. Some count differently. Some don’t count at all. Some appear to use one credit but use many. And the meaningful difference between a scenario that costs you 1,000 credits a month and a scenario that costs you 100,000 isn’t usually the number of modules — it’s how those modules interact when data starts flowing through them.
A few rules that hold for standard non-AI modules:
- A module that runs consumes a credit. A module that’s skipped (because a filter upstream stopped the bundle) doesn’t.
- The trigger module counts. Every time a scenario starts, the trigger has already used one credit before any downstream module has done anything.
- Routers and filters themselves are free. They don’t consume credits. They affect what comes next (and what next-modules consume), but the routers and filters themselves cost zero.
- Sub-scenario control modules (Call a subscenario, Start a scenario, Return output, Customize run name) are listed in Make’s current credit docs as not consuming credits themselves. The sub-scenario’s own modules still consume credits when they run, so the cost risk is calling a heavy sub-scenario many times, not the call itself.
- Many Tools modules consume credits even though they don’t call an external API (Set Multiple Variables, for example, uses 1 credit). Some are free. The safest move is to check the module’s run bubble after a test execution rather than assuming all internal/tools modules are free.
- A scenario that fails partway through bills you for the credits it consumed before failing. You don’t get a refund for the ones that didn’t run.
That last point is the one that bites people who are still learning. Errors don’t pause the meter.
The August 2025 rename, and why it matters
Make changed the word “operations” to “credits” because it wanted a single billing currency that could cover both the old per-module count and the newer AI-related usage that doesn’t map cleanly onto modules. An AI Agent doing a long chain of internal reasoning isn’t running a discrete module the way a Google Sheets Watch Row is, but Make still needs to charge for it. “Credits” is the more general unit.
For ordinary non-AI scenarios, the practical math is still 1 operation = 1 credit. The bigger reason the rename matters is downstream of that math, in how you find help.
First, when you go searching for help — Googling “why are my make.com operations so high” or “how do I reduce make operations” — every helpful article you find is from before August 2025 and uses the old terminology. The advice still works. The screenshots are slightly out of date. The dashboard you’re looking at right now says something different than the article. That’s just a vocabulary lag, not a content problem.
Second, if you’re new to Make and you started after August 2025, you’re being onboarded into the “credits” world. You’ll read a tutorial that says “this scenario uses 4 operations per run” and wonder why your dashboard says you have credits, not operations. For standard non-AI workflows, you can mentally substitute one for the other and you’re fine.
In the rest of this article, I’ll use credits (the current term) but mention “operations” alongside it where the older usage is still dominant in search and tutorials.
AI modules use credits differently — and that’s where bills jump fastest
Most of this article applies to traditional scenarios where 1 module run = 1 credit. AI modules don’t play by that rule.
AI modules (LLM calls, vision modules, OCR, AI Agents, transcription, generation) consume credits dynamically, based on factors that vary by module type:
- Token count for text-completion modules — a 200-word prompt costs less than a 2,000-word prompt
- Page count for PDF processing modules
- File size or image resolution for vision and OCR modules
- Processing time for some AI operations
- Token count of the response (output is often billed too)
A single AI module call can consume anywhere from 1 credit to many tens or hundreds of credits depending on what you ask it to do. There’s no simple flat rate.
If your monthly credit usage spiked and you’ve started using AI modules recently, the AI modules are very likely the cause — even if you only run them a few times a day. A single image-generation call processing high-resolution outputs can consume more credits than a dozen “normal” module runs.
The fix is the same as for any cost discipline on Make: watch the actual credit consumption on the module’s run bubble after a test execution, and compare it to what you expected. For AI modules in production, monitor a few real runs and project forward before assuming light usage.
Why your bill is higher than expected
Six patterns account for almost every “wait, that can’t be right” Make bill on non-AI workflows. Many operators are running several of them simultaneously without realizing it.
1. Iterators multiply everything downstream
This is the single biggest source of surprise on a Make bill, and it’s invisible until you’ve been burned by it once.
An Iterator takes a single bundle that contains an array and splits it into many bundles, each carrying one item from that array. If you watch a Google Sheets row and the row contains a list of 50 product IDs, your Iterator splits that into 50 separate bundles. Every module after the Iterator now runs fifty times instead of once.
A scenario that looked like 4 modules — watch, iterate, transform, write — actually costs you 1 + 1 + (50 × 2) = 102 credits per run, not 4. Run that scenario hourly and you’re at ~73,000 credits a month from one workflow.
The fix isn’t to stop using Iterators. They’re correct for the job. The fix is to put a filter between the Iterator and the modules after it, so only the bundles you actually need to process continue. Filters drop bundles before they consume credits on downstream modules. A filter that drops 40 of the 50 bundles cuts your downstream cost by 80%.
2. Routers run every matching path, not just one
A Router with three paths and “or” conditions feels like a switch statement: data goes down one path. It doesn’t quite work that way. Make runs every path whose filter condition matches, and every module on every path that runs costs credits.
If your Router has a fallback path with three modules on it, and your data sometimes matches the first path and the fallback (because your fallback filter is loose), every match double-bills. Worse, if your fallback has no filter at all, it always runs, even when one of the other paths also ran.
The fix: every Router path should have a filter, and the filters should be mutually exclusive. The fallback path’s filter should be the negation of the others (or set as the explicit Fallback route in Router options), not a blanket “always run.”
The router module itself is free. The cost comes from the downstream modules on each path that ends up running.
3. Error handlers and retries quietly re-bill the scenario
When a module errors and your error handler is set to retry, every retry consumes a fresh credit. A module configured to retry three times can cost you four credits (the original attempt plus three retries) for what looks like one module run. If that module is downstream of an Iterator processing 50 items, and the API is having a bad afternoon, you can burn through thousands of credits in an hour from one scenario.
The fix: retry sparingly, and route persistent failures to a different handler (Data Store write, Slack notification, or an audit route) rather than retrying indefinitely. Set retry counts based on whether the failure is likely transient (network blip — retry) or permanent (validation error — don’t retry, log and move on).
4. Polling triggers run on a clock, even when nothing changes
If a scenario uses a polling trigger — Watch Rows, Search, Get Records — set to run every minute, that trigger fires every minute, whether or not there’s new data to act on. Even when nothing has changed, the trigger module still consumes a credit. That’s 60 × 24 × 30 = 43,200 credits per month from one trigger, before any of the work even starts.
If the trigger does find new data and the rest of the scenario runs, you add the downstream credits on top.
The fix: webhooks instead of polling whenever the source supports them. A webhook scenario sits idle and consumes zero credits until something actually triggers it. The same Google Sheets workflow that costs you 43,200 credits/month as a polling scenario can cost you 200 credits/month as a webhook scenario, because it only fires when there’s actually new data.
When you can’t use a webhook — some apps don’t expose them — increase the polling interval. Going from 1-minute polling to 15-minute polling cuts trigger cost by 15× with almost no real-world impact for most use cases.
5. Search modules return more than you need
Many Make modules let you set a maximum number of records to return. The defaults are sometimes high — “return up to 100” or “return up to 1,000” — and operators leave them at the default while developing, then forget.
The Search module itself may only consume 1 credit even when it returns many bundles. The cost explosion happens downstream: every returned bundle moves through whatever modules sit after it. If you set “max records: 100” and the search returns 100, you’ve got 100 bundles entering whatever’s downstream — and every one of those downstream modules runs 100 times. If you only ever need the most recent 5, set the limit to 5. That’s a 95% reduction on every downstream module.
6. Sub-scenarios get called more than you think
The Call a Scenario module itself doesn’t consume a credit, but the sub-scenario it calls has its own credit cost. If your parent scenario iterates and calls a heavy sub-scenario for each item, you’re multiplying by the sub-scenario’s full credit cost. The cost-trap isn’t the call module — it’s running an expensive workflow many times.
The pattern is fine when the sub-scenario’s logic genuinely needs to be reusable across multiple parent scenarios. It’s wasteful when the sub-scenario could just be inlined into the parent — the only thing you save by separating them is editor clutter, and you pay for that clutter in credits.
How to cut your credit usage
If you want a single rule of thumb for cost discipline on Make: process less data, fewer times, with fewer modules. Almost every optimization is a flavor of that rule.
In rough priority order, here’s where to start an audit:
- Switch any polling trigger to a webhook if the source supports webhooks. This is usually the single biggest win — sometimes 90% or more on the affected scenarios.
- Add filters before Iterators, not after. A filter after an Iterator stops downstream work for one bundle at a time. A filter before drops the entire array if the parent record doesn’t qualify.
- Lower search and trigger result limits to the actual number you need. Defaults are almost always too high.
- Audit Router paths for overlapping filter conditions and remove path duplications.
- Tune retry logic — don’t retry permanent errors, set sensible max-attempts, route exhausted retries to a logged-failure handler instead of looping.
- Inline sub-scenarios that are only called from one parent unless there’s a clear reusability case.
- Cache external data in Data Stores when the same lookup happens repeatedly. A Data Store read is one credit; an HTTP call to refetch the same data is one credit plus the latency.
- Increase polling intervals on any trigger that doesn’t need sub-minute responsiveness. Most don’t.
- Audit AI module usage separately — the dynamic credit logic on AI modules can mask significant cost in a small number of runs.
Many operators can cut their monthly credit cost dramatically — often 50–80% on inefficient polling-heavy builds — without changing what the scenarios actually do.
How to find your worst offenders in Make
If you’ve never done a credit audit before, here’s the actual workflow. Takes about 30 minutes for most accounts.
- Open Make → Scenarios. Sort by activity if the option is available; otherwise scan for the scenarios you know fire most often (anything with a 1-minute polling trigger is almost certainly in your top 3).
- Click into your top scenario → History. This shows recent runs with the credits consumed per run visible on each entry.
- Inspect a recent successful run. Each module’s bubble shows the operations/credits consumed by that specific module on that specific run.
- Look for these signals on the module bubbles, in order of how much they typically cost:
- High credit numbers on a single module (often AI modules — see the AI section above)
- Iterators with large bundle counts following
- Search modules returning more results than the downstream logic needs
- Trigger modules with very frequent run cadences in the history
- Sub-scenario calls happening inside iterators
- Calculate the monthly cost of the top suspect: credits per run × runs per day × 30. Compare to your monthly bill. If one scenario accounts for more than 20% of your monthly credits, that’s the first one to fix.
- Repeat for your top 3-5 scenarios. In most Make accounts, fewer than 5 scenarios account for 80%+ of monthly credit usage. Fix those and the bill drops dramatically.
The Production Readiness Checklist in the free Builder’s Companion Kit includes this audit as a one-page checklist you can run quarterly.
Before and after: a real optimization example
A real scenario: watching a Google Sheets sheet for new rows and processing each new row through 3 downstream modules (an HTTP enrichment call, a CRM write, a Slack notification). Let’s say the sheet gets 50 new rows per month spread randomly across the month.
Before optimization — built with a 1-minute polling trigger, no filter:
- Trigger runs: 60 × 24 × 30 = 43,200 trigger credits/month
- New rows found and processed: 50 × 3 downstream modules = 150 downstream credits/month
- Total: ~43,350 credits/month
After optimization — switched to a webhook-style trigger using Apps Script or another event-push workaround instead of polling Watch Rows:
- Trigger runs: only when a new row exists, so 50 trigger credits/month
- Downstream credits: same 150 (the same actual work still happens)
- Total: ~200 credits/month
Reduction: 99.5%. Same business outcome. The webhook scenario captures new rows just as quickly — actually faster, because it fires the moment a row is added rather than waiting up to 60 seconds for the next poll. The only thing that changed was the trigger architecture.
This is the order of magnitude most polling-to-webhook conversions deliver. It’s why the very first item on the cut-your-credit-usage list is “switch polling to webhooks.”
Want the Operations Cost Estimator? The free Builder’s Companion Kit includes a spreadsheet that lets you plug in your scenario design and get the monthly credit cost before you build it — plus reference cards for what every standard module actually costs. Get the kit →
Quick reference: what counts as 1 credit
| Element | Credits consumed |
|---|---|
| Standard non-AI module run | 1 |
| Trigger module (when scenario starts) | 1 |
| Iterator module itself | 1 |
| Each bundle out of an Iterator, per downstream module that runs on it | 1 per module per bundle |
| Router module itself | 0 |
| Filters | 0 |
| Each path of a Router that runs, per module on that path | 1 per module |
| HTTP module call | 1 per call regardless of payload size |
| Sleep module | 1 |
| Many Tools modules (Set Multiple Variables, etc.) | 1 each (check the run bubble per module — a few are free) |
| Retry attempts | The failed module/action can consume credits again on each rerun; the error-handler module itself is free |
| Sub-scenario control modules (Call a subscenario, Start a scenario, Return output, Customize run name) | 0 (but the sub-scenario’s own modules still consume credits) |
| Scenario that fails partway through | Pays for the credits consumed before failure |
| Scenario that’s skipped because trigger had no data | 1 (the trigger still runs) |
| AI modules (LLM, vision, OCR, AI Agents, generation) | Dynamic — varies by tokens, file size, processing time |
The full operations math for every module type — including the less-obvious ones like Aggregators, ListIterators, and AI Agent invocations — is covered in Part III of The Missing Manual for Make. More about the book →
Make plan tiers and credit allocations
The plan tier you’re on caps your monthly credits and a few other limits. The current tiers, with the stable mechanics that don’t churn often:
| Plan | Monthly credits | Active scenarios | Polling interval minimum |
|---|---|---|---|
| Free | 1,000 | 2 | 15 minutes |
| Core | 10,000+ (scales by plan size) | Unlimited | 1 minute |
| Pro | 10,000+ (higher caps, more features) | Unlimited | 1 minute |
| Teams | Per-seat pricing, shared org pool | Unlimited | 1 minute |
| Enterprise | Custom | Custom | 1 minute |
I’m deliberately not quoting dollar prices in this article because Make’s pricing has changed several times in the past 18 months and any number I print here will be wrong soon. Check make.com/pricing for current numbers.
The one tier-related insight worth knowing: the jump from Free to Core isn’t really about the credit count — it’s about the polling interval. Free’s 15-minute minimum makes most real-world scenarios impractical because anything time-sensitive can’t poll fast enough. Core drops the minimum to 1 minute and removes the 2-scenario cap, which is what unlocks Make as a serious tool. If you’re hitting either of those limits regularly, you’re on the wrong plan.
If you don’t have a Make account yet and want to start on Free to test scenarios before committing, sign up here. If you’ve outgrown Free’s 1,000 credits or the 15-minute polling floor, the same link lets you start on a paid plan.
The pattern that runs through all of this
Almost everything in this article comes back to one idea: the credit count isn’t a function of how much work your business does, it’s a function of how your scenarios are designed. Two operators with identical real workloads — same number of records processed, same APIs touched, same outcomes — can have wildly different Make bills because one of them used webhooks where the other used polling, or filtered before the Iterator where the other filtered after.
That’s the good news. It means cutting your bill isn’t about doing less; it’s about designing better. The hour you spend auditing your top three highest-volume scenarios this week will pay for itself every month for as long as those scenarios run.
If you want a starting point that’s faster than guessing: the Builder’s Companion Kit is a free download that includes the Operations Cost Estimator (model a scenario’s monthly credits before you build it), reference cards for every standard module’s credit cost, and six production-ready blueprint imports you can adapt.
Grab the free Builder’s Companion Kit. Includes the Operations Cost Estimator, module reference cards, the Production Readiness Checklist, the Scenario Planning Worksheet, and six importable starter blueprints. One download, no upsell.
Frequently asked questions
Are Make operations and credits the same thing? For most non-AI workflows, yes — 1 operation = 1 credit. They’re closely related but not identical: operations describes the activities/modules that run, while credits is the billing currency you consume. Some AI and advanced Make features use dynamic credit logic that doesn’t map cleanly to one-module-equals-one-credit.
Does a Make trigger use credits if there’s no new data? Yes. The trigger module runs every polling interval whether or not it finds new data. Each check consumes 1 credit even when nothing is processed. This is the single biggest source of “unexpected” Make bills on polling-based scenarios. Webhook triggers don’t have this problem — they sit idle and consume zero credits until something actually fires them.
Do filters use Make credits? No. Filters themselves are free. Their value is that they can stop bundles from reaching downstream modules — and those downstream modules are what would consume credits. A well-placed filter saves more credits than it costs (which is zero).
Do routers use Make credits? The router module itself is free. The modules on each route that runs do consume credits. Routes whose filter conditions match all run in parallel — so if multiple routes match the same bundle, all of their downstream modules consume credits. Set tight, mutually-exclusive filters on each route to avoid running every path on every bundle.
Do Make AI modules use more credits than regular modules? Often, yes — sometimes dramatically more. AI modules use dynamic credit logic based on tokens, file size, page count, processing time, and similar factors. A single AI module call can range from 1 credit to many tens or hundreds. If your Make bill jumped after you added AI modules, the AI modules are almost certainly the cause. Monitor actual credit consumption on each AI module’s run bubble after a test execution and project forward before assuming light usage.
How do I reduce Make credit usage? The highest-leverage moves, in order: switch polling triggers to webhooks where possible (often 90%+ savings on the affected scenarios); filter before iterators (not after); lower search result caps to the actual number needed; audit router filter overlap; set sensible retry limits and route persistent failures to a logger instead of retrying indefinitely; inline single-use sub-scenarios. Most operators can cut their monthly credits dramatically — often 50-80% on inefficient polling-heavy builds — on a first serious audit.
Does a scenario that fails partway through cost me credits? Yes. Make bills you for every credit consumed up to the point the scenario errored. The modules that didn’t run aren’t billed, but you don’t get a refund for the ones that did. This is why aggressive retry settings can be expensive — every retry attempt is a fresh credit.
Sources
Verified live as of May 29, 2026:
- Make Help Center — Credits: help.make.com/credits
- Make Help Center — How features use credits: help.make.com/how-features-use-credits
- Make Help Center — Operations: help.make.com/operations
- Make Pricing: make.com/en/pricing
Brian Kasday writes The Operator’s Library for MMS Vegas — production-grade reference manuals for the tools small operators actually run. The Missing Manual for Make is the long-form companion to articles like this one.