When it's worth fine-tuning a model

Fine-tuning is worthwhile if two tests are passed and a solid reason supports it. The tests determine: Is your problem behavior rather than a lack of knowledge, and is your base model already capable of the task in principle? If one test fails, training will not help. As for the reason, one of three is enough: reliability, unit price at volume, or ownership.

Having your own model sounds like the thorough solution, and if the tests and reason align, indeed it is: a small, fast model that solves your task more reliably than a standard model. If they do not align, this only becomes apparent after months, and by then it has been expensive. This article brings together the five points that allow you to clarify this beforehand, and identifies for each one how you can recognize the answer.

The foundation consists of twelve published papers, eleven of them peer-reviewed and ten appearing at NeurIPS, ICLR, EMNLP, or TMLR, along with the providers' public price lists. All sources were individually retrieved on September 16, 2026. Where research speaks against fine-tuning, it is presented here just as much as the opposite.

Terms: Baseline is the measured state before any change. Test set is the set of cases on which measurements are made. Teacher is a larger model that provides a smaller one with answers to learn from. SFT (Supervised Fine-Tuning) is training on predefined sample answers. LoRA trains only small additional matrices instead of all weights; their size is determined by the rank, and the result is called an adapter. Retrieval means attaching the matching documents to the model at runtime, usually implemented as RAG. Distillation is the training of a small model on the answers of a larger one. An epoch is a complete run through all training examples.

The Essentials in Brief

• Two tests decide whether training can work, three reasons whether it is worth it. If you do not pass the tests, training will not help. If you pass them, one of the three reasons is sufficient: reliability, unit price at volume, or ownership.

• The strongest reason is usually reliability, not cost. Where an incorrect result is expensive, such as with a deadline or a classification with liability consequences, this reason alone is enough. A volume argument is not needed for this.

• Training changes behavior, not knowledge. Ovadia et al. compared fine-tuning and retrieval on the same tasks. Retrieval won almost consistently; the authors summarize it as a consistent advantage. On Llama2, training pushed the result from 0.353 down to 0.219, well below the baseline.

• There is a diagnostic that predicts whether training will take hold. Have the hardest cases solved a hundred times. If the model solves each one at least once, but unreliably, training will work. If it never solves it, training will not work.

• Check prompt and output format before booking the GPU. In Tam et al., Claude-3-Haiku fell from 86.51 to 23.44 percent on a math task solely due to a format constraint. In a measurement, such drops look like a lack of capability.

• Reinforcement learning makes capabilities more reliable, it does not create new ones. Yue et al. show in a paper accepted as an Oral at NeurIPS 2025, measured on math, code, and visual reasoning tasks: Trained models win on the first attempt, while the untrained base model achieves the higher value with many attempts. The base model is the upper limit.

• You need fewer data than expected. Zhou et al. achieved, with 1,000 curated examples, that human evaluators rated the answers as equivalent or better in 43 percent of comparisons against GPT-4. OpenAI recommends 50 as a starting point.

• Data quality measurably beats data quantity. Chen et al. filtered 52,000 training examples down to around 9,000 and achieved a better model than with the full set, with a training time of 14 instead of 80 minutes for the 7B variant.

• There are three operational paths, not two. Fine-tuning via the model provider's API, running an open model yourself, or having an open model run as a dedicated endpoint. Only in the first case do the weights not belong to you; only in the second case do you have the burden of operation.

• Open models in Europe are significantly cheaper than frontier APIs. A Llama 3.3 with 70 billion parameters costs $0.71 per million output tokens at IONOS, while Gemini 3.8 Flash costs $3.75 at Google. Anyone arguing on price has room to maneuver here.

• Safety properties do not survive training automatically. Qi et al. measured an increase in harmful outputs from 5.5 to 31.8 percent after one epoch on the harmless Alpaca dataset. This needs to be remeasured after every run.

Table of Contents

1. Two Tests and Three Reasons

2. Test 1: Fine-Tuning or RAG? Behavior vs. Knowledge

3. Test 2: Can Your Base Model Do the Task in Principle?

4. Reason 1: Reliability on Your Task

5. Reason 2: Volume and Unit Price, Three Operational Paths Compared

6. Reason 3: Ownership and Independence

7. How Much Data You Need

8. Three Side Effects and What to Do About Them

9. How to Recognize a Solid Offer

10. How We Go Through This With You

11. Frequently Asked Questions

12. Sources

Two Tests and Three Reasons

The most common misconception about this decision is that everything must come together. That is not true. Two points are tests you must pass, otherwise training cannot work at all. The remaining three are reasons, and only one of them needs to be strong enough.

The difference is practical. Those who do not pass the two tests should not start a training project, even if all three reasons speak for them. On the other hand, those who pass them do not need all three reasons, but one that is heavy enough. A health insurer with three hundred processes a day has no volume argument but still a very good reliability argument.

Test 1: Fine-Tuning or RAG? Behavior vs. Knowledge

A language model acquires its knowledge during pre-training. What comes after changes little about that, but all the more about how reliably it retrieves what is known and in what form it responds. This results in a clear mapping.

For the first row, there is the cleanest measurement available on this topic. Ovadia et al. had fine-tuning and retrieval compete against each other on the same tasks with the same models, using facts that emerged after pre-training.

Retrieval wins clearly in all three cases, and almost consistently across the other tasks of the paper. On Llama2, training even pushed the model below its starting point. The authors tested unsupervised fine-tuning, i.e., further training on raw text; part of the gap is due to this method. To be fair, they were able to repair the drop themselves: If you train on multiple reformulations of the same facts, all three models are above their baseline again. Still, they do not catch up with retrieval.

The explanation is provided by Gekhman et al. in a paper accepted at EMNLP 2024. They show two things: A model learns training examples that introduce new knowledge significantly slower than those that fit its existing knowledge. And as soon as it has learned them, its tendency to hallucinate answers increases linearly. The model not only learns the facts, it also learns to answer confidently when it does not know something.

The question “Fine-tuning or RAG” is therefore incorrectly posed. Factual knowledge belongs in retrieval because it can be updated there without retraining. Rules, format, and taxonomy belong in the model because they are available there for every query without context costs. A project that cleanly separates both becomes cheaper and better than one that throws everything into one pot.

The intermediate step that almost everyone skips

Before claiming row three or four for yourself, test row two to the end. Format problems look exactly like a lack of capability in a measurement, and they are orders of magnitude cheaper to fix.

How large this effect can get was systematically measured by Tam et al. in a paper accepted in the Industry Track at EMNLP 2024. Same models, same tasks, once in free text and once with a forced JSON schema:

A 63 percentage point drop for Claude-3-Haiku, without anything else in the task having changed. Anyone who measures in this situation and mistakes the value for a lack of capability commissions a training project for a problem that an afternoon would have solved.

The effect also goes in the other direction: On a classification task, Gemini-1.5-Flash rose from 41.6 to 60.3 percent through the same format constraint because it restricts the response space. And the authors were able to name the mechanism. In GPT-3.5-Turbo, on one of the tasks in JSON mode, 100 percent of the responses placed the key answer before the key reason. The model then answers first and justifies afterward, so the reasoning can no longer influence the result.

The order of the fields in your schema is therefore a lever that costs nothing. The measurements date from 2024, and providers have since improved their methods for formatted output. However, the mechanism is structural in nature and still applies.

Test 2: Can Your Base Model Do the Task in Principle?

This is the question where most projects guess, and where it is not necessary. There is a measurement that answers it, and it takes hours.

The procedure is called pass@k. The k stands for the number of attempts you grant the model.

For diagnostics, you turn up the temperature, i.e., the parameter that controls how much the model may deviate from the most probable word. Then a slightly different answer comes out with each attempt. That is the whole trick: you do not want to know what the model says this time, but what it can say at all if it is allowed to try often enough.

So take your hardest cases, say about twenty, and have each solved a hundred times. This yields 2,000 answers. From this, you read two numbers, and both deliberately count different things.

pass@1 counts answers. Out of all 2,000 answers: How many were correct? This is the hit rate of a single run under measurement conditions. In production, you run a lower temperature and usually perform slightly higher; so the measurement is on the conservative side.

pass@100 counts cases. Of your twenty cases: For how many was at least one among the hundred attempts correct? This is the upper limit of what is within the model.

A calculation example. One case is solved correctly in 11 out of 100 attempts, another in 83 out of 100. For pass@1, the 11 and the 83 count individually: 94 correct answers out of 200 attempts, or 47 percent. For pass@100, only the fact that at least one hit was included in both counts, so both cases count fully: 100 percent. The gap between 47 and 100 is exactly the span that training can close. That is why pass@100 is never below pass@1.

Thus, the two numbers separate the only question that matters here: Is the model incapable, or is it capable and just not hitting consistently? In the first case, capability is lacking, which training cannot generate. In the second case, consistency is lacking, and that is exactly what training brings.

That this interpretation holds is well-supported. Yue et al. showed in a paper accepted as an Oral at NeurIPS 2025 that trained models beat their base model on one attempt, but the base model achieves the higher pass@k value over many attempts. Their conclusion: capabilities originate from the base model and are limited by it. Six common reinforcement learning methods behaved the same in this regard. Distillation from a stronger teacher, on the other hand, was able to introduce new patterns and actually expand capabilities. So whoever hits the ceiling of their base model has a second lever here and not the end of the line.

Brown et al. show the same structure from the other side, and their result is a success, not a warning sign. A model without task-specific training, DeepSeek-Coder-V2-Instruct, solved 15.9 percent of cases on the SWE-bench Lite benchmark on one attempt, and 56 percent on 250 attempts. With this, it significantly exceeded the then-best value of 43 percent for a single attempt. So the capability was long present, only access to it was missing, and that access is exactly what training creates.

Their caveat is practically important: this is only useful if an automated checker recognizes the correct answer among the 250. If you can build such a checker, multiple attempts plus a checker may solve your problem cheaper than a trained model. This is an option that rarely appears in any proposal.

Reason 1: Reliability on Your Task

This is the reason that regularly gets lost in cost comparisons, and for many applications, the only one that truly counts. Training turns a model that sometimes solves your task into one that solves it reliably.

How large this gain turns out for you is what you already measured in Test 2. This gap is the span by which training can raise reliability. A model that solves the hardest cases correctly in 47 out of 100 attempts, and at least once in 100 out of 100, is fully capable of the task. It just retrieves it unreliably, and that is exactly what training works on.

The crucial question, which is in no cost calculation, is: What does an incorrect result cost you? For an internal search function, an error rate of ten percent is a nuisance. For a transaction classification tied to a deadline, it is a liability issue. Where an error is expensive, the quality gain justifies training even if the unit price is above that of an API. This reason stands completely independent of volume.

Two orders of magnitude from research on what is achievable here. Zhou et al. brought a model with 1,000 curated examples to the point where human evaluators rated its answers as equal or better in 65 percent of comparisons against DaVinci-003. Chen et al. achieved over 90 percent of the performance of their teacher model with 9,000 filtered examples. Neither of these are year-long projects.

The limitation is part of it, and it is the same as in Test 2: training does not go beyond the ceiling of the base model; it raises the floor. If you lack the floor, this is the right lever. If you lack the ceiling, you need a stronger base model or distillation from a larger teacher.

Reason 2: Volume and Unit Price, Three Operational Paths Compared

This question can be answered at your desk and ends more projects than any other. There are three ways to run a fine-tuned model, and they differ less in quality than in who has the work and who ends up owning something.

Path 3 is regularly forgotten in comparisons, although it resolves the disadvantages of the other two. You get a model whose weights belong to you without running a serving stack yourself, monitoring cards, or getting up at night during load peaks. You pay for capacity, not consumption, and that is exactly why the calculation behaves differently than with Path 1.

Each of the three paths has an item that rarely appears in offers. One by one.

Path one, fine-tuning with an API provider. This path is currently losing ground. OpenAI is winding down its own fine-tuning platform: according to the pricing page, new users no longer get access, existing ones can still start training runs for a few months, and already trained models remain retrievable only as long as their base model exists.

And OpenAI is not alone. Mistral has also deprecated fine-tuning: the documentation carries the note “deprecated and no longer actively supported” and is now in the archive section. Technically, the jobs still run, but no shutdown date has been published.

At Google and via AWS Bedrock, the path continues without restriction, and training runs can also be calculated in advance there: both show training prices on their cloud pricing pages, depending on the model as a price per thousand tokens or per training hour. Check this for your desired model; the specifications differ significantly within the same provider, and are missing for some of the models.

What remains the same for all providers: the result is a right of use on a third-party platform, and someone else decides what happens to this platform. Two discontinuations within a year demonstrate exactly that.

Path two, running an open model yourself. Here, the token price disappears and is replaced by an hourly price. Examples from published European price lists, retrieved on September 16, 2026, net and in the currency in which the provider lists them:

For context, a third set of numbers, which is neither Path 2 nor Path 3, but marks the lower limit of your bill: what an open model costs without own training at a European provider via a shared API. At IONOS AI Model Hub, that is $0.11 per million input tokens and 0.17 for output for a 9B model. A Llama 3.3 with 70 billion parameters costs $0.71 there, same for both directions.

The 0.71 is worth a moment. Gemini 3.8 Flash costs $3.75 per million output tokens according to Google's price list, which is over five times as much. That is a temporary introductory price; the same page lists double that value starting January 1, 2027. The gap lies on the output side: for input tokens, both are close with 0.75 versus 0.71. The comparison is deliberately skewed, as the Llama is not trained on your task and runs on shared infrastructure. That is exactly why it is useful: it shows how much leeway lies between the price level of open models in Europe and a frontier API. Anyone arguing on price must fill this leeway with quality. Anyone arguing on reliability or ownership does not need to.

If you host yourself, utilization decides, completely. You can set up the calculation for this without outside help: hourly price divided by the number of documents your card manages in an hour. This second number is what you have to measure; it depends on model size, response length, and batch size. What is regularly overlooked here: without batching, i.e., without multiple requests running through the card at the same time, throughput is significantly lower. A GPU waiting for requests costs the same as one that is working.

From this follows the actual rule of thumb: not the model size decides the economic viability, but whether your load is predictable enough to keep the card busy continuously. For a few hundred documents a day, a shared API is correct, where you only pay for consumption. For a few hundred a minute, it is not.

Path three, the same hourly price without the operation. A dedicated endpoint follows the same calculation as Path two, because you pay for capacity there as well. What drops out is the item that hardly any project plan contains: setting up and keeping the serving stack up to date, monitoring utilization, scaling, on-call duty. What is added is the service provider's margin. Whether this is worthwhile is a calculation of person-days, not tokens, and it turns out all the clearer the smaller your platform team is. There is no solid threshold for this; it depends on your team.

What you should watch out for: a dedicated endpoint is only Path three and not disguised Path one if the weights belong to you and you can export them at any time. Ask about this explicitly before you sign.

Reason 3: Ownership and Independence

This reason is not a measurement, but a decision, and it is often posed too late. Fine-tuning over a third-party API results in a model that you can use but cannot download. An open base model results in a file.

For regulated industries, the third row often clarifies the decision before the cost calculation even begins. For professional secret-keepers, dedicated inference is structurally easier to justify than a chain of providers, because there is nothing to obligate where no one is. Anyone using OpenAI, Claude, or Gemini from within Europe can find the classification of delivery paths in our post on OpenAI, Claude, and Gemini in Europe.

A side note with cost consequences: Mistral shows a 10 percent surcharge for regional inference on its own pricing page. So sovereignty has a price, but it is usually smaller than it appears in discussions.

To be honest, the answer to this question is no for many applications, and then an API is the right solution, permanently and not temporarily.

How Many Data You Need

Hardly any assumption about fine-tuning persists as stubbornly as the one that tens of thousands of examples are needed. Research says the opposite, multiple times independently.

The work of Chen et al. is the cleanest evidence for “quality over quantity” because the same data source was used once with and once without filters. Evaluation was predominantly performed by a language model, backed by a small user study and four benchmarks. The evaluation prompt explicitly instructs the judge not to consider response length.

Notable is the advice OpenAI gives in case 50 examples do nothing: then one should reconsider the task formulation or prompt instead of collecting more data. The recommendation applies regardless of which platform you ultimately train on. That is Test 1 in other words, formulated by a provider that profits from selling training runs.

So the actual effort lies not in quantity, but in ensuring that the target answers are correct. If you do not want to write them yourself, you can use a larger model as a teacher. Which model is legally permissible for this is a separate question: Anthropic, OpenAI, and Google prohibit in their terms the training of competing models on the outputs of their commercial models. For Google's open Gemma weights, this explicitly does not apply; Gemma 4 is under Apache 2.0. Which clause is where has been compiled in our post on providers' distillation clauses. Anyone using real business data as training material also clarifies beforehand why automatic redaction of personal data alone is not sufficient.

Three Side Effects and What to Do About Them

Training has side effects. All three are well researched, all three are treatable, and none of them is a reason to avoid it. They are a reason not to do it on the side. Therefore, they are listed here with the respective countermeasure.

First: Safety properties are not automatically inherited. Anyone fine-tuning a model with safety alignment does not get this alignment automatically. Qi et al. quantified this in a paper accepted at ICLR 2024, specifically for ordinary, harmless training datasets after a single epoch:

Countermeasure: The safety check belongs in the eval run after training, just like the functional check. This is an additional test step, not a project risk. To contextualize the numbers: they originate from model generations of 2023, and a model evaluated against its own taxonomy. The scale is still too clear to be explained by measurement noise.

Second: A model can lose what it could do before. This is researched under the name Catastrophic Forgetting. Luo et al. found it consistently in the range of 1 to 7 billion parameters, with the counterintuitive addition that it increases with model size there.

Countermeasure: the choice of method. Biderman et al. quantify in a paper published in TMLR how much difference this makes: after instruction tuning on code, general capabilities were at 0.510 with LoRA versus 0.414 with full fine-tuning, measured at rank 64 after 16 epochs. The values are hit shares on general benchmarks, so the gap corresponds to about ten percentage points. Anyone who chooses LoRA has already solved a good part of the problem before it occurs.

Third: LoRA itself has a limit, and it lies in the data volume. The same work shows where. During true domain training over 20 billion tokens, LoRA was at 0.202 versus 0.293 for full fine-tuning on a math task, and at 0.224 versus 0.263 on a programming task. For instruction tuning on around one hundred thousand examples, however, LoRA caught up with high rank (256), but not with low rank.

Countermeasure: choose the method and rank matching the data volume. For task-specific training in usual sizes, LoRA is the right choice; bringing in an entire specialist domain over billions of tokens is something else and needs something else.

A detail in case you want to continuously retrain: Shuttleworth et al. show that LoRA, especially at low rank, creates structures in the weights that full fine-tuning does not, and that these accumulate over multiple successive runs. At high rank, the effect largely disappears. Less forgetting on a single run, potentially more on repeated cycles. This does not contradict Biderman, it complements him, and it is an argument for tracking eval results across runs instead of just per run.

In summary: three times a decision in setup, not three times a reason for caution. Measure safety after each run, choose LoRA instead of full fine-tuning, and match rank and method to data volume. That is craftsmanship.

How to Recognize a Solid Offer

Suppose the tests are passed, a reason supports it, and you gather proposals. Numbers on model quality are cheap, almost every demonstration shows an improvement, and many of these are generated by the measurement procedure. This checklist helps with sorting them out. Hold it against any provider, including us.

How We Go Through This With You

The two tests are described in such a way that your team can perform them themselves. Most teams do not fail because of the procedure, but because of building a test set they actually believe afterwards.

If you do not want to do it yourself, we do exactly that: test set from your real cases, with your domain experts as graders, baseline against a strong model with a fair prompt, pass@k on your hardest cases. After that, you know whether a training project is worthwhile and have a test set that you need anyway, regardless of how the decision turns out.

In the system of Reason 2, we are Path three: we train an open model on your task and operate it as a dedicated endpoint, behind an OpenAI-compatible API. You do not get a right of use, but the model.

Three commitments that make the difference: training and operation are done on dedicated GPUs in the EU, without US hyperscalers in the chain. Weights, eval set, and documentation belong to you, with export at any time. And no model goes into production without an eval gate, every rollout as an A/B test with rollback. The DPA stands before the first data record. Everything else, from the OpenAI-compatible API to the audit log, can be queried in the checklist above.

The first step is a conversation about your task: 30 minutes, engineering is present, no pitch. If it turns out that a prompt or a retrieval system solves your problem and no training, we say so in the conversation. Schedule an appointment.

Frequently Asked Questions

What is the difference between fine-tuning and RAG?

Fine-tuning changes weights and thus behavior, format, and consistency. RAG leaves the model unchanged and attaches the matching documents at runtime. As a rule of thumb: what can change belongs in retrieval. What should always remain the same belongs in the model.

How do I recognize that fine-tuning will not help?

By two signals. First, if the missing information was never in pre-training, such as your product data or contract content. Second, if the base model never solves the hardest cases even in a hundred attempts. Then capability is lacking. Yue et al. show for reinforcement learning that it does not generate new ones, but only retrieves existing ones more reliably.

How quickly do I know if it works for us?

The diagnostic from pass@1 and pass@100 takes hours and costs a few euros in model calls. Upstream is only the construction of a test set from your real cases, and you need that anyway, regardless of the decision.

How many examples do we need?

Fewer than usually assumed. OpenAI calls 50 carefully created ones a starting point, Zhou et al. achieved results with 1,000 curated examples that human evaluators rated as equal or better in 43 percent of comparisons against GPT-4. Crucial is that the target answers are correct.

Is LoRA enough or do we need full fine-tuning?

For task-specific training, much speaks for LoRA, especially the lower loss of general capabilities. One limitation: Biderman et al. did not measure small datasets; their smallest case is around one hundred thousand examples, and there LoRA only drew equal at a high rank.

What does fine-tuning bring in the best case?

A small, specialized model that solves your task as reliably as a significantly larger one and is owned by you. Zhou et al. achieved, with 1,000 curated examples, that human evaluators rated the answers as equal or better in 65 percent of comparisons against DaVinci-003. Chen et al. came to over 90 percent of the teacher model's performance with 9,000 filtered examples.

At what volume does own hardware pay off?

That depends on utilization, not the model. An hourly price continues to run whether the card works or waits. Calculate hourly price divided by documents per hour and compare with the token price of your provider. Without batching, throughput is significantly lower, so measure it in batched operation.

Can we run the model ourselves afterward?

Yes, for open base models with a suitable license. The result of a LoRA run is an adapter that is orders of magnitude smaller than the base model, plus protocol, eval results, and model card. With fine-tuning over a third-party API, you get a right of use on their platform instead.

Sources

• Ovadia et al., “Fine-Tuning or Retrieval? Comparing Knowledge Injection in LLMs” (EMNLP 2024): controlled comparison on factual knowledge

• Gekhman et al., “Does Fine-Tuning LLMs on New Knowledge Encourage Hallucinations?” (EMNLP 2024): why factual knowledge belongs in retrieval

• Tam et al., “Let Me Speak Freely? A Study on the Impact of Format Restrictions” (EMNLP 2024 Industry Track): format specifications and field order

• Yue et al., “Does Reinforcement Learning Really Incentivize Reasoning Capacity in LLMs Beyond the Base Model?” (NeurIPS 2025, Oral): pass@k and the upper limit of the base model

• Brown et al., “Large Language Monkeys: Scaling Inference Compute with Repeated Sampling” (arXiv:2407.21787): latent capability versus reliability

• Zhou et al., “LIMA: Less Is More for Alignment” (NeurIPS 2023): 1,000 curated examples as a reference point

• Chen et al., “AlpaGasus: Training A Better Alpaca with Fewer Data” (ICLR 2024): data quality versus data quantity

• Qi et al., “Fine-tuning Aligned Language Models Compromises Safety, Even When Users Do Not Intend To!” (ICLR 2024, Oral): safety degradation through harmless training

• Hu et al., “LoRA: Low-Rank Adaptation of Large Language Models” (ICLR 2022): the method behind the adapter

• Biderman et al., “LoRA Learns Less and Forgets Less” (TMLR): LoRA versus full fine-tuning

• Shuttleworth et al., “LoRA vs Full Fine-tuning: An Illusion of Equivalence” (NeurIPS 2025): counter-finding on forgetting with repeated training

• Luo et al., “An Empirical Study of Catastrophic Forgetting in Large Language Models During Continual Fine-tuning” (IEEE/ACM TASLP 33, 2025): forgetting in the range of 1 to 7 billion parameters

• OpenAI, Supervised Fine-Tuning Guide and API Pricing: minimum example numbers and the notice on the wind-down of the fine-tuning platform

• Scaleway GPU Prices, OVHcloud Public Cloud Prices, IONOS Cloud Prices and Mistral API Prices and Mistral Fine-Tuning Documentation (the deprecation notice there), Gemini API Prices, Google Cloud, Prices for Model Tuning and AWS Bedrock Prices: comparative values and training prices

• The Evals Guide: construction of test sets, scorers, and statistical evaluation

Status: September 16, 2026 · kontinent.ai. All percentage values originate from the cited publications and apply to the models and tasks tested there, predominantly from the years 2023 to 2025. Pricing details were retrieved on September 16, 2026 from the providers' pages and are subject to change. Not legal advice.