Deprecations, retirements, and the 400 wall

Everything in this lesson is a request that used to work. That is what makes it dangerous and what makes it examinable: your code did not change, the model did.

The four 400s

Notice the pattern in the boundaries, because it is the thing questions are built out of. Prefill dies at 4.6. Extended thinking is only deprecated at 4.6 and dies at 4.7. Two features, two adjacent versions, opposite states at the same version number. That is a deliberately confusable pair and it is worth ten seconds of extra attention now.

And learn each boundary in both directions. A question that shows you a perfectly legal request on 4.6 and invites you to condemn it is exactly as common as one showing you a broken request, and by the time you have read a list of four failures the instinct to find a fifth is strong.

Why hard rejection is the right call

It reads as hostile the first time. Your working service points at a newer model and immediately throws.

But compare it to the alternative. A silently ignored temperature means you ship believing you have determinism you do not have. A silently downgraded thinking budget means quality moves and nothing tells you. Both of those are found weeks later by a customer.

A 400 is found in about four minutes, by you, at integration time.

The counter-example sits one module back: the prompt cache minimum, which fails silently and quietly costs you money forever. Having seen both, the loud one is obviously better, and that framing is a genuinely useful thing to carry out of this course and into your own API design. When you get to choose your own failure direction, choose the one that cannot be ignored.

Retirements are a lifecycle commitment

Model ids do not live forever. claude-opus-4-1-20250805 retires on 2026-08-05, and it is the concrete example of a mechanism that applies to every dated id you pin.

The trade is clean. A dated id gives you a stable snapshot, which is what evaluation and reproducibility need, and it comes with an expiry date. An undated current id such as claude-sonnet-5 never expires and instead moves under you, which is fine for exploratory work and awkward for anything whose behaviour you have measured and promised.

Pin dated ids where behaviour matters. Then put the retirement date somewhere that will interrupt you.

A migration checklist worth keeping

Before repointing any service at a newer model, four greps:

thinking or budget_tokens anywhere in your request construction. Replace with output_config.effort and let adaptive thinking do its job.

temperature, top_p, top_k, including defaults baked into wrapper libraries and shared helpers, which is where they hide.

A request builder that can append an assistant message last. Formatting hacks live here. Replace with output_config.format.

Any request that sets both citations and a structured output format. Split it into two calls.

Four greps, and they cover every hard failure this course has named. That is a genuinely good afternoon of work before an upgrade, and it is also, not coincidentally, a very good revision exercise the night before an exam.

{
  "model": "claude-opus-4-6",
  "max_tokens": 1024,
  "temperature": 0.3,
  "thinking": { "type": "enabled", "budget_tokens": 4000 },
  "messages": [
    { "role": "user", "content": "Review this contract clause." },
    { "role": "assistant", "content": "The indemnity is uncapped." },
    { "role": "user", "content": "Draft a replacement." }
  ]
}

{
  "model": "claude-opus-4-7",
  "max_tokens": 1024,
  "temperature": 0.7,
  "thinking": { "type": "enabled", "budget_tokens": 4000 },
  "messages": [
    { "role": "user", "content": "List three risks as JSON." },
    { "role": "assistant", "content": "[" }
  ]
}