DEV Community: Dashu

A 200 Response Is Not Enough: Testing Claude Code Through an Anthropic Gateway

Dashu — Sun, 30 Aug 2026 12:56:41 +0000

A 200 response from an AI gateway proves that one HTTP request worked. It does not prove that Claude Code can discover a model, send the right Messages payload, recover from an optional endpoint failure, and finish a task.

That distinction matters when Claude Code is configured through an Anthropic-compatible gateway such as XiuRouter.

This guide uses a two-layer acceptance test:

Send a small request directly to /v1/messages.
Run a complete short task in Claude Code.

If the first layer fails, debug the gateway configuration. If it passes but the second layer fails, debug the client workflow instead of rotating keys or changing models at random.

Configure the API root, not the Messages path

Claude Code appends /v1/messages to the configured base URL. Set the API root without /v1:

export ANTHROPIC_BASE_URL="https://router-api.xiu.ai"
export ANTHROPIC_AUTH_TOKEN="YOUR_XIUROUTER_API_KEY"
export CLAUDE_CODE_ENABLE_GATEWAY_MODEL_DISCOVERY="1"

ANTHROPIC_AUTH_TOKEN sends a Bearer token, which XiuRouter accepts on the Messages route. Gateway model discovery lets Claude Code load models exposed by the configured gateway.

A base URL ending in /v1 produces the duplicated path:

https://router-api.xiu.ai/v1/v1/messages

That is a configuration error, not a model error.

Test `/v1/messages` before opening Claude Code

Use an exact model ID visible to the intended XiuRouter key. Do not copy a model ID from an old article or another service group.

curl -X POST "$ANTHROPIC_BASE_URL/v1/messages" \
  -H "Authorization: Bearer $ANTHROPIC_AUTH_TOKEN" \
  -H "anthropic-version: 2023-06-01" \
  -H "content-type: application/json" \
  -d '{
    "model": "YOUR_MODEL_ID",
    "max_tokens": 32,
    "messages": [
      {
        "role": "user",
        "content": "Reply only with: connected"
      }
    ]
  }'

The response should be JSON with a Messages content value. Check more than the status code:

The body is JSON, not an HTML error page returned by a proxy.
The response contains text content.
The model and usage fields are plausible for the request.
The request appears in the expected XiuRouter usage records.

An HTTP 200 with an empty body, malformed JSON, or HTML is still a failed integration.

Then test the Claude Code workflow

Start Claude Code in a non-critical repository:

claude

Use /model and select a model marked From gateway. Run /status and confirm the Anthropic base URL and gateway credential are active.

The test task should exercise the client, not just produce a greeting. For example:

Read package.json and report the package manager, test command, and build command.
Do not edit any files.

A useful pass condition is:

Claude Code discovers a gateway model.
The task starts without an authentication or payload error.
The client receives a usable Messages response.
The task reaches a final answer.
The corresponding gateway request is visible in usage records.

This catches failures that a standalone curl request cannot expose.

Treat `count_tokens` 404 as a workflow signal

XiuRouter does not expose a dedicated /v1/messages/count_tokens route. Claude Code documents token counting as optional and can fall back through the inference endpoint.

Do not classify the connection as broken from that 404 alone. Check what happens next:

If Claude Code falls back to /v1/messages and completes the task, the missing optional route did not block the workflow.
If the task stops after the 404, capture the client version and logs, then diagnose the client behavior.

The pass condition is task completion, not the absence of every warning.

Failure patterns and the shortest useful check

`401` or invalid token

Confirm that the variable is ANTHROPIC_AUTH_TOKEN, the key is active, and the shell that starts Claude Code actually contains the variable.

If Claude Code reports multiple credential sources, run /logout to use the gateway credential, or unset the gateway variables to keep the saved Claude login. Do not leave both paths ambiguous.

Gateway models do not appear

Confirm:

export CLAUDE_CODE_ENABLE_GATEWAY_MODEL_DISCOVERY="1"

Restart Claude Code after changing the environment. Also verify that the intended key can see at least one Claude model.

The request path is `/v1/v1/messages`

Remove /v1 from ANTHROPIC_BASE_URL. The correct value is:

https://router-api.xiu.ai

A `400` response names experimental fields

Retry with:

export CLAUDE_CODE_DISABLE_EXPERIMENTAL_BETAS="1"

This is narrower than changing the model, key, and gateway at the same time.

HTTP 200 contains HTML

Inspect the response content-type and body. A CDN, login wall, or proxy can return an HTML page with a successful transport status. The direct curl test should return Messages JSON.

Direct Messages works, but Claude Code still fails

Keep the successful curl response as evidence and narrow the remaining variables:

Claude Code version
selected gateway model
active environment variables
credential-source warning
optional endpoint fallback
experimental request fields

Changing one variable at a time preserves the known-good gateway result.

Roll back without leaving mixed credentials

For the CLI, unset the gateway variables and restart Claude Code:

unset ANTHROPIC_BASE_URL
unset ANTHROPIC_AUTH_TOKEN
unset CLAUDE_CODE_ENABLE_GATEWAY_MODEL_DISCOVERY
unset CLAUDE_CODE_DISABLE_EXPERIMENTAL_BETAS

Run /status after restart and confirm that the previous connection is active.

For the VS Code extension or Claude desktop Code, restore the previous environment or Third-Party Inference configuration, restart the application, and run the same status check.

References

These references were reviewed on August 30, 2026. Model availability can change, so use the current catalogue and an exact model ID visible to the intended key.

XiuAI and its products are operated by XiuLab Inc, a U.S. corporation.

One API Does Not Mean One Protocol: Chat Completions, Responses, Messages, and Gemini

Dashu — Sun, 30 Aug 2026 10:40:07 +0000

"OpenAI compatible" is useful shorthand, but it is not a complete integration contract.

Two clients can accept the same API key and base domain while sending different request paths, authentication headers, payload shapes, streaming events, and tool-call formats. That difference matters when you connect coding agents, SDKs, or production applications to a multi-model gateway.

At XiuAI, we expose four text-generation routes through XiuRouter:

OpenAI Chat Completions
OpenAI Responses
Anthropic Messages
Gemini GenerateContent

The practical rule is simple:

Start with the protocol your client actually sends. Do not choose a protocol from the model name or from an "OpenAI compatible" label.

This article explains how to make that choice and how to verify the integration without turning a small configuration change into a production incident.

1. Choose the client protocol before the model

A model name does not determine the request protocol.

For example, the same model may be reachable through Chat Completions in one service group but not through Responses or Messages in another. A successful Chat Completions request is not proof that the same model and route will support Responses, Anthropic Messages, or Gemini GenerateContent.

Use the client's native behavior as the starting point:

Client or application	Preferred route
Codex, agents, and new OpenAI-style applications	OpenAI Responses
Claude Code, Anthropic SDKs, and Claude-native clients	Anthropic Messages
Existing OpenAI-compatible applications that do not support Responses	Chat Completions
Gemini SDKs and Gemini-native clients	Gemini GenerateContent

If the client documentation is unclear, inspect its official configuration guide or request logs. Do not infer the protocol from a generic compatibility badge.

2. Base URLs depend on what the client appends

An OpenAI-compatible SDK usually appends paths under /v1\, so its configured base URL is:

\text https://router-api.xiu.ai/v1 \\

A Claude client that appends /v1/messages\, or a Gemini client that appends /v1beta/models/...\, should use the API root:

\text https://router-api.xiu.ai \\

This is a common source of duplicated paths such as /v1/v1/messages\, especially when a configuration field is called "API URL" without explaining whether it expects a domain, a base path, or a complete endpoint.

For direct requests, use the complete path:

Protocol	Method and path
Chat Completions	`POST /v1/chat/completions\`
Responses	`POST /v1/responses\`
Anthropic Messages	`POST /v1/messages\`
Gemini GenerateContent	`POST /v1beta/models/{model}:generateContent\`

3. Authentication is also protocol-specific

OpenAI-compatible requests use a Bearer token:

\http Authorization: Bearer YOUR_XIUROUTER_API_KEY \\

Anthropic Messages can use:

\http x-api-key: YOUR_XIUROUTER_API_KEY anthropic-version: 2023-06-01 \\

XiuRouter also accepts a Bearer token on the Messages route for gateway clients such as Claude Code.

Gemini GenerateContent can use:

\http x-goog-api-key: YOUR_XIUROUTER_API_KEY \\

Gemini's key\ query parameter is accepted as well, but headers are easier to keep out of access logs and copied URLs.

4. Run one small request on the exact production combination

Before moving application traffic, test the exact combination of:

API key
model ID
service group
protocol
streaming mode
tool or structured-output features you need

First list the models visible to the scoped key:

\bash curl https://router-api.xiu.ai/v1/models \ -H "Authorization: Bearer $XIUROUTER_API_KEY" \\

Then send one small request through the route your client will use. For Responses:

\bash curl https://router-api.xiu.ai/v1/responses \ -H "Authorization: Bearer $XIUROUTER_API_KEY" \ -H "Content-Type: application/json" \ -d '{ "model": "YOUR_MODEL_ID", "input": "Reply only with: XiuRouter connected" }' \\

For Anthropic Messages:

\bash curl https://router-api.xiu.ai/v1/messages \ -H "x-api-key: $XIUROUTER_API_KEY" \ -H "anthropic-version: 2023-06-01" \ -H "Content-Type: application/json" \ -d '{ "model": "YOUR_MODEL_ID", "max_tokens": 64, "messages": [ { "role": "user", "content": "Reply only with: XiuRouter connected" } ] }' \\

After the response, verify the same request in usage records: key, model, service group, endpoint, token counts, status, and cost.

The small test is billable. Check the current model and service-group pricing before sending it.

5. Know the compatibility boundaries

A gateway route can support the core text request without implementing every provider feature.

Current XiuRouter boundaries include:

/v1/messages/count_tokens\ has no dedicated route. Claude Code documents token counting as optional and can fall back through inference, but you still need to verify that the final task completes.
The Responses route is stateless. Stored conversations, previous_response_id\, background mode, and provider-hosted tools are outside the current compatibility scope.
XiuRouter exposes Gemini GenerateContent, not the Gemini Interactions API.
Files, fine-tuning, image variations, and some legacy endpoints are not implemented by the current gateway.
Tool calls, structured output, prompt caching, streaming events, and token accounting can differ when an inbound request is converted to an upstream provider format.

These are not edge cases to hide in fine print. They determine whether an agent can finish a task, whether a retry is safe, and whether usage records match the client's expectations.

6. Use scoped keys and keep the rollback small

Create one key per application or environment. Limit models, service groups, quota, expiration, and IP scope where appropriate.

For a migration:

Keep the existing provider configuration available.
Add XiuRouter as a separate provider or environment.
Test a small non-critical task.
Compare output, streaming, tool calls, token accounting, latency, and cost.
Move traffic gradually.
Keep the previous provider as the rollback path until the new route has passed real workloads.

Changing only a base URL is convenient. Treating that change as proof of full protocol compatibility is not.

Reference

The current endpoint table and limitations are maintained in the XiuRouter API compatibility guide. The guide was reviewed on August 22, 2026, and this article was checked against it on August 30, 2026.