Fine-tuning Claude: you probably do not need it in 2026

Every few weeks someone asks us the same thing: "Should we fine-tune Claude on our domain data?" In 2026 the answer is almost always no. Long-context examples, prompt caching, structured outputs and model routing have closed the gap that fine-tuning used to open. They also keep you off a frozen snapshot of the base model, which will be obsolete in a couple of months.

Below: why that is, when a fine-tune still makes sense, and a working example where a cached system prompt with 50 examples beats a fine-tuned model on invoice extraction.

What Claude fine-tuning looks like in 2026

Anthropic offers fine-tuning for Claude Haiku and Sonnet through Amazon Bedrock, and that is currently the only first-party path. The mechanics will be familiar to anyone who has tuned an OpenAI model: upload a JSONL file of labelled examples, run a training job, deploy a custom endpoint, and pay a higher per-token rate plus an hourly hosting fee.

The trouble is the economics and the iteration loop. Neither resembles prompt engineering:

• Training. Each run on a non-trivial dataset is a one-time spend of four to five figures.
• Hosting. A flat hourly rate. It is the same for one request or for a million.
• Tokens. A fine-tuned Claude costs noticeably more per token than the base model.
• Iteration. One attempt takes hours, not seconds. You cannot A/B-test a comma in your dataset.
• Upgrades. A new base model never reaches your fine-tune. When the release after Sonnet 4.6 ships, your version stays on 4.6 until you retrain it.

For a team shipping a product, that last point usually settles it. Base models improved so fast in 2025-2026 that a six-month-old fine-tune often loses to the latest base model with no customisation at all.

The alternative stack

Here is what to try before you seriously consider fine-tuning. In our experience it covers ~90% of the cases where a team thinks it needs one.

1. Few-shot examples in a cached system prompt

Sonnet 4.6 has a 200K-token context window. That is room for 50-200 high-quality input/output pairs from your domain. With prompt caching, the examples are tokenised once, cost about 10% of the input rate on later calls, and stay almost free to reuse for the next five minutes.

You get most of what fine-tuning offers: the model has actually seen your domain's edge cases, formats and tone. Plus three properties fine-tuning lacks:

• Instant iteration. Edit a JSON file, redeploy, done.
• Transparent debugging. If the model gets something wrong, read the exemplars it was conditioned on.
• Free upgrades. Anthropic ships a smarter Sonnet and your prompt improves with it.

2. The base model is already very good

Nobody likes admitting this part. In 2024, fine-tuning on narrow domains often brought real gains. In 2026, Sonnet 4.6 out of the box handles legal, medical, financial, code and customer-support work very well. Fine-tuning frequently makes the model worse on out-of-distribution inputs while adding only a little on in-distribution ones.

Run an honest eval before deciding you need a fine-tune. Odds are the gap you saw was a prompt problem.

3. Structured outputs via forced tool use

Suppose what you actually need is output that matches a strict schema every time. A fine-tune is not required for that; forcing tool use is enough. Define the output as a tool's input_schema, set tool_choice to that tool, and Claude must return JSON that validates against your schema.

In 2023 this was one of the main reasons to tune OpenAI models. On Claude in 2026 it is a five-line change to the request payload.

4. Model routing for cost

Most production pipelines see requests of very different difficulty. Send the easy ones to gpt-5.6-luna, escalate to Sonnet when confidence drops, and keep Opus for the genuinely hard cases. A well-tuned router cuts total spend by 60-80% compared with running everything on Sonnet, and it needs no custom training.

You can build the router as a gpt-5.6-luna classifier in front of Sonnet, or as a confidence threshold on the first model's logprobs.

The codexkey catalog does include Haiku: claude-haiku-5.5 and claude-haiku-4.5, with prices on the models page. They run in the Premium channel; the Cheap channel has no Haiku.

5. RAG for knowledge that changes

The other common reason to reach for fine-tuning: "we want the model to know our docs." That is a retrieval task, not a training task. Fine-tuning on a corpus that changes weekly means retraining every Friday. Embed the corpus instead, pull the top chunks and inject them into the cached prompt. The knowledge base updates the moment you re-index.

Cost comparison

Now the numbers. Say you process 1M invoice extractions a month, at 2K input and 500 output tokens on average.

Path A: fine-tune Sonnet

• One-time training: ~$8K for a quality dataset and a few iterations.
• Hosted endpoint: ~$2K/month, flat.
• Per-token premium: roughly 1.5× the base Sonnet rates.
• Month 1: ~$15K. Steady state: ~$10K/month.
• Re-tuning after a base-model upgrade: another $8K every six months.

Path B: cached 50-shot Sonnet

• 50 exemplars ≈ 30K cached tokens, written once per cache window.
• Per request: 30K cached input (10% rate) + 2K live input + 500 output.
• Total: ~$5K/month, with no training and no hosting fee.
• The upgrade path to Sonnet 4.6, 4.8 and beyond is free.

The gap widens with volume, because the cached prefix is spread across every request inside the cache window.

When fine-tuning is still the right call

We are not absolutists. Three scenarios do justify a fine-tune:

1. Domain language Claude struggles with. Niche scientific notation, low-resource non-English languages, or proprietary DSLs where even 200-shot prompting hits a quality ceiling.
2. Latency-critical extraction at scale. You need sub-200ms responses and cannot afford the cached prefix: a small fine-tuned Haiku with a short prompt can win on p99.
3. Regulatory output constraints. Some compliance regimes require the model to have been trained on approved data. Conditioning it on that data at inference time does not count. Rare, but real.

If none of that applies to you, start with the alternative stack.

Code: 50-shot invoice extraction

A minimal example against codexkey's OpenAI-compatible endpoint. The system prompt loads a JSON file with 50 invoice exemplars and is cached, so later calls pay only for the live invoice text.

import json
from anthropic import Anthropic

client = Anthropic(
    api_key="sk-cxa-...",
    base_url="https://api.codexkey.online/v1",
)

# Load 50 input/output pairs from your gold dataset
with open("invoice_exemplars.json") as f:
    exemplars = json.load(f)

few_shot_block = "\n\n".join(
    f"<example>\n<invoice>{ex['input']}</invoice>\n"
    f"<extracted>{json.dumps(ex['output'])}</extracted>\n</example>"
    for ex in exemplars
)

EXTRACT_TOOL = {
    "name": "record_invoice",
    "description": "Record the structured invoice data.",
    "input_schema": {
        "type": "object",
        "properties": {
            "invoice_number": {"type": "string"},
            "issue_date": {"type": "string"},
            "vendor": {"type": "string"},
            "total_amount": {"type": "number"},
            "currency": {"type": "string"},
            "line_items": {"type": "array"},
        },
        "required": ["invoice_number", "vendor", "total_amount"],
    },
}

def extract(invoice_text: str):
    return client.messages.create(
        model="claude-sonnet-5",
        max_tokens=1024,
        system=[
            {
                "type": "text",
                "text": "You are an invoice extraction system. "
                        "Match the format and edge-case handling of "
                        "the examples exactly.",
            },
            {
                "type": "text",
                "text": few_shot_block,
                "cache_control": {"type": "ephemeral"},
            },
        ],
        tools=[EXTRACT_TOOL],
        tool_choice={"type": "tool", "name": "record_invoice"},
        messages=[{"role": "user", "content": invoice_text}],
    )

Three things do the heavy lifting here:

• cache_control on the exemplar block drops the per-request cost of the 30K-token example set to roughly 10% of the normal input rate.
• tool_choice forced to record_invoice guarantees a JSON object that validates against your schema. No regex parsing and no retry loops on malformed output.
• The exemplars themselves condition the model on your vendor formats, currency conventions and line-item edge cases.

Eval before, eval after

One piece of advice: measure. Before committing to either path, build a held-out eval of 200-500 real inputs with gold labels. Then run:

1. Baseline: Sonnet 4.6 with a one-paragraph system prompt.
2. Few-shot cached: the same model, a 50-shot cached prompt and a forced tool.
3. Fine-tuned: only if 1 and 2 fall short.

On our internal benchmarks (invoice extraction, support-ticket classification, contract clause tagging), configuration #2 matched or beat a same-model fine-tune on 7 tasks out of 10. It cost less, and an iteration took a day.

What to pick instead of a fine-tune

Fine-tuning Claude in 2026 still works as a tool. It just no longer serves as the default when a base model is "almost good enough". Start with the alternative stack: cached few-shot, forced tool use, RAG for fresh knowledge and a gpt-5.6-luna-first router. You will ship faster, spend less and get every base-model improvement from Anthropic for free.

To try cached few-shot at Anthropic-equivalent pricing, point your SDK at https://api.codexkey.online/v1; your existing prompt-caching code will work unchanged.