Claude Fable 5.1 无原生多租户能力，需服务层实现租户隔离：透传 X-Tenant-ID 鉴权、元数据注入、租户级限流与缓存、物理隔离提示词及知识库，并全量统计含 thinking tokens 的 output_tokens 计费。
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
直接说结论：Claude Fable 5.1 本身不提供多租户能力，它只是一个模型 API；所谓“多租户部署”，实际是你的服务层（比如 API 网关、Agent 调度器、租户路由中间件）必须承担全部隔离责任。Fable 5.1 的模型 ID claude-fable-5-1 是全局共享的，调用时不会自动识别租户身份，漏掉一层鉴权或上下文注入，就会串数据、混账单、越权访问。
租户标识必须透传到模型请求体里
Anthropic 协议不原生支持 tenant_id 字段，你不能指望在 messages 或 system 里塞个注释就完事——那只是语义隔离，不是工程隔离。真正有效的做法是把租户信息作为元数据注入到请求头或代理层上下文中：
- 在网关层（如 Kong、Traefik 或自研路由）根据
X-Tenant-ID请求头做分流，同时将该值写入下游服务的 context，再由 Agent SDK 注入到每个anthropic.messages.create()调用的metadata字段（如果平台支持），或作为systemprompt 的首行固定前缀（例如"Tenant: acme-corp | "） - 不要依赖前端传来的任意字符串做租户判定，必须经后端鉴权服务校验其有效性与权限范围，否则
X-Tenant-ID: admin这种伪造请求会直接绕过隔离 - 若使用缓存（如
cache_control+cache_read），注意缓存 key 必须包含租户维度，否则 A 租户的 prompt 缓存可能被 B 租户命中，造成提示词泄露
配额与成本必须按租户粒度硬限流
Fable 5.1 的滑动窗口配额（5 小时）是账户级的，不是租户级的。如果你共用一个 Anthropic API Key，所有租户流量会挤在同一个桶里，大客户一跑批量分析，小客户立刻 429。必须在你的服务层实现两级限流：
- 第一级：租户级 token 用量统计，基于
input_tokens和output_tokens（含 thinking tokens）实时累加，触发阈值时直接拒绝请求，不发往 Anthropic - 第二级：租户级并发控制，限制同一租户最多允许多少个
claude-fable-5-1并发调用，避免 GPU 推理队列被打满导致其他租户延迟飙升 - 务必把
effort参数纳入配额计算——effort: max下输出 token 可达effort: high的 1.7 倍，但单价不变，只涨用量；不封顶的话，账单会突然翻倍
提示词模板与知识库必须物理分离
很多团队以为把不同租户的 system prompt 存在数据库不同字段里就算隔离了，其实远远不够。Fable 5.1 的 system 字段内容会参与推理上下文构建，如果模板中引用了共享变量（比如 {{knowledge_base_url}}），而渲染逻辑没做租户沙箱，就可能把租户 A 的向量库地址拼进租户 B 的请求里。
- 每个租户的提示词模板应独立存储、独立版本管理，渲染时禁用任意代码执行（如 Jinja2 的
{% exec %}），只允许白名单内的变量替换 - 知识库检索结果必须在进入
messages前完成租户过滤——例如向量库查询时强制加上filter: {"tenant_id": "acme-corp"}，不能靠应用层后过滤 - 避免在
system中硬编码敏感路径，比如"请从 s3://prod-tenant-data/acme-corp/faq.json 读取最新FAQ"，这种写法会让租户 ID 泄露在日志和 trace 中
最易被忽略的一点：Fable 5.1 的 thinking 块默认开启且不可关闭，这部分 token 会计入 output_tokens 并按 $50/MTok 计费，但它不返回给前端，也不出现在 content 字段里。如果你的租户用量统计只看响应体中的 content 长度，就会严重低估真实成本——必须解析 Anthropic 返回的完整 usage 对象，提取 output_tokens 全量计入账单系统。
