Workflow Execution Pricing: Examples & Companies

What is it

Workflow Execution Pricing is a billing unit where each end-to-end workflow or automation run is metered and billed, regardless of the compute steps it contains. The execution is the unit of finished work: one trigger fires, the workflow runs to completion, one execution is counted. What happens inside — the number of LLM calls, API lookups, branches, or data transformations — is absorbed into that single charge rather than billed line-by-line.

The model emerged from a legibility problem. As automation platforms stitched AI steps into their flows, the per-task and per-operation meters that governed simple linear Zaps began to diverge from the buyer’s lived experience. A multi-step AI-agent workflow that loops through a language model, queries a database, and posts a Slack message isn’t intuitively “three things” to the operator running it; it’s one job that either succeeded or didn’t. Execution pricing recaptures that intuition and makes the billing conversation start from “how many workflows did you run?” — a question every operator can answer without opening a dashboard.

n8n is the sharpest example. Since its August 2025 repricing, n8n’s cloud plans are defined entirely by monthly workflow-execution quotas, with users, workflows, and steps all unlimited on every paid plan. A workflow that fans out across hundreds of nodes, fires sub-workflows, and calls three different LLMs still costs exactly one execution, because the meter is attached to the run, not the work inside it. n8n raised a $180M Series C at a $2.5B valuation in October 2025 on the strength of this positioning.

CrewAI applied the same logic to AI-agent orchestration: one crew run counts as one execution regardless of how many agents, tasks, and tool calls it orchestrates internally. Its AMP platform meters those executions, and the OSS framework underneath is free and self-hostable (MIT license, 50,000+ GitHub stars), so the meter only applies to the hosted product. A $25/month Professional tier (100 executions, $0.50 per additional) launched with AMP in October 2025 and was removed in spring 2026 — a signal that the self-serve shape is still unsettled.

Pipedream is the important variant: it lists workflow-executions as a billing unit but meters compute time and memory rather than invocation count, so the execution stays the unit of intuition while cost tracks how long the run took and how much RAM it held.

How it works

Workflow execution pricing spans a wide mechanical range. The table below maps the key design dimensions against companies in this cohort.

The core unit math for a pure execution model:

Total bill = (plan fee) + (executions × rate), where executions are counted once per run regardless of internal fan-out.

For compute-layered models like Trigger.dev:

Total bill = (plan base) + (run invocations × $0.000025) + (execution seconds × machine rate)

Trigger.dev’s own pricing page works a concrete example: a 10-second task running 100 times a day on the default Small 1x machine costs about $1.09 a month, all-in. Because the monthly base ($10 Hobby, $50 Pro) is a prepaid credit balance rather than a license, a light workload effectively pays only the base fee.

For Pipedream’s memory-scaled credit model:

Credit consumption = (execution seconds / 30) × (allocated memory GB / 0.256)

The distinction between these formulas matters enormously at scale. A team running 100,000 short, lightweight automations per month will pay very differently on a pure-execution meter (one charge per run) versus a compute-layered meter (invocation fee plus seconds billed). The pure-execution model is always predictable; the compute-layered model is always accurate.

Upstash Workflow takes a third path: it meters workflow steps, not whole-workflow runs, at $1 per 100,000 steps — a PAYG model that scales with internal complexity rather than run count. A fixed-plan option ($180/mo for 1M steps, $420/mo for 10M steps) is available for predictable workloads. This sits structurally closer to Make’s per-operation meter than to n8n’s per-run meter, but the unit (a durable, checkpointed workflow step) is more precisely defined than a generic “operation.”

Companies using this

Twelve companies in this corpus meter workflow executions as a primary or secondary billing unit, spanning developer-infrastructure tools, AI-agent platforms, and enterprise automation suites. n8n and CrewAI are the purest examples of the execution-as-primary-metric model; Trigger.dev and Pipedream layer execution counting onto a compute-time foundation; LangChain, Upstash, Copy.ai, and Writer treat it as one of several billing dimensions; and Automation Anywhere, UiPath, and Ironclad fold it into enterprise consumption models gated behind sales.

Patterns observed

The definition of “one execution” is the whole ballgame. The most consequential choice isn’t the rate — it’s the altitude at which the meter attaches. n8n attaches at the workflow level; CrewAI at the crew level; Trigger.dev at the task invocation, where a sub-task spawned by a parent is a separate run billed at $0.000025. So “200 executions per month” means very different things across the three: CrewAI’s 200 could be 200 complete multi-step agentic workflows, while Trigger.dev’s 200 might be 200 individual function calls inside a single conceptual job. Sub-flow counting is where the divergence bites — after n8n’s 2025 repricing, teams that modularized with child workflows reported execution counts running two-to-five times higher than expected.

Execution pricing absorbs AI-agent fan-out better than per-action alternatives. The LLM calls, web lookups, and tool invocations inside an agent run are not individually predictable, but the number of agent jobs you dispatch is — so the execution meter gives a per-job cost floor that per-action and per-token meters can’t. A loop of 50 LLM calls is one n8n execution; Make’s per-operation meter would count each step. Copy.ai shows the framing at the GTM layer: its Growth/Expansion/Scale tiers ($1,000–$3,000/mo) meter the underlying work in credits, yet each workflow run is the unit the buyer thinks in — legibility for a marketing team even when the meter is credit-denominated.

Free tiers hard-cap at the execution level. The free tier imposes a hard execution or credit cap rather than a soft limit or time-boxed trial — Pipedream Free stops at 100 credits, Trigger.dev at $5 of compute credits, Cognosys’s old Free tier at exactly 20 executions (and 100 messages). Generous enough to ship a real automation, hard-limited enough to force an upgrade when production volume arrives: textbook PLG entitlement sequencing where the cap is the conversion mechanism, not a penalty.

Open-source escape hatches discipline the rate cards. n8n, CrewAI, and Trigger.dev each ship both a metered managed cloud and a free, self-hostable engine, which sets an implicit ceiling: the managed rate must stay below the loaded cost of self-hosting at equivalent volume — Trigger.dev’s Apache-2.0 engine is the exact runtime behind its Cloud product. The platforms without that discipline — Automation Anywhere, Ironclad, UiPath — compensate with enterprise-only opacity: no public execution rates, volume negotiated inside annual contracts.

Per-step and per-execution meters are converging. LangChain’s LangSmith Deployment moved from $0.001 per node executed to a flat $0.005 per deployment run between late 2025 and January 2026, because the per-node meter over-charged complex graphs and under-charged trivial ones. The break-even was exactly 5 nodes: a 20-node agent invocation that cost $0.02 under per-node billing now costs a flat half-cent, while a trivial 3-node graph got 67% more expensive. The market is sorting — per-step billing suits infrastructure primitives with variable, known workloads; per-run billing suits application-layer platforms where the workflow is the customer’s unit of work.

Counterexamples & variants

Cognosys is the execution-metering cautionary tale. Launched in 2023 as a freemium AI-agent product metered on messages-per-month and workflow executions (Free: 100 messages, 20 executions; Pro $15/mo; Ultimate $59/mo), Cognosys rebranded to Ottogrid in October 2024 and was acquired by Cohere in May 2025, at which point the standalone product was sunset. The pricing was well-designed for consumer AI agents — it read like a productivity app rather than per-seat SaaS — but the product couldn’t survive as an independent entity long enough to prove or disprove the model at scale. It is a reminder that execution pricing solves a billing-legibility problem but does not solve product-market fit.

Make does not use execution pricing, despite being in the automation category. Make charges per operation (credit), where one module run equals one credit for non-AI workflows. A four-module scenario fires four credits, not one — but scenarios and users are unlimited; you buy throughput, not runs. This is the direct commercial competitor to execution pricing: Make’s per-module meter is more granular and yields more revenue per complex workflow, but it’s harder for a buyer to intuit. n8n deliberately chose the opposite side of this trade-off when it removed its active-workflow caps in August 2025 and put everything on the execution meter. The two models represent a genuine design disagreement, not a transitional state.

Zapier’s per-task meter is a partial substitute but measures a different thing. Zapier counts every successful action step as one task. A five-step Zap running 1,000 times a month consumes 5,000 tasks, not 1,000 executions. Zapier is not in this cohort because it lists tasks, not workflow-executions, as its billing unit — but it’s the closest alternative model. The practical difference: for simple, narrow automations, per-task and per-execution pricing converge. For complex multi-step or AI-agent workflows, per-execution pricing becomes meaningfully cheaper because the execution meter ignores internal complexity. This is why n8n marketed the 2025 repricing explicitly as a departure from Zapier-style per-step billing.

Enterprise consumption models include execution-adjacent meters without exposing them. Automation Anywhere, UiPath, and Ironclad all list workflow-executions in their billing units, but none publishes a per-execution rate. UiPath’s Unified Pricing meters agent and document actions in Platform Units — “units are consumed at a rate of 0.2 Platform Units per chargeable action” — with Basic starting at $25/mo self-serve and Standard/Enterprise both Contact Sales. Automation Anywhere prices cloud consumption inside an annual bot contract (third-party aggregators peg the median ACV near $41,877). Ironclad scales pricing on seats and contract/workflow volume, with a reported median ACV of ~$39,995/yr and large deals above $200,000/yr. These are execution-aware models hidden behind sales-negotiated deals — the execution dimension lives in the contract, not the pricing page. For buyers here, explicitly asking for per-execution or per-run unit pricing in procurement is worth the friction, because it enables scenario-based cost modeling that “contact sales” obfuscates.

What this means for buyers vs vendors

For buyers

Ask one question before you sign: “Does a sub-workflow triggered inside my automation count as a separate execution?” If you compose, reuse, or conditionally branch across separate workflows, the answer dominates your total cost more than any headline rate — and it splits the field (yes for n8n, no for CrewAI).

Then map your workload shape to the model. Short, simple, high-volume automations (email notifications, CRM field syncs) suit per-execution tiers, where run count is predictable and the per-run rate is small. High-fan-out AI-agent workflows with unpredictable internal loops are better on the execution-only model (n8n, CrewAI) than the compute-layered one (Trigger.dev, Pipedream), because the run-level meter insulates you from per-step variance inside the job. Model both patterns with the usage metric selection guide and the invoicing cycles guide, then sanity-check against the pricing calculator hub.

Finally, budget for the tier cliffs. Execution tiers step up steeply — the quota can quadruple while the price rises 16×, and always-on polling or chatbot workflows can burn a monthly allowance in days — with no graceful overage path between tiers, so you pay the next tier’s price the day you cross the cap. Run a week of realistic traffic in a free or dev environment, multiply by 30, and provision for the tier above.

For vendors

Execution pricing works best when your customers can answer “how many workflows ran this month?” without opening a dashboard — which means the unit must map cleanly to the user’s operational model. If your workflows are triggered by external events at unpredictable rates (webhooks, email ingestion, polling), execution pricing aligns with what the customer already monitors. If they’re triggered programmatically inside the user’s own application code, compute-layered pricing (Trigger.dev’s credit-balance model, Pipedream’s memory-scaled credits) may produce better margin alignment because it tracks what you actually pay for.

The infrastructure requirement is real: an execution meter needs a durable counter that increments at workflow start and doesn’t double-count retries or failed starts. Trigger.dev’s use of OpenMeter for per-millisecond compute billing, synced to Stripe with entitlements gating the free tier, is a public reference architecture for building this at scale without in-house billing plumbing — while LangChain took the opposite path and built its trace/run/LCU meter in-house. Open-source engines like n8n’s and Trigger.dev’s create long-term rate-card discipline: you can’t price the managed cloud above what a competent team could self-host for, so plan your execution tiers with self-hosting cost as a floor, not a ceiling. See the tracking and metering guide for the implementation fundamentals.

Explore this theme in the knowledge graph →