Fine-tune, build agents, or neither?
A cost model that tells you when a build pays back, and when it does not.
This is for you if
- You are the founder whose investors keep asking about AI, and you need a straight answer before you commit budget.
- You are the platform lead who owns the spend and has to defend the build cost to a CFO.
- You are the data lead who keeps being asked whether you can just fine-tune it, and want a real answer, not a guess.
- You are the fractional CTO advising several teams that all want the same build, and need a repeatable way to check whether it pays.
Three inputs, one costed verdict
Everything else uses a documented default until you open Refine.
How many times a month this task runs. The strongest lever on the whole model.
Cost over time, with its error bars
Each path is a range, not a point. Where the bands overlap, the choice is genuinely close.
What one wrong answer costs
The number nobody models. Move this and watch how much of the total above comes from error cost alone.
Refine: every remaining input, with the default already applied
Every path is checked against this floor at its best case.
Build cost scales directly with this rate.
How expensive it is to close the data gap fine-tuning needs.
The single biggest driver of an agent system's run cost. The default varies with task shape; set your own if you know it.
Dollars per wrong answer. Multiplied by the error rate and your volume every month, so it can dominate the total.
Our defaults are reasoned estimates, not benchmarks. If you have measured accuracy for any path, enter it as a percentage.
Want this run against your real numbers, not a reasoned estimate?
Book a scoping callRun this in your own LLM
Send the same decision procedure this page runs to Claude, ChatGPT, or Gemini, and fill in your own numbers there.
Questions we get about this tool
Why does this tool give a range instead of one number?
Every dollar figure here is computed three times: an optimistic case, a middle case, and a pessimistic case, then shown as a low, mid, high band. The volume at which a fine-tuned model starts beating an agent system is reported the same way, as a range, never a single point, because the input with the widest uncertainty, how many model calls one task takes, can span nearly an order of magnitude between implementations.
What does it mean when the verdict is a close call?
It means at least two viable paths cost close to the same on the middle estimate, close enough that the gap falls inside the model's own margin of error. When that happens the recommendation still names a winner, but the honest reading is that either path is defensible and the choice should turn on something this model does not capture, like team preference or the value of the capability you build along the way.
Why would it recommend fine-tuning now and agents later, or the reverse?
This is the hybrid path. When an agent system is cheaper in the first few months but a distilled, fine-tuned model becomes cheaper by the end of your horizon, the tool recommends building the agent system now and revisiting distillation once volume passes the trigger, rather than one path forever. Fine-tuning alone is never compared to agents directly for this decision, because the same gate that removes standalone fine-tuning, needing tools or state, is exactly when this question is live.
What if no option fits?
If every path is eliminated at once, which only happens when a sub-second response is required for a task that also needs multiple orchestrated steps, the tool returns no fit instead of forcing a recommendation. Multi-call orchestration cannot fit inside a sub-second budget, so the fix is to relax the latency requirement or reduce the task to a single step, not to pick a fine-tuned model where none of the assumptions apply.
Can I trust the dollar figures on this page?
Every number traces to a named source in the provenance section further down this page. Token prices and GPU rates cite the vendor pages we read them from; engineering days, error costs, and call counts are reasoned estimates we say so about. Where we invented nothing, we still built in wide bands, because a reasoned estimate presented as a single confident number is worse than one presented honestly as a range.
Does the fine-tune cost include efficiency tools like Unsloth?
Not as a separate line. The tool prices fine-tuning two ways: a managed service, using published per-token training rates, and self-hosted, using published GPU hourly rates. Efficiency libraries like Unsloth, Axolotl, or TRL with PEFT run on top of the self-hosted path and make it faster and lighter on memory, which pushes the real cost toward the low end of the band the tool already shows. We do not model them as a distinct provider because the saving is a technique, not a price you can cite, and it swings with model size and hardware. If you fine-tune with one of these, read the optimistic end of the fine-tune range as the number to plan around.
Should I trust this over an actual audit of my numbers?
No. This is a reasoned model, not a measurement of your business. It does not account for opportunity cost, vendor lock-in, or the value of a capability you build along the way. If your own numbers differ, or you want this run against them directly, book a call and we will work through it with you.
How the decision is made
This is the exact procedure the calculator runs, published in full so you, or any language model, can follow it by hand. It is the MLDeep Fine-tune vs Agents Framework, and the calculator above is just this procedure with the numbers filled in.
The short answer: fine-tuning and agents are not alternatives. Most teams should stay on prompting with retrieval until volume is high and the task is stable, add agents when the work needs tools or multiple steps, and distil the hot path into a small fine-tuned model only once volume makes the training pay back. This is the MLDeep Fine-tune vs Agents Framework, and the calculator above prices your specific case against it.
The ten gates
A hard gate removes a path outright, whatever it would cost. A soft gate leaves the path in play but attaches a warning.
- G1
No data, no fine-tune. No labeled examples and no way to generate synthetic ones removes fine-tuning outright.
- G2
Tools or state, no standalone fine-tune. A task that needs to call your systems, take actions, or hold state across steps removes standalone fine-tuning. A fine-tuned model can still sit inside an agent system, which is what the hybrid path covers.
- G3
Air-gapped switches the cost model. Air-gapped deployment removes nothing. It moves every path onto a self-hosted GPU cost model instead of hosted APIs.
- G4
Sub-second plus multi-step, no orchestration. A sub-second latency budget on a task that takes more than one step removes both agents and hybrid, because multi-call orchestration cannot fit inside that budget.
- G5
Weekly spec churn warns fine-tune. A specification that changes weekly is a soft warning on fine-tuning: retraining outruns the point where it pays back.
- G6
Open-ended needs more data. An open-ended task without 5,000 or more labeled examples is a soft warning on fine-tuning: it needs far more training data than a narrow one.
- G7
No MLOps warns self-hosting. No dedicated MLOps maturity, outside a pure cloud-API deployment, is a soft warning on fine-tuning: self-hosting needs capability the team has to build first.
- G8
Two-week deadline warns fine-tune. A two-week time-to-first-value requirement is a soft warning on fine-tuning: data collection alone takes longer than that.
- G9
Accuracy floor warns any path. A soft warning on any path whose best-case accuracy lands below the floor you set. Plan for a human review step, or revisit the floor.
- G10
Side effects, no prompt plus RAG. A task that needs to execute actions with side effects, or hold long-horizon state, removes prompting with retrieval: it can look things up, but it cannot take those actions or carry that state on its own.
The procedure, step by step
- Run the ten gates above against your inputs. Hard gates eliminate paths; soft gates attach warnings.
- For every path with no hard gate against it, estimate a total cost of ownership over your horizon: a one-time build cost, plus for each month that month's volume times cost per task, plus monthly maintenance, plus that month's error cost (volume times the path's error rate times your cost per error). Compute three bands, optimistic, middle, and pessimistic, and report every figure as a low to high range, never a single confident number.
- Rank the viable paths by middle-band cost, cheapest first. If agents and hybrid are both viable, and agents is cheaper in the first few months but hybrid is cheaper across the full horizon, recommend hybrid, that is, build the agent system now and distil later. Applied last: if prompting with RAG is viable and within 15 percent of the cheapest ranked path on the middle-band cost, recommend it instead, because ties go to doing less.
- Call the result a close call rather than a clear win when at least two viable paths land close to each other on the middle-band cost, close enough that the gap sits inside the model's own margin of error.
- If hybrid is viable, name the monthly task volume at which it overtakes agents as a range, never a single point, because the agent call count behind that crossover can swing by nearly an order of magnitude. If hybrid already wins at low volume, say so. If it never overtakes agents, say there is no crossing.
- If every path is hard-eliminated at once, which only happens when a sub-second response is required for a task that also needs several orchestrated steps, do not force a recommendation. Say plainly that the constraints conflict, and that the fix is to relax the latency budget or reduce the task to a single step.
The MLDeep Fine-tune vs Agents Framework
The same logic this calculator runs, written up so you can walk any stakeholder through the decision. Free, no email required.
Get the framework (PDF)The six numbers that move the answer most
Vendor prices are verified from the source, dated below. Day rate and labeling cost are the reader selectable defaults, yours to change in the calculator above. The accuracy floor is the default threshold; you set your own per case. The full set of assumptions, including our reasoned estimates, is in the expandable table below.
| Assumption | Low | Mid | High | Source |
|---|---|---|---|---|
| Frontier model token price, input / output per million tokens | $2 / $10 | $5 / $25 | $10 / $50 | Anthropic Claude API pricing, read 2026 08 13. Claude Sonnet 5 at the low end, Claude Opus 5 at mid, Claude Fable 5 and Claude Mythos 5 at high. |
| GPU hourly rate, self hosted training class (80GB and up) | $1.39 | $2.89 | $4.39 | RunPod on demand GPU pricing, Secure Cloud Pods, read 2026 08 13. NVIDIA A100 80GB at low, H100 80GB at mid, H200 at high. |
| Training run cost, managed fine tuning | $4.00 | $7.50 | $14.50 | Together AI fine tuning pricing, read 2026 08 13. A representative 5 million token training job priced across the vendor's three published model size tiers. |
| Engineer day rate (specialist consultancy preset, reader selectable) | $1,200 | $1,800 | $2,600 | MLDeep internal estimate, presented as a choice rather than an assertion. Two other presets are offered in the calculator above. |
| Cost per labeled example (outsourced vendor preset, reader selectable) | $0.30 | $1.00 | $3.00 | MLDeep internal estimate, presented as a choice rather than an assertion. Two other presets are offered in the calculator above. |
| Accuracy floor (default threshold, reader adjustable) | 90 percent | MLDeep default. You set your own floor per case with the slider in the calculator above; a soft warning attaches to any path that lands below it. | ||
Assumptions and sources (version )
Every number this tool uses, where it came from, and when it was last checked.
Vendor prices are verified from the source. Your own inputs (like day rate) are yours to change. The rest are our reasoned estimates, not measured values.
| Assumption | Low | Mid | High | Source |
|---|