Why Dwarkesh is Wrong about Computer Use + How OpenAI shipped its Jev competitor in 1 Week

The host opens with Ari, who leads the product and engineering team for computer-use agents, and asks for a rapid recap of DevDay. Ari highlights Dots, a new personal-assistant product whose instances have access to their own Linux virtual computers in the cloud; GPT 6.1 Sol, which OpenAI presented as especially useful for computer use because of its speed and cost; computer use in the Agents API; and demonstrations of existing features such as App Shots and native computer use on the Mac. Ari says GPT 6.1 Sol costs one-fifth as much as Astra generally and one-seventh as much for computer-use workloads. App Shots let users bring the context of an application into Codex or ChatGPT, while native Mac computer use can automatically take screenshots and operate applications while the user continues doing other work. The conversation also briefly distinguishes the new Decisions API: it performs inference in parallel, does not use reasoning, and is smaller and faster than the models used for computer use. Ari says that makes it attractive for rapid decisions, although it is currently less capable on long-horizon, sophisticated tasks, and combining the two approaches remains an open research problem.

The host asks how users should push the limits of Dots. Ari explains that Dots differ from products that only provide a cloud browser or access to the user’s existing computer: each Dot gets an entire Linux computer in the cloud, allowing it to run desktop applications as well as use a browser. His general recommendation is to identify a recurring computer task that consumes time and ask what parts could be delegated. The host mentions flight booking, shopping, gaming, and customer-service tasks, including fixing an issue without having to sign in or authenticate personally. Ari gives a concrete example from his own life. He subscribed to a meal-preparation service that allowed extremely detailed customization, such as specifying the grams of chicken and rice, but one order took him two hours. Computer use completed the same order in 15 minutes on GPT 6.1 Sol, saving him roughly two hours and completing the task about eight times faster. The host says his immediate top use case is automating YouTube operations that are not exposed through the YouTube API, including A/B-testing features and community posts. Because computer use operates the visual interface inside a virtual machine, he argues, it can handle workflows that developers otherwise cannot automate through official APIs.

The host raises a claim from a leading AI podcast that computer use had not advanced in the previous two years. Ari strongly rejects that framing, saying computer use is now “180 degrees different” from the systems he worked on a few months earlier. He describes a career-long interest in automating computer tasks, from his work at Apple to founding Sky and then joining OpenAI, with the goal of saving people from spending their time operating computers inefficiently. Ari’s main technical milestone is that earlier systems could reliably begin a task but often failed when they encountered an unexpected problem. Current models are much better at debugging, trying again, and introspecting about what is and is not working. He also says computer-use systems no longer need to perform every action one at a time. In Codex, the model can write JavaScript that the computer executes, sometimes carrying out many actions in one operation. The harness now combines screenshots, accessibility information, direct application or DOM access, and Playwright, choosing among these mechanisms according to the task. Ari identifies richer modalities as a major breakthrough. Instead of repeatedly scrolling, taking screenshots, and scrolling again, a model can use accessibility data or the DOM to see an entire page or application and act on it directly. Many smaller engineering fixes also contribute to speed improvements.

The host and Ari explain why App Shots are more powerful than their visual presentation suggests. In Codex, a user can double-press the Command key to bring the current application into Codex or ChatGPT. Although the result looks like an ordinary screenshot attachment, it also contains metadata, text, and the application’s accessibility representation. Ari gives the example of a webpage: a normal screenshot shows that a link exists but not where it leads. A calendar screenshot may truncate event titles. An App Shot can provide the language model with the full underlying context, including the destinations of links and complete event information. Users who click the attachment’s small button in the top-right corner can inspect the raw text and accessibility representation. OpenAI has worked to make that representation token-efficient as well as useful. Ari notes that the same accessibility technologies originally built to help people use screen readers also help language models operate computers. The host points listeners toward a full workshop by Jason Liu at AI Engineering for more detail. The broader point is that computer use is not limited to visual imitation: it can combine visual understanding with structured application information, making actions faster and more reliable.

Asked where computer-use agents might be in two years, Ari says the team has already reached a striking milestone: in many cases, computer use is faster at completing tasks than an average person. The next frontier is “superhuman” performance—agents that are as fast as or faster than expert computer users. He expects that to enable more real-time products and reduce the activation energy required to use software, causing people to delegate tasks they currently perform manually. The remaining bottlenecks are spread across the model, inference system, harness, and representation. Ari says that as the model becomes faster, waiting for the software itself becomes a larger share of the task. In a DoorDash example, the agent may spend substantial time waiting for the website to load. The ideal harness would react immediately when loading finishes rather than inserting a fixed delay, but event-driven behavior is complicated: web navigation has load events, while other applications and interactions do not expose equally useful signals. The host describes customer-service conversations where replies may take 30 seconds or three minutes. He has had Codex manage those exchanges, answer in complete sentences, and even adopt an “annoyed human” style rather than sounding like a bot. He also asks it to use subagents to research better solutions while waiting. They joke that computer-use bots may increasingly end up talking to other bots.

Ari says a major recent trust milestone is that people have moved from being afraid to connect language models to the web and their devices to letting computer use configure DNS and pay bills. He says he has entrusted it with tens of thousands of dollars’ worth of activity, though the discussion does not establish that every such action is risk-free. The host’s customer-service examples likewise illustrate how much autonomous work is already possible with limited human intervention. For developers adopting computer use through the Agents API, Ari recommends using OpenAI’s supplied computer-use harness where possible. Developers can build their own harnesses, but it is difficult, and OpenAI trains its models against the distributed harness. Using it may therefore provide advantages in speed, cost, and accuracy. The API’s main attraction is universality: an agent can work with third-party websites and services even when no suitable API exists. Ari also stresses that trust must be built through reliability and safety checks. Applications should ask for user consent before consequential actions such as making a payment and, depending on the use case, limit access to only the websites or applications necessary for the task. The host and Ari then discuss computer use completing the development loop: an agent can build software, test it visually, and find design problems before the human reviews it. The host says his visual play-testing skill catches issues that code inspection would miss, and suggests computer use can clone a SaaS product screen by screen.

The second interview features Nick Orange, who leads product for OpenAI’s API team. He says his work has consistently involved taking capabilities developed with research and post-training teams and exposing them through the API. For the new GPT 6-related API capabilities, he highlights asynchronous function calling: a model can start a long-running tool call, continue reasoning, and check back later instead of pausing execution. The API also supports mid-turn steering, allowing developers to inject messages while the model is reasoning. Nick says this capability existed in the product experience but was not reliable enough for the API until it improved through training. WebSockets provide the bidirectional communication needed for these interactions and reduce the overhead of repeatedly going back and forth between the model and tools. The discussion turns to UltraFast, which Nick describes as the first time frontier intelligence has been available at extreme speed. He says the inference team initially focused on efficiency and reduced costs, cutting the “lunar” price by 80 percent, and later shifted toward maximizing speed. WebSockets were originally launched for this kind of model-tool interaction and are especially useful when tools take substantial time to run. Nick also says first-party OpenAI products, including Codex security features and a meeting-related demonstration, are being built on top of the Agents API.

Nick describes the Decisions API as OpenAI’s response to the market’s interest in very fast decision or classification models. He credits the team behind “Jev” with inspiring the effort: after users and internal teams asked for a similar capability, an engineer built a prototype in roughly a week. OpenAI’s goal is to release it once it meets its latency target, while continuing to improve it iteratively. Unlike a newly trained model, the first Decisions API implementation is built on the existing Luna weights. Nick says it combines structured outputs with an inference stack optimized for time to first token and runs multiple questions in parallel as a batch. These choices make it fast, but the model is not expected to match Astra’s intelligence for complex computer control. For computer use, Luna may select one action at a time, whereas Astra can write JavaScript that controls the computer through multiple steps. Nick nevertheless expects some computer tasks to be suitable for the faster model. Other potential uses include classifying support tickets, powering fast internal operations, and making voice interactions more natural. The host notes that Decisions can also provide vision because it uses Luna, whereas some competing systems do not. They discuss broader possibilities such as confidence calibration, diffusion-style generation, and activation-based approaches, but Nick presents those as speculation and future research rather than describing them as features of the current API.

Nick says the platform team is focused not only on launching new APIs but also on making the Responses API fast and reliable. One major effort is reducing latency by rewriting its infrastructure for better time to first token and overall response speed. The second is caching, especially for personal agents that maintain a single conversation thread for a long time. OpenAI offers guaranteed cache hits within 30 minutes and is testing a 12-hour caching guarantee for users willing to pay a little more for the cache. That would let an agent resume a thread several hours later while retaining caching performance. Nick recommends that developers design applications to be cache-aware and use OpenAI’s prompt-diagnostics and cache-diagnostics tools to discover where cache hits are being lost. He also describes pre-warming: developers can pay the cache-write fee in advance when they know a prompt will be needed, leaving it ready for use during the following 30 minutes and allowing multiple instances of a thread to be spawned. Because caching does not eliminate the need to manage very large contexts, the host asks about compression. Nick says the Agents API includes server-side compaction, which automatically reduces context after a chosen token threshold, and a manual “slash compact” option for developers who want control. The open-source Codex harness uses the manual approach and is also experimenting with file-based compaction systems.

In the closing discussion, Nick says the next platform question is how many higher-level primitives OpenAI should provide instead of leaving developers with low-level APIs and example harnesses. He compares the problem to his previous work at Stripe, where teams built higher-level products on top of core payment primitives. OpenAI previously launched the Assistant API, but Nick says the team is now exploring the Agents API as a better foundation for agentic applications. The unresolved design questions include how much flexibility developers should retain, whether the API should offer built-in memory walls, and whether it should abstract away more storage concepts. Nick says he is interested in finding the right balance between giving builders control and embedding more of the harness directly into the platform. The host compares OpenAI’s work to building an AI cloud analogous to AWS, with different AI-native equivalents of primitives such as compute and storage; pre-warmed caches are one example of that infrastructure layer. Nick’s request to developers is straightforward: use the Agents API and Decisions API and provide feedback that can shape the roadmap. For the Responses API, he particularly wants feedback on low-level latency, caching, and reliability. The episode ends with the idea that the APIs, harnesses, and first-party products are being developed together, so real-world builders will help determine which abstractions OpenAI eventually makes standard.