Most people who search for n8n pricing want one number. The honest answer is that n8n has two price lists that have almost nothing to do with each other. One is what n8n charges you to run it in their cloud. The other is what it costs you to run the free version yourself, which is never actually free once you count the server and the hours.

We build n8n workflows for clients, and we get asked this every week. So here is the full picture as of October 2026, checked against n8n's own pricing page, docs and help center, plus what we have learned from keeping a self-hosted instance alive in production. If you are new to the tool itself, start with what n8n is and how it works.

Quick answer

Pay per run in the cloud, or pay for a server.

n8n Cloud bills per execution, which is one full run of a workflow no matter how many steps it has. For US customers, Starter is $20 a month billed annually ($24 month to month) for 2,500 executions, Pro is $50 ($60) for 10,000, and Business is $800 ($960) for 40,000 on your own servers. The self-hosted Community Edition is free with no execution cap; a small production server runs roughly $8–14 a month in 2026. On Starter and Pro, runs over your limit fail until the month resets.

• $20: Per month for 2,500 Cloud executions, billed annually (n8n)

• 1 run: Counts as one execution, whether it has 3 steps or 40 (n8n docs)

• ~$6: A month for Hetzner's CX23 server (€5.49) after the June 2026 price rise

n8n pricing at a glance

All prices below are in US dollars, which is what n8n charges billing addresses in the US. n8n's default currency is the euro: in most other countries you pay the same numbers in euros, except Business, which is €667 a month billed annually. Annual billing saves about 17%.

n8n plans at a glance

US prices, Oct 2026

Want to test it before you pay? n8n Cloud has a 14-day free trial with no credit card. Affiliate link: Amplence may earn a commission if you later subscribe, at no extra cost to you. It doesn't change what we recommend.

Every paid plan includes unlimited users, unlimited workflows and every integration. That was not always true. Until August 2025, n8n also capped how many workflows you could have active at once, which made the cheaper plans far less useful than they look today.

How n8n charges: one execution per workflow run

This is the part that makes n8n cheap for some teams and oddly expensive for others. n8n bills per execution , and an execution is one complete run of a workflow, no matter how many steps are inside it. A 3-step workflow and a 40-step workflow cost exactly the same per run.

Compare that with Zapier, which charges a task for every action step, and Make, which charges a credit for nearly every module. We run a 37-step order and support workflow for an e-commerce client. On n8n, each run is one execution. On Zapier the same run would be dozens of tasks. That gap is the whole reason many teams move to n8n once their workflows grow past a handful of steps. We break down that comparison in our n8n vs Make vs Zapier guide.

What counts as an execution (and what doesn't)

n8n's documentation is specific about this, and a lot of the pricing articles out there get it wrong. Only production runs count. Here is the official list.

Counts toward your limit:

• A Schedule trigger counts one execution every time it fires, whether or not it finds anything to do.
• A polling trigger (for example, "check Gmail for new emails") counts only when it finds new data.
• A webhook counts once for every request that starts the workflow.

Does not count:

• Manual test runs from the editor while you build.
• Sub-workflows. Only the parent workflow's run counts.
• Error workflows that fire when something fails.
• Polls that come back empty.
• Malformed webhook calls that fail before the workflow starts.

Two practical consequences. First, you can split a big workflow into sub-workflows for sanity without paying more. Second, the real budget-killer is a Schedule trigger on a tight interval. A workflow that runs every five minutes uses about 8,640 executions a month on its own, which is more than three Starter plans. If you only need to react to new data, a polling trigger or a webhook is almost always cheaper.

A 3-step workflow and a 40-step workflow cost the same per run on n8n. What drives the bill is how often a workflow runs, not how long it is.

Each n8n Cloud plan in plain English

Starter: $20/month (annual) or $24 (monthly)

2,500 executions, 5 concurrent executions, one shared project and 1,600 Assistant credits a month. Each run can last up to 5 minutes, and you get 1 day of workflow history and 7 days of execution logs. It is enough for a small business running a few event-driven workflows: form to CRM, new order to Slack, invoice to accounting. It is not enough for anything on a frequent schedule, or for long AI runs that need more than 5 minutes.

Pro: $50/month (annual) or $60 (monthly)

10,000 executions, 20 concurrent executions, three shared projects, admin roles, global variables, 5 days of workflow history and execution search. Runs can last up to 40 minutes, and execution logs are kept for 30 days. Pro also comes in a larger tier with 50,000 executions and 50 concurrent runs, and monthly subscribers on that tier can add more executions themselves. For most small teams running customer-facing automations, Pro is the plan that makes sense.

Business: $800/month (annual) or $960 (monthly), self-hosted

This one surprises people: Business is not a cloud plan. You run it on your own infrastructure; a version hosted by n8n is only on a waitlist so far. n8n now pitches it at companies with fewer than 100 employees. It adds SSO (SAML and LDAP), separate environments, Git-based version control, queue mode for scaling and six shared projects, with 40,000 executions included. Beyond that, n8n sells overage in buckets of 300,000 executions, priced at €4,000 each (n8n quotes overage in euros), and invoices it 45 days after it happens.

Enterprise: custom

Enterprise can run in n8n's cloud or on your own servers, with 200+ concurrent executions, longer log retention, an SLA and dedicated support. n8n does not publish a price. Since the August 2025 pricing change, it is quoted based on execution volume.

What happens when you hit your execution limit

This is the question we wish more people asked before choosing a plan.

On Starter and Pro , there is no grace period. According to n8n's help center, executions over the limit are not queued. They fail immediately with the error "Execution limit reached. Consider upgrading your plan." Your options are to wait for the reset on the first of the calendar month, upgrade (which applies instantly), or use a one-time courtesy reset that n8n grants once per customer on the Trial, Starter and smaller Pro tiers.

For a lead form or an order workflow, a hard stop in the middle of the month means lost leads or unprocessed orders, and you may not notice for days. If your volume is anywhere near the limit, size up. A Pro plan is cheaper than a week of missed orders.

On Business , the behavior is different. n8n's pricing FAQ says workflows keep running when you go over, sales gets in touch around 80% usage, and any overage is invoiced later.

AI credits: two different things with similar names

n8n now has two kinds of AI credits, and they are easy to mix up.

• Assistant credits pay for n8n's own AI helpers: the AI workflow builder and "Ask AI" inside the editor. Starter includes 1,600 a month and Pro 4,000 or 9,600, depending on the tier. Included credits reset on the 1st of each month and don't roll over. Since October 2026, the instance owner can also buy extra credits, which carry over for up to 12 months. As a rough guide from n8n, a quick question uses 10–20 credits, a simple workflow built from one prompt 50–100, and a larger build or long debugging session 300–600. Running workflows never uses Assistant credits, and self-hosted n8n doesn't use them at all: there, the Assistant runs on your own AI provider account.
• Gateway credits are newer and separate. On Cloud Starter and Pro, they let your workflows call models like OpenAI or Anthropic through n8n without adding your own API key, and they are billed per request.

You don't have to use gateway credits. Any AI node can use your own API key instead, in which case the model provider bills you directly. For client builds, we almost always use the client's own keys, so model costs show up on one bill the client already understands.

Is n8n free?

The software is free if you host it yourself. The Community Edition has no execution cap, no user cap and no workflow cap. What you give up compared with paid plans are the team and governance features: projects and sharing, SSO, environments, Git version control, external secrets, log streaming and multi-main scaling.

Worth knowing: if you register your Community Edition with an email address, n8n sends a free license key that unlocks a few extras, including folders, debugging past executions in the editor, and custom execution data. It takes two minutes, and most self-hosters never do it.

There is no free n8n Cloud plan. There is a 14-day Cloud trial with most Pro features, 1,000 executions, 5 concurrent runs, a 3-minute limit per run and 800 Assistant credits, a one-time allowance that can't be topped up during the trial. No credit card is required.

The licensing detail agencies and SaaS founders miss

n8n is not open source in the strict sense. It is "fair-code," released under n8n's Sustainable Use License. For internal business use, that makes no practical difference. For agencies and product builders, it matters a lot. n8n's help center spells it out:

• Helping a client set up and run their own n8n instance needs no commercial license from you.
• Hosting and managing clients' workflows and credentials inside your instance requires an Enterprise license.
• Embedding n8n in your product so your customers build or run workflows requires an Embed license.

This is why we set up n8n in each client's own account rather than running everyone on one shared server. It is cleaner for security, and it keeps the licensing simple.

What self-hosting n8n really costs in 2026

Most articles say self-hosting costs "$5 a month." That was roughly true in 2025. In June 2026, Hetzner, the favorite budget host for n8n, raised cloud prices across its range, and several popular guides still quote the old numbers. Here is where common options stand now.

What a small n8n server costs in 2026

Before backups and your time

How to read this table.

Hetzner bills in euros; prices are for Germany and Finland after its 15 June 2026 price change, excluding VAT, with rough dollar equivalents. Add roughly 20–30% for backups, and budget an hour or two a month for updates if nothing breaks.

Then add the things that don't show up on the server invoice:

• Backups. DigitalOcean charges 20% of the droplet price for weekly backups and 30% for daily. Budget something similar wherever you host.
• A real database. n8n starts on SQLite. For anything in production, use Postgres. It can live on the same server for small setups.
• Scaling. If you ever need queue mode for high volume, you add Redis and worker processes. That is a different cost bracket, typically several servers instead of one.
• Your time. Updates, SSL, monitoring and the occasional 2 a.m. surprise. This is the cost people underestimate.

A realistic small production setup in 2026 lands around $8–14 a month in hosting, plus an hour or two of maintenance each month if nothing breaks.

What we've learned keeping a self-hosted n8n instance alive

Three things from a real client system, a multilingual customer support pipeline built on self-hosted n8n with Shopify, Airtable and OpenAI:

1. Disk fills up quietly. Execution logs from AI steps plus daily database backups were adding about 1 GB a day. Nothing warns you until the disk is nearly full. Set execution data pruning on day one and watch disk usage.
2. "Active" doesn't always mean working. An email (IMAP) trigger dropped its connection during a forced reconnect while n8n still showed the workflow as active. We only caught it because incoming emails stopped being processed. Any workflow that listens for events needs an outside check, not just the green toggle.
3. Third-party APIs move under you. The same system was still pointed at an old Shopify API version that Shopify has since retired. Self-hosting means you own that upkeep, not n8n.

None of this is a reason to avoid self-hosting. It is a reason to count maintenance as part of the price.

n8n Cloud vs self-hosted: which should you choose?

Our rule of thumb for clients:

• Choose Cloud Starter or Pro if nobody on your team wants to manage a server, your volume fits comfortably under the plan limit, and you are happy with your data on n8n's EU infrastructure.
• Self-host the Community Edition if you have high or unpredictable volume, need data to stay on your own infrastructure, or run many frequently scheduled workflows. Budget for maintenance or a support retainer.
• Look at Business when you need SSO, Git-based deployments or separate staging and production environments, and you already self-host. If you are a startup with fewer than 20 employees and under €5M in funding, n8n's startup plan takes 50% off Business.

A quick way to decide on cost alone: if your monthly executions would push you past Pro's 10,000, the self-hosted Community Edition becomes very hard to beat on price, even after you pay someone to maintain it.

A worked example: estimating your n8n bill

Say you run three workflows:

• A website lead form workflow that sends leads to your CRM and Slack, about 600 submissions a month (webhook): 600 executions .
• A Shopify order workflow with 25 steps, about 1,200 orders a month (webhook): 1,200 executions , not 30,000.
• An hourly inventory sync (Schedule trigger): 24 × 30 = 720 executions .

That is 2,520 executions a month, just over Starter's 2,500. On Starter, the last day or two of the month would fail. The sensible choices are Pro at $50 a month, or moving the inventory sync to every two hours (360 executions), which brings the total to 2,160 and fits the $20 Starter plan with a little headroom. Small scheduling decisions like that often matter more than the plan you pick.

Run the same numbers through a per-step tool and the 25-step order workflow alone becomes tens of thousands of billable actions a month. That is the case for n8n in one line.

Discounts worth knowing about

• Startup plan: 50% off Business ($400 a month billed annually, €333 in euros) for companies with fewer than 20 employees and less than €5M in funding. Self-hosted only.
• Non-profits: a 30% discount code on all Cloud plans for verified non-profits, NGOs and charities. You request it through n8n support.
• Annual billing: about 17% off any paid plan.

Frequently asked questions

How much does n8n cost per month?

For US customers, n8n Cloud starts at $20 a month billed annually ($24 month to month) for 2,500 executions. Pro is $50 ($60 monthly) for 10,000 executions. Outside the US, UK and Brazil you pay the same numbers in euros. The self-hosted Community Edition is free, and you pay only for your server.

Is n8n really free?

The self-hosted Community Edition is free to use with no execution limits. You still pay for hosting, and you are responsible for updates, backups and security. There is no free Cloud plan, only a 14-day trial with 1,000 executions.

What counts as an execution in n8n?

One complete production run of a workflow, regardless of how many steps it has. Manual test runs, sub-workflows, error workflows and polls that find nothing don't count.

What happens if I go over my n8n execution limit?

On Cloud Starter and Pro, new executions fail with an "Execution limit reached" error until the monthly reset or an upgrade. n8n grants one courtesy reset per customer on the smaller plans. On Business, workflows keep running and overage is billed in buckets of 300,000 executions.

Is n8n cheaper than Zapier?

For multi-step workflows, almost always, because Zapier bills every action step as a task while n8n bills a whole run as one execution. For a couple of simple two-step automations, Zapier's lower tiers can cost about the same and take less setup.

Can I use n8n commercially?

Yes, for your own business. If you want to host clients' workflows on your own instance, or embed n8n in a product you sell, you need an Enterprise or Embed license from n8n.

• n8n plan check: Not sure which n8n plan you need?

Send us the workflows you run or want to build and roughly how often they fire. We'll estimate your monthly executions, tell you whether Cloud or self-hosting is cheaper for you, and build it in your own account with monitoring and handover docs.

Sources: n8n, Plans and pricing and Startup plan; n8n docs, Understand executions and Assistant credits; n8n community, Assistant credits top-up announcement; n8n help center, Can you reset my executions?, Can I use your license for my use case? and Non-profit pricing; Hetzner, Price adjustment; DigitalOcean Droplet pricing; AWS Lightsail pricing; Zapier pricing.

Written by the Amplence team. Plan prices, execution rules and license terms are as n8n published them on its pricing page, docs and help center in September 2026 and rechecked on October 19, 2026. Prices are shown in US dollars, which is what n8n charges US billing addresses; euro prices are the same figures except Business (€667 annually, €800 monthly). Server prices are list prices from Hetzner, DigitalOcean and AWS in September 2026. The self-hosting lessons come from a support system we built and have supported on self-hosted n8n. Confirm current prices on n8n's pricing page before you buy.

Need help with this? Amplence builds production AI automations for small businesses: n8n automation services.

Every agent proposal you'll read has the same sentence in it somewhere: "anything it can't handle is escalated to a human." It sounds like a safety feature. In most builds it's a blank. Nobody has decided who the human is, how quickly you need them to appear, or what they'll be looking at when they do. So the handoff, which is where your agent meets your business, ends up the least designed part of the system.

That matters more than the model does. A support agent resolving 65% of contacts still hands you 35 out of every hundred. If each of those arrives as a bare forward with no context, you've built a machine for generating work. If they arrive sorted, explained and half done, you've built the thing you were promised.

The guardrails article covers what your agent may do without asking you. This one covers what happens at the boundary: when it should stop, how fast you need a person there, what that person sees, and the one failure mode that quietly undoes all of it.

Quick answer

A handoff is three decisions, not one.

A handoff is three decisions, not one: when your agent stops, how fast a person has to arrive, and what that person sees. Write the triggers in code, not in the prompt. Make the handoff asynchronous unless the customer is literally waiting, because a synchronous one costs you four people on standby for the work one person does in a day. Send every handoff as a packet, never a forward. And watch for approval fatigue: a gate that fires forty times a day on a cheap action loses you money the moment your reviewer misses 2% of the mistakes.

• 4 vs 1: People at peak, synchronous vs asynchronous

• $645/mo: Cost of a gate that fires 40 times a day

• 20 to 1: Gate firings per real catch at 95%

"Escalate to a human" is three decisions, not one

The phrase hides three separate choices, and each one has a wrong default you'll get unless you decide otherwise.

1

When

• The trigger: Which conditions stop the agent. The wrong default is "when it isn't sure", which is a feeling, not a rule.

Decide it in code, and log the reason so you can count it

2

How fast

• The channel: Whether a person must be there while the customer waits, or can pick it up in an hour. The wrong default is "immediately", which quietly sets your staffing.

Asynchronous unless someone is waiting

3

What they see

• The packet: What lands in front of your person: the original message, what the agent understood, what it did, what it wants. The wrong default is a forwarded email.

A data contract, not a forward

AWS's guidance for running agents puts it in a line worth keeping: a handoff is a data contract before it is a workflow step. The same guidance separates two kinds of escalation you'll see muddled together. Routing a task to another agent because it needs a capability the first one lacks is a routing decision. Sending it to a person because confidence dropped, the stakes are high or the retry budget is spent is a judgement decision. Mix them, in AWS's words, and you either send too many routine tasks to humans, creating fatigue and bottlenecks, or send high-stakes decisions through automated routing. Keep them apart, and make sure you can see each one fire.

When your agent should stop

Five triggers cover almost every production agent we've built or reviewed. The order matters, because the first one has to work even when the other four fail.

1. The customer asksDoes "I want a person" always work?Yes, first time, no negotiation. An agent that argues with a request for a human has already lost you the customer, and in the EU an agent that hides what it is has a legal problem as well.
2. Confidence dropsBelow what threshold, on which classification?Language, intent and account matching each get their own threshold, set from your test set rather than guessed. Below it, the item routes to you with the original message and the score attached.
3. A gated actionWhich actions need a person by the arithmetic?The permission ladder from the guardrails article. Anything above its threshold pauses and waits, and the agent never gets to decide that this case is the exception.
4. The budget is spentHow many retries or turns before it gives up?A turn cap or a retry limit, in code. OpenAI's guide names exceeding failure thresholds as one of its two triggers for human intervention, and AWS calls it the retry budget. Both mean stop looping.
5. A signal the model shouldn't judgeWhich cases go straight to a person before any reply is drafted?Legal language, a chargeback threat, a VIP account, a complaint spanning several issues. A separate step scores these before the reply model runs, so the model that writes never decides whether it should be writing.

Notice what isn't on the list. "The agent feels uncertain" is not a trigger, because the agent's feeling is a number you can't inspect. Every one of the five is a condition you can write down, test and count.

Synchronous or asynchronous: the decision that sets your staffing

Here's the decision you'll make by accident if you don't make it on purpose. If a person has to be available while the customer waits, your handoff is synchronous. You then staff for the busiest hour, the way a contact centre does. If the person can pick it up within the hour and the customer is told so, it's asynchronous, and you staff for the total hours of work. The gap between those two is not small.

Take CollageDepot's published volume: 5,000 emails a month at 65% auto-resolution. That's 1,750 handoffs a month, about 80 a working day, and around 20 in the peak hour. Each one takes a person six minutes, the same figure as the cost article. Run those numbers through the standard contact-centre staffing formula and you get this.

The same 80 handoffs, staffed four ways

Erlang C, peak hour

How to read this table.

The work is identical in every row: 80 handoffs, six minutes each, eight hours of a person's time. What changes is how many people you need free at once. A synchronous target needs four people on standby to cover a peak that keeps them busy half the time. An asynchronous one needs one person's day, and they can do it between other things.

That's why you should design handoffs asynchronous by default, and it's why the frameworks are built for it. When an agent pauses for a human in LangGraph, the interrupted run holds nothing but its saved state and, in LangChain's own words, can be resumed many months later, on a different machine. OpenAI's tooling does the same: a paused run returns its state to your application and resumes whenever the answer arrives. The agent doesn't need the human to be there. Your customer sometimes does, and only then should you pay for synchronous.

What the customer hears while they wait

Asynchronous only works if you tell the customer, and tell them well. A silent handoff, where the automation stops and nothing happens until a person gets to it, is the worst of both designs, and you'll see it in most first versions. The customer gets the delay of asynchronous with the expectations of synchronous.

So the handoff itself sends a message, in the same channel, within seconds, and it says three things. A person is now handling this. Here's when you'll hear back, as a time you can actually keep. And, where it applies, what you were talking to until now was an AI. Since 2 August 2026, Article 50 of the EU AI Act requires any AI system that interacts directly with people to be designed so they're informed they're dealing with AI, unless it's obvious. If your customers are in Europe, the handoff message is the natural place for that disclosure, and your builder should know the rule exists.

One more rule. The customer should never have to repeat themselves. If the person picking up the handoff has to ask for the order number the agent already extracted, your packet was wrong, and the customer will tell you so in the survey.

A handoff is not the agent giving up. It's the agent finishing the part it's good at, which is reading, sorting, looking things up and drafting, and handing you the part it isn't, which is deciding. Design it that way and your person starts on step four instead of step one.

Approval fatigue: the gate that trains people to click

The guardrails article set every approval gate by one line of arithmetic: gate an action when its error rate times the cost of a mistake beats the cost of a two-minute review. That line carried a silent assumption, that your reviewer catches the mistake. Here's how thin that assumption is, and what it costs you.

A gate that fires 40 times a day costs you 40 reviews, $29 a day, about $645 a month. Now put it on a $15 goodwill credit that the agent gets right 95% of the time. If your reviewer catches every mistake, the gate saves $30 a day, so it just pays. If they miss more than 2% of the mistakes, it's a net loss. On a $40 refund the same gate survives until the reviewer misses 63% of the mistakes, which is why you put gates on expensive actions and not cheap ones. On an order-status reply the gate never paid at all.

The reason reviewers miss mistakes is well documented, just not in our field. A 95%-accurate action fires its gate 20 times for every real catch, so 95% of what you're asking your reviewer to look at needs no action. In hospitals, the Joint Commission estimated that between 85 and 99 percent of alarm signals do not require clinical intervention, and named the result alarm fatigue. Staff become desensitised, turn alarms down, turn them off, or set them outside safe limits. A systematic review of 74 studies on automation bias found the same pattern wherever people supervise automation. Its list of what makes it worse reads like a description of a badly designed approval queue: workload, task complexity and time pressure.

• Gate what the arithmetic justifies, sample the rest. A gate that fires twenty times per real catch is an alarm, not a control. Move cheap actions to a weekly sample and keep your gates for money and the irreversible.
• Show the reason and the confidence, not just the request. The automation-bias review found that attaching confidence to the output, and giving information rather than a bare recommendation, both reduce over-reliance. A gate that says "approve?" gets clicked. One that says "refund $40, order delivered 3 days ago, confidence 61%" gets read.
• Name the reviewer. Accountability was the other mitigator the review identified. A queue everyone owns is a queue nobody reads.
• Count approvals per hour. If one person approved 60 gates in an hour, they reviewed none of them. Put that number on your dashboard next to the resolution rate.

What your person sees when they arrive

Everything above decides whether the handoff happens and how fast. This decides whether it's useful. AWS specifies the minimum context package as the task description, the work completed, the memory artefacts and the reason for the handoff, and recommends versioning the schema so a receiver can reject a malformed one. Here's the version we hand over, and the one you should ask for. Every field earns its place. It's the same shape as the partner review in our finance deal-flow concept, which presents the company brief, the risks, the missing information and the confidence indicators to the reviewer in one place.

• The customer's original message, verbatim, with any attachments. Not the agent's summary of it.
• What the agent understood: language, intent, the account it matched, each with its confidence score.
• What it already did: every lookup and tool call, with the result. The order record it pulled, the policy it checked.
• What it proposes, and why, in two sentences. A drafted reply or a recommended action you can accept, edit or reject.
• The one decision it needs. Not "please review", but "is this customer entitled to the refund under the 30-day policy?"
• Whether the proposed action is reversible, and what it costs if it's wrong.
• The reason it handed off, as a code from the trigger list, so you can count them later.
• The clock: when the customer was told to expect a reply, and how long the item has been waiting.

The test is simple. Someone who has never seen this customer should be able to act on the packet in under six minutes without opening another system. If they have to go and look up something the agent already knew, the packet failed.

An escalation queue with the context already loaded

CollageDepot is the shape of this in production. Every inbound email is scored for sentiment, urgency and complexity before any reply is drafted. The ones that cross a threshold go straight to a person: a chargeback threat, a multi-issue complaint with legal language, a VIP account with a high-value order problem. The classification data and the live Shopify order context arrive already attached, so nobody opens the ticket cold.

The queue lives in a dashboard the support team runs themselves. They see incoming volume, resolution rates by category and language, sentiment trends and the live escalation queue. They can override, reassign or flag any ticket, and move the escalation thresholds without touching the pipeline. That last part is the piece most builds forget: the thresholds that decide what reaches a human belong to the people who receive it, not to the developer.

When the handoff is the product

Sometimes the handoff isn't the exception path. It's the whole point. The Greenfield Systems concept is an intake agent for a precision-instrumentation manufacturer whose enquiries mention sub-picosecond timing, trigger channels and calibration in a single paragraph. The agent doesn't answer them. It reads the request and separates it into application, constraint, tolerance, service need, product family and review priority. Then it suggests the most likely product path with a confidence and a reason, flags what an engineer should verify, and hands over. In the concept's design, 85% of outputs are marked for human review. That's the success condition, not a failure rate: the engineer starts from a structured note instead of a raw email. The RFQ automation guide works the same pattern through a manufacturer's whole quoting process.

That's the lesson for any process where the final decision genuinely belongs to your expert. If you're building for one, don't measure the agent by how often it avoids the human. Measure it by how much of the human's work it did before the handoff.

Every handoff is a lesson, if you record why

The reason code in the packet is the most valuable field in your logs. Count them weekly, and you'll find that the most common reason for handing off is your next improvement. It's usually not the model. It's a missing policy document, a product the agent can't match, an intent it's never seen. The evaluation article treats escalation rate over time as the early warning that the world moved and your agent didn't. The reason codes tell you which way it moved.

Two operational rules close the loop. Every handoff needs a timeout and an owner, because, again in AWS's words, a deadlock that requires a human to notice is a deadlock that lasts until someone notices. An item waiting past its promised time should re-route or page someone, automatically. And every override, where your person changed what the agent proposed, is a labelled training example. A month of them is a better test set than anything you wrote before launch.

What to require from whoever builds it

Whether that's us or anyone else, this is what you should see written down before the agent goes live.

• The five triggers written down as conditions, each with its threshold and each logged with a reason code when it fires.
• "I want a person" honoured on the first request, in every language the agent speaks.
• A decision, per trigger, on synchronous or asynchronous, with the staffing arithmetic for whichever you chose.
• The customer message the handoff sends, with a reply time you can keep and, for EU customers, the AI disclosure.
• The handoff packet, all eight fields, tested by someone who has never seen the customer.
• Gates only where the guardrails arithmetic puts them, with approvals per hour on the dashboard.
• Thresholds your team can adjust without a developer.
• A timeout and a named owner on every queue, with automatic re-routing when the promised time passes.
• Weekly reason-code counts and a monthly review of overrides as training data.

Frequently Asked Questions

What's a reasonable escalation rate for an AI agent?

It depends on what you built the agent for. A support agent handing off 35% of contacts with full context is doing well. An intake agent that hands off 85% of enquiries as structured notes may be doing exactly its job. Judge the rate against the work done before the handoff, and watch the trend rather than the level.

Should the customer know they've been handed to a human?

Yes, immediately, in the same channel, with a reply time you can keep. In the EU, Article 50 of the AI Act also requires that people interacting with an AI system are informed of it, so the handoff message is where both disclosures naturally sit.

How fast does a human need to respond to an escalation?

Only as fast as the customer is actually waiting. On live chat or a phone call, seconds. On email or a form, the same day is usually fine if you told the customer. The staffing table above shows what each promise costs you, so make the promise you can afford.

Isn't a high approval rate a sign the agent is working well?

It's a sign of one of two things: the agent is right, or your reviewer has stopped reading. Count approvals per hour per reviewer. If a person approved sixty items in an hour, treat that queue as unreviewed and check a sample yourself.

What should we log about each handoff?

The trigger and its reason code, the confidence scores, what the agent did before stopping, what it proposed, how long the item waited, who picked it up, and what they changed. That last field is the one people skip and the one that improves your agent most, so don't let anyone talk you out of it.

• Agent review: Want the handoff designed before the agent is built?

We'll write the five triggers, run the staffing arithmetic on your volume, and hand you the packet spec and the customer message, whether we build the agent or not.

Sources: AWS Well-Architected Agentic AI Lens, AGENTOPS01-BP02; OpenAI, A practical guide to building agents; LangChain, Making it easier to build human-in-the-loop agents with interrupt (14 December 2024); Goddard, Roudsari and Wyatt, Automation bias: a systematic review, JAMIA 2012; The Joint Commission, Sentinel Event Alert 50: Medical device alarm safety in hospitals (8 April 2013); EU AI Act, Article 50.

Written by the Amplence team. The staffing figures come from a re-runnable model using the standard Erlang C contact-centre formula on CollageDepot's published volume, with six minutes per handoff and a peak hour at twice the daily average. They are worked examples, not measurements from the CollageDepot team. The approval-fatigue figures use the same $22 loaded hour and two-minute review as the guardrails article. CollageDepot details are as published in the case study; Greenfield Systems is a concept design. Nothing here is legal advice; the Article 50 point is a pointer to the regulation, not an interpretation of it for your case.

Need help with this? Amplence builds production AI automations for small businesses: AI agent development.

Quick answer

RAG fixes what the model doesn’t know. Fine-tuning fixes how it behaves.

RAG fixes what the model doesn't know. Fine-tuning fixes how the model behaves. Almost every founder asking this question has a knowledge problem, so the answer is RAG, and often not even that. Run four one-hour blocks against twenty real cases and your failure modes will tell you which one you need. Cost will not decide it. At MVP scale the two land within a few dollars a month of each other.

• 19%: Fine-tuning accuracy updating facts

• 4 hours: To a decision you can defend

• 5 of 7: Failure points fine-tuning won’t fix

Teams lose weeks to this decision. They read that fine-tuning makes a model "learn your business", budget for it, and discover four months later that the model still can't answer a question about a policy written last Tuesday.

That's not a tooling failure. It's a category error. The two techniques solve different problems, and only one of them is about knowledge.

We hear this question on roughly half our scoping calls, usually phrased as "we're deciding between RAG and fine-tuning." Almost every time, the honest response is that they haven't got a decision yet. They've got twenty test cases they haven't written and a prompt nobody has taken seriously. That sounds dismissive. It isn't. It's the fastest path to shipping, and it costs nothing.

This guide uses published API rates checked on 25 August 2026, peer-reviewed results on what fine-tuning can and can't teach, and a protocol you can finish between lunch and dinner. If your product needs retrieval systems built from your own documents, the same protocol is how we scope it.

What Do RAG and Fine-Tuning Actually Do?

Strip away the marketing and there are two different interventions.

1

• RAG: Retrieval-augmented generation

Before answering, your system searches your documents and pastes the relevant passages into the prompt. The model reads them like a brief.

Changes what the model

knows

in this request.

2

• Fine-tuning: Supervised training on your examples

You train a copy of the model on hundreds or thousands of input-output pairs until it reliably produces your shape of answer.

Changes how the model

behaves

in every request.

That distinction does the work. A model with your handbook in its context can quote your refund window. A model fine-tuned on your handbook has, at best, absorbed a statistical impression of it.

Here's the version we use on calls. Fine-tuning is like sending someone on a training course. They come back with better habits, a house style, and a feel for how you do things. They don't come back knowing what's in the email you sent this morning. RAG is handing them the email before they answer. You can do both, and most mature products eventually do, but if what you actually need is for them to read today's email, no amount of training will substitute.

The other thing worth knowing early: your data doesn't move. Fine-tuning bakes it into a model checkpoint, so a policy change means retraining and re-evaluating. Retrieval reads the current document at query time, which means correcting a mistake is an edit, not a project. For a product still finding its shape, that difference compounds fast.

Say it out loud before you spend anything.

"The model doesn't know X" is a RAG sentence. "The model knows X but keeps answering wrong" is a fine-tuning sentence. Most teams say the first and buy the second.

RAG vs Fine-Tuning: The Honest Comparison

Here is the comparison with the rows that usually get left out.

RAG and fine-tuning, side by side

10 decision factors

That last row surprises people. Anthropic's published pricing lists no fine-tuning tier for Claude at all. If your stack is on Claude, fine-tuning isn't a decision you get to make without changing provider.

What Does Each One Cost in 2026?

Published list rates, read from each vendor's own pricing page on 25 August 2026. Recheck before you budget.

What fine-tuning adds to every token

Verified 25 Aug 2026

Sources: OpenAI API pricing and Anthropic pricing, both checked 25 August 2026. All figures are per million tokens. Embeddings for retrieval run $0.02 per million tokens on text-embedding-3-small.

Read the premium column twice. Fine-tuning does not charge you once. It charges you 1.5x to 2x on every token for the life of the product , and it applies to output tokens, which already cost four times what input costs. A chatty product pays that tax harder than a terse one.

RAG's cost works the other way. It adds input tokens per call, and input is the cheap side. It is also the side that caching discounts: OpenAI prices cached input at 75% off on the gpt-4.1 family, and Anthropic prices a cache hit at 0.1x base input.

A worked example at 20,000 tasks a month

Assume a support-answer feature on gpt-4.1-mini. Each task sends 800 prompt tokens and returns 300. RAG adds 2,500 retrieved tokens per call.

Worked example: 20,000 tasks a month

Illustrative

How to read this table.

These are Amplence planning calculations from published rates, not a quote. The headline is the one nobody prints: at MVP scale RAG and fine-tuning cost within four dollars a month of each other. Ten times the volume keeps the same ratio.

Cost is not going to decide this for you.

What does diverge is the retraining bill. Every behavior change means another training run and another evaluation pass, and when the provider retires that model version you pay it again. RAG's equivalent is re-indexing one document, which costs cents. Our breakdown of what an AI MVP actually costs to run separates these ongoing ledgers properly.

What the Research Says About Teaching a Model Facts

This is where the decision usually gets made, and it isn't close.

What the published research found

4 sources traced

Sources: Fine-Tuning or Retrieval? Comparing Knowledge Injection in LLMs, FineTuneBench, RAG vs Fine-tuning: Pipelines, Tradeoffs, and a Case Study on Agriculture, Seven Failure Points When Engineering a Retrieval Augmented Generation System.

The FineTuneBench number is the one to keep. Those researchers tested the actual commercial APIs a founder would reach for, and found that fine-tuning updated existing knowledge correctly 19% of the time . Their Gemini results were worse: the paper concludes those APIs were unable to learn new knowledge at all.

Fine-tuning is not a memory. Stop treating it like one.

The Afternoon Protocol: Four Hours to a Decision

You do not need a spike, a vendor call, or a week. You need twenty real cases and four hours. Block them out, in this order.

1. Build the evaluation setTwenty real cases, with the answer you'd acceptPull them from actual user questions, support tickets, or your own backlog. No synthetic examples. This hour decides everything after it, so don't shorten it.
2. Baseline with a plain promptNo retrieval, no training, just a careful promptSend all twenty through and score each pass or fail. Then write one sentence per failure describing what went wrong. Those sentences are the raw material for hour four.
3. Add naive retrieval by handPaste the relevant document straight into the promptNo vector database, no chunking strategy, no infrastructure. You're testing whether the information helps at all, not building a pipeline.
4. Classify the failuresSort every failure sentence into the seven buckets belowThe shape of the pile is your answer. Count the rows, don't weigh the arguments.

Hour four is the whole point. You're not asking "did it get better". You're asking "what kind of wrong was it", because the kind of wrong maps directly onto the fix.

Why twenty cases? Because it's enough to see a pattern and few enough that you'll actually finish. Five hides the pattern. A hundred turns hour one into a week and the project dies there. Twenty is the number we use internally, and we've never needed more to make this particular call.

One rule for hour three: don't build anything. The temptation to stand up a vector database before you know whether retrieval helps is strong, and it's where most of these afternoons turn into fortnights. Copy and paste the document. If the answers get better with the information sitting in the prompt, retrieval is worth engineering. If they don't, you've saved yourself a sprint and learned something more valuable than any benchmark would have told you. Our step-by-step guide to building an AI MVP puts this same test before the architecture decision for the same reason.

What Your Failure Modes Are Telling You

The seven failure points below come from Barnett et al.'s study of three production RAG systems. The right-hand column is ours.

Seven failure points, and what each one actually needs

2 of 7 are fine-tuning

Count your pile. Five of the seven are not fine-tuning problems. If most of your failures land in rows one to four or row seven, buying a training run will change nothing except your monthly bill.

If your pile is genuinely stacked in rows five and six, you have found the real case for fine-tuning, and you should read on.

When Do You Actually Need Fine-Tuning?

There is a real case. It is narrower than the marketing, and it looks like this.

• You need a rigid output shape on every call. A specific JSON structure, a clinical note format, a legal clause template. You have tried prompting and it holds ninety percent of the time, which is not enough.
• You need a voice you cannot describe. Tone that your editors recognize instantly but nobody can write down as an instruction. Examples teach this better than adjectives do.
• You are compressing a long prompt. If your system prompt has grown to three thousand tokens of rules, fine-tuning can bake them in and cut latency and cost per call.
• You need a small model to punch above its weight. Fine-tuning a nano-class model on a narrow task can match a much larger model at a fraction of the price.
• Your task is classification or extraction, not conversation. Fixed label sets and fixed fields are exactly what supervised training is for.

Notice what's absent from that list. None of it is about knowledge. Every item is about form, and form is what training teaches well.

You also need the data. A few hundred clean, consistent examples minimum, and consistency matters more than volume. Contradictory examples teach a model to be inconsistent, reliably. We've seen a team assemble twelve hundred examples from three different authors who each had their own idea of a good answer, then wonder why the fine-tuned model couldn't pick a lane. It had learned exactly what it was shown.

There's a timing argument too, and it cuts against fine-tuning early. Base models keep improving, and every improvement is free if you're prompting and expensive if you've trained. A fine-tune pins you to one checkpoint. When something better ships six months later, you don't just switch: you rebuild your training set, retrain, and re-evaluate before you can take the upgrade. For an MVP that's still changing weekly, that's a bad trade. For a stable, narrow, high-volume task, it's often worth it.

When Is Neither One Your Problem?

The unprofitable part of the answer, and the one we give most often on scoping calls.

• Your corpus is small enough to just paste in. Work out the break-even. RAG adds roughly 2,500 retrieved tokens per call at $0.40 per million, so about $0.001 per call. Cached input on the same model costs $0.10 per million. Divide and you get 10,000 tokens : if your entire knowledge base fits under that, caching the whole thing in the prompt is cheaper and simpler than any retrieval pipeline you could build. Claude 4.6 and later carry a full million-token context at standard rates, so the ceiling is generous.
• Your documents are a mess. Retrieval over inconsistent, duplicated, undated files returns inconsistent, duplicated, undated answers. Fix the corpus first. This is unglamorous and it is usually the highest-return work available.
• Your prompt has never been seriously written. We have watched a careful prompt with four worked examples close a gap that a team had already budgeted a fine-tuning project to fix.
• The task needs reasoning you haven't got. If the model cannot follow the logic, more context and more training both fail. Change the model or decompose the task.

That last one is worth money to hear early. Our guide to choosing an AI MVP tech stack covers when a model swap beats an architecture change.

Can You Use Both?

Yes, and for mature products it's often the right end state. The Microsoft agriculture study found the gains were cumulative: fine-tuning contributed over six points of accuracy, retrieval added five more on top.

Read those numbers carefully before you plan around them. Six points and five points are real improvements, and they are not the order of magnitude that the word "learn your business" suggests. If your evaluation set is failing half the time, an eleven-point combined lift doesn't get you to a shippable product. Something more basic is wrong, and you'll find it in hour four.

The sequencing matters too.

• Get retrieval right first. Fine-tuning on top of a retrieval layer that returns the wrong passages just teaches the model to be confidently wrong in your house style.
• Fine-tune the behavior, not the facts. Train on how to use retrieved context well: citing it, admitting when it is thin, refusing when it is absent.
• Keep the evaluation set from hour one. It is the only thing that will tell you whether the second intervention helped or quietly undid the first.
• Budget for both retraining and re-indexing. They are separate ongoing costs on separate schedules.

When we built Find The Plan, a plan-comparison MVP, retrieval was the whole architecture: every recommendation had to show the evidence behind it and hand off to a licensed advisor. A fine-tuned model could have produced fluent recommendations. It could not have shown its sources, and in that domain a recommendation without sources is not a product.

Failure mode review

Not sure which pile your failures land in?

Send us twenty of your real cases. We'll run the protocol, classify the failure modes, and tell you which intervention your product actually needs, including when the answer is a better prompt.

Which Should You Pick?

The verdict, by what you are building.

A document question-answering MVP

RAG, without hesitation. Your users will ask about things written after the model's training cut-off, they will expect citations, and access control has to be enforceable per user. All three are retrieval properties and none of them survive fine-tuning.

An internal tool over a small, stable handbook

Probably neither. Run the break-even above. Under ten thousand tokens, cache the corpus in the prompt and ship this week. You can add retrieval later when the corpus grows, and that migration is easy.

A structured extraction or classification feature

Fine-tuning is a genuine contender here, and it may be the cheaper answer because it lets you drop to a smaller model. Baseline with a prompt first, because current models are better at this than they were when the fine-tuning advice was written.

A support or operations agent

Retrieval first, then behavior. Get the agent grounded in real records, add permissions and approval points, and only then consider training the response style. Our AI agent development work sequences it that way for a reason: an agent that acts on a wrong retrieval is worse than one that answers slowly.

Frequently Asked Questions

Is RAG always cheaper than fine-tuning?

No, and the belief that it is causes bad decisions. At 20,000 tasks a month on gpt-4.1-mini the two land within four dollars of each other. Fine-tuning is more expensive over time because of retraining, not because of the per-token premium. Pick on capability and let the cost fall where it falls.

How much data do I need to fine-tune?

A few hundred consistent examples is a realistic floor for a narrow task. Consistency beats volume: fifty examples that agree with each other teach more than five hundred that contradict. If you cannot produce that set, you have your answer already.

Can fine-tuning teach a model my company's information?

Poorly, and the published evidence is blunt about it. FineTuneBench measured commercial fine-tuning APIs at 37% accuracy for injecting new information and 19% for updating existing knowledge. Use retrieval for facts.

Do I still need RAG if the model has a million-token context window?

Sometimes not. If your whole corpus fits comfortably and you can cache it, skip retrieval. Beyond that, retrieval still wins on cost, on per-user access control, and on answer quality, because a focused passage beats a haystack.

What is RAFT, and do I need it?

Retrieval-augmented fine-tuning trains a model to work well with retrieved context, including ignoring irrelevant passages. It is a real technique and a poor first move. Get retrieval working, measure it, then consider it.

How long does a RAG pipeline take to build for an MVP?

A naive one that proves the value takes an afternoon. A production one with chunking, evaluation, monitoring, and access control is a two to four week piece of work. Do not confuse the two when you plan, because the first one is what the demo runs on and the second one is what your users get.

Written by Muneeb Ashraf, CEO at Amplence, and Zahra A., technical writer. API rates in this article were read from OpenAI's and Anthropic's own pricing pages on 25 August 2026 and change often, so recheck them before budgeting. Figures labelled as Amplence planning calculations are worked examples derived from those published rates on one task shape, not quotes or benchmarks. The research findings are linked to their primary sources and describe the models and datasets those studies tested, which may not resemble your workload.

Need help with this? Amplence builds production AI automations for small businesses: RAG development services.