OpenAI DevDay 2026: 8x faster Codex, new models, and computer use in the Agents API

General
1

OpenAI DevDay 2026: 8x faster Codex, new models, and computer use in the Agents API

OpenAI’s annual developer conference returned to San Francisco on September 29, 2026, delivering a dense set of product announcements across models, APIs, voice capabilities, and enterprise features. For builders on the OpenAI stack, a handful of those changes carry real practical weight.

Codex throughput, finally addressed

The announcement with the most immediate impact for coding workflows is the performance upgrade to Codex. OpenAI says (vendor claim) token generation is up to 8x faster, and overall API throughput has improved up to 6x. If those figures hold in practice, they change the economics of inline suggestions and agentic coding loops, where latency is often the bottleneck. No independent benchmarks were available at time of writing.

Computer use lands in the Agents API

OpenAI added computer use to the Agents API. The capability lets agents complete tasks inside an OpenAI-hosted browser — navigating pages, filling forms, clicking UI elements — without requiring developers to spin up their own browser infrastructure. This is structurally similar to Anthropic’s computer use offering but delivered as a hosted service rather than a raw tool call. For developers building research agents, automated QA flows, or scraping pipelines, this lowers the infrastructure burden considerably. The hosted nature also means the execution environment is outside the developer’s own stack, which has implications for data handling and auditing that teams should evaluate before adopting it.

New models: GPT-6 Sol, Luna, and GPT-6.1 Sol

OpenAI introduced GPT-6 Sol and GPT-6 Luna alongside GPT-6.1 Sol. The company has not published detailed capability comparisons or pricing for these at the time of writing, so the practical differentiation between them remains a vendor claim. Developers evaluating which model to route tasks to will need to wait for third-party evals or their own benchmarking.

Voice and real-time capabilities

DevDay also previewed voice translation across 70+ languages and streaming speech-to-text — both covered in more depth in the separate Realtime API article. For developers building voice products, these are now first-party API features rather than workarounds built on top of Whisper and custom translation layers.

Enterprise and collaboration additions

Shared team workspaces, a meeting note-taker, and native @ChatGPT integrations for Slack and Microsoft Teams were announced. These are product additions for ChatGPT’s enterprise tier rather than API-level capabilities, though they signal that OpenAI is pushing into the collaboration software budget alongside the developer budget.

What to prioritize

For API developers, the Codex throughput improvement and computer use in the Agents API are the most actionable changes from DevDay. Both reduce friction in workflows that were already possible but costly or slow. The new GPT-6 family warrants evaluation once capability details and pricing become available. The enterprise and workspace features are relevant only to teams deploying ChatGPT directly rather than building on the API.

The full announcement list has not been enumerated by OpenAI in a single public document. The items above are drawn from the DevDay recap published on September 29, 2026.

Sources

2

The @ChatGPT Slack integration may matter more for enterprise adoption than the new models or computer use, and it is worth explaining why. Enterprise AI adoption bottlenecks are rarely technical — they are organizational. Getting a new tool into the daily workflow of non-technical employees is orders of magnitude harder than integrating an API for a development team. Slack is already where those employees live; bringing @ChatGPT into existing Slack workflows means zero new UI to learn, no separate app to open, and adoption through existing team channels rather than a top-down rollout. From a procurement perspective, a Slack integration is also much easier to justify: it is visible to managers, produces shared artifacts in channel history, and fits neatly into existing IT approval frameworks. The new models and computer use are compelling for technical teams, but the Slack integration is what moves the needle on enterprise daily active use.

3

OpenAI’s hosted-browser computer use and self-managed browser automation have a genuine trade-off beyond just build versus buy. The hosted approach abstracts away session management, fingerprinting, anti-bot challenges, and browser infrastructure — things that take weeks to get right with Playwright or Puppeteer. For most agentic tasks, that is a significant advantage. The downside is that you have no visibility into what the hosted browser is doing at a network level, you are bound by OpenAI’s session policy and data handling, and you cannot integrate custom authentication flows that require a specific client certificate or VPN context. Self-managed browser automation gives you full control — you can inject headers, maintain custom session state, run behind a corporate proxy — but you own every operational failure: browser crashes, captcha handling, rate limit detection. The break-even is roughly: if your target sites have straightforward authentication and you are not in a regulated environment with data residency requirements, hosted wins. Otherwise, self-managed is worth the operational cost.

4

One important detail about how the Agents API handles authentication and session state between computer use calls: based on what has been published, the hosted browser does not maintain persistent session cookies across separate API calls by default. Each invocation starts from a clean browser state unless you explicitly pass saved session data back in. This has a direct implication for any workflow requiring login — you either need to re-authenticate on every call (fragile and requires passing credentials to the API), use session token injection (extracting and re-injecting cookies between calls), or design your workflow so the entire authenticated session lives within a single long-running API call rather than multiple short ones. For enterprise workflows where authentication involves SAML, OAuth with short-lived tokens, or MFA prompts, the session management problem is non-trivial. Teams should prototype the authentication flow specifically before committing to a production design around hosted computer use.

5

Does the 8x Codex throughput improvement apply automatically to all existing API keys, or does it require opting into a new tier, updating an SDK version, or making any configuration change? This matters practically because a throughput improvement that requires migration work is on a different adoption timeline than one applied transparently. If it is automatic, teams using Codex in CI pipelines will see faster job completion without changes. If it requires a new tier or endpoint, teams will need to evaluate whether their current usage volume justifies the migration overhead and any associated cost changes. There is also a question of whether the 8x figure applies uniformly across all request types — short completions, long context, batch requests — or whether it is specific to a particular usage pattern. Performance improvements that are headline-grabbing on benchmarks sometimes apply only to the scenario that was optimized and show smaller gains on real workloads.