Cost estimation is near the top of the list of tasks where AI performs better than most people expect. Not final, invoice-ready pricing — rough-order-of-magnitude thinking. “How much would it cost to run a server for this workload?” or “What should I budget for a freelance logo project?” or “Is renting a van and doing this move myself actually cheaper?”
These questions have a structure AI handles well: known ranges, publicly documented rates, a handful of variables. For broad-strokes estimates, it can shortcut hours of tab-opening. But there are specific places it goes quietly wrong, and the failure mode is almost always the same one: confident specificity on numbers that are actually stale, regional, or assembled from pattern-matching on whatever training examples happened to be nearby.
Where AI cost estimation actually works
Give Claude or ChatGPT a scenario like “I want to run a small PostgreSQL database on a VPS handling maybe 50 requests a minute” and you’ll get a useful working estimate — instance sizing, rough monthly cost range, what goes up if traffic spikes. Not because the model has live pricing, but because cloud pricing for common configurations is documented enough online that the variance across examples is narrow and the model can triangulate it reliably.
Same with freelance market rates. “What does a mid-level Python developer charge per hour on a contract basis in the UK?” produces a range that’s roughly right, with the right caveats (senior vs junior, platform vs direct). The model has absorbed enough job boards, forums, and rate surveys to land somewhere defensible on anything commonly discussed.
The useful move isn’t to ask for a single number — it’s to ask for a structured breakdown. “Give me a rough budget for launching a simple mobile app, broken down by category” produces something you can actually interrogate. Each line becomes a conversation starter: “that design estimate seems low, why did you land there?” You’re using the output as a thinking scaffold, not a deliverable.
We’ve done this when scoping new product features — not to replace actual vendor quotes, but to quickly sanity-check whether something is a $500 problem or a $5,000 problem before committing time to a full spec.
Where it goes wrong
Three specific failure modes, in rough order of how often they bite people:
1. Stale pricing on fast-moving services
More categories qualify here than you’d expect. AI API pricing specifically has dropped sharply in the last couple of years — GPT-4-class capabilities cost a fraction now of what they did eighteen months ago. Ask a model with an older training cutoff to estimate API spend for a given workload and the number it produces could be off by a factor of three or more. Not because it’s bad at math, but because it’s pattern-matching to prices that no longer exist.
Same issue with anything affected by supply chain shifts or energy prices. Don’t use AI for commodity pricing without checking a current source first.
2. Hyper-local costs treated as universal
Ask “how much does it cost to hire a plumber?” and you’ll get a figure that’s roughly right for somewhere — probably the most-represented geography in the training data. But labor costs vary enormously. A job that runs £150 in a mid-size UK city might be £300 in central London and considerably less in a lower cost-of-living market. The model knows this abstractly and will often add a disclaimer, but the baseline number it anchors on still reflects whatever distribution dominated its training text.
Any estimate involving local labor, local rent, or local regulatory costs needs a local check. The AI output gives you a frame; it doesn’t substitute for a quote from an actual person in the actual place.
3. The long-tail problem — estimating things rarely discussed online
Common categories are well-represented in training data. Niche ones aren’t. “What does it cost to certify a small commercial drone for agricultural use in the EU?” or “How much should I budget for a customs broker for a small consignment from Turkey?” — these involve regulatory fees, broker margins, and country-specific requirements that are documented somewhere, but sparsely. The model produces a number in the same confident tone it uses for everything else. That number might be roughly right or wildly wrong, and the output itself gives you no real signal about which.
The tell is when you ask it to explain its reasoning and the explanation is vague. “Based on typical regulatory costs…” is a red flag. “Based on EU UAS Regulation 2019/947, which sets certification fees in the range of…” is at least checkable — go check it.
How to actually use this in practice
The approach that works: treat AI cost estimates as a first-pass structure, not a final number. Ask for line items, not a total. Then check the two or three biggest line items against a current real-world source — a vendor quote, a recent forum post, an official fee schedule. The model saves you the work of knowing which categories to look at; you supply the actual current figures for the ones that move the decision.
Prompting the model to flag its own uncertainty helps too. “Give me a rough breakdown for X, and call out any line items where your estimate might be out of date or highly location-dependent” produces more useful output than just asking for the number. It’s the same principle as telling a model what a bad output looks like before it generates — it doesn’t prevent the failure mode entirely, but it makes the failure more visible when it happens.
One genuine caveat: this works better in a back-and-forth conversation than a single prompt. One big “estimate everything” question gets you a broad but shallow number. Asking iteratively — “okay, break down the hosting costs more” or “why is that design estimate lower than what I’ve seen quoted?” — surfaces the assumptions, and the assumptions are where the errors live.
What to be skeptical of: any workflow where an AI estimate goes straight into a proposal or a business case without a human checking the numbers that actually move the decision. As a thinking tool, this is genuinely useful. As a substitute for a quote, it isn’t.
Next time you’re scoping something, try asking for the breakdown first — not to skip the research, but to figure out which parts of the research are actually worth doing.
