OpenAI 新智能体栈：Computer Use、Decisions API 与 AI Cloud

Ari Weinstein

现在 Computer Use 完成任务的速度，在多数情况下大概已经快过普通人。我认为下一关是让电脑真正做出超人类表现——用软件的速度达到甚至超过我们这种老手。

Computers are now faster at completing tasks than the average person, probably in most cases. I think the next challenge is that computers will literally perform superhuman feats—handle software as fast or even faster than experienced computer users like us.

Ari Weinstein

一旦到那一步，会非常关键、也非常令人兴奋：我们突然就能做更实时的产品体验。就在四周前，这些还完全不在开发雷达上。

If that happens, it will be very consequential and exciting, because we’ll suddenly be able to develop products that offer much more real-time experiences. Four weeks ago, that wasn’t the case at all.

Vibhu

我们非常兴奋。今天是 OpenAI DevDay 特辑——直播后第一场播客。Ari 负责 Computer Use 智能体的产品与工程。先快速回顾：今天宣布了什么？

We’re very excited to be here. Today is OpenAI DevDay. Special podcast—first podcast after your livestream. We have Ari, who leads product and engineering for Computer Use agents. Quick recap: what was announced today?

Ari Weinstein

刚从 keynote 出来，Computer Use 相关的很猛。Dots 是新的个人助理产品，带很强的 Computer Use；GPT-6.1 Sol 成本和速度对 Computer Use 特别友好——我们分享过，相对 Astra 大约五分之一成本，若只看 Computer Use 大约七分之一。

We just got out of the keynote. Dots is the new personal assistant product with exciting Computer Use features. GPT-6.1 Sol is particularly great for Computer Use because of cost and speed—we shared it’s a fifth the cost of Astra and a seventh of the cost if you’re looking at Computer Use specifically.

Ari Weinstein

Agents API 现在也有 Computer Use 了，开发者可以搭和 Codex、ChatGPT 同一套实现。还有 App Shots：把你电脑上正在做的上下文快速带进 Codex / ChatGPT；以及 Mac 上原生 Computer Use——Roman 演示里它在截他的应用，而他还能同时干别的。

Agents API now has Computer Use, so developers can build on the same Computer Use that’s in Codex and ChatGPT. App Shots bring context from what you’re doing on your computer into Codex and ChatGPT really fast. And native Computer Use on Mac—Roman had it taking screenshots of his app while he did other things on his computer.

Swyx

还有 Decisions API。Computer Use 和 Decisions 是同一模型、同一数据蒸馏出来的不同形态，还是两套？

And not to mention the Decisions API. Off the bat—are they all the same model, or the same dataset distilled to different models? Is Computer Use using Decisions API, or are they kind of separate?

Ari Weinstein

Decisions API 很酷的一点是：并行推理、没有 reasoning、模型比 Computer Use 用的更小，所以非常快；但长程、复杂任务会弱一些。怎么把两套路径合起来，还是开放研究问题。

What’s cool about the Decisions API is it does inference in parallel, it doesn’t have reasoning, and it’s a smaller model than the ones we use for Computer Use—so those capabilities make it really fast. They’re also a little less good at long-horizon, sophisticated tasks. How we bring those approaches together is still an open area of research.

Vibhu

Dots 现在挂了个人电脑，看起来更持久。该怎么往极限推？我现在很多用来搞客服——不想登录、不想认证，就让它去搞定。

One of the interesting things is Dots now have attached personal computers—they seem much more persistent. How should people push the bounds? Personally I use it a lot for customer service—“I don’t want to sign in, I don’t want to authenticate”—find whatever and just get it fixed.

Ari Weinstein

每个 Dot 都能用自己的云端 Linux 虚拟机——以前多是云浏览器，或用你自己的电脑；现在是整台 Linux，可跑完整桌面应用，也能用浏览器。Computer Use 激动人心的地方在于：世界上软件都是为人设计的，智能体现在能用同一套软件，你就能把事委派出去。

Each Dot has access to its own Linux virtual computer in the cloud—different from a browser in the cloud or access to your own computer. You get an entire Linux computer that can run full desktop applications and a web browser. Computer Use is exciting because all software in the world was designed for humans, and now agents can use that same software, and you can delegate to the agent.

Ari Weinstein

我最近订了定制化很高的备餐服务，自己下单要两小时；让 Computer Use 用 GPT-6.1 Sol 做，十五分钟搞定——大约快八倍，也省了我两小时。这类任务特别有价值。

I subscribed to a meal prep service with high customization granularity. It took me two hours to place an order; I asked Computer Use to do it and it did it in 15 minutes on GPT-6.1 Sol—eight times faster, and it saved me two hours. Those are the kinds of tasks that feel really powerful.

Swyx

我作为创作者，头号用例是自动化 YouTube——很多能力没 API，只能丢进 VM：A/B 测试、社区帖之类。开发者体验团队也说常拿它对付 YouTube。

As a creator, my number one use case is automating YouTube—YouTube doesn’t expose a lot via API, so you put it in a VM for AB testing or community posts. I’ve heard from our developer experience team too—they use it with YouTube a lot.

Swyx

我有点辣一点：有一位很有影响力的 AI 播客朋友，说过 Computer Use 这两年几乎没进步。你怎么看进展？

I want to get a little spicy. One of the leading AI podcasts—our friends—is famous for saying Computer Use hasn’t advanced in the last two years. How have things progressed?

Ari Weinstein

他们大概几个月前说的；我希望现在看法不同了——Computer Use 和那时比，真是差了 180 度。

They said that a few months ago, I think, and I hope they have a different perspective now, because Computer Use is 180 degrees different than it was.

Swyx

你几乎整段职业生涯都在做电脑自动化：Apple Shortcuts、Sky，再到 OpenAI。主线是什么？过去做不到的，现在卡点在哪？

You’ve basically spent your whole career on some kind of computer automation—Shortcuts at Apple, then Sky, then OpenAI. What’s the through line? What wasn’t possible back then, and what were your milestones?

Vibhu

追问：从上周 Codex Computer Use 到今天，最大变化是模型、Dots，还是 harness？

Follow-up: what’s the major change from Codex Computer Use last week through today—model, Dots, or harness?

Ari Weinstein

主线一直是自动化，省下精细操作电脑的时间，去做更重要的事。回看 Sky：当时也在做 Computer Use，但模型弱太多。这一年模型能力飞跃。我看到的最大差是：以前能靠谱地开任务，但一出问题就挂；现在很会调试、会重试、会内省哪里通不通。

The through line is automation—save time operating a computer intricately and focus on what matters. Looking back at Sky, we were working on Computer Use and the models were so much less capable. In the last year they’ve become extraordinarily capable. The biggest delta: before they could reliably start tasks but then run into problems; now they’re really good at debugging, trying again, introspecting what is and isn’t working.

Ari Weinstein

领域本身也在前进：Computer Use 常常写代码——在 Codex 展开工具调用能看到，不只是一步一动作，而是写 JS，让电脑一次执行多步。还用更多多模态：截图、无障碍、Playwright，按任务切换。单日差异不如过去一两月大；Dots 里的 Computer Use 和新模型都很兴奋。

The field has moved forward too. Computer Use often writes code—expand the tool calls in Codex and you’ll see it’s not just one action at a time; it’s writing JavaScript the computer executes to perform many actions at once. We use more multimodal interfaces—screenshots, accessibility, Playwright—depending on the task. One day’s difference is less consequential than the past month or two. Computer Use in Dot and the new model are really exciting.

Vibhu

Keynote 里 Tejal 提到 Computer Use 速度大约 7×、若干基准也好很多。你们内部怎么度量？是 harness、模型还是后训练？

On the keynote, Tejal mentioned 7× improvements in Computer Use speed, better on a few benchmarks. How do you measure it internally—harness, model, or post-training?

Ari Weinstein

我们有很多套度量，对应不同 harness 配置；生产路径还有更多安全检查。不过无论怎么量，增益都相当一致——有时来自 harness，有时来自模型。GPT-6.1 在 Computer Use 上的性价比，甚至好过它相对 Astra 的基线成本改善，这点我特别开心。

We have a bunch of ways of measuring it across harness permutations. Production products have more safety checks configured differently by task. Regardless of how we measure, we find pretty consistent gains—sometimes in the harness, sometimes in the model. I was really excited that GPT-6.1 is even more cost-effective for Computer Use than its baseline cost improvement versus Astra.

Swyx

直播里你们在一起推 Pareto 前沿。有没有「啊哈」时刻——模型推 harness，或反向？

One visual I liked from the livestream was improving the Pareto frontier together with the harness. Any aha moments—model driving harness or the reverse?

Ari Weinstein

引入更多模态很有力。以前很多产品花大量时间滚动：截图→做事→「还得往下滚」→再截图。有了无障碍、直接 DOM 等，模型能看到整页或整个应用，还能写代码一次多步。大改进往往是很多小纸割伤叠起来的。

Introducing more modalities has been powerful. In the past a lot of products spent time scrolling—screenshot, try something, scroll to the next page of results, screenshot again. With accessibility and direct DOM access, the model can see an entire page or application and write code that does multiple steps at once. A lot of speed also comes from little paper cuts we have to introspect.

Swyx

App Shots 很多人以为只是好看的截图；其实你能驱动每个按钮，文本也是对模型友好的表示。

With app shots, people see a nice visual in Codex but may not get that you can drive each button and have each text in a very optimal representation.

Ari Weinstein

在 Codex 连按两次 Command 抓当前应用内容进对话；点附件右上角小按钮，能看到原始文本和无障碍表示。我们既要「倒出来」，又要 token 高效——这有点艺术。为人做的读屏无障碍技术，对 LLM 用电脑也极有帮助。

In Codex, hit the two Command keys to grab content from whatever app you’re in. Click the attachment and the tiny button top-right to see raw text and the accessibility representation. We’ve put work into dumping it out and making it token-efficient—there’s an art to it. Screen-reader tech invented for humans with accessibility needs is also really helpful for LLMs using computers.

Vibhu

很多人甚至不知道 App Shots：双击 Command，看起来像丢了张截图——其实是元数据、结构、一切。

A lot of people don’t even know app shots exist. Double-hit Command—it looks like a screenshot. No: it’s pulling metadata, code, everything.

Ari Weinstein

网页截图没有链接指向哪里；日历截图标题可能被截断。App Shot 给模型完整上下文，能做的事多得多。

A screenshot of a webpage doesn’t include where a link goes; a calendar screenshot may truncate event titles. An app shot gives the language model full context about everything, and that lets it do much more.

Vibhu

过去是截图—滚动—再截图；今天已能自动化很多。瓶颈是模型还是 harness？两年后会不会一跑数小时？

Screenshot–scroll–screenshot is where we were; today they can automate a lot. Bottlenecks—models or harnesses? In two years, do you see it running for hours?

Ari Weinstein

过去几个月团队做到的Crazy 点是：多数情况下 Computer Use 完成任务已快过普通人。下一前沿是字面意义上的超人类——用软件的速度达到甚至超过我们这种专家用户。那时产品会更实时，激活能也会下降，我们会默认把一些事交给智能体。

What’s crazy is that over the past couple of months Computer Use is faster at accomplishing tasks than the average human, probably in most cases. The next frontier is literally superhuman—as fast or faster than expert computer users like us. Then we can build much more real-time experiences, and lowering activation energy will make us default to agents for things we do manually.

Ari Weinstein

卡点分散在模型、推理、harness、表示。越快，就越被「操作本身」卡住——比如自动化 DoorDash，基准里不少时间其实在等网站加载。加载完成到触发下一步 LLM，延迟要压到极低，这本身是门统计科学；能事件驱动就事件驱动，但很多事件做不到。

There are paper cuts on the model side, inference, harness, and representation. As Computer Use gets faster, we’re bottlenecked by the speed of the operation itself—on doordash.com a non-trivial amount of benchmark time is waiting for the site to load. You want as little delay as possible between load finishing and triggering the next LLM action—itself a statistical science. When possible you want it event-driven; many event types can’t be.

Swyx

三四年前我们还不敢把 LLM 挂到网页和设备上；现在我让它配 DNS、付账单，成千上万刀的事 YOLO 丢给 Computer Use。

Three or four years ago we were scared of hooking LLMs to the web and our devices. Now I’m having it configure DNS, pay my bills—tens of thousands of dollars I’m just sending over and YOLO-ing with Computer Use.

Swyx

现在放进 API 了，想给开发者什么坑位提醒和技巧？

Now that you’ve released this in the API, what pitfalls or tips do you want to tell developers?

Ari Weinstein

我很兴奋 Computer Use 进了 Agents API。开发者要对接第三方网站和服务，Computer Use 有普适性。自己做 harness 也很好，但很难；我们在自己的 harness 上训模型，用分布内实现可能有速度、成本和准确率优势。

I’m really excited we brought Computer Use into the Agents API. Developers building apps that work with third-party sites need that universality. Building your own harness is great work but hard; we train models on our harness, so there may be a speed, cost, and accuracy advantage to the in-distribution one.

Ari Weinstein

大家还在建立信任。我们要靠可靠性、合适的安全检查、在付款等重大动作前征求同意，以及按任务只放开必要网站/应用，来逐步建立信任。欢迎试用 Agents API，有反馈告诉我们。

We’re still getting comfortable trusting this technology. It’s incumbent on us to build trust by being reliable, with the right safety checks, asking consent before consequential actions like payments, and only letting it access the sites or apps it needs. Try the new Agents API—we’d love feedback.

Vibhu

Dots 出现在 Slack、语音里；Roman 演示边改应用边截图反馈。Computer Use 怎么改写编码工作流？

With Dots you’re seeing it in Slack, voice—Roman’s example of change this app and send screenshots along the way. Any tips on Computer Use for coding workflows?

Ari Weinstein

我最喜欢、野外也常见的一类：让智能体测试它自己刚写的软件。以前 Codex 写完你还得当 QA；有了 Computer Use，可以闭合开发生命周期——智能体构建、再测试，到我手里往往已经能跑。我有时还在开发 Computer Use 本身，于是出现「Computer Use 智能体用着我的 Computer Use 智能体」的套娃，特别爽。

One of my favorite use cases—and one we see a lot—is Computer Use letting the agent test the software it has built. Traditionally Codex builds and you’re QA for the agent. With Computer Use you complete the SDLC: the agent builds and tests; by the time it comes to me it’s already working. Sometimes I’m developing Computer Use itself, so I have a Computer Use agent using my Computer Use agent—super powerful.

Swyx

我做了视觉 play-test skill，能抓到光看代码抓不到的设计问题；也适合一屏一屏克隆烂 SaaS，再交给 Codex 复刻。

I have a visual play-test skill that catches design issues you wouldn’t pick up from code alone. It’s also really good for cloning apps screen by screen—Computer Use drives everything, screenshots, notes it down, then clone with Codex.

Vibhu

Nikunj，你在 API 侧发了很多。先介绍自己，再讲 GPT-6 相关 API 亮点？

Nikunj, you shipped a lot on the API side. Introduce yourself and highlight API-side changes?

Nikunj Handa

我是 Nikunj，带 API 产品大概三年，一直在发模型：和后训练、研究紧耦合，再把能力暴露到 API。GPT-6 新能力里，首先是异步函数调用——Codex、Dots 里工具经常跑很久，不必卡住模型；可以踢出工具调用，继续跑、继续推理，再回来汇合。还有回合中途转向：推理过程中可注入消息，工具一结束就能塞进指令。

I’m Nikunj; I lead product for the API team—roughly three years—launching models, working closely with post-training and research, then exposing capabilities in the API. With GPT-6: first, async function calling—tool calls in Codex and Dots take so long you don’t have to pause the model; kick off a tool call, keep running and reasoning, then check back. Mid-turn steering: inject messages while the model is reasoning, so as a tool finishes you can put in instructions.

Nikunj Handa

API 的原则是：训进 harness、够好了再放进 API。很多能力靠几个月前上线的 WebSockets——双向通道，支撑异步工具、异步推理、注入消息（我说的是 GPT-6，不是 GPT Live）。

Our main goal in the API is to put things in once they’re trained into the harness and good enough. A lot of that is powered by WebSockets we launched months ago—bidirectional communication for async tool calling, async reasoning, injecting messages. This is not the GPT Live thing; I’m talking about GPT-6.

Swyx

这和 UltraFast 很搭——好像第一次在 API 里提供这种「前沿智力 × 极限速度」。

This pairs very well with UltraFast—for the first time ever available in the API: theoretical fastest speed at the frontier of intelligence.

Nikunj Handa

UltraFast 最有趣的是看推理团队用 Astra「开火」：一直跑着 Codex 智能体抠性能。前几个月重点是效率、压成本——Luna 价格砍了大约 80%，大量来自推理改进；现在转向「能跑多快」。WebSockets 最早是为 GPT-5.3 Codex Spark 上的，工具来回开销降很多。

The most fun part of UltraFast has been watching the inference team cook with Astra—Codex agents constantly squeezing performance. For a couple of months a lot was efficiency and cost—how we cut Luna price by like 80%, driven by inference improvements. Now they’ve shifted to how fast can we run. WebSockets first launched for GPT-5.3 Codex Spark; it really reduced overhead going back and forth with tools.

Swyx

大象：决策模型。我们是最早深聊 Jev 的播客之一。你们多快看到 Jev 就决定跟？

Elephant in the room: decision models. Decisions API. We were the first podcast to do a big Jev deep dive. How quickly did you see Jev and go?

Nikunj Handa

先给 Diogo 和 Jev 团队巨大 credit——启发了整块市场。用户在催，内部也说「我们需要更快的分类系统」。不想剧透 Dots 后续，但你会看到搭在 Decisions API 上的非常跟手的东西。OpenAI 有人被 nerd-snipe：「怎么做出来？我们不打算另训一个新模型。」

Huge props to Diogo and the Jev team for inspiring the whole segment. Users were hitting us up; internal teams said we need a much faster classification system. I don’t want to get ahead of some Dots features, but you’ll see really snappy things on Decisions API. People at OpenAI got nerd-sniped: how can we make this work—we’re not going to train a new model.

Swyx

四周前这还不在开发雷达上吧？

Four weeks ago this was not on the DevDay radar, right?

Nikunj Handa

完全没有。就是 Jev 启发。OpenAI 黑客文化很强：推理、infra 的人说「太酷了，我们黑一个」——原型能跑，然后我们就在延迟上 hill-climb，一到延迟目标就尽量发。

No, not at all. This is Jev-inspired. OpenAI has such a strong hacker culture. A guy from inference and someone from infra were like, this is amazing, we’re going to hack on it. They built a prototype that works, and now we’re hill-climbing on latency and want to launch in the coming days—as soon as we hit our latency target.

Vibhu

很多人听过 Jev 热度、没动手。该怎么理解 Decisions API？

How should people see Decisions API? A lot of people heard the Jev buzz and haven’t built with it.

Nikunj Handa

主用例是极快分类。Astra 写 JS 控电脑 vs Luna 一次选一个动作，智力档位不同，但有些 Computer Use 任务「够用就行」。内部还有人把 Decisions 接到 GPT Live——前端 talker 很快、会委派，后端坐着 Astra；以前 Live 里工具调用很拖，接上之后控电脑的 demo 跟手自然很多。

Main use cases we’ve seen: really fast classification. Astra writing a JavaScript-like script versus Luna picking one action at a time won’t be the same intelligence level, but maybe some Computer Use tasks are good enough. Internally people hook it up with GPT Live—the talker is super fast at delegation with Astra in the back. Tool calling always felt slow in Live; demos of Live controlling a computer feel much more snappy and natural with Luna on Decisions API.

Swyx

两周冒出大概一百个 Jev 克隆。克隆一个 API 其实就是结构化输出——你们先做的。决策模型不只是低延迟 + 结构化输出：把 Luna 关 reasoning 再加 structured outputs，不等于 Jev。定价和 Luna 一样？

About 100 Jev clones in the last two weeks. Cloning a Jev API is honestly structured outputs—which OpenAI was first to. What’s important isn’t just latency or structured output. If I take Luna, turn off reasoning, add structured outputs—do I have a Jev? No. The decision model is priced the same as Luna, right?

Nikunj Handa

对。我们没为这个训新模型，就是同一套 Luna 权重。上面做约束：结构化输出很关键，并猛抠推理栈的 TTFD；多问题就并行/批量跑。第一版基本是在 Luna 上零样本，先发出去看反馈，再按 OpenAI 经典迭代部署补模型——这就是 Decisions API。

Mm-hmm. We haven’t trained a new model; we’re building purely on the same Luna weights. On top you constrain—structured output is a big part—and optimize the inference stack for very fast TTFD. With multiple questions you run them in parallel as a batch. This first version is zero-shotting on Luna—put it out, see what people think, then make model improvements. That’s the Decisions API.

Swyx

你们还白捡了视觉；Jev 侧没有。若仍是同一 Luna 权重，校准/置信度这类能力多半还要后续 hill-climb。

As a benefit you have vision—they don’t; you get it free with Luna. If it’s still the same Luna weights, calibration innovations still sound to-come—RLHF collapses you toward what people want to hear, not true confidence.

Nikunj Handa

完全同意。这些可能是未来模型发布要 hill-climb 的关键区。

Totally. These are going to be key areas where we may have to hill-climb with a future model release.

Vibhu

平台团队要赋能 builder。Decisions 和 Computer Use agents，内部有什么一变就打开的东西？

Being on the platform team, your job is to empower builders. What should people build? Anything internal that really opens up after this change?

Nikunj Handa

Decisions：用户运营立刻扑上来分类工单；还有很酷的 GPT Live demo；Codex 应用侧也可能拿去玩。整件事大概一周前才真正启动，非常早。LLM-as-judge 低延迟也有人推。Agents API 上，OpenAI 一堆第一方已经全建在上面——刚出去的 Codex 安全相关、今天上的会议类能力；Sam 演示插件扩展里日历会议纪要流进 Space，也是 Agents API。

Decisions—user ops jumped on classifying support tickets; cool GPT Live demos; Codex app team might pick it up. This whole thing started like a week ago—very early. Low-latency LLM-as-judge is interesting too. On Agents API, a bunch of first-party products are built fully on it—Codex security that just went out, a meetings-type thing launching today. The plugin demo where meeting notes flow into your Space is fully on Agents API.

Swyx

你希望开发者聚焦反馈什么？路边有分叉时，想让他们帮你选？

Is there something you want people to focus feedback on—a fork in the road where developers help you decide?

Nikunj Handa

Agents API 和 Decisions API 最新，欢迎任何反馈。Responses API 是主力，现在死磕性能：一是延迟——整栈在重写，盯 TTFT 等；二是缓存，尤其个人智能体那种永远不结束的单线程。我们现在提供大约 30 分钟内的缓存命中保证；对某用户上线了更长窗口——12 小时缓存保证（预览，尚未全量公开）：多付一点 cache write，就能保证更长时间的 cache read，三四小时后再回来仍吃到缓存。

Agents API and Decisions API are our newest—any and all feedback. On Responses API, our workhorse, we’re focused on performance two ways. First, latency—rewriting the whole stack for TTFT and related. Second, caching for personal agents: a single thread that goes on forever. We provide guarantees of cache hits within like 30 minutes. For one user we launched a much longer window—a 12-hour caching guarantee, not public yet, in preview. Pay a bit more for the cache write and we guarantee cache reads much longer—come back three to four hours later and still get caching performance.

Vibhu

新模型下缓存读也更便宜了吧——大约便宜 25%？builder 应该按缓存友好来设计。

You cut the cost quite a bit with the new model—like 25% cheaper—so builders should implement because it’s significantly cheaper.

Nikunj Handa

对，把应用做成缓存感知，用 prompt/cache diagnostics 看哪里掉命中。还有预热：知道马上要用某 prompt，就先付 cache write 把缓存预热好，之后约 30 分钟随时可用，还能派生很多该线程实例。

Yeah—build apps to be cache-aware; use prompt or cache diagnostics to see where things drop off. We also have pre-warming: if you know you’ll need a prompt, pre-warm the cache, pay the cache write now, and have it ready for the next 30 minutes—and you can spawn many instances of that thread.

Swyx

缓存很好，但终究还是会撞上大约百万 token 上下文，压缩怎么办？

Caching is great, but you’re still bumping against a million-token context. What’s best practice for compression?

Nikunj Handa

OpenAI 有专有 compaction。Agents API 里写进 harness；Responses API 有两条路：服务端 compaction——设 token 阈值自动压；以及 /compact——要完全控制时手动触发。很多大型 coding agent 喜欢手动；开源 Codex harness 里就能看到用 /compact。还有新的、偏文件式的 compaction 技术，有的已在 Codex harness 里实验。

OpenAI has proprietary compaction. In Agents API it comes built into the harness. In Responses API: server-side compaction—hit a token threshold and auto-compact—or /compact for full control anytime. A lot of big coding agents like to do it manually; the open-source Codex harness uses /compact. There are also new compaction techniques—some file-based—already experimented with in the Codex harness.

Swyx

平台未来你还在琢磨什么？

Any other hints on the future of the platform?

Nikunj Handa

我们偏底层。我以前在 Stripe，游戏是在支付原语上堆更高层产品。AI 里怎么做最好，我一直好奇。Assistants API 当年不太对；现在 Agents API 给你 Codex harness，但灵活度给多少是开放问题——memory 墙、更高层 API 对象、抽象存储……很多 AI 工作流是：给底层原语 + 示例 harness，让 coding agent 去实现。多少该建进 API，是我成天在想的。

We’re obviously very low-level. I used to work at Stripe, where a lot of the game was higher-level primitives on core payments. I’m always curious about the best way to do that in AI. Assistants API way back wasn’t the right fit. Agents API gives you the Codex harness—but what’s the right amount of flexibility? How should we have memory walls and higher-level API objects that abstract storage? A lot of AI is: low-level primitive, example harness, let your coding agent implement it. How much we build into the API is a constant question.

Swyx

类比收个尾：你们在建 AI cloud——Sam 一年前说过——几乎像在发明 AI 原生的 EC2、S3。

The analogy I’ll end on: you’re building an AI cloud—something Sam said a year ago. You’re almost doing the AWS invention: this is EC2, this is S3—but AI-native versions of each.

Vibhu

类比很多：你会为预知的负载预热缓存，而且都暴露给 builder，这打开了新玩法。

There are a lot of analogies—you’re pre-warming caches for stuff you know will be needed, and it’s nice that it’s all exposed to builders because it opens up ways to build new things.

Nikunj Handa

完全同意。谢谢你们。

Yeah, absolutely. Thank you, guys.