Per-Task Pricing: Examples & Companies

What is it

Per-Task Pricing is a billing unit where customers are charged per task an automation or agent executes — Zapier’s historical unit, now spreading to AI agents. The task is work-shaped: not a request served or a token generated, but a discrete action completed on the user’s behalf, which makes it the unit that most directly answers the buyer’s question “what did I get for the money?”

The catch is that “task” has no fixed altitude. Zapier defined the genre — one task per executed action step, plans sold as monthly task tiers — a crisp, countable unit a buyer can estimate from a workflow. But once the task becomes an autonomous agent run, vendors stop selling the count: they reprice it as compute time, effort, or a fair-use tier multiplier. And in the data-and-labor tier — Scale AI, Snorkel AI, Mercor, micro1 — the task is a labeled record or expert engagement whose buyer-side rate never appears in public at all.

Ten corpus companies meter tasks, and they span that whole range: crisp automation (Zapier, Rows), effort- or compute-priced agents (Cognition, Replit AI, Cognosys, Lindy), and quote-gated marketplaces. What unites them is not a rate — it’s the single decision every one makes before setting a rate: at what altitude is a “task” defined?

How it works

Every task meter is downstream of that altitude choice. An action step, a goal-level run, a unit of compute time, and a labeled data record are all called “tasks” here and differ in cost by orders of magnitude; tiering, bundling, and quotes only decide how the count is packaged after the fact.

Worked example — the definition is the price. A five-step Zap (one trigger, four actions) firing 30 times a day consumes ~3,600 Zapier tasks a month — but the same logical workflow on a platform that counts one goal-level run per execution would meter 900. Neither vendor is wrong; they’ve defined the unit at different altitudes, and the 4x spread is invisible until you price your actual workflows. This is the sharpest instance of the rule in the usage-metric guide: the unit’s definition, not its rate, is where task quotes diverge.

Worked example — one name, 5,000x apart. On Rows Plus, an “AI Task” (an LLM analysis step, 200/month included) and a “cell-enrichment task” (a table lookup, 1,000,000/month included) share a word and differ in allowance by 5,000x — so “tasks included” is meaningless without the qualifier. The far end of the range is Cognition, which sidesteps counting entirely: it prices Devin’s work in ACUs, each ~15 minutes of active effort at about $2.25 in on-demand credit, so a one-line fix and a multi-hour refactor are both “one task” but burn wildly different ACU counts. That is the closest the corpus comes to charging for effort delivered rather than actions attempted.

Companies using this

10 in-corpus companies meter tasks, spanning three genera: crisp-boundary automation (Zapier, Rows), effort-or-compute-priced agents (Cognition, Replit AI, Cognosys, Lindy), and quote-gated data/expert marketplaces (Scale AI, Snorkel AI, Mercor, micro1).

Patterns observed

The count survives only where tasks are discrete. Where step boundaries are crisp and enumerable, vendors publish the counting rule and let a tier ladder carry the volume discount — the buyer can look at a workflow and estimate the bill, and the vendor never has to defend what a task “is.” As soon as the task becomes an autonomous run whose internal cost swings by an order of magnitude, that stops working: vendors abandon the count for compute-time, effort, or “3x / 7x” tier multipliers. The entitlement-style allowance that wraps most agent pricing exists for this reason — an always-on assistant’s task burn is unforecastable, so the vendor sells a capacity envelope, not an itemized meter.

The dual-meter is a recurring hazard. Cognosys gated on messages/month AND workflow executions simultaneously; Rows runs its AI-Task and cell-enrichment meters side by side. Two caps means the buyer can’t tell which limit they’ll hit first — a forecasting tax that argues for one dominant task definition per product.

In the data-and-labor tier, the task is real but the rate is private. At Scale AI, Snorkel AI, Mercor and micro1, the “task” is a labeled record, an annotation, or an expert engagement performed by a vetted contributor workforce (Scale reports 240,000+ contributors and a 50%+ gross margin on the labor markup). Buyer-side rates are negotiated because the task mix and quality bar are the negotiation. These are per-task businesses in unit terms but sales-led procurement businesses in go-to-market terms.

Counterexamples & variants

Lindy is the counterexample from inside the cohort. It ran task-credit pricing for its agents and walked it back in 2026, landing on flat $49.99 / $99.99 / $199.99 subscriptions where usage exists only as tier multipliers — direct evidence that for ambient AI assistants, the meter’s precision reads as unpredictability to the buyer. Replit AI shows a different retreat: it abandoned a flat per-checkpoint fee for effort-based Agent billing because a fixed rate mispriced an agent’s real variable cost, then hid the arithmetic inside a dollar-denominated wallet ($25 on Core, $100 on Pro) where “how many tasks is $25” is intentionally unanswerable. The agent-platform world is split between these hidden-count models and the published per-task conviction Zapier still embodies; which side wins is one of the open questions in agent pricing.

Cognosys is the terminal variant: a transparent, self-serve task-and-message meter from $15/month that was acquired by Cohere and sunset — proof that a clean per-task rate card is no moat if the product doesn’t survive.

The marketplaces are less a counterexample than a different genus: the “task” is a unit of labor procurement, not software metering. Scale AI meters per labeled task on a human-plus-AI workforce; Snorkel AI prices committed data-licensing contracts scoped by volume rather than a per-record meter — and both keep the effective rate behind an RFP. The word “task” does double duty across the corpus: sometimes a metered software action, sometimes a priced-per-engagement human deliverable.

What this means for buyers vs vendors

For buyers

Price your three highest-volume workflows, not the rate card, and count the steps the way each vendor counts them — the definition alone moves a quote by 4x before any discount conversation. On bundled and wallet models, confirm which meter your workload actually draws from: a generous-sounding million-task allowance may not cover your AI usage, and a dollar-denominated credit wallet won’t tell you your task count until you run real work. For effort- or compute-priced agents, model your heaviest tasks, not the entry-tier floor. On flat agent plans, treat a “3x usage” multiplier as a fair-use policy you haven’t read yet and get the underlying cap in writing. And in the data-and-expert tier, expect no public rate — benchmark on task volume and quality bar and accept that an RFP is the only way to compare quotes.

For vendors

The task is the most buyer-legible unit in automation — one task, one thing done — so spend that legibility carefully: publish the counting rule with worked examples, keep one definition across endpoints, and put volume discounts in visible tiers rather than inside the plan name.

If your product acts continuously rather than discretely, decide honestly whether you’re selling tasks at all. Lindy’s pivot suggests ambient agents sell better as capacity (flat tiers with allowances) than as itemized work — a meter the buyer can’t predict is a churn driver however fair it is. When the underlying cost is genuinely variable, reprice the task as effort or compute, but give the buyer a wallet and dials so the variability is theirs to control, not a monthly surprise. And avoid the dual-meter trap: two simultaneous caps double the forecasting burden, so pick the dominant unit and lead the price card with it.

Explore this theme in the knowledge graph →