AI Agent Workflows, make vs n8n: Real Cost and Limits

The make vs n8n question sounds like it’s about features, but for AI agent workflows it’s about one word on each company’s pricing page: what counts as a “run.” I run my whole operation on n8n: the social pipeline, content batches, error alerts, the workflows that write files back to the repo. Before writing this I mapped one agent workflow onto both tools, module by module, to see where each one starts charging. The features turned out nearly identical. The bills did not.

So this isn’t a which-has-more-integrations list. It covers how each tool bills an agent that loops, where it runs, what happens when a Claude call times out halfway through a batch, and the same workflow built both ways so you can do the math for your own volume.

One line item neither pricing page shows: a step that fails quietly still bills. My own publish workflow once logged success: true every hour for a day while the Instagram step inside it had stopped posting. The Acrid Team plan finds it and fixes it, in either tool.

Make vs n8n: the billing difference that decides everything

Make bills per module run. n8n bills per workflow execution. Everything else in this article sits on top of that sentence.

In Make, every time a module does something (fetch a row, call an API, parse JSON, write to a sheet), that’s one billable unit. Make used to call these “operations.” It now calls them credits, and AI modules can use more than one per call. A scenario with eight modules that runs once uses at least eight. Put those eight modules inside an iterator over 20 items and you’ve used roughly 160 for one trigger.

In n8n Cloud, the same trigger is one execution. It doesn’t matter if the workflow has 8 nodes or 80, or if it loops over 20 items or 2,000. One start, one execution, one billable unit. If you self-host the Community edition, there’s no per-execution fee at all. You pay for the server, and a small VPS covers a lot of workflows. I wrote up the hosting tradeoff in detail in n8n cloud vs self-hosted.

That’s why the comparison changes for AI agents in particular. A simple “new form submission, send to Slack” zap has three steps either way, and the two pricing models land close together. An agent workflow is almost never that shape. It reads, reasons, calls a tool, reads the result, reasons again, and loops. Make’s model charges for every one of those beats. n8n’s doesn’t.

Both companies change plan tiers and included quotas often enough that I won’t print a price table that will be wrong by next quarter. Check the live pricing pages. The structure (per module vs per execution) has stayed the same for years, and that’s what you’re actually choosing between. For n8n’s current tiers specifically, I keep n8n pricing explained updated.

The same workflow, built in both

Here’s the test workflow, a stripped-down version of something I actually run: every morning, pull 10 rows of story ideas from a Google Sheet, send each one to Claude to draft a caption, check that the draft passes a banned-phrase filter, write it back to the sheet, and post a summary to Slack.

The Make version

In Make, this becomes a scenario with this chain:

1. Google Sheets: Search Rows: returns 10 bundles (Make’s word for items).
2. Iterator: splits them so each row flows through on its own.
3. Anthropic / HTTP: Make a request: calls the Claude API once per row.
4. JSON: Parse: pulls the caption out of the response.
5. Filter + Router: sends drafts that pass the filter one way and failures another.
6. Google Sheets: Update Row: writes the result back.
7. Array Aggregator: collects all 10 results back into one bundle.
8. Slack: Send Message: posts the summary.

Count the billable module runs: 1 search, then 10 passes through the Claude call, the parse and the sheet update (30), plus the aggregator and the Slack message, plus the iterator’s own runs depending on how you count them. Call it 33 to 45 units per morning. Run it 3 times a day and you’re around 3,000 to 4,000 units a month for one small workflow, before any retries. Add a second Claude call per row (a critic pass that checks the draft, which I do run) and the per-row cost goes up again.

The n8n version

In n8n, the same thing is:

{
  "nodes": [
    { "name": "Schedule Trigger", "type": "n8n-nodes-base.scheduleTrigger" },
    { "name": "Read Ideas", "type": "n8n-nodes-base.googleSheets" },
    { "name": "Loop Over Items", "type": "n8n-nodes-base.splitInBatches",
      "parameters": { "batchSize": 1 } },
    { "name": "Draft Caption", "type": "n8n-nodes-base.httpRequest",
      "parameters": {
        "url": "https://api.anthropic.com/v1/messages",
        "method": "POST",
        "sendBody": true,
        "jsonBody": "={ \"model\": \"claude-sonnet-4-6\", \"max_tokens\": 400, \"messages\": [{ \"role\": \"user\", \"content\": \"Draft a caption for: {{ $json.idea }}\" }] }"
      },
      "retryOnFail": true, "maxTries": 3, "waitBetweenTries": 5000 },
    { "name": "Banned Phrase Check", "type": "n8n-nodes-base.code" },
    { "name": "Write Back", "type": "n8n-nodes-base.googleSheets" },
    { "name": "Slack Summary", "type": "n8n-nodes-base.slack" }
  ]
}

That’s a trimmed sketch with credentials and connections removed, not a paste-and-run export, but the node choices match how I build these. The whole run counts as one execution on n8n Cloud and costs nothing extra self-hosted. Three runs a day is about 90 executions a month. Add the critic pass and it’s still 90.

Same logic, same API calls, same Claude bill. One platform counts about 90 things a month, the other counts thousands. The Anthropic invoice is the same on both. Only the orchestration layer’s bill moves.

The banned-phrase check also shows a quieter difference. In n8n it’s a Code node with ten lines of JavaScript. In Make you’d build it from filters and text functions, which works but gets awkward once the list is longer than a handful of patterns.

Loops and API calls: where the two tools actually differ

Loops are where agent workflows live, and the two tools think about them differently.

Make’s iterator/aggregator pair is elegant to look at. Data visibly fans out and comes back together, which makes a scenario easy to read for someone who’s never seen it before. It’s built for “do this for each item,” and not as well for “keep going until a condition is true,” which is what a real agent loop is: call the model, check whether it wants a tool, run the tool, call the model again, stop when it says it’s done. You can build that in Make with repeaters and routers, but every pass costs units and the scenario gets hard to read quickly.

n8n has Loop Over Items for batches, and you can wire a node’s output back to an earlier node for conditional loops. It also has a dedicated AI Agent node that runs the model-tool-model loop inside one node, with tools attached as sub-nodes. That matters for cost, because the whole agent loop sits inside one execution. I wrote about the batch-loop patterns I actually use in how I run n8n workflow loops for content batches, including the one where I accidentally sent 40 items to Claude at once and hit the rate limit on every one of them.

For raw API calls, both have a general HTTP module and both handle auth headers, JSON bodies and pagination fine. n8n pulls ahead when the response needs real work done on it. A Code node that reshapes a messy JSON response is faster to write and easier to debug than a chain of Make’s built-in functions. Make pulls ahead on its catalog of ready-made app modules, which is larger and more polished, so if the API you need already has a Make module you might never write a request by hand.

Make scenarios also have a maximum run time per execution, measured in minutes, set by plan. A slow batch of model calls can hit it. Self-hosted n8n has no hard limit beyond whatever timeout you set, which matters when one Claude call with a big context takes 30 seconds and you have 50 of them.

What happens when the model call fails at 3am?

Model APIs fail in boring ways: rate limits, timeouts, the occasional overloaded error, a response that doesn’t parse because the model wrapped the JSON in a sentence. How a tool handles failure matters more than how it handles success.

Make attaches error handlers to individual modules. If the Claude call fails you can Resume with a fallback value, Ignore and move on, Break and save the run as an incomplete execution to retry later, or Rollback/Commit for transaction-like behavior. Stored incomplete executions are a nice feature. You fix the problem and replay the exact bundle that failed. n8n has nothing native that matches it.

n8n gives you per-node Retry On Fail with a set number of tries and a wait between them, an “On Error: Continue (using error output)” setting that sends failures down their own branch, and the Error Trigger: a separate workflow that fires whenever any workflow fails. That last one is what I depend on. One error workflow catches failures across the whole fleet and sends me the workflow name, the node, and the message. The setup is in how I alert on failed n8n workflows.

The failure that matters most for agents isn’t a crash, though. It’s a run that “succeeds” with garbage: the model returned an empty caption, the parser took it, and the sheet now has a blank row marked done. Neither tool catches that for you. You need an explicit check node (like the banned-phrase check above) that fails loudly on bad output. Retries in Make cost units. Retries in n8n are free inside the execution. If your agent retries a lot, that cost difference grows.

Hosting, data, and who sees your prompts

Make is cloud-only, full stop. Your scenarios, credentials and the data passing through them all live on Make’s infrastructure. For most small businesses that’s fine. Make is a mature company with the usual compliance paperwork.

n8n gives you the choice. n8n Cloud works like Make: they host it, you pay a subscription. The self-hosted Community edition runs in Docker on any server you control, and your prompts, API keys and customer data never touch a third party except the APIs you call on purpose. If you’re piping client documents through Claude, self-hosting can be what gets the project approved.

Self-hosting has real costs, and I’ve paid them: updates you have to apply yourself, a database to back up, a webhook URL that breaks when you move servers. If nobody on your team wants to maintain a box, n8n Cloud or Make is the honest answer.

Which one to pick

Pick Make if your workflows are mostly linear, run at modest volume, rely on lots of polished app integrations, and the person building them isn’t comfortable with JSON. The editor is lovely and the learning curve is short. My full take is in the Make review.

Pick n8n if your workflows loop, call models several times per run, retry often, need custom code, or need to run on your own infrastructure. That’s most real AI agent work. It’s why I run my operation on n8n, and why the per-execution model keeps my orchestration bill flat while the workflows grow. If you’re brand new to both, n8n vs Make for beginners is a gentler start.

The rule I use: count the module runs in your busiest workflow, multiply by monthly runs, and compare that number to the number of executions. If the first is ten times the second, you already know which pricing model you want.

If you’d rather see the actual configs than my summary, the fleet files are the real prompt and workflow files this operation runs on. Drop an email and they’re yours.

If you’d rather not build it yourself, tell us the workflow and we’ll build it for you with AI.