App 只发 Chat，后端如何在 Inroi Chat 与 Requesty Responses 之间安全回退

接中转最容易踩的坑，不是 JSON 少一个逗号，而是把三个不同层次混成一件事：App 对 Foreverse 说什么协议、Foreverse 对中转说什么协议，以及最后按哪张价表扣费。Luna 和 Terra 的生产链已经把这三层拆开：客户端始终发 OpenAI Chat；一级 Inroi 接 Chat；只有一级在首帧前失败时，后端才把同一请求转换成 Requesty Responses。

一套 App Chat 接口，为什么后端要维护两种上游协议？

Android 和 iOS 不需要知道当前是哪家中转。App 仍向 Foreverse 的 Chat Completions SSE 接口发消息；后端根据实际承载渠道做协议转换。这样续写、扩写、ST 和 Agent 共用一条客户端消息轨道，供应商差异不会散进 UI。

Inroi 的 API 基址是 https://www.inroi.shop/v1。Requesty 的 API 基址是https://router.requesty.ai/v1；https://app.requesty.ai/ 只是管理后台，拿它当 API Host 会得到网页或 404。Requesty 这条链的关键不是把 openai/ 模型名硬送进 Chat，而是/responses 加 openai-responses/ 目录前缀。

回退规则：一级一次、二级一次，不是失败三次再切

文本生成是付费长请求。同一个故障渠道连续重试三遍，会把等待和可能的上游费用一起放大。Foreverse 的边界是“用户是否已经看见任何上游帧”：没看见时可以安全换路；一旦看见，就不再重放。

两级全失败且零产出时，预扣全退；一级失败但二级成功时，只按最终 usage 结算一次。失败尝试会进入统一渠道健康统计，备用成功不会把一级故障抹掉，但人为强制回退的验收样本也不能拿来冒充线上 SLA。

生产到底测了哪些功能？

最终验收不是一句“你好”。两条渠道都跑了普通续写、单次扩写、Agent 发工具、回传工具结果，以及重复前缀缓存。早期出现过超时、断流和 Requesty 工具 400；修复后的最终矩阵闭环如下。

Requesty 早期 Agent 400 的根因是 Chat 形态的命名函数选择被原样塞进 Responses。直连 A/B 证明 Responses 需要扁平的函数名字段；转换后，Luna 与 Terra 的工具首轮和结果回传都完成。这个事故说明“模型支持工具”与“每一种兼容参数组合都支持”不是同一句话。

旧筛选里还出现过 output_tokens=8192、reasoning_tokens=8192、正文为零的 xhigh 请求。那两笔直接请求 Requesty 的评测由 runner 显式设成 8K，并没有经过 Foreverse；不过旧服务端和 Agent / Reader 默认同样使用 8K，产品链也存在相同风险。reasoning、工具参数和可见正文共用输出额度，8K 不是模型能力上限，而是当时为了让预扣与最大输出一致设置的资金护栏。

缓存命中了多少？为什么仍不能写 cache write 为 0？

Requesty 直连重复探针先证明了自动前缀缓存；生产链随后分别验证了 Inroi 显式路由键和 Requesty Responses 回退。下表只写 token 事实，不把命中率包装成长期保证。

另一组显式 5247-token 探针在两款模型上都命中 5244 cached tokens。Inroi 不带缓存字段时重复大前缀没有回传命中；加入稳定的prompt_cache_key 与显式模式后才出现命中。稳定键只由用户与公开模型生成哈希，不包含 prompt、邮箱或原始用户 ID。

两家当前都没有暴露 cache_write_tokens。所以正确记录是 null，不是 0。后端已经兼容标准字段和 Requesty 的兼容别名，也支持 1.25 倍写入价；在权威 token 明细出现以前，不从 cache miss 或中转成本字段倒推。

基础短档与 App +50% 用户价必须分开看

统一价真源是 2026-07-31 的 OpenAI Standard 短上下文价目档与 prompt caching 规则，而不是任一中转返回的usage.cost。OpenAI 在 7 月 30 日的 Changelog 中还明确记录了 Luna 降价 80%、Terra 降价 20%； 下表采用降价后的官方短上下文口径。

1 credit = $0.0001。基础美元价先换成 credits，再统一乘 1.5，整笔向上取整。普通输入、缓存写入和缓存读取互斥拆分，不能把已经包含在prompt_tokens 里的缓存 token 再收一次；缓存写入单价正好是普通输入的 1.25 倍。两款官方模型的 Foreverse 中转 prompt 暂时硬顶 200k tokens，避免进入更贵的长上下文档却仍按短档结算。

Inroi 与 Requesty 的内部采购成本可能不同，有些中转还会返回自己的倍率或旧价。Foreverse 不把这个差额传给用户：两条路都按上表统一结算。反过来，上游若没有给完整 usage，也不能凭一个内部成本数字伪造 token 拆分。

这次实测能证明什么，不能证明什么？

它能证明两款 OpenAI 官方模型 ID 在两级中转生产协议上完成过续写、扩写、Agent 和缓存，回退与统一计费也走通过真实闭环。它不能把中转调用写成 Foreverse 直连 OpenAI，不能把强制故障验收换算成中转 SLA，也不能用接口成功替代小说质量评测。

价格和目录都会变化，本文的数字绑定 2026-07-31。想继续理解重复前缀为什么省钱，可看Prompt 缓存账单实测；想分清官方渠道和自带 key，见手机 BYOK 配置说明；更长周期的价目变化收在Token 价格趋势。

协议背景可对照Requesty Responses 文档、OpenAI Changelog、Standard 定价与Prompt caching 规则。