Request parameters, in full

1 · One endpoint, many knobs essential

Picture the cockpit of a plane you've never flown. Dozens of switches, and the panic move is to start flipping the ones that look interesting. But a good pilot knows that almost all of those switches sit at a safe default, and touching the wrong one on a calm day is how you make things worse, not better. The Claude API is exactly that cockpit: one big panel of parameters, most of which you should leave alone unless you can say out loud why you're moving them.

Here's the reassuring part, and the reason this reference is worth reading once end to end: it's all one call. People new to LLM APIs expect a maze — a separate endpoint for tools, another for vision, another for streaming, another for "reasoning mode". There isn't. Everything is a keyword argument on client.messages.create(...). Once that clicks, "how do I add tools?" stops being "which API do I switch to?" and becomes "which parameter do I add?" — a much smaller, much friendlier question.

The common mistake this whole lesson is built to prevent is over-configuring: a beginner reads that temperature, top_p, and top_k all exist, sets all three "to be safe," and ends up with a call that's slower, costlier, and often dumber than the three-line version would have been. Every knob you turn is a chance to break something that was working. So the mental model to carry from the first page to the last is simple: the defaults are good — change them deliberately, one at a time, with a reason you could defend.

Almost everything you do with Claude goes through a single call: client.messages.create(...). Tools, vision, streaming, thinking, structured output — none of them are separate APIs. They are all parameters on this one call. Learn the parameters once and the whole surface opens up.

This lesson is a reference. Earlier lessons showed you the parameters you needed in the moment (a model here, a max_tokens there); this one lays every parameter out in a single place, with its default, what it actually changes, and when — if ever — you should touch it. Read it once end to end, then come back to the big table whenever you're unsure.

There are only three required parameters — model, max_tokens, and messages. Everything else has a sensible default, and the single most common mistake is over-configuring: setting knobs you don't understand and making the model worse. The mental model to carry through this lesson: the defaults are good — change them deliberately, one at a time, with a reason.

2 · The parameter groups essential

A flat list of fifteen parameters is a memorisation problem. Five labelled drawers is a filing problem — and filing is far easier. The reason this section exists before the big reference table is that a list you have to memorise slides out of your head by next week, but a shape you understand sticks. So instead of asking you to hold fifteen names in your head, we group them into five drawers, and from then on the only question about any parameter is "which drawer does this live in?"

Think of it like the controls in a car, sorted by what they affect. Some controls you must operate to move at all (key, gear, wheel) — those are the required parameters. Some shape where you're going (the destination you punch into the GPS) — that's your prompt. Some tune how the car behaves without changing the destination (sport mode, eco mode) — that's sampling. Some are optional attachments you only fit when the trip needs them (a roof box) — that's tools. And some are about the journey's logistics rather than the drive itself (toll transponder, trip logger) — the operational knobs. Same panel, five very different jobs.

The mistake this grouping heads off is reaching into the wrong drawer. Engineers who don't have this map will try to make a response "more focused" by adding a tool, or try to speed up a call by lowering temperature — both are category errors, like adjusting the GPS to change the engine mode. When a parameter confuses you, name its drawer first: is this about what I'm asking (prompt), how the words are chosen (sampling), whether it can act (tools), or how the request is delivered and billed (operational)? The drawer usually answers the question before you've read the docs.

The parameters fall into five natural groups. Hold this shape in your head and every specific parameter has a home:

Required is the minimum any call needs. Prompt shaping is where your actual instructions and conversation live. Sampling tunes how the model picks the next token. Tools let the model call functions. Operational knobs govern delivery, reasoning, and billing rather than the content of the answer. The reference table in §3 uses these same groups.

3 · The full reference table essential

This is the page you'll come back to at 2am when a call is misbehaving and you can't remember whether the default for temperature is 0 or 1. Don't try to absorb it in one sitting — that's not what a reference is for. Read it once to learn the shape (the five drawers from §2, laid out row by row), then treat it as the map you unfold whenever a parameter surprises you.

The single most useful column here is the last one — "When to touch it." A lot of API docs tell you what a parameter does and stop there, which quietly implies you should be setting all of them. This table takes the opposite stance: for every non-required row it tells you the specific situation that justifies the deviation, and by omission, tells you to leave it alone the rest of the time. If you can't find your situation in that column, the honest answer is usually "don't set this parameter."

Read each row as a small contract: the default is what happens if you say nothing, what it does is the behaviour, and when to touch it is the trigger. Notice how few rows say "Always" — only the three required ones and system. Everything below system is a lever for a special case, and the skill this table teaches is recognising when you're actually in that special case versus when you just think you are.

Every parameter of messages.create, its default, what it does, and when you'd actually reach for it. Bookmark this section.

4 · Required + prompt shaping — model, max_tokens, messages, system essential

Get these four right and you can ship real features; get them subtly wrong and you'll spend an afternoon debugging a "the model isn't following instructions" bug that was never about the model at all. This is the group you touch on essentially every call, so it's worth slowing down on the two that actually have shape to them — messages and system — rather than treating them as boilerplate.

The mental model for messages is a transcript of a conversation, written down turn by turn. Each turn is one speaker (a role, either "user" or "assistant") and what they said (content). The API is stateless — it has no memory of earlier calls — so this transcript is the whole story every time; if you want the model to "remember" the last three turns, you resend all three. That's the single most common beginner surprise: the model didn't forget, you simply didn't include the history.

Content can be a plain string when all you have is text, but it can also be a list of content blocks — {"type": "text", ...}, {"type": "image", ...}, a tool result — which is how one user turn carries a screenshot and a question together. system is the parameter people most often misuse: it is not another message in the transcript, it's a separate top-level channel for standing instructions — the model's role, rules, and persona. The analogy is a play: system is the stage direction that tells the actor who they are and how to behave; messages is the actual dialogue. Put "you are a terse DevOps assistant" in system, not in a user turn, and it carries the weight of an instruction rather than a passing request. And when that instruction is large and stable, giving system as a list of text blocks (rather than a bare string) lets you attach cache_control and stop paying to re-read the same prefix on every call.

These are the parameters you set on essentially every call. model and max_tokens are scalars; the interesting shape is in messages and system.

messages is a list of turns. Each turn has a role ("user" or "assistant") and content. Content can be a plain string, or — when you need images, documents, or tool results — a list of content blocks ({"type": "text", ...}, {"type": "image", ...}, and so on). system is separate from messages: it's top-level instructions, given as a string, or as a list of text blocks when you want to attach cache_control to cache a large stable prompt.

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

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

resp = client.messages.create(
    model="claude-opus-4-8",            # REQUIRED: which model answers
    max_tokens=1024,                    # REQUIRED: hard cap on output tokens
    system=[                            # top-level instructions (list form → cacheable)
        {
            "type": "text",
            "text": "You are a terse DevOps assistant. Answer in one sentence.",
            "cache_control": {"type": "ephemeral"},   # cache this stable prefix
        }
    ],
    messages=[                          # REQUIRED: the conversation
        {"role": "user", "content": "What does 'kubectl get pods' show?"},
        # content can also be a LIST of blocks, e.g. text + an image:
        # {"role": "user", "content": [
        #     {"type": "text", "text": "What's in this screenshot?"},
        #     {"type": "image", "source": {"type": "url", "url": "https://.../shot.png"}},
        # ]},
    ],
)

# content is a LIST of blocks — read only the text ones
print(next((b.text for b in resp.content if b.type == "text"), ""))

5 · Recipe — temperature vs top_p (and stop_sequences) intermediate

The most common cause of "my extraction pipeline gives a different answer every time I run it" is a single unset parameter — temperature — sitting at its default of 1. Sampling parameters are where a lot of flakiness (and a lot of wasted 400 errors) come from, so they're worth understanding rather than copy-pasting.

Here's what these knobs actually control. At every step the model produces a probability distribution over possible next tokens — "the next word is 78% likely to be X, 12% Y, 3% Z…". temperature decides how boldly it gambles on that distribution. Turn it toward 0 and the model almost always takes the single most likely token — flat, predictable, repeatable. Leave it at 1 (the default) and it samples across the full range, which is what you want for prose and brainstorming but is a menace for a task where you need the same answer twice. The intuition: temperature is the "how surprising am I allowed to be?" dial.

top_p is a second, different way to constrain that same gamble — instead of scaling the whole distribution, it lops off the long tail and only samples from the most-likely tokens that together add up to probability p. Because both knobs shape the same randomness, the golden rule is to set at most one of them. This is the classic beginner trap: setting temperature=0.2 and top_p=0.9 "to be extra careful" doesn't give you finer control, it gives you two levers fighting over the same distribution — and on the Anthropic API it's a frequent source of 400 errors. Anthropic's own guidance is to adjust temperature and leave top_p alone; reach for top_p only if you have a specific reason, and drop temperature when you do. Note also that temperature here ranges 0 to 1 (not the 0–2 you may have seen on other providers). A completely separate knob, stop_sequences, has nothing to do with randomness — it's a list of strings that end generation the instant the model writes one (the marker itself is not returned), and when one fires stop_reason becomes "stop_sequence".

temperature ranges 0 to 1. Near 0 the model almost always picks the most likely token — good for extraction, classification, and anything you want reproducible-ish. At 1 (the default) it samples across the full distribution — good for brainstorming and prose. stop_sequences is unrelated to randomness: it's a list of strings that, when the model generates one, cut the response off immediately (the stop string itself is not returned). When that happens, stop_reason is "stop_sequence" and stop_sequence tells you which one fired.

sampling.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=256,
    temperature=0,                      # near-deterministic: extraction / classification
    # top_p=0.9,                        # DON'T also set this — pick ONE knob, not both
    stop_sequences=["\n\nEND"],       # stop the moment the model writes this marker
    system="Extract the error code. Output only the code, then write \n\nEND.",
    messages=[{"role": "user",
               "content": "Log: FATAL 2026-09-06 db timeout code=E5521 retry=3"}],
)

text = next((b.text for b in resp.content if b.type == "text"), "")
print("text:", repr(text))
print("stop_reason:", resp.stop_reason)      # "stop_sequence" if the marker fired
print("stop_sequence:", resp.stop_sequence)  # which sequence caused the stop

6 · Recipe — tools & tool_choice (force / allow / forbid) intermediate

Someone forces a tool, then writes resp.content[0].text to read the answer — and gets an empty string or a crash. It's one of the most common tool-use bugs, and it comes from not internalising a single fact: forcing a tool changes the shape of the response. This section is really about two parameters that work as a pair, and the surprising thing that happens when you turn the second one up.

The mental model: tools is you handing the model a labelled toolbox — each entry a name, a plain-English description, and a JSON schema describing the arguments it takes. Crucially, the model never runs your tool; it decides a tool is needed and hands you the filled-in arguments in a tool_use block, and your code does the actual work. tool_choice is the separate dial for how much say the model gets in whether to reach into that box at all — think of it as a spectrum from "use your judgement" to "you must use this exact tool" to "hands off the toolbox entirely."

That dial has a consequence people miss, and it's the whole reason this is a recipe rather than a one-liner: the moment you force a tool (with {"type":"tool"} or {"type":"any"}), the model stops answering in prose. There is no text block to read — the answer lives inside the tool_use block's arguments, and stop_reason flips to "tool_use" to tell you so. This is a feature, not a quirk: forcing a tool is exactly how you get guaranteed structured extraction — you know the model will emit a dict matching your schema instead of a paragraph you'd have to parse. It's the right move for "pull these fields out of this text" and the wrong move for open-ended chat, where forcing a tool just straitjackets a model that should be free to answer normally. Read stop_reason first, then read from the block it points you to.

tools is a list of tool definitions (each a name, a description, and a JSON-schema for its input). tool_choice controls whether and which tool the model uses. It has four modes:

Any of these can also carry "disable_parallel_tool_use": true to force at most one tool call per turn (by default the model may request several at once). Here is a forced tool call — useful when you want structured extraction and you know the model should always fill in this one tool:

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

client = anthropic.Anthropic()

record_incident = {
    "name": "record_incident",
    "description": "Record a parsed incident from an alert line.",
    "input_schema": {
        "type": "object",
        "properties": {
            "service": {"type": "string"},
            "severity": {"type": "string", "enum": ["low", "high", "critical"]},
        },
        "required": ["service", "severity"],
    },
}

resp = client.messages.create(
    model="claude-opus-4-8",
    max_tokens=512,
    tools=[record_incident],
    # FORCE this exact tool + at most one call this turn:
    tool_choice={"type": "tool", "name": "record_incident",
                 "disable_parallel_tool_use": True},
    messages=[{"role": "user",
               "content": "CRITICAL checkout-api is down, 500s everywhere"}],
)

# a forced tool means stop_reason == "tool_use" and a tool_use block with the args
tool_use = next((b for b in resp.content if b.type == "tool_use"), None)
print(resp.stop_reason)          # "tool_use"
print(tool_use.name, tool_use.input)   # record_incident {'service': 'checkout-api', ...}

7 · Recipe — extended thinking advanced

Two things trip everyone up here, and both throw a 400 in production if you get them wrong: the old budget_tokens syntax is gone, and you cannot lower the temperature while thinking is on. Extended thinking is a genuinely powerful lever — but it's also the one parameter with rules that changed recently, so muscle memory from a tutorial written a year ago will now fail.

What thinking actually buys you: on a hard, multi-step problem — planning a migration, chasing a subtle bug, a maths proof — the model reasons privately before committing to an answer, the way you'd scribble on a whiteboard before speaking. That scratch-work costs extra tokens and latency, which is exactly why it's the wrong tool for a lookup or a one-word classification and the right one when a wrong answer is expensive. The way you turn it on today is adaptive thinking ({"type": "adaptive"}), where the model itself decides how deep to go, and you steer the overall depth with a separate dial, output_config.effort (low through max).

Now the two gotchas, stated plainly so you never hit them. First, the pre-2026 form {"type": "enabled", "budget_tokens": N} — where you handed the model a fixed thinking budget — is removed on Opus 4.8 / 4.7 and returns a 400; the replacement is adaptive thinking plus effort, and there's no fixed token budget to set anymore. Second, and this is the subtle one: extended thinking always runs at temperature=1. You cannot combine it with a lowered temperature, or with top_p or top_k — those sampling parameters are incompatible with thinking and the request 400s. The reflex to "make thinking more focused by dropping the temperature" is precisely the trap. So the whole recipe collapses to one sentence: turn thinking on, tune depth with effort, and leave every sampling knob untouched.

Extended thinking lets the model reason privately before it answers — a real lever on hard, multi-step problems (planning, tricky debugging, math). On current models you turn it on with adaptive thinking, where the model itself decides how much to think, and you tune the overall depth with output_config.effort.

Two accuracy points that trip people up. First, on Opus 4.8 / 4.7 the old {"type": "enabled", "budget_tokens": N} form is gone — it returns a 400. Use {"type": "adaptive"}. Second, thinking runs at temperature=1 — you cannot combine extended thinking with a lowered temperature (or with top_p/top_k); those sampling params are incompatible with thinking. So the recipe is: turn thinking on, leave sampling alone.

thinking.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=8000,
    thinking={"type": "adaptive", "display": "summarized"},  # model decides how much
    output_config={"effort": "high"},   # low | medium | high | max  — the depth dial
    # NOTE: do NOT also set temperature / top_p / top_k here — thinking runs at
    # temperature=1 and rejects those sampling params.
    messages=[{"role": "user",
               "content": "Plan a zero-downtime Postgres major-version upgrade."}],
)

for block in resp.content:
    if block.type == "thinking":
        print("[thinking]", block.thinking[:80], "...")
    elif block.type == "text":
        print("[answer]", block.text)

8 · Validate before you send (this one runs offline) professional

A 400 from a bad parameter combination isn't free — it costs you a round trip, and in production it costs you a failed request, a retry, and possibly a 2am page. The frustrating part is that almost every one of these mistakes is knowable before the request ever leaves your machine: you don't need Claude to tell you that you set both temperature and top_p, or that max_tokens is bigger than the model can produce. You already have all the information.

This is the same instinct as a compiler catching a type error before you run the program, or a form validating an email field before it hits the server. The principle is shift the check left — move it as close to where the mistake is made as you can, so it fails cheaply and instantly instead of expensively and remotely. A malformed params dict caught by a unit test costs nothing; the same dict caught as a 400 in front of a user costs a request, latency, and trust.

The common trap this guards against is treating the API as your validator — "I'll just send it and see if it errors." That works exactly once, in a REPL, on a quiet afternoon. It does not scale to a codebase with fifty call sites where a subtle combination (thinking on and a lowered temperature, say) only trips on the one route nobody tested. The helper below is deliberately pure stdlib — no API key, no network — so it drops straight into a test and lints every call site offline. It doesn't try to be clever; it just encodes the handful of rules this lesson taught and returns a plain list of human-readable warnings.

Most parameter mistakes are catchable before you spend a request: both temperature and top_p set, a max_tokens that exceeds the model's output cap, or extended thinking combined with a non-default temperature. The helper below is pure stdlib — no API key, no network — and runs with a plain python file.py. It inspects a params dict and returns a list of warnings, so you can lint your call sites in a test.

validate_params.py# Catch the common messages.create mistakes locally, before spending a request.
# Model output caps as of this writing (verify current values in the docs):
MODEL_MAX_OUTPUT = {
    "claude-opus-4-8": 128_000,
    "claude-sonnet-4-6": 64_000,
    "claude-haiku-4-5": 64_000,
}


def validate_params(params):
    """Return a list of human-readable warnings for a messages.create params dict.
    Pure stdlib; does not call the API."""
    warnings = []
    model = params.get("model")
    if not model:
        warnings.append("model is REQUIRED and missing")
    if "max_tokens" not in params:
        warnings.append("max_tokens is REQUIRED and missing")
    if not params.get("messages"):
        warnings.append("messages is REQUIRED and empty/missing")

    # don't set both temperature and top_p
    if "temperature" in params and "top_p" in params:
        warnings.append("both temperature and top_p set — pick ONE, not both")

    # max_tokens must fit the model's output cap
    cap = MODEL_MAX_OUTPUT.get(model)
    mt = params.get("max_tokens")
    if cap is not None and isinstance(mt, int) and mt > cap:
        warnings.append(f"max_tokens={mt} exceeds {model} output cap of {cap}")

    # extended thinking requires temperature == 1 (i.e. leave it unset)
    thinking = params.get("thinking")
    thinking_on = isinstance(thinking, dict) and thinking.get("type") in ("adaptive", "enabled")
    if thinking_on and params.get("temperature", 1) != 1:
        warnings.append("thinking is on but temperature != 1 — thinking runs at temperature=1")
    if thinking_on and ("top_p" in params or "top_k" in params):
        warnings.append("thinking is on but top_p/top_k set — incompatible with thinking")

    return warnings


bad = {
    "model": "claude-opus-4-8",
    "max_tokens": 200_000,          # over the 128K cap
    "messages": [{"role": "user", "content": "hi"}],
    "temperature": 0.2,             # both temperature ...
    "top_p": 0.9,                   # ... and top_p
    "thinking": {"type": "adaptive"},  # thinking on, but temperature != 1
}
for w in validate_params(bad):
    print("WARN:", w)
print("ok:", validate_params({
    "model": "claude-opus-4-8", "max_tokens": 1024,
    "messages": [{"role": "user", "content": "hi"}],
}))

WARN: both temperature and top_p set — pick ONE, not both
WARN: max_tokens=200000 exceeds claude-opus-4-8 output cap of 128000
WARN: thinking is on but temperature != 1 — thinking runs at temperature=1
WARN: thinking is on but top_p/top_k set — incompatible with thinking
ok: []

9 · Tech-lead — operational knobs & a house policy tech-lead

When you're the lead, the failure mode isn't a bad parameter on one call — it's fifty engineers each guessing at stream, metadata, and betas in fifty slightly different ways. The operational knobs are the group where inconsistency, not incorrectness, is the real cost. Any single call site setting them "wrong" is survivable; a codebase where nobody agrees on them is a slow-motion incident waiting for the day support asks "which user made this call?" and the answer is "we don't log that."

What makes this group different is that these parameters don't change what the model says at all — they govern how the request is delivered, tracked, and billed. That's precisely why they should be a platform decision, not a feature decision. The content parameters (messages, system, tools) belong to whoever is building the feature and vary per request. The operational parameters are cross-cutting: streaming behaviour, per-user tracking, service tier, beta flags. Leave those to individual judgement and you get drift; centralise them and every engineer inherits the right behaviour for free.

The concrete mechanism a good lead reaches for is a thin house wrapper — one function that everyone calls instead of messages.create directly, which fills in the model default, a sane max_tokens, the streaming decision, and the metadata.user_id, and runs the validate_params linter from §8 in that one place. The mistake to avoid is the opposite instinct — baking these into a giant shared config object with thirty toggles, or worse, letting beta flags accumulate uncommented across the codebase until nobody remembers which are still needed. The policy below is the short version: stream the big and interactive calls, tag every production request with a hashed user id, turn thinking on by route, treat service_tier and betas as deliberate opt-ins you verify against current docs, and put the whole lot behind one wrapper.

The last group of parameters doesn't change what the model says — it changes how the request is delivered, tracked, and billed. A lead sets a house policy for these so every call site is consistent:

Operational parameter policy

1. stream for anything interactive or large. Streaming isn't just UX — it's how you avoid HTTP timeouts on big max_tokens calls. Policy: stream any user-facing response and any call with max_tokens above ~16K; use .get_final_message() to still get the assembled reply and usage.
2. metadata.user_id on every production call. Attach a stable, hashed per-end-user identifier (never raw PII) so abuse and rate-limit issues can be traced to a tenant. It costs nothing and it's the field support will ask you for.
3. thinking + effort by route, not globally. Turn thinking on for the hard routes (planning, debugging) and leave it off for lookups and classification. Standardise the effort level per route so cost is predictable.
4. service_tier only if you have an arrangement. It requests a priority / standard / batch service level; the exact accepted values and behaviour evolve, so treat it as opt-in and verify the current options in the docs before wiring it in.
5. betas deliberately, never by default. Beta features live on client.beta.messages with an explicit flag string. Pin the flag, document why you need it, and plan to remove it when the feature goes GA — don't leave stale beta headers scattered across the codebase.
6. Centralise the defaults. Wrap messages.create in one thin house function that fills model, sane max_tokens, metadata, and the streaming decision. Then validate_params from §8 runs in that one place.

The through-line: the content parameters (messages, system, tools) are per-request and belong to the feature; the operational parameters (stream, metadata, service_tier, betas) are cross-cutting and belong to the platform. Put the second set behind one wrapper and every engineer inherits the house policy for free.

import anthropic
client = anthropic.Anthropic()

resp = client.messages.create(
    model="claude-sonnet-4-6",   # required
    max_tokens=256,               # required: hard cap on output
    messages=[{"role": "user", "content": "Define idempotency."}],  # required
)
# system is optional: with no role/rules given, the model uses its defaults.
print(resp.content[0].text)

import anthropic
client = anthropic.Anthropic()

resp = client.messages.create(
    model="claude-sonnet-4-6",
    max_tokens=64,
    temperature=0,           # focused, repeatable; do NOT also set top_p
    stop_sequences=["\n\n"],  # stop at first blank line
    messages=[{"role": "user", "content": "Extract the year: Founded in 1994."}],
)
print(resp.content[0].text, resp.stop_reason)

import anthropic
client = anthropic.Anthropic()

tools = [{
    "name": "record_temp",
    "description": "Record a temperature reading.",
    "input_schema": {"type": "object",
        "properties": {"celsius": {"type": "number"}},
        "required": ["celsius"]},
}]
resp = client.messages.create(
    model="claude-sonnet-4-6", max_tokens=256, tools=tools,
    tool_choice={"type": "tool", "name": "record_temp"},
    messages=[{"role": "user", "content": "It is 21 degrees C."}],
)
# stop_reason == 'tool_use' -> the args are in a tool_use block:
for block in resp.content:
    if block.type == "tool_use":
        print(block.input)   # {'celsius': 21}

import anthropic
client = anthropic.Anthropic()

resp = client.messages.create(
    model="claude-opus-4-8",
    max_tokens=2048,
    thinking={"type": "adaptive", "display": "summarized"},
    output_config={"effort": "high"},   # low | medium | high | max
    # NOTE: with thinking on, do NOT pass temperature/top_p/top_k -> 400.
    messages=[{"role": "user", "content": "Prove sqrt(2) is irrational."}],
)
for b in resp.content:
    if b.type == "text":
        print(b.text)

def validate_params(p, model_cap):
    warns = []
    if "temperature" in p and "top_p" in p:
        warns.append("set temperature OR top_p, not both")
    if p.get("max_tokens", 0) > model_cap:
        warns.append(f"max_tokens {p['max_tokens']} > cap {model_cap}")
    if p.get("thinking") and p.get("temperature", 1) != 1:
        warns.append("thinking requires temperature=1 (drop it)")
    for k in ("model", "max_tokens", "messages"):
        if k not in p:
            warns.append(f"missing required param: {k}")
    return warns

bad = {"model": "claude-opus-4-8", "max_tokens": 200000,
       "messages": [], "temperature": 0.3, "top_p": 0.9}
print(validate_params(bad, model_cap=128000))

CAPS = {"claude-opus-4-8": 128000, "claude-sonnet-4-6": 64000,
        "claude-haiku-4-5": 64000}

def house_policy(p):
    p = dict(p)
    cap = CAPS.get(p["model"], 4096)
    p.setdefault("max_tokens", 1024)
    p["max_tokens"] = min(p["max_tokens"], cap)      # never exceed the cap
    if "temperature" in p:
        p.pop("top_p", None)                          # one sampling knob
    md = p.setdefault("metadata", {})
    if "user_id" not in md:
        raise ValueError("metadata.user_id required for abuse tracking")
    return p

out = house_policy({"model": "claude-sonnet-4-6", "max_tokens": 999999,
                    "temperature": 0.2, "top_p": 0.8,
                    "metadata": {"user_id": "u-42"}})
print(out["max_tokens"], "top_p" in out)   # 64000 False

Knowledge check check yourself