指南/四层身份
卖的是 Claude Code，为什么回答自己在 Kiro 或 Copilot
卖家标的是「Claude Code 订阅资源」，响应却说自己在 Kiro 或 GitHub Copilot。这个冲突值得记录，但一句自报最多算产品环境残留，不能推出模型掉包或订阅来源造假。继续判断前，要把四层身份分开。
四个名称回答四个问题
一条响应里可能同时出现 claude-sonnet、Claude Code、Kiro、GitHub Copilot、Bedrock 和「Max 订阅」等名称。它们并不处在同一层。
| 身份层 | 要回答的问题 | 常见例子 | 需要的独立证据 |
|---|---|---|---|
| 模型 | 哪个模型快照生成了响应 | 某个 Claude、GPT 或 Gemini 版本 | 可信端点的固定模型标识、服务日志、可复现审计 |
| 产品环境 | 哪个客户端或代理组织了上下文与工具 | Claude Code、Kiro、GitHub Copilot | 持续一致的工具、权限与运行环境记录 |
| 推理渠道 | 请求经由哪个服务到达模型 | 厂商 API、云平台、产品托管服务、企业网关 | 网络记录、响应头、请求 ID、上游日志 |
| 资源来源 | 哪个账号、订阅或项目承担额度与费用 | Claude Pro / Max、API 项目、云账号、组织席位 | 账号授权、用量与账单记录 |
「Claude Code 订阅资源」通常同时声称产品环境和资源来源：调用经过 Claude Code，并消耗某类 Claude 订阅权益。响应里出现 Kiro 或 Copilot，只与产品环境这一层发生表面冲突。模型、推理渠道和付费来源仍是待查项。
这个区分也适用于中转站后台的分组名。分组名是经营者给出的声明，并非请求路径的自动证明。官转、一方云、号池和 IDE 额度等社区叫法的范围，见中转站渠道类型。
Kiro 和 Copilot 都不是单一模型
Kiro 的模型文档明确写明，它提供来自 Anthropic、OpenAI 等厂商的多个模型，也允许选择 Auto，由 Kiro 为任务自动选择模型。GitHub 的Copilot 支持模型列表同样覆盖多个厂商；自动模型选择说明还写明，路由会参考任务复杂度、服务健康、可用性、订阅类型和组织策略。
因此，「我在 Kiro 中运行」或「这是 Copilot」即使属实，也只指向产品环境。它没有给出底层模型的唯一答案。Kiro 可以调用 Claude，也可以调用其他模型；Copilot 也一样。自动选择开启时，同一产品中的不同任务还可能经过不同模型。
反方向也不成立。响应提到 Kiro，不等于已经确认请求进入 Kiro。模型可能复述上下文里的名称，也可能根据问题猜测身份；网关还可能插入、保留或改写系统消息。单次自报只能记作「观察到的文本」，其来源仍是推断。
Claude Code 也不能证明订阅来源
Claude Code 是客户端和代理环境。Anthropic 的模型配置文档允许它选择模型别名或完整名称，也支持 Anthropic API、Amazon Bedrock、Google Cloud 和 Microsoft Foundry 对应的模型标识，并可通过自定义基础地址连接 LLM 网关。文档还区分了两项配置：基础地址决定请求发往哪里，模型设置决定请求哪个模型。
资源来源另有一套配置。Anthropic 的Pro / Max 使用说明写明，系统中若设置了 ANTHROPIC_API_KEY，Claude Code 会改用 API key 认证并产生 API 用量费用，不再消耗订阅内用量。
所以，即便能够确认某次会话运行在 Claude Code 中，也只能确认产品环境；它可能使用 Claude 订阅、API 项目、云平台凭证或企业网关。要验证「Max 订阅资源」，仍需持有资源一方提供账号授权状态、订阅权益与对应时段的用量记录。客户端输出无法代替这些记录。
自报名称处在证据的最低一层
对这类冲突，可以把证据分为四级。等级表达的是可支持的结论范围，不是一个自动判分公式。
一级：响应中的一句自报
保存原始响应、时间、请求模型名和商家当时的分组说明。可写成：「响应文本出现 Kiro，和分组标注不一致。」不能写成：「已确认走 Kiro」「底层不是 Claude」或「订阅来源造假」。
二级：持续的产品环境证据
在正常工作任务中，长期记录工具类别、权限处理、工作区边界和运行环境表现。多次记录若持续一致，能提高对产品环境的判断强度。具体产品指纹、固定问句、探针与组合规则不宜公开；这些细节一旦固定，服务方可以专门改写响应，证据价值随之下降。
这一层仍然回答不了底层模型。Kiro 与 Copilot 的多模型机制已经给出直接反例：同一产品环境可以承载多个模型。
若证据表现为异常缓存、陌生工作目录或远端容器信息，还要先确认它来自模型文本、工具参数还是结构化执行结果。各位置的证据强度见异常缓存与陌生运行环境怎么判断。
三级：推理渠道证据
客户端网络记录、未经改写的响应头、厂商请求 ID、企业网关或云平台日志，可以说明请求经过哪里。中转站可能删除或重写字段，所以「没有某个头」通常只表示证据缺失；可核验的上游日志和与请求时间对应的 ID 更强。
渠道也不等于模型。云平台和产品托管服务都可能提供多种模型，网关还可能进行内部映射。模型字符串长期不变时，后端行为为何仍会变化，可继续看模型名称没变，后端行为为什么会漂移。
四级：模型与资源来源的独立证明
模型身份需要可信服务端的固定模型标识、请求日志或成体系的行为审计。仅看中转站返回的 model 字段仍不充分，因为转发层可以重写它。学术界常用的输出概率、知识边界、潜空间和水印方法，也各有适用条件与误判边界，详见学术界怎么审计中转站掉包模型。
资源来源则要回到账户侧：谁完成认证，哪类权益被使用，费用记到哪个项目或订阅。模型审计再完善，也不能推导账单从哪里扣除。这两项需要两组证据。
同一条材料不能重复计算
身份判断还要检查证据是否独立。一段响应先自称 Kiro，后面又使用 Kiro 的产品名称，仍然可能来自同一段系统上下文；把两句话记成两票，会夸大证据强度。一个中转站复制到多个端点的相同响应模板，也没有形成多个独立来源。
时间连续性比重复次数更有价值。跨会话、跨日期的正常工作记录若保持一致，且请求与响应可以对应到各自的原始记录，才适合讨论产品环境是否持续偏离声明。若差异只在一次会话中出现，下一次又消失，应保留两次原始材料，避免挑选符合预期的样本。
不同层的材料也不能合并成一条身份结论。产品环境记录与响应头共同变化，可以支持「服务路径发生过变化」；它们仍未自动给出模型名称或付费账号。需要确认模型时补模型证据，需要确认订阅时补账户侧证据，各自保留未知项。
遇到名称冲突时怎样记录
先把商家声明原样保存，包括分组名称、承诺的产品环境、模型和资源类型。再保存同一时刻的脱敏请求、完整响应、响应头、请求 ID 与客户端版本，避免只留一张截取了自报句子的截图。
随后给每条材料标注「已观察」「推断」或「缺少证据」。例如：
- 已观察：响应文本出现 Kiro；分组页面标注 Claude Code Max。
- 推断：这次响应可能带有 Kiro 产品环境残留，也可能受上下文或网关改写影响。
- 缺少证据：底层模型、实际推理渠道、承担费用的账号或订阅。
若多次正常任务持续出现同一套产品环境特征，可将结论收窄到「产品环境与声明疑似不一致」，并向服务方索取对应请求的上游记录。若只能取得一句自报，合适的结论是「发现名称冲突，原因未定」。
「Kiro 所以不是 Claude」「Copilot 所以必定是 GPT」「出现 Claude Code 就是 Max 订阅」都跨越了证据层。四层身份分开之后，争议会变成四个可核对的问题：响应由谁生成、在哪个产品中组织、经由哪里推理、由什么资源付费。缺哪一层，就把哪一层留作未知。
LinkyMonitor 持续记录同一分组的请求、响应与历史变化，帮助定位产品环境、协议行为和渠道特征何时发生偏移。