Kimi K3 is now availableExplore Kimi K3
Claude Opus 5 through EvoLink unified API routing across production workloads
Tutorial

How to Use Claude Opus 5 API with EvoLink: Production Setup and Migration

Jessie
Jessie
COO
July 24, 2026
Updated on July 25, 2026
16 min read
Claude Opus 5 is available on EvoLink under the model ID claude-opus-5. Create an EvoLink API key, then send a Claude Messages request to the direct EvoLink Messages endpoint. The route uses the existing EvoLink Claude Messages API contract, so teams already using a Claude route can migrate without adding a second provider integration.
Availability does not remove the need for production validation. Keep the model ID in configuration, verify response.model, usage, billing, streaming, and tool behavior with your own account, then promote traffic by workload. This separates “the route is live” from the stronger claim that every application path has passed its rollout gates.
This guide covers more than a first call. It shows how thinking, effort, and max_tokens interact, what changes when you migrate from Opus 4.8, how to handle refusals and transport failures, and where Opus 5 belongs in a cost-aware production routing policy.

Claude Opus 5 API Quick Facts

Anthropic released Claude Opus 5 on July 24, 2026 for complex agentic coding and enterprise work. The official Opus 5 documentation defines the core API contract.
FieldVerified valueWhy it matters
Anthropic model IDclaude-opus-5Use the exact identifier supported by your API provider
Context window1M tokensLarge repositories and document sets can fit in one model context, but sending all available context is rarely the cheapest design
Maximum output128K tokensmax_tokens still limits thinking plus visible output
ThinkingOn by defaultA request that omitted thinking on Opus 4.8 changes behavior after migration
Effort levelslow, medium, high, xhigh, maxEffort is the main control for intelligence, latency, and token use
Official base price$5 per million input tokens and $25 per million output tokensThe same base token price as Opus 4.8
EvoLink Messages endpointDirect Messages endpointRecommended EvoLink endpoint for long-running Claude requests
EvoLink route statusAvailableCall claude-opus-5 through the EvoLink Messages API and validate production behavior with your own workload

The practical takeaway is simple: Claude Opus 5 is callable through EvoLink now, while parameter compatibility, billing, and operational behavior should still be validated with a real account-level request before full production rollout.

Why Use Claude Opus 5 Through a Unified API

Calling a new model is easy. Keeping an application flexible after the launch week is harder.

A direct integration can be the right choice when a team needs every Anthropic-native feature immediately and intends to use only Claude. A unified gateway becomes more useful when the application must choose among models, contain cost, preserve a fallback, or switch providers without spreading model-specific code through the product.

EvoLink's useful role is therefore not to make every request an Opus 5 request. It is to keep model selection at the routing layer:

Application task
  -> routing policy
  -> selected model
  -> Messages API request
  -> actual-model and usage verification
  -> quality and cost record
  -> promote, retry, fall back, or roll back

This architecture gives a team four concrete advantages:

  1. One integration surface. The application sends Claude-style messages through one documented endpoint.
  2. Configurable model selection. Business logic describes the job, such as routine_coding or architecture_escalation, while configuration chooses the current model.
  3. Measurable fallback. A retry or model change becomes an explicit operational event rather than an invisible benchmark contaminant.
  4. Migration flexibility. The next model change is primarily a routing and evaluation decision, not a rewrite across prompts, product code, and customer settings.
Use the Claude model collection on EvoLink for family-level selection. For the exact route, current model details, and pricing surface, use the Claude Opus 5 model page.

Make the First Claude Opus 5 Call

1. Confirm account access before changing production code

The EvoLink route is available. Before changing production traffic, confirm that your account can call it and that the complete application path behaves as expected:

  • claude-opus-5 is listed for your EvoLink account.
  • A minimal request returns HTTP 200.
  • response.model identifies the expected model.
  • The usage record and charged amount match the current EvoLink pricing surface.
  • Required features such as streaming or tools work on the same route.

If your account does not expose the route or a required feature fails, keep the existing model as the fallback and resolve the account or compatibility issue before rollout.

2. Store the API key on the server

Create an EvoLink API key and load it from a server-side environment variable:

export EVOLINK_API_KEY="your_api_key_here"
Do not expose the key in browser JavaScript, a Client Component, a public repository, or a NEXT_PUBLIC_* variable.

3. Send a minimal request

The minimal request follows EvoLink's Claude Messages API shape:

curl --request POST \
  --url https://direct.evolink.ai/v1/messages \
  --header "Authorization: Bearer $EVOLINK_API_KEY" \
  --header "Content-Type: application/json" \
  --data '{
    "model": "claude-opus-5",
    "max_tokens": 4096,
    "messages": [
      {
        "role": "user",
        "content": "Review this service architecture and identify the three highest-risk failure points."
      }
    ]
  }'

Start without optional parameters. A small payload isolates authentication, route availability, and the core request contract before effort, tools, streaming, or caching add more failure modes.

4. Verify the response, not only the status code

A successful HTTP response proves that the endpoint returned something. It does not by itself prove that the intended model served the request or that the result belongs in an Opus 5 evaluation.

Record at least:

  • response.model
  • response.stop_reason
  • input and output usage
  • request latency
  • request ID when available
  • application task ID
  • retry and fallback count

The following server-side TypeScript example distinguishes non-retryable client errors from retryable capacity failures and verifies the returned model without using untyped values:

type Usage = {
  input_tokens: number
  output_tokens: number
  cache_creation_input_tokens?: number
  cache_read_input_tokens?: number
}

type TextBlock = {
  type: 'text'
  text: string
}

type MessageResponse = {
  id: string
  model: string
  stop_reason: string | null
  content: TextBlock[]
  usage: Usage
}

const RETRYABLE_STATUS = new Set([429, 500, 503, 524])

function isMessageResponse(value: unknown): value is MessageResponse {
  if (typeof value !== 'object' || value === null) return false

  const record = value as Record<string, unknown>
  return (
    typeof record.id === 'string' &&
    typeof record.model === 'string' &&
    Array.isArray(record.content) &&
    typeof record.usage === 'object' &&
    record.usage !== null
  )
}

async function callClaudeOpus5(prompt: string): Promise<MessageResponse> {
  const credential = process.env.EVOLINK_API_KEY
  if (!credential) throw new Error('EVOLINK_API_KEY is not configured')

  for (let attempt = 0; attempt < 3; attempt += 1) {
    const response = await fetch('https://direct.evolink.ai/v1/messages', {
      method: 'POST',
      headers: {
        Authorization: `Bearer ${credential}`,
        'Content-Type': 'application/json',
      },
      body: JSON.stringify({
        model: 'claude-opus-5',
        max_tokens: 4096,
        messages: [{ role: 'user', content: prompt }],
      }),
      signal: AbortSignal.timeout(120_000),
    })

    if (response.ok) {
      const payload: unknown = await response.json()
      if (!isMessageResponse(payload)) {
        throw new Error('Unexpected Claude Messages API response')
      }

      if (payload.model !== 'claude-opus-5') {
        throw new Error(`Unexpected response model: ${payload.model}`)
      }

      return payload
    }

    if (!RETRYABLE_STATUS.has(response.status) || attempt === 2) {
      throw new Error(`Claude request failed with HTTP ${response.status}`)
    }

    const backoffMs = 1_000 * 2 ** attempt + Math.floor(Math.random() * 250)
    await new Promise((resolve) => setTimeout(resolve, backoffMs))
  }

  throw new Error('Claude request exhausted its retry policy')
}

This is a reference pattern, not a substitute for account-level testing. In a high-volume service, add structured logs, request correlation, concurrency controls, and a fallback chosen by your routing policy.

How Thinking, Effort, and max_tokens Interact

Opus 5 changes the behavior of an otherwise familiar request. Thinking is on by default, and effort controls how much compute the model can apply.

Claude Opus 5 thinking and effort workflow showing progressively deeper compute lanes and a verified output
Claude Opus 5 thinking and effort workflow showing progressively deeper compute lanes and a verified output
Thinking configurationEffortValid on Anthropic's Opus 5 contract?Production implication
Default or adaptivelowYesLowest-cost evaluation lane
Default or adaptivemediumYesUseful cost and latency baseline
Default or adaptivehighYesAPI default and general intelligence-sensitive route
Default or adaptivexhighYesRecommended starting point for difficult coding and agentic work
Default or adaptivemaxYesCapability-critical tasks where extra token use is acceptable
Disabledlow, medium, or highYesRequires extra output and tool-call validation
Disabledxhigh or maxNoReturns a 400 error
Anthropic recommends starting with xhigh for coding and agentic work, using high for other intelligence-sensitive workloads, and testing low or medium wherever evaluation quality holds. At xhigh or max, Anthropic suggests starting with at least 64K max_tokens so the model has room for thinking, subagents, and tool calls.

Three details prevent common integration mistakes:

  1. max_tokens covers thinking and visible output. A ceiling inherited from a no-thinking Opus 4.8 route may truncate an Opus 5 task earlier than expected.
  2. Effort does not reliably control visible answer length. Prompt explicitly for a concise response or target deliverable length.
  3. Provider support can differ. Only send output_config.effort through EvoLink after its current route documentation or a real test confirms the field is accepted.

Keep thinking enabled where practical. Anthropic warns that disabling thinking can occasionally cause a tool call to appear as ordinary text or expose internal XML-like tags in the visible response.

Migrate from Claude Opus 4.8 Without Carrying Old Assumptions

The model ID change is the easy part:

- "model": "claude-opus-4-8"
+ "model": "claude-opus-5"
The official migration guide identifies the behavior changes that need real application review. For the same-family replacement decision, use the Claude Opus 5 vs Claude Opus 4.8 comparison; this guide stays focused on implementing the migration.

Request migration

  • Requests without a thinking field now run with thinking on.
  • Revisit max_tokens for workflows that previously ran without thinking.
  • Do not combine disabled thinking with xhigh or max.
  • Confirm no temperature, top_p, or top_k values linger from pre-4.8 configs — Opus 4.8 already rejects them, and Opus 5 keeps the same behavior.
  • Test the new 512-token prompt-cache minimum if repeated prompts were previously too short to cache.
  • Handle stop_reason: "refusal" as an application outcome.

Prompt migration

Opus 5 is more likely to verify its own work, narrate progress, and delegate to subagents. Prompts tuned for an earlier model can accidentally multiply those behaviors.

Update prompts in four ways:

  • Specify the intended answer or document length.
  • Remove unconditional instructions to double-check or add a final verifier.
  • Constrain scope for narrow tasks.
  • Cap subagent delegation unless independent parallel work justifies it.
Anthropic's Opus 5 prompting guide recommends giving the complete task specification up front for difficult coding work and allowing the model to run, while avoiding redundant verification scaffolding.

Harness migration

Replay representative tasks through the whole application, not only the raw model call. Verify:

  • tool selection and arguments
  • streaming parser behavior
  • timeout and retry limits
  • refusal handling
  • actual returned model
  • token and cache usage
  • output length
  • task acceptance by the real reviewer or downstream check

Promote Opus 5 by workload. A model can improve difficult architecture tasks while adding unnecessary cost to routine extraction.

Handle Tool Use, Streaming, Refusals, and Transport Failures

The EvoLink Messages API exposes streaming, tools, tool choice, usage, and stop reasons. A production loop should branch on the response rather than assume every 200 response contains a final answer.

Send message
  -> end_turn: return the answer
  -> tool_use: execute the allowed tool and continue
  -> refusal: apply the refusal and fallback policy
  -> max_tokens: mark the result incomplete
  -> transport error: retry only when the error is retryable

Set a maximum tool-loop count, validate every tool argument, and preserve the trace needed to explain a failed task. Never execute a model-produced tool call without application-level authorization and schema validation.

Treat failures by class:

OutcomeRecommended action
400 invalid requestFix model, thinking, effort, sampling, or schema fields; do not blindly retry
401 authenticationCorrect server-side credentials
402 billingRestore credits or change the product response
404 model not foundRecheck the EvoLink model enum and account access
429 rate limitApply bounded exponential backoff with jitter
503 overloadedRetry within a strict budget or move to an approved fallback
524 timeoutUse the direct endpoint, set a long-task timeout, and avoid duplicate untracked work
stop_reason: "refusal"Record the outcome and apply the workload's fallback or user-message policy

A refusal is not the same as a failed HTTP request. Anthropic documents it as a normal response outcome for Opus 5. Automatic fallback may be available on Anthropic's native API, but confirm the EvoLink equivalent before putting provider-specific fields into a gateway request.

Measure Cost per Successful Task

Claude Opus 5 keeps the same official base token price as Opus 4.8, but list price does not tell a production team which route is cheaper.

Use this decision metric:

successful-task cost =
  input token cost
  + output token cost
  + retry cost
  + fallback cost
  + tool execution cost
  + human review or repair cost
Run the same privacy-safe evaluation set at medium, high, and xhigh. Record whether the task passed, not merely how fluent the output sounded. A higher-effort request can be economical if it prevents retries and manual repair. It can also be wasteful when the task would pass at medium.

The evaluation table should include:

MetricWhy it belongs
Accepted-task rateMeasures whether the result was usable
Total input and output tokensCaptures the full model bill
Cache reads and writesShows whether repeated context is being reused
Tool calls and failuresExposes agent-loop overhead
Retries and fallbacksPrevents hidden multi-request cost
End-to-end latencySeparates interactive and background fit
Human review timeCaptures cleanup that token pricing misses

Do not publish a universal effort recommendation from a single prompt. Choose the lowest-effort lane that meets the quality threshold for each workload, then reserve escalation for tasks where failure is expensive.

Route Sonnet, Opus, and Fable by Workload

Anthropic positions Opus 5 as the starting choice for complex agentic coding and enterprise work, while Fable 5 remains the highest-capability generally released Claude model. Use the Opus 5 vs Fable 5 decision guide to turn that hierarchy into workload rules.
Production routing and fallback workflow for Claude Opus 5 and other model lanes on EvoLink
Production routing and fallback workflow for Claude Opus 5 and other model lanes on EvoLink
WorkloadSuggested starting routeEscalation signal
Classification, extraction, and short rewritesLower-cost modelSchema or quality failures exceed the accepted threshold
Everyday coding and production assistant workClaude Sonnet 5Repeated debugging failure, wide repository scope, or higher decision risk
Complex debugging, architecture, and long agent loopsClaude Opus 5The task remains unresolved and the expected value justifies the premium
Highest-difficulty autonomous or knowledge workClaude Fable 5Use only where the measured task value supports the higher price

Store the routing decision in configuration:

type Workload =
  | 'routine_text'
  | 'everyday_coding'
  | 'complex_agent'
  | 'frontier_escalation'

const modelByWorkload: Record<Workload, string> = {
  routine_text: 'configured-low-cost-model',
  everyday_coding: 'claude-sonnet-5',
  complex_agent: 'claude-opus-5',
  frontier_escalation: 'claude-fable-5',
}

The application should log both the requested and returned model. If a fallback occurs, exclude that trace from a clean Opus 5 benchmark or label it separately.

This is where a unified API earns its place. The value is not access to one new model. The value is the ability to change the production decision without rewriting the application around every release. If the choice crosses model providers, use the Claude Opus 5 vs GPT-5.6 comparison before changing the routing policy.

Production Readiness Checklist

Before moving real traffic to Opus 5:

  • claude-opus-5 is listed for the EvoLink account.
  • A minimal request returns the expected response.model.
  • Usage and billing match the documented route.
  • Streaming is verified if the product depends on it.
  • Every required tool path has a valid request and result trace.
  • The application distinguishes refusal from HTTP failure.
  • Retryable and non-retryable errors follow different policies.
  • A known fallback route exists and has been exercised.
  • Representative tasks have been replayed at multiple effort levels.
  • Promotion thresholds use accepted-task rate, latency, and successful-task cost.
  • Model IDs live in configuration rather than business logic.
  • Rollback conditions are explicit.

FAQ

What is the Claude Opus 5 API model ID?

The EvoLink request model ID is claude-opus-5. Keep it in configuration and verify the returned model when evaluating production traffic.
Yes. Use claude-opus-5 with the EvoLink Claude Messages API. See the Claude Opus 5 model page for the current product and pricing surface.
Use the direct EvoLink Messages endpoint. EvoLink recommends the direct base URL for long-running requests and timeout-sensitive work.

Is thinking enabled by default on Claude Opus 5?

Yes. On Opus 5, omitting the thinking field leaves adaptive thinking on. This differs from Opus 4.8 requests that ran without thinking when the field was absent.

Which effort level should I choose?

Start with xhigh for difficult coding and agentic work, high for other intelligence-sensitive tasks, and evaluate medium or low as cost and latency controls. Use max only when the task value justifies unconstrained token spending.

How do I migrate from Claude Opus 4.8?

Update the model ID, then retest thinking defaults, max_tokens, sampling parameters, prompt length, verification instructions, subagent behavior, refusal handling, usage, and cost. Treat the migration as a workflow evaluation rather than a string replacement.

How much does Claude Opus 5 cost?

Anthropic's official base price is $5 per million input tokens and $25 per million output tokens, unchanged from Opus 4.8. Check the current EvoLink pricing surface for the gateway route, and compare models by successful-task cost rather than token price alone.

Sources

Ready to Reduce Your AI Costs by 89%?

Start using EvoLink today and experience the power of intelligent API routing.