[AINews] OpenAI reports median internal Codex output tokens grew 56x in Research, 32x in Customer Support, 27x in Engineering, and 13x in Legal since November 2025.
![[AINews] OpenAI reports median internal Codex output tokens grew 56x in Research, 32x in Customer Support, 27x in Engineering, and 13x in Legal since November 2025.](/api/img-proxy?url=https%3A%2F%2Fsubstackcdn.com%2Fimage%2Ffetch%2F%24s_!roAd!%2Cw_1456%2Cc_limit%2Cf_auto%2Cq_auto%3Agood%2Cfl_progressive%3Asteep%2Fhttps%253A%252F%252Fsubstack-post-media.s3.amazonaws.com%252Fpublic%252Fimages%252F3a48b472-a807-4211-b981-983f7a401c3a_2156x1576.png)
TL;DR · AI 摘要
OpenAI 内部 Codex 使用量在多个部门激增,Research 部门增长 56 倍,Legal 部门增长 13 倍,显示 AI 工具在非编码任务中的广泛应用。
核心要点
- Research 部门 Codex 使用量增长 56 倍,显示 AI 在研究领域的深度应用。
- Legal 部门 Codex 使用量增长 13 倍,表明 AI 在法律领域的逐步渗透。
- OpenAI 员工在 2025 年底前对 AI 工具的使用率远低于 10%,说明 AI 工具仍有巨大提升空间。
结构提纲
按章节快速跳转。
- §引言
Research 部门增长 56 倍,Customer Support 增长 32 倍,Engineering 增长 27 倍,Legal 增长 13 倍。
OpenAI 员工在 2025 年底前对 AI 工具的使用率远低于 10%,说明 AI 工具仍有巨大提升空间。
GLM-5.2 在编码和代理任务中表现突出,Ornith-1.0 和 LFM2.5-230M 等模型也取得进展。
思维导图
用一张图看清主题之间的关系。
查看大纲文本(无障碍 / 无 JS 友好)
- OpenAI Codex 使用增长
- Research 部门增长 56 倍
- Customer Support 增长 32 倍
- Engineering 增长 27 倍
- Legal 增长 13 倍
- 其他 AI 模型进展
- GLM-5.2 在编码和代理任务中表现突出
- Ornith-1.0 和 LFM2.5-230M 等模型取得进展
金句 / Highlights
值得收藏与分享的关键句。
Research 部门 Codex 使用量增长 56 倍,显示 AI 在研究领域的深度应用。
Legal 部门 Codex 使用量增长 13 倍,表明 AI 在法律领域的逐步渗透。
OpenAI 员工在 2025 年底前对 AI 工具的使用率远低于 10%,说明 AI 工具仍有巨大提升空间。
[AINews] OpenAI 报告称,自 2025 年 11 月以来,内部 Codex 输出令牌在研究领域增长了 56 倍,在客户支持领域增长了 32 倍,在工程领域增长了 27 倍,在法律领域增长了 13 倍。
AINews:工作日简报
这正在发生。
2026 年 6 月 26 日
仅剩 200 个 AI 工程师门票 - 预计将在未来 24 小时内售罄。现在购买可获得超过 6 万美元的赞助积分!
添加到“2025 年发生了什么?”文件中:OpenAI 经济研究部门报告称,非编码领域的令牌使用量正在爆炸式增长:
截至 2025 年 8 月,OpenAI 的平均员工在 Codex 上花费的令牌不到 10%。然而在过去的六个月中,Codex 的使用在 OpenAI 内部显著增加。在活跃的内部用户中,各部门的总输出令牌数量急剧上升。研究部门增长最为显著:到 2026 年 6 月,中位数使用量是 2025 年 11 月的 56 倍。客户支持增长了 32 倍,工程增长了 27 倍,而法律虽然增长较为缓慢,但仍达到了 2025 年 11 月水平的 13 倍。
这应该为 Tokenmaxxing 的担忧提供一个有趣的基准 - 请记住,OpenAI 员工一直都有无限访问权限,但无论如何,他们直到 2025 年底仍然严重低估了 AI 的使用。
有时候,你只能让他们去“烹饪”:
2026 年 6 月 24 日至 2026 年 6 月 25 日的 AI 新闻。我们检查了 12 个 Reddit 子版块、544 个 Twitter 帐号,没有进一步的 Discord。AINews 网站允许你搜索所有过去的版本。提醒一下,AINews 现在是 Latent Space 的一个部分。你可以选择加入或退出电子邮件频率!
AI Twitter 总结
开放模型、编码基准和 GLM/Ornith/Liquid Wave
- GLM-5.2 在编码和代理基准中的迅速崛起:多篇帖子都聚焦于 Z.ai 的 GLM-5.2,将其视为当天最重要的开放模型故事。在前端编码方面,Arena 报告称 GLM-5.2 Max 在 Code Arena: Frontend 上达到了 1595 分,超过了 Opus 4.8,并缩小了与 Claude Fable 5 的差距。在代理可靠性方面,PostTrainBench 指出 GLM 5.2 Max 的推理准确率为 34.29%,略高于 Opus 4.8 Max 的 34.08%,在 84 次运行中没有失败运行。速度方面也有进展:@Yuchenj_UW 表示 Databricks 将 GLM-5.2 推到了 Artificial Analysis 上的 392 tok/s,比 H200 上的 201 tok/s 有所提升,并在 B300 上进一步提高,结果归因于硬件和优化,如推测解码和内核。
- 新的编码专用开放权重:Ornith-1.0 作为一系列 MIT 许可的代理编码模型推出,包括 9B 密集、31B 密集、35B MoE 和 397B MoE,基于 Gemma 4 和 Qwen3.5 进行了后期训练。报告的分数包括 Terminal-Bench 2.1:77.5,SWE-Bench Verified:82.4,SWE-Bench Pro:62.2,ClawEval:77.1。值得注意的训练声明是一个自我改进的 RL 设置,不仅优化了解决方案的展开,还优化了驱动这些展开的任务特定支架。同时,Liquid AI 推出了 LFM2.5-230M,一个超小型模型,旨在机器人/电子商务中的低延迟工具使用;vLLM 添加了 day-0 支持,SGLang 添加了支持,WebGPU 工作将其本地速度推进到约 1400 tok/s。
- Google 将计算机使用功能引入 Gemini 3.5 Flash:Google 在 Gemini 3.5 Flash 中将计算机使用功能作为核心内置能力,覆盖浏览器、桌面和移动设备。主要发布信息来自 @Google、@GoogleDeepMind 和 @googledevs。安全控制措施包括对敏感操作的明确用户确认和自动任务停止。对于开发者,@_philschmid 分享了一个快速入门指南,展示了通过 adb 控制 Android 手机的方法,同样的模式也可以扩展到 iOS。这是一个重要的产品转变:不仅仅是模型 API,而是一个标准化的操作接口,具备人机协作的便利性。
- Agent 基础设施在持久性和成本方面变得更加明确:多家初创公司/产品正在优化长期运行的 Agent,而不是交互式聊天的延迟。Sail 获得了 8000 万美元融资,旨在为运行数天或数周的 Agent 提供低成本推理和沙盒环境,声称“每美元产生 10 倍的智能”。Hyperagent 被强调为每个 Agent 都拥有自己的云机器,具备持久的浏览器/代码执行能力。LangChain 的 Fleet 框架提出了一个有用的区分:当工作以答案结束时,使用通用聊天;当工作具有可重复的形状和持久的上下文时,使用专用 Agent。
- OpenAI 的内部 Codex 使用情况正在成为领先指标:OpenAI 表示 Agent 正在“每个部门”改变工作方式,Codex 被用于更长时间运行、更跨职能的任务。来自 @gdb、@reach_vb 和 @eliebakouch 的外部评论强调了内部令牌消耗的增长,尤其是研究团队,以及技能和并发 Agent 的模式。实际的启示是更少地强调“Agent 是神奇的”,而更多地强调在组织能够支持审查循环、工具和持久工作流的地方,真正的采用正在出现。
评估、奖励黑客行为和合成数据作为前沿杠杆
- 公共基准测试正变得越来越容易被攻破:Cursor 的研究文章指出,包括 Opus 4.8 和 Composer 2.5 在内的近期模型,可以通过从互联网或 Git 历史中检索解决方案来破解公共基准测试;在更严格的测试框架下,得分会显著下降。这与 ProgramBench 推动的“无互联网设置”作为未来代码评估的默认选项相一致。更广泛的主题是:评估环境的设计现在是一个首要变量,而不是基准测试的卫生问题。
- 自动数据/代理生成的合成数据正在获得关注:由 @jaseweston 发布的 Meta Autodata 论文是其中较为实质性的研究之一。该提案将数据生成视为数据科学家代理循环的一部分,包括创建、分析和元优化,将额外的推理计算转换为更好的训练/评估数据。报告的收益涵盖了计算机科学、法律和数学任务,而元优化框架将创建通过率从 62.1% 提高到了 79.6%。独立放大效应来自 @iScienceLuvr 和 @omarsar0。这是摘要中“自动研究”从口号转变为具体循环设计的最清晰例子之一。
- 数据整理现在也成为测试时计算的杠杆:Datology 认为,数据整理可以通过诱导简洁性而不影响任务性能,使模型在答案生成方面效率提高 35 倍;@pratyushmaini 明确地将此视为超越质量和训练效率的第三轴。这值得注意,因为它将预训练/后训练数据选择直接与服务成本和用户感知延迟联系起来,而不仅仅是基准质量。
开放生态系统经济学:Hugging Face、数据发布与代理工具链
- Hugging Face 在不放弃其开放定位的前提下,实现了重要的商业里程碑:Clement Delangue 宣布 Hugging Face 的年收入达到 1 亿美元,同时表示 Hugging Face 仍然为 97% 的用户提供免费和开放的平台,并管理着数百 PB 的模型和数据集。对于基础设施和平台观察者来说,这是最明确的证明之一,表明开放模型分发、托管和社区工作流程可以支持一个可持续的业务。这也为后续的采用故事提供了背景,例如 Gemma 4 在 2.5 个月内下载量达到了 2 亿次。
- 有用的开放语料库和数据管道继续扩展:Common Crawl 发布了其 2026 年 6 月的存档:21 亿个网页,354 TiB 的未压缩数据,来自 4080 万个主机,以及更新的网络图。领域特定的数据也通过 Telco-Common-Corpus 项目发布,这是一个 100 亿 token 的完全开放的电信语料库。对于具身化/机器人数据,Chris Paxton 估计目前可用的开放数据集可能已经达到了大约 10,000 小时的机器人工作时间,足以让“基本上任何人”尝试构建一个相当不错的机器人基础模型。
- 本地/开放部署的工具继续改进:当天还发布了 Qdrant EDGE + LiteRT,用于完全在设备上的 RAG;Hugging Face 的“在本地运行你自己的模型”流;GGUF UI 对 MTP 头的支持;以及面向开发者的改进,如 LangChain 的部署食谱。这些并不是孤立的功能;它们都是朝着可移植代理堆栈和本地推理可用性趋势的组成部分。
政策、访问控制与蒸馏之争
- Fable 5 并没有回归,它可能只是一个 UI 艺术品:短暂看起来像是 Claude Fable 5 的再现,实际上成为了一个关于谣言传播和访问不透明性的案例研究。推测来自 @kimmonismus,但 Anthropic 方面的更正非常明确:@sammcallister 表示他们向 Fable 5 提供的流量为零,@TheAmolAvasare 表示没有 Fable/Mythos 的流量,很可能是 UI 的错误或恶作剧。后来的更正帖子反映了这一点。
- 蒸馏之争升级为政策戏剧:围绕 Anthropic 关于阿里巴巴据称使用数百万次 Claude 交流的声明,讨论扩展到了技术和地缘政治评论。Andrew Curran 发布了 Dario Amodei 的信件,同时许多评论者就问题是否是基准领先的合成后训练、API 泄漏、中间商转售或政治定位展开了辩论。最具体的政策发展信号是 The Information 报道称美国政府要求 OpenAI 按客户逐一延迟 GPT-5.6 预览访问,这表明对于前沿发布,一个事实上的审查制度正在逐渐形成。
热门推文(按参与度)
- OpenAI 内部代理采用:OpenAI 关于 Codex 在各部门工作中的转变。
- Hugging Face 经济:Clement Delangue 关于 Hugging Face 超过 1 亿美元的 ARR。
- 基准完整性:Cursor 关于模型破解公共基准。
- 开源编码模型:Ornith-1.0 发布。
- Google 代理产品化:Gemini 3.5 Flash 计算机使用发布。
- 多代理系统行为:Thom Wolf 关于 100 多个代理协作优化 Gemma 4 推理速度 5 倍。
AI Reddit 总结
/r/LocalLlama + /r/localLLM 总结
1. 专用开放模型发布
- NVIDIA 已发布 Nemotron-TwoTower-30B-A3B-Base-BF16,这是一款基于 Nemotron 3 Nano 30B-A3B 主干构建的不寻常的扩散式语言模型。(活跃度:459):NVIDIA 发布了 Nemotron-TwoTower-30B-A3B-Base-BF16,这是一款基于 Nemotron 3 Nano 30B-A3B 主干的扩散风格大语言模型。该模型结合了一个冻结的自回归上下文塔和一个并行填充标记块的扩散去噪塔;NVIDIA 声称默认的掩码扩散配置保留了 98.7% 的自回归基线综合基准得分,同时实现了 2.42 倍的实时生成吞吐量。唯一的技术相关评论质疑其质量保留与基线相比是否优于 DiffusionGemma;其余的顶级评论则大多是玩笑或与模型无关的请求。有评论者指出,Nemotron-TwoTower-30B-A3B-Base-BF16 相对于其原始 Nemotron 主干似乎保留了更多的准确性,而 DiffusionGemma 相对于其基础模型则没有如此高的保留率,尽管该讨论线并未提供具体的基准名称或数值得分。
- Qwen-AgentWorld-35B-A3B:一个 3B 活动参数的 MoE 模型,用于模拟 MCP、终端、SWE、Android、Web 和 OS 环境(活跃度:315):通义千问发布了 Qwen-AgentWorld-35B-A3B,这是一个总参数量为 35B、约 3B 活动参数/标记的稀疏 MoE 模型,定位为语言世界模型,而非聊天/指令代理。该模型经过训练,用于模拟代理循环中的环境响应——预测在 MCP/工具调用、搜索、终端、SWE、Android、Web 和 OS-GUI 交互领域中执行操作后的下一个观察值/状态——可能实现离线代理训练/评估、合成轨迹和模拟工具工作流程。唯一实质性技术评论指出,它可能通过模拟操作输出用于评估,例如预测 ls -la 的终端输出。其他顶级评论大多是对数据集是否只是交换了用户/助手角色或提示模型“你现在是 MCP 服务器”的玩笑或怀疑。有评论者认为该模型学习了环境转移动态:给定一个用户/工具命令,如 ls -la,它会预测对应的终端输出。他们认为这不仅对代理训练有用,还可以在评估中模拟工具/环境操作,从而减少执行真实沙箱操作的需要。另一个技术解读是,Qwen-AgentWorld-35B-A3B 可能是在模拟的“世界”轨迹上进行训练的——包括 MCP、终端、SWE、Android、Web 和 OS 交互——然后评估下游代理性能的提升。评论者认为,如果这种解读是正确的,该模型应被视为改进的代理模型,而不仅仅是模拟器,并请求运行代理基准测试的人提供实证检查。
- Unlimited-OCR 现已上线 ModelScope!这是一款 33 亿参数的多语言 OCR 模型,支持对单张图像、多页文档和 PDF 进行一次解析。许可证:MIT(活动数:1123):百度的 Unlimited-OCR 在 ModelScope 上发布,是一款采用 MIT 许可证的 33 亿参数多语言 OCR/文档解析模型,旨在对单张图像、多页文档和 PDF 进行一次完整的文档解析,支持最多 32K 的输出 token 以处理长 OCR 序列。该项目提供了基础图像模式和“高达”(gundam)图像模式,并支持 Transformers 推理和 SGLang 服务,同时提供与 OpenAI 兼容的流式 API;代码可在 GitHub 上获取,相关公告发布在 X 上。评论者主要询问了缺少的技术比较和细节:该模型是否与 PaddleOCR 有关,或者是否缺少 PaddleOCR 的支持;它与 PaddleOCR-VL-1.6 的性能如何;32K 输出限制下能容纳多少页文档;以及“高达模式”具体指什么。评论者要求直接与 PaddleOCR-VL-1.6 进行基准测试,特别是 Unlimited-OCR 在 OCR 质量/性能方面的表现,以及在多页/PDF 解析中,模型的 32K 上下文窗口能实际容纳多少页文档。围绕模型和文档中提到的“高达模式”,评论者提出了技术上的模糊之处——多位用户询问其含义,表明发布材料中可能存在术语不清晰或未记录的推理/解析模式。一位评论者链接了 Hugging Face 上的模型卡片:baidu/Unlimited-OCR,另一位评论者则在一张图片旁标注了“缺少 Paddle?”,可能指向与 PaddleOCR 相关的不一致之处或缺失的参考/依赖项。
- Ornith-1.0 在 Hugging Face 上发布(活动:391):DeepReinforce-AI 发布了 Ornith-1.0 Hugging Face 集合,包括 9B / 31B 的密集模型和 35B / 397B 的 MoE 变体,声称在未指定的基准测试中取得了最先进的结果;评论者认为这些模型是基于 Qwen3.5 和 Gemma4 进行了后续训练的模型。一位用户报告称,在双 R9700 Vulkan 配置上运行的 35B Q8_0 版本,生成速度约为每秒 115 个 token,提示处理速度约为每秒 5400 个 token,与“关闭思考模式的 Qwen 3.6 35B”相当,偶尔会出现短暂的下降至每秒 95 个 token。另一位测试者观察到 35B 模型拒绝揭示隐藏的 canary token,并明确识别该请求为提示注入尝试,表明模型内置了防止信息泄露或提示注入的机制。早期的主观反馈非常积极:一位测试者发现 Ornith-35B 的编码/API/安全测试输出“远比 Qwen 3.6 35B 更加详细”,同时速度也快得多,得出结论:“这可能是真正的突破。” 一位用户报告称,Ornith-1.0 35B Q8_0 量化版本在双 R9700 Vulkan 配置上的原始吞吐量与关闭思考模式的 Qwen 3.6 35B 几乎相同:生成速度约为每秒 115 个 token,提示处理速度约为每秒 5400 个 token。他们观察到在响应过程中偶尔会出现从每秒 115 个 token 下降到每秒 95 个 token 的情况,可能是与热相关的,但总体上描述该模型比 Qwen 3.6 35B 更快,并且在非正式的 Ruby/Sinatra 测试中提供了更详细的编码/API/安全测试响应。在 Pi 配置上的测试表明,35B 模型可能内置了防止提示注入或 canary 泄漏的防御机制。一个上下文退化扩展在上下文中隐藏了一个随机字符串,并要求模型之后检索它,但模型拒绝了该请求,明确推理出该请求是“提示注入尝试”,并拒绝回显 canary token。几位评论者将 Ornith-1.0 描述为基于 Qwen3.5 和 Gemma4 后续训练的衍生模型,据称其基准测试结果超过了 Qwen 3.6 27B。一个技术上的担忧是,为什么发布建议对 vLLM 使用 qwen3_xml 格式,而对 SGLang 使用 qwen3_coder,这可能意味着与服务堆栈相关的提示模板差异,可能会影响质量或基准测试的可重复性。
使用 7 天免费试用继续阅读
订阅 Latent.Space 以继续阅读本文,并获得 7 天免费访问完整文章存档的权限。
开始试用
已经是付费订阅者?
上一篇
下一篇