Workflow:Anthropics Anthropic sdk python Basic Message Conversation
| Knowledge Sources | |
|---|---|
| Domains | LLMs, Conversational_AI, API_Integration |
| Last Updated | 2026-02-15 12:00 GMT |
Overview
End-to-end process for creating single-turn and multi-turn conversations with Claude using the Anthropic Python SDK Messages API.
Description
This workflow covers the fundamental pattern for interacting with Claude through the Messages API. It demonstrates how to initialize the SDK client with authentication, construct message payloads with the required parameters (model, max_tokens, messages), send requests to the API, and process the structured response. The workflow extends to multi-turn conversations by accumulating message history and passing it back to subsequent API calls, enabling contextual follow-up interactions.
Usage
Execute this workflow when you need to integrate Claude into a Python application for text generation, question answering, content creation, or any conversational task. This is the foundational workflow for all Anthropic SDK interactions and serves as the starting point before adding streaming, tool use, or other advanced features.
Execution Steps
Step 1: Client Initialization
Create an Anthropic client instance that handles authentication and API communication. The client reads the API key from the ANTHROPIC_API_KEY environment variable by default, or accepts it as an explicit parameter. For asynchronous applications, use the AsyncAnthropic variant instead.
Key considerations:
- The API key can be provided explicitly or via environment variable
- The client manages connection pooling, retries (default 2), and timeouts (default 10 minutes)
- Both synchronous (Anthropic) and asynchronous (AsyncAnthropic) clients are available
Step 2: Message Request Construction
Build the message creation request with the required parameters: model identifier, maximum output tokens, and a list of messages following the conversation format. Each message has a role ("user" or "assistant") and content (string or structured content blocks).
Key considerations:
- The model parameter accepts named model strings (e.g., "claude-sonnet-4-20250514")
- max_tokens sets the upper bound on response length
- The messages list must alternate between user and assistant roles
- Optional parameters include system prompt, temperature, top_p, top_k, and stop_sequences
Step 3: API Request Execution
Send the constructed request to the Messages API endpoint via the client. The client handles HTTP communication, automatic retries on transient errors, request serialization, and response deserialization into typed Pydantic models.
Key considerations:
- The create() method returns a Message object with typed fields
- Retries use exponential backoff for rate limits and server errors
- Request parameters are validated via TypedDict type checking
Step 4: Response Processing
Extract and process the response from the returned Message object. The response contains content blocks (text, tool_use, etc.), stop reason, model identifier, token usage statistics, and a unique message ID.
Key considerations:
- Response content is a list of ContentBlock objects (TextBlock, ToolUseBlock, etc.)
- The stop_reason field indicates why generation stopped ("end_turn", "max_tokens", "stop_sequence", "tool_use")
- Usage contains input_tokens, output_tokens, and optionally cache_creation_input_tokens and cache_read_input_tokens
Step 5: Multi_turn Conversation Management
For follow-up interactions, append the assistant's response and a new user message to the conversation history, then make another API call. The SDK expects the full conversation history to be passed each time, as the API is stateless.
Key considerations:
- Maintain the full message list across turns for context continuity
- Assistant messages from the response must be formatted as MessageParam objects
- Token usage accumulates across turns; monitor to stay within model context limits
- System prompts remain constant across turns and are passed separately from messages