POST
Multi-turn Conversation

Overview

The Claude API is stateless — Claude has no memory between requests. Every request starts fresh. To maintain context across a conversation, your application must pass the full conversation history with every request. This is not a limitation, it is a deliberate design decision that gives developers complete control over what context Claude sees at any point in the conversation.

How Context Works

Every message in the conversation is passed as an object in the messages array. Claude reads the entire array on every request and responds based on the full history you provide.
Claude’s response to the third message:
“Your name is Chisaneme and you are a technical writer.”
Claude knew the answer because you passed the full history. Without it, Claude would have no context.

The Alternating Role Pattern

Messages must strictly alternate between user and assistant roles: user → assistant → user → assistant → user The array must always:
  • Start with a user message
  • Alternate between user and assistant roles throughout
The API does not always throw an error for consecutive messages of the same role — but the behavior is unpredictable. In real testing, two consecutive user messages caused Claude to answer only the second message and silently drop context from the first. Always maintain the alternating pattern for reliable behavior.

Token Accumulation

Every message in the history consumes input tokens. As a conversation grows, input tokens increase with every request: Input tokens are billed on every request — a long conversation history means higher costs on every subsequent turn.
For long-running conversations, consider summarizing older messages into a single context block rather than passing the full raw history. This keeps token counts manageable without losing important context.

Context Window Limit

The total conversation history including all messages and the system prompt, must fit within the model’s context window: 200,000 tokens is approximately 150,000 words. For most applications this limit is rarely reached — but document-heavy or very long conversations can approach it. If the limit is exceeded the API returns:

Who Manages History

Your application manages conversation history — not the API. A typical implementation looks like this:
  1. User sends a message
  2. Your app appends it to the history array as a user turn
  3. Your app sends the full history to the API
  4. Claude responds
  5. Your app appends Claude’s response to the history as an assistant turn
  6. Repeat from step 1
The API receives the full history every time. It never stores anything between requests.

Further Reading

Messages

Deep dive into the messages array structure

Tokens

How token accumulation affects cost in long conversations

System Prompt

Add a system prompt to shape behavior across all turns

Tool Use

Maintain context across tool use cycles

Authorizations

x-api-key
string
header
required

Headers

anthropic-version
string
required
Example:

"2023-06-01"

Body

application/json
model
enum<string>
required

The Claude model to use.

Available options:
claude-sonnet-4-6,
claude-opus-4-6,
claude-haiku-4-5
Example:

"claude-sonnet-4-6"

max_tokens
integer
required

Maximum number of output tokens to generate.

Required range: x >= 1
Example:

1024

messages
object[]
required

Response

Successful response

id
string
Example:

"msg_01XFDUDYJgAACzvnptvVoYEL"

type
string
Example:

"message"

role
string
Example:

"assistant"

content
object[]
model
string
Example:

"claude-sonnet-4-6"

stop_reason
enum<string>
Available options:
end_turn,
max_tokens,
stop_sequence,
tool_use
Example:

"end_turn"

stop_details
object | null
usage
object