ILLATE
← Engineering notes

Choosing someone to migrate your OpenAI fine-tune: 12 questions to ask

Updated 21 October 2026Sources checked 8 and 21 October 202612 questionsWritten by a vendor, our gaps included
Short answer

Ask for twelve things, in writing: an evaluation report on your own held-out test set, a test harness you can rerun without the vendor, a replacement-model recommendation that includes the options that earn the vendor nothing (GPT-5.6 Luna with a prompt, an embeddings classifier), a deployment plan, a rollback procedure that still works after 23 October 2026, per-class recall, a confusion matrix, results for rare classes, latency at p50 and p95, cost per 1,000 calls, the invalid-output rate, and how your data is handled. Whoever you hire, save your fine-tune's answers on real inputs before 23 October 2026, because after that nobody can measure a replacement against what you had.

We sell this service, so under each question we give our own answer too, including what we don't have: ILLATE is one person, holds no SOC 2, and has two public sample reports and no client results yet. The list is just as useful if you hire someone else. Already past 23 October? See the 48-hour rescue.

01 Before you ask

Three facts every good answer will respect

The weights don't move

It's a rebuild, not a transfer

OpenAI doesn't release the weights of models fine-tuned on its platform, and we found no export path on Azure either. What moves is the task: your training data, a labelled test set and your fine-tune's saved answers. Treat a promise to "convert" or "transfer" your model as a warning sign.

As of 8 October 2026

The named replacement can't be fine-tuned

OpenAI's deprecations page names gpt-5.6-luna as the replacement for fine-tuned gpt-4.1-nano, and Luna's model page lists fine-tuning as "Not supported". A public mirror of the page records three different replacements since April 2026: gpt-5-nano on 25 April, gpt-5.4-nano on 13 May and gpt-5.6-luna on 4 August (the dates are when the mirror's copy changed). gpt-5-nano-2025-08-07 itself shuts down on 11 December 2026.

Before 23 October 2026

Save your fine-tune's answers

Run it on 2,000–5,000 real inputs, chosen so rare categories are covered, in your own OpenAI organization with your own key. Record the model ID, prompt, parameters and raw output, and log its live answers until the shutdown. After 23 October 2026 nobody, you included, can ask it anything.

Sources: OpenAI deprecations, GPT-5.6 Luna model page and the change history of a public copy of the deprecations page, all checked 8 October 2026. Our step-by-step for saving answers is on the gpt-4.1-nano replacement page.

You may not need to hire anyone. If GPT-5.6 Luna with a prompt, or an embeddings classifier trained on a CPU, meets your margin on your own labelled test set, that is the cheapest answer. On simple support triage (Banking77), a bge-base embeddings classifier statistically tied our fine-tuned 4B model: 93.5% against 94.0%, a paired difference of +0.5 points (95% CI −0.3 to +1.2). On three public classification tests, GPT-5.6 Luna given the 20 most similar past examples tied our model on two and trailed by 2 points on the third. An engineer with a labelled test set can run that comparison with an open tool.

The twelve questions, to paste into an email

Send them to everyone you're considering, us included, and compare the replies side by side.

Questions for anyone offering to migrate our OpenAI fine-tune:

1. Evaluation report: will we get one on our own held-out test set, and can we see a real, unedited one first?

2. Reproducible test harness: can we rerun every number ourselves, without you?

3. Replacement-model recommendation: which options will you compare, including GPT-5.6 Luna with a prompt and an embeddings classifier, and will you recommend one that earns you nothing?

4. Deployment plan: how does it go live, what are the shadow and traffic steps, and who does what?

5. Rollback procedure: what do we fall back to after 23 October 2026, when our fine-tune no longer answers?

6. Per-class recall: will you report recall for every category, and can we set a floor for the ones that matter most?

7. Confusion matrix: will we see which categories get mistaken for which?

8. Rare classes: how are categories with few examples tested and reported?

9. Latency: what are p50 and p95, measured where, and at our peak request rate?

10. Cost per 1,000 calls: for every option, at our volume, with fixed costs shown?

11. Invalid-output rate: how often is the answer not one of our categories, and what happens then?

12. Data handling: where does our data go, who can see it, when is it deleted, and which certifications do you hold?

02 Deliverables

Questions 1–5: what you should receive

Question 1 · Evaluation report

Will we get an evaluation report on our own data, and can we see a real one first?

This is the document you'll decide on. A report on the vendor's demo data, or on a few dozen of your examples, says little about your traffic.

A good answer
  • Scored on a held-out test set of your real inputs, labelled by people or taken from your records, not by the model being replaced. At least 1,000 items, enough to tell a 3-point gap from noise.
  • Every option scored on the same items: your current fine-tune (from its saved answers), the proposed replacement and at least one cheap option.
  • Accuracy and macro-F1 with 95% confidence intervals, and a verdict against a margin agreed before the run, such as "no more than 3 points below the current model".
  • A section on where the replacement is worse, not only the total.
  • A real, unedited sample report, offered before you sign.

Be wary of one accuracy number with no interval, a test set chosen after the results were in, or "it looked right on the examples we tried".

ILLATE's answer

Yes. The check on your data is at no charge before you commit and ends in a decision report like the sample below: PASS, FAIL or INCONCLUSIVE against your margin, accuracy with 95% confidence intervals, macro-F1, invalid answers, recall for every category, and cost at your volume. It compares GPT-5.6 Luna, shown your most similar labelled examples, and an embeddings classifier too, and your fine-tune, from its saved answers. The check runs inside your cloud account or on a machine you control, so your data stays with you, and you run the Luna column in your own OpenAI organization with your own key.

What we can show you first is limited to two public sample reports, both on public consumer complaints, not a client's data. The first is unedited and not flattering: a PASS that only tied a TF-IDF baseline (−0.7 points, paired 95% CI −1.9 to +0.5), compared with that baseline alone because there was no current model. The sample decision report scores eight options on the same public CFPB data and picks GPT-5.6 Luna with the 20 most similar examples at a 3-point margin, over our own model, below about 681,000 calls a month; it scores 10 merged products, a mapping chosen after seeing the results, and says that on the 14 labels as filed the pick would be TF-IDF. We have no client reports to show yet.

Question 2 · Reproducible test harness

Can we rerun every number ourselves, without you?

There will be another deprecation. If you can't rerun the test, you can't check this vendor's work today or test the next candidate later.

A good answer
  • The test set, every model's prediction files and the scoring scripts, handed over, so anyone on your team can reproduce each number.
  • Scoring that runs on your machines, without the vendor's accounts or keys.
  • The exact prompt, settings and model ID for every prompted model, so the comparison is fair and repeatable.
  • A way to add a new candidate later and get the same report.

Be wary of numbers that exist only in a vendor's dashboard or slides.

ILLATE's answer

The paired test is open source: github.com/illate/parity. It takes JSONL files of gold labels and each model's predictions, needs no GPU or API key, returns PASS, FAIL or INCONCLUSIVE, and exits non-zero unless PASS, so it can gate a CI job. Its Banking77 example reproduces our published result. In a migration you also receive the test set and the scripts that produced every number.

Two limits. It compares one label per item by exact match, so it suits classification, routing and tagging, not open-ended text. And our training and serving scripts are not public: you receive yours with your model.

Question 3 · Replacement-model recommendation

Which replacement do you recommend, and what did you compare it with?

A vendor that sells one route tends to recommend it. Ask which options were tested, including the ones that earn the vendor nothing.

A good answer
  • A written recommendation made after testing the realistic options on your data, even when it is "use the cheap one".
  • OpenAI's named replacement, GPT-5.6 Luna, with a fair prompt: the category list, a strict schema and the most similar labelled examples. It can't be fine-tuned (Luna model page, checked 8 October 2026).
  • A classifier you own: embeddings plus a small classifier, or a fine-tuned encoder.
  • No gpt-4.1-mini fine-tune as the destination: it stops on 14 January 2027, when OpenAI removes gpt-4o, gpt-4o-mini, gpt-4.1 and gpt-4.1-mini and the fine-tunes built on them (OpenAI deprecations, notice of 14 October 2026, read 21 October 2026).
  • Azure, only if your subscription has already deployed gpt-4.1-nano. Microsoft lists it as "Deprecated", which means new customers can't create deployments, judged per subscription. Fine-tuned deployments retire on 14 October 2027 and cost $1.70 an hour each (retirement schedule and lifecycle policy and cost page, checked 8 October 2026).
  • For every option, the exact prompt or setup, and when it will next be forced to move.
ILLATE's answer

The check scores GPT-5.6 Luna with your most similar labelled examples, an embeddings classifier and a model you own on your test set. You run Luna in your own OpenAI organization with your own key, and the scoring runs on your machine or inside your cloud account, as with the Azure route below. If Luna meets your margin, we tell you to use it; you can switch yourself or buy our USD 750 fixed switch-to-Luna package, which sets up Luna with retrieved examples and tests it on your data. If an embeddings classifier is enough, we say that too.

On public test sets, measured 5–8 October 2026, in tests we pre-registered: on Banking77 support triage, GPT-5.6 Luna shown the 20 most similar labelled examples scored 93.8%, our fine-tuned Qwen3-4B 94.0% and a bge-base embeddings classifier 93.5%: a three-way statistical tie. For a task like that, we'd choose on cost at your volume, latency and control. With one fixed example of every category, Luna scored 87.2%. On CLINC150 (150 intents plus off-topic requests), Luna with examples tied ours too: 94.6% against 95.1%, with embeddings at 90.6%. On long CFPB complaints, ours led by 2.0 points, 89.5% against 87.5%, and one product accounts for more than that lead; those scores merge renamed products, a choice we made after seeing the errors. Full tables.

We can't run the Azure route ourselves: a new Azure subscription counts as a new customer. If you qualify, you train it in your own subscription and the same test scores its answers, where your data is. We don't suggest a new gpt-4.1-mini fine-tune: it would stop on 14 January 2027, and OpenAI refused our own fine-tuning job on 7 October 2026, so we can't measure one. OpenAI's Decisions API, in public beta since 6 October 2026 (OpenAI Decisions guide, checked 8 October 2026), scored 76.8% on Banking77 with the bare category names as its choices.

Question 4 · Deployment plan

How does the replacement go live, and who does what?

Most of the damage in a migration happens in the first days of real traffic, on inputs the test set didn't cover.

A good answer
  • A shadow run first: the replacement answers a copy of real traffic while users still get the old answers, and the two are compared.
  • Then staged traffic, for example 1%, 5%, 25% and 100%, with written criteria for each step: per-class recall, invalid-output rate and latency.
  • An interface you can review. With an OpenAI-compatible endpoint, the change in your code is the base URL and the model name.
  • Named owners and dates, including how much of your engineers' time it needs.
  • A plan that fits 23 October 2026: compared with your live fine-tune before that date, and with its saved answers plus a daily sample checked by a person after it.
ILLATE's answer

A full migration is planned at three to five weeks: train on your full labelled set, agree the test set and margin in writing, replay a sample of your logged traffic offline, load-test on the GPU it will run on at your peak rate, then move traffic in steps of 1%, 5%, 25% and 100% with a small control group left on your old path. You get a runbook covering rollout, the kill switch, monitoring and retraining. We need one of your engineers for about two hours a week (how it works).

So a migration that starts in October 2026 finishes after 23 October. Before that date, what fits is saving your fine-tune's answers and getting a verdict from the check, with Luna (if it met your margin) or a review queue as the stopgap.

Question 5 · Rollback procedure

If the replacement misbehaves, how do we go back, and to what?

Until 23 October 2026 the obvious fallback is your fine-tune. After that it no longer answers, so a rollback that points to it doesn't work.

A good answer
  • One configuration change that moves all traffic to the fallback, tested before cutover.
  • A fallback that still exists after 23 October 2026: a prompted model that met your margin, a review queue where low-confidence answers go to a person, or the previous version of a model you own.
  • A confidence signal, so uncertain answers go to the fallback before a user sees a wrong one.
  • Nothing in the rollback that depends on the vendor's accounts, keys or availability.
ILLATE's answer

A kill switch moves all traffic in one config change. After 23 October 2026 the fallback is GPT-5.6 Luna with the prompt tested in your check, if it met your margin, or your review queue. Our endpoint answers defer when it is unsure, and your own code sends that item to the fallback; we never hold your OpenAI key. On Banking77, set to a 99% target, it answered 80.3% of test messages at 99.1% accuracy and deferred the rest.

ILLATE is one person, so plan for that too. You keep the weights, the scripts and the runbook, and the model runs on any server that runs vLLM, so neither a rollback nor day-to-day running depends on us.

03 Measurements

Questions 6–11: what the report should measure

Accuracy alone hides most of what goes wrong in a migration. These six measurements are where problems show up first.

Question 6 · Per-class recall

Will you report recall for every category, and can we set a floor for the ones that matter?

Overall accuracy can rise while one important category gets worse. Recall for a category is the share of its real cases the model catches.

A good answer
  • Precision, recall and F1 for every category, for your current model and each candidate, with the number of test items behind each figure.
  • The categories that cost you most when missed (fraud, cancellations or legal complaints, for example) named before the run, with a minimum recall written into the acceptance bar.
  • Which categories got worse, and by how much, not only the totals.
ILLATE's answer

Every run writes precision, recall and F1 for every category as a file, available on request. The decision report shows recall for every category, for every option, weakest first, and the open-source check lists the categories where the candidate loses most. Our acceptance bar is overall accuracy against the margin we agree.

Why it matters, from our own runs: on Banking77 our fine-tune beat the TF-IDF baseline overall (94.0% against 89.3%), but its F1 on receiving_money fell from 97.4% to 91.4% (40 items). In the first public CFPB sample, on the 14 labels as filed, its F1 on "Credit card" was 11.8% against the baseline's 25.2%.

Question 7 · Confusion matrix

Will we see which categories get mistaken for which?

Two models with the same accuracy can make very different mistakes. A confusion matrix, true category against predicted category, shows whether errors are harmless near-misses or costly ones, and often exposes problems in the labels themselves.

A good answer
  • A full confusion matrix for the current model and the replacement, on the same test items.
  • The most common confusions in plain words, with counts.
  • A note on confusions that point to a labelling problem rather than a model problem, with a fix agreed before training.
ILLATE's answer

Every run writes the full confusion matrix as a file, available on request. The report and our published results list the most common mistakes in words: on Banking77, card_arrival predicted as card_delivery_estimate 4 times, for example. The sample decision report includes the full confusion matrix for the option it recommends; the first sample report doesn't include one.

Reading the confusions is how our CFPB run found its real problem: 994 of the model's 1,688 errors, 59%, were one credit-reporting product name mistaken for the other, because the agency renamed products on 25 August 2023 and the date isn't in the text. Merging the renamed products took the same predictions from 67.0% to 89.5%. We chose that merge after seeing the confusions, so it is a diagnosis, not a pre-registered result (details).

Question 8 · Rare classes

How do you test categories with only a few examples?

Rare categories barely move overall accuracy, so a replacement can lose them without the total showing it. They are where migrations usually break.

A good answer
  • A test set split within each category, so rare ones are represented, with duplicates removed so no text appears in both training and test data.
  • The number of test items per category in the report, and categories with too few items marked as not measurable rather than averaged away.
  • Macro-F1 next to accuracy. It weights every category equally, so it falls when small categories do badly.
  • A plan for the gaps: more labelled examples, merged categories, or routing rare cases to a person.
ILLATE's answer

Our intake drops repeated texts, splits 70/10/20 within each label, and keeps labels with fewer than 5 rows out of the test set; they are still trained on. We report macro-F1 next to accuracy.

On CFPB complaints (10 products), our model's accuracy is 89.5% but its macro-F1 is 71.9%: the less common products are where it is weaker. The first public sample report, on the 14 labels as filed, shows two products with 5 and 23 test items on which both models scored 0% F1, rather than leaving them out. The sample decision report gives correct answers out of the test items for the five rarest products, with an interval.

Question 9 · Latency

How fast is it at p50 and p95, and measured where?

The median hides the slow tail. p95, the time within which 95% of answers arrive, is what users and timeouts notice.

A good answer
  • p50 and p95 for your current model and every candidate, on the same inputs.
  • The setup stated: where it was called from, the region, the hardware and how many requests were in flight.
  • A load test at your peak request rate, since latency climbs once a server is saturated.
  • Cold starts, if the replacement scales to zero when idle.
ILLATE's answer

From our public runs: our 4B model on one NVIDIA L4 answers a single request in 194 ms at p50 and 269 ms at p95. At 32 requests in flight it handles 86.6 a second at p95 546 ms; at 64 in flight p95 rose to 3,045 ms, so we cap concurrency per replica. That was measured in the GPU's own region, so add your network round trip (serving numbers). Prompted over OpenAI's API from Modal's cloud, on Banking77 with an example of every category, GPT-5.6 Luna took 978 ms at p50 and 1,368 ms at p95, and GPT-6 Luna 1,117 ms and 2,391 ms. With the 20 most similar examples instead, GPT-5.6 Luna took 812 ms and 1,158 ms; the Decisions API 120 ms and 246 ms. On long CFPB complaints, our model took 317 ms at p50 and 551 ms at p95 one request at a time, and GPT-5.6 Luna with examples 902 ms and 1,225 ms.

The sample decision report lists p50 and p95 for every option and says where each was measured. In a migration we load-test on the GPU your model will run on, at your peak rate. After scaling to zero, our first request takes about a minute, so production endpoints keep a warm replica.

Question 10 · Cost per 1,000 calls

What will each option cost per 1,000 calls at our volume, fixed costs included?

Per-token prices are only part of it. A prompted model pays for your label list on every call, an always-on GPU or hosted deployment costs the same busy or idle, and the migration itself has a price.

A good answer
  • Cost per 1,000 calls for every option, at your real monthly volume and prompt length, using the prices you would actually pay.
  • Fixed costs shown separately: an always-on GPU, Azure's $1.70 an hour per fine-tuned deployment (about $1,241 a month at 730 hours) used or not, and any monthly minimum.
  • The one-off fee and your engineers' time.
  • A plain statement of when owning costs more than renting.
ILLATE's answer

The check starts with a cost check of every option on your volumes. At low volume, owning usually costs more: one always-on L4 costs about $584 a month for the GPU alone, about $815 with an assumed 4-core, 16 GiB container, while 1.5 million short classification calls a month on a fine-tuned gpt-4.1-mini cost about $480 (cost section). For small workloads the reason to own is control, not price, and we say so.

With the 20 most similar examples, each GPT-5.6 Luna call on short Banking77 messages sent about 1,600 input tokens and got about 17 back: about $0.37 per 1,000 calls, from our OpenAI bill for 8-9 Oct. On long CFPB complaints each call sent about 5,400 tokens: about $1.20 per 1,000 calls. That bill came to about 9% more than the per-token prices we read in OpenAI's docs, across both Lunas. It doesn't split by model, so each model's own price is still unverified. The sample decision report uses the same figures; for your check, we also use the prices on your own usage page. Our fees: the check is at no charge before you commit, a migration is USD 3,000 fixed per classification or routing task, and hosting with us, if you want it, is priced per 1,000 calls with a monthly minimum, both fixed for 12 months (pricing).

Question 11 · Invalid-output rate

How often is the answer not one of our categories, and what happens then?

A prompted model can answer with a near-miss spelling, an extra sentence or a category that doesn't exist. Each one is an error your code has to catch.

A good answer
  • The share of answers that weren't a valid label, for every option, counted as errors in the accuracy figure, not quietly cleaned up afterwards.
  • How the replacement is kept to your label list: a JSON schema or Structured Outputs, constrained decoding, or an allowlist check with a fallback.
  • What your code does when an invalid answer gets through.
ILLATE's answer

Our model's output is constrained to your label list, so it can't answer outside it: 0 invalid answers on all three of our public test sets. Without that constraint, an early smoke test produced 68 invalid labels in 200 answers (how we fixed it).

In our runs without a schema, GPT-5.6 Luna gave 15 answers outside the list on 5,500 CLINC150 requests and none on Banking77 or CFPB. GPT-6 Luna gave 4 on Banking77 with an example of every category, 6 on CLINC150 and 2 on CFPB. With a strict JSON schema (Structured Outputs), both Lunas gave none outside the list in 28,437 answers in our pre-registered tests on all three sets.

04 Data

Question 12: what happens to your data

Question 12 · Data handling

Where does our data go, who can see it, when is it deleted, and which certifications do you hold?

A migration needs your real inputs, often support tickets with personal data in them, and the labels you train on decide what the new model learns.

A good answer
  • In writing: where data is stored and processed, every service that sees it, who has access, and when it is deleted, with a certificate.
  • No use of your data for anyone else's model, and no request for your OpenAI or other provider keys.
  • The option to run everything inside your own cloud account.
  • An NDA, a DPA where you need one, and the certifications your security review requires, such as SOC 2 or ISO 27001.
  • Where the training labels come from. Labels written or checked by people, or taken from your records, are the safe choice.

If a vendor proposes training on your fine-tune's answers, know that OpenAI's Services Agreement has a "Permitted Exception" (§17) for models "primarily intended to categorize, classify, or organize data (e.g., embeddings or classifiers), if these models are not distributed or made commercially available to third parties", but doesn't lift its ban on reverse engineering, which it defines to include "model extraction or stealing attacks" (§3.3(d)) (OpenAI Services Agreement, checked 8 October 2026). This is not legal advice. Either way, a model trained on another model's answers copies its mistakes.

ILLATE's answer

By default your data stays with you: the check runs inside your cloud account or on a machine you control. If you choose to have us train or host for you, your examples train and test your model only and are never pooled with other clients' data. We never ask for provider keys. Training data is deleted within 30 days of the engagement ending, or sooner on request, with written confirmation. The services that touch it are Modal (GPU training and serving), Google Workspace (email and file transfer) and Anthropic's Claude, the AI assistant we run our scripts with, which reads their output (counts, scores, column names). Hugging Face only supplies the open base models (security and data). We don't send your data to OpenAI or any other provider API: the GPT-5.6 Luna column runs in your own OpenAI organization, with your own key.

We don't hold SOC 2 or ISO 27001. If your review requires them, we deploy into your own cloud account and never hold your data. We sign your NDA or ours; until a DPA is signed, we work only on de-identified data or inside your cloud. We train only on labels a person or your records confirmed.

05 Beyond the twelve

What else to weigh, and where we stand

The answers above tell you how good the work will be. These tell you who you are hiring.

CheckWhy it mattersILLATE, plainly
Who does the workYou want the names of the people who will see your data and sign off the result.One person: Poojith Devan, founder, sole proprietor trading as ILLATE, in New Delhi. He runs ILLATE with AI agents for research, email and the training pipeline; every call, decision and sign-off is his (about).
Track recordClient references and published results from similar migrations.No client results to show yet; you would be one of our first clients. The evidence is public: benchmarks on Banking77, CLINC150 and CFPB complaints, the adapter on Hugging Face, the open-source check and two sample reports.
CertificationsYour security review may require them.No SOC 2 and no ISO 27001. We deploy into your cloud instead.
Price, and what happens if it missesA fixed price in writing, with a remedy if the result misses the agreed bar.Check at no charge before you commit. Migration USD 3,000 fixed per classification or routing task; the first three clients pay nothing up front and owe nothing unless the final model meets the agreed margin. Switch-to-Luna package USD 750: Luna with retrieved examples, set up and tested on your data. 48-hour rescue USD 1,500, paid on acceptance.
TimeWhether it lands before 23 October 2026, and what the stopgap is if not.Check report within 2 business days of getting access. Full migration planned at three to five weeks. Rescue within 48 hours of access and the signed order.
Whether they'll tell you not to hire themA vendor who says when you don't need them is easier to trust on everything else.If Luna or an embeddings classifier passes on your data, we say so. Not a fit: open-ended writing or chat, tasks with no way to say what a correct answer is, and teams with their own ML platform team.
06 Options

Who can help migrate an OpenAI fine-tune

Listed by what each is good for, with the questions above that matter most for them. We are one of them.

WhoGood forAsk them especially
Your OpenAI account teamWhether your organization can still create a fine-tuning job, and whether dedicated capacity can keep your fine-tune running after 23 October 2026. The published offer is one sentence: "In some cases, developers may be able to provision dedicated capacity for continued access after a model's shutdown date. To explore this option, contact our sales team." (deprecations, checked 8 October 2026)Whether dedicated capacity covers fine-tuned models, at what price and for how long.
OpenAI Partner Network firms, such as Cognita ReplyEnterprise programmes around OpenAI's current models (OpenAI's announcement, June 2026, and Cognita Reply's announcement, 29 July 2026, both checked 8 October 2026). Their published offers are ChatGPT Enterprise, Codex and GPT-5.6 programmes.Question 3: whether they test options outside OpenAI. We found no fine-tune migration offer from them.
Microsoft or your Azure account teamMoving the fine-tune to Azure, if your subscription has already deployed gpt-4.1-nano (retirement schedule, checked 8 October 2026)Questions 5 and 10: what you move to after 14 October 2027, and the $1.70 an hour per deployment.
AWS, through partners such as LokaAn AWS-funded assessment that moves apps to OpenAI models on Amazon Bedrock, in 4–6 weeks (Loka, checked 8 October 2026)Question 3: whether fine-tunes are in scope. We found no mention of fine-tunes or 23 October, and the funded share and who qualifies differ between Loka's pages.
A model gateway, such as TrueFoundryStaged cutovers and fallbacks between models you already call (their post on deprecations, checked 8 October 2026)Questions 3, 4 and 5. Their post covers routing and staged cutovers between models; ask whether they also help choose or train the replacement.
Your own engineer, or a freelancerTeams with someone who can label a test set and run the comparisonQuestions 1, 2 and 6–8. The open-source check and this list work for them too.
ILLATE (us)A bake-off on your data at no charge, then the cheapest option that passes: Luna with retrieved examples, an embeddings classifier, or a fixed-price model you ownAll twelve, starting with our gaps: one person, no SOC 2, no client results yet, two public sample reports.

Sources dated 8 October 2026 were read through verbatim copies: public GitHub mirrors of OpenAI's docs and Microsoft's own docs repository. OpenAI's Services Agreement was read through Open Terms Archive's verbatim capture, and the Loka, TrueFoundry and partner pages through search results. Recheck any date before you plan around it. On gpt-4.1-nano specifically, the dated facts and four questions to ask OpenAI first are on the gpt-4.1-nano replacement page.

07 Questions

Common questions

What should I ask before hiring someone to migrate an OpenAI fine-tuned model?

Ask for an evaluation report on your own held-out test set, a test harness you can rerun yourself, a replacement-model recommendation that includes GPT-5.6 Luna with a prompt and an embeddings classifier, a deployment plan, a rollback procedure that still works after 23 October 2026, per-class recall, a confusion matrix, results for rare classes, latency at p50 and p95, cost per 1,000 calls, the invalid-output rate, and a written data-handling statement. Ask to see a real, unedited sample report before you sign.

Do I need to hire anyone to replace my fine-tuned model?

Not always. If GPT-5.6 Luna with a prompt, or an embeddings classifier you own, meets your margin on your own labelled test set, use it. On Banking77 support triage, GPT-5.6 Luna shown the 20 most similar labelled examples and a bge-base embeddings classifier both statistically tied a fine-tuned 4B model: 93.8% and 93.5% against 94.0%. Luna with examples tied on CLINC150 too, and trailed by 2.0 points on long CFPB complaints, with renamed products merged after seeing the errors. An engineer with a labelled test set can run the comparison with an open tool such as github.com/illate/parity.

Can a vendor transfer or convert my fine-tuned OpenAI model?

No. OpenAI doesn't release the weights of models fine-tuned on its platform, and we found no export path on Azure either. A vendor can only rebuild the task from your training data and a labelled test set, so treat a promise to convert or transfer the model as a warning sign.

How much does it cost to migrate an OpenAI fine-tune?

It depends on the route. Ours: the check on your data is at no charge before you commit, a migration is USD 3,000 fixed per classification or routing task; the first three clients pay nothing up front and owe nothing unless the final model meets the agreed margin, the switch-to-Luna package is USD 750 and the 48-hour rescue USD 1,500, paid on acceptance. Through partners such as Loka, AWS funds part or all of an assessment for customers who qualify (Loka, checked 8 October 2026). Whoever you hire, get the price fixed in writing with what happens if the result misses the agreed bar.

What should the contract say if the replacement isn't as good as our fine-tune?

It should fix the test set and the margin in writing before the final run, define a pass (for example, the whole 95% confidence interval of the difference sits above minus the margin), list any per-category minimums, and name the remedy: a refund, no second payment, or more work at the vendor's cost. It should also say that you own the weights, the test set and the scripts afterwards.

Is a small vendor riskier than a large consultancy?

In some ways: fewer people, no certifications and a shorter record. You can reduce that risk by owning the weights, test set, scripts and runbook, keeping the rollback independent of the vendor, and running in your own cloud if your data requires it. A larger firm brings more people and paperwork; ask it the same twelve questions, because a bigger team doesn't by itself mean a better test.

How long does migrating a fine-tuned model take?

Saving your fine-tune's answers can start today and needs no vendor. A comparison on your test set takes days: our check reports within 2 business days of getting access. A full migration with a staged rollout takes weeks: ours is planned at three to five, and Loka lists 4–6 weeks for its AWS assessment. If your model stops on 23 October 2026 and the replacement isn't ready, use a prompted model that met your margin, or a review queue, as the stopgap.

What if our fine-tune has already stopped answering?

You can no longer record its answers, so a replacement can only be measured against your labels. The file you trained it with still works, if its labels were written or checked by people or come from your records: a model you own can be trained on it and tested on rows it never saw. Our 48-hour rescue does that for USD 1,500, paid only once it meets the accuracy we agree. If GPT wrote the labels, tell us and we'll quote a labelling job or decline.

Want our answers to these questions, on your data?

Start with a 20-minute call or a short email; no data needed. Then the check runs where your labelled examples and your fine-tune's saved answers already are: inside your cloud account or on a machine you control (how to prepare the file). Nothing leaves your infrastructure. Within 2 business days of getting access you get the report, including "use Luna" or "use an embeddings classifier" when that's the answer. If a model you own is the better choice, the migration is a fixed fee; the first three clients pay nothing up front and owe nothing unless the final model meets the agreed margin (pricing).