Back to notes

December 10, 2025 · 6 min read

How I Actually Estimate AI Project Costs for a Client Proposal

Most AI project estimates blow up because nobody models the token cost curve past the demo. Here's the actual framework I use before I quote a number.

ProcessFreelance

I quoted a client a flat project fee once that didn't account for their actual production volume, and the per-query API cost alone would have eaten the entire margin within two months of launch. Never again. Now the estimate has three separate numbers, and I show the client all three before we sign anything.

The three numbers

  • Build cost: my time to design, implement, and test the feature — the part everyone already estimates reasonably.
  • Per-unit inference cost at projected volume, not demo volume — this is the number that gets skipped most often.
  • Ongoing operational cost: monitoring, prompt maintenance, model version migrations when a provider deprecates something.

The second number requires actually asking the client how many queries per day they expect at scale, then multiplying by realistic token counts for both the prompt and the output, including any retrieved context. Clients almost always underestimate their own volume, so I pad whatever number they give me by 50% and show them the math so it isn't a surprise later.

A demo that costs four cents per query can cost four thousand dollars a month in production, and nobody notices until the invoice.

A rough model I actually use

monthly_cost = queries_per_day * 30
             * (input_tokens + output_tokens) / 1_000_000
             * blended_price_per_million_tokens

+ caching discount if applicable
+ retry/failure overhead (typically 5-15%)

I also build in a review checkpoint at 90 days post-launch specifically to recheck this number against real usage, because actual query patterns almost never match the projection — sometimes because usage is lower than hoped, more often because someone found a way to use the feature in a loop nobody anticipated. Clients respect the estimate more, not less, when I show them where the uncertainty actually lives instead of pretending a single number captures it.