Claude Opus 5.5 API Tutorial: Build a Python Coding Assistant

Claude Opus 5.5 arrived on September 22, 2026 with a model ID that can be called directly from Anthropic's Messages API. The useful part for a programmer is not the announcement itself: you can build a small Python coding assistant around the new model with a few files, an API key, and the official Anthropic SDK. This tutorial walks through that setup and then adds conversation history, adaptive thinking, and a simple code-review workflow.

What Claude Opus 5.5 changes for API developers

Anthropic positions Claude Opus 5.5 as a model for complex coding and long-running agentic work. Its Claude API model ID is claude-opus-5-5, with a 1 million token context window and a maximum output of 128,000 tokens. Anthropic lists pricing at $4 per million input tokens and $20 per million output tokens, while saying the model costs 40 percent less to run than Claude Opus 5. Those numbers matter when you move beyond a small experiment because large source files and repeated coding conversations can consume substantially more input context than a simple question.

The API still follows the familiar Messages API pattern: send a model name, a maximum output size, and a sequence of user and assistant messages. The API is stateless, so an application that needs memory must send the relevant conversation history with each request. That makes a small coding assistant a useful project because it exposes the same pattern you will later use in larger development tools.

Prepare Python and the Anthropic SDK

The current Anthropic Python SDK requires Python 3.10 or later and can be installed with pip install anthropic. Start with a virtual environment so the SDK version and your application's dependencies stay separate from other Python projects. The following commands create a project directory, create the environment, activate it, and install the SDK.

mkdir claude-opus-tutorial
cd claude-opus-tutorial

python -m venv .venv

On Windows, activate the environment with the following command.

.venv\Scripts\activate

On macOS or Linux, use the equivalent activation command below.

source .venv/bin/activate

Now install the official SDK.

pip install anthropic

If the installation completes without an error, the Python environment is ready. Keeping the environment isolated also makes it easier to remove the experiment later without affecting other applications.

Create the API key without putting it in your code

Create an API key in the Claude Console and store it as the ANTHROPIC_API_KEY environment variable. The Python SDK reads that variable automatically, so there is no reason to paste a secret into your source file. This is more than a style preference: a key committed to a public repository can be copied and abused before you notice the leak.

On Windows PowerShell, set the variable for the current terminal session like this:

$env:ANTHROPIC_API_KEY="your-api-key-here"

On macOS or Linux, use:

export ANTHROPIC_API_KEY="your-api-key-here"

Check that the variable exists before running the application. Do not print its value as part of that check. If you use a .env file during development, keep that file out of source control and use a secrets-management system when deploying the application.

Make the first Claude Opus 5.5 API request

Create a file named assistant.py. Import the Anthropic client, create an instance, and send one user message to Claude Opus 5.5. The important detail is the model identifier: claude-opus-5-5 is the current Claude API ID for this model.

import anthropic

client = anthropic.Anthropic()

message = client.messages.create(
model="claude-opus-5-5",
max_tokens=1024,
messages=[
{
"role": "user",
"content": "Explain Python decorators with a small example."
}
],
)

for block in message.content:
if block.type == "text":
print(block.text)

Run it with python assistant.py. A successful request returns a message containing content blocks, and the loop prints the text blocks returned by Claude. If you get an authentication error instead, check the environment variable before changing the Python code. If you get a model or parameter error, verify the model ID and the SDK version installed in the active virtual environment.

Turn the single request into a coding conversation

A real programming assistant needs context. Suppose the user first asks Claude to create a function and then asks for a test. The second request cannot rely on the server remembering the first message. The Messages API is stateless, so your program sends the previous user and assistant turns again.

Replace the single request with a small conversation stored in a Python list.

import anthropic

client = anthropic.Anthropic()

messages = [
{
"role": "user",
"content": "Write a Python function that validates an email address."
}
]

response = client.messages.create(
model="claude-opus-5-5",
max_tokens=1500,
messages=messages,
)

answer = "".join(
block.text for block in response.content
if block.type == "text"
)

print(answer)

messages.append({
"role": "assistant",
"content": answer
})

messages.append({
"role": "user",
"content": "Now write three unit tests for that function."
})

response = client.messages.create(
model="claude-opus-5-5",
max_tokens=1500,
messages=messages,
)

for block in response.content:
if block.type == "text":
print(block.text)

The second request now contains the original question, Claude's previous answer, and the new instruction. That is the basic memory mechanism for a Messages API application. In a production assistant, you would normally store these turns in a database or another application-level session store instead of keeping them in a Python list.

Add a system instruction for safer code reviews

A system instruction lets your application define behavior that should apply to the conversation. For a coding assistant, it can establish a practical review style instead of repeating the same instructions in every user message.

import anthropic

client = anthropic.Anthropic()

response = client.messages.create(
model="claude-opus-5-5",
max_tokens=2000,
system=(
"You are a careful Python code reviewer. "
"Identify correctness problems first, then security and "
"maintainability concerns. Explain each issue briefly and "
"provide corrected code only when it is useful."
),
messages=[
{
"role": "user",
"content": """
Review this function:

def average(values):
total = 0
for value in values:
total += value
return total / len(values)
"""
}
],
)

for block in response.content:
if block.type == "text":
print(block.text)

This changes the job Claude performs without changing the API structure. The user supplies code, while the system instruction establishes the review policy. Keep that distinction in your application because it becomes especially useful when different users can submit arbitrary prompts.

Use adaptive thinking when the problem needs deeper reasoning

Claude Opus 5.5 uses adaptive thinking, meaning the model can allocate reasoning effort according to the task rather than requiring the application to choose a fixed thinking-token budget. The current API documentation shows adaptive thinking enabled with thinking={"type": "adaptive"}. For a short formatting request it may add little value, but debugging a difficult algorithm or reasoning through several interacting functions is a better fit.

You can also request summarized thinking output when you want progress information exposed by the application. A basic request looks like this:

import anthropic

client = anthropic.Anthropic()

response = client.messages.create(
model="claude-opus-5-5",
max_tokens=4000,
thinking={
"type": "adaptive",
"display": "summarized"
},
messages=[
{
"role": "user",
"content": (
"Review this algorithm for correctness and edge cases. "
"Explain any bug and then provide a corrected implementation."
)
}
],
)

for block in response.content:
if block.type == "thinking":
print("Reasoning summary:")
print(block.thinking)
elif block.type == "text":
print("Answer:")
print(block.text)

There is an important implementation detail when combining thinking with tools or multiple turns: the thinking and tool-use blocks returned by the assistant need to be preserved when they are passed back in the conversation. Treat those response blocks as part of the API protocol rather than converting every response into plain text.

Build a small code-review command

Once the basic request works, the next useful step is to make the program accept a source file. This turns the experiment into something you can actually use from a terminal. The example below reads a Python file, places its contents inside a review prompt, and prints Claude's response.

import sys
import anthropic

client = anthropic.Anthropic()

if len(sys.argv) != 2:
print("Usage: python review.py app.py")
raise SystemExit(1)

filename = sys.argv[1]

with open(filename, "r", encoding="utf-8") as file:
source = file.read()

prompt = f"""
Review the following Python source code.

Look for:

1. Correctness bugs
2. Security problems
3. Error-handling problems
4. Unnecessary complexity

Explain each finding clearly and include corrected code for important issues.

Source code:

```python
{source}
```

"""

response = client.messages.create(
model="claude-opus-5-5",
max_tokens=4000,
messages=[
{
"role": "user",
"content": prompt
}
],
)

for block in response.content:
if block.type == "text":
print(block.text)

Save this as review.py and run python review.py app.py. The program now has a simple workflow: read code, send it to the model, and display the review. Before using this against sensitive source, remember that the code is being sent to an external API; project secrets, credentials, private keys, and other material that should never leave your environment should be filtered before transmission.

Know the limits before turning it into a real tool

The 1 million token context window gives Opus 5.5 room for large programming tasks, but it does not mean every request should contain an entire repository. Sending unnecessary files increases input usage and can make the useful context harder to identify. A better application selects the relevant files, summarizes stable project information, and keeps the active debugging context focused on the code involved in the current task.

There is another cost difference worth keeping in mind. Anthropic lists $4 per million input tokens and $20 per million output tokens for Opus 5.5, so a large generated response costs five times as much per token as the corresponding input. For a coding assistant, that makes max_tokens a practical control rather than a value to set arbitrarily high. Start with enough room for the expected answer, then increase it when the task genuinely requires a larger response.

Finally, keep the model ID in configuration rather than scattering it throughout a larger application. If your project eventually supports several models, a single configuration value makes it possible to change models without editing every API call. The first working script is small, but the same separation between credentials, model configuration, conversation state, and application logic is what keeps a prototype manageable when it grows.