Prompting Claude & model migration

1 · Anthropic-specific prompting, in one picture essential

Here's the failure that this whole lesson is built to prevent. You paste a 40-page contract into a prompt, tack "what's the termination clause?" onto the end, and Claude confidently answers — from the wrong section, or worse, from a clause it half-invented. You didn't do anything obviously wrong. The trouble is that from the model's point of view your instructions and your data were one undifferentiated wall of text, and it guessed at the seams. A handful of small, deliberate moves would have removed that guesswork entirely — and those moves are what this lesson is.

Think of a good prompt like a well-labelled shipping crate rather than a pile of loose parts. The label on the outside says what's inside and how to handle it; the parts sit in clearly marked compartments; the "this way up" arrow points the reader's attention the right direction. Claude, like a careful worker, does its best job when the crate is labelled — and its most creative, most error-prone job when it has to reverse-engineer what you meant. Every technique here is a label or a compartment.

You already know general prompting from ch02 and pe1 — be clear, give examples, ask for structure. This lesson is narrower and deeper: the handful of techniques that are specific to Claude and that Anthropic documents as first-class. There are four, and they stack:

Read it left to right as a build order. XML tags label the pieces of your prompt so Claude never confuses your data for your instructions. The system prompt sets who Claude is. Prefill (on older models) or structured output (on current ones) pins the shape of the reply. And when the prompt is huge, ordering — long document first, question last — is what keeps recall high. Everything else in this half is detail on those four.

2 · Recipe 1 — structure the prompt with XML tags essential

Imagine handing a colleague a single sheet of paper with a contract, a note to yourself, and a question all typed one after another with no headings. They'd have to infer where the contract ends and your question begins — and half the time they'd get it slightly wrong. That is exactly the position a plain, unstructured prompt puts Claude in. The fix is almost embarrassingly simple: draw lines around the pieces. In Claude's world, those lines are XML-style tags.

Here's why this specific technique works and isn't just tidiness. Claude was trained on a great deal of text where tags like <document>…</document> reliably mark a self-contained block, so the model has learned to treat a tag boundary as a real boundary of meaning. When you write "answer using the text in <document>", Claude can resolve that reference precisely, the same way you can point at a labelled box and say "the thing in that one." Without the tag, "the document" is just a phrase competing with every other phrase for the model's attention.

The common mistake to name up front: people either skip tags entirely on long mixed prompts (and get answers drawn from the wrong part), or they open a tag and forget to close it, or they use one name to wrap the content and a different name in the instructions. All three break the very reference you were trying to create. The rule of thumb is boring and reliable — every tag opens and closes, and the name you wrap with is the name you cite. Now the precise version:

Claude is trained to pay attention to XML-style tags. When your prompt mixes a document, a few examples, and your instructions, wrapping each part in a tag (<document>, <example>, <instructions>) removes ambiguity: Claude can tell "the thing to act on" from "how to act on it". The tag names are yours to choose — there is no fixed vocabulary — but pick descriptive names and close every tag.

xml_prompt.py# needs: pip install anthropic + ANTHROPIC_API_KEY; makes a real API call.
# XML tags are just text in the prompt string — no special parameter, no beta header.
import anthropic

client = anthropic.Anthropic()   # reads ANTHROPIC_API_KEY from the environment

CONTRACT = "... the full text of a 40-page contract ..."

prompt = f"""<document>
{CONTRACT}
</document>

<instructions>
Answer the question using ONLY the contract above. Quote the exact clause you
relied on inside <quote></quote> tags, then give your answer in <answer></answer> tags.
If the contract does not address the question, say so — do not guess.
</instructions>

<question>What is the termination notice period?</question>"""

resp = client.messages.create(
    model="claude-opus-4-8",
    max_tokens=1024,
    messages=[{"role": "user", "content": prompt}],
)
print(next(b.text for b in resp.content if b.type == "text"))

Two things are doing work here. First, the tags give Claude a frame: the contract is data, the instructions are rules, the question is the ask. Second, asking for the answer inside <answer> tags makes the reply easy to parse on your side — you split on the tag instead of guessing where the prose ends.

3 · The system prompt's job essential

Most people cram everything into the user message and never touch the system prompt — and it quietly costs them both quality and money. The role, the rules, the format contract, the document, the question, all pasted into one turn. It works well enough that the leak goes unnoticed, which is exactly why it's worth stopping on: there's a cleaner place for half of that text, and using it makes your calls both more reliable and cheaper.

The mental model is a job description versus a work ticket. The system prompt is the job description — who you are, the standards you always hold to, how you're expected to format your output. It doesn't change from task to task. The user message is the work ticket — this specific document, this specific question, handed over fresh each time. You wouldn't re-read a new employee their entire job description every time you gave them a task; you set the role once and then just hand over the work. Claude is the same: put the durable identity and rules in system, and let the user turn carry only what's genuinely new.

Two concrete payoffs make this more than style. First, reliability: a stable, clearly-scoped role reads more consistently than the same instructions buried mid-paragraph next to the data. Second, and this is the one engineers underrate, cost: that frozen system prefix is precisely what prompt caching can reuse across requests, so you pay to process it once instead of on every call. The mistake that kills the caching win is sliding something variable — a timestamp, the document, "today's" question — into the system prompt; the moment the prefix changes, the cache misses. Keep the boundary clean and both wins hold. Now the precise version:

Claude takes a system prompt separately from the conversation. Put the stable stuff there — who Claude is, the rules it must always follow, the output contract — and keep the variable stuff (the actual document, this turn's question) in the user message. The split matters for two reasons: it reads more reliably, and it caches better (the frozen system prefix is exactly what prompt caching reuses).

system_role.py# needs: pip install anthropic + ANTHROPIC_API_KEY; makes a real API call.
import anthropic

client = anthropic.Anthropic()

resp = client.messages.create(
    model="claude-opus-4-8",
    max_tokens=512,
    # STABLE: role + hard rules + output contract — same every request, caches well.
    system=(
        "You are a senior contracts analyst. Answer only from the document the user "
        "provides. Be explicit and literal. If something is not stated, say 'not stated' "
        "rather than inferring. Always cite the clause you used."
    ),
    # VARIABLE: this turn's data + question.
    messages=[{"role": "user", "content": "<document>...</document>\n\nWhat is the SLA credit?"}],
)
print(resp.stop_reason, "|", resp.usage.input_tokens, "input tokens")

4 · Recipe 2 — prefilling the assistant turn (and its modern replacement) intermediate

You ask for JSON and Claude gives you "Sure! Here's the data you asked for:" followed by the JSON in a code fence. Now your parser chokes on the friendly preamble. The old fix for this was a genuinely clever trick called prefilling — and it's worth learning even though it's been superseded, because understanding why it worked and why it was replaced is one of the cleanest windows into how these models actually generate text.

Here's the intuition. A language model doesn't decide on a whole answer and then type it; it writes one token at a time, each one strongly shaped by what came just before. Prefilling exploits that directly: you write the opening words of Claude's own reply for it — as an assistant turn left dangling with no response after it — and the model, seeing a reply already in progress, simply continues it. It's like starting someone's sentence for them: begin "The three main causes are…" and they'll naturally list three, not ramble. Begin the reply with { and the most natural continuation is more JSON, so the preamble never gets a chance to appear.

The catch — and it's the reason this section pulls double duty as your first real migration lesson — is that prefilling is a technique tied to a model's behaviour, and model behaviour changes. On current Claude models the trailing-assistant-turn trick has been removed and now returns an error outright. So this recipe teaches two things at once: the classic prefill (still live on older models, and a lovely illustration of token-by-token generation) and the modern replacement you should actually reach for. Watch the seam between them closely — a prompt that "just worked" turning into a hard error on the next model is the entire premise of the second half of this lesson. Now the precise version:

Prefilling means you put the first words of Claude's reply into the conversation yourself, as an assistant message with no answer after it. Claude then continues from your words. The classic use is forcing a format: start the assistant turn with { and Claude keeps writing JSON; start it with a label and Claude fills it in. It skips preambles like "Sure, here is…".

prefill_old.py# needs: pip install anthropic + ANTHROPIC_API_KEY; makes a real API call.
# PREFILL PATTERN — works on older models (e.g. claude-sonnet-4-5). On Opus 4.6+ /
# Sonnet 4.6 / Fable 5 a trailing assistant turn returns a 400. See the replacement below.
import anthropic

client = anthropic.Anthropic()

resp = client.messages.create(
    model="claude-sonnet-4-5",                 # older model: prefill still allowed
    max_tokens=256,
    messages=[
        {"role": "user", "content": "Give the capital and population of France as JSON."},
        {"role": "assistant", "content": "{"},  # PREFILL: Claude continues the JSON
    ],
)
# The reply starts after your "{" — prepend it back to reconstruct the full object.
text = next(b.text for b in resp.content if b.type == "text")
print("{" + text)

On current models you get the same guarantee — and a stronger one — with structured output. Instead of nudging the first token, you hand Claude a JSON schema and the reply is constrained to match it. This is the recommended replacement for every "prefill to force a format" case.

structured_output.py# needs: pip install anthropic + ANTHROPIC_API_KEY; makes a real API call.
# Replaces format-forcing prefills on current models. output_config.format constrains
# the reply to your JSON schema — no prefill, guaranteed shape.
import anthropic

client = anthropic.Anthropic()

resp = client.messages.create(
    model="claude-opus-4-8",
    max_tokens=256,
    messages=[{"role": "user", "content": "Give the capital and population of France."}],
    output_config={
        "format": {
            "type": "json_schema",
            "schema": {
                "type": "object",
                "properties": {
                    "capital": {"type": "string"},
                    "population": {"type": "integer"},
                },
                "required": ["capital", "population"],
                "additionalProperties": False,
            },
        }
    },
)
import json
text = next(b.text for b in resp.content if b.type == "text")
print(json.loads(text))    # {'capital': 'Paris', 'population': ...}

5 · Recipe 3 — long-context ordering intermediate

The window is enormous, so surely order doesn't matter — just dump everything in and ask. That assumption is the trap this section exists to spring. Claude's models take huge inputs (up to 1M tokens on Opus 4.8), and it's tempting to treat the prompt as a bag where placement is irrelevant. It isn't. The same document and the same question can give you a sharp, grounded answer or a vague one depending purely on the order you arranged them in — and getting that order right costs you nothing.

An analogy that makes the fix stick: think of how you'd brief a human researcher. You'd hand them the report first, let them read it, and then ask your question — so the question lands while the material is fresh and they know what they're looking for. Ask the question first and shove fifty pages at them afterward, and they've read the whole thing without knowing what mattered, then have to scan back through their memory of it. Claude behaves in a strikingly similar way: it attends most sharply to a question that arrives after the material it's about. Document first, question last is not a superstition — it's putting the ask where the model can act on it.

The mistake to avoid is the natural, conversational order — "answer this about the following: [huge blob]" — which front-loads a question the model can't yet ground and back-loads the evidence. A second, subtler mistake is trusting a long-input answer that cites nothing; on big documents a model can drift toward what it half-remembers instead of what the text says. The antidote, quote-then-answer, is the third rule below and it's the cheapest accuracy upgrade in this whole lesson. Anthropic's documented long-context guidance is three rules:

Long-context rules

1. Put the long document first, the question last. Claude attends best to a query that comes after the material it's about. A 50-page doc followed by "now answer X" beats "answer X about the following: [50 pages]".
2. Wrap each document in tags (<document>, or <doc index="1"> when there are several) so Claude can reference them and you can ask it to cite by index.
3. Ask it to quote first, then answer. Instruct Claude to pull the relevant sentences into <quotes> before writing the answer. Grounding the answer in extracted quotes raises accuracy and gives you something to audit.

long_context.py# needs: pip install anthropic + ANTHROPIC_API_KEY; makes a real API call.
import anthropic

client = anthropic.Anthropic()

DOCS = {1: "... report one ...", 2: "... report two ..."}

# Long material FIRST ...
doc_blocks = "\n".join(f'<doc index="{i}">\n{txt}\n</doc>' for i, txt in DOCS.items())

# ... question and instructions LAST.
prompt = f"""{doc_blocks}

Using only the documents above:
1. Pull the sentences relevant to the question into <quotes></quotes>, tagging each with
   the doc index it came from.
2. Then write your answer in <answer></answer>, citing the doc index.

<question>Which report projects higher Q4 revenue, and by how much?</question>"""

resp = client.messages.create(
    model="claude-opus-4-8",
    max_tokens=1024,
    messages=[{"role": "user", "content": prompt}],
)
print(next(b.text for b in resp.content if b.type == "text"))

6 · The Console prompt improver & generator advanced

You've just learned four techniques — and now you're staring at a blank prompt, applying them by hand, one tag at a time. There's a faster on-ramp that most people never touch, and it applies these exact techniques for you. It won't replace your judgement, but it will get you to a decent first draft in seconds instead of an hour of fiddling.

The right way to think about these Console tools is as a scaffolding crew, not an architect. A scaffolding crew can put up a sound, standards-compliant structure fast — the equivalent of laying down XML tags, a clear role, worked examples, and an answer contract — so you're not starting from bare ground. But they don't know what building you actually need; that judgement stays with you. The generator raises scaffolding from a plain-language description; the improver re-scaffolds a prompt you already have. Both give you a well-formed starting point built from the very practices in this lesson.

The mistake here is subtle because the output looks so polished: people paste a generated prompt straight into production and assume "reads well" equals "performs well." It doesn't. A prompt that's beautifully tagged and articulate can still score worse on your specific task than the scrappy one you already had — because the Console optimizes for general best practice, and only your eval set knows your task. The discipline is simple: generate, then measure. Treat the draft as a hypothesis and let the numbers from ch05 confirm or kill it. Here's what each tool is:

You don't have to write every prompt from a blank page. The Anthropic Console (console.anthropic.com) ships two tools that most people underuse:

Treat the output as a strong first draft, not a finished artifact. The Console applies the exact techniques in this lesson — XML tags, explicit instructions, an answer contract — so its drafts are a good scaffold. But you still own the evals: a generated prompt that reads beautifully can still score worse on your task than the one you had. Generate, then measure.

7 · Why migration is a workflow, not a find-and-replace advanced

The email arrives on a Tuesday: the model your product runs on is being retired in six weeks. Your instinct is to shrug — it's one string, you'll change claude-sonnet-4-5 to the new id, deploy, done by lunch. That instinct is how migrations become Friday-night incidents. Swapping the string is the easy five percent; the ninety-five percent that bites you is everything the string is silently attached to.

The analogy that reframes it correctly: a model version is a dependency, exactly like a library you import. Nobody sensible bumps a major library version by find-and-replace and ships without running the tests — because a major version can change the function signatures and the behaviour behind them. A model is the same kind of dependency, just an unusually opaque one. Its "API surface" can change (parameters that used to be accepted now error), and its "behaviour" can change (it follows instructions more literally, reaches for tools differently, calibrates length differently) — all under an innocent-looking id swap.

That second kind of change is the one that fools careful engineers, so name it plainly: your code can be completely valid and the output still gets worse. Nothing throws. No error, no 400, no red in the logs — just a prompt that was tuned for the old model's temperament now over-triggering or under-triggering on the new one's. A prompt is tuned for a model, and when the model moves, the prompt has to be re-validated against evidence, not vibes. That evidence is your eval set, and the disciplined loop that uses it is the rest of this lesson. Two facts make migration more than swapping a string:

What actually changes across a model version

1. The request surface can change. Moving to Opus 4.6+ / Sonnet 4.6 / Fable 5, assistant-turn prefills 400, budget_tokens is replaced by thinking={"type":"adaptive"}, and (Opus 4.7+) sampling params temperature/top_p are rejected. A blind id swap can start erroring.
2. Behavior shifts even when the code is valid. Newer models follow instructions more literally, reach for tools differently, and calibrate verbosity to the task. A prompt tuned for the old model may over- or under-trigger on the new one — so the prompt often needs adjusting, not just the id.

The upshot: a prompt is tuned for a model. When the model changes, you re-validate the prompt against evidence — which is exactly what the loop below is for. This is where your eval set (ch05) earns its keep: it's the evidence.

8 · The safe migration loop professional

Every technique so far has been about a single call; this is about how you change the model under thousands of them without your users noticing. If §7 convinced you that a model is a dependency, this section is the deployment procedure for upgrading it — and like any good deployment procedure, its whole value is that it turns a scary event into a routine, reversible one.

The mental model is the way careful teams already ship risky changes anywhere else: you don't flip the new version on for everyone at midnight and hope. You test it against known-good cases first, you release it to a sliver of real traffic while keeping the escape hatch open, you watch, and only then do you widen it. The migration loop is that same discipline applied to a model swap — pin, test, diff, adjust, canary, watch — and the reason to draw it as a loop is the "adjust" arrow that sends you back: a regression almost never means "the new model is bad," it means "my prompt no longer fits it," so you tune and re-run.

The mistake that turns this into a fire drill is skipping steps because the pass-rate looked fine — most often skipping the canary, or trusting the aggregate number without diffing per case. The eval set proves the new model is good on the cases you thought of; the canary proves it's good on the messy real traffic you didn't. Both matter, and the order matters: doing them in sequence is precisely the difference between a boring Tuesday and a Friday incident. Here's the loop:

The loop, step by step

1. Pin the model id. Put the id in one config constant (MODEL = "claude-opus-4-8"), never scattered as string literals. You can't migrate safely what you can't find in one place.
2. Keep an eval set. A fixed set of representative inputs with known-good expectations (from ch05). This is the ground truth you'll diff against.
3. Run BOTH old and new against the evals. Same prompts, same inputs, two model ids. Compare pass-rates and eyeball the diffs — where the new model changed matters as much as the aggregate number.
4. Adjust prompts if needed. If the new model regresses, it's usually prompt fit, not a bad model: dial back aggressive tool instructions, add a length instruction, remove prefills. Re-run the evals after each change.
5. Roll out behind a flag (canary). Send a small slice of real traffic to the new model, keep the rest on the old one. A flag means instant rollback with no deploy.
6. Watch, then promote. Monitor the canary — latency, cost, error rate, refusals, and any quality signal you have — then widen the flag to 100% once it holds.

9 · Recipe 4 — the migration gate (this one runs offline) professional

"The new model passed — 90% either way, ship it." That sentence has caused more quiet quality regressions than any bug, because it treats a single averaged number as if it were the whole story. The "Pass?" diamond in the migration diagram deserves a real rule, and this section builds one you can actually run — no API key, no network, pure stdlib, a plain python file.py.

The insight the gate is built around is worth internalizing beyond this lesson: an average can stay perfectly still while the thing underneath it churns. Picture a class where the average test score holds at 75% two years running — and yet half the students who used to pass now fail, exactly offset by half who used to fail now passing. The headline says "no change"; the reality is a completely different class. Two model versions do this constantly: identical aggregate pass-rate, but they disagree on which specific cases they get right. If you only watch the average, that reshuffle is invisible — and one of those newly-broken cases is your most important customer flow.

So the gate refuses to reason about averages alone. It diffs per case and treats a regression — a case the old model passed but the new one fails — as the signal that matters, regardless of what the aggregate did. That's why its verdicts are stricter than "did the number go up": go demands zero regressions, not merely an equal-or-better rate; adjust means something slipped but stayed within a tolerance band, so tune the prompt and re-run; block means a real drop, do not ship. The common mistake it's designed to stop is shipping on a flat headline while a case silently broke. Here's the rule made concrete:

migration_gate.pydef migration_gate(old_results, new_results, adjust_band=0.03):
    """Decide whether a new model is safe to roll out, from eval results.

    old_results / new_results: dict[case_id] -> bool (True = passed the eval).
    Both must cover the SAME case ids. Returns a decision dict.

    Rule (per-case regressions matter, not just the aggregate):
      no case regressed                        -> "go"      (as good or better)
      some regressed, rate held within band    -> "adjust"  (small/hidden regression)
      rate dropped past the band               -> "block"   (real regression)
    A "regression" is a case the old model passed but the new one fails. Note a
    migration can hold its aggregate pass-rate while still regressing cases (it fixed
    as many as it broke) — that is exactly why go requires ZERO regressions.
    """
    ids = sorted(old_results)
    assert ids == sorted(new_results), "eval sets must cover the same case ids"

    n = len(ids)
    old_rate = sum(old_results[i] for i in ids) / n
    new_rate = sum(new_results[i] for i in ids) / n
    regressions = [i for i in ids if old_results[i] and not new_results[i]]

    if not regressions and new_rate >= old_rate:
        decision = "go"
    elif old_rate - new_rate <= adjust_band:
        decision = "adjust"
    else:
        decision = "block"

    return {
        "old_rate": round(old_rate, 3),
        "new_rate": round(new_rate, 3),
        "delta": round(new_rate - old_rate, 3),
        "regressions": regressions,
        "decision": decision,
    }


# Fake eval set: 10 cases, old model (e.g. sonnet-4-5) vs new (opus-4-8).
old = {f"case-{i:02d}": True for i in range(10)}
old["case-07"] = False                       # old already failed this one
new = dict(old)
new["case-03"] = False                       # new regressed one case the old passed
new["case-07"] = True                        # new fixed the one old failed

result = migration_gate(old, new)
for k, v in result.items():
    print(f"{k}: {v}")

old_rate: 0.9
new_rate: 0.9
delta: 0.0
regressions: ['case-03']
decision: adjust

Read the output: overall pass-rate is unchanged (0.9 → 0.9), but the models disagree on which cases — the new one fixed case-07 and broke case-03. The aggregate hid a real regression, which is why the gate reports regressions explicitly and returns adjust: go look at case-03, tune the prompt, re-run. A pass-rate that only went up would return go; a drop past the band would return block.

10 · Tech-lead — owning migrations across a fleet tech-lead

Everything so far assumed one service and one prompt. Now multiply it by forty. When you lead a team, "the model is being retired" doesn't land on one call site — it lands on every service your group owns, each with its own prompts, its own quirks, its own on-call engineer who's already busy. The loop from §8 is correct for each service; the tech-lead's problem is making it happen forty times without it being forty heroic, error-prone one-offs.

The reframe that makes this tractable is the same one from §7, promoted to an org principle: a model version is a dependency, so manage it with the boring machinery you already use for dependencies. You don't hand-track which service uses which version of a library from memory — you pin it in one discoverable place, you gate upgrades on CI, you roll them out behind config you can flip, and you keep the old version installable until the new one has proven itself. Do exactly that for the model id and a fleet migration stops being a scramble and becomes a checklist anyone on the team can execute.

The failure mode a lead is specifically paid to prevent is the "scavenger hunt": a deprecation lands, and the team spends two days just finding every place a model id is hardcoded, because it's scattered as string literals across repos with no single grep that surfaces them. One pinned constant per service, evals wired into the build, the id behind a flag, and a written per-version change checklist turn that scavenger hunt into a few minutes of routine work — and, just as importantly, make the rollback a config flip rather than an emergency deploy. The levers that get you there:

Fleet-level migration discipline

1. One pinned id per service, discoverable in one grep. A single MODEL constant (or a shared config key) per service. When a deprecation lands, you want rg 'claude-' to find every call site in seconds — not a scavenger hunt.
2. Evals are a shipping gate, tied to the prompt. The eval set lives with the code and runs in CI. A model or prompt change that drops the gate (the migration_gate returning block) fails the build.
3. The model id is a flag, not a constant edit. Route it through a feature flag / config so you can canary and roll back without a deploy. Deploy-to-rollback is too slow when a migration goes sideways in production.
4. Migration is a checklist, not a memory. Codify the breaking changes (prefill → structured output, budget_tokens → adaptive thinking, drop sampling params) so every service applies the same edits. Anthropic publishes a per-version migration guide — start from it.
5. Watch refusals and stop reasons after cutover. New models can refuse more appropriately (handle stop_reason == "refusal") and hit the context window differently. Add these to the canary dashboard, not just latency and cost.
6. Keep the old id available during the canary. Until the new model is at 100% and holding, the old (non-retired) id is your instant fallback. Don't delete the old path until the new one has soaked.

The mental model: a model version is a dependency, and you manage it like any other — pinned, tested in CI, rolled out behind a flag, monitored, and rolled back cleanly. Prompting well (Half A) makes each service work; the migration loop (Half B) keeps it working as the model underneath it moves.

import anthropic
client = anthropic.Anthropic()

doc = "Our refund window is 30 days from delivery."
prompt = (
    "<document>\n" + doc + "\n</document>\n"
    "<question>How long do customers have to request a refund?</question>"
)
resp = client.messages.create(
    model="claude-sonnet-4-6", max_tokens=128,
    messages=[{"role": "user", "content": prompt}],
)
print(resp.content[0].text)

import anthropic
client = anthropic.Anthropic()

SYSTEM = ("You are a support classifier. Reply with exactly one label: "
          "billing, technical, or other.")   # stable -> cacheable
resp = client.messages.create(
    model="claude-sonnet-4-6", max_tokens=8,
    system=SYSTEM,
    messages=[{"role": "user", "content": "My card was charged twice."}],  # variable
)
print(resp.content[0].text)

import anthropic
client = anthropic.Anthropic()

schema = {"type": "object",
          "properties": {"label": {"type": "string"},
                         "confidence": {"type": "number"}},
          "required": ["label", "confidence"]}
resp = client.messages.create(
    model="claude-sonnet-4-6", max_tokens=128,
    output_config={"format": {"type": "json_schema", "schema": schema}},
    messages=[{"role": "user", "content": "Classify: the app keeps crashing."}],
)
print(resp.content[0].text)   # valid JSON per the schema

import anthropic
client = anthropic.Anthropic()

long_doc = "...(many pages of policy text)..."
prompt = (
    "<document>\n" + long_doc + "\n</document>\n"
    "<instructions>First quote the exact sentence that answers the "
    "question, then answer in one line.</instructions>\n"
    "<question>What is the SLA for critical incidents?</question>"
)
resp = client.messages.create(
    model="claude-sonnet-4-6", max_tokens=256,
    messages=[{"role": "user", "content": prompt}],
)
print(resp.content[0].text)

def migration_gate(old, new, band=0.03):
    assert len(old) == len(new)
    regressed = [i for i, (o, n) in enumerate(zip(old, new)) if o and not n]
    drop = (sum(old) - sum(new)) / len(old)
    if not regressed:
        decision = "go"
    elif drop <= band:
        decision = "adjust"
    else:
        decision = "block"
    return {"decision": decision, "regressed": regressed, "net_drop": round(drop, 4)}

old = [1,1,1,1,1,1,1,1,1,1]
new = [1,1,0,1,1,1,1,1,1,1]     # one regression, 10% drop
print(migration_gate(old, new))  # block (drop 0.1 > band)

def uses_prefill(messages):
    return bool(messages) and messages[-1].get("role") == "assistant"

def gate(old, new, band=0.03):
    reg = [i for i,(o,n) in enumerate(zip(old,new)) if o and not n]
    drop = (sum(old)-sum(new))/len(old)
    return "go" if not reg else ("adjust" if drop<=band else "block")

prompts = {
    "p1": {"messages": [{"role":"user","content":"x"}],
           "old": [1,1,1,1], "new": [1,1,1,1]},
    "p2": {"messages": [{"role":"user","content":"x"},
                        {"role":"assistant","content":"{"}],   # prefill!
           "old": [1,1,1,1], "new": [1,1,1,1]},
}
plan = {}
for name, p in prompts.items():
    if uses_prefill(p["messages"]):
        plan[name] = "refactor: prefill -> output_config.format"
    else:
        d = gate(p["old"], p["new"])
        plan[name] = "canary behind flag" if d == "go" else f"hold ({d})"
print(plan)

Knowledge check check yourself