DEV Community: 2pizza.team

How Much Does AI Automation Cost in 2026? Real Numbers

2pizza.team — Fri, 11 Sep 2026 13:00:09 +0000

TL;DR: simple two-app flow $500-1,500. Multi-step business process $1,000-3,000. Custom pipeline with AI and error handling $3,000-8,000. Full custom system replacing a manual back office $8,000-25,000. Running costs $50-200/month for most small businesses. The number that surprises people is not the build, it is the second year.

Every article with this title is useless in one of two ways. Either it hands you a range so wide it means nothing, or it is a soft pitch that stops right before the number and asks you to book a call. I have been on the buying side of that and it is infuriating, so here is the version I wish someone had written for me.

These are the bands we quote in, why a project lands in one band rather than another, and the running costs that never make it into the proposal. I run 2pizza.team, we have shipped automation systems for 80+ clients, and the numbers below are what we charge and what we see competitors charge. Where I am uncertain I say so.

Why the range is genuinely that wide

AI automation projects run from $500 to $50,000 and the spread is not vagueness. Connecting two apps with an if-this-then-that rule and building a system that runs a back office are both called automation, and they are not the same kind of work. One is configuration. The other is software engineering with a different label on it.

A useful test: if the whole thing breaks and nobody notices for a week, you are buying configuration. If the whole thing breaks and your operations stop by lunchtime, you are buying software, and software carries the cost of error handling, monitoring, and someone who can fix it. Most of the price difference between the bands is that second category.

The four things that actually move the number

Scope conversations go in circles until you name the variables. There are four, and in our experience they explain most of the variance between two quotes for what sounds like the same project.

1. How many systems have to talk to each other

Each integration is its own small project: read the API docs, handle authentication, map the fields, deal with the one endpoint that behaves differently from the rest, then test it against real data. Two systems is a day. Five systems is not two and a half days, because now you also own the question of what happens when system three is down and systems one and two have already committed. Integrations compound.

2. Whether the logic is rules or judgment

A rule is cheap: if the invoice total is over 5,000, route it to the finance lead. Judgment is expensive: read this supplier email and decide whether it is a delivery delay, a price change, or a complaint. Judgment means an AI layer, and an AI layer means prompt work, a test set, a fallback for when the model is unsure, and a way for a human to correct it. Budget roughly 30-50% on top of the equivalent rules-only build.

3. Volume and what failure costs

Fifty records a month and fifty thousand records a month are different systems. At low volume you can retry by hand. At high volume you need queuing, rate-limit handling, idempotency so a retry does not double-charge someone, and alerting that tells you before the client tells you. This is the single most common reason a quote comes back higher than expected.

4. How clean your data is

This is the one nobody budgets for. If your product names are inconsistent, your customer records are duplicated across two tools, or half your orders arrive as free text in a chat window, someone has to reconcile that before any automation can be trusted. We have seen data cleanup take longer than the automation itself. It is worth asking any agency directly how they price it, because plenty of them discover it mid-project and come back for more money.

Secondary drivers, smaller but real:

A dashboard or admin UI instead of no interface at all: add $1,000-3,000
Proper error handling and alerting: cheap to build in, expensive to retrofit
Compliance requirements, GDPR or the Australian Privacy Principles: add scoping time before any code
Number of edge cases that must be handled rather than escalated to a human
Whether you need the system documented well enough for someone else to maintain it

Price bands by project type

What a project costs to build, and more usefully, what you actually get for the money at each level.

$500-1,500: a single flow

Two or three steps between standard apps. Form submission creates a CRM record and sends a Slack message. New order triggers a supplier email. This is Make or Zapier configuration. It works, it is worth doing, and it will not survive a change in either app without someone looking at it. No error handling beyond the platform default.

$1,000-3,000: a business process

Five to ten steps, two or three integrations, real branching logic. Lead comes in, gets enriched, gets scored, routes to the right person, follows up if nobody touches it in 48 hours. This is the band most small businesses should start in, because it automates something that currently occupies a person rather than something that currently occupies a click.

$3,000-8,000: a pipeline you can rely on

Custom n8n or code, an AI layer doing classification or extraction, error handling, retries, alerting, and a place to see what happened. Invoice processing, document extraction, support triage, outbound systems. The difference from the band below is not features, it is that this one is built to be trusted with money or with customer-facing decisions.

$8,000-25,000: a system that replaces a back office

A custom application with a database, an interface people log into, and integrations out to everything else. Production ERPs, client portals, scheduling systems. You buy this when the off-the-shelf tools genuinely do not fit your process and you have checked, properly, that they do not.

Typical builds and their bands:

Simple two-app flow, standard connectors: $500-1,500
Multi-step process with logic and 2-3 integrations: $1,000-3,000
AI customer support with retrieval, classification and escalation: $2,500-6,000
Invoice processing with vision extraction, matching and ERP write-back: $4,000-8,000
Outbound sales system with enrichment, sequencing and qualification: $5,000-12,000
Custom production ERP or client portal: $8,000-25,000

Three builds and where they landed

Bands are abstract, so here are three systems we shipped and the shape of each. I am giving the band rather than the invoice, because what a specific client paid is theirs, not mine to publish.

An online store run by one warehouse worker

Simbago sells pet supplies. Orders flow in from WooCommerce, get picked and confirmed automatically, supplier reorders fire when stock hits a threshold, and a chatbot handles the bulk of support. One employee now runs what would normally take three or four people. Multiple integrations, an AI layer on support, real volume: this is a mid band build, the $3,000-8,000 shape.

A confectionery studio running on WhatsApp and a notebook

Cupcake Studio was taking custom orders through Instagram DMs, calculating ingredient quantities by hand per recipe, and tracking production capacity from memory. Past 30-40 orders a week that stops working: double bookings, miscalculated ingredients, inconsistent client communication. We built a purpose-built production ERP covering orders, CRM, a recipe database with auto-scaling, scheduling, procurement and delivery. Admin went from around 8 hours a day to about 1. Custom application with a database and an interface: top band.

A B2B supplier with a good product and no sales system

B2B Pallets, in Australia, had one salesperson doing manual outreach and burning hours on qualification calls that went nowhere. We built list building and enrichment, personalised sequences, and an AI voice agent that runs the first qualification call, scores the lead, and only passes warm prospects to the human. Outreach volume went up roughly fivefold and coverage went from one city to nationwide. Several integrations plus a voice AI layer: upper mid band.

The running costs nobody puts in the proposal

The build is a one-off. The running cost is forever, and it is where budgets get embarrassing in month seven. Three separate lines, and they behave differently.

Platform fees, predictable

Make sits at roughly $9-16/month for most small business automations. n8n cloud starts around $20/month, or $30-50/month in server costs if you self-host, which also buys you data residency if that matters to you. Zapier is the expensive one at volume and that is the main argument against it. These numbers are stable and easy to plan around.

AI API usage, the one that surprises people

For typical small business volumes, $20-100/month on Claude or OpenAI. The surprise is that this scales with usage, not with subscribers, so a successful automation gets more expensive as it works harder. Ask any agency what your per-record model cost is and what happens to it at ten times the volume. If they cannot answer, they have not measured it. A well-built pipeline usually has a cheap model doing the routine cases and an expensive model only on the hard ones, and that design choice can be a five to ten times difference in the bill.

Maintenance, the honest version

Most well-built automations run for months without anyone touching them. What does break them: an app you integrate with changes its API, a supplier changes their invoice format, or your own process changes and nobody told the system. Realistically budget a few hours a quarter, or a retainer if you have no technical person at all. A $500/month maintenance retainer on a simple Make flow is not maintenance, it is a subscription to someone answering the phone. Ask exactly what is included and what response time you are buying.

Total for most small business automations: $50-200/month all in. High volume or multiple AI-heavy systems: up to $500/month. If someone quotes you a build with no running cost at all, they have either not thought about it or they are hiding it in a retainer.

Fixed price or hourly, and why it matters to you

Hourly billing on automation work is a signal worth reading. An agency that has built the same shape of system before knows how long it takes. If they will not commit to a number, either they have not built it before, or the incentives are pointed the wrong way, because under hourly billing the slower option pays better.

We quote fixed price on fixed scope. You know the number before anything starts, projects run two to six weeks, and if we mis-scoped something that is our cost to absorb, not a change order. The trade for you is that scoping has to be done properly up front, which takes a day or two and some of your attention. That trade is worth making.

Things in a quote that should make you ask another question:

An hourly rate with no estimated total
A maintenance retainer with no list of what it covers
No mention of what happens when an integration fails at 2am
No mention of who owns the accounts, the code and the data at the end
A discovery phase that costs real money and produces only a document

How to make your own project cheaper

Most of the levers are on your side of the table, not the agency's. These are the ones that actually reduce a quote rather than just squeezing a margin.

Automate one process end to end instead of three processes halfway. Half-automated processes still need a person watching them, so you pay and keep the headcount.
Clean the data first, or agree explicitly who is cleaning it. This is the largest single hidden cost.
Decide the edge cases before the build. Every 'what should happen if' answered during the build is a change of direction; answered before, it is a line in the spec.
Let the system escalate to a human on the rare cases. Insisting on 100% automation of a case that happens twice a month can add thousands.
Use the tools you already pay for where they fit. Replacing a working CRM for elegance is a cost with no return.

When the honest answer is do not automate this

We turn down work over this and I would rather say it here than on a call. If the process runs fewer than a handful of times a month, if it is about to change anyway, or if it is broken as a process and automating it just makes it break faster, the return will not be there. Automating a bad process gives you a bad process running at speed and with less visibility.

The rough arithmetic: take the hours the process eats each month, multiply by a realistic loaded hourly cost, and compare that to the build spread over 12 months plus the running cost. If it does not clear comfortably inside a year, the project is not the problem, the priority is.

What to bring to get a real number

A scoped quote takes us one to two days once we have four things. Without them, any number anyone gives you is a guess dressed as a quote.

The process written out step by step, including the steps you think are obvious
The systems involved: every tool that touches it today, including the spreadsheet
Rough volume per month, and what you expect it to be in a year
What the output is and where it needs to end up

If you are not sure the process is even worth automating, that is a fine place to start from. Half the useful part of a scoping conversation is finding out that the expensive thing is not the step you thought it was.

Four questions, two minutes, no call required: take the audit at 2pizza.team/audit and get an estimate for your specific process. If the honest answer is that you do not need us yet, that is what it will say.

Originally published at 2pizza.team. We build AI and automation systems for small teams - fixed price, two to six weeks. See the work.

iGaming Retention CRM: The Gradient Boosting Playbook (2026)

2pizza.team — Fri, 11 Sep 2026 09:27:31 +0000

TL;DR: Casino retention is a per-player decision, not a cohort blast. Score churn and reactivation with gradient boosting on raw transactions, feed the output into the analyst team's CRM as a prioritised worklist, and keep LLMs out of anything that touches money. Player payback is five to seven months - a hallucinated risk score is real loss. This playbook is from a live pilot for a European online casino operator.

Online casino retention is one of the last frontiers of B2C where cohort blasts are still the norm. Analyst teams build segments by hand, push the same bonus to everyone in the segment, and hope the numbers move at the end of the month. The signal that a single VIP is about to go silent gets averaged away in the cohort. By the time anyone notices, the window to hold that player has closed.

This post is the technical playbook for building a retention CRM that actually decides per player. It is not vendor pitch. It is what we shipped in a two-week scoring core for a European casino operator, plus what we learned in the discovery calls that led up to it - including the parts where we told the operator not to do things.

Why cohort retention breaks down

Take the standard retention workflow. Analysts pull yesterday's active players, segment by deposit tier and recency, and push a bonus to each segment. The bonus is either a percentage cashback, a bonus-hunter-bait match, or an untargeted freespins bundle. The retention team measures conversion by segment at the end of the week.

Three problems compound. First, bonus economics leak. Bonus hunters in the cohort collect the same offer as your loyal whales. The margin gets eaten by the wrong audience. Second, VIP silence gets missed. A high-frequency depositor whose bet size just dropped by 60% is a churn signal that no cohort segmentation surfaces - his tier and recency still look fine. Third, the analyst worklist is flat. A dashboard with 4,000 active players sorted by yesterday's deposit tells the team nothing about who to act on.

The problem is not the analysts. The problem is that the retention layer was never designed to produce per-player decisions.

Why not use an LLM for scoring?

This is the question we get on every discovery call. The answer is no, and it is not a religious no.

Player payback periods in iGaming run five to seven months. A hallucinated risk score - and every LLM hallucinates in some percentage of calls - is not an amusing error. It is real money that either walks out the door in the form of a bonus given to the wrong player, or gets saved in the form of a churn that would have been catchable. Compounded over a rolling week of scoring, the drift adds up to material P&L movement.

There is a second issue. LLMs are not auditable in the sense that a retention analyst can trust. When an XGBoost model returns a churn probability of 0.72 for player X, the analyst can pull the top ten SHAP features and see exactly why - bet size dropped, session length dropped, game-mix shifted from slots to blackjack, no deposit in fourteen days. When an LLM returns a churn probability of 0.72, there is no audit trail. The analyst either trusts the black box or does not, and if they do not, the whole system loses adoption.

LLMs have a real place in the retention loop - drafting the copy of a retention message, summarising a player's history for the analyst before a call, generating human-language explanations of an already-auditable score. Anywhere the wrong output is recoverable by a human review pass, we use them freely. Anywhere the wrong output leaks money before a human sees it, we do not.

The scoring architecture

Four source tables aggregate into a per-player feature card. Players, transactions, sessions, and game events. Every casino platform has some form of these, whether the schema is documented or has to be reverse-engineered from a self-written platform's database.

The feature card is one row per player, wide, with features scoped to prediction windows. Critically, the aggregation runs inside the feature pipeline and not upstream. This is not a small technical detail - it is the single most important choice that separates a scoring model that works from one that pretends to work.

Why raw transactions, not pre-aggregated averages

Casino platforms typically produce pre-computed player statistics - average bet, favourite game, lifetime deposits - available as an API. Nice, convenient, and a trap. Those aggregates are usually computed over the player's full history, including the period the model is supposed to predict. That is future-data leakage. Trained on those features, a model will look brilliant offline and degrade in production, because in production the features are being computed on partial history.

We take raw transactions and let the pipeline compute the aggregates fresh at scoring time, scoped to the exact time window the model was trained on - typically the trailing 7, 14, and 30 days for behavioural features, and the trailing 90 days for lifetime deposit statistics. This is boring engineering work. It is also the reason the model generalises.

Account-type filtering

Real players are not the only things in a casino database. There are test accounts from QA, service accounts from support tools, and bot accounts. Training a model on unfiltered data teaches it that test accounts are real players with strange behaviour. In production, that shows up as noisy predictions for edge-case real players.

We ask the operator for account-type flags before training - real, test, service, bot - and filter aggressively. If the platform does not maintain those flags, the first sprint of the engagement is adding them. The scoring model will not perform without them.

Consent and responsible gaming as a gate

Marketing consent, service consent, self-exclusion, deposit limits, and time-played thresholds are read at scoring time and again at trigger time. A player who self-excluded three days ago must not receive a reactivation bonus, even if the model would rank them as high-value. This is not optional. In regulated markets (MGA, UKGC, regional licences), it is a hard gate. In unregulated markets, it is still what a responsible operator does.

Structurally, we build the responsible-gaming check as a suppression layer between the scored worklist and the outreach queue. The scoring model does not know about consent - it scores every player. The trigger layer filters. This separation matters because it lets the analyst inspect scored players who are suppressed - useful for QA and edge cases.

Model choice: gradient boosting

XGBoost, LightGBM, or CatBoost - the specific choice is less important than the choice to use tabular gradient boosting over neural networks for this problem. Tabular data with under a few million rows and dozens to hundreds of features is the exact terrain where gradient boosting reliably beats neural networks. It trains faster. It is auditable. Its predictions come with SHAP explanations that the retention analyst can read.

The two scores we return per player are churn probability in the next 7 to 30 days, and reactivation probability if the player has already gone silent. These are two separate models. Trying to fit one model to both is a common temptation - it produces a model that predicts nothing very well.

Training details that matter in practice: class imbalance is real - most active players will still be active in seven days, so class balance techniques (weighted loss, focal loss for the extreme cases) are the difference between a model that predicts one class always and one that surfaces real signal. Cross-validation must be time-aware, not random - a random split leaks future information into the training fold. Calibration is essential if the retention team is going to trust the probabilities; a well-ranking but poorly-calibrated model is common with gradient boosting and needs an isotonic or Platt post-fit.

Output: the prioritised worklist

The scoring model produces two numbers per player. That is not yet a product. The product is what happens on top - specifically, the prioritised worklist that flows into the retention team's existing CRM.

A good worklist has four properties. It is sorted by expected value, not raw score - a player with a churn probability of 0.9 and a monthly deposit of $100 is lower priority than a player with a churn probability of 0.5 and a monthly deposit of $10,000. It is grouped by suggested action - hold, reactivate, monitor - because analysts think in actions, not scores. It is explainable - each row shows the top three features that drove the flag, so the analyst can decide whether to trust it. It respects consent - self-excluded and responsible-gaming-flagged players are visible in a separate lane for QA but never in the outreach queue.

We do not decide the bonus, the script, or the channel. The operator decides those. Our layer says who to act on, in what order, and why. This separation is intentional - it is how the retention team stays in the loop rather than being replaced by a black box.

Adapter architecture for self-written platforms

Almost every casino operator we talk to runs a self-written platform. Off-the-shelf retention CRMs assume a standard schema that these platforms do not have. Integration efforts drag on for months and the result still does not understand how the platform actually works.

We build an adapter - one lightweight service that maps the operator's specific schema to a standard feature card. Once the adapter is in place, the scoring layer plugs in on top without any changes to the operator's platform. The operator does not migrate off their own stack.

The adapter is where most of the discovery work happens. Which table has the transactions. Which field means what. Which player states exist. Which currency codes are used and whether amounts are stored in cents or in units. Time zones - are timestamps stored in UTC or in the operator's local. These are the questions that make or break the pilot, and they are boring, and there is no way around them.

The pilot: two phases, not one

We scope every retention engagement as two phases and refuse to bundle them into one price. Phase one is the data audit and the adapter. Phase two is the model and the pilot itself.

Phase one takes two to four weeks. We map the schema, verify account-type flags exist or add them, check consent state, verify time-window correctness in the source data, and confirm that six or more months of clean player history is available. At the end of phase one, we either have a working adapter and a confirmed dataset - or we stop and tell the operator the data is not ready. Both outcomes are honest. Neither is spun as bad news.

Phase two takes another four to eight weeks. We train the two scoring models, run offline evaluation on held-out windows, calibrate the outputs, integrate into the operator's existing retention CRM as a prioritised worklist, and run the pilot in shadow mode for two weeks before the retention team starts acting on the scores. Shadow mode is important - it produces the first evidence that the model's flagged players actually go silent, without any campaign spend.

What does not work

A few patterns we have seen fail on other retention services, mostly because the vendor was selling a product they did not have to engineer.

The patterns that reliably fail:

Segment-level scoring dressed up as per-player - if the score comes from a cohort membership, it is not a per-player decision no matter how the dashboard displays it
Robocalls with hardcoded scripts scripted by the operator - anti-fraud filters kill a large percentage of the calls, and the ones that connect sound like scam calls
Real-time scoring on aggregated features from the platform's own API - the future-data leak we described above, dressed up as low-latency
Bonus recommendation as part of the scoring output - bonus economics are the operator's decision, tied to margin and legal constraints the model does not know about
Anything that markets itself as 'AI retention' with no auditable scoring layer underneath

Cost model that works for the operator

The cost structure of this kind of build has a useful property for operators. The scoring service runs at very low operational cost per player - inference is cheap once trained, retraining is a weekly batch job. The expensive parts of retention - outbound calls, SMS, WhatsApp, incentive spend - sit on the operator's side. The operator pays the telco and the bonuses. We are responsible for scoring quality and worklist ranking.

This alignment matters. When our incentive is scoring accuracy and the operator's incentive is bonus spend efficiency, both sides pull in the same direction. When a vendor's incentive is per-call revenue, the model gets pushed to score more players as at-risk than they actually are.

Where this goes next

Beyond the retention score itself, the same feature card supports downstream work - LTV prediction for affiliate quality assessment (score affiliates on the 90-day value of players they bring, not on registrations), fraud scoring (bonus abuse and multi-account detection), personalised game-mix ranking. Once the adapter is in place and the feature card is populated cleanly, each of these is a new model trained on the same substrate.

The technical work of casino retention is one hundred percent about the substrate - the raw transactions, the account flags, the consent state, the currency and timezone hygiene. Get those right and every model on top of them works. Get them wrong and no amount of sophistication above rescues you.

Running a casino or sportsbook platform and thinking about retention scoring? Book a scoping call - we run a two-phase pilot starting with a data audit. If the data is not ready we tell you and stop rather than push to phase two. See the live pilot at /work/igaming-retention.

Originally published at 2pizza.team. We build AI and automation systems for small teams - fixed price, two to six weeks. See the work.

Fine-tuning Claude vs GPT vs Llama in Production: What Actually Works (2026)

2pizza.team — Fri, 11 Sep 2026 02:32:59 +0000

TL;DR: Most teams reach for fine-tuning when they should be tightening their retrieval stack. Anthropic does not currently offer general-purpose fine-tuning for Claude - prompt caching, RAG, and context engineering carry it. OpenAI's fine-tuning is useful for narrow style and format control, less useful for domain knowledge injection. Open-weight fine-tuning (Llama 3, Mistral, Qwen) unlocks real domain adaptation but adds infra cost most teams underestimate. When in doubt: RAG first, fine-tune only when RAG has a measurable ceiling.

Fine-tuning is the most misused word in production LLM engineering right now. Half the teams asking for it need a better retrieval stack. A quarter need better prompts. The remaining quarter have a real fine-tuning problem and need to pick the right target model, and that choice depends on constraints most decision-makers do not see coming.

This is the version from the trenches. We ship production ML systems across Claude, OpenAI, Llama, Mistral, and Gemini stacks, most of them for teams that hire us specifically because they hit the ceiling of prompt engineering. The comparison below is what we actually recommend on scoping calls in 2026.

When to fine-tune vs when to RAG vs when to prompt-engineer

The decision tree is simple but rarely applied cleanly. Fine-tuning teaches a model style, format, and tone at a level prompt engineering cannot match consistently. RAG teaches a model what your domain knowledge is at a level fine-tuning cannot match economically. Prompt engineering is the baseline that determines whether either of the other two is worth trying.

Rules of thumb we use in production:

You want the model to sound like your brand voice or follow a very specific output format on every response → fine-tune
You want the model to answer using your product docs, support tickets, contracts, or any body of proprietary text → RAG
You want the model to reason over a specific analytical framework or make decisions using your rubric → prompt engineering, possibly with structured outputs
You want to shrink the model to fit on your infra or reduce inference cost → fine-tune a smaller open-weight model on high-quality outputs from a bigger one (distillation)
The model gets facts wrong on production tasks → almost always a RAG problem, not a fine-tuning problem

The mistake we see repeatedly is teams trying to inject domain knowledge through fine-tuning. It works, technically, but the economics rarely favour it. Fine-tuning a knowledge cutoff into a model means retraining every time your knowledge changes. RAG updates the moment you update the source. On changing knowledge, RAG always wins on total cost of ownership.

Claude and the Anthropic stack

Anthropic does not currently expose general-purpose fine-tuning for Claude the way OpenAI does. This surprises teams when they first plan a Claude project. The reasoning from Anthropic is roughly that most fine-tuning use cases are better served by prompt engineering plus RAG in Claude specifically because Claude handles very long contexts well and follows instructions in ways that reduce the need for fine-tuning.

In practice, that is largely correct for the workloads we run. Claude Opus and Sonnet with a well-designed system prompt, prompt caching for the invariant parts of the context, and a properly built retrieval stack cover most of what teams reach for fine-tuning to solve. The one gap is heavy structural output constraints where you need the model to always emit a specific schema, in which case tool use and structured output modes carry it.

Prompt caching is the piece most teams underuse. If your system prompt plus retrieved context is 40k tokens and stays largely stable across a session, prompt caching drops the per-request cost by 90% on the cached portion. Combined with the extended thinking mode on newer Claude models, this is often the pattern that turns a project from unaffordable to production-ready.

For teams that do need Claude-specific adaptation beyond prompt engineering, Anthropic's enterprise offerings include prompt-engineering support and evaluation frameworks. That is not fine-tuning in the technical sense, but for most production use cases it produces the same outcome cheaper.

OpenAI and GPT fine-tuning

OpenAI offers fine-tuning across the GPT-4o, GPT-4o-mini, and GPT-3.5-turbo families. The API is mature, the pricing is transparent, and the fine-tuning cost has come down over the past two years to a level where it is genuinely economical for narrow style and format tuning.

Where OpenAI fine-tuning shines: consistent output style across thousands of requests, structural format enforcement that goes beyond what tool-use covers, and voice or tone matching a brand's specific characteristics with minimum drift. A hundred to a few hundred well-labelled examples typically suffice for style and format.

Where OpenAI fine-tuning is oversold: domain knowledge injection. Fine-tuning a GPT-4o on your product docs feels like teaching the model your business. In practice, the fine-tuned model develops confident wrong answers on facts adjacent to but not in the training data. RAG produces measurable improvements on the same task with source-attribution as a free by-product. If a customer support agent needs to cite the specific doc it used, RAG makes that trivial and fine-tuning makes that impossible.

One useful pattern with OpenAI fine-tuning that works: distil a mini or Nano model from GPT-4o outputs to run high-volume inference at a fraction of the cost. This is the case where fine-tuning economics dominate. The distilled model is not as capable as GPT-4o on hard tasks, but it is fast and cheap on the narrow task you distilled it for.

Open-weight fine-tuning: Llama, Mistral, Qwen

Fine-tuning a Llama 3 8B or 70B model, a Mistral Small or Large, or a Qwen 2.5 variant is the option that gives the most control and the most infrastructure cost. LoRA and QLoRA make training cheap - a single 80GB A100 can fine-tune Llama 3 8B in a few hours - but inference infrastructure is where the total cost of ownership lives.

Cases where open-weight fine-tuning wins: data residency requirements that forbid US-cloud LLM providers, on-premise deployment for regulated industries, ultra-high-volume inference where API pricing becomes prohibitive, and specialised domains where you need to teach the model concepts that pre-training did not include (specific medical, legal, or scientific specialties).

Cases where it does not win: teams without ML engineering resources for the deployment. The training is the easy part. The inference stack - VLLM or SGLang for serving, request batching, monitoring, model versioning, drift detection - is where the total cost lives, and most teams underestimate it by an order of magnitude.

Our recommendation: default to Claude or GPT via API for most use cases. Move to open-weight fine-tuning when specific constraints force it - compliance, scale, or capability gaps. Do not move to open-weight because it feels like more control. Control comes with cost.

RAG done right beats fine-tuning done poorly

Retrieval-augmented generation is where most production LLM value actually lives. Teams get it wrong in predictable ways.

The most common mistake: chunking documents by fixed character count and embedding each chunk. This produces retrieval that returns bits of context out of sequence, half a sentence at a time. The model then hallucinates the connective tissue. Good chunking respects semantic boundaries - paragraphs, sections, complete thoughts - and often uses overlapping chunks so no boundary is a knowledge cliff.

The second most common: using pure vector search when the query has strong keyword signal. Hybrid search - vector similarity plus BM25 keyword score with a fusion step - beats vector alone on most real workloads. Cohere's Rerank or Voyage's rerank models add another meaningful lift for a small marginal cost.

The third: no evaluation loop. A RAG system that works on your ten test queries and quietly fails on the ninetieth production query is worse than useless. Build a evaluation dataset of two hundred to a thousand real user queries and their correct answers, and re-run it on every retrieval stack change. Without this, the team is optimising in the dark.

Multi-model orchestration: when to route

In our video-generation and content pipelines, we run multi-model orchestration - route each stage of the pipeline to the model that owns that step. Brief interpretation to Claude for reasoning, storyboard to a vision model, image generation to the model with the best fidelity on the current subject, product-fidelity cleanup to a specialist model. Total cost per output is lower and quality per stage is higher than running one model end-to-end.

This pattern applies beyond video. Any pipeline with distinct steps benefits from routing. The overhead is a thin orchestration layer that tracks which model handled which step and lets you swap models per step as new versions land.

Cost math that matters in production

The pricing conversation on scoping calls always ends up in the same place. Let us do the math cleanly with realistic numbers.

Cost per one million tokens (input) in 2026 - approximate:

Claude Haiku 4.5: cheapest tier, fast, good for high-volume routine tasks
Claude Sonnet: mid-tier, the workhorse for most production work
Claude Opus: highest capability, expensive, use for hard reasoning stages
GPT-4o-mini: comparable to Sonnet, sometimes slightly cheaper
GPT-4o: comparable to Opus, priced accordingly
Llama 3 70B on Together AI or Groq: cheaper than Sonnet at API tier, more expensive if you self-host at low volume

Prompt caching changes the math for Claude specifically. If your invariant context is 30k tokens and you serve 1000 requests per day, the cached tier drops the cost by 90% on that portion. This alone can be the difference between a project being economical and not.

Fine-tuning has a training cost (one-off) and an inference cost (per-request, higher than base model). For narrow style tasks with high volume, the inference math works out favourably. For domain knowledge with modest volume, RAG on a base model always wins on total cost.

What we actually recommend

For most production LLM projects we scope in 2026, the recommendation is: Claude Sonnet or GPT-4o via API, prompt caching where invariants exist, a proper RAG stack for domain knowledge, and evaluation infrastructure from day one. Fine-tuning enters the conversation only when a specific ceiling is hit and there is clear evidence that fine-tuning would move it.

For compliance-constrained workloads: Llama 3 or Mistral with LoRA fine-tuning, self-hosted, is the answer. The engineering cost is real and needs to be part of the project scope.

For narrow style and format control at scale: OpenAI fine-tuning is the tightest option. A hundred to five hundred labelled examples, a single training run, and consistent output.

For anything scoring, decisioning, or touching unit economics: LLMs stay in supporting roles - drafting, summarising, explaining - and the decision layer sits on auditable ML. This is not an LLM story at all, and we cover it in the iGaming retention playbook linked above.

Building a production LLM system and unsure whether fine-tuning is the right lever? Book a call. We scope honestly - if RAG or prompt engineering would deliver the same outcome cheaper, we tell you before quoting fine-tuning work. See /services/ml for the full stack we work with.

Originally published at 2pizza.team. We build AI and automation systems for small teams - fixed price, two to six weeks. See the work.

Make vs Zapier vs n8n in 2026: Honest Comparison from 80+ Shipped Projects

2pizza.team — Fri, 11 Sep 2026 02:32:23 +0000

TL;DR: Most SMBs should start with Make.com. Move to n8n when you need self-hosting, FADP/GDPR compliance, or have a developer on the team. Use Zapier only for non-technical founders running low volume. AI integration changes the calculus - covered in section 7. This is based on 80+ shipped projects, not affiliate copy.

If you have started looking into business automation in 2026, you have hit the same wall everyone hits: Make, Zapier, and n8n all claim to do the same thing. Their marketing copy is nearly interchangeable. Pricing is confusing on purpose. Most comparison articles you find were written by someone getting affiliate commissions on signup.

We have built automation systems for 80+ clients across all three platforms - DTC e-commerce on Shopify, B2B SaaS sales ops, logistics document processing, agency content pipelines, and AI-augmented workflows with Claude and OpenAI. This is the honest version, with real numbers and real trade-offs.

Quick decision matrix

Skip everything below if you just want the answer. Read everything below if you want to know why.

Choose Zapier if:

You need something live in under an hour and you cannot hire a consultant
You are a solo founder with no technical team
You are running fewer than 500 automation runs per month total
You are connecting two common tools (Gmail to Notion, Typeform to HubSpot, Calendly to CRM) with simple logic
Time-to-shipping matters more than monthly cost

Choose Make.com if:

You are automating real business processes with branching logic, not just two-app connections
Monthly automation volume will exceed 1,000 operations
You want a visual builder that handles loops, conditionals, error handling, and aggregators natively
You need to integrate with Claude or OpenAI for content drafting, classification, or summarisation
You can spend half a day learning the interface OR you are hiring a consultant

Choose n8n if:

You have a developer on the team or you are technical yourself
You need self-hosting for data residency, FADP, GDPR, HIPAA, or any compliance reason
You need to write JavaScript or Python inside workflow steps
You are running high volume where cloud tool costs would exceed $200/month
You want to own the infrastructure with no vendor lock-in

Real pricing math (the part vendors hide)

All three platforms publish pricing pages. None of them help you predict your actual bill. The three plans are priced on completely different units of work, which is intentional - it makes apples-to-apples comparison hard.

Here is the simplified mental model. Zapier charges per task. A task = one action step. So one automation that pulls a record, transforms it, and writes to three destinations = 4 tasks per run. Make charges per operation. An operation is approximately one module execution - the same automation might be 4-6 operations depending on how it is built. n8n charges per workflow execution (cloud) or zero (self-host). One execution = one full run of one workflow, no matter how many steps.

What this means in practice for a typical use case: customer support ticket triage that processes 1,000 tickets per month and runs 8 actions per ticket. On Zapier that is 8,000 tasks per month, which puts you on the $73/month Professional plan but burning through tasks. On Make that is roughly 8,000-10,000 operations, comfortably in the $9/month Core plan. On n8n cloud that is 1,000 executions, well within the $20/month plan. On self-hosted n8n it is zero marginal cost.

At 10,000 tickets per month, the spread is dramatic. Zapier: ~$199/month Professional plan, hitting limits. Make: $16/month Pro plan, easily fits. n8n cloud: $50/month. n8n self-hosted: still zero marginal. At enterprise volumes (1,000+ workflows running 24/7), the gap widens further.

There is a hidden cost everyone misses: time spent on workarounds. Zapier is fast to start with, but complex branching forces you to chain multiple Zaps together with webhooks. Each chain link is more tasks and more complexity. We have seen Zapier setups that look elegant in marketing diagrams but eat 30-50% extra tasks in practice. Make handles the same logic in one scenario with zero overhead, often half the operations of equivalent Zapier task counts.

Capability matrix - what each platform actually does well

This is the table we wish vendors would publish. Based on building real production workflows, not feature checklists.

Visual workflow builder quality

Zapier: simplest, most opinionated. Linear flow visualization. Branching feels bolted on.
Make: best in class for visual logic. True canvas with branching, looping, aggregating. Steep at first but unbeatable for complex flows.
n8n: similar to Make but less polished. More technical look. Better for developers, harder for non-technical builders.

Integration count and quality

Zapier: 6,000+ apps. Largest catalog. Quality varies wildly - many integrations are read-only or limited to common operations.
Make: 1,800+ apps. Generally deeper integration per app. Most apps expose advanced operations not available in Zapier.
n8n: 400+ native integrations plus universal HTTP request node. If an API exists, n8n can talk to it. You write more glue code.

Custom code / scripting

Zapier: limited Code by Zapier step. Python or JavaScript with restrictions. Not for real custom logic.
Make: Custom Apps and inline code through tools modules. More flexible than Zapier but still cloud-bound.
n8n: Full Function nodes with JavaScript or Python. You can import npm packages on self-hosted instances. This is where n8n shines for developers.

Error handling and retries

Zapier: basic. Auto-retry on temporary failures, error notifications. Limited control over branching on error.
Make: excellent. Per-module error routes, configurable retries, break / commit / rollback patterns. Production-grade.
n8n: excellent. Wait nodes, error workflows, manual retry from UI. Most flexible because you can write custom error handlers.

Versioning, environments, team collaboration

Zapier: team plans include folders and access controls. No versioning. No environments (staging vs production).
Make: team and enterprise plans add organization workspaces and team folders. Native versioning still weak.
n8n: workflow JSON is git-able. You can deploy to dev/staging/prod environments. Native team features improving but not the focus.

Self-hosting, data residency, and compliance

This is where the comparison gets one-sided fast. Zapier is cloud-only. Make is cloud-only with EU region. n8n can be self-hosted on any infrastructure you control.

For a Swiss client subject to FADP and revDSG, or a German client with USt and GoBD compliance requirements, or any healthcare/finance client touching sensitive data - n8n self-hosted is often the only option that legal will sign off on. Your customer PII never leaves your infrastructure. You control where the database is, who has access, what gets logged.

Make.com offers an EU region (Frankfurt-based) that satisfies many GDPR requirements. For most EU SMBs that is sufficient. If your DPO or compliance team requires non-EU data to never touch your records, or you need contractual control over sub-processors, that is where Make stops and n8n self-hosted starts.

Zapier offers SOC 2 and various enterprise certifications but is US-cloud only. For some non-EU and non-Swiss regulated industries this is acceptable. For Swiss banking, German healthcare, or any client where the legal team explicitly forbids US-based processors, it is not.

Performance at scale

How do they behave when you push 100,000+ runs per month?

Zapier scales horizontally on their cloud. You pay more, they handle the rest. Latency between trigger and action is typically 1-3 seconds. For human-perception use cases (form to CRM, email to Slack) this is fine. For real-time customer-facing workflows, it is slow.

Make handles concurrent scenarios well at the paid tiers. Operation execution is faster than Zapier on average - typically sub-second per module. We have run Make scenarios processing 50,000 records per day reliably. Beyond that you start hitting plan limits or need enterprise pricing.

n8n self-hosted scales with your infrastructure. We have run n8n on a single $40/month Hetzner VPS processing 200,000+ workflow runs per month with margin to spare. Add a database queue (Redis + worker nodes) and you can scale to millions of runs per day. This is the architecture we use for production AI processing workloads.

AI integration - this is where the comparison shifted in 2026

Until 2024, this section did not really matter. By 2026, it matters more than any other capability. Every business automation we build now has AI in it somewhere - drafting, classifying, summarising, deciding.

All three platforms have native nodes for Claude (Anthropic), OpenAI, and other LLM providers. The integration quality is where they diverge.

Zapier and AI

Native Anthropic, OpenAI, and Gemini steps available
Templates for common patterns (summarise email, draft reply, classify ticket)
Limited: token usage hidden inside Zapier billing, hard to monitor
No native support for streaming, tool use, or structured outputs as of late 2025
Best for: simple AI augmentation where you do not need fine control

Make and AI

Full Anthropic and OpenAI modules with system prompt, model selection, max tokens
Structured output / JSON mode supported
Direct API key billing - your account, your bill, you see exact usage
Can chain multiple AI calls in one scenario with conditional branching
Best for: production AI workflows where cost monitoring and prompt versioning matter

n8n and AI

All native LLM nodes plus the universal HTTP node for any new provider
Tool use / function calling supported via custom logic
Self-hosted means LLM calls happen on your infrastructure - data never touches your automation vendor
MCP server integration possible (we have implemented this for several clients)
Best for: AI workflows under compliance constraints OR where you need cutting-edge model features

Our recommendation for 2026: if AI is core to your automation, start with Make for visual prompt management and easy team handoff. Move to n8n self-hosted when you need data isolation, custom tool calling, or are paying enough in LLM tokens that having dedicated infrastructure saves money. Skip Zapier for AI-heavy workflows.

Use cases by industry - what we actually build for clients

Real client patterns from 80+ shipped projects across e-commerce, B2B SaaS, logistics, finance, agencies, and DTC.

E-commerce and DTC

Default: Make. Shopify + Klaviyo + Stripe + warehouse integrations work seamlessly. Cost stays low.
Switch to n8n self-hosted: when handling >5,000 orders/month with custom AI tagging or recommendation logic
Zapier only if: small store doing under 50 orders/day with no AI in the workflow

B2B SaaS and sales ops

Default: Make. HubSpot + Salesforce + Pipedrive integrations are deep and reliable.
n8n: when sales team is 50+ people and you need custom lead scoring with self-hosted LLM
Zapier: starting a new SaaS, MVP stage, simple lead form to CRM flows

Logistics and document-heavy operations

Default: n8n. High document volume + custom OCR/AI extraction + compliance = n8n territory.
Make: smaller logistics SMBs with manageable document volume (under 1,000 docs/month)
Zapier: not recommended - costs explode with document processing volume

Finance, FP&A, and back-office

Default: n8n self-hosted. Financial data sensitivity + custom logic + AI narration = compliance + flexibility
Make: small finance teams where Xero/QuickBooks + Slack are the whole stack
Zapier: never. Audit teams will reject US-cloud-only solutions in regulated industries.

Agencies (white-label and client work)

Default: Make. Client teams can co-edit scenarios. Visual canvas is easy to demo and hand off.
n8n: for agency internal ops (PR triage, client reporting consolidation, where you control everything)
Zapier: starter client gigs where the client demands their own ownership and is non-technical

Learning curve and team adoption

Pricing and capability matter, but if your team will not actually use the tool, it does not matter.

Zapier is the easiest to ramp on. A non-technical operator can build a useful Zap in 30 minutes after watching one YouTube tutorial. The template library does most of the thinking for you. Six months in, your team will have shipped a lot of small automations.

Make has a 2-3 day learning curve for visual-thinkers, a week for non-technical operators. Once over the hump, productivity scales sharply. Six months in, your team builds significantly more complex workflows than they could have in Zapier.

n8n has the steepest curve - 1-2 weeks for someone with basic JS knowledge, a month for non-technical. But the ceiling is highest. Six months in, your team is building custom integrations no other tool supports.

Our adoption pattern recommendation: start the company on Make. Hire or train one person to become the n8n specialist if and when volume justifies it. Keep Zapier only for personal automations and edge cases where speed-to-ship beats everything else.

Migration paths between platforms

Moving between tools is painful. Plan for it before you commit at scale.

Zapier to Make is the most common migration we do. Triggers and actions usually map 1-to-1 but branching logic needs to be rebuilt because Make handles it natively whereas Zapier hacks it through multi-Zap chains. Expect 2-4 hours per Zap to migrate properly. Budget time for testing, especially error paths.

Make to n8n is harder because n8n workflows are not 1-to-1 with Make scenarios - n8n expects you to write more glue code. We typically rebuild rather than migrate. Allow 1 day per moderately complex scenario.

n8n to anything else is rare. Once you are on n8n with custom code, you have moved beyond what cloud tools offer. The only realistic migration is to a fully custom-coded backend - which means you have outgrown automation platforms entirely.

Honest pros and cons each

What we tell clients when they ask off the record.

Zapier pros

Fastest time to first working automation
Largest app catalog
Best documentation and learning resources
Strongest brand recognition (easy to explain to non-technical stakeholders)

Zapier cons

Most expensive at any meaningful scale
Limited branching and logic without painful workarounds
US cloud-only - compliance dead-end for many EU customers
Vendor lock-in - your automations live in their format only

Make pros

Best price-per-capability of the three
Visual canvas handles complex logic naturally
EU region available, sufficient for most GDPR cases
Mature error handling and retry semantics
Strong Anthropic and OpenAI integrations

Make cons

Steeper learning curve than Zapier - team training is required
No self-hosting option ever (not on their roadmap)
Some niche integrations missing vs Zapier
Visual canvas can become unwieldy on very complex scenarios

n8n pros

Self-hosting eliminates vendor lock-in and compliance constraints
Most powerful customization through code nodes
Lowest marginal cost at high volume (self-hosted = zero)
Open-source - inspect, modify, contribute
Best for cutting-edge AI workflows requiring custom tool use or MCP

n8n cons

Steepest learning curve - typically requires developer involvement
You manage infrastructure (security, upgrades, backups) on self-hosted
Smaller native integration catalog (compensated by HTTP node)
Less polished UI than Make - improving but not at parity

Common questions answered

What about Power Automate, Workato, Tray.io, or Pipedream?

Power Automate is good if you are deep in Microsoft 365 - it is included in many M365 plans and integrates natively with Outlook, Teams, SharePoint, and Dynamics. Outside the Microsoft ecosystem it is more painful. Workato and Tray.io are enterprise platforms - powerful and expensive ($10K+/year typical). Pipedream is closer to n8n - code-first, developer-friendly, but smaller community. For the SMB to mid-market sweet spot 2pizza serves, Make and n8n cover 95% of needs.

Can I use multiple platforms in one stack?

Yes, and we sometimes recommend it. Zapier for a few quick personal automations, Make for departmental workflows, n8n self-hosted for compliance-critical core processes. The cost is mental overhead and skills required across multiple tools. We usually nudge clients toward consolidating on one primary platform within 6 months of starting.

How much should I budget for a typical automation project?

Fixed-price builds at 2pizza start at $1,000 for a single workflow Starter tier and run $2,000-$4,000 for a multi-workflow Standard build delivered in 2-4 weeks. Custom builds with multi-tenant architecture and compliance overhead run $5,000-$15,000. Platform subscription is separate - typically $20-200/month depending on which tool and what volume.

What if I already built things in the wrong tool?

Migrate the highest-cost or highest-pain workflows first. Leave low-volume legacy stuff in place until it breaks - sunk cost on time saved versus rebuild cost is rarely worth disrupting working systems. We typically migrate clients in phases over 3-6 months.

Is n8n really free?

Self-hosted n8n itself is free and open-source (Sustainable Use License - free for internal business use, paid licensing required for resale). You pay for the infrastructure - typically $20-100/month on Hetzner, DigitalOcean, or Exoscale - plus operational time. For an automation that would cost $200/month on Make or $500/month on Zapier, the math works. For lower volumes the math is less obvious.

How we pick for clients

We do not have affiliate deals with any of these platforms. Tool choice is driven by client requirements, not commission rates.

Standard sequence: 30-minute audit call to understand the workflow + compliance + volume + team. Then we recommend the platform that fits - usually Make for default cases, n8n for compliance and scale cases, Zapier occasionally for non-technical solo founders. We then build, ship, and document.

Free 30-minute audit call to find the right automation platform for your specific workflow. We tell you which tool fits, what it will cost, and what timeline to expect - whether or not you work with us. Book at calendly.com/ib-2pizza/30min

Originally published at 2pizza.team. We build AI and automation systems for small teams - fixed price, two to six weeks. See the work.

Claude API vs OpenAI for Business Automation: What Actually Decides It in 2026

2pizza.team — Fri, 11 Sep 2026 02:27:15 +0000

Short version: the context window stopped being the deciding factor. Both families now ship a million-token window, so the choice moved to three things you only feel in production - how reliably the model returns the shape you asked for, what your bill looks like once caching is on, and how much of your system is already welded to one vendor. Prices below were checked on 10 September 2026 and they move; treat them as a shape, not a quote.

I run 2pizza.team. We are an official Anthropic partner and we also ship systems on OpenAI, because clients arrive with what they already have. Over the last two years I have watched this comparison get rewritten by both sides roughly every quarter, and almost every article about it ages badly within a month because it is built on a spec table.

This one is built on what actually breaks. If you are picking a model for an automation system rather than a chat toy, the spec table will not help you much. What follows is the shortlist of things that have decided the answer on real projects, and the one section most comparisons leave out: what does not work.

The context window argument is over

For two years the honest answer to "which model handles long documents" was Claude, because 200,000 tokens against 128,000 is a real gap when you are parsing contracts. That gap is gone. Claude Opus 5 and Sonnet 5 both carry a 1M token window; the current OpenAI flagships are in the same territory. Haiku 4.5 sits at 200K, which is still more than most pipelines need.

What replaced it is subtler and costs more money: long-context pricing tiers. OpenAI applies a higher rate above a length threshold, so a request that crosses it can roughly double in price without you changing a line of code. Anthropic's published rates for Opus 5 and Sonnet 5 are flat. If your workload is bimodal - mostly short calls with occasional monsters - model the monsters separately before you commit.

What we actually pay, and where the bill really comes from

Anthropic list prices per million tokens: Opus 5 at $5 input and $25 output, Sonnet 5 at $2 and $10, Haiku 4.5 at $1 and $5. On the OpenAI side the September 2026 aggregator figures put GPT-6 Astra at roughly $10 and $50, the 5.6 family from about $5 and $30 down to $0.20 and $1.20 at the small end, with an August price cut on the mid tier. Check the vendor pricing page before you budget; both change these more often than they announce them.

Now the part that matters more than any of those numbers. In every production system we have built, the model rate was not the main cost driver. Two mechanics were: prompt caching and retries. Both vendors bill cached input at about a tenth of the standard rate, and both halve everything on batch. A pipeline that reuses a large system prompt across thousands of calls and gets caching right pays a fraction of what the rate card implies. A pipeline that invalidates its cache on every request - a timestamp in the system prompt, an unsorted JSON blob, a tool list that reorders - pays full price forever and nobody notices, because the bill looks plausible.

The retry tax nobody budgets for

If a model returns malformed JSON on five percent of calls and your code retries, you are paying 105 percent of your token estimate and adding latency to every slow path. At a hundred thousand calls a month that is not a rounding error. This is why output reliability shows up in the cost section rather than the quality section: it is a cost line.

Structured output is the thing that decides most builds

An automation system is a machine that routes on a field. If the model returns a JSON object where status is sometimes "approved", sometimes "Approved", and once in a while a sentence explaining why it chose approved, the router breaks. Not loudly. It breaks on the two percent of records that then sit in a queue nobody watches.

Both vendors now solve this properly rather than by prompting. On the Anthropic side you set a response format through output_config, or mark a tool strict so its arguments validate exactly against your schema. That is a real constraint enforced server side, not an instruction the model may drift from on turn forty. If you are still parsing free text with a regex and a prayer, that is the single highest-leverage change you can make this week, on either vendor.

One caveat from our own postmortems: current models may escape strings inside tool arguments differently than older ones - Unicode, forward slashes. If any of your code does raw string matching on a serialized tool input instead of parsing it, it will fail silently after a model upgrade. Parse the JSON. Always.

Thinking became a dial, and the dial has a price

The biggest practical change since 2025 is that reasoning stopped being a checkbox. Anthropic's current models use adaptive thinking - the model decides how much to reason - and you control spend with an effort setting from low through max. The old fixed thinking budget is gone and returns an error on the current generation. Code written against that pattern breaks on upgrade.

This matters commercially because effort is now your first quality-versus-cost lever after caching. In our experience the interesting finding is counterintuitive: a newer model at low effort often beats an older model at high effort, and costs less. Before you build a cascade that routes cheap work to a small model, measure the flagship at low effort on the same tasks. A cascade also forfeits cache reuse, because caches are scoped per model - people forget that and are surprised when the savings do not appear.

Lock-in is a real cost and it is asymmetric

If you already have twenty OpenAI integrations, an embeddings store, and a team fluent in that SDK, the correct answer is usually to stay unless something is actually failing. Migration is not a model swap. It is a prompt rewrite, a re-tune of every temperature and format assumption, and a fresh eval run. We quote that work honestly and it is rarely the cheapest thing a client could do with the same budget.

The exception is when the failing thing is reliability rather than capability. If your system breaks on output format or long-document handling, a migration pays for itself. If it breaks because the prompt is vague, no vendor will fix that.

Rules of thumb we actually apply

Long documents in a single call, contracts and invoices: either family now, but check the long-context price tier before you commit
Output that must validate every time: use enforced structured output, not prompt instructions, on whichever vendor you are on
High volume and latency-tolerant: batch it and halve the bill, on either side
Already deep in one ecosystem and nothing is broken: stay, and spend the migration budget on caching and evals instead
Real-time voice: OpenAI's realtime stack is still the more mature one
Cost is the problem: fix caching and retries first, change model second, build a cascade last

What does not work

Picking on benchmark scores. Public benchmarks measure things that are not your workload, and both vendors optimise for them. We have had models that led a leaderboard lose to a cheaper one on our own extraction eval, because the task was mostly about following a schema, not about reasoning.

Migrating without an eval. If you cannot measure the current system, you cannot tell whether the new one is better; you will be arguing from vibes about a change that costs real money. Build a small eval on your own traffic first - a few dozen real records with known correct answers is enough to make the decision non-religious.

Copying a prompt across vendors unchanged. Prompts carry assumptions about how a specific model behaves, and those assumptions are usually invisible until they are wrong. Prompts written for older models are often too prescriptive for current ones and actively reduce output quality. Rewriting the prompt is part of the migration, not an optional polish step.

How we choose on a real project

We start with the constraint that is hardest to move. Usually that is an existing integration or a compliance requirement about where inference runs. Then we look at the output contract: if the system routes on a field, structured output support decides it. Then we model cost at the client's actual volume with caching switched on, not at list rate. The model name is usually the last thing we pick, and on about half our builds we end up using two - a capable model for the judgment step and a small one for bulk extraction.

That is less exciting than a verdict, but a verdict would be dishonest. Both families are good enough that the deciding factors are in your system, not in theirs.

If you are choosing right now and want a second opinion that is not selling you a migration: book a free 30-minute call. We will look at your output contract, your volume and your existing stack, and tell you which way we would go. If the answer is stay where you are, you will hear that.

Originally published at 2pizza.team. We build AI and automation systems for small teams - fixed price, two to six weeks. See the work.