Gumloop meters work in credits, and AI nodes consume more of them than plumbing nodes do, so the bill tracks how much thinking your flows do.
Credit models are flexible, which is their advantage and the reason consumption is hard to predict before you run something.
This page explains the shape of the pricing model rather than quoting figures, because plans and credit allowances change. Check gumloop.com for current numbers before deciding.
| Gumloop | n8n Cloud | Aisle | |
|---|---|---|---|
| Billable unit | Credits, weighted by node type | Workflow execution | Run, plus model calls |
| AI steps | More credits than plumbing nodes | Model billed separately | The call, at a line you wrote |
| Adding a non-AI step | Some credits | Nothing | Nothing |
| Cost known before running | Hard to forecast | Roughly | Yes, calls sit in the code |
| Running on every record | Credits scale with volume | One execution per run | One run, calls per item |
| Retry after partial failure | Re-runs and re-consumes | Re-runs | Checkpoints skip finished items |
A credit model weights consumption by the kind of work a node does, so an AI step costs more than moving a field between two apps. The same flow can therefore consume very different amounts depending on how much text it processes and how many items come through.
When a flow fails part way through a batch, re-running it repeats the AI steps that already completed. You pay twice for the same thinking, and any side effects those steps caused happen twice too. On a large batch it is usually the largest avoidable cost in an AI automation.
In a task the model is called from your Python at lines you wrote, so the calls per run are countable by reading the file.
Nothing calls a model unless a line in your file says so, which puts the decision about when to spend tokens with you rather than with an agent. Cache results, checkpoint long runs, and know the bill before it arrives.
brief = aisle.cache.get_or_set( f"brief:{account['domain']}", lambda: aisle.ai.run_prompt(slug="account-brief", variables=account), ttl="7d", ) # Cached between runs. No second model call.
Gumloop meters work in credits, weighted by the type of node, so AI steps consume more than simple data-moving steps. Plans include a credit allowance. Check gumloop.com for current allowances and prices, since they change.
It depends on how much work each item needs rather than volume alone. Because AI nodes carry more weight, a flow processing long documents on every record consumes credits considerably faster than one moving fields between apps. Estimate on work per item, not runs per month.
Four things do most of the work. Use a small model for easy steps and reserve the large one for hard judgment. Cache expensive lookups so they are not repeated between runs. Checkpoint batch work so a retry does not pay again for completed items. And keep model calls at points you can see, so you can count them.
Put the model calls in code at points you chose. When you can read the file and count the calls per item, the monthly cost becomes arithmetic. Any model where consumption is weighted and spread across a visual graph is harder to predict in advance, whatever the headline rate.
Competitor details reviewed . Vendors change plans and features without notice, so check theirs before deciding.
Model calls at lines you wrote, with checkpoints so a retry never pays twice.