What Builders Received at OpenAI DevDay
The theme behind OpenAI DevDay—and how its models, agents, coding tools, and ChatGPT experiences fit together.

At OpenAI DevDay, the company's developer conference held on September 29, OpenAI described its ambition as “a new renaissance of creativity and discovery.” Its complete DevDay announcement recap connected that ambition to agents taking on ongoing responsibilities, people collaborating with AI, and developers building new experiences inside ChatGPT.
My practical reading of that theme: give AI a continuing role in getting work done. Dots takes on ongoing assignments. ChatGPT Space and Pages give people and agents a shared place to work. Codex Cloud provides an environment for software tasks, while the Agents API lets developers put managed agents inside their own applications. Plugin Extensions give those products an interface inside ChatGPT.
That connection is the useful starting point for a builder. An application needs intelligence, a place to execute work, and an experience people can use. The announcements address different parts of that sequence. Here is how they fit together—and where the rollout limits affect what you can build today.
For the full announcement list and rollout details, read our OpenAI DevDay recap. This lesson focuses on what the changes mean for the next thing you build.
// The Lesson
Follow the work through the announcements
Start with the complete job you want to help someone do. Then map the DevDay products to its three parts: the intelligence that understands the task, the tools that carry it out, and the interface where a person directs and checks the work.
The sections below follow that sequence, linking each announcement to its product page or developer documentation. OpenAI's full recap above is the reference for every DevDay announcement; this lesson explains the building choices behind them. Availability was checked on October 5. The examples illustrate possible uses, not results from hands-on testing.
// Models
Give routine work a different model budget
The first part is the model that does the reasoning. OpenAI's updated Sol is positioned for coding, computer use, and professional work at lower published token prices than Astra. Developers can access it through the API; eligible subscribers can use it in ChatGPT Work and Codex. The launch page explicitly says it is not yet in ordinary Chat. (See the GPT-6.1 Sol announcement.)
For a builder, that makes Sol a candidate for repeated document analysis or coding tasks. It does not establish which model will complete your particular workflow most reliably. OpenAI's performance comparisons are its reported evaluations, so treat them as reasons to run your own representative tests.
Speed is a separate choice. Ultrafast is an API service tier for generating responses more quickly. Astra access is broadly available, with rate limits. The practical question is whether faster generation shortens the user's whole wait, including any external tools the application calls.
Sol also gained multi-agent support in beta: a request can delegate work to subagents. That is a feature to evaluate separately from the model's ordinary availability.
// Development Work
Move coding tasks into a prepared workspace
The next part is a place to execute the work. Codex Cloud provides reusable environments containing a project's repositories and tools. Each task gets its own working space and can continue while your computer sleeps. You review changed files and check results when the work returns.
Think of a maintenance task that requires the same dependencies and test commands every week. A reusable environment gives that task a prepared place to run. Your team still needs to verify that the environment can execute the relevant checks before relying on the output.
Review received attention too. The desktop Code Review experience brings together descriptions, changed files, comments, and checks. Its GitHub support is generally available; GitLab merge-request support is in preview. A review interface helps you investigate a proposed change. Your acceptance criteria should still determine whether that change is ready.
// Agent Applications
Put a managed agent inside your own product
For developers building an agent into a product, the Agents API exposes the machinery behind Codex. OpenAI manages the running session, coordination, recovery, and the summarization needed to keep long tasks within the model's context. Your application supplies tools and chooses the execution environment.
In practical terms, you can give an agent a task, receive progress events, and continue the same session with follow-up instructions. A support-investigation product, for example, could use that structure to gather evidence and return a proposed resolution for review. The product team would define the permitted data, actions, and approval points.
DevDay adds hosted computer use. An agent can operate an OpenAI-hosted browser to test a website, collect information, or use a browser interface. Your application must handle website-access requests and sign-in when needed, follow the session, and verify the result.
That division matters. Hosting the browser removes infrastructure work, but it leaves the builder responsible for a sensible user journey when the agent needs permission, gets interrupted, or cannot finish.
Check the data requirements early: the current Agents API documentation says session state is retained, data residency is currently US-only, and Zero Data Retention is unsupported. Those constraints can decide whether this execution option fits your application.
// Decisions
Ask a narrow question when the answer is finite
The Decisions API targets classification and routing. Developers define questions with a finite set of permitted answers and receive answers for their software to use. OpenAI announced it in limited preview, with broader release planned. A promised release is not confirmation that your account has access.
Consider a support request that should be labeled “billing,” “technical,” or “needs a person.” That is the kind of bounded choice this design suggests. You would decide what each answer triggers and how to handle a wrong classification.
I would evaluate it on a labeled sample of real requests before attaching actions to its decisions. Include ambiguous examples and cases that must go to a person. The useful measure is whether the selected route is correct enough for the next action you intend to permit.
// Distribution
Build an experience people can use inside ChatGPT
The third part is the experience people use to direct the work. Plugin Extensions let developers connect their products to ChatGPT's sidebar, composer, and file viewers. This gives a product room for an interactive experience alongside a conversation. Current documentation says web extensions for Free and Go are coming soon, and composer mentions are desktop-only.
The surrounding vocabulary is easier to understand as a set of parts. A skill supplies instructions and resources for a repeatable workflow. An MCP server connects tools and external services. A plugin packages those capabilities for installation and distribution. Optional interfaces can use the MCP Apps standard. These roles are described in OpenAI's plugin architecture guide.
For example, a document-review product might need instructions for the review process, a connection to the document system, and an interface where a person examines proposed changes. Decide which parts your use case needs. A skills-only plugin can be enough when instructions and existing tools already cover the job.
The opportunity is to extend the product experience. Read skills, apps, and plugins as complementary parts. Check each capability against the device and interface your intended users will actually use.
Turn a connected workflow into a usable site
ChatGPT Sites creates and hosts websites and web apps. It is in public beta. The new plugin capability lets a workspace site use each visitor's own connected accounts and permissions, so two teammates can open the same application and see the information they are individually allowed to access.
The documentation requires plugin-connected sites to be private to an enabled workspace. Sharing a site does not share the builder's connected accounts. This is a useful distinction for an internal dashboard: the interface may be shared while access to the underlying information remains personal.
Treat available, beta, limited preview, and express interest as different planning states. The OpenAI Marketplace, for instance, requires enterprise buyers to confirm eligibility and asks prospective partners to join a waitlist. That is a different starting point from a documented API you can already call.
Choose one unfinished project this week and name its actual obstacle. If it is model performance, test the model. If it is running a long task, examine the execution environment. If it is getting the work into someone's hands, examine the plugin or site experience. Put the access requirements and acceptance test next to that choice. That gives your team a concrete next step from DevDay.
Your AI Sherpa,

Mark R. Hinkle
Founding Publisher, The AIE Network
Follow me on LinkedIn
[If you want to get in contact or give me feedback, just reply to this email. I read every single one of them. ]
