Anthropic models

Connect an Anthropic model to use it through POST /v1/responses or product Chat. The gateway translates the request to Anthropic Messages and translates the result back to Responses. Chat continues to use Responses. The client API and the model's backend protocol are separate choices.

This integration covers ordinary generation, client functions and gateway-executed tools. It does not expose a Messages endpoint or Anthropic-hosted tools. An Anthropic connector cannot serve the gateway's native Chat Completions, embeddings, rerank or transcription endpoints, or act as the current safeguard judge.

Connect a model

1. In the portal, open the external-model connection form and select Anthropic.
2. Set Provider model ID to one of the supported IDs below. Choose a public model ID for clients to use.
3. Enter the upstream Anthropic API key. The connector type is Chat. No base URL or API-version setting is needed.
4. Share the connector with the intended tenant and grant the caller's platform API key permission to invoke it.

The gateway calls https://api.anthropic.com with the connector's key in x-api-key. Clients continue to send their platform key in Authorization: Bearer …; that key is never used as the upstream Anthropic credential. Model aliases use the same target authorization and provider selection as direct model IDs.

Provider model ID	Default output limit when the effective Responses request omits it
claude-opus-5-5	128,000 tokens
claude-sonnet-5-5	128,000 tokens
claude-haiku-5-5	128,000 tokens
claude-fable-5-1	128,000 tokens

These standard limits were checked against Anthropic's Models API on 21 October 2026. Other Anthropic model IDs are rejected until their capabilities are supported. An explicit caller or preset output limit takes precedence; the gateway does not silently clamp it. Anthropic still validates its allowed values. See Anthropic model metadata.

Make a request

curl -sS "https://api.<your-domain>/v1/responses" \
  -H "Authorization: Bearer $CM_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "YOUR_ANTHROPIC_PUBLIC_MODEL_ID",
    "input": "Explain how rain forms in two sentences.",
    "max_output_tokens": 2048,
    "store": false
  }'

Set stream:true for Responses SSE events. The backend connection streams in either case; the gateway owns client-facing JSON or SSE delivery, cancellation and the single model/tool loop.

Supported translation

Responses input	Anthropic behavior
Ordered text and instructions	Preserve text and order in the supported message/system representation.
Image URLs and data URLs	Forward supported sources without fetching or uploading. Only detail auto is supported.
PDF URLs	Forward as PDF sources. The URL's bytes must stay stable for exact replay.
Inline PDF data	Require store:false; conversation storage does not retain inline file bytes.
Function declarations/results	Preserve names, arguments, call IDs, results and execution ownership.
tool_choice:auto or none	Translate to the corresponding native choice.
Required or named tool choice	Support Haiku 5.5; reject on the other selected models without downgrading to auto. See stored-tool qualification limits.
parallel_tool_calls:false	Request serial tool use. Returned calls still obey gateway concurrency limits.
Structured JSON Schema	Forward constraints unchanged. Anthropic enforces strict output whether strict is omitted or true. Reject strict:false and nonempty format descriptions.
Effort low, medium, high, xhigh, max	Map to the same native effort name.
Effort none	Disable thinking on Haiku; reject on other selected models. minimal has no equivalent.
Reasoning summary auto	Request summarized thinking. Omission keeps the provider default.
Explicit sampling settings	Forward supported settings; Anthropic validates them for the selected model.

In stateless requests, leading system/developer messages join the top-level system prompt after the gateway's and caller's instructions. Later system/developer messages stay in order as plain system messages, which require no beta header on the supported models. The scoped system messages and tool updates used by stored history have separate beta requirements, described below. For ordinary conversation history, a later system/developer message or consecutive group of them must follow a user turn and either precede an assistant turn or end the input. Anthropic rejects other placements; the gateway preserves the supplied order. See Anthropic's placement rules.

Provider file IDs, unsupported content blocks, provider-hosted tools and controls without a faithful mapping are rejected. Effort mappings do not promise identical behavior across providers. A provider default may return a signature without readable thinking. Unsupported schemas remain provider errors; the gateway does not remove constraints. A preset's locked settings and input restrictions still apply. Presets using an Anthropic generator can use an independently configured, supported safeguard judge.

Tools and continuation

A Responses request can contain client functions, gateway MCP tools, or both. Each newly generated call has an execution owner. Replaying a completed call does not grant permission or execute it again.

• For gateway calls, the gateway runs its existing discovery, authorization, budget and concurrency checks. It sends the results back to Anthropic and continues the same request. A known executor failure is sent as a native error result; arbitrary result text is not interpreted as an error flag.
• For client functions, the gateway returns function_call items. Submit their results in the next request using the original call_id and the complete replay history.
• For mixed turns, the gateway completes its calls and returns the unresolved client calls. Preserve assistant call order; completed gateway results precede the newly supplied client results and text on native replay.

Request-supplied MCP declarations also request serial model tool use under the gateway's existing policy. Registered gateway functions and preset tools can use other supported call patterns. The gateway still handles multiple returned calls correctly; asking the model for parallel calls and executing returned calls are separate controls.

Keep returned item IDs as well as call IDs. New Anthropic item IDs retain the native message and block grouping. Flattened call/result pairs alone cannot distinguish parallel calls from sequential model turns. Missing or ambiguous grouping is an explicit compatibility limitation.

A failed gateway tool replays as failed only when its function_call_output keeps the returned id. The gateway does not infer failure from result text. Ordinary client-supplied Responses results have no separate error flag.

Signed and redacted thinking uses the existing Responses encrypted_content field as an opaque replay carrier. Preserve the entire returned reasoning item, including its ID. Do not edit or interpret the carrier. For streaming, replay completed items from response.output_item.done, including their final signatures.

History ownership

With store:false, the caller owns history. The gateway creates no conversation or hidden session. Client instructions and history remain faithful to the supplied request. Gateway-added context and tools are fixed during one request's tool loop. Across stateless requests, preserved thinking requires that context to remain unchanged or reproducible. Provider validation remains authoritative; the gateway does not remove thinking, retry, or repair edited history.

With storage enabled, the existing conversation defaults, authorization and model-ID replay filtering apply. The gateway privately retains the server context and effective tool definitions used for each eligible request. Anthropic encodes later updates with scoped system messages and tool updates; other backends keep their existing wire behavior. Private context is excluded from public conversation-item retrieval and GenAI capture. It contains no connector or tool credentials, and callers cannot supply it through the conversation API.

Private stored context belongs to the preset that created it. An Anthropic continuation rejects history containing context from another preset, including switching between a preset and a direct model. Continue with the original preset or start a new conversation. Editing that preset preserves its identity; deleting and recreating it does not. Direct-model conversations can continue across direct targets and aliases, subject to the existing model-ID replay filter. These restrictions do not change continuation to a Responses backend, which does not send stored private context. The gateway does not discard thinking or private context to make a rejected continuation succeed.

Stored context uses Anthropic's turn-scoped system-message and inline-tool beta contracts. A continuation normally adds user content or tool results before the next model turn. A request that adds no input after an assistant answer can fail Anthropic's placement rules; the gateway does not insert a synthetic user message to make it work.

Haiku 5.5 may not apply factual statements in preset instructions, such as a user's stated preference, in stored conversations, even when the same instructions work with store: false. If a preset relies on such statements, test it with stored continuations.

The history window remains 128 items. Old conversations, deleted items, forks inside a turn, failed saves and a capped prefix can lack information required for exact thinking replay. The gateway does not invent that history or silently fall back to a different session strategy. Token-aware compaction and truncation are separate work.

Output guards continue to withhold intermediate content from public Responses output and capture. After an allowed verdict, eligible accepted intermediates are retained for replay and authorized conversation-item retrieval. A block retains the caller input and block message, not the private intermediates. For an allowed Anthropic answer, authorized conversation retrieval retains each original text block as a separate message for replay. Public Responses output and capture still contain the merged selected answer.

Completion and errors

An ordinary final answer or client tool call produces a completed Responses result. Anthropic's output-token limit produces status:incomplete with reason:max_output_tokens. A text block that Anthropic has finished retains item status completed; this does not mean the response as a whole completed. Check the response status and incomplete reason to detect the output limit. If that limit cuts off a tool-call message, none of that message's gateway calls execute; the final call retains its partial arguments and incomplete status. The gateway does not retry it. A refusal remains a refusal, including when Anthropic provides no explanation. Nonempty refusal explanations replay as exact assistant text. An empty refusal cannot be replayed to Anthropic. Start a new conversation or fork before that item when necessary.

Anthropic's classifier refusal produces status:incomplete with incomplete_details.reason:content_filter. For unguarded requests, partial blocks retain their original item IDs and output positions, with item status incomplete; the refusal explanation follows them. A stream ends with response.incomplete. Already-delivered deltas cannot be retracted. Discard the refused turn's incomplete items when building the next request, and never execute its function calls. Earlier completed turns and gateway tool results remain valid.

The refused turn's partials are excluded from stored replay and GenAI capture; the refusal message is stored under the existing storage policy. Guarded requests expose only the selected refusal; a guard can replace it with the existing completed block-message response. Unsupported terminal outcomes fail explicitly; there is no automatic resume or recovery prompt.

A provider-reported stream error ends the turn as failed and accepts none of that turn's output for stored replay. If the connection instead closes before a terminal outcome, an unguarded streaming response can include completed text and thinking blocks in its public response.failed output. Stored history keeps the text already streamed, including unfinished text blocks, as incomplete assistant messages; it keeps no thinking from that interrupted turn. The gateway does not execute that turn's tool calls. Unary requests discard a turn whose read fails. Text already delivered to a streaming client cannot be retracted.

OpenAI Python 2.14.0 parses response.incomplete through responses.create(stream=True), but its get_final_response() streaming helper expects response.completed and raises for incomplete responses. Handle the response.incomplete event directly when using that version.

Usage includes uncached input, cache creation and cache reads in total input tokens. Counters are accumulated once per model invocation. A later event that omits counters keeps the earlier values. A message missing Anthropic's required initial input/output counters fails before its content or tool calls are accepted; explicit zero is valid. The existing failed-response usage fallback is unchanged. Ordinary logs and traces exclude input, output, thinking, tool payloads and backend error bodies; eligible content is recorded only through permission-gated GenAI capture.

Qualification limits

The supported mapping is narrower than complete Anthropic API compatibility. Native Messages ingress, Anthropic-hosted tools and their cross-format mappings are separate deliveries. Earlier direct-provider experiments do not qualify a deployed gateway route. Each rollout must verify the configured models, SDK replay, stored context, gateway tools, guards and product Chat against the serving revision. Stored tool-choice and parallel-call controls also need qualification with the inline tool definitions used by that route. Mixed preserved-thinking continuation remains a named live qualification requirement; deterministic translation checks alone do not satisfy it.