Exact v1 recognition for Messages base URLs
Messages 基址严格识别 v1
The Messages transport appends the Anthropic-standard `/v1` namespace to a configured base URL. A base that already ends in `/v1` previously produced `/v1/v1/messages`, while recognizing every `v`-plus-digit suffix as a provider version granted undocumented compatibility and could bypass the standard namespace.
English
Problem
The Messages transport appends the Anthropic-standard /v1 namespace to a configured base URL. A base that already ends in /v1 previously produced /v1/v1/messages, while recognizing every v-plus-digit suffix as a provider version granted undocumented compatibility and could bypass the standard namespace.
Decision
The shared Messages API owner trims trailing slashes and treats only a final path segment exactly equal to v1 as the existing API version. It preserves that root and appends /messages or /files; every other base receives /v1/messages or /v1/files. The same resolved root scopes cached file uploads. The official https://api.deepseek.com/anthropic base therefore resolves to /anthropic/v1, and an explicit /anthropic/v1 base remains unchanged.
The Messages rule does not infer support for v1beta, v2, v4, or other version-like suffixes; deployments that include those segments receive the standard /v1 namespace beneath them.
Alternatives considered
Recognize any final segment beginning with v and a digit. This avoids repetition for more custom endpoints, but it turns a narrow duplicate-v1 repair into an undocumented compatibility policy and can route requests outside the Anthropic-standard namespace.
Always append /v1. This follows the standard path for unversioned roots but preserves the original duplicate path for callers whose configured base already ends in /v1.
Consequences
Messages, Files, and file-cache identity use one deterministic rule. Exact /v1 configurations remain compatible without changing the recommended unversioned base. Other version-like suffixes are not treated as API versions and therefore resolve beneath an added /v1; this deliberately gives up speculative proxy compatibility.
中文
问题
Messages 传输会在配置的基址后追加 Anthropic 标准 /v1 命名空间。此前，已经以 /v1 结尾的基址会生成 /v1/v1/messages；而把所有 v 加数字的后缀都识别为提供方版本，会提供未经说明的兼容性，并可能绕过标准命名空间。
决策
共享 Messages API 所有者移除末尾斜线，仅把严格等于 v1 的最后路径段视为已有 API 版本。它保留该根地址并追加 /messages 或 /files；其他基址均追加 /v1/messages 或 /v1/files。缓存文件上传也使用同一个解析后的根地址划分作用域。因此，官方 https://api.deepseek.com/anthropic 基址解析为 /anthropic/v1，显式 /anthropic/v1 基址保持不变。
Messages 规则不推断 v1beta、v2、v4 或其他类似版本后缀的支持；包含这些路径段的部署会在其下接收标准 /v1 命名空间。
考虑过的替代方案
识别所有以 v 加数字开头的末尾路径段。 这可以避免更多自定义端点重复版本，但会把范围有限的 v1 重复修复变成未经说明的兼容策略，并可能把请求路由到 Anthropic 标准命名空间之外。
始终追加 /v1。 这对无版本根地址遵循标准路径，但仍会为已以 /v1 结尾的配置产生原有重复路径。
结果
Messages、Files 与文件缓存标识使用同一条确定性规则。严格匹配 /v1 的配置保持兼容，推荐的无版本基址无需改变。其他版本式后缀不被视为 API 版本，因此会在其下追加 /v1；这会有意放弃对代理的推测性兼容。