AI 早报
产品上新

Claude Code 走微软 Foundry:把 5 小时墙换成 Azure 配额池

三行环境变量把 Claude Code 路由到 Microsoft Foundry,用企业配额池换掉 Anthropic 端 5 小时速率墙。

2026年7月5日 · 周日 深度报告 中置信 重要度 4/5
#Claude Code#Microsoft Foundry#Azure#企业IT#路由#配额#Sonnet 5#5小时上限

本文要点

  • 速率限制从单一 Anthropic 5 小时墙,迁移到消费级窗口加 Foundry 配额池双轨制。
  • 厂商绑定由 Anthropic API Key 扩展到独立的 Foundry 资源与密钥鉴权层。
  • 模型选择从硬写模型名,变为 sonnet、opus、haiku 三档环境变量别名。

阅读辅助

先看数字、证据和来源，再读正文。

3 个必填环境变量 特性开关、必填环境变量数
claude-sonnet、haiku、opus 三档别名 模型别名集(可在 .env 中覆盖)
5 条 Claim Audit

Claude Code 现支持走 Microsoft Foundry 路由 Claude Sonnet 5 与 Opus 4.8;绕过 Anthropic 消费级 5 小时滚动上限。

6 个时间点

2026-04 前后 · Anthropic 在 Claude Code 引入第三方推理 Provider 抽象层(BASE_URL 与 AUTH_TOKEN 通用化);后续 issue #64677 暴露该层在 Foundry 上的兼容性欠账。

8 个来源 7 个非 X 来源

一条 X 教程把 GitHub 主干里的开关送进了中文社区算法流

7-4 晚,@israfill 在 X 发了一条「Claude Code 旁路 5 小时墙」教程,核心只有三个环境变量。但把这条推文当作「民间 hack 教程」是低估了它——它的真实作用是把 Claude Code v2.1.152+ 主干里已经写好的 CLAUDE_CODE_USE_FOUNDRY 特性开关,第一次从 GitHub issue 区带进中文社区的算法流。

这条路径不是泄漏,也不是 hack。它是 Anthropic 与 Microsoft 在 Claude 模型分发层面的一次低调合入:Claude Code 主干代码 + Microsoft Foundry 目录同时上架,Anthropic 的 docs 至今没正式宣告,而 @israfill 的推文恰好补上了「中文用户最快上手的 README」。7-5 时点检索 CLAUDE_CODE_USE_FOUNDRY,Anthropic 官方 docs 仍然 0 命中;docs.anthropic.com 会 301 重定向到 code.claude.com,但这条路径目前直接 404。

对企业 IT 决策者来说,值得把这件事摆在桌面上重新看一眼的原因只有一个:这不是「免费多打几次 Sonnet 5」的福利,而是「把 Claude 消费级订阅采购换成 Azure 月度账单摊销」的一条灰色通道。但走通之前必须先把账算清——Foundry 路径当前的 bug 谱系,直接影响「这条路径能不能上生产」。

Foundry 专属 7 个 issue:「能不能上生产」的硬证据

把 anthropics/claude-code 仓库的 foundry+azure 检索命中按 Foundry 路径影响过滤,Foundry 专属 issue 合计 7 个,分两档:

状态数量issue
Open6#64677 / #64766 / #66896 / #67179 / #69179 / #63358
Closed Not planned1#62894
Foundry 专属合计7—

宽口径(另含 2 个旁系 issue):#52572(第三方 Provider 完整 parity Not planned)+ #65585(auto-compact 自 v2.1.161 起对 3P Provider 失效 Open)= 2 个旁系。所以 Foundry 路径实际受 9 个 issue 影响,但 Foundry 专属 = 7 个(6 Open + 1 Closed Not planned)。下文除特别说明外,「Foundry 专属 N 个 issue」一律指 7 这个数。

Issue标题要点影响状态
#62894子代理 effort 参数在 Foundry 上 400(Foundry 不支持 effort 字段)子代理掉链Not planned
#64677缺 /anthropic 路径段,首次 Interactive Sign-in 404 api_not_supported首次连接失败Open
#64766Foundry 模型探测不传 api-version 查询参数 → 误判 404模型探测失败Open(stale)
#66896Test connection 指向 /models/chat/completions 而非 /anthropic/v1/messages测试连接假阳/假阴Open(stale)
#67179Azure Foundry 部署校验时 404 api_not_supported部署验证失败Open
#69179加载 claude-api skill 后 21% 上下文误报 Context limit reached误限速Open
#63358Opus 4.8 thinking block 在 Foundry 上空返回(从 Opus 4.7 起的回归)Opus 走 Foundry 能力降级Open

Foundry 专属 7 个 issue 的判读:

  • #62894(子代理 effort)是 Not planned,实装影响最大:Claude Code 自动给进程注入 CLAUDE_EFFORT=high,子代理翻译成 effort API 字段后 Azure Foundry 不认,直接 400。Anthropic 处理决定非常清晰——Foundry 路径上子代理掉 effort 短期内不会修,企业用户必须自己绕开(目前社区方案是手动清环境变量)。
  • #63358(Opus 4.8 thinking block)Open,意味着「在 Foundry 上跑 Opus extended thinking」目前是能力降级状态;不是连不上,而是 thinking block 返回空。
  • #64677 / #64766 / #66896 / #67179 四个 Open 全部围绕 endpoint 拼装错误——首部署 90% 概率撞上 404 api_not_supported,Claude Code 的 Test connection 一键验证本身又会被 #66896 / #64766 欺骗(打错 URL 得到假 404),排错体验差。
  • #69179 21% 上下文误报影响所有 Foundry 用户,但只在加载 claude-api skill 后触发。
  • 旁系 #65585:Foundry 走的是 Claude Code 的「第三方 Provider 抽象层」,这条抽象层 v2.1.161 起对所有 3P Provider 关闭了 auto-compact——Foundry 也吃这个回归,长会话压缩失效。

Foundry 专属 7 个 issue 里只有 1 个 Not planned(#62894),其余 6 个都是 Open,这意味着首次部署 Foundry 路径大概率会撞上 1-2 个 Open bug,而不是「等官方修完再上」。Foundry 路径的真实稳定度目前是「基础对话 + 基础工具调用能用,高级特性(subagent effort / Opus thinking / auto-compact)等待官方支持」的有限功能集。

三行命令背后的路由机制

按 issue #62894 复现路径,完整配置是把这几行写进 .bashrc(Windows 同理进 PowerShell profile):

export CLAUDE_CODE_USE_FOUNDRY=1
export ANTHROPIC_FOUNDRY_RESOURCE="<你的 Azure 资源名>"
export ANTHROPIC_FOUNDRY_API_KEY="<你的 Azure Foundry key>"
export ANTHROPIC_DEFAULT_SONNET_MODEL="claude-sonnet"

启动 Claude Code 时,SDK 检测到 CLAUDE_CODE_USE_FOUNDRY=1,不再走 Anthropic 官方 api.anthropic.com,而是构造 https://<resource>.services.ai.azure.com/anthropic/v1/messages 走 Azure Foundry 的兼容 endpoint,APM、Token 计费、配额监控则全打到 Azure 控制台。

三组环境变量各管一段:

  • CLAUDE_CODE_USE_FOUNDRY=1 — 开关。SDK 看到这个标志位,会切到 Foundry 的 endpoint 拼装路径。
  • ANTHROPIC_FOUNDRY_RESOURCE + ANTHROPIC_FOUNDRY_API_KEY — 一对鉴权。RESOURCE 是 Azure Foundry 的 resource name,API_KEY 是 Foundry 控制台签发的密钥,跟 Anthropic 的 API Key 体系完全独立。
  • ANTHROPIC_DEFAULT_<MODEL>_MODEL — 模型别名映射。claude-sonnet / claude-haiku / claude-opus 是 Claude Code 内置的三档别名,各自映射到 Foundry 目录里的具体模型——你可以绑 sonnet-5、也可以绑 opus-4-8。

@israfill 的推文里把这套 env var 缩写成了 AZURE_ENDPOINT_URL / AZURE_API_KEY——这两组命名跟 GitHub issue 实测的 ANTHROPIC_FOUNDRY_RESOURCE / ANTHROPIC_FOUNDRY_API_KEY 不一致。可能的解释是推文给的是「教程级简化命名」、issue 给的是 Anthropic SDK 实装命名;真实生产配置必须以 issue #62894 的 .bashrc 复现路径为准。

5 小时墙被绕开的机制:Claude Code 不再向 Anthropic API 发请求,自然不消费 Anthropic 的速率预算;替代它的是 Azure 配额池按 TPM/RPM 计费,按企业订阅走 Enterprise Agreement 月度发票,而不是消费级信用卡月付。

维度Anthropic 官方路径(Pro / Max / API Key)Microsoft Foundry 路径
速率限制5 小时滚动窗口 + 周/月配额Azure 配额池(TPM/RPM,由企业 IT 调)
计费主体信用卡 / 预付Enterprise Agreement 月度发票 / 成本中心
模型档位Sonnet 5、Opus 4.8(消费级速率)Foundry 目录全量(含 mythos-5、fable-5)
鉴权方式Anthropic API Key(OAuth / Setup Token)ANTHROPIC_FOUNDRY_RESOURCE + ANTHROPIC_FOUNDRY_API_KEY
官方文档完整度完整截至 7-5 仍无完整 doc
Foundry 专属未修 issue—7 个(6 Open + 1 Closed Not planned)

这条路径是 6 月内被「无声明」点亮

把时间线拉回到 6 月初,这条路径其实是被企业集成问题反向点亮。

5-28:Anthropic 在 issue #52572 把「第三方推理 Provider 完整 parity」的需求关为 Not planned——这是非常关键的官方表态:Anthropic 不会主动扩展第三方 Provider,但 Foundry 这条 Azure 合作路径仍是主线有写入的特例(否则 #62894 不会被 closed not planned 而 #64677 等 Foundry 专属 bug 也不会在主线跟踪)。

6-2:issue #64677(Claude Desktop 3P + Foundry + Interactive Sign-in)在 Windows 平台完整复现出 endpoint 拼装错误——Claude Desktop 拼出来的 URL 是 https://<resource>.services.ai.azure.com/models/chat/completions,少了 /anthropic 这段,直接返回 404 api_not_supported。这个 issue 透露两个信号:1) Foundry 路径在 Claude Code 客户端里实装;2) 实装里有 3P 通用抽象层遗留的 endpoint 拼装错误。

6 月中下旬:Claude Code v2.1.152 起,主干里多了 CLAUDE_CODE_USE_FOUNDRY 特性开关。但同期 issue #62894 在 Ubuntu WSL 上把它完整跑通后,发现子代理流程会失败——Claude Code 自动给进程注入 CLAUDE_EFFORT=high,子代理会把它翻译成 effort API 字段传给 Azure Foundry,Azure Foundry 不支持这个字段,直接 400。Anthropic 的处理是该 issue closed not planned——这是非常清晰的官方信号:Foundry 路径上子代理掉 effort,目前没打算修。

7 月上旬:Microsoft Foundry 目录正式把 Claude 模型档列出来——实测目录页可见的 4 档:claude-sonnet-5、claude-opus-4-8、claude-mythos-5、claude-fable-5(全部 Messages API 类型),跟 claude-sonnet / claude-opus 别名正好对齐。同期 Foundry 专属 7 个 issue(6 Open + 1 Closed Not planned)集中浮现。

7-4 晚:@israfill 在 X 把 CLAUDE_CODE_USE_FOUNDRY=1 + ANTHROPIC_FOUNDRY_RESOURCE + ANTHROPIC_FOUNDRY_API_KEY 三行 env var 串成 30 秒可复制的教程,首次把 Foundry 旁路玩法从 GitHub issue 区带进中文社区算法流。

双供应商 fallback 是这条路径真正的运营价值

把视角从技术细节拉到企业运营视角,值得追问的是这条路径的真正运营形态——单 Foundry 模式 vs 双供应商 fallback 模式。

单 Foundry 模式:Claude Code 完全只配 CLAUDE_CODE_USE_FOUNDRY=1 + Foundry 鉴权,所有调用走 Azure Foundry。好处是企业发票摊销和成本中心治理;坏处是 Foundry 专属 7 个 issue 中 Not planned 的 #62894(子代理 effort)+ Open 的 #63358(Opus thinking block)+ 旁系 Open 的 #65585(auto-compact)三档高级特性会 silently downgraded,生产环境上 Opus 跑 thinking 会拿到空块、子代理流程直接 400、长会话压缩失效。

双供应商 fallback 模式:Claude Code 同时配 ANTHROPIC_API_KEY(Pro/Max)和 ANTHROPIC_FOUNDRY_API_KEY + CLAUDE_CODE_USE_FOUNDRY=1,通过环境变量手动切换。理论上能跑——Anthropic API Key 模式跑日常 5 小时内任务(高级特性完整),Foundry 模式跑 5 小时外重型任务(以基础对话 + 基础工具调用为主)。issue 区目前没有这个双配置验证,但 @israfill 的教程暗示 fallback 模式是中文社区实操的真实需求。

双供应商 fallback 模式的核心张力:日常任务在 Anthropic 1P 路径上,重负载溢出到 Foundry 3P 路径上——这条架构实质上是把「5 小时墙」从「硬墙」变成「软墙 + Foundry 配额池补充」。但 Foundry 配额池在企业大规模调用 Claude Code 时,可能从「软墙」变成新的「硬墙」——Azure Foundry 的 TPM/RPM 是按订阅 Enterprise Agreement 的配额池配置的,Foundry 专属 7 个 issue 综合叠加,真实生产环境可能在月底配额打爆时爆出新一类账单 Spike,比 Pro/Max 的「周末 5 小时用完」模式更难诊断。

商务侧的真实含义:换发票比换速率重要

把视角从技术文档拉到企业采购视角,Anthropic 选择「无声明 + Not planned」的处理方式,是给双方都留余地:

  • Anthropic 没正式宣告 Foundry 路径 — 意味着官方不背书 SLA、不承诺子代理 / Thinking block 这类高级特性在 Foundry 上能跑。
  • Microsoft 没主推这条路径 — 意味着 Azure 配额模型不针对 Claude Code 调优。
  • 两边的克制客观上把 Foundry 路径定位成「企业用户自助式 enabled」 — 能用,但出问题没有窗口可找。

这跟 GitHub Actions+Codespaces、OpenTelemetry+Datadog 这类「免费层当漏斗、SaaS 层当变现」组合的本质差别在于:Foundry 路径目前两个厂商都还没正式定价,所以连「免费层 → 付费层」的转化漏斗都没搭起来。

对中文企业市场,这条路径短期最大意义不是「免费多打几次 Sonnet 5」:

  1. 5 小时墙的本质是消费级速率设计,不是工程瓶颈。Anthropic 在 Pro/Max 套餐外硬卡 5 小时窗口是产品决策,不是 Claude Code 跑不动——Claude Code v2.1.152+ 主干里早就写好了「切去 Foundry」的代码路径,说明 Anthropic 是知道 Foundry 能跑通的。问题是这条路径目前不属于任何官方 sales motion——找不到 enterprise 销售 push、找不到 docs、没有 SLA 承诺。

  2. Azure Foundry 路径的真实买点不是「无限配额」,而是「换发票+换成本中心」。Anthropic Pro 信用卡月付在中大企业内没法走 IT 报销;Azure Foundry 走 EA 月度发票,资源组 / tagging / cost allocation 全可以用上。这条路径对中文大客户最大的实际价值,是把 Claude 模型调用从「个人卡消费」切到「企业财务链路」——Claude Code 5 小时墙是否还存在,远没有发票能报销重要。

  3. 从今天起 Claude Code 试点可以直接放进已批下来的 Azure 配额池做 PoC,而不需要等 Anthropic enterprise 销售回邮件。对中文 IT 决策者,这是 2026 年下半年 Claude 模型扩散到中文企业的最快漏斗。

早报观点

这条路径的重心在 Anthropic 与 Microsoft 的模型分发合作深度。Claude Code 主干里写入了 CLAUDE_CODE_USE_FOUNDRY 开关,Azure Foundry 目录上架 4 档 Claude 模型;这更像双方在企业市场层面签定级别的合作底盘,而不是一次偶然泄漏的 hack。只看技术会低估它,只看定价又会高估它。真正值得追问的是:Anthropic 什么时候会在 enterprise sales 端正式 push 这条 Foundry 路径,以及 Microsoft 会不会把「Claude on Foundry」做成 Azure OpenAI 之外独立计费 SKU。

更深层的判断是: Foundry 路径短期最大隐患在「官方不背书 SLA」这个隐性成本。这 7 个 issue 里 #62894 子代理 effort 是 Not planned,#63358 Opus thinking block 是 Open,#65585 auto-compact 自 v2.1.161 起对 3P 失效。这意味着企业真把生产负载搬到 Foundry 路径上时,会发现「Claude Code 的高级特性至少有三档 silently downgraded」。这类问题靠 patch 解决不了,它反映的是官方对 Foundry 路径的支持度天花板。企业 IT 真要做决策,需要把 Foundry 路径按「Claude Code 的有限功能集(基础对话 + 基础工具调用)正常运行,高级特性(opus thinking / subagent effort / auto-compact)等待官方支持」来定价,而不是按「完整 Claude Code」来定价。

另一个容易被忽视的角度:这条路径把「企业级 Claude 接入」从「签 enterprise 合同 + 走 Anthropic 法务」降维到「开 Azure 订阅 + 在 resource group 里加一个 Foundry 资源」。后者对中文大客户的 IT 团队而言,意味着 Claude Code 部署不再需要走 6-12 个月的 enterprise sales 流程。对中文 IT 决策者真正重要的是:从今天起,可以把 Claude Code 试点直接放在已经批下来的 Azure 配额池里做 PoC,而不需要等 Anthropic enterprise 销售回邮件——这是 2026 年下半年 Claude 模型扩散到中文企业的最快漏斗。

反面 caveat:Foundry 路径目前完全没有官方 SLA、没有 enterprise 销售管线、没有 docs,这意味着 「Foundry 真出问题时,Anthropic 和 Azure 双方都可能说不归我管」。中文大客户真要把生产负载搬到 Foundry 上,需要先想清楚一件事:出问题找谁?Anthropic 这个开关在主干里,Azure 配额池可以打发票,但责任链目前是空白。Foundry 专属 7 个 issue 中 #62894 已显式 Not planned,#63358 / #64677 等 6 个 Open 短期不会集体修复——这条路径目前仍更适合「PoC / 内部工具 / 非关键生产」场景,真正承担 SLA 的工作负载上 Foundry 还需要至少一个季度的官方背书累积。

跟踪节点

  • 7-12 前:Anthropic 官方 docs 是否补出 CLAUDE_CODE_USE_FOUNDRY 完整 endpoint 规范。如果仍未更新,意味着 Foundry 仍是「用户自助式 enabled」,出问题时官方不会背书。
  • 7 月底:Microsoft Foundry 是否公示 Claude 模型的 per-1k-tokens 定价。这决定了 Foundry 路径 vs Pro/Max 订阅的真实 ROI。
  • Claude Code v2.1.180+:是否合入对 Foundry effort 参数的兼容或显式 Not planned。若后者,Foundry 专属 7 个 issue 中 Not planned 的 #62894 会继续维持,Foundry 上子代理流程短期内仍不可用。
  • 中文社区实战教程:7 月内是否出现「Foundry 旁路 + Pro 订阅并用」的双 fallback 教程,这会验证双供应商模式的可生产性。
  • Azure 配额池打爆事件:中文大客户真把 Claude Code 大规模跑 Foundry 后,月底是否会出现 TPM/RPM 打爆导致账单 Spike——这会成为 Foundry 路径在企业内的第一场真实事故。