Price a fine-tune against the thing it replaces: a longer prompt that caches. Training, the per-request inference premium, and any hourly hosting fee, with the break-even and the payback period.
Worked setups you can load into the form above. Each one is a decision the generator makes differently, and the reason it makes it.
The honest comparison. Few-shot examples are a fixed prefix, so they cost a tenth, and the fine-tune's inference premium never earns the training run back.
The same numbers with caching off. The prompting option nearly triples, the fine-tune now saves money, and nothing about the fine-tune changed.
At $1.70 an hour the hosting is over $1,200 a month whether or not anything calls it, which is more than the token cost by a wide margin and appears in no per-token estimate.
A job will run on this. The difference from the base model is inside the variance, and eight passes over twenty examples memorises them rather than generalising.
These are the ones that fail silently. The config is accepted, nothing raises an error, and the consequence arrives later.
Training is a one-off in the tens of dollars. The fine-tuned inference premium is charged on every request forever, and at any real volume it passes the training cost within days. The comparison is between two ongoing costs, not between a one-off and an ongoing one.
Instead:Price a month of each and find the break-even. The training run is a rounding error in that arithmetic.
Few-shot examples are a fixed prefix, which is exactly what prompt caching is for, so their real cost is a tenth of the input rate. Pricing them at full rate makes fine-tuning look inevitable, and on most realistic inputs it flips the answer.
Instead:Put a cache breakpoint after the example block and price it as a cache read before deciding.
A deployment billed by the hour costs the same at zero requests as at ten thousand, and there are 730 hours in a month. It never appears in a per-token estimate because it is not a rate per token.
Instead:Add it as a fixed monthly line. If the traffic is bursty, check whether the deployment can be torn down between runs.
The weights are derived from one version of the base model. When the provider retires it the fine-tune goes with it, and the work is repeated. A payback period longer than the snapshot's remaining life is not a payback.
Instead:Keep the training data and the evaluation set in version control so retraining is a pipeline, and budget for it at whatever cadence snapshots are retired.
A job will run on ten. The difference between the fine-tune and the base model on a set that small is inside the variance, and what comes out reproduces the examples it saw rather than generalising.
Instead:Collect fifty at minimum, hold back a validation split, and count the cost of producing good examples in the comparison. It is usually larger than the training run.
It is also the only number most estimates contain. A few hundred examples costs a few dollars to train. What the decision actually turns on is what happens afterwards, every day, forever.
Published rates have run at one and a half to two times the base model's, on both input and output. That premium is charged on every request for as long as the model is in service, so at any real volume it passes the training cost within days. A comparison that treats training as the cost of fine-tuning is measuring the wrong thing by two or three orders of magnitude.
training, once $0.18
inference premium $13.50 every month
the training run is spent again every four daysA hosted fine-tune with an hourly fee costs the same at zero requests as at ten thousand, and there are 730 hours in a month. Even a modest hourly rate then dwarfs the token cost at anything below very high volume. It never appears in a per-token estimate because it is not a rate per token, which is exactly why it is the line that turns a budget into a surprise.
Few-shot examples are a fixed prefix that does not change between requests, which is the case prompt caching exists for. Priced as a cache read they cost a tenth. Compare fine-tuning against an uncached prompt and it looks inevitable; compare it against a cached one and it usually does not. That single choice flips the answer on most realistic inputs, which is why it is a checkbox here rather than an assumption.
few-shot block, 3,000 tokens per request
uncached full input rate $63.00 a month
cached a tenth of it $22.50 a month
fine-tuned no examples, 2x $36.00 a monthThe weights are derived from a specific version of the base model. When the provider retires that version the fine-tune goes with it, and the only path forward is to train again and re-evaluate whether it still behaves. So a payback period longer than the snapshot's remaining life is not a payback. Keep the training data and the evaluation set in version control so retraining is a pipeline rather than an excavation.
A job will run on ten. The difference between the fine-tune and the base model on a set that small is inside the variance, and what you get is a model that reproduces the handful of examples it saw. The cost of producing good examples is real and belongs in this comparison too; it is usually larger than the training run by a wide margin.
Fine-tuning wins on latency, because the prompt is shorter. It wins on output format compliance, where a schema in a prompt is a request and a fine-tune is a habit. It wins on tasks a prompt cannot express at all. Those are good reasons and this page is not an argument against any of them. It is an argument against doing it for cost without checking whether it is cheaper.
No fine-tuning price list is bundled: published rates move, they differ by provider and by method, and a wrong one here would be a wrong recommendation rather than a wrong total. Left blank, the fine-tuned rates default to twice the base rate, which is a prefill and is labelled as one in the output. It also cannot price the parts that are not tokens: producing and cleaning the training set, running the evaluation, and the engineering time for both. Those routinely exceed everything on this page.