OpenAI将取消ChatGPT无限对话,与Codex用量合并
来源标题:I Am the Reason OpenAI Is Killing Unlimited Chats
OpenAI宣布将取消ChatGPT的无限对话,并把其用量与Codex合并计算。此前有开发者借助自定义MCP服务器和Secure MCP Tunnel,让普通ChatGPT对话就能完成检查仓库、改代码、运行命令和调试等开发工作,从而避开Codex额度限制。
以下正文由 AI 翻译自 Hacker News(原文版权归原站所有),可能存在偏差,重要内容请以原文为准。
好吧,大概不是。但看我拿ChatGPT干的这些事,我能理解他们为什么想这么做。
OpenAI最近宣布了调整,将取消无限ChatGPT对话,并把用量与Codex合并计算。我此前一直用来做开发的那种无限对话,之后就不会再是同样的用法了。
过去几个月,我基本上把所有软件开发工作都放在无限量的ChatGPT对话里完成,完全没有消耗Codex的额度。
ChatGPT对自定义MCP服务器的支持,加上OpenAI的Secure MCP Tunnel,让我可以把运行在自己机器上的工具直接暴露给普通的ChatGPT对话。
我在Windows笔记本上搭了一个统一的MCP服务器,在VPS上也做了类似配置,并集成了一些开源项目:
突然间,普通ChatGPT对话就能完成我以前用Codex做的大部分实际开发工作。
它们可以查看仓库、修改代码、执行命令、调试错误,并直观地验证改动。
下一个难题是让我本地的MCP服务器能被ChatGPT访问。
OpenAI提供了Secure MCP Tunnel,事实证明这正是我需要的。
我通过隧道连接了统一的MCP网关,用API key完成认证,把MCP工具直接暴露给ChatGPT。
不需要为了把ChatGPT接到我的笔记本上而专门搭建云端基础设施。
隧道和MCP集成不需要额外的付费API推理调用。我用的是开源工具、OpenAI提供的隧道工具、已有的ChatGPT订阅,以及本来就有的电脑。
01 / 连接架构 一条私有MCP连接,多种本地能力。ChatGPT普通对话Secure MCP TunnelOpenAI托管的隧道客户端运行在我的电脑上工具调用HTTPS本地MCP进程统一MCP网关Node.js路由/工具聚合Desktop Commander文件·代码·终端·测试Enhanced TryCua屏幕·鼠标·浏览器·UILocal后端工具也可以托管在我的VPS上。连接架构。
我改进了这套集成 当然,等一切跑通之后,我就忍不住开始折腾这些工具本身了。
我对CUA集成做了几项增强,改善ChatGPT与我电脑的交互方式,以及结果在对话中的呈现。
一个例子是让实际截图直接显示在ChatGPT里。
以前截图工具返回的结果ChatGPT能看,但我自己不容易看到;于是我加了对自定义MCP App查看器的支持,把抓到的截图显示出来。
我还改进了工具调用结果的处理方式,让我在ChatGPT对话里读起来更轻松。
03 / 我的增强 一些小改动,让底层工具更实用。基础MCP工具Desktop Commander·CUAS截图查看器抓到的屏幕在ChatGPT内可见可靠的工具结果图像边界·一致的错误监控与控制实时日志·健康状态·CPU/内存更好的体验真实工作流自定义工具集成。
我有趣的小AI开发工作流 由于ChatGPT对话无法创建或控制子对话/子代理,为了做多代理开发和编排,我不得不动点脑筋。
02 / 工作流高级规划。独立的GitHub issue。多个Sol High工作者。Astra/Pro模型系统设计与规划GitHub issue小而明确的任务并行工作者池独立的ChatGPT对话Sol High·Chat AIssue 1Sol High·Chat BIssue 2Sol High·Chat CIssue 3Sol High·Chat DIssue 4共享MCP访问读取·编辑·跑测试·检查结果规划与并行执行。
我会先用一个更强的推理模型,比如Codex里的Astra,或者ChatGPT里有限额的Pro模型,让它制定一份详细的实现计划。
然后我让它把计划拆成更小、定义清晰的GitHub issue。每个issue都包含足够的上下文、需求和验收标准,另一个AI代理可以独立接手。
本质上,我是把一个大开发任务变成了一队小任务。
接着我会开几个独立的ChatGPT对话,每个都跑Sol 6 High,给它们分配不同的issue。
因为这些对话都能访问我的MCP服务器,它们可以真正动手改代码。
它们能读项目、改文件、跑测试、检查错误,反复迭代直到分配的任务完成。
而且在当时,我用Sol High对话不会撞上在Codex里遇到的那种用量限制。
当然,Sol High比高级模型慢,但用量实际上无限时,我愿意忍。
我会让多个对话同时处理不同任务,把更有限的高级模型额度留给架构、难题决策和评审。
这套做法并不完美。并行代理共享文件系统需要协调,偶尔某个issue需要更强的模型介入。
但对于定义明确的编码任务,它效果好得出奇。
我实际上是把ChatGPT当成一个编码代理池,用GitHub issue当任务队列。
我还搭了一个非常轻量的界面,可以启动或停止整个MCP连接、监控服务器健康状态、跟踪CPU和内存使用,并查看工具调用的实时流。
我能看到ChatGPT何时读文件、执行命令或调用computer-use工具。
面板还会跟踪失败情况,让我查看最近的活动。
天下没有不散的筵席,这件事也一样。它要消失了,我挺难过。
无限对话是唯一让我留在OpenAI订阅上的原因。我个人更偏爱Claude模型,打算转过去了。尤其是Claude Opus,在我的使用场景里似乎聪明得多,而且Claude订阅比Codex订阅更经用。
说清楚一点,我没有违反任何规则。
(原文较长,此处译出前 6000 字,完整内容请点「打开原文」。)
正文由 探How 从来源站点 RSS 同步,内容未经改写;遇到排版缺失或需要图片、视频时请以原文为准。