OpenAI Client with Anthropic Upstream

AISIX lets an application keep the OpenAI Chat Completions request shape while the gateway calls an Anthropic upstream model. Use this pattern when application code is already built around an OpenAI-compatible SDK, but the platform team wants to route that traffic to Claude.

AISIX resolves the model alias, translates the request to Anthropic Messages, calls Anthropic with the stored provider credential, and translates the response back into an OpenAI-compatible chat completion.

Prerequisites

Before starting, prepare the following:

• A running AISIX gateway that your application can reach.
• An Anthropic-backed model alias that accepts OpenAI-compatible Chat Completions requests.
• A caller API key allowed to use that model alias.
• Node.js 20 LTS or newer with npm for the SDK example, or curl for the HTTP example.

If you have not configured the model alias and caller API key, follow Anthropic for either AISIX Cloud or the open-source AISIX gateway.

Request Flow

The application keeps the OpenAI-compatible client contract. Provider selection and protocol translation stay in the gateway.

The application sends the model alias and caller API key to AISIX. The gateway resolves the upstream model, supplies the stored Anthropic credential, and translates both sides of the exchange. The application continues to send and receive OpenAI-compatible data.

Call the Alias

Export the caller API key and model alias used by both request examples:

export AISIX_API_KEY="YOUR_CALLER_API_KEY"
export AISIX_MODEL="claude-sonnet-prod"

OpenAI SDK

Install the OpenAI SDK:

npm install openai

Set the OpenAI-compatible base URL. The OpenAI SDK requires the /v1 path:

# The local quickstarts use http://127.0.0.1:3000/v1
export AISIX_BASE_URL="YOUR_AISIX_GATEWAY_URL/v1"

Create a minimal Chat Completions client:

anthropic-via-openai-sdk.mjs

import OpenAI from "openai";

const client = new OpenAI({
  apiKey: process.env.AISIX_API_KEY,
  baseURL: process.env.AISIX_BASE_URL,
});

const completion = await client.chat.completions.create({
  model: process.env.AISIX_MODEL,
  messages: [{ role: "user", content: "Say hello from AISIX." }],
});

console.log(completion.choices[0]?.message.content);
console.log(completion.usage);

Run the example from the shell where the AISIX values are set:

node anthropic-via-openai-sdk.mjs

HTTP

To inspect the response without an SDK, export the gateway origin and send the same request with curl:

# AISIX_PROXY has no trailing slash or endpoint path
# The local quickstarts use http://127.0.0.1:3000
export AISIX_PROXY="YOUR_AISIX_GATEWAY_URL"

Send the request:

curl -sS -X POST "$AISIX_PROXY/v1/chat/completions" \
  -H "Authorization: Bearer $AISIX_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "'"$AISIX_MODEL"'",
    "messages": [{"role":"user","content":"Say hello from AISIX."}]
  }'

Both examples return the OpenAI-compatible Chat Completions shape. The caller does not receive Anthropic-shaped content blocks:

{
  "object": "chat.completion",
  "model": "claude-sonnet-prod",
  "choices": [
    {
      "message": {
        "role": "assistant",
        "content": "Hello from AISIX."
      },
      "finish_reason": "stop"
    }
  ],
  "usage": {
    "prompt_tokens": 9,
    "completion_tokens": 5,
    "total_tokens": 14
  }
}

Translation Behavior

The translation preserves the parts of the OpenAI-compatible contract that common chat applications depend on:

Behavior	What AISIX does
Model and authentication	Resolves the model alias to the configured Anthropic model, authenticates the caller, and uses the stored provider credential for the upstream request.
Messages and tools	Maps leading system messages, user and assistant messages, function tools, tool calls, and tool results to Anthropic Messages structures. Developer messages join the top-level system field wherever they appear in the conversation.
Responses	Converts Anthropic text and tool-use blocks, stop reasons, token usage, and streaming events back into OpenAI-compatible fields.
Output limit	Supplies max_tokens: 4096 when the OpenAI-compatible request omits an output limit, because Anthropic requires one.
Structured output	Sends a response_format as Anthropic's native output_config.format on Claude 4.5 and later, and as a forced synthetic tool on every other model. See Structured Output.
Reasoning effort	Sends reasoning_effort as output_config.effort, Anthropic's current depth control. minimal maps to low, Anthropic's floor, and none becomes thinking: {"type": "disabled"} instead, because Anthropic has no none tier. AISIX adds no thinking block in the other cases: the request asked for a depth, not a thinking mode, and current Anthropic models apply their own. A reasoning_effort value outside that set is dropped entirely: it corresponds to no known Anthropic tier, and the original field cannot be forwarded in its place either, because /v1/messages rejects unknown top-level fields. An output_config or thinking the request supplies itself is left as written and takes precedence.

caution

When an OpenAI Chat Completions message uses typed content parts, the Anthropic translation preserves text parts but drops non-text parts such as images and audio. Use the Anthropic-style /v1/messages route when image or document content must reach an Anthropic upstream.

For a complete tool loop, see Tool Calling. AISIX can also add Anthropic prompt-cache markers to eligible Chat Completions requests; see Anthropic Prompt Caching.

Use the Anthropic-style /v1/messages route when the application must keep the Anthropic request and response shape, especially for provider-specific content or thinking blocks. See Anthropic-Style Messages API for the native client contract and its compatibility boundaries.

Structured Output

A response_format on the Chat Completions request reaches the model. The same translation handles the response_format the Responses bridge builds from text.format, and the one the Anthropic Messages bridge builds from output_config.format.

Which shape goes on the wire depends on the upstream model:

• Claude 4.5 and later take Anthropic's own control: the schema lands in output_config.format, merged beside whatever else that carrier already holds, such as an effort translated from reasoning_effort. A format the request supplies natively is the more specific statement of the same setting and wins. No beta header is sent; the current API takes the field without one.
• Every other model — older Claude families, and the non-Claude models served behind Anthropic-compatible endpoints — takes the synthetic tool route, which needs no capability beyond tool calling.

AISIX holds no model capability map, so it reads the family version off the upstream model name. Both of Anthropic's orderings are recognized (claude-3-5-haiku-... and claude-sonnet-4-5-...), and the trailing eight-digit release date is read as a date rather than a minor version: claude-sonnet-4-20250514 is 4.0, while claude-sonnet-4-5-20250929 is 4.5. The claude-sonnet-4-5@20250929 spelling is recognized too.

{"type": "json_object"} and {"type": "text"} name no schema, and Anthropic's JSON controls are schema-driven on both routes, so neither puts anything on the Anthropic body. response_format itself never reaches that body either way: /v1/messages rejects unknown top-level fields.

The Synthetic Tool Route

Where the model has no native control, the schema rides a synthetic tool named json_tool_call whose input is the answer. It is appended to the tools the caller sent and forced through tool_choice, which is what makes the reply JSON rather than a suggestion the model may ignore. Two things outrank the forcing, each leaving the synthetic tool on offer under the model's own auto:

• A tool_choice the request stated — any value, auto included. auto is not an absence of intent: it is the client saying the model decides, and a client running an agent loop sends it beside its own tools on every turn, so forcing the synthetic tool there would mean those tools could never be called for as long as response_format is set. An explicit JSON null counts as unstated, because it is how SDKs spell an absent optional.
• Extended thinking, which Anthropic rejects outright beside a forced tool choice.

The reply is translated back before it reaches the caller. When the synthetic call is the only one, its input replaces the message content, with no tool_calls and finish_reason: stop — a client that never offered a tool must not be told the model stopped to call one. When the model also called tools the caller really offered, the caller did ask for tool calls and is parsing them itself, so those calls and their finish reason survive and the JSON is appended to whatever text came with them.

A streaming request on this route is served as a simulated stream. A tool call cannot be streamed before it is complete, so AISIX makes one non-streaming upstream call and renders the result as ordinary role, content, finish, and usage chunks; downstream encoders and usage reporting see a normal stream. The cost is first-byte latency — the client waits for the whole completion instead of the first token — and it applies only to a request that asks for a schema on a model with no native control. That leg is measured against the model's end-to-end timeout rather than its stream_timeout, so a chunk-gap deadline shorter than the request deadline does not cut it short.

How AISIX Adapts the Schema

Anthropic compiles the schema into a decoding grammar and returns an error for any keyword outside its documented subset, so a schema that worked against an OpenAI upstream would fail outright if forwarded untouched. AISIX adapts it instead, on both routes:

• Sealed, not closed. Every object in the schema gets additionalProperties: false, which Anthropic requires. required is left exactly as written: Anthropic treats it as an ordinary JSON Schema keyword, so a property left out of it stays optional and merely sorts after the required ones. Promoting every declared property into required, the way OpenAI strict mode does, would make an optional field mandatory on this provider and nowhere else.
• Narrowed to the supported subset. minimum, maximum, exclusiveMinimum, exclusiveMaximum, multipleOf, minLength, maxLength, maxItems, uniqueItems, and a minItems other than 0 or 1 are removed and restated in that property's description — "full name (maxLength: 20)" — so the constraint still reaches the model as a sentence even though the decoder no longer enforces it.
• oneOf becomes anyOf. Anthropic documents anyOf and not oneOf, and for constraining output the difference between matching one branch and matching at least one does not bind, since a document the model produced matches whichever branch it followed. Dropping the keyword would take the alternatives with it.
• Internal $ref, $defs, and definitions are supported by Anthropic and are kept. A recursive or external $ref is left exactly as it came in, so the provider's own rejection stands rather than a silently mangled schema.

Token Usage

Anthropic and OpenAI count prompt-cache tokens differently, so AISIX converts the counts instead of passing them through. Anthropic reports input_tokens as the non-cached input, with cache_creation_input_tokens and cache_read_input_tokens as separate counters beside it. OpenAI accounting has one prompt_tokens that already includes the cached part, named under prompt_tokens_details.cached_tokens. OpenAI has no cache-write concept at all, so AISIX folds the write into prompt_tokens — it is billed input — and reports it beside the hit.

An upstream response reporting:

{
  "usage": {
    "input_tokens": 40,
    "output_tokens": 10,
    "cache_creation_input_tokens": 30,
    "cache_read_input_tokens": 70
  }
}

reaches an OpenAI-compatible caller as:

{
  "usage": {
    "prompt_tokens": 140,
    "completion_tokens": 10,
    "total_tokens": 150,
    "prompt_tokens_details": {
      "cached_tokens": 70,
      "cache_creation_tokens": 30
    }
  }
}

The rules a caller can rely on:

• prompt_tokens is the full input the model read, cache reads and cache writes included.
• total_tokens is prompt_tokens + completion_tokens.
• cached_tokens is a subset of prompt_tokens, and counts only cache reads.
• cache_creation_tokens is the cache write, also a subset of prompt_tokens. It is billed input but is not a cache hit, so it is reported separately rather than inside cached_tokens. OpenAI has no cache-write concept, so this field appears only when the upstream reported one — which matters because a provider typically bills a write above the plain input rate. On the first turn of a cached conversation, a write with no read, it is the only signal that a cache was involved at all.

The same conversion applies to streaming responses and to the Responses API over an Anthropic upstream.

Logs, metrics, and spend reporting are not converted: they keep Anthropic's own counters, so a call costs the same whichever protocol addressed it. See Anthropic Prompt Caching for the recorded view.

Next Steps

You have now routed an OpenAI-compatible client to an Anthropic upstream. See OpenAI-Compatible API for caller-facing route behavior. Use Anthropic Messages when you want the Anthropic request and response shape end to end, or review Provider Compatibility for endpoint and provider support boundaries.