协议端点

三套原生入口，互相平级。入口路径即协议，我们不做请求体嗅探。

端点

入口	协议标识	base_url	说明
`POST /v1/messages`	anthropic	https://api.akrouter.com	原生 Messages API。thinking block、cache_control 断点、tool_use id 全部原样透传
`POST /v1/responses`	openai_responses	https://api.akrouter.com/v1	原生 Responses API。reasoning item 原样保留
`POST /v1/chat/completions`	openai_chat	https://api.akrouter.com/v1	最广泛兼容的入口
`POST /v1/messages/count_tokens`	anthropic	https://api.akrouter.com	Claude Code 用它估算上下文占用，以决定何时压缩历史

流式与非流式都支持，由请求体里的 stream 决定，与我们无关 —— 我们只是把它转发出去。

原样转发是默认，翻译是降级

调度顺序固定为：

优先选 protocols 包含你的客户端协议的渠道 —— 请求体字节级透传，零翻译
无同协议渠道可用时才降级到翻译路径
走了翻译的请求会在日志上标记 translated = true，你能在使用日志里看到

跨协议翻译是有损的

损失点恰好都在编码 Agent 最依赖的功能上。这类故障的共同特征是「能用，但行为不对」—— 不报错、难复现。

翻译时丢失的东西	后果
`Anthropic thinking block`	扩展思考内容丢失或格式错乱
`cache_control 断点`	prompt cache 全部不命中，成本涨数倍、TTFT 变差
`tool_use / tool_result 的 id 对齐`	多轮工具调用直接崩
`Responses API 的 reasoning item`	Codex 的推理链断裂
`anthropic-beta / openai-beta 头`	特性开关静默失效

因此如果你在意这些能力，建议在路由偏好里打开「只用原生协议渠道」硬约束：满足不了就报错，而不是悄悄翻译。

请求头处理

原则是默认放行，只剥必须剥的。

处理	头
剥离	hop-by-hop 头、`host`、`content-length`、`cf-`、`x-forwarded-`，以及你的下游凭据（`Authorization` / `x-api-key`）
透传	其余全部，尤其 `anthropic-beta`、`openai-beta`、`anthropic-version`

路由元数据

我们会回传这次请求实际走了哪条渠道、尝试过哪些、哪些约束生效了。没有它，「为什么这次慢」只能靠猜。

json

{
  "akrouter": {
    "requested": "claude-sonnet-5",
    "selected": { "merchant": "acme-01", "channelId": "...", "translated": false },
    "attempts": [ { "channel": "...", "status": 429, "errorClass": "rate_limited" } ],
    "constraints": { "priceCap": "applied", "preferLatency": "soft, 2 channels downweighted" }
  }
}

同样的信息在使用日志的请求详情里有完整的 attempts 时间线。

错误响应形状

错误一律按你的客户端协议的形状返回，不做统一格式。

json

// anthropic
{ "type": "error", "error": { "type": "...", "message": "..." } }

// openai_chat / openai_responses
{ "error": { "message": "...", "type": "...", "code": "..." } }