Build guides
Replace one per-task step and measure the bill
If your automation bill grows every time a workflow succeeds, the usual response is to automate less. This build moves one step off a per-task price and onto tokens, then measures it — because whether that is cheaper depends entirely on your task size, and anyone who tells you otherwise has not seen your workload.
I build this, so check the arithmetic rather than the framing. Every figure below is measured.
Pick the right step to move
Not the whole workflow. The one step where a task is expensive relative to what it does — a classification, a summary, a draft — and where your current tool is charging you the same per-task price it charges for moving a row.
| Good candidate | Bad candidate |
|---|---|
| A step that reads something varied and decides | A step that moves a record from A to B |
| A chain of IF nodes that is never quite finished | Anything needing a maintained connector |
| Something producing text a person then edits | Anything that must be byte-identical twice |
Step 1 — build the agent
Agents → Create agent. The instructions go in the Configuration (JSON) box — there is no separate instructions field, which is the single most common thing to get wrong here:
{
"system_prompt": "You classify and summarise inbound items for an operations team. Return JSON with: category, urgency, summary (one line), and needs_human. Be decisive and brief.",
"temperature": 0.2,
"response_format": "json"
}Then add a Webhook trigger on the Schedules page so your existing tool can POST to it and read the answer back. Your Zap or scenario keeps everything else.
Step 2 — measure it, do not estimate it
Run it twenty times on real inputs and read the cost on each run. Then do the arithmetic against your current bill:
| Per-task pricing | Here | |
|---|---|---|
| Unit | One task, whatever its size | Tokens, so it follows the size of the job |
| A small step | Full task price | $0.0024–$0.0144 measured |
| A large step | Same task price | More — the dearest agents shipped here reach about 11 cents |
| A step that fails early | Often still a task | $0.0024 — you pay for tokens spent |
| Monthly floor | Plan price | $29 flat, or free under 100 runs and $0.50 a day |
Source: three runs opened up step by step, costed by the same pricing code the product bills with.
The arithmetic that actually decides it
Take your current per-task price, multiply by the number of times that one step runs a month, and compare against your measured cost per run times the same number, plus $29. If your step runs a few hundred times a month and each run is small, tokens win. If it runs twenty times, the $29 is the whole story and you should not move.
Where the shape matters more than the size
The useful difference is not that it is cheaper — it may not be. It is that the bill stops punishing success. A workflow that doubles in volume doubles a token line that was already small, instead of doubling a per-task line that was already the reason you throttled it.
Removing the ceiling entirely
Attach your own Anthropic or OpenAI key under Account → Integrations and the daily limits stop applying on either plan. You pay the model provider directly, at cost, and we do not mark up tokens. At that point your usage bill is the provider’s and it is not ours to inflate.
What you give up by moving that step
Said plainly, because a page that only lists savings is a sales sheet:
- **Ten tools here, against a catalogue of hundreds.** Any REST API is reachable, and that is not the same as a maintained connector with somebody else on the hook when a vendor changes their API.
- **It is not repeatable.** The same input can produce differently worded output. Fine for a draft a person edits; wrong for anything another system parses without `response_format: "json"`.
- **No SOC 2 or HIPAA report.** Those are certifications, not postures, and we do not hold them.
- **Billing is per account, not per seat.** A team wanting seat-level roles will find this thin.
The failure that costs more than the bill
A deterministic step that cannot reach an API errors. An agent often writes a sentence as though it had. Source: a logged run of mine finished COMPLETED after two calls returned HTTP 403 while the tool result said "ok": true — and it told a customer it had checked her orders.
So the check to build is not on status. Have the step return a count and assert on it in your existing tool — the run says what it processed, the source says what it handed over, and the two have to tie out. That check survives either engine being wrong about itself.
Next
- The full click-by-click on one agent — see Build a support agent that answers a refund ticket.
- The dated side-by-side on price — see agent-mesh.org/compare/zapier.
- What the two daily ceilings actually are — see Billing, plans & the Pro trial.