Engineering

Fine-tuning is closing at OpenAI: what a funded startup should build its AI feature on

Editorial · Reveneau · October 27, 2026

Fine-tuning is closing at OpenAI: what a funded startup should build its AI feature on

If you raised a seed or Series A round this year with a plan to fine-tune a model for your product, read two pages before you spend that part of the budget. On 26 October 2026 we read OpenAI's pricing page, which says: "OpenAI is winding down the fine-tuning platform. The platform is no longer accessible to new users, but existing users of the fine-tuning platform will be able to create training jobs for the coming months." Google's Gemini API documentation says that since May 2025 "we no longer have a model available which supports fine-tuning in the Gemini API or AI Studio."

Fine-tuning means training a provider's model further on your own examples, so that it gives the answers you want with shorter instructions. For a startup that signs up with OpenAI or the Gemini API today, that option is gone from the self-serve product.

Our view is that the thing a startup should build is its set of examples: real inputs, each paired with the answer it wants. Keep that set in your own files and use it in three places: inside the prompt, inside the eval suite, and as a ready training file if a later decision calls for tuning.

What changed, with the dates

OpenAI's deprecations page gives three dates:

Date What OpenAI's deprecations page says
7 May 2026 Organizations that have never run fine-tuning can no longer create fine-tuning jobs
2 July 2026 Organizations that have not used a fine-tuned model in the past 60 days can no longer create jobs
6 January 2027 Active existing customers can no longer create new fine-tuning jobs

Models already tuned keep answering for a time. The same page says "Inference on fine-tuned models will continue to be available until the base models are deprecated." Inference means using a model to produce answers. The base model is the provider's model that your tuned version was built from, and a deprecated model is one the provider has scheduled for retirement.

Google still offers tuning, on a different product. Google Cloud's documentation lists supervised tuning, which means training on pairs of example inputs and wanted outputs, for six Gemini models, among them Gemini 3.5 Flash and Gemini 2.5 Pro. The Gemini API itself has none, and Google says "We don't have immediate plans to bring fine-tuning support" back to it.

Anthropic's developer documentation index, read the same day, lists no page about fine-tuning. That result covers Anthropic's own documentation only. We did not check what other clouds offer for Anthropic's models.

The guide page API or your own model compares every option in detail. This post covers one decision: where the work you would have put into tuning should go now.

1. The examples are what you keep, so they live in your repository

On OpenAI, a tuned model keeps answering only until its base model is deprecated. The deprecations page gives an example: "The gpt-5.4-cyber model is deprecated and will be removed from the API on October 1, 2026." Every product built on a retired model has to move to another one.

The examples keep their value through every one of those moves. Take an invented case: a set of 300 customer support emails, each paired with the reply your best support person would send. That set works with any model. You can paste ten of them into a prompt. You can run all 300 as tests. You can upload them to a tuning service on another platform if you ever need one.

How many should you collect? Google Cloud's tuning guide gives a number: "For best results, provide at least 100 to 500 examples." We would use that range as the target even when no tuning is planned, because a set of that size also works as an eval suite. Evals are written, repeatable tests of a model's answers.

Keep the set in your own code repository, next to the code. OpenAI's deprecations page says its Evals dashboard and API "are scheduled to shut down" on 30 November 2026. A team that kept its test cases only inside that tool has to export them before then. A team that kept them as files in its repository has nothing to do.

2. Put the best examples in the prompt, and use caching to lower the cost

OpenAI's guide to model optimization starts with instructions, before any training. It says: "The prompt engineering process may be all you need in order to get great results for your use case." Prompt engineering is the work of writing and testing the instructions sent with each request, and adding a few of your best examples to them is part of that work.

Examples make every request longer, and providers charge by the token, the small piece of text (a word or part of a word) that they count to set prices. Prompt caching lowers that cost. Caching means the provider stores part of a request that repeats and charges less when the same part is sent again.

  • OpenAI's caching guide says "Prompt caching is enabled by default for supported OpenAI models", and that reused input tokens are "discounted up to 95%". Its minimum cacheable prompt is 1,024 tokens for GPT-5.6 and later.
  • Anthropic's pricing page says "A cache hit costs 10% of the standard input price", and 5% on Claude Opus 5.5 and Claude Sonnet 5.5. A write to its 5-minute cache costs 1.25 times the base input price, which Anthropic says pays off after one cache read.

Here is an invented example to show the arithmetic, using Anthropic's prices read on 26 October 2026. A feature sends 3,000 tokens of fixed instructions and examples with every request, and it handles 100,000 requests a month. That is 300 million input tokens. At Claude Sonnet 5.5's base input price of $2 per million tokens, they cost $600 a month. Read from the cache at $0.10 per million, they cost $30, plus the cost of writing the cache, which depends on how often requests arrive. The user's own text and the model's answer are billed on top in both cases.

Check one limit before you count on that saving. Anthropic's caching documentation says requests to cache fewer tokens than its minimum "are processed without caching, and no error is returned." The minimum is 512 tokens on its newest models. Check the cache figures in your provider's usage data in the first week, or a short fixed prompt is billed at the full price with no warning. The guide page on what an AI feature costs to run has the full price tables for all three providers.

3. Let the eval suite decide when to tune

Tuning is still the right choice in some cases, and our rule for spotting them has two conditions: the eval suite shows a gap that better instructions and examples have failed to close, and a provider still offers tuning for the model you need.

The rule depends on having the suite first. With 100 to 500 cases scored against the answers you want, a gap is a number you can point to, and so is the effect of each change you try. Without the suite, "the model is not good enough" is an opinion, and tuning spends money on it.

When the suite does show a gap, there are three routes, and the same examples feed each one:

  • Tune on a platform that still offers it. Google Cloud lists supervised tuning for Gemini models. Read the data terms first: Google's Gemini API terms say "Google only uses content that you import or upload to our model tuning feature for that express purpose."
  • Run an open-weight model. An open-weight model has its trained values published, so you can run it on servers you control. OpenAI's gpt-oss-120b model card lists the Apache 2.0 licence and says the model fits on a single GPU (the type of chip that runs AI models) with 80GB of memory. Meta's Llama 3.1 licence requires a separate licence from Meta for a product with more than 700 million monthly active users. Read the licence of the exact version you use.
  • Change hosted models. Run the same suite against another model. If it passes more of your cases, move to it.

The providers' terms add two checks. If you plan to use one provider's answers as training examples for another model, read that provider's terms on the point first. Anthropic's commercial terms say a customer may not use its services "to build a competing product or service, including to train competing AI models". And OpenAI's pricing page says "Inference discounts are available if you enable data sharing when creating the fine-tune job." That lower price is paid with your data, so treat it as a question about your customers' data before you treat it as a price.

The case for keeping a tuned model

A founder who tuned a model on OpenAI last year will disagree with part of this. The tuned model works, the instructions are shorter because of it, and active customers can still create jobs until 6 January 2027. That is a fair position, and the tuned model can stay in production while you test.

We would still use the months before January for two tasks. Export the training examples into the repository as eval cases. Then run them against at least one hosted model with examples in the prompt. If the hosted model passes the same cases, the product has a tested option before the base model's retirement date. If it fails some of them, you know which cases need a tuned model, and you can price tuning on a platform that still offers it.

The order we would build in

Collect the examples. Turn them into an eval suite in your repository. Put the best of them into the prompt and confirm in the first week that caching works. Change approach only when the suite gives a reason. The guide on building your AI product after you raise covers the rest of the first year, and the page on provider terms and data use sets out what each provider keeps and for how long.

Reveneau is an AI software development consultancy with offices in San Francisco and Vancouver. Reveneau says AI writes all of its code and every change must pass an eval suite written from the specification. It says Jev, TypeSafe AI's decision model, grades that suite, and that the suite runs ten times faster than it did with its previous grader.

Credit for the facts in this post goes to the documentation teams at OpenAI, Google, Anthropic and Meta, who publish their dates, prices and licence terms in plain text that anyone can check.

A tuned model lasts as long as its base model. A good set of examples works with every model you test after it.

Sources

Common questions

What should a startup do with the examples it collected for fine-tuning?

Keep them in its own code repository and use them three ways: a small sample inside the prompt, the whole set as eval cases, and the same set as a training file if tuning is ever needed. Examples of real inputs paired with the answers you want keep their value when a provider closes a service or retires a model, because every model can be tested against them.

How many examples should a startup collect before it decides how to build an AI feature?

Google Cloud's tuning guide says that for best results you should provide at least 100 to 500 examples, and our view is to use that range as the target even when no tuning is planned. A set that size is large enough to work as an eval suite, so it shows whether instructions alone are good enough before any money goes into tuning.

We already fine-tuned a model on OpenAI. How long can our product keep using it?

OpenAI's deprecations page says inference on fine-tuned models continues until their base models are deprecated, and it says active customers can create new fine-tuning jobs until 6 January 2027. Use the time to export your training examples as eval cases and test a hosted model with examples in the prompt, so you have a tested option before the base model's retirement date.

Do long prompts full of examples make an AI feature too expensive to run?

Prompt caching lowers the cost of the part of the prompt that repeats. Anthropic says a cache hit costs 10% of the standard input price, or 5% on Claude Opus 5.5 and Claude Sonnet 5.5, and OpenAI says reused input tokens are discounted up to 95%. Check that the repeated part is above each provider's minimum cacheable size, or it is billed at full price.

Why can a prompt that is too short cost more than expected?

Anthropic says that requests to cache fewer tokens than its minimum are processed without caching, and no error is returned. Its minimum is 512 tokens on its newest models, and OpenAI's is 1,024 tokens for GPT-5.6 and later, so a short fixed prompt is billed at the full input price on every request with no warning in the response.

Why should eval cases live in our own repository and outside a provider's tool?

A provider can close a tool on its own schedule. OpenAI's deprecations page says its Evals dashboard and API are scheduled to shut down on 30 November 2026, so cases stored only there must be exported first. Cases kept as files next to the code stay usable with any model and any test runner the team picks later.

When should a startup move from prompting to tuning a model?

Our rule has two conditions. The eval suite must show a gap on your own cases that better instructions and examples have failed to close, and a provider must still offer tuning for the model you need, as Google Cloud does for six Gemini models listed on 26 October 2026. Without both, tuning spends money on a problem nobody has measured.

Is an open-weight model a good fallback now that hosted tuning is closing?

It can be, when a customer contract requires data to stay on your servers or your measured volume favours it. OpenAI's model card for gpt-oss-120b lists the Apache 2.0 licence and says it fits on a single 80GB GPU, while Meta's Llama 3.1 licence requires a separate licence above 700 million monthly active users. Run your eval suite against it before you commit.

Does sharing data with OpenAI make a fine-tuned model cheaper?

OpenAI's pricing page says inference discounts are available if you enable data sharing when you create the fine-tune job. That lower price is paid with your data, which may include your customers' data, so decide it as a data question first, check your customer contracts, and only then look at the price.

In what order should a funded startup build its first AI feature?

Our order is four steps. Collect real examples with the answers you want, turn them into an eval suite in your repository, put the best of them into the prompt and confirm caching works, and change approach only when the suite shows a reason. Each step uses the output of the one before it, so nothing is built twice.

Start a project