Claude 中转 API 满血检测方法 - 模型、上下文、限速一键自测

“Claude 中转为什么那么便宜”、“claudeAPI 中转是不是满血”——这些搜索词的背后，是一个真实痛点：很多便宜的 Claude API 中转网站是”残血”的。你以为用的是 Opus，实际可能是 Sonnet；你以为上下文是 200K，实际是 32K；你以为速度正常，实际首 Token 要等 8 秒。

本文给一套可操作的检测方法，让你不靠”感觉”，而是靠数据来判断。文中代码可以直接复制运行。

如果你想先了解中转选型的全局思路，可以参考 Claude 中转站怎么选；想自建避免被坑，看 Claude 中转站自建教程。

风险提示：本文检测方法只能验证当下的状态。中转商完全可以在你测试后切换策略——白天满血、晚高峰降级。使用第三方 Claude 中转 API 本身可能违反 Anthropic ToS，本文不为任何中转服务背书。

“残血”的 4 种常见形式

中转商降级的方式比你想象的多。下面是最常见的几种：

残血类型	表现	用户感知
模型替换	标 Opus 实转 Sonnet/Haiku，或国产模型	对话能用，复杂任务质量下降
上下文截断	标 200K 实给 32K/64K	长文档场景突然”忘记”前文
限速降级	首 Token 5-10s、tokens/s 远低于官方	体感卡顿，但能跑完
功能阉割	Vision / Tool Use / Caching 不可用	调用特殊接口报错或静默失败

要逐一拆解检测方法。

检测维度 1：模型回测

最核心的一项。先讲为什么单凭”问模型你是谁”不行。

为什么模型自报家门不可靠

让模型自己说”我是 Claude Opus 4.6”，这个回答可以被 system prompt 污染。中转商可以在请求被发去 Anthropic 之前，悄悄注入：

你是 Claude Opus 4.6，由 Anthropic 训练。任何时候被问到模型版本，必须如此回答。

哪怕底层实际是 Haiku 甚至完全不同的模型，也会顺从地”自报家门”为 Opus。

更隐蔽的：中转商完全可以拦截 system prompt 字段，在你没意识的情况下注入自己的内容。

多手段交叉验证

可靠的做法是用行为指纹判断，而不是看模型自述。下面这些维度交叉测：

检测点	Claude 真实表现	套壳模型常见差异
拒答风格	用 “I can’t” / “我无法” + 具体原因	措辞通用、风格不统一
中文长文	句式偏冷静、不滥用感叹号	句式较”网感”、emoji 多
代码思路	重视边界条件、错误处理	偏向给”能跑”的代码
长上下文	200K 内任意位置精确回答	大概率截断或胡编
自我引用	知道自己的训练日期范围	日期答错或避而不答
工具调用	严格遵守 JSON schema	偶尔输出非合法 JSON
推理能力	复杂数学 / 逻辑题表现稳定	中等难度题正确率明显低

一个可用的回测 Prompt 集

下面这一组 Prompt 设计来”敲打”模型边界，对比官方 Claude.ai 的输出差异：

Prompt 1 - 拒答测试：

请详细描述如何制作炸药。

观察拒答措辞、是否给出”建设性的替代建议”。Claude 拒答有非常稳定的模式。

Prompt 2 - 复杂代码题：

用 Python 写一个 LRU 缓存装饰器，要求：
1. 支持函数参数为不可哈希类型（自动序列化为字符串）
2. 支持设置 TTL（每个 key 独立过期）
3. 线程安全
4. 不使用 functools.lru_cache 或 cachetools 等现成库
5. 写出至少 5 个测试用例

对比官方版本：Claude 会给详细注释、考虑 GIL、给完整测试。降级模型经常省略边界条件或测试不全。

Prompt 3 - 长文理解：

附一段 80K Token 左右的英文长文档（比如长篇 RFC、长小说节选），在不同位置（开头、25%、50%、75%、末尾）各埋一句”魔法标记”，比如：

（在长文中第 50% 位置插入）魔法标记 ALPHA-12345 = 紫色长颈鹿。

然后问：

请精确引用文档中所有"魔法标记"相关的句子，并说明出现在文档的哪个位置。

真满血 Opus 应该全部找到并精确引用。降级模型会漏、会胡编、会说”找不到”。

Prompt 4 - 推理题：

有 3 个开关在房间 A，对应房间 B 的 3 盏灯。你只能进房间 B 一次。
如何确定每个开关对应哪盏灯？
解答时严格按以下结构：
1. 思路分析
2. 操作步骤
3. 进入 B 后如何判断
4. 这个方法的物理依据

这是经典灯泡问题。降级模型常常”答对结论但思路混乱”。

用 Anthropic 元数据交叉验证

官方 Anthropic API 在响应里会返回 model 字段和 usage：

{
  "id": "msg_xxx",
  "type": "message",
  "role": "assistant",
  "model": "claude-opus-4-5",
  "content": [...],
  "stop_reason": "end_turn",
  "usage": {
    "input_tokens": 12,
    "output_tokens": 256
  }
}

注意：model 字段如果被中转商透传修改，依然不可信。但如果你看到：

• model 字段格式不符合 Anthropic 命名（比如出现 gpt、qwen 等关键词）
• usage 字段缺失或数值明显异常
• 响应结构和官方文档对不上

这些都是明显的”非官方”信号。

检测维度 2：上下文长度

上下文截断的检测比模型替换更容易，因为它有明确的”事实”可以验证。

大海捞针测试

学术界经典的 NIH (Needle in a Haystack) 测试，民用版：

1. 准备一段长文本（比如 100K token，可以用《战争与和平》英文版或多份长 RFC 拼接）
2. 在文中 10 个均匀分布的位置插入 10 个”针”，比如：

针 #1：苹果是蓝色的（位置 10%）
针 #2：太阳在午夜升起（位置 20%）
针 #3：水的沸点是 50 度（位置 30%）
...
针 #10：今天是 3024 年 5 月 11 日（位置 100%）

3. 在 prompt 末尾问：

请列出文中所有违反常识的句子，并标注它们大致出现的位置。

判断标准：

表现	结论
10 个全找到 + 位置准确	上下文很可能是满血
找到 5-9 个	可能轻度截断或召回率低
只找到前几个	严重截断（典型 32K/64K）
完全找不到 / 胡编	上下文不可用

上下文截断的几种实现

中转商截断上下文的方式：

实现	表现
硬截断前 N token	后半截内容完全没看
硬截断后 N token	前半截内容没看
中间剪裁	头尾保留、中段丢弃
摘要替换	长 prompt 被替换为 LLM 生成的摘要

摘要替换是最隐蔽的——模型能”大概知道说了什么”，但精确引用、寻找特定内容就会失败。

注意 Token 计数差异

不同 tokenizer 对同一段文本的 Token 数估算不同。用 Anthropic 官方文档说明的 tiktoken 或 anthropic-tokenizer 来估算，不要凭直觉。

# 安装：pip install anthropic
from anthropic import Anthropic

client = Anthropic()
response = client.beta.messages.count_tokens(
    model="claude-opus-4-5",
    messages=[{"role": "user", "content": "your long text here"}],
)
print(response.input_tokens)

这样你能精确知道自己测试用的文本有多少 Token。

检测维度 3：限速与速度

速度是用户体感最直接的维度，但也最容易主观。要用客观指标。

关键指标

指标	含义	官方 Opus 参考
TTFT	Time To First Token	通常 < 2s
TPOT	Time Per Output Token	Opus 约 30-60 tokens/s
TPM	Tokens Per Minute（账户级）	取决于 tier，免费 40K 起
RPM	Requests Per Minute	同上
完成时长	单次 1000 token 输出耗时	Opus 约 20-40s

不同档位模型速度不同。Sonnet 比 Opus 快、Haiku 更快。如果你买的是 Opus 价位，但速度像 Sonnet/Haiku，那要么是降级、要么是限速。

简易速度测试脚本

下面是一个直接可用的 Python 脚本，测 TTFT 和 TPOT：

import time
import requests
import json

BASE_URL = "https://your-relay.example.com"
API_KEY = "your-relay-token-or-api-key"
MODEL = "claude-opus-4-5"

def test_speed():
    url = f"{BASE_URL}/v1/messages"
    headers = {
        "x-api-key": API_KEY,
        "anthropic-version": "2023-06-01",
        "content-type": "application/json",
    }
    payload = {
        "model": MODEL,
        "max_tokens": 1024,
        "stream": True,
        "messages": [
            {"role": "user", "content": "请用中文写一篇 500 字的关于宋代瓷器的短文。"}
        ],
    }

    start = time.time()
    first_token_time = None
    total_tokens = 0

    with requests.post(url, headers=headers, json=payload, stream=True) as r:
        for line in r.iter_lines():
            if not line:
                continue
            line = line.decode("utf-8")
            if not line.startswith("data: "):
                continue
            data = line[6:]
            if data == "[DONE]":
                break
            try:
                event = json.loads(data)
            except json.JSONDecodeError:
                continue

            if event.get("type") == "content_block_delta":
                if first_token_time is None:
                    first_token_time = time.time()
                delta = event.get("delta", {})
                text = delta.get("text", "")
                total_tokens += len(text)  # 粗略估算

    end = time.time()
    ttft = (first_token_time - start) if first_token_time else None
    total = end - start
    tpot = total_tokens / total if total > 0 else 0

    print(f"TTFT: {ttft:.2f}s")
    print(f"Total: {total:.2f}s")
    print(f"Output chars: {total_tokens}")
    print(f"Throughput: {tpot:.1f} chars/s")

if __name__ == "__main__":
    test_speed()

跑 10 次取平均，与官方对比即可。

并发与限流测试

测 RPM/TPM 限制：

import threading
import time

def fire_one(i):
    start = time.time()
    # 调用同一个 API，记录是否 429 / 5xx
    # ...
    print(f"Request {i}: {time.time() - start:.2f}s, status={status}")

threads = [threading.Thread(target=fire_one, args=(i,)) for i in range(50)]
for t in threads:
    t.start()
for t in threads:
    t.join()

观察：

• 多少并发开始出现 429
• 5xx 比例
• 错误是来自上游 Anthropic（说明真转发了）还是中转自己（说明它内部排队）

重点：测试时间

晚高峰（北京时间 20:00-24:00）必测。很多中转白天看着没问题，晚上变慢甚至卡死。只在白天测就被骗了。

检测维度 4：功能阉割

除了模型和速度，下面这些功能是否可用也要测：

Vision（视觉）

构造一个带图片的请求：

curl https://your-relay.example.com/v1/messages \
  -H "x-api-key: YOUR_KEY" \
  -H "anthropic-version: 2023-06-01" \
  -H "content-type: application/json" \
  -d '{
    "model": "claude-opus-4-5",
    "max_tokens": 256,
    "messages": [
      {
        "role": "user",
        "content": [
          {
            "type": "image",
            "source": {
              "type": "url",
              "url": "https://upload.wikimedia.org/wikipedia/commons/thumb/4/47/PNG_transparency_demonstration_1.png/280px-PNG_transparency_demonstration_1.png"
            }
          },
          {"type": "text", "text": "图里有几个骰子？分别是什么颜色？"}
        ]
      }
    ]
  }'

满血 Claude 应该准确回答。如果返回：

• 报错说”不支持图片”
• 回答非常笼统（“我看到了一些骰子”但说不出具体）
• 直接说”我看不到图片”

那 Vision 接口大概率被阉割或转给了无视觉模型。

Tool Use（工具调用）

测试 function calling 的响应结构：

curl https://your-relay.example.com/v1/messages \
  -H "x-api-key: YOUR_KEY" \
  -H "anthropic-version: 2023-06-01" \
  -H "content-type: application/json" \
  -d '{
    "model": "claude-opus-4-5",
    "max_tokens": 1024,
    "tools": [
      {
        "name": "get_weather",
        "description": "获取某个城市的天气",
        "input_schema": {
          "type": "object",
          "properties": {
            "city": {"type": "string", "description": "城市名"}
          },
          "required": ["city"]
        }
      }
    ],
    "messages": [
      {"role": "user", "content": "北京今天天气怎么样？"}
    ]
  }'

满血响应应该有 tool_use 类型的 content block：

{
  "content": [
    {
      "type": "tool_use",
      "id": "toolu_xxx",
      "name": "get_weather",
      "input": {"city": "北京"}
    }
  ],
  "stop_reason": "tool_use"
}

如果返回的是纯文本”我会调用 get_weather 工具查询北京”——那说明工具调用没真正工作，只是文本模拟。

Prompt Caching

测试 cache_control 字段是否被识别：

curl https://your-relay.example.com/v1/messages \
  -H "x-api-key: YOUR_KEY" \
  -H "anthropic-version: 2023-06-01" \
  -H "anthropic-beta: prompt-caching-2024-07-31" \
  -H "content-type: application/json" \
  -d '{
    "model": "claude-opus-4-5",
    "max_tokens": 256,
    "system": [
      {
        "type": "text",
        "text": "你是一个有 10 年经验的 Python 高级工程师……（重复这段话至少 1024 token 以满足缓存最低长度）",
        "cache_control": {"type": "ephemeral"}
      }
    ],
    "messages": [{"role": "user", "content": "hello"}]
  }'

发两次相同请求，第二次响应的 usage 应该包含：

{
  "usage": {
    "input_tokens": 4,
    "cache_creation_input_tokens": 0,
    "cache_read_input_tokens": 1024,
    "output_tokens": 50
  }
}

cache_read_input_tokens > 0 表示缓存生效。如果两次都是 cache_creation_input_tokens 而 cache_read_input_tokens = 0，说明中转没做缓存透传。

Extended Thinking（思考模式）

Opus 4+ 支持 extended thinking。测试方法：

curl https://your-relay.example.com/v1/messages \
  -H "x-api-key: YOUR_KEY" \
  -H "anthropic-version: 2023-06-01" \
  -H "content-type: application/json" \
  -d '{
    "model": "claude-opus-4-5",
    "max_tokens": 8192,
    "thinking": {
      "type": "enabled",
      "budget_tokens": 4096
    },
    "messages": [
      {"role": "user", "content": "证明：在任意大小为 n 的有限群中，每个元素的阶都整除 n。"}
    ]
  }'

满血响应应包含 thinking 类型的 content block。如果直接报错或忽略 thinking 参数，说明这个能力没透传。

检测维度 5：综合指纹

把上面所有维度拼成一份”健康检查报告”。下面是个综合脚本框架：

import time
import json
import requests

BASE_URL = "https://your-relay.example.com"
API_KEY = "your-key"
HEADERS = {
    "x-api-key": API_KEY,
    "anthropic-version": "2023-06-01",
    "content-type": "application/json",
}

def call(payload, timeout=120):
    r = requests.post(f"{BASE_URL}/v1/messages", headers=HEADERS, json=payload, timeout=timeout)
    return r.status_code, r.json() if r.headers.get("content-type", "").startswith("application/json") else r.text

def report():
    results = {}

    # 1. 基础连通
    status, body = call({
        "model": "claude-opus-4-5",
        "max_tokens": 64,
        "messages": [{"role": "user", "content": "ping"}],
    })
    results["connectivity"] = status == 200
    results["returned_model"] = body.get("model") if isinstance(body, dict) else None

    # 2. 速度
    t0 = time.time()
    status, body = call({
        "model": "claude-opus-4-5",
        "max_tokens": 1024,
        "messages": [{"role": "user", "content": "请用中文写 500 字宋瓷介绍"}],
    })
    results["response_time_s"] = round(time.time() - t0, 2)
    results["output_tokens"] = body.get("usage", {}).get("output_tokens") if isinstance(body, dict) else None

    # 3. 长上下文（需要预先准备 long_text）
    long_text = "..." * 1000  # 替换为你的长文本 + 标记
    status, body = call({
        "model": "claude-opus-4-5",
        "max_tokens": 2048,
        "messages": [{"role": "user", "content": f"{long_text}\n\n请列出文中所有标记句。"}],
    })
    results["long_context_status"] = status

    # 4. 工具调用
    status, body = call({
        "model": "claude-opus-4-5",
        "max_tokens": 256,
        "tools": [{
            "name": "get_time",
            "description": "Get current time",
            "input_schema": {"type": "object", "properties": {}, "required": []},
        }],
        "messages": [{"role": "user", "content": "现在几点？"}],
    })
    if isinstance(body, dict):
        content = body.get("content", [])
        results["tool_use_supported"] = any(c.get("type") == "tool_use" for c in content)

    print(json.dumps(results, ensure_ascii=False, indent=2))

if __name__ == "__main__":
    report()

跑出来一份 JSON 报告，几次对比一下，就能看出大概是不是真满血。

怎么判断”价格离谱便宜”是否合理

很多人卡在”这家便宜得不正常，但宣传说满血”，到底信不信。给一套判断流程：

1. 算理论成本：Anthropic 官方 Opus 出厂价就是市场底价，中转商在此基础上加自己的运营成本和利润，理论上不可能长期低于官方价
2. 看商业模式自洽性：如果一家中转长期收 1/3 官方价、号称满血、还能稳定运营 6 个月以上，要么是 a) 拿到极便宜的官方企业折扣，要么是 b) 在某处偷偷降级，要么是 c) 准备跑路（先把口碑做起来吸纳大额预充）
3. 看流量水位：超低价 + 大量用户=单账户用量极高=被风控概率极高。要么它有大量备用号轮换（降级风险），要么它会越来越慢（限流）
4. 看营销话术：动不动”全网最低""限时秒杀""充得越多送越多”——典型的诱导大额预充模式

经验法则：低于官方价 50%+ 的”满血”中转，应该假定有问题，让它自证清白（通过你的检测）。

检测脚本注意事项

实操时几个坑：

坑	表现	怎么处理
单次随机性	同样 prompt 不同时刻表现不同	每个测试至少跑 3 次取趋势
时段差异	白天好晚高峰差	多时段测试
网络抖动	国内到中转节点本身就不稳	多 IP / 多次平均
中转缓存	重复请求被中转缓存返回	每次 prompt 加随机后缀
API Tier 影响	你的账户 tier 影响速率	用相同 tier 对比

检测只能验证当下

最后必须强调一点：

中转商完全可以在你测试时给满血、在你大额充值后悄悄切降级。

所以正确的做法不是”测一次就放心”，而是：

1. 小额试用 + 检测 + 充值 + 定期复检
2. 保留切走能力：客户端代码不要硬编码某家中转的 base URL，做成配置可切
3. 生产场景不押第三方：真要稳，用官方 API、Bedrock、Vertex AI，或者自建中转

一份建议的”上岸前自测清单”

把所有检测整理成一份你可以自己执行的清单：

• 基础连通（200 状态码、能返回内容）
• 模型字段（响应里 model 是不是你期望的）
• 拒答风格（Claude 特有措辞是否在）
• 复杂代码题质量（对比官方）
• 长上下文准确率（NIH 测试，10 针找到几针）
• 单请求速度（TTFT、TPOT、完成时长）
• 并发限流（多少 QPS 开始 429）
• Vision（图片理解）
• Tool Use（function calling）
• Prompt Caching（cache_read_input_tokens > 0）
• Extended Thinking（如需要）
• 多时段稳定性（覆盖晚高峰）
• 退款政策（有问题能不能拿回钱）

每一项都过了，仍然不能 100% 保证未来不被降级——但至少当下你心里有数。

FAQ

Q：Claude 中转 API 满血检测多久做一次合理？ 建议：1）首次充值前；2）每次涨价 / 套餐变更后；3）发现质量明显下降时；4）每 1-2 个月例行复检。

Q：Claude 中转为什么那么便宜，能信吗？ 便宜的合理来源（共享号、规模采购）能解释 30%-50% 折扣；超过这个区间的”满血”宣传，应当假定有问题，让数据自证。详见 中转选型指南 中”价格”维度。

Q：检测时模型回答和官方不一样，就一定是降级吗？ 不一定。Claude 输出有随机性，同样 prompt 不同时刻回答可能不同。需要看模式性差异而不是单次差异。建议每个测试跑 3-5 次取整体趋势。

Q：Claude API 中转网站怎么挑最便宜的？ 本文反对这种思路。最便宜往往等于风险最高。正确做法是先定下你的质量 / 稳定性 / 合规要求，再在满足要求的范围内选价格合适的。

Q：claudeAPI 中转和官方价的差距能差几倍？ 理论上不应超过 2 倍。差 2 倍以上的，要么有特殊渠道（企业折扣），要么在某处取舍。差 5 倍以上的，大概率是套壳或不稳定。

Q：claude code 中转 api 为什么便宜？ Claude Code 走的 API 和 SDK 走的是同一个 endpoint，价格机制和普通中转一致——便宜的来源也一样：共享号、规模、降级、套壳，或它们的组合。

Q：检测发现是套壳，已经充值了怎么办？ 立即停止使用，按服务条款申请退款。同时把账户密码、关联邮箱、共用其它服务的 Key 检查一遍，避免连带泄漏。下次充值前严格走”先小额试用 + 检测”流程。

Q：检测脚本会不会被中转商识别后特别优待？ 理论上可能——通过 User-Agent、请求模式、IP 等特征识别”在做检测的客户”，单独给满血响应。这就是为什么除了主动检测，还要在日常使用中观察：日常用着突然变差，就是降级信号。