一个端点，
所有模型。
Tare 是挡在你所有模型前面的一层 OpenAI 兼容网关 —— 我们的，和你自己带来的。一个 base URL、一把 key，每一个 token 都算得清。
演习（Mock）
这篇解决什么问题：让你不用真的把额度花光、也不用等一次真实故障，就能演练各种失败 场景。
Mock（演习）不会真的打上游。它让 Tare 按指定剧本，返回和真实失败形状一致的错误。
为什么需要它
演习最难自己造的就是错误分支。真要撞到额度用尽，得先把钱花光；真要遇上一次上游故障，只能等它 自己发生，不由你挑时候。
给某一把 key 挂上一种固定场景，用这把 key 打的请求就会直接返回模拟结果，不会真的打到上游。 不花一个 token，也不用等一次真实故障出现。
什么时候用 Mock
- 上线前验证客户端如何处理限流、欠费、额度用尽。
- 验证客服或前端展示给终端用户的错误文案。
- 验证重试逻辑是否只对该重试的错误重试。
- 验证监控和告警能否识别失败。
推荐演练顺序
- 先用正常 Mock 响应（
SUCCESS）确认调用链路可控。 - 演练 429，确认客户端读取了
Retry-After。 - 演练额度用尽和欠费，确认不会盲目重试。
- 演练上游全挂，确认前端和告警都能识别。
- 演练 DLP 拦截，确认不会把敏感内容继续发给上游。
详细说明
挂上一个场景
控制台路径：API Keys → 某把 key 上的烧瓶图标。
也可以直接调接口：
curl -X PUT https://tare.jamerly.ai/v1/mocks/{apiKeyId} -H "Authorization: Bearer $TARE_KEY" -H "Content-Type: application/json" -d '{"scenario":"UPSTREAM_TIMEOUT","enabled":true}'
只圈定你指名的这把 key，不是整个账号。 用管理凭据操作时，也只能动它名下的 key。拿一把专门 的 key 去演习，不会因此把同事的生产流量变成假数据。
场景清单
GET /v1/mocks/scenarios 会给出完整列表，从这里读，不要在客户端写死，因为清单
以后可能增加：
| 场景 | 模拟的是 |
|---|---|
KEY_CREDIT_EXHAUSTED | 这把 key 自己的消费上限用完 |
BUDGET_EXHAUSTED | 账号月度预算用完 |
ACCOUNT_BALANCE_INSUFFICIENT | 账号余额耗尽 |
RATE_LIMITED | 请求太频繁 |
UPSTREAM_TIMEOUT | 上游一直不响应 |
UPSTREAM_ERROR | 上游返回 5xx |
INVALID_KEY | 凭据被拒 |
MODEL_NOT_FOUND | 请求的模型不存在 |
BAD_REQUEST | 请求格式错误 |
CONTENT_FILTERED | 内容策略拦截 |
SUCCESS | 正常响应，内容由你指定（见下文） |
每一种失败场景返回的错误形状，和真实发生时 Tare 会给的一模一样。目的是让你的代码走到真正的 那条分支，而不是一个近似的版本。
SUCCESS：固定响应，不是失败
这是唯一一种非失败场景。把 responseBody 设成你想要的那段完整 JSON，可选加上
delayMs 模拟延迟。适合测试正常路径：拿到一个稳定可预测的输出，而不是真实模型那种
会变化的回答。
过期时间
演习本来就该是临时的：不填 expiresAt，默认从开启时算起 4 小时后过期，没有
「永久」这个选项。
一个没人记得开过的演习，挂在一把不知不觉变成生产 key 的凭据上，比重新开一次的麻烦要糟得多。
不会影响的地方
- 别的 key 上的调用不受影响。 演习是挂在 key 上的属性，不是账号级的。
- 不消耗一个 token，演习从不会真的打到上游。
- 关闭或删除从下一次调用起生效；已经在处理中的调用不受影响。
演习仍然会留下痕迹，也可能计费
演习调用永远会写一条用量记录，标成 MOCKED，所以无论哪种场景，都不计入你的
成功率统计（SUCCESS 场景不会把它拉高，失败场景也不会把它拉低）。
它走的是和真实调用同一条计费链路：token 用量始终是 0，但如果这个模型走的渠道配了单次调用 的最低收费，这笔最低收费照收。这次调用同样要先过余额、key 额度、预算这三道闸，和真实调用一样。 已经用尽额度的 key，没法靠开演习绕过检查、顺便蹭一笔路由费。
开关演习本身也会留痕。 生产流量悄悄开始返回假数据这件事，之后一定会有人要你解释那段时间 发生了什么。详见 审计日志。