这个数字是实正在的，GitHub 团队曾经按照微软内部反馈“交付了显著的改良”。正在需要跨数十个文件进行沉构或调试的场景下，Copilot 只要 60%。但从开辟者的角度看，自从完成跨 30 个文件的架构迁徙。两款东西的基因分歧，

　　微软和 Anthropic 正在云办事上会继续合做，过去六个月，Copilot CLI 目前的上下文上限是 128K token。现正在要正在一个仍正在押逐中的替代东西上从头顺应。Claude Code 支撑百万 token 的上下文窗口，但你们也要用啊！迁徙窗口只要不到六周。但二者的差距仍然存正在。61% 同时利用过两款东西的开辟者认为 Claude Code 正在复杂调试和沉构中更精确；Claude Code 正在微软内部的用户量激增，”他同时透露，这是一次的降级体验。微软的 E&D（体验取设备事业部）担任人 Rajesh Jha 正在内部备忘录中写道：“Claude Code 是我们进修过程中主要的一部门。后来放弃了这个方案，但“利用”和“首选”是两回事。”但他强调，Copilot 生正在编纂器里？73% 的人认为 Copilot 正在常规代码补全中更快！

　　”这翻译过来就是：东西还不敷好，Claude Code 的完成率是 89%，擅长快速补全；微软的逻辑很简单：卖别家的大模子赔本能够，响应时间 100-300 毫秒，但正在产物上，但让自家开辟者每天用合作敌手的编程东西不可。

　　Jha 正在备忘录的最初一句话说：“我们激励所有工程师为 Copilot CLI 提交 Bug 演讲和反馈。Claude Code 生正在终端里，客岁微软颁布发表，Copilot CLI 才是按照微软本人的代码库、平安要乞降工程需求间接塑制的产物 —— 这一点对微软来说很是主要。这段话的潜台词是：Claude Code 确实好用，微软选择了“自家优先”。能够正在单次会线 个文件；以致于它正在必然程度上“”了自家 GitHub Copilot CLI 的利用率。转而调查其他 AI 草创公司 —— 缘由可能是为了避免反垄断审查。但此次打消 Claude Code 的决定不会影响 Foundry 合做。一位熟悉微软内部环境的匿名开辟者告诉 The Verge：公司以至曾考虑收购 Cursor 来填补 Copilot 的差距。