Most cost estimates for synthetic data are token arithmetic: prompt length times input price, plus expected output times output price. That calculation is usually wrong by a factor of two or more, because it ignores the thing that actually dominates the bill.
Here are measured numbers from generating Saudi Arabic customer-support conversations, and what they say about model selection.
The retry loop is the cost
Every conversation goes through a quality gate. Failures are fed back to the model with its own output and regenerated, up to three attempts.
From production data, the distribution of attempts per successfully delivered row:
| Attempts | Rows |
|---|---|
| 1 | 12 |
| 2 | 36 |
| 3 | 32 |
An average of 2.25 attempts per delivered row. Only 15% passed on the first try.
This changes the arithmetic completely. A retry is not a cheap top-up: it resends the system prompt, the full scenario prompt, the previous failed output, and a repair prompt. Attempts two and three have larger inputs than attempt one.
So the naive per-row estimate needs multiplying by roughly 2.25 — and the multiplier is a property of your quality gate, not of the model's price list.
Measured across three models
Same prompts, same gate, same taxonomy:
| Model | Pass rate | Cost per delivered row | 49,900 rows |
|---|---|---|---|
| GLM 5.3 Flash (minimal reasoning) | 59/62 (95%) | ~$0.00076 | ~$34–46 |
| DeepSeek v4 Flash | 20/27 (74%) | ~$0.0016–0.0027 | ~$80–133 |
Two things stand out.
The cheaper model was also the better one here, which is not the usual trade-off. Nothing about a lower price implies worse dialect handling, and the assumption that it must costs you money.
And the pass rates are noisy at these sample sizes. GLM scored 12/12, then 24/24, then 21/24 on identical configuration. DeepSeek scored 33%, then 67%, then 92%. Budget from the pooled figure across several runs; a single sample of twelve is not a pass rate, it is an anecdote.
The trap that returns nothing
GLM 5.3 Flash has reasoning that cannot be disabled. Sending a request without specifying a reasoning effort produced this:
- 8 of 8 requests returned empty content
- Every request consumed its full 4,000-token budget
- All of it went to reasoning tokens
The model thought until it ran out of room and never wrote an answer. Setting
reasoning: { effort: "minimal" } drops reasoning to roughly zero tokens and
the output appears normally. Attempting to disable reasoning entirely returns a
400: "Reasoning is mandatory for this endpoint and cannot be disabled."
The failure mode is worth internalising because it is silent. You are not rejected, you are not rate limited, you are billed in full for output tokens and you receive nothing. If you are switching models on a hosted router, check whether the new one reasons by default before you queue fifty thousand rows.
What to actually measure
Before committing to a large run, generate about two dozen rows through your real prompt and your real gate, and record:
- Pass rate — how many produce a usable row at all
- Attempts per success — the true cost multiplier
- Cost per delivered row from the provider's own reported usage, not your token estimate
- Wall time at your concurrency — this sets the schedule, and it is usually the thing that bites
Two dozen rows costs a few cents and tells you more than any amount of pricing-page arithmetic. Skipping this step is how a $40 job becomes a $130 one.
The part nobody budgets for
Inference is not the only cost, just the visible one. Database writes, container time for a run measured in days, and storage all add up — modest here, a few dollars, but not zero.
The larger unbudgeted cost is the quality gate itself: the time spent working out which checks matter for your domain. That is not an inference cost and it does not appear on any invoice, but it is most of the work, and it is the part that determines whether the output is worth anything.