OpenAI put its Agents API into public beta on 10 September 2026. It is not the Agents SDK, and the difference matters more than the shared name suggests. The SDK was a library you ran yourself. The API is a managed service that exposes the same harness and infrastructure sitting behind Codex and ChatGPT for Work, so a single API call can stand up a production agent with its task, model, tools and compute environment specified together.
We compared the older library against Claude's Agent SDK in our earlier builder's comparison. This is a different question. A managed harness changes what an Australian development team is actually buying, and what it cannot easily change later.
What is the difference between the OpenAI Agents SDK and the Agents API?
The Agents SDK is a client library: your code holds the agent loop, and you run it wherever you like. The Agents API, in public beta from 10 September 2026, is a managed service where OpenAI runs the loop for you. One call specifies task, model, tools and compute environment, and the service handles context compaction, tool loading, parallel tool calls and subagent delegation. You are moving the orchestration layer from your infrastructure onto theirs.
What the managed harness actually gives you
Stripped of announcement language, the capability list is concrete and worth taking seriously:
Automatic context compaction across long sessions, so an agent does not fall over when the conversation outgrows the window.
Tool search, which loads relevant tool definitions on demand instead of carrying every definition in every request.
Programmatic and parallel tool calling.
Native subagent support, where a main agent delegates to parallel subagents that each keep their own context.
A choice of compute environment: an OpenAI-hosted sandbox, your own VPC, or one of nine named sandbox partners including Cloudflare, DigitalOcean, E2B, Modal, Oracle and Vercel.
No additional platform fee beyond token and tool usage, with the underlying Codex harness published as open source.
If you have built agent infrastructure yourself, that list will read as a year of work you did not enjoy doing. Compaction and subagent context isolation in particular are where home-grown harnesses usually break first.
How the two routes compare for a small team
Where the responsibility sits under each approach
| Dimension | Claude Agent SDK, MCP and Claude Code | OpenAI Agents API |
|---|---|---|
| Who runs the loop | You do, in your own process | The vendor does, as a service |
| Tool integration | MCP servers you build and version | Tools declared in the API call |
| Compute location | Wherever you deploy it | Vendor sandbox, your VPC, or a partner |
| Debugging a bad run | Your logs, your process, your breakpoints | Whatever the service surfaces |
| Switching cost later | Model swap, harness stays | Harness and orchestration move with the vendor |
The three questions that decide it
Feature scorecards are the wrong instrument here. Both options can build a working agent. The Australian buyer question is which one a small team can operate, govern and debug in production on a Tuesday afternoon when something has gone wrong.
Governance first. If your agent touches customer records, you have Privacy Act obligations and, in regulated sectors, an APRA or ASIC view on where processing happens and who can see it. A hosted sandbox is fine until someone asks that question in a procurement review. The self-hosted and VPC options exist precisely because that question gets asked, so check early whether your team can actually operate them.
Debuggability second. A managed harness is a black box by design. When compaction drops the wrong context or a subagent returns nonsense, you can only investigate as far as the service lets you. Running the loop yourself is more work and more visibility. Our notes on Claude Agent SDK patterns in Australian production and sandboxing patterns for Australian teams cover what that visibility buys you.
Lock-in third, and be precise about it. Model lock-in is mild; models are swappable. Harness lock-in is not. If your agent's memory, delegation and tool-loading behaviour all live in a vendor's service, moving is a rewrite rather than a configuration change. The open-source harness reduces that risk without removing it, because the managed infrastructure around it is still the vendor's.
What the customer numbers do and do not tell you
The launch carried customer results: an eval score moving from 0.71 to 0.85 with a fourfold latency reduction on subagent orchestration, a 60% reduction in cost per case at one firm, and 86% fewer failed agent responses at a financial services company. These are vendor-published figures from customers who agreed to be quoted, on their own workloads, against their own baselines.
Take them as evidence the thing works at production scale, which is a real and useful claim. Do not take them as a forecast for your workload. Nobody publishes the baseline they started from, and an 86% reduction in failures tells you more about the previous setup than the new one.
Our read for Australian teams
If you have two developers and an agent that needs to run unattended, a managed harness removes work you have no business doing. If you have a compliance function, a regulated dataset, or a five-year horizon on the product, own the orchestration layer and accept the extra engineering. Claude's Agent SDK with MCP gives you that, and Claude Code and managed agents cover the middle ground where you want a harness without owning every part of it.
We scope this decision as a two-week piece of work, usually $9,000 to $15,000, because getting it wrong costs far more than that to unwind. Talk to us through our contact page if you are choosing now, or read OpenAI's launch post for the full capability list.
