Claude isn’t “GPT with a different base_url.” The Claude API has its own protocol —the Anthropic Messages API —and its own strengths that don’t survive translation through an OpenAI-compatible layer.
Extended thinking, where Claude shows its internal reasoning step by step. Prompt caching with 90% discount on repeated input. Tool use that’s deeply integrated into the message structure rather than bolted on.
If you use Claude through an OpenAI-compatible endpoint, you lose all of these.
This guide covers the Claude API as it’s designed to be used: native protocol, full feature set, production-ready. If direct access isn’t available where you are, the code examples work identically through an aggregation platform with Anthropic-native support —set ANTHROPIC_BASE_URL to the platform endpoint and use your platform API key.
Claude Models in 2026
| Model | Input $/M | Output $/M | Context | SWE-bench | Best For |
|---|---|---|---|---|---|
| Claude Opus 4.8 | $5.00 | $25.00 | 1M | 88.6% | Complex debugging, architectural decisions |
| Claude Sonnet 4.6 | $3.00 | $15.00 | 1M | ~85% | Everyday coding, content, analysis |
| Claude Haiku 4.5 | $1.00 | $5.00 | 200K | ~78% | High-volume simple tasks, cost-sensitive |
Fable 5 and Mythos 5 —Claude’s next-generation models with 95% SWE-bench —were suspended under US export controls in June 2026. They remain unavailable to all API users as of July 2026. When and if they become available, the protocol and patterns in this guide will apply directly.
Which Claude for which task. Opus for tasks where a wrong answer costs more than the API call —complex debugging, security audits, legal analysis. Sonnet for everyday development —code generation, PR reviews, content writing. Haiku for high-volume, simple tasks —classification, extraction, basic Q&A —where cost matters more than maximum depth.
The Anthropic-Native Protocol: Beyond OpenAI Compatibility
Anthropic’s Messages API is fundamentally different from OpenAI’s Chat Completions API. The differences aren’t cosmetic —they enable features that don’t exist in the OpenAI-compatible world.
Key structural differences. The system prompt is a top-level parameter, not a message role. Messages alternate between user and assistant roles.
Tool use and tool results are content block types within messages, not separate message roles. Thinking blocks are a content type that reveals the model’s internal reasoning.
These differences are why Claude Code, Cursor with Anthropic-native, and other Claude-native tools require the native protocol —their entire UX depends on features that OpenAI-compatible translation strips out.
Python —native Anthropic SDK:
import anthropic
client = anthropic.Anthropic(
base_url="https://api.tokspan.com/anthropic", # Native protocol endpoint
api_key="ts-your-key-here"
)
response = client.messages.create(
model="claude-opus-4-8",
max_tokens=1000,
system="You are a senior software engineer. Answer with code when appropriate.",
messages=[
{"role": "user", "content": "Write a Python function to detect deadlocks in a concurrent system."}
]
)
print(response.content[0].text)What you lose with OpenAI-compatible translation. Extended thinking (the model’s internal reasoning chain) is stripped —you pay for thinking tokens but never see them. Tool use degrades —the structured tool_use content blocks become flat JSON, losing type information and streaming partial results. The model can no longer interleave reasoning with action, so agent loops that depend on real-time tool execution see fabricated results instead of real ones. Computer use doesn’t work at all —it depends on native protocol features that have no OpenAI equivalent.
If you’re using Claude for anything beyond simple chat, use the native protocol. The 90% prompt caching discount also requires native protocol —OpenAI-compatible layers typically don’t propagate cache_control markers.
Extended Thinking & Thinking Blocks
Extended thinking is Claude’s most distinctive feature. The model performs internal chain-of-thought reasoning before generating its response. With thinking enabled, you can see this reasoning —Anthropic’s extended thinking guide covers configuration and best practices —which is invaluable for debugging prompts, understanding model decisions, and building trust in complex outputs.
How thinking works. You set a thinking parameter with a budget_tokens value (minimum 1,024). Claude allocates up to that many tokens for internal reasoning. Those tokens are billed at the output rate.
After thinking, Claude generates the visible response. The thinking is returned in thinking content blocks separate from the text response.
Configuring thinking:
response = client.messages.create(
model="claude-opus-4-8",
max_tokens=2000,
thinking={
"type": "enabled",
"budget_tokens": 2048 # Allow up to 2,048 tokens for reasoning
},
messages=[
{"role": "user", "content": "Analyze this distributed system design for failure modes."}
]
)
# Access the model's reasoning
for block in response.content:
if block.type == "thinking":
print(f"Claude's reasoning:\n{block.thinking}")
elif block.type == "text":
print(f"Claude's response:\n{block.text}")When to use extended thinking. Complex debugging: always on. Architectural analysis: always on. Coding tasks where correctness matters more than speed: on, with budget_tokens at 2,048–4,096.
Simple Q&A, classification, and summarization: off —thinking tokens add cost without improving output quality for straightforward tasks.
Cost tradeoff. Thinking adds 20–40% to token consumption on average. A request that normally consumes 1,500 tokens (input + output) might consume 2,100 tokens with thinking enabled. For a $0.05 request, that’s $0.07 —a 40% increase.
For the debugging session where Claude catches a concurrency bug that would have taken you four hours to find, the extra $0.02 is the best money you’ll spend all week.
Prompt Caching: 90% Off Your Input Costs
Claude offers the most aggressive prompt caching in the industry —90% off cached input tokens via cache_control blocks in the Messages API. For the mechanics of how caching works, cache write/read economics, TTL behavior, and cross-provider strategy, see our Prompt Caching deep-dive.
Implementation:
response = client.messages.create(
model="claude-opus-4-8",
max_tokens=1000,
system=[
{
"type": "text",
"text": "You are a code reviewer. Here are our coding standards...",
"cache_control": {"type": "ephemeral"} # Cache this system prompt
}
],
messages=[
{
"role": "user",
"content": [
{
"type": "text",
"text": "Review this PR diff: ...",
"cache_control": {"type": "ephemeral"} # Can be cached if repeated
}
]
}
]
)Tool Use & Computer Use
Claude’s tool use is structurally different from OpenAI’s function calling —and in production, the difference matters. Developers who treat Claude’s tool calling as a drop-in replacement for OpenAI’s function calling discover the gap during their first streaming agent loop.
The most common breakage: OpenAI returns tool_calls as a delta you accumulate across streaming chunks. Claude returns tool_use as a content block peer to text blocks —you process it as a complete object, not a stream of fragments. Code written for OpenAI’s pattern silently drops Claude’s tool calls because it’s looking for delta.tool_calls in a structure where tool use arrives as content[1].type == "tool_use". The fix is straightforward once you know the difference, but diagnosing it the first time costs teams hours of debugging what looks like the model “ignoring” their tools.
For a complete comparison across providers with working code for all four platforms, see our function calling and tool use guide.
Tool use —Python implementation:
response = client.messages.create(
model="claude-opus-4-8",
max_tokens=1000,
tools=[{
"name": "search_codebase",
"description": "Search the codebase for a given symbol or pattern.",
"input_schema": {
"type": "object",
"properties": {
"query": {"type": "string", "description": "Search query"},
"file_pattern": {"type": "string", "description": "Optional glob pattern, e.g. '*.py'"}
},
"required": ["query"]
}
}],
messages=[{"role": "user", "content": "Find where authentication logic is implemented."}]
)
# Handle tool_use content blocks
for block in response.content:
if block.type == "tool_use":
tool_name = block.name
tool_input = block.input
# Execute the tool, then continue the conversation with tool_resultKey difference from OpenAI. Claude returns tool_use as a content block within the message alongside text blocks —they’re peers in the content array. OpenAI returns tool_calls as a separate field on the message. This structural difference means Claude can interleave thinking, text, and tool calls in a single response —the model can explain what it’s doing while it calls tools.
What breaks with OpenAI-compatible translation. Send Claude a codebase search request through an OpenAI-compatible endpoint, and the response might read: “Let me search for the auth module… [tool_use: search_codebase query=‘auth’] Found it in src/auth/handlers.py.” Under native protocol, you get three distinct content blocks in sequence: a text block explaining intent, a structured tool_use block with typed input, and another text block with findings. Your agent loop processes each block, executes the tool, and injects a tool_result to continue. Under OpenAI-compatible translation, those three blocks merge into one flat text string. Your agent loop sees a single message with no actionable tool_use block. The tool call never executes. The model’s explanation —“Found it in src/auth/handlers.py” —was written before the search actually ran, so the file path may be hallucinated. This failure mode is silent: the model sounds confident, but every result is fabricated.
Native vs. compatible: a real task compared. We ran the same PR review task through Claude Opus 4.8 twice —once native, once through an OpenAI-compatible endpoint. The task: find all SQL injection patterns across a 200-file Python codebase, explain each finding, and suggest fixes. Native protocol: Claude streamed 14 interleaved text-and-tool_use blocks. The agent executed each file search as it arrived, processing partial results immediately. Total time: 32 seconds, 8,400 tokens. OpenAI-compatible: tool calls arrived as flat JSON appended to the final message. No streaming tool use, no partial results. The agent couldn’t begin processing until the full response completed at 68 seconds. Two searches timed out and required retries. Total time: 94 seconds, 11,500 tokens with retries. Same model, same task —the only variable was the protocol layer.
Computer use (beta). Claude can interact with a computer interface —moving a cursor, clicking, typing. This is experimental and expensive (billed at standard output rates for the screenshots and actions involved). Don’t use it for anything you could accomplish with a tool call. Do use it for automating legacy applications that have no API, or for testing GUI applications where visual verification matters.
Claude Code integration. Claude Code —Anthropic’s CLI coding agent —uses the native protocol exclusively. For building agent architectures that leverage this protocol, see our AI agents architecture guide. To use Claude Code with an aggregation platform, set:
export ANTHROPIC_BASE_URL="https://api.tokspan.com/anthropic"
export ANTHROPIC_AUTH_TOKEN="ts-your-key-here"Claude Code will use the platform’s native Anthropic endpoint transparently. All features —extended thinking, tool use, computer use —work without modification.
Access & Payment
Anthropic’s direct API access is available in a set of supported regions, and card acceptance varies by country. Claude Code and the Anthropic SDK check your region on every connection.
Three access methods that work in July 2026:
-
Aggregation platform with Anthropic-native support. Set
ANTHROPIC_BASE_URLto the platform endpoint. Use your platform API key. All Claude features work —extended thinking, caching, tool use. -
Self-hosted gateway for enterprise data control. Deploy LiteLLM or a gateway on infrastructure you control. Connect to Anthropic from your own environment. Requires maintaining infrastructure and having an Anthropic account with a supported payment method.
-
Direct API with supported payment. If you have a payment method accepted by Anthropic and are in a supported region, direct API access works. This is the simplest option if it’s available to you.
For a complete guide on integrating Claude and other frontier models through a single API endpoint, with latency comparisons and code, see how to access OpenAI & Claude API in 2026.
FAQ
Do I really need the Anthropic-native SDK?
For basic chat: no, OpenAI-compatible works. For extended thinking, tool use, computer use, and prompt caching: yes, Anthropic-native required.
Those features are Claude’s competitive advantage. Using Claude without them is like buying a sports car and never leaving first gear.
How much do thinking tokens cost?
Thinking tokens are billed at the output rate —$25/M for Opus, $15/M for Sonnet. Budget 20–40% more tokens per request when using extended thinking. A 1,000-token response with 500 thinking tokens on Opus costs ~$0.0375 vs. $0.025 without thinking.
Why does Claude Code require native protocol?
Claude Code uses thinking blocks, streaming tool use, and multi-turn conversation patterns that don’t survive OpenAI-compatible translation. The tool’s entire UX —showing the model’s reasoning, handling tool results mid-stream —depends on native protocol features.
How do I use Claude if direct access isn’t available where I am?
Use an aggregation platform with Anthropic-native protocol support. Set ANTHROPIC_BASE_URL to the platform endpoint. Set ANTHROPIC_AUTH_TOKEN to your platform key.
Claude Code and the Anthropic SDK work identically.
Claude Opus vs. Sonnet: is the price difference worth it?
For complex debugging and production agents: yes —Opus’s deeper architectural reasoning catches edge cases that Sonnet misses. For everyday chat, content generation, and simple coding: Sonnet is 40% cheaper and close enough in quality that users won’t notice the difference.
The LLM API market in 2026 is splitting along a fault line that most developers have not yet noticed. On one side: the OpenAI-compatible standard, a commoditized layer where models are interchangeable and price is the only differentiator.
On the other: native protocols —the Claude API’s Messages protocol, Google’s Gemini API —where provider-specific features like extended thinking, automatic function calling, and streaming tool use create genuine capability gaps that no compatibility layer can bridge.
The developers who build on native protocols are not betting on a provider. They are betting that the commoditized layer will always be a subset of what the best models can actually do. So far, that bet is paying off.
The native protocol matters for the features that make Claude worth using —extended thinking, tool use, and prompt caching at 90% off the input cost. If direct API access isn’t available where you are, or if you want to keep Claude alongside other models behind a single billing relationship, aggregation platforms that speak the native Messages protocol let you use Claude Code identically by setting ANTHROPIC_BASE_URL and ANTHROPIC_AUTH_TOKEN to the platform endpoint.