$0.03 per product description looks like a rounding error. It is, at 500 SKUs. It stops being one somewhere between "we generated our catalog once" and "we regenerate descriptions every season, for every SKU, plus the ones we add mid-quarter." The per-unit number never changes — what changes is how many times you multiply it, and most teams don't see that multiplication coming until the bill does.

TL;DR

1. Product description generation, chatbot support, and recommendation explanations are the three places e-commerce AI spend concentrates.
2. Seasonal rewrites — not the initial catalog pass — are usually the real cost driver on descriptions.
3. Recommendation explanations are the sneakiest cost center: a naive per-page-view implementation regenerates text that should be cached per product.

Cost Center 1: Product Descriptions

Scales with catalog size × rewrite frequency

The multiplication most teams miss

The initial pass over a catalog is a one-time cost that's easy to budget for. What's harder to see coming is how often that pass repeats: a seasonal collection launch, a rebrand, a promotional rewrite for a sale event, new SKUs added continuously through the year. Each of those is a full or partial re-run of the same generation cost.

50,000 SKUs × $0.03/description
= $1,500 per full catalog pass

4 seasonal rewrites/year × $1,500
= $6,000/year — 4x the "one-time" cost

Neither number is large in absolute terms for most e-commerce businesses. The point isn't that this is expensive — it's that the true annual cost is a multiple of the number most teams budget against, because they price the first pass and forget the recurring ones.

Cost Center 2: AI Customer Support

Scales with traffic × conversation length

The variance problem

Unlike descriptions, support chatbot cost doesn't scale predictably — it depends on traffic (which spikes around sales events, exactly when support volume also spikes) and conversation length (a simple "where's my order" exchange versus a multi-turn troubleshooting conversation). This is where model routing matters most: FAQ-pattern questions ("what's your return policy") don't need the same model as an escalated order dispute.

Cost Center 3: Recommendation Explanations

Scales with page views, not catalog size

The one that catches teams off guard

"Why we recommend this" text generated per page view, rather than cached per product, is the quietest cost center of the three because it doesn't look like it should scale this way. A 10,000-product catalog with 500,000 monthly page views isn't generating explanation text 10,000 times — a naive implementation generates it 500,000 times, once per view, because most page views are repeat visitors seeing products that were already explained yesterday.

Want to see which of these three is your biggest cost center?

One URL change shows you cost broken down by feature — descriptions, chat, recommendations — separately.

See Your Cost Breakdown by Feature

One URL change. See which features cost the most. Free to start.

The Fix for Recommendation Explanations

Cache by product ID, not by page view. If the explanation text for a given product hasn't changed — same product, same recommendation reasoning — regenerating it on every view is pure waste. A cache keyed on product ID (invalidated when the product's attributes or the recommendation logic actually change) turns 500,000 generation calls into, realistically, a few thousand — one per product, refreshed only when something about that product's recommendation context changes.

This is the same underlying pattern as running an expensive model on a task that doesn't need it — except here the waste isn't model choice, it's regenerating identical output instead of reusing it. The response caching implementation guide covers the exact-match caching pattern that fits this case well.

Where This Leaves the $0.03 Number

The per-description price was never the problem — it's genuinely cheap. The problem is treating a per-unit cost as the whole picture when the real driver is frequency (seasonal rewrites) and multiplication (per-view instead of per-product caching). Both are fixable once they're visible, which requires breaking spend down by feature rather than looking at one aggregate LLM bill — the same principle covered in tracking cost per user, applied here to cost per feature instead.

Frequently Asked Questions

How much does it cost to generate AI product descriptions at scale?
At roughly $0.03 per description, a 50,000-SKU catalog costs about $1,500 for a single full pass. Seasonal rewrites multiply that cost every time they happen — most catalogs do this several times a year, not once.
What are the three biggest LLM cost centers for e-commerce AI?
Product description generation (scales with catalog size × rewrite frequency), AI customer support chatbots (scales with traffic × conversation length), and recommendation explanations (scales with page views if not cached properly).
Why do recommendation explanations get expensive fast?
The naive implementation calls the model once per page view rather than once per product. Caching by product ID rather than regenerating per view is the fix — most page views are repeat visitors seeing the same product.
Does model choice matter more for descriptions or for chatbot support?
Descriptions are usually the easier win — a bounded task a budget model handles well. Chatbot support has more variance, so routing needs more care: simple FAQ questions to a cheap model, escalated issues to a stronger one.

See your descriptions, chat, and recommendations costs separately.

One URL change, and Preto breaks your LLM spend down by feature — so you know which of the three is actually driving your bill.

See Your Cost Breakdown by Feature

Free forever up to 10K requests. No credit card required.

Gaurav Dagade
Gaurav Dagade

Founder of Preto.ai. 11 years engineering leadership. Previously Engineering Manager at Bynry. Building the cost intelligence layer for AI infrastructure.

LinkedIn · Twitter