Make vs Zapier Pricing 2026: Where the Meter Flips

Make vs Zapier comes down to one number neither vendor puts on its pricing page: how many billable units your workflow spends per delivered outcome. At published July 2026 prices a Make credit costs $0.0009 and a Zapier task costs $0.039987, so Make is roughly 44 times cheaper per unit — and the only common workflow shape that reverses that is a low-yield polling trigger.

Our position is that the headline prices are the least useful thing on either page. Zapier bills a task only when an action succeeds; Make bills a credit for every module run, including the trigger check that finds nothing. Those two rules, not the plan prices, decide which invoice is smaller. Troy Tessalone, a Zapier Orchestrator and Solution Partner, put it plainly in a follow-up comment on his Zapier Community post comparing tasks with operations: "Both apps can be cheaper depending on the use cases and configurations." The post itself, from January 2023, carries a worked table of task and operation counts at four polling intervals, and three years later most comparison articles still quote a per-plan price and stop.

The short answer: Make is cheaper for almost every workflow shape, and the exception is precise — a scenario whose trigger performs more than about 43 idle checks per billable action, which in practice means a one-minute-polled scenario delivering fewer than roughly 1,000 billable actions a month.

Last updated: July 31, 2026.

One run, two meters. Zapier bills three successful actions; Make bills the trigger check as well.

What Make and Zapier actually bill you for

The two platforms meter different events, and the difference is documented on both sides. Zapier bills successful actions only. Make bills module runs, including checks that return nothing. Every Make vs Zapier cost argument is downstream of those two sentences, so it is worth reading each vendor's own wording before touching a spreadsheet.

Zapier's help centre article on task usage, updated 21 July 2026, is unusually blunt: "A task is any successful action that runs in Zapier. Only successful actions count toward your task usage." The same page lists what does not count — "All trigger steps", "Any Filter or Paths step", "All action steps that error or halt", and "All steps that do not run, either because of a previous filter or path condition, or because the Zap errored" (Zapier). Zapier's blog restates the trigger rule in plainer language: polling triggers "can check for new data as often as every minute, but those checks aren't tasks", and "Filters and Paths don't eat into your task usage" (Zapier, published December 2025 and updated June 2026).

Make defines its unit around the module rather than the outcome. Make's operations documentation says "an operation is a single module run to process data or check for new data" — the second half of that sentence is the whole argument. Make's guide to how features use credits then publishes per-module-type rates, and one line settles the comparison: trigger modules "use 1 credit per run, regardless of whether they return data", and "even when a trigger finds no new data, it still uses 1 credit for checking". Search modules "use 1 credit per run, even when they return multiple bundles". Action modules use "1 credit per input bundle processed". Routers, filters, error handler modules, scenario modules and Make functions are listed under "modules with no credit cost".

Put the two rate cards side by side and the asymmetry is narrow but decisive.

Read down the two columns and the pattern is not the one the comparison usually assumes, that Make charges for everything. Filters are free on both. Routing is free on both. Built-in utility steps are free on both. The genuine differences are exactly three: the trigger check, the failed attempt, and the search that finds nothing. Everything else is symmetrical, and the largest of the three by a wide margin is the trigger check — because a trigger runs on a clock whether or not your business has anything for it to do.

Make vs Zapier at a glance

Prices below were read from each vendor's pricing page on 31 July 2026. Both vendors reprice; treat the date as part of the number, and re-read the pages before either figure enters a business case.

A single run makes the arithmetic concrete. Take a five-step automation — trigger, filter, three successful writes. Zapier bills the three writes and nothing else: 3 tasks, or $0.1200 at the entry rate. Make bills the trigger as well: 4 credits, or $0.0036 at the entry rate. Make spends a third more units and still costs about 33 times less for the same run.

Two rows in that table do more work than the rest. The unit-price row is the reason Make wins most comparisons: one entry-plan Zapier task costs $0.039987, and $0.039987 buys 44 entry-plan Make credits. The trigger row is the reason the answer is not always Make. Checking an API costs nothing on Zapier at any plan tier, however often the plan lets you do it; on Make, checking every minute costs 43,200 credits a month.

The published price ladders, and the rungs Make does not publish

Any honest Make vs Zapier pricing comparison stops here for a moment. Zapier publishes its whole ladder. Make publishes one rung. That difference matters for anyone modelling a bill at a volume higher than an entry plan, and it is the single biggest gap in this comparison.

Zapier's pricing page carries a task-tier selector, and each rung has a published price. These are the monthly-billed Professional rungs, with the derived unit cost:

Annual prices come from the same selector: the 750-task Professional rung is billed at $239.88 a year, which is $19.99 a month, and the 2,000,000-task rung is $40,668 a year, which is $3,389 a month. The Team plan runs the same ladder at a premium — $253.50 a month against Professional's $193.50 at the identical 10,000-task tier.

The important structural fact is the shape: Zapier's per-task cost falls by roughly 15.7 times between its cheapest and its largest self-serve rung. A comparison that quotes only the entry rung overstates Zapier's disadvantage at scale by more than an order of magnitude.

Make's side of the same table cannot be filled in. Make's pricing page shows a credit selector running from 10,000 up through 300,000, 1 million and 8 million, but the price displayed on the page is the 10,000-credit price for each plan: $9 for Core, $16 for Pro, $29 for Teams, quoted for Enterprise. Higher rungs require the account or a conversation with sales. The same page states that credits expire at the end of the term, monthly or annual, and that extra credits are sold in bundles of 1,000 or 10,000 at a fixed price set by your subscription.

The one overflow rate Make does publish is a percentage. Make's plans and pricing adjustment notice, carrying an effective date of 6 November 2025, records that "additional credits now cost 25% more than credits included in your plan", for both automatic and manual purchases, and that the Core plan "now includes up to 300,000 credits per month" while Pro "now includes up to 8 million credits per month". Applied to the Core rate, an extra credit costs $0.001125. That is the only Make rate above the entry rung that can be derived from published material, so every model below that needs one uses it, and says so.

This is also the freshness trap in this topic. Make renamed and redefined its unit in 2025: Make's help centre announcement records the transition from operations to credits with balances converted one for one. Any comparison article that still talks only about "operations", or quotes a Make entry price above $9, is describing a system that no longer exists. Our own analysis of Make.com pricing and the failure path covers that repricing and the error-handling meter in full, and this article deliberately does not repeat it.

Costing model one: the linear webhook workflow

This section is a costing model, not a measurement. Nobody on our side has metered these workflows on a live account of either vendor; every figure is derived from the published rate cards and prices quoted above, and the assumptions are named so you can substitute your own.

Assumptions. One workflow. An instant webhook trigger, so no polling. Three action steps writing to three different applications. One filter, which passes on every run. No search modules, no iteration, no failures. 2,000 runs a month. Monthly billing on both platforms.

Unit count per run. Zapier bills the three successful actions and nothing else: the trigger is free, the filter is free. That is 3 tasks. Make bills the trigger module run plus three action runs, and the filter is free: 4 credits.

Make costs 45 cents per 100 runs against Zapier's $9.68 per 100 runs on this shape — a 21.5-fold difference on monthly billing. Put the Zapier plan on annual billing at $129 a month and the gap against Make's $9 narrows to 14.3-fold. Make advertises 15% or more off for annual billing but publishes no annual per-plan price, so the true annual-against-annual gap is wider than 14.3 and cannot be stated exactly from public information. Note where the gap comes from. Make spends 33% more units per run than Zapier does, because it bills the trigger and Zapier does not. It still wins by more than 20 times, because the unit itself is so much cheaper. That is the general case, and it holds for any workflow with an instant trigger.

The second thing worth noticing is the rung effect. Zapier's 6,000 tasks do not fit the 5,000-task rung, so the model buys the 10,000-task rung and wastes 40% of it. Make's 8,000 credits fit inside the 10,000-credit Core tier with room to spare. Both platforms sell capacity in steps, and both punish a forecast that lands just above a step.

The Idle-to-Action Ratio, and where it flips

Here is the rule this article exists to establish. Call it the Idle-to-Action Ratio: the number of unbilled-on-Zapier trigger checks a scenario performs for every billable action it produces. It is the only variable in ordinary workflow design that can reverse the cost verdict, and you can compute it before you build anything.

The derivation is short. Let U be the billable actions a workflow produces in a month — the same number on both platforms, since a successful write is a task on Zapier and a credit on Make. Let P be the trigger checks the same workflow performs in that month. Let Pz be the price of a Zapier task and Pm the price of a Make credit. Then:

• Zapier's bill is Pz × U, because checks and filters are free.
• Make's bill is Pm × (P + U), because every check is a module run.

Make is cheaper whenever Pm(P + U) < Pz × U, which rearranges to P / U < (Pz / Pm) − 1. At entry-plan prices — $0.039987 a task against $0.0009 a credit — that threshold is 43.43. So Make is cheaper for the same work unless the scenario burns more than about 43 idle trigger checks per billable action.

Now put a clock on it. A scenario polling every minute performs 43,200 checks in a 30-day month; every five minutes, 8,640; every fifteen minutes, 2,880; hourly, 720. Divide each by 43.43 and you get the volume of billable actions above which Make is cheaper again:

The crossover on a one-minute-polled scenario at published entry prices: Zapier's flat entry plan wins to the left of about 1,000 billable actions a month, Make's cheaper unit wins to the right.

The threshold moves with the Zapier rung, because Zapier's unit price falls with volume while Make's published unit price does not move at all. At the 10,000-task Professional rung the ratio is 21.5, so the break-even ratio drops to 20.5 and the one-minute-poll break-even rises to about 2,107 billable actions. At the 100,000-task rung it rises to about 6,042. Every one of those figures holds Make at its Core rate, which is the only rate Make publishes; if Make's higher rungs are cheaper per credit, and they almost certainly are, the true break-even sits lower than these numbers. Treat them as the ceiling of the flip zone, not its centre.

Costing model two: the low-yield polled scenario

The ratio is abstract until you cost a real shape, so here is the flip demonstrated with plan prices rather than unit prices. Again: a model, with named assumptions, not a measurement.

Assumptions. One scenario watching an API endpoint that offers no webhook. Polling interval one minute, so 43,200 checks a month. Of those checks, 300 return a record worth acting on. Each productive run performs two action steps, so 600 billable actions a month. No failures, no retries, no searches. Monthly billing. Zapier on the smallest sufficient Professional rung; Make on Core with overflow credits at the published 25% premium.

Zapier is cheaper here by $17.03 a month, and it is cheaper for one reason only: it does not charge for looking. That is the entire flip. Nothing else in the model moves. Run the same model with the productive volume raised, keeping the poll at one minute, and it reverses close to where the ratio put it — at 1,000 billable actions Zapier's next rung costs $58.50 against Make's $47.47, and Make never gives the lead back. The two models bracket each other rather than confirm each other: the unit-price rule puts the flip at 995 actions using the included-credit rate, while this table prices Make's overflow credits at the 25% premium, which on its own would push the flip out past 1,200. What lands the plan-price crossover between 600 and 1,000 is Zapier's rung step, not agreement between the two methods.

Now the third model, and the one that should change what you build rather than what you buy. Take the same scenario and replace the one-minute poll with an instant webhook, so the endpoint tells Make when something happened instead of Make asking 43,200 times. Make's unit count collapses from 43,800 to 600, the overflow disappears, and the monthly cost becomes $9.00 — the Core plan price, cheaper than either column in the previous table.

The crossover is real, and it is worth about seventeen dollars. The trigger change is worth thirty-eight. Anyone who reaches the flip point and responds by switching vendors has solved a $17 problem and left the $38 one in place.

What does not flip it: steps, fan-out and failure

Three intuitions circulate about Make vs Zapier and none of them survives arithmetic. Naming them matters, because each one gets used to justify a platform choice that the numbers do not support.

The first: Make charges per scenario, so multi-step workflows are nearly free. This is the most common error in third-party comparisons, and Make's own documentation contradicts it: an operation is "a single module run", and a ten-module scenario therefore consumes about ten credits per run, not one. Make is cheaper on multi-step work because its unit is cheaper, not because it bundles steps. Anyone modelling on the bundling assumption will under-forecast a ten-step scenario by an order of magnitude.

The second: fan-out punishes Make. Iteration multiplies both platforms in the same way. Make's rate card says iterators "use 1 credit to split an array into bundles, and the next modules use 1 credit for each iterated bundle". On Zapier, the Looping step itself is a built-in tool and does not count, but each action inside the loop runs once per iteration and each of those is a successful action, so each is a task. A 100-item array through two write steps costs Make 201 credits and Zapier 200 tasks. The unit counts converge; the price ratio does not. Fan-out is neutral in the comparison and expensive on both.

The third: retries and errors flip it. They move the number in Zapier's favour, and not nearly far enough. Zapier does not bill actions that "error or halt"; Make bills every attempt, because every attempt is a module run. On a workflow where one action in ten fails and is retried once before succeeding, Make bills eleven module runs where ten would have done — about 10% more units — while Zapier's count stays flat, against a unit-price gap of 44 times. Even Make's exponential backoff, which retries a connection error or module timeout on a fixed ladder and can turn one specified module run into as many as nine, produces a multiplier an order of magnitude short of what a flip would require. The failure path is a genuine and badly under-modelled Make cost, and it is the subject of a separate analysis of Make's failure-path billing; it is not a reason to buy Zapier.

That leaves the trigger check as the sole mechanism. It is worth saying plainly, because it is a more useful procurement finding than a table of plan prices: on published rates, the only ordinary design decision that can make Zapier cheaper than Make is polling a quiet endpoint frequently.

Frequency is a meter on Make and a plan step on Zapier

Both vendors charge for freshness. They just put the charge in different places, and the placement changes who notices it.

On Make, the minimum interval is a plan feature — 15 minutes on Free, one minute on every paid plan — but the use of that interval is metered. Choosing one minute over fifteen multiplies a scenario's trigger consumption by fifteen, from 2,880 credits a month to 43,200, and nothing in the interface presents that as a price. It is a dropdown.

On Zapier, the interval is the plan. The pricing page's plan data gives 15 minutes on Free, two minutes on Professional and one minute on Team, and the checks themselves are free at every tier. Buying faster polling on Zapier means moving from Professional at $193.50 to Team at $253.50 at the 10,000-task tier — a fixed $60 a month for the whole account, regardless of how many scenarios use it.

That difference has a governance consequence that outlives the invoice. On Zapier, trigger frequency is a decision someone makes once, at plan level, with a purchase order attached. On Make, it is a decision every builder makes silently, per scenario, and the cost surfaces weeks later in a credit balance nobody attributed to a dropdown. If your organisation has more builders than reviewers, that asymmetry is worth more attention than the price-per-unit table.

The FinOps Foundation's framework defines unit economics as developing and tracking metrics that connect how technology is used and managed to the value of what an organisation sells, and it separates resource-efficiency unit metrics such as "cost per GB transferred" from business unit metrics such as "cost per transaction". Applied here, the resource metric is cost per credit or per task, and the business metric is cost per delivered outcome. The two platforms rank differently on the first than they do on the second for exactly one workflow shape, and that is the shape this article has now costed twice.

Make: where the cheap unit earns its keep

Best for: teams with high-volume, multi-step, event-driven automation, at least one person comfortable with data structures, and the discipline to prefer webhooks over polling.

Key facts, from Make's own pages, fetched 31 July 2026: credits replaced operations as the billing unit, with balances converted one for one. Free gives 1,000 credits, two active scenarios, a 15-minute minimum interval and a 7-day execution log. Core is $9 a month at the 10,000-credit tier and now reaches 300,000 credits a month; Pro is $16 at the same tier and reaches 8 million; Teams is $29. Every paid plan advertises unlimited users. Extra credits cost 25% more than the credits included in the plan. Make advertises 3,000+ standard apps. Execution logs run 30 days on paid plans and 60 on Enterprise.

Pros. The cheapest published unit in this comparison by a wide margin, and it is not close. Routers, filters, error handlers and scenario modules carry no credit cost, so branching logic is genuinely free. Unlimited users on every paid plan means no seat tax on adding a builder or a reviewer. The rate card is published per module type, which makes a forecast possible before you build.

Cons. The meter bills attempts, not outcomes: an empty check, a failed write and a rolled-back run all consume credits. Credits expire at the end of the term, so unused capacity is not a buffer for the month you have an incident. Only the 10,000-credit rung has a published price on any plan, which makes an at-scale comparison impossible from public information alone. And the same "unlimited users" that removes the seat tax removes the seat as a control point: anyone with access can set a trigger to one minute.

Bottom line. If your triggers are instant and your volume is real, Make is cheaper than Zapier by a factor that no amount of workflow redesign on the Zapier side will close. Its costs are the ones you cannot see in the builder — the check that finds nothing, the retry, the expiring balance.

Zapier: where the free trigger earns its keep

Best for: teams whose automations wait on quiet endpoints, teams with more connectors to satisfy than volume to process, and organisations that would rather buy capacity in one visible plan decision than meter it per scenario.

Key facts, from Zapier's own pages, fetched 31 July 2026: a task is any successful action; triggers, filters, paths, failed and skipped steps and built-in tools do not count. Free gives 100 tasks a month, two-step Zaps and 15-minute polling. Professional starts at $29.99 a month for 750 tasks, monthly-billed, and its published self-serve ladder runs to 2,000,000 tasks at $5,099. Team runs the same ladder at a premium and offers one-minute polling. Zapier advertises 6,000+ apps. Zap history is guaranteed for a maximum of 60 days.

Pros. The billing rule aligns with delivered work: you pay when something succeeded in another application, and for nothing else. Free polling at every tier makes noisy, low-yield triggers cost nothing. The whole self-serve price ladder is public, so a finance model can be built without a sales call. The largest advertised connector catalogue in this pair. Failed actions are free, which quietly removes the flaky-integration cost problem that Make buyers have to model.

Cons. The unit is expensive — roughly 44 times a Make credit at entry prices, and still nearly three times at Zapier's largest self-serve rung against Make's smallest. Multi-step workflows are billed step by step, so the shapes teams most want are the shapes that cost most. Search steps configured to proceed when nothing is found bill even on the empty result. And a separate meter governs the AI side: agent activity is not counted in tasks, which means the task ladder is no longer the whole bill for anyone using Zapier's agent features. Our analysis of Zapier's task multipliers covers that second meter.

Bottom line. Zapier's pricing is honest about what it charges for and expensive at what it charges. It wins on cost only in the narrow polling case, and it wins on everything else that is not cost: catalogue breadth, published ladder, and a meter that never bills you for a failure.

What each platform leaves behind

Cost is the question buyers ask first and the least durable of the differences. The one that outlives the contract is the record: after a run has finished, what can you prove about it, and for how long?

Both platforms keep a run history and both cap it. Zapier's help centre states that Zapier "can only guarantee a maximum of 60 days of Zap run data in your Zap history" and will display up to 10,000 runs, recording per-step status, timestamp, version and the data received and sent (Zapier). Make's pricing page lists execution log storage as 7 days on Free, 30 days on Core, Pro and Teams, and 60 days on Enterprise. Neither is an audit archive, and both vendors say so in their own way: Zapier advises exporting history if you need records beyond the window.

For a regulated team that gap is the real finding of this comparison. A 30-day or 60-day window is shorter than most incident investigations, shorter than an annual audit cycle, and much shorter than the retention period any evidence request will assume. The difference between the two platforms here is measured in weeks; the difference between either platform and what an auditor asks for is measured in years. That is a shortfall you close outside the automation tool, by exporting run records into a store you control, on a schedule, before the window closes.

The second half of the record question is who can change the thing that runs. Both platforms let a builder edit a live automation, and neither meters the review step. That is not a criticism of either product — it is the standard shape of self-serve automation — but it means the control that matters most for irreversible actions is one both platforms leave to you. Our earlier analysis of when an approval gate is the actual control sets out the shape that a mandatory human step has to take before it counts as one.

Choose Make if, choose Zapier if

The decision as a sequence: trigger type first, then volume, then catalogue and record requirements.

Choose Make if your triggers are instant or your polled endpoints are busy; if you run more than roughly 1,000 billable actions a month per scenario; if your logic is branch-heavy, since routers and filters cost nothing; if you need many builders without paying per seat; or if unit cost is the constraint that actually binds your roadmap.

Choose Zapier if your automations poll quiet endpoints on a short interval and produce few outcomes. Or if the apps you need appear in Zapier's catalogue and not in Make's, which is a hard blocker no pricing analysis overrides. Or if your workflows fail often enough that free failed actions matter more than cheap successful ones, or you need a public price ladder to build a multi-year forecast without a sales conversation.

Choose neither on price if the deciding factor is the connector you cannot live without, the compliance requirement neither meets, or the review step neither enforces. Those are not tie-breakers, they are gates, and they should be evaluated before either pricing page is opened.

The one-sitting diagnostic. For each automation you plan to run, write down four numbers: trigger checks per month, billable actions per month, actions per run, and failure rate. Divide the first by the second to get the Idle-to-Action Ratio. Above 43 at entry prices, price it on both platforms; below 43, Make is cheaper and the remaining question is whether it is capable. That takes about ten minutes per workflow and it is the whole analysis.

When the meter is not your real problem

There is a volume below which the whole Make vs Zapier question is noise. A team running twenty automations that produce a few hundred actions a month will pay somewhere between nothing and $50 either way, and the hours spent modelling it cost more than the difference. The honest advice at that scale is to pick on capability and connector coverage, use the free plan until it breaks, and revisit when a bill first surprises someone.

There is also a shape where both platforms are the wrong tool. Both are metered per unit of work, which means both make high-frequency, low-value work expensive in a way that a self-hosted runner does not. If your workload is thousands of runs an hour against your own APIs, the comparison to run is not Make against Zapier but hosted against self-hosted, with the operational and data-residency questions that opens up. Our comparison of workflow tools chosen for their failure behaviour covers that decision from the reliability side.

And there is the case where the automation platform is not where the money goes at all. Once a workflow calls a model on every run, the model bill can dwarf the automation bill, and it is metered by a third party on tokens rather than by your automation vendor on steps. A workflow that costs four Make credits — under half a cent — and one long model call can be dominated by the model call. Neither vendor's pricing page tells you that, and neither meter shows it to you in the same view.

Where a governance layer fits, and where it does not

LeapForce does not replace Make or Zapier, and this comparison does not have a third column with our name on it. What the analysis above surfaces is a layer neither platform is trying to own: the AI calls those workflows make, and the record of what they did.

Once a workflow hands a step to a model, three questions arrive that a task counter and a credit counter cannot answer. Which model did that step call, and was it the approved one for that data. What did the call cost, charged to which team. And what happened to the data on the way out. LeapForce is an AI gateway that sits in front of those calls: one governed endpoint, with identity, policy, routing and metering applied per request, and budgets denominated in dollars rather than tokens. The rollout model we publish is deliberately unglamorous — Observe first. Enforce second. Optimize third. Point one team's traffic at the gateway in observe mode, learn what is actually being called and what it costs, and only then write rules. That sequence exists because the alternative, writing policy against a guess, is how governance projects stall. Per our honesty convention, gateway endpoints and tracing are live capabilities while budget enforcement is still in development, and this paragraph is the only place in this article where our own product appears.

Everything else in this piece stands whether or not you ever look at our platform: the unit definitions are the vendors' own, the arithmetic is reproducible from published prices, and the crossover holds regardless of what sits above the workflow layer.

Honest limits on this analysis

Nobody on our side has metered these workflows on a live Make or Zapier account. Every Make vs Zapier number above is derived from each vendor's published rate card and published prices as fetched on 31 July 2026, and both vendors have repriced within the last twelve months — Make twice, by its own release notes. Re-read both pricing pages before any figure here enters a business case, including the derived ones.

One assumption carries more weight than any other and deserves naming on its own. Every derived figure in this article — the $0.0009 credit, the 44-fold ratio, the threshold of 43, the whole break-even table — rests on Make's Core plan costing $9 a month with the pay-monthly toggle selected, which is what the page rendered on 31 July 2026. Make's annual toggle advertises a saving of 15% or more without publishing the resulting price. If your account's monthly rate differs from $9, every ratio here moves proportionally, and the arithmetic is set out step by step precisely so you can redo it with your own number rather than trust ours.

Four further limits are worth stating rather than burying. First, Make publishes a price for only the 10,000-credit rung of each plan, so every model here that needs a higher-volume Make rate uses the Core rate plus the published 25% extra-credit premium; if Make's higher rungs are cheaper per credit, the true crossover sits below the figures in the break-even table. Second, the models assume equivalent capability — that a workflow buildable on one platform is buildable on the other with the same step count, which is a simplification that breaks down on data transformation, where Make's structural tooling often needs fewer steps than an equivalent Zapier chain. Third, none of these models includes model or API costs incurred inside a step, which for AI-heavy workflows can exceed the automation bill entirely. Fourth, we quote Zapier's plan-level polling intervals from its pricing page data rather than a help-centre article, because Zapier does not publish an interval-by-plan table in its help centre; confirm the interval on your own plan before designing around it.

One source-quality note, since it cuts both ways. The clearest public worked example of this comparison is the Zapier Community post cited at the top, and its five-minute row lists 288 Zapier tasks where every other row in the same table lists 100 — a figure that matches the trigger-check count rather than the action count, and that Zapier's own published rule says should not be billed at all. That is a transcription slip in an otherwise careful table by a named expert, and it is the reason this article derives its arithmetic from vendor rate cards rather than from anybody's summary, including its own. Check the arithmetic here the same way.

We also found no independent, non-vendor measurement of either platform's real-world unit consumption. Both vendors publish rate cards; neither publishes a distribution of what customers actually consume per workflow shape, and no third-party dataset we could reach fills that gap. That absence is why this piece models rather than reports, and it is the single most useful thing a reader with production accounts on both platforms could contribute.

Ready to Govern Your AI?

Talk to LeapForce — one controlled layer for every AI tool, connector, model, and agent.