Resolving Claude Opus 4.6 Thinking Model API Errors: A Complete Analysis of Format Compatibility Issues Between /v1/messages and /v1/chat/completions

Ever run into this situation: you're using the claude-opus-4-6-thinking model, and calls via /v1/chat/completions (OpenAI format) work perfectly fine, but when you switch to /v1/messages (Anthropic native format), you get the error content: Input should be a valid list? This seemingly counterintuitive phenomenon actually reveals a deep compatibility issue with the Thinking model across the two API formats. This article will start from the underlying API formats and thoroughly explain the root cause of the error and the correct way to call it.

Core Value: After reading this article, you'll understand the behavioral differences of the Thinking model between the two API formats, solve the content should be a valid list error, and master the correct way to handle thinking blocks in multi-turn conversations.

Core Points of Claude Thinking Model API Compatibility

Let's get straight to the point about this "counter-intuitive" phenomenon.

The Technical Essence of Claude Thinking Model API Errors

The error message content: Input should be a valid list reveals a crucial format difference:

Anthropic Native API (/v1/messages) requires the content field to be a content block array (list):

{
  "role": "assistant",
  "content": [
    {"type": "thinking", "thinking": "Let me analyze this problem...", "signature": "CpcH..."},
    {"type": "text", "text": "Here's my answer..."}
  ]
}

OpenAI Compatible Format (/v1/chat/completions) allows content to be a plain string:

{
  "role": "assistant",
  "content": "Here's my answer..."
}

When an API proxy platform (like APIYI's backend) has its channel configured for /v1/messages format, if an upstream client sends OpenAI-format string content, the proxy needs to convert "string" to [{"type": "text", "text": "string"}]. If this conversion is incomplete—especially when a Thinking model's response is passed back to the next round of conversation—it triggers the Input should be a valid list error.

Detailed Comparison of Claude Thinking Model API's Two Endpoint Formats

This is key to understanding the issue: the two endpoints have fundamentally different requirements for the content field.

Claude Thinking Model API Format Differences

Claude Thinking Model API Request Format Comparison

OpenAI Format Call (Recommended for Proxy Scenarios):

import openai

client = openai.OpenAI(
    api_key="YOUR_API_KEY",
    base_url="https://vip.apiyi.com/v1"
)

response = client.chat.completions.create(
    model="claude-opus-4-6-thinking",  # Proxy platform alias
    messages=[
        {"role": "user", "content": "Analyze the business prospects of quantum computing"}
    ],
    max_tokens=16000
)
print(response.choices[0].message.content)

import anthropic

client = anthropic.Anthropic(api_key="YOUR_API_KEY")

response = client.messages.create(
    model="claude-opus-4-6",  # Official model name, no -thinking suffix
    max_tokens=16000,
    thinking={
        "type": "adaptive"    # Enable thinking via parameter
    },
    messages=[
        {"role": "user", "content": "Analyze the business prospects of quantum computing"}
    ]
)

# Response content is a list containing thinking blocks and text blocks
for block in response.content:
    if block.type == "thinking":
        print(f"[Thinking Process] {block.thinking[:100]}...")
    elif block.type == "text":
        print(f"[Answer] {block.text}")

🎯 Calling Advice: If you're calling Claude Thinking models through a proxy platform, prioritize using /v1/chat/completions (OpenAI format) for the best compatibility.
The OpenAI-compatible endpoint on the APIYI apiyi.com platform has been adapted for Thinking models, automatically handling thinking block conversions.

Why the OpenAI Format Works Better for Claude Thinking Model API

This is the most counterintuitive part: using the "non-native" OpenAI format to call the Claude Thinking model actually has better compatibility. There are three reasons:

Reason 1: Content Format Flexibility Differs

The OpenAI format allows content to be either a plain string "hello" or a content block array [{"type":"text","text":"hello"}]. The native Anthropic format only accepts content block arrays—string format will directly cause an error.

When client code passes content as a string (which is the default behavior of the OpenAI SDK), if the proxy uses the OpenAI format channel, the client and upstream endpoint formats match, avoiding conversion issues. But if it goes through the Anthropic format channel, strings won't be accepted.

Reason 2: Automatic Stripping of Thinking Blocks

OpenAI-compatible mode automatically strips thinking blocks from Claude's response, returning only the final text. This means:

• Clients don't receive thinking blocks
• Thinking blocks don't need to be passed back in the next round of conversation
• There's no thinking block ordering issue

The native Anthropic format requires thinking blocks to be fully preserved in multi-turn conversations, and assistant messages must start with a thinking block. If the proxy doesn't handle this ordering requirement correctly, it will cause errors.

Reason 3: The thoughtSignature Passing Problem

As mentioned earlier, thinking blocks in the Anthropic format contain an encrypted signature (signature) that must be passed back exactly as received. The OpenAI format skips this entirely—it doesn't return signatures, and doesn't require passing them back.

🎯 Recommendation: When calling the Claude Thinking model through an API proxy, prioritize using the /v1/chat/completions format to avoid thinking block format compatibility issues.
APIYI's OpenAI-compatible endpoints at apiyi.com have been fully adapted for Thinking models.

Claude Thinking Model API Calling Solutions Comparison

Three Calling Solutions for Claude Thinking Model API

Claude Thinking Model API Model Name Differences

Different platforms use different naming conventions for Thinking models, which is a common source of confusion:

In the official Anthropic API, there's no claude-opus-4-6-thinking model name. The -thinking suffix is a naming convention used by proxy platforms, allowing users to directly enable thinking functionality through the model name without manually setting parameters.

Tip: If you use the claude-opus-4-6-thinking model name on APIYI at apiyi.com, the platform automatically adds the thinking: {"type": "adaptive"} parameter to your request. This means you can get thinking capabilities directly with the OpenAI SDK without modifying your code.

Common Pitfalls and Solutions for Claude Thinking Model API

Frequently Asked Questions

Summary

The key points about Claude Thinking model API compatibility issues:

1. Root cause is content format mismatch: Anthropic's native API strictly requires content to be a list, while OpenAI format allows strings—if an API proxy service uses /v1/messages but the client sends a string, it will throw Input should be a valid list
2. OpenAI format has better compatibility: Automatically strips thinking blocks, doesn't require passing back signature, content can be a string—the preferred choice for proxy scenarios
3. The -thinking suffix is a proxy convention, not an official model name: The official model name is claude-opus-4-6, thinking is enabled via parameters

When calling Claude Thinking models through an API proxy, the simplest solution is to consistently use the OpenAI-compatible format.

We recommend calling through APIYI at apiyi.com—the platform has already optimized format compatibility for Thinking models, offering free credits and a unified interface for multiple models.

📚 References

1. Claude API Extended Thinking Documentation: Complete API reference for thinking mode

   • Link: platform.claude.com/docs/en/build-with-claude/extended-thinking
   • Description: Includes detailed explanations of adaptive thinking, effort parameters, and content block formats

2. Claude API OpenAI SDK Compatibility Documentation: Official guide for calling Claude using OpenAI format

   • Link: platform.claude.com/docs/en/api/openai-sdk
   • Description: Includes compatibility limitations and unsupported features list

3. Claude API Error Code Reference: Explanation of all API error types

   • Link: platform.claude.com/docs/en/api/errors
   • Description: Includes specific troubleshooting methods for invalid_request_error

4. APIYI Documentation Center: Calling Claude Thinking models through OpenAI-compatible interface

   • Link: docs.apiyi.com
   • Description: Already adapted for Thinking models, automatically handles thinking blocks conversion

Author: APIYI Technical Team
Technical Discussion: Welcome to discuss in the comments, more resources available at APIYI docs.apiyi.com documentation center