# Claude Code 换了 API 端点后，你调的还是 Claude 吗？四个 curl 判别方法

> 本文所有输出均为实测结果，命令可直接复制运行。测试端点为一个接入 Anthropic 官方上游的网关，测试时间 2026 年 8 月。

网上讲「国内怎么用 Claude Code」的教程，大多止步于这两行：

```bash
export ANTHROPIC_BASE_URL="某个地址"
export ANTHROPIC_AUTH_TOKEN="某个密钥"
```

配完能跑起来，教程就结束了。但这里有一个几乎没人讲清楚的问题：**Claude Code 只是一个客户端，它把请求发到哪儿由你决定，而对面跑的是什么模型，它并不知道，也不会告诉你。**

换句话说，`ANTHROPIC_BASE_URL` 改成任何一个实现了 Anthropic 协议的地址，Claude Code 都能正常工作——不管对面是 Anthropic 官方、是别的厂商的兼容层，还是一个把请求翻译成完全不同协议再转发出去的服务。界面一模一样，回答也像模像样，你无从分辨。

如果你只是想要一个能写代码的助手，这不重要。但如果你是**冲着 Claude 的特定能力来的**——长上下文下的稳定性、Agent 任务的规划质量、工具调用的准确率——那你有必要知道自己实际在调什么。

下面是四个可以自己验证的方法。

---

## 一、先说结论：响应里的 `model` 字段靠不住

最直觉的做法是看响应体里的 `model` 字段。实测：

```bash
curl -sS "$ANTHROPIC_BASE_URL/v1/messages" \
  -H "content-type: application/json" \
  -H "x-api-key: $ANTHROPIC_AUTH_TOKEN" \
  -H "anthropic-version: 2023-06-01" \
  -d '{"model":"claude-sonnet-5","max_tokens":16,
       "messages":[{"role":"user","content":"只回复两个字：通了"}]}'
```

返回：

```json
{
    "model": "claude-sonnet-5",
    "id": "msg_011CeMUfdok2KYdMLXntV8Un",
    "type": "message",
    "role": "assistant",
    "content": [{"type": "text", "text": "通了"}],
    "stop_reason": "end_turn"
}
```

看起来是 `claude-sonnet-5`。但**这个字段的值就是你在请求里写的那个**——任何一个兼容层为了不让客户端报错，都必须原样回显它。它证明不了任何事。

同理，直接问模型「你是谁」也没有意义：模型对自己的身份认知来自训练数据和系统提示词，两者都可以被中间层改写，而且很多模型在被追问身份时本来就会给出不准确的回答。

**要判断，得看协议层面那些不容易伪造的地方。**

---

## 二、为什么会出现这个问题

Anthropic 的 `/v1/messages` 是一个公开的 HTTP 协议。任何服务都可以实现它，实现之后 Claude Code 就认。目前市面上的端点大致有三类：

| 类型 | 做了什么 | 你实际调用的模型 |
|---|---|---|
| **官方直连** | 请求直接到 `api.anthropic.com` | Claude |
| **接入网关** | 转发到 Anthropic 上游，处理鉴权、计费、连接优化 | Claude |
| **协议兼容层** | 把 Anthropic 格式的请求翻译成别的协议，转发给另一个模型 | 不是 Claude |

第三类没有任何问题，它是一种合理的产品形态——让你用惯了的客户端接到别的模型上。问题只在于**你得知道自己用的是哪一类**，否则会拿着 A 的体验去评价 B。

区别在实际使用中会暴露出来：兼容层需要把 Anthropic 的请求结构映射到目标模型的结构，而两边的能力并不一一对应。工具调用的格式、多轮对话里的 `tool_result` 处理、system 提示词的组织方式、超长上下文的截断策略——每一处映射都可能有损耗。日常补全感觉不出来，跑长任务时就会表现为「莫名其妙就跑偏了」。

判断方法的思路也就清楚了：**去测那些只有真上游才做得到的行为。**

---

## 三、四个判别方法

### 3.1 用一个不存在的模型名探测

真正的 Anthropic 上游维护着一份模型清单，请求一个不在清单上的名字会被明确拒绝：

```bash
curl -sS "$ANTHROPIC_BASE_URL/v1/messages" \
  -H "content-type: application/json" \
  -H "x-api-key: $ANTHROPIC_AUTH_TOKEN" \
  -H "anthropic-version: 2023-06-01" \
  -d '{"model":"claude-not-a-real-model-9","max_tokens":8,
       "messages":[{"role":"user","content":"hi"}]}'
```

实测返回：

```json
{"type":"error",
 "error":{"type":"not_found_error","message":"model: claude-not-a-real-model-9"},
 "request_id":"req_011CeMUhppqPZbsdhGjqVxG4"}
```

**怎么判读**：

- 返回 `not_found_error` 且消息里带上了你写的模型名 → 上游在做真实的模型校验
- **任何模型名都能正常返回内容** → 中间层没有校验，大概率是把所有请求都映射到同一个后端模型
- 返回的错误结构不是 Anthropic 的 `{"type":"error","error":{...}}` 形状 → 中间做了协议转换

第二种情况是最值得警惕的：如果 `claude-not-a-real-model-9` 也能给你写代码，那你请求 `claude-opus-4-5` 时拿到的是什么，就完全无从确认了。

### 3.2 看响应头

响应体容易构造，响应头往往是透传的。实测：

```bash
curl -sS -D- -o /dev/null "$ANTHROPIC_BASE_URL/v1/messages" \
  -H "content-type: application/json" \
  -H "x-api-key: $ANTHROPIC_AUTH_TOKEN" \
  -H "anthropic-version: 2023-06-01" \
  -d '{"model":"claude-sonnet-5","max_tokens":8,
       "messages":[{"role":"user","content":"hi"}]}' \
  | grep -iE '^(HTTP|anthropic|request-id)'
```

实测输出：

```
HTTP/1.1 200 OK
anthropic-ratelimit-unified-representative-claim: five_hour
anthropic-ratelimit-unified-reset: 1787579400
anthropic-ratelimit-unified-overage-disabled-reason: org_level_disabled
anthropic-ratelimit-unified-overage-status: rejected
request-id: req_011CeMUhtExvwSMUGtBB6Uwn
anthropic-workspace-id: wrkspc_01YJURGSxnjoNMHLYCybV6jq
```

（限额相关的头还有几个，这里只保留了能说明问题的部分。）

**怎么判读**：

- `anthropic-ratelimit-unified-*` 这一组头是 Anthropic 侧的限额状态，且各字段之间有内在一致性（`reset` 是 Unix 时间戳、`representative-claim` 对应计费窗口）
- `request-id` 是 `req_` 开头的 Anthropic 格式，和响应体里 `msg_` 开头的消息 ID 属于同一套编码风格
- **一个头都没有，只有 `content-type` 和 `date`** → 中间层自己组装了响应，没有透传上游

需要说明的是，正规的接入网关出于安全考虑也可能过滤掉部分响应头，所以「头少」不等于「有问题」，它只是让你无法从这一项得到确认。真正的红旗是第 3.1 节那种情况。

### 3.3 测 prompt caching 是否真实生效

这一项最难伪造，因为它必须有真实的计费和存储行为在背后支撑。

Anthropic 的 prompt caching 需要在请求里显式标记要缓存的部分，这是 Anthropic 协议独有的设计。构造一个足够长的 system 提示词（缓存有最小长度要求，太短不会生效）：

```bash
python3 - <<'PY' > /tmp/cc.json
import json
long_text = "这是一段用于测试 prompt caching 的填充文本。" * 120
print(json.dumps({
  "model": "claude-sonnet-5", "max_tokens": 8,
  "system": [{"type": "text", "text": long_text,
              "cache_control": {"type": "ephemeral"}}],
  "messages": [{"role": "user", "content": "只回复一个字：好"}]
}, ensure_ascii=False))
PY

# 连发三次，观察 usage 的变化
for i in 1 2 3; do
  curl -sS "$ANTHROPIC_BASE_URL/v1/messages" \
    -H "content-type: application/json" \
    -H "x-api-key: $ANTHROPIC_AUTH_TOKEN" \
    -H "anthropic-version: 2023-06-01" \
    --data-binary @/tmp/cc.json \
  | python3 -c "
import sys,json; u=json.load(sys.stdin)['usage']
print(f\"创建={u['cache_creation_input_tokens']:<6} 命中={u['cache_read_input_tokens']}\")"
done
```

实测输出：

```
创建=2546   命中=0
创建=0      命中=2546
创建=0      命中=2546
```

**这组数字是很强的证据**：第一次写入缓存 2546 个 token，之后两次全部命中。数字前后严格一致，说明上游确实按 token 粒度存了这段内容——这不是一个转发层能靠伪造字段编出来的。

**怎么判读**：

- 出现「先创建、后命中」且数字一致 → 真实的 Anthropic 缓存行为
- `cache_creation` 和 `cache_read` **恒为 0** → 请求里的 `cache_control` 被忽略了，说明目标模型不支持这个特性
- 请求直接报错、提示不认识 `cache_control` 字段 → 中间层没有实现完整协议

顺带一提，这一项对成本影响很大。跑 Agent 任务时 system 提示词和项目上下文会被反复发送，缓存命中与否可能差出一个数量级的输入 token 消耗。

### 3.4 看 `usage` 字段的结构

Anthropic 的 `usage` 对象这几年长出了不少字段，兼容层通常只实现最基本的几个。完整的实测输出：

```json
{
  "input_tokens": 12,
  "cache_creation_input_tokens": 2546,
  "cache_read_input_tokens": 0,
  "cache_creation": {
    "ephemeral_5m_input_tokens": 2546,
    "ephemeral_1h_input_tokens": 0
  },
  "output_tokens": 3,
  "service_tier": "standard",
  "inference_geo": "not_available",
  "output_tokens_details": {
    "thinking_tokens": 0
  }
}
```

**怎么判读**：`cache_creation` 的两档时长拆分、`service_tier`、`inference_geo`、`output_tokens_details.thinking_tokens` 这些字段，只有跟着 Anthropic 协议版本走的服务才会有。如果只返回 `input_tokens` 和 `output_tokens` 两个字段，基本可以确定中间做过一次结构重建。

同样地，字段少不必然意味着有问题——但字段齐全且数值自洽，是相当可靠的正面信号。

---

## 四、四项汇总

| 判别项 | 真上游的表现 | 值得警惕的表现 |
|---|---|---|
| 假模型名 | `not_found_error`，消息里回显模型名 | **任何名字都能返回内容** |
| 响应头 | `anthropic-ratelimit-unified-*`、`req_` 格式 ID | 完全没有上游头（也可能是安全过滤） |
| prompt caching | 先 `creation` 后 `read`，数字一致 | 两项恒为 0，或直接报错 |
| `usage` 结构 | 含 `cache_creation` / `service_tier` 等 | 只有最基础的两个 token 计数 |

**四项里第一项权重最高**，因为它没有「安全过滤」这类正当解释。四项全过，基本可以确认请求确实到了 Anthropic；第一项就不过，那后面三项也不用测了。

---

## 五、顺带解决三个常见报错

测试过程中最容易撞上的几个错误，判断依据都很明确。

**返回 404。** 十有八九是 `ANTHROPIC_BASE_URL` 里把 `/v1/messages` 也写进去了——客户端会自己补这一段，于是路径变成 `/v1/messages/v1/messages`。实测复现：

```bash
# 正确路径
curl -sS -o /dev/null -w 'HTTP %{http_code}\n' -X POST \
  "$ANTHROPIC_BASE_URL/v1/messages" \
  -H "content-type: application/json" -H "x-api-key: $ANTHROPIC_AUTH_TOKEN" \
  -H "anthropic-version: 2023-06-01" \
  -d '{"model":"claude-sonnet-5","max_tokens":8,"messages":[{"role":"user","content":"hi"}]}'
# → HTTP 200

# base_url 里多写了一层 /v1/messages 时，客户端拼出来的实际路径
curl -sS -o /dev/null -w 'HTTP %{http_code}\n' -X POST \
  "$ANTHROPIC_BASE_URL/v1/messages/v1/messages" \
  -H "content-type: application/json" -H "x-api-key: $ANTHROPIC_AUTH_TOKEN" \
  -H "anthropic-version: 2023-06-01" \
  -d '{"model":"claude-sonnet-5","max_tokens":8,"messages":[{"role":"user","content":"hi"}]}'
# → HTTP 404
```

**地址填到域名或 `/v1` 为止就够了。** 这个坑的完整排查过程可以参考[这篇 404 排查记录](https://console.code2ai.codes/kb/anthropic-base-url-404)。

**Claude Code 里所有请求都超时，但上面的 curl 却是通的。** 这种「curl 通、客户端不通」的组合几乎总是环境变量问题——shell 里残留了指向不可用地址的网络相关变量，导致每个请求都要先撞一次超时。先查一下：

```bash
env | grep -iE "proxy|PROXY"
```

WSL 用户尤其容易中招，因为 WSL 和 Windows 是两套独立的网络栈，配置里写的本机地址在 WSL 内并不指向 Windows 侧的同名端口。[这篇超时排查](https://console.code2ai.codes/kb/all-requests-timeout)里有完整的判断流程。

**报 `temperature is deprecated for this model`。** Claude 5 系列已经弃用了这个参数，自己写脚本调用时去掉即可。注意这个报错本身也是一个判别信号——**能准确报出这个错，说明上游确实在按 Claude 5 的参数规则校验请求**。

---

## 六、FAQ

**Q：这些方法会不会误伤正规的接入服务？**

会有一定概率。响应头过滤是常见的安全实践，`usage` 字段也可能因为协议版本滞后而不全。所以判断要看四项的组合，尤其以「假模型名」那一项为准——它没有正当的其他解释。

**Q：测试会消耗多少额度？**

四项加起来不到 3000 个输入 token、几十个输出 token。用最小的 `max_tokens` 即可，成本可以忽略。

**Q：兼容层是不是就一定不好？**

不是。用 Claude Code 的界面接别的模型是一种合理产品形态，日常补全和小范围重构上体验差别不大，价格往往还更有优势。本文要解决的只是知情权问题：**你应该知道自己在用什么，再决定它值不值那个价。**

**Q：怎么判断一个服务是网关还是单纯的请求转发？**

这是另一个维度的问题，涉及是否做鉴权隔离、是否留存请求内容、是否有独立的限额与计费体系。Code2AI（code2ai.codes）整理过[一份六个维度的判别清单](https://www.code2ai.codes/kb/ai-gateway-vs-proxy.html)，可以配合本文的协议层测试一起用。

**Q：请求内容会被中间层看到吗？**

技术上，任何位于你和模型之间的服务都具备读取请求体的条件，这是 HTTP 转发的固有属性，与服务商是谁无关。所以这个问题不该问「会不会」，而该问「对方有没有把处理方式写成可追责的公开承诺」。判断依据、以及应该在服务条款里找哪几句话，[这篇说明](https://www.code2ai.codes/kb/api-gateway-data-privacy.html)里列得比较全。

---

## 小结

三句话：

1. **`model` 字段是回显，不是证据**，问模型「你是谁」同样无效
2. **四个协议层特征可以验证**：假模型名报错、上游响应头、prompt caching 真实生效、`usage` 字段结构
3. **兼容层不是问题，不知情才是问题**——知道自己在调什么，才谈得上评价它值不值

这套方法不需要任何特殊权限，四条 curl 命令、三千个 token，谁都能自己跑一遍。包括跑在你现在正在用的那个端点上。

---

*本文由 Code2AI（code2ai.codes）团队整理，基于实际部署与排错记录。文中所有命令输出均为实测结果。*

本文所有输出均为实测结果，命令可直接复制运行。测试端点为一个接入 Anthropic 官方上游的网关，测试时间 2026 年 8 月。

Claude Code 换了 API 端点后，你调的还是 Claude 吗？四个 curl 判别方法

响应里的 model 字段是回显你请求的值，不能用来判断端点背后到底是什么模型，问模型「你是谁」同样无效。本文给出四个
  可自行验证的协议层判别方法：用不存在的模型名探测上游是否真做校验、检查 anthropic-ratelimit 系列响应头、实测
  prompt caching 是否真实命中、核对 usage 字段结构。全部命令可复制运行，附实测输出。

开发工具

人工智能

测试

ClaudeCode换API端点后如何确认真正调用的模型？本文提供四个curl验证方法：使用假模型名探测上游校验、检查Anthropic特有响应头、测试prompt caching真实生效、查看usage字段完整性。实测结果显示，model字段仅为回显不可靠，而缓存命中率和错误响应结构能有效区分官方网关与协议兼容层。附404、超时等常见报错排查方案。

热销域名限时优惠，新客首年免费！


domain

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

ClaudeCode换API端点后如何确认真正调用的模型？本文提供四个curl验证方法：使用假模型名探测上游校验、检查Anthropic特有响应头、测试prompt caching真实生效、查看usage字段完整性。实测结果显示，model字段仅为回显不可靠，而缓存命中率和错误响应结构能有效区分官方网关与协议兼容层。附...

Claude Code 换了 API 端点后，你调的还是 Claude 吗？四个 curl 判别方法-腾讯云开发者社区-腾讯云

Claude Code 换了 API 端点后，你调的还是 Claude 吗？四个 curl 判别方法

Claude Code 换了 API 端点后，你调的还是 Claude 吗？四个 curl 判别方法

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐