Why GPT-6.1 Sol, Agents API, Decisions API, and Private Intelligence matter far more together than they do separately
Insightful take on overall presentation from OpenAI in DevDay 2026. Taken together, GPT-6.1 Sol, the Agents API, Decisions API, and Private Intelligence point toward something much larger. OpenAI is slowly packaging the entire operating environment around intelligence.
There was a time when building an AI product mostly meant choosing a model.
You called an API, sent some text, received some text back, wrapped a product around it, and spent an uncomfortable amount of time convincing everyone that this was definitely not “just a wrapper.”
That era is disappearing remarkably quickly.
The most interesting announcements from OpenAI's DevDay 2026 were not really about making the chat box better. Taken together, GPT-6.1 Sol, the Agents API, Decisions API, and Private Intelligence point toward something much larger.
OpenAI is slowly packaging the entire operating environment around intelligence.
The model is getting cheaper. The agent runtime is becoming managed infrastructure. Decision-making is getting its own constrained primitive. And the security architecture around sensitive enterprise data is being pushed deeper into the platform.
Those four things belong together.
Because once AI stops answering occasional questions and starts doing real work for hours, across tools, using private company data, the model itself becomes only one part of the problem.
And perhaps not even the hardest part.
The first shift: intelligence is moving down the cost curve
GPT-6.1 Sol is easy to misunderstand if you look at it as another entry on a benchmark leaderboard.
Yes, the model is better than GPT-6 Sol. OpenAI says it gets close to GPT-6 Astra on agentic coding, computer use, document-heavy professional work, and multi-step business workflows. But the more interesting part is where that capability now sits on the cost curve.
Standard API pricing is $2 per million input tokens and $10 per million output tokens. Cached input costs just $0.10 per million tokens. The model also supports a 1.05-million-token context window and up to 128,000 output tokens.
Those numbers matter, but token prices alone don't tell the story.
Agentic software does not consume intelligence the way a chatbot does.
Imagine asking ChatGPT one question about an invoice. The model reads perhaps a few thousand tokens, reasons briefly, and answers.
Now imagine an agent investigating a production incident.
It reads logs. Then code. Then deployment history. Then calls another tool. It comes back to the original code. It delegates part of the investigation. It reads several long files again. It writes a script, executes it, inspects the result, discovers its hypothesis was wrong, and takes another path.
Suddenly you are not paying for one answer.
You are paying for a chain of cognition.
That is why OpenAI's own GPT-6.1 Sol release is increasingly framed around cost per completed task, rather than only cost per token.
On DeepSWE, which tests long-running software-engineering work against real repositories, OpenAI says GPT-6.1 Sol reaches roughly Astra-level performance at around one-fifth the cost.
On OSWorld 2.0, where agents must actually operate computer interfaces, Sol comes within 2.1 percentage points of Astra at maximum reasoning effort while costing roughly one-seventh as much per task.
On AutomationBench, which evaluates multi-step business workflows across functions such as sales, support, finance, HR, and marketing, Sol beats Opus 5.5 by 2.2 percentage points at medium reasoning effort while costing roughly one-third as much per task.
That is much more interesting than saying one model scored 73 and another scored 71.
Because the question developers are beginning to ask is changing.
For the last few years it was:
Can the model do this?
Increasingly it will become:
Can I afford to let the model do this 50,000 times a day?
That is the economics question behind agents.
A coding agent that solves one difficult issue during a demo is impressive.
A coding agent that can economically review every pull request, investigate every production regression, continuously clean technical debt, update documentation, migrate dependencies, and investigate security findings is an entirely different kind of technology.
The second scenario requires intelligence to become cheap enough that you stop rationing it.
Caching matters enormously here too.
Long-running systems repeatedly carry the same context: system instructions, repository conventions, schemas, tool descriptions, company policies, large documents, or previous conversation history. GPT-6.1 Sol's cached-input price of $0.10/M is half the cached-input price of the original GPT-6 Sol and 95% below its standard input price.
That can fundamentally alter agent economics.
The frontier model will still matter for the hardest problems. OpenAI still positions Astra above Sol when maximum capability matters.
But there is a familiar pattern in computing history here.
The transformative moment is rarely when something becomes possible for the first time.
It is when something that was expensive becomes cheap enough to use almost carelessly.
Compute did this.
Storage did this.
Bandwidth did this.
AI inference is now moving through the same curve.
But a cheaper brain does not give you a reliable worker
This is where the story gets more interesting.
Suppose GPT-6.1 Sol makes reasoning dramatically more economical.
You still haven't built an agent.
You have built a cheap brain.
A useful agent needs a surprising amount of machinery around that brain.
It needs somewhere to work.
It needs files.
It needs tools.
It needs credentials and permissions.
It needs to remember what happened fifteen steps ago.
When the context becomes enormous, something needs to compact it without destroying the information that matters.
If the job takes two hours, the process needs to survive network interruptions and application restarts.
If the agent delegates research to three other agents, something must coordinate them.
If it writes code, that code needs an execution environment.
If it is halfway through a task and your application loses its connection, you cannot simply replay the last request and hope nothing executes twice.
This collection of machinery is what people increasingly call the agent harness.
And this is where the Agents API may eventually matter more than yet another model release.
The Agents API is OpenAI productizing the harness
OpenAI introduced the Agents API in public beta shortly before DevDay and expanded it at DevDay with capabilities including computer use.
The simplest way to understand it is this:
OpenAI is taking much of the infrastructure it learned to build around Codex and exposing it as a managed runtime for other developers.
The API has four fundamental concepts: an agent, an environment, a persistent session, and the stream of events/items produced while that agent works.
The agent contains the model, instructions, tools, and MCP servers available to it.
The environment is where work happens. That can be an OpenAI-hosted sandbox, infrastructure you host yourself, or no sandbox at all if the task does not require one.
The session is important. It represents a durable instance of the agent that can continue working across turns instead of being reconstructed from scratch on every request.
And OpenAI manages much of the ugly machinery behind it: orchestration, session state, context compaction, recovery, tool coordination, and multi-agent execution.
That sounds like infrastructure trivia until you actually build a serious agent.
Consider a production incident agent.
You tell it:
Investigate why checkout failures increased over the last 30 minutes.
That sentence might trigger an hour of work.
The agent could query observability tools, inspect recent deployments, delegate one hypothesis to a subagent looking at downstream dependencies, ask another to examine application errors, correlate those findings, execute diagnostic scripts inside a sandbox, save evidence to files, and eventually prepare a recommended mitigation.
If a human engineer joins halfway through and says, “Ignore the payment-provider hypothesis; we've already ruled that out,” the same session can be steered rather than restarted.
That is very different from an LLM request.
It behaves much more like a job running inside a distributed system.
The Agents API documentation even reflects that mindset. Sessions can be followed through events, recovered after connection failures, inspected through logs, and continued with more work.
This is an important architectural shift.
For years, frameworks such as LangGraph, LangChain, Microsoft Agent Framework, and many internal platforms have been solving some variation of these problems themselves.
OpenAI is now saying:
You can still control the workflow yourself. But if you don't want to operate the harness, we'll operate it for you.
There are now effectively three levels of abstraction in OpenAI's stack.
At the lowest level, the Responses API lets you work close to model calls and orchestrate much of the system yourself.
The Agents SDK gives you reusable agents, tools, handoffs, and an application-controlled runtime.
The Agents API goes further and lets OpenAI run the Codex harness, preserve sessions, and manage much more of the orchestration infrastructure.
That distinction will matter a great deal to architecture teams.
More abstraction means less infrastructure to build.
It can also mean less control.
And those two forces are going to shape nearly every enterprise agent-platform decision over the next few years.
Then OpenAI gave those agents a computer
At DevDay, the Agents API gained computer use.
This matters because APIs only expose a fraction of the software humans use every day.
Companies have internal portals built fifteen years ago. Vendor dashboards. Admin panels. Desktop-style web applications. Tools with incomplete APIs. Systems that nobody wants to integrate deeply because they may disappear next year.
Humans can use all of them because humans understand interfaces.
Computer-use agents attempt to close that gap.
Inside the Agents API, OpenAI can provision a hosted browser. The agent observes the interface, decides what to do, and interacts with the site while your application handles sensitive boundaries such as website-access approvals and authentication.
Now imagine the difference this makes.
Without computer use, automating an old procurement system may require weeks of API integration.
With a sufficiently reliable computer-using agent, the integration surface can become the interface the application already has.
That does not mean every API should be replaced by clicking buttons.
APIs remain more deterministic, observable, efficient, and controllable.
But computer use gives agents an escape hatch for the enormous long tail of software that was never designed to be automated.
That turns the browser into something surprisingly important:
a universal compatibility layer for agents.
There is a reason to remain cautious here. UI automation is inherently less deterministic than calling a well-defined function. Interfaces change. Elements move. Pages contain untrusted content. Authentication introduces security boundaries. An agent may misunderstand what it sees.
OpenAI explicitly warns developers to treat website content as untrusted and provides approval mechanisms for network origins and sign-in flows.
So the future is unlikely to be “agents click everything.”
The more credible architecture is hybrid.
Use APIs, MCP, functions, SQL, and deterministic tools wherever possible.
Use computer interaction where no better interface exists.
That is a much more powerful system than either approach alone.
And then comes the counterintuitive part: sometimes the agent should have fewer choices
Agent development has spent years chasing autonomy.
Give the model more tools.
Give it more memory.
Give it a computer.
Give it subagents.
Let it plan for longer.
Let it recover from mistakes.
And for many workloads, that is exactly the direction we want.
But there are places inside real companies where maximal autonomy is the wrong design goal.
Imagine an insurance claim arrives.
You probably do not want to tell an unconstrained agent:
Do whatever you think is appropriate.
You might instead want intelligence to answer a much narrower question:
What should happen next?
Approve automatically.
Route to manual review.
Request additional documentation.
Reject as out of policy.
The model still needs intelligence. It may need to interpret messy text, photographs, supporting documents, policy rules, and prior context.
But the action space is deliberately bounded.
That is the idea behind OpenAI's new Decisions API.
Developers provide text or image context along with specific questions whose valid answers are predefined. Luna then selects among those possibilities. OpenAI describes use cases such as content classification, request routing, and deciding an agent's next action. The API launched at DevDay in limited preview.
At first glance this sounds almost boring compared with autonomous agents.
I think it may turn out to be one of the most important enterprise patterns OpenAI announced.
Because production systems rarely consist entirely of autonomous agents.
They contain moments of judgment inside larger deterministic processes.
Consider customer support.
A model may decide:
refund / escalate / ask another question.
Consider cybersecurity.
benign / suspicious / isolate / human investigation.
Consider document processing.
accept / reject / request missing evidence.
Consider an AI router.
cheap model / stronger model / specialist agent / human.
These are not necessarily conversations.
They are decisions embedded inside software.
For years, we built these systems with rules.
if amount > 10000 and country != expected_country ...
Rules are wonderfully predictable until reality becomes too messy to describe with rules.
Traditional machine-learning classifiers handle messiness better, but every new decision often requires labelled data, training pipelines, evaluation, deployment, monitoring, and retraining.
LLMs gave us a third option: reason over rich unstructured context.
The Decisions API turns that capability into a more constrained primitive.
That constraint is not weakness.
It is architecture.
A powerful model can understand the world.
Your application can decide which choices the model is actually authorized to make.
That separation between intelligence and authority is likely to become foundational in safe agent systems.
And it leads naturally to the next problem.
Because once agents can reason, act, use computers, and make business decisions, companies eventually have to give them access to the one thing they protect most carefully.
Enterprise AI eventually runs into the trust wall
The best enterprise AI use cases are almost always trapped behind sensitive information.
The model that could radically improve legal work needs contracts nobody wants leaking.
The engineering agent needs source code and vulnerability reports.
The healthcare system needs patient information.
The finance agent needs internal forecasts.
The customer-support agent needs customer records.
The research agent needs intellectual property that may represent years of work.
This creates a strange paradox.
The more valuable the AI use case becomes, the more sensitive the context usually becomes too.
That is the problem OpenAI is addressing under the umbrella of Private Intelligence.
One part available today is Zero Data Retention with Private Safety Processing — ZDR with PSP.
The design is worth understanding because it is more interesting than the phrase makes it sound.
Ordinarily, AI providers have a difficult safety problem. They want to protect customers' privacy while still maintaining mechanisms for detecting serious abuse of their systems.
With ZDR plus Private Safety Processing, protected content used for safety review is stored in customer-controlled cloud storage rather than retained by OpenAI as normal customer content. OpenAI says customers control the permissions and enterprise key-management authorization needed to retrieve and decrypt those records.
When automated safety review is necessary, encrypted records are processed inside an approved, hardware-attested environment designed to prevent OpenAI personnel from accessing the underlying content.
Only bounded safety signals and operational metadata leave that protected processing environment in plaintext. OpenAI says the retained customer content is for approved safety purposes only and cannot be used to train models.
Supported customer-controlled storage includes AWS S3, Azure Blob Storage, and Google Cloud Storage.
This is very different from simply putting “we don't train on enterprise data” into a terms page.
It is an attempt to move privacy guarantees deeper into system architecture.
OpenAI also previewed something called Private Inference, expected this fall, which it says will combine confidential computing with strict, verifiable controls. Public technical detail is still limited, so it is too early to make strong claims about exactly what that architecture will guarantee.
But the direction is clear.
The enterprise AI battle is moving from:
Trust our policy.
toward:
Verify the technical boundary.
That is a healthier direction for the industry.
There is an important catch
It would be tempting to connect these announcements into one perfect architecture:
Use Sol for affordable intelligence.
Run it through the Agents API.
Give it computer use.
Constrain sensitive actions with Decisions API.
Protect everything with Private Intelligence.
That would make a lovely architecture diagram.
It would also currently be misleading.
OpenAI's Agents API documentation says the beta presently supports data residency in the United States only and does not support Zero Data Retention, even when using a self-hosted sandbox.
This distinction matters enormously.
Private Intelligence is not a magic privacy switch that automatically applies to every OpenAI capability.
Different endpoints have different retention properties. Some OpenAI APIs can qualify for ZDR while other capabilities preserve application state because state is fundamental to what they do. OpenAI's data-control documentation explicitly distinguishes between these cases.
And this exposes one of the central tensions in agent architecture.
Agents become dramatically more useful when they remember.
Privacy architectures often become dramatically simpler when systems remember nothing.
Those goals pull in opposite directions.
A long-running agent may need persistent sessions, files, intermediate results, browser state, tool history, credentials, and resumable execution.
An organization with strict data-governance requirements may instead demand tight retention windows, geographic residency, customer-controlled encryption, or complete elimination of stored model context.
Reconciling those two worlds is going to be one of the hardest engineering problems in enterprise agent platforms.
Not prompting.
Not model selection.
State.
Who stores it?
Where?
For how long?
Who can decrypt it?
Can the model recover without it?
Can the system be audited?
What happens when a user asks for deletion?
What happens when an agent delegates work to another agent?
What data crosses that boundary?
Those questions are boring compared with benchmark charts.
They are also the questions that decide whether an agent survives an architecture review.
Put the four announcements together
Now the larger pattern starts to appear.
GPT-6.1 Sol pushes capable intelligence farther down the cost curve.
The Agents API packages the machinery needed to keep that intelligence working over time.
Computer use expands the set of software that intelligence can operate.
Decisions API creates a bounded interface between model judgment and application authority.
Private Intelligence pushes privacy controls deeper into the infrastructure required to use sensitive data.
These are not independent product launches.
They are pieces of an emerging agent computing stack.
At the bottom sits increasingly cheap reasoning.
Above that sits execution.
Then tools.
Then state.
Then decision boundaries.
Then security and governance.
The model is still incredibly important.
But the center of gravity is clearly moving outward.
The next moat may not be the model
This has an uncomfortable implication for everyone building AI products.
For a while, simply having access to a better model could produce a surprisingly large product advantage.
That advantage is becoming less durable.
Models improve too quickly.
Prices fall too quickly.
Capabilities diffuse across providers too quickly.
A workflow that only one frontier model could perform six months ago may suddenly work on a cheaper model.
If intelligence keeps commoditizing this way, the durable value moves elsewhere.
Into proprietary context.
Into deeply integrated tools.
Into permissions.
Into evals.
Into workflow design.
Into organizational knowledge.
Into reliability.
Into the accumulated understanding of how a particular company actually operates.
That is why I think the Agents API announcement is strategically more interesting than it first appears.
OpenAI is effectively saying:
We'll increasingly handle the general machinery required to run intelligence. You concentrate on the part that belongs uniquely to your business.
Cloud computing made a similar transition.
Companies once differentiated themselves partly by how well they could operate physical servers.
Then AWS turned servers, queues, object storage, databases, and networking into APIs.
Those components did not stop mattering.
They became infrastructure.
Something similar may now be happening around AI.
Model calls were layer one.
The agent loop came next.
Now execution, context management, computer interaction, decision primitives, multi-agent coordination, safety processing, and persistent work are moving into managed platforms.
Which leaves builders with a more interesting problem.
Not:
How do I call an LLM?
Not even:
How do I build an agent?
But:
What work should this intelligence be trusted with, what does it need to know, what authority should it have, and how do we know when it is doing that work well?
That is a much harder problem.
It is also where the real engineering begins.
The part of DevDay I would pay attention to
The flashy interpretation of DevDay 2026 is that OpenAI released another powerful model and a large collection of agent features.
The more consequential interpretation is that AI is beginning to look less like an API you call and more like a computing substrate you build on.
Intelligence becomes cheap enough to run continuously.
Agents become durable processes instead of prompt-response loops.
Software interfaces become tools agents can operate.
Model judgment becomes something developers can insert inside deterministic workflows.
Security starts moving from contractual promises toward architectural controls.
None of these pieces is finished.
Computer-using agents still make mistakes.
Managed runtimes introduce platform trade-offs.
Decisions API is new.
Private Inference is still a preview.
Agents API currently has real data-retention and residency limitations.
And benchmark performance is never the same thing as production reliability.
But direction matters.
For most of software history, machines were extraordinarily capable but painfully literal. Humans had to translate intent into every menu, API, workflow, rule, and line of code.
We are slowly building a computing layer that works differently.
One where we describe the outcome, give intelligence the right context and tools, constrain its authority, and allow it to work its way toward the result.
If that works, the most important change will not be that software becomes smarter.
It will be that software begins carrying more of the work itself.
And that is a much bigger idea than another model release.
