Foundations

The parameters that matter

The request has a handful of knobs. You'll set two on every call, three sometimes, and the rest rarely. This page is the field guide: what each knob does, when to turn it, and the sane default. Build a request by toggling parameters and watch the effect.

modelmax_tokens systemtemperature stop_sequencestop_p / top_kstream

Explain like I'm 10

Think of ordering a pizza. You always pick a size (that's model) and how many slices max (max_tokens). Sometimes you add special instructions ("no onions" = system) or say how adventurous the chef can be (temperature). And you can say "stop adding toppings once you reach pepperoni" (stop_sequences). Most knobs have a normal default — you only touch them when you have a reason.

Build a request — flip knobs, read the effect

model

max_tokens

temperature

system prompt stop_sequences stream

The field guide

Parameter	Required?	What it does	When to change it
`model`	yes	Which Claude answers (Haiku/Sonnet/Opus).	Every call. Route to the cheapest model that clears the bar → model selection.
`max_tokens`	yes	Hard cap on the reply length (in tokens). Reserves output room in the window.	Every call. Big enough for a full answer; too small → `stop_reason:"max_tokens"` (cut off).
`messages`	yes	The conversation, alternating user/assistant.	Every call — it is the conversation.
`system`	no	Standing instructions / role, separate from the chat.	Almost always — set the role and rules here → prompt anatomy.
`temperature`	no (def ~1.0)	Randomness. 0 = focused/repeatable; higher = more varied/creative.	Set 0 for extraction, classification, code. Raise for brainstorming/creative writing.
`stop_sequences`	no	Strings that make Claude stop the moment it produces one.	When you need output to end at a marker (e.g. stop at `"\n\n"` or `"END"`).
`stream`	no (def false)	Send the reply token-by-token as it's generated.	For chat UIs (show text as it types). Off for batch/backend jobs.
`tools`	no	Tool definitions that enable `tool_use`.	When the model needs to take actions → Domain 2.
`top_p` / `top_k`	no	Alternative sampling controls (nucleus / top-k).	Rarely. Prefer `temperature`; don't tune both at once.

Exam & practice traps: max_tokens limits the reply, not the input — and if a reply looks truncated, check stop_reason == "max_tokens" and raise it. For anything you want consistent (extraction, classification, evals), set temperature=0 — leaving it high is why "the same prompt gives different answers." Don't twiddle top_p and temperature together. And system is its own parameter, not a message.

Takeaways: set model + max_tokens + messages on every call, and system almost always. Reach for temperature=0 when you need repeatable output, raise it for creativity. Use stop_sequences to end at a marker and stream for typing UIs. Leave top_p/top_k alone unless you have a specific reason. Everything else (tools, thinking) turns on features covered in their own explainers.

Try these knobs for real in the runnable Python exercises (Exercise 3 is a temperature experiment). Next: how to read the API docs →