Joel Stevick

Chapter 1 · section 3 of 9

The request, field by field

messages and the shape of a conversation

The messages array is the entire input to the model, and it is a list of message objects. A message is one contribution to the exchange, and it has exactly two parts that matter here: a role, saying who is speaking, and content, saying what they said.

There are two roles you will write by hand:

  • user: you, or your program acting on your behalf.
  • assistant: the model.

The array must begin with a user message, and conventionally the two alternate. The complete array is the conversation, and it is the input: not a reference to a session on Anthropic’s servers, not a pointer to a conversation ID, but the literal text of everything said so far, sent again, in full, on every request.

The model is stateless: it retains nothing between requests, and every request is answered from scratch using only what that request contains. The illusion of memory in any chat product you have used is a program on the other side keeping an array and resending it. In Chapter 2 your program keeps one too, and what it puts in it is not what the model said but what the learner was shown, which turns out to matter.

model

The string claude-opus-5-5 is a model ID: the exact identifier of the model a request runs against. Anthropic serves several models at once, larger and slower, smaller and cheaper, and the model ID is how you choose between them. The field has no default; every request must name one.

max_tokens

max_tokens is a hard ceiling on how much the model may produce in this response. It is required, it is not a suggestion, and if the model reaches it the response simply stops, mid-sentence if necessary.

Which requires knowing what a token is.