OpenAI DevDay on September 29, 2026 brings model updates, ongoing agents, and more ways to build developer workflows. For an application team, the useful question is which announcement changes a measurable constraint: cost, completion quality, integration effort, or the amount of supervision a task needs. This field note reviews confirmed launch material and turns it into a practical evaluation plan.
The announcements that change engineering decisions
The official DevDay recap covers GPT-6.1 Sol, dots, Codex cloud workflows, plugin extensions, and new developer capabilities. Two distinctions matter immediately: the Decisions API is in limited preview, while GPT-6.1 Sol Ultrafast is described as coming soon. An announcement and access for a particular account are separate facts.
OpenAI's GPT-6.1 Sol launch article lists standard API prices of $2 per million input tokens, $0.10 per million cached input tokens, and $10 per million output tokens. It positions the model near Astra on selected evaluations at lower prices. Those comparisons are company-reported results; they are not measurements of this portfolio or a guarantee about another team's workload.
My interpretation is that cheaper capable models make more workflows worth testing. They do not remove the need to define success. A task that produces an attractive answer but changes the wrong record is still a failed task.
Evaluate the completed task before the token bill
A useful evaluation set contains real work with an observable endpoint. For a coding assistant, that might be a reviewed patch that passes a focused regression check. For document processing, it might be a validated extraction with citations to the correct pages. Avoid scoring only whether the response looks fluent.
Keep a fixed sample of ordinary cases alongside difficult ones. Include missing information, conflicting documents, unavailable tools, and tasks that should stop for clarification. Record which model and configuration handled each case, how many attempts were needed, and whether a person had to repair the result. Compare results under the same acceptance rules.
Token prices then become one part of a larger accounting model. Track tool charges, runtime, retries, and review effort where those costs apply. Cache savings are meaningful only when your actual requests benefit from caching. A public price table alone cannot establish the cost per accepted result.
- Accepted outcomes on real tasks
- Incorrect external actions
- Human repair effort
- End-to-end completion time
- Total cost per accepted result
Proposed evaluation priorities, not published OpenAI benchmark scores or results measured by this portfolio.
Begin with a narrow comparison rather than migrating every workflow. Keep the existing path available, run the same sample through the candidate, and inspect disagreements. If the new model handles routine cases well but struggles with a specific document type, route that category deliberately instead of averaging the problem away.
Ongoing agents need a durable work record
OpenAI's dots announcement describes agents with their own cloud computer, connected applications, and the ability to work across ongoing responsibilities. Rollout depends on plan, market, and workspace settings. The article also describes access controls and approval mechanisms. It should be read alongside the current settings for the account that will actually run the work.
For a team building an analogous workflow, I would define a durable record for each task: purpose, permitted tools, last completed step, pending decision, and final evidence. This is my proposed application design. It is not a description of undisclosed dots internals.
The record should survive a worker restart. If an agent drafts a support response, the system must distinguish drafting from sending. If a connection drops after a write, the next attempt should check the resulting state before repeating it. A task identifier and an external operation identifier can help connect the user's request to the final outcome.
- ScopeRecord goal and permissions
- ExecuteRun bounded tool operations
- VerifyRead the resulting state
- ReportAttach evidence and remaining decisions
Conceptual application workflow proposed by the author; it does not depict OpenAI's internal implementation.
A clear completion report is part of the product. It should state what changed, where the result lives, and whether any step failed. For recurring work, notify on a meaningful change or a decision that needs attention. Repeated messages that say nothing changed train people to ignore the system.
Put the September timeline in order
The Agents API introduction is dated September 10, 2026. It describes a managed harness, long-running sessions, tools, and execution environments. DevDay's recap adds computer-use support to that existing product. Calling the entire Agents API a September 29 invention would blur the release history.
For an integration, separate the model from the harness and the execution environment. The model decides what to do next; the surrounding application controls which tools exist, how state is stored, and how outcomes are checked. A managed service can take over parts of that infrastructure while your product still owns its user experience and acceptance criteria.
Plugin extensions are another decision about where a workflow belongs. Before creating a panel, identify the action a person needs to take there: compare alternatives, approve a draft, inspect a file, or correct a record. Build the smallest surface that makes that action understandable. A panel filled with generic status cards may add complexity without improving the task.
September 2026 evidence update
Sources were reviewed on September 29 after official launch pages became available. This is a publication-day analysis, not an independent hands-on benchmark. It replaces an earlier September decision-model topic in the two-articles-per-month archive. Product access and preview status may change after publication; the linked primary sources are the place to verify current availability.
My proposed next step is a one-workflow pilot with a named owner. Select a representative task sample, write acceptance criteria, define permitted actions, and retain the old path for comparison. Review the failures before expanding access. A release is useful when it improves a real workflow under conditions your team can reproduce.
Sources and further reading
- OpenAI DevDay 2026 recap — launch overview and preview distinctions.
- Introducing GPT-6.1 Sol — model claims, pricing, and availability.
- Introducing dots — ongoing agents, rollout, and controls.
- Introducing the Agents API — September 10 origin and managed runtime context.